The document describes a control framework called the "stack of tasks" which provides hierarchical task-based control for real-time redundant manipulators. It allows implementation of a data flow graph controlled by Python scripting. Tasks are defined as functions of the robot configuration, time, and other parameters that should converge to zero. The framework computes joint velocities to minimize higher priority tasks while satisfying lower priority tasks when possible. It has been tested on robots including HRP-2, Nao, and Romeo.
Reproducing Kernel Hilbert Space of A Set Indexed Brownian MotionIJMERJOURNAL
ABSTRACT: This study researches a representation of set indexed Brownian motion { : } X X A A A via orthonormal basis, based on reproducing kernel Hilbert space (RKHS). The RKHS associated with the set indexed Brownian motion X is a Hilbert space of real-valued functions on T that is naturally isometric to 2 L ( ) A . The isometry between these Hilbert spaces leads to useful spectral representations of the set indexed Brownian motion, notably the Karhunen-Loève (KL) representation: [ ] X e E X e A n A n where { }n e is an orthonormal sequence of centered Gaussian variables. In addition, we present two special cases of a representation of a set indexed Brownian motion, when ([0,1] ) d A A and A = A( ) Ls .
Reproducing Kernel Hilbert Space of A Set Indexed Brownian MotionIJMERJOURNAL
ABSTRACT: This study researches a representation of set indexed Brownian motion { : } X X A A A via orthonormal basis, based on reproducing kernel Hilbert space (RKHS). The RKHS associated with the set indexed Brownian motion X is a Hilbert space of real-valued functions on T that is naturally isometric to 2 L ( ) A . The isometry between these Hilbert spaces leads to useful spectral representations of the set indexed Brownian motion, notably the Karhunen-Loève (KL) representation: [ ] X e E X e A n A n where { }n e is an orthonormal sequence of centered Gaussian variables. In addition, we present two special cases of a representation of a set indexed Brownian motion, when ([0,1] ) d A A and A = A( ) Ls .
International Conference on Monte Carlo techniques
Closing conference of thematic cycle
Paris July 5-8th 2016
Campus les cordeliers
Jere Koskela's slides
Multinomial Logistic Regression with Apache SparkDB Tsai
Logistic Regression can not only be used for modeling binary outcomes but also multinomial outcome with some extension. In this talk, DB will talk about basic idea of binary logistic regression step by step, and then extend to multinomial one. He will show how easy it's with Spark to parallelize this iterative algorithm by utilizing the in-memory RDD cache to scale horizontally (the numbers of training data.) However, there is mathematical limitation on scaling vertically (the numbers of training features) while many recent applications from document classification and computational linguistics are of this type. He will talk about how to address this problem by L-BFGS optimizer instead of Newton optimizer.
Bio:
DB Tsai is a machine learning engineer working at Alpine Data Labs. He is recently working with Spark MLlib team to add support of L-BFGS optimizer and multinomial logistic regression in the upstream. He also led the Apache Spark development at Alpine Data Labs. Before joining Alpine Data labs, he was working on large-scale optimization of optical quantum circuits at Stanford as a PhD student.
In this lecture, I will describe how to calculate optical response functions using real-time simulations. In particular, I will discuss td-hartree, td-dft and similar approximations.
Code of the multidimensional fractional pseudo-Newton method using recursive ...mathsjournal
The following paper presents one way to define and classify the fractional pseudo-Newton method through a group of fractional matrix operators, as well as a code written in recursive programming to implement this method, which through minor modifications, can be implemented in any fractional fixed-point method that allows solving nonlinear algebraic equation systems.
MVPA with SpaceNet: sparse structured priorsElvis DOHMATOB
The GraphNet (aka S-Lasso), as well as other “sparsity + structure” priors like TV (Total-Variation), TV-L1, etc., are not easily applicable to brain data because of technical problems
relating to the selection of the regularization parameters. Also, in
their own right, such models lead to challenging high-dimensional optimization problems. In this manuscript, we present some heuristics for speeding up the overall optimization process: (a) Early-stopping, whereby one halts the optimization process when the test score (performance on leftout data) for the internal cross-validation for model-selection stops improving, and (b) univariate feature-screening, whereby irrelevant (non-predictive) voxels are detected and eliminated before the optimization problem is entered, thus reducing the size of the problem. Empirical results with GraphNet on real MRI (Magnetic Resonance Imaging) datasets indicate that these heuristics are a win-win strategy, as they add speed without sacrificing the quality of the predictions. We expect the proposed heuristics to work on other models like TV-L1, etc.
International Conference on Monte Carlo techniques
Closing conference of thematic cycle
Paris July 5-8th 2016
Campus les cordeliers
Jere Koskela's slides
Multinomial Logistic Regression with Apache SparkDB Tsai
Logistic Regression can not only be used for modeling binary outcomes but also multinomial outcome with some extension. In this talk, DB will talk about basic idea of binary logistic regression step by step, and then extend to multinomial one. He will show how easy it's with Spark to parallelize this iterative algorithm by utilizing the in-memory RDD cache to scale horizontally (the numbers of training data.) However, there is mathematical limitation on scaling vertically (the numbers of training features) while many recent applications from document classification and computational linguistics are of this type. He will talk about how to address this problem by L-BFGS optimizer instead of Newton optimizer.
Bio:
DB Tsai is a machine learning engineer working at Alpine Data Labs. He is recently working with Spark MLlib team to add support of L-BFGS optimizer and multinomial logistic regression in the upstream. He also led the Apache Spark development at Alpine Data Labs. Before joining Alpine Data labs, he was working on large-scale optimization of optical quantum circuits at Stanford as a PhD student.
In this lecture, I will describe how to calculate optical response functions using real-time simulations. In particular, I will discuss td-hartree, td-dft and similar approximations.
Code of the multidimensional fractional pseudo-Newton method using recursive ...mathsjournal
The following paper presents one way to define and classify the fractional pseudo-Newton method through a group of fractional matrix operators, as well as a code written in recursive programming to implement this method, which through minor modifications, can be implemented in any fractional fixed-point method that allows solving nonlinear algebraic equation systems.
MVPA with SpaceNet: sparse structured priorsElvis DOHMATOB
The GraphNet (aka S-Lasso), as well as other “sparsity + structure” priors like TV (Total-Variation), TV-L1, etc., are not easily applicable to brain data because of technical problems
relating to the selection of the regularization parameters. Also, in
their own right, such models lead to challenging high-dimensional optimization problems. In this manuscript, we present some heuristics for speeding up the overall optimization process: (a) Early-stopping, whereby one halts the optimization process when the test score (performance on leftout data) for the internal cross-validation for model-selection stops improving, and (b) univariate feature-screening, whereby irrelevant (non-predictive) voxels are detected and eliminated before the optimization problem is entered, thus reducing the size of the problem. Empirical results with GraphNet on real MRI (Magnetic Resonance Imaging) datasets indicate that these heuristics are a win-win strategy, as they add speed without sacrificing the quality of the predictions. We expect the proposed heuristics to work on other models like TV-L1, etc.
Task Constrained Motion Planning for Snake RobotGiovanni Murru
Presentation of the work I've done during the Mobile Robotics course, about the task constrained motion planning for a snake-like robot with 24 dof, using probabilistic planning RRT to handle the task.
Convex Optimization Modelling with CVXOPTandrewmart11
An introduction to convex optimization modelling using cvxopt in an IPython environment. The facility location problem is used as an example to demonstrate modelling in cvxopt.
Random Matrix Theory and Machine Learning - Part 3Fabian Pedregosa
ICML 2021 tutorial on random matrix theory and machine learning.
Part 3 covers: 1. Motivation: Average-case versus worst-case in high dimensions 2. Algorithm halting times (runtimes) 3. Outlook
Linear Machine Learning Models with L2 Regularization and Kernel TricksFengtao Wu
The slides are the course project presentation for INFSCI 2915 Machine Learning Foundations course. The presentation reviewed and summarized how the L2 regularization techniques are applied in the linear machine models including linear regression, logistic regression, support vector machine and perceptron learning algorithm. Also the presentation reviewed the quadratic programming problem and took SVM model as an example to illustrate the relation between primal and dual problem. At last, the presentation reviewed the general conclusion which is the representer theorem, and connected the kernel tricks to the L2 regularized linear models.
This Presentation describes, in short, Introduction to Time Series and the overall procedure required for Time Series Modelling including general terminologies and algorithms. However the detailed Mathematics is excluded in the slides, this ppt means to give a start to understanding the Time Series Modelling before going into detailed Statistics.
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
4. Introduction
Theoretical foundations
Software
Introduction
The stack of tasks provides a control framework for real-time
redundant manipulator control
◮ implementation of a data-flow,
◮ control of the graph by python scripting,
◮ task-based hierarchical control,
◮ portable: tested on HRP-2, Nao, Romeo.
The stack of tasks
5. Introduction
Theoretical foundations
Software
Introduction
The stack of tasks provides a control framework for real-time
redundant manipulator control
◮ implementation of a data-flow,
◮ control of the graph by python scripting,
◮ task-based hierarchical control,
◮ portable: tested on HRP-2, Nao, Romeo.
The stack of tasks
6. Introduction
Theoretical foundations
Software
Introduction
The stack of tasks provides a control framework for real-time
redundant manipulator control
◮ implementation of a data-flow,
◮ control of the graph by python scripting,
◮ task-based hierarchical control,
◮ portable: tested on HRP-2, Nao, Romeo.
The stack of tasks
7. Introduction
Theoretical foundations
Software
Introduction
The stack of tasks provides a control framework for real-time
redundant manipulator control
◮ implementation of a data-flow,
◮ control of the graph by python scripting,
◮ task-based hierarchical control,
◮ portable: tested on HRP-2, Nao, Romeo.
The stack of tasks
8. Introduction
Theoretical foundations
Software
Introduction
The stack of tasks provides a control framework for real-time
redundant manipulator control
◮ implementation of a data-flow,
◮ control of the graph by python scripting,
◮ task-based hierarchical control,
◮ portable: tested on HRP-2, Nao, Romeo.
The stack of tasks
10. Introduction
Theoretical foundations
Software
Rigid body B
◮ Configuration represented by an homogeneous matrix
MB =
RB tB
0 0 0 1
∈ SE(3)
RB ∈ SO(3) ⇔ RT
B RB = I3
Point x ∈ R3 in local frame of B is moved to y ∈ R3 in
global frame:
y
1
= MB
x
1
The stack of tasks
11. Introduction
Theoretical foundations
Software
Rigid body B
◮ Configuration represented by an homogeneous matrix
MB =
RB tB
0 0 0 1
∈ SE(3)
RB ∈ SO(3) ⇔ RT
B RB = I3
Point x ∈ R3 in local frame of B is moved to y ∈ R3 in
global frame:
y
1
= MB
x
1
The stack of tasks
12. Introduction
Theoretical foundations
Software
Rigid body B
◮ Configuration represented by an homogeneous matrix
MB =
RB tB
0 0 0 1
∈ SE(3)
RB ∈ SO(3) ⇔ RT
B RB = I3
Point x ∈ R3 in local frame of B is moved to y ∈ R3 in
global frame:
y
1
= MB
x
1
The stack of tasks
13. Introduction
Theoretical foundations
Software
Rigid body B
◮ Velocity represented by (vB, ωB) ∈ R6 where
˙RB = ˆωBRB
and
ˆω =
0 −ω3 ω2
ω3 0 −ω1
−ω2 ω1 0
is the matrix corresponding to the cross product operator
◮ Velocity of point P on B
vp = ˙tB + ωB × OBP
where OB is the origin of the local frame of B.
The stack of tasks
14. Introduction
Theoretical foundations
Software
Rigid body B
◮ Velocity represented by (vB, ωB) ∈ R6 where
˙RB = ˆωBRB
and
ˆω =
0 −ω3 ω2
ω3 0 −ω1
−ω2 ω1 0
is the matrix corresponding to the cross product operator
◮ Velocity of point P on B
vp = ˙tB + ωB × OBP
where OB is the origin of the local frame of B.
The stack of tasks
15. Introduction
Theoretical foundations
Software
Rigid body B
◮ Velocity represented by (vB, ωB) ∈ R6 where
˙RB = ˆωBRB
and
ˆω =
0 −ω3 ω2
ω3 0 −ω1
−ω2 ω1 0
is the matrix corresponding to the cross product operator
◮ Velocity of point P on B
vp = ˙tB + ωB × OBP
where OB is the origin of the local frame of B.
The stack of tasks
16. Introduction
Theoretical foundations
Software
Configuration space
◮ Robot: set of rigid-bodies linked by
joints B0, · · · Bm.
◮ Configuration: position in space of each
body.
q = (qwaist , θ1, · · · θn−6) ∈ SE(3) × Rn−6
qwaist = (x, y, z, roll, pitch, yaw)
◮ Position of Bi depends on q:
MBi
(q) ∈ SE(3)
The stack of tasks
17. Introduction
Theoretical foundations
Software
Configuration space
◮ Robot: set of rigid-bodies linked by
joints B0, · · · Bm.
◮ Configuration: position in space of each
body.
q = (qwaist , θ1, · · · θn−6) ∈ SE(3) × Rn−6
qwaist = (x, y, z, roll, pitch, yaw)
◮ Position of Bi depends on q:
MBi
(q) ∈ SE(3)
The stack of tasks
18. Introduction
Theoretical foundations
Software
Configuration space
◮ Robot: set of rigid-bodies linked by
joints B0, · · · Bm.
◮ Configuration: position in space of each
body.
q = (qwaist , θ1, · · · θn−6) ∈ SE(3) × Rn−6
qwaist = (x, y, z, roll, pitch, yaw)
◮ Position of Bi depends on q:
MBi
(q) ∈ SE(3)
The stack of tasks
22. Introduction
Theoretical foundations
Software
Task
◮ Definition: function of the
◮ robot configuration,
◮ time and
◮ possibly external parameters
that should converge to 0:
T ∈ C∞
(C × R, Rm
)
◮ Example: position tracking of an end-effector Bee
◮ M(q) ∈ SE(3) position of the end-effector,
◮ M∗
(t) ∈ SE(3) reference position
T(q, t) =
t(M∗−1(t)M(q))
uθ(R∗−1(t)R(q))
where
◮ t() is the translation part of an homogeneous matrix,
◮ R and R∗
are the rotation part of M and M∗
.
The stack of tasks
23. Introduction
Theoretical foundations
Software
Task
◮ Definition: function of the
◮ robot configuration,
◮ time and
◮ possibly external parameters
that should converge to 0:
T ∈ C∞
(C × R, Rm
)
◮ Example: position tracking of an end-effector Bee
◮ M(q) ∈ SE(3) position of the end-effector,
◮ M∗
(t) ∈ SE(3) reference position
T(q, t) =
t(M∗−1(t)M(q))
uθ(R∗−1(t)R(q))
where
◮ t() is the translation part of an homogeneous matrix,
◮ R and R∗
are the rotation part of M and M∗
.
The stack of tasks
24. Introduction
Theoretical foundations
Software
Task
◮ Definition: function of the
◮ robot configuration,
◮ time and
◮ possibly external parameters
that should converge to 0:
T ∈ C∞
(C × R, Rm
)
◮ Example: position tracking of an end-effector Bee
◮ M(q) ∈ SE(3) position of the end-effector,
◮ M∗
(t) ∈ SE(3) reference position
T(q, t) =
t(M∗−1(t)M(q))
uθ(R∗−1(t)R(q))
where
◮ t() is the translation part of an homogeneous matrix,
◮ R and R∗
are the rotation part of M and M∗
.
The stack of tasks
25. Introduction
Theoretical foundations
Software
Task
◮ Definition: function of the
◮ robot configuration,
◮ time and
◮ possibly external parameters
that should converge to 0:
T ∈ C∞
(C × R, Rm
)
◮ Example: position tracking of an end-effector Bee
◮ M(q) ∈ SE(3) position of the end-effector,
◮ M∗
(t) ∈ SE(3) reference position
T(q, t) =
t(M∗−1(t)M(q))
uθ(R∗−1(t)R(q))
where
◮ t() is the translation part of an homogeneous matrix,
◮ R and R∗
are the rotation part of M and M∗
.
The stack of tasks
26. Introduction
Theoretical foundations
Software
Task
◮ Definition: function of the
◮ robot configuration,
◮ time and
◮ possibly external parameters
that should converge to 0:
T ∈ C∞
(C × R, Rm
)
◮ Example: position tracking of an end-effector Bee
◮ M(q) ∈ SE(3) position of the end-effector,
◮ M∗
(t) ∈ SE(3) reference position
T(q, t) =
t(M∗−1(t)M(q))
uθ(R∗−1(t)R(q))
where
◮ t() is the translation part of an homogeneous matrix,
◮ R and R∗
are the rotation part of M and M∗
.
The stack of tasks
27. Introduction
Theoretical foundations
Software
Hierarchical task based control
Given
◮ a configuration q,
◮ two tasks of decreasing priorities:
◮ T1 ∈ C∞
(C × R, Rm1
),
◮ T2 ∈ C∞
(C × R, Rm2
),
compute a control vector ˙q
◮ that makes T1 converge toward 0 and
◮ that makes T2 converge toward 0 if possible.
The stack of tasks
28. Introduction
Theoretical foundations
Software
Hierarchical task based control
Given
◮ a configuration q,
◮ two tasks of decreasing priorities:
◮ T1 ∈ C∞
(C × R, Rm1
),
◮ T2 ∈ C∞
(C × R, Rm2
),
compute a control vector ˙q
◮ that makes T1 converge toward 0 and
◮ that makes T2 converge toward 0 if possible.
The stack of tasks
29. Introduction
Theoretical foundations
Software
Hierarchical task based control
Jacobian:
◮ we denote
◮ Ji = ∂Ti
∂q for i ∈ {1, 2}
◮ then
◮ ∀q ∈ C, ∀t ∈ R, ∀ ˙q ∈ Rn
, ˙Ti = Ji (q, t) ˙q + ∂Ti
∂t (q, t)
We try to enforce
◮ ˙T1 = −λ1T1 ⇒ T1(t) = e−λ1t T1(0) → 0
◮ ˙T2 = −λ2T2 ⇒ T2(t) = e−λ2t T2(0) → 0
◮ λ1 and λ2 are called the gains associated to T1 and T2.
The stack of tasks
30. Introduction
Theoretical foundations
Software
Hierarchical task based control
Jacobian:
◮ we denote
◮ Ji = ∂Ti
∂q for i ∈ {1, 2}
◮ then
◮ ∀q ∈ C, ∀t ∈ R, ∀ ˙q ∈ Rn
, ˙Ti = Ji (q, t) ˙q + ∂Ti
∂t (q, t)
We try to enforce
◮ ˙T1 = −λ1T1 ⇒ T1(t) = e−λ1t T1(0) → 0
◮ ˙T2 = −λ2T2 ⇒ T2(t) = e−λ2t T2(0) → 0
◮ λ1 and λ2 are called the gains associated to T1 and T2.
The stack of tasks
31. Introduction
Theoretical foundations
Software
Hierarchical task based control
Jacobian:
◮ we denote
◮ Ji = ∂Ti
∂q for i ∈ {1, 2}
◮ then
◮ ∀q ∈ C, ∀t ∈ R, ∀ ˙q ∈ Rn
, ˙Ti = Ji (q, t) ˙q + ∂Ti
∂t (q, t)
We try to enforce
◮ ˙T1 = −λ1T1 ⇒ T1(t) = e−λ1t T1(0) → 0
◮ ˙T2 = −λ2T2 ⇒ T2(t) = e−λ2t T2(0) → 0
◮ λ1 and λ2 are called the gains associated to T1 and T2.
The stack of tasks
32. Introduction
Theoretical foundations
Software
Hierarchical task based control
Jacobian:
◮ we denote
◮ Ji = ∂Ti
∂q for i ∈ {1, 2}
◮ then
◮ ∀q ∈ C, ∀t ∈ R, ∀ ˙q ∈ Rn
, ˙Ti = Ji (q, t) ˙q + ∂Ti
∂t (q, t)
We try to enforce
◮ ˙T1 = −λ1T1 ⇒ T1(t) = e−λ1t T1(0) → 0
◮ ˙T2 = −λ2T2 ⇒ T2(t) = e−λ2t T2(0) → 0
◮ λ1 and λ2 are called the gains associated to T1 and T2.
The stack of tasks
33. Introduction
Theoretical foundations
Software
Hierarchical task based control
Jacobian:
◮ we denote
◮ Ji = ∂Ti
∂q for i ∈ {1, 2}
◮ then
◮ ∀q ∈ C, ∀t ∈ R, ∀ ˙q ∈ Rn
, ˙Ti = Ji (q, t) ˙q + ∂Ti
∂t (q, t)
We try to enforce
◮ ˙T1 = −λ1T1 ⇒ T1(t) = e−λ1t T1(0) → 0
◮ ˙T2 = −λ2T2 ⇒ T2(t) = e−λ2t T2(0) → 0
◮ λ1 and λ2 are called the gains associated to T1 and T2.
The stack of tasks
34. Introduction
Theoretical foundations
Software
Moore Penrose pseudo-inverse
Given a matrix A ∈ Rm×n, the Moore Penrose pseudo inverse
A+ ∈ Rn×m of A is the unique matrix satisfying:
AA+
A = A
A+
AA+
= A+
(AA+
)T
= AA+
(A+
A)T
= A+
A
Given a linear system:
Ax = b, A ∈ Rm×n
, x ∈ Rn
, b ∈ Rm
x = A+b minimizes
◮ Ax − b over Rn,
◮ x over argmin Ax − b .
The stack of tasks
35. Introduction
Theoretical foundations
Software
Moore Penrose pseudo-inverse
Given a matrix A ∈ Rm×n, the Moore Penrose pseudo inverse
A+ ∈ Rn×m of A is the unique matrix satisfying:
AA+
A = A
A+
AA+
= A+
(AA+
)T
= AA+
(A+
A)T
= A+
A
Given a linear system:
Ax = b, A ∈ Rm×n
, x ∈ Rn
, b ∈ Rm
x = A+b minimizes
◮ Ax − b over Rn,
◮ x over argmin Ax − b .
The stack of tasks
36. Introduction
Theoretical foundations
Software
Moore Penrose pseudo-inverse
Given a matrix A ∈ Rm×n, the Moore Penrose pseudo inverse
A+ ∈ Rn×m of A is the unique matrix satisfying:
AA+
A = A
A+
AA+
= A+
(AA+
)T
= AA+
(A+
A)T
= A+
A
Given a linear system:
Ax = b, A ∈ Rm×n
, x ∈ Rn
, b ∈ Rm
x = A+b minimizes
◮ Ax − b over Rn,
◮ x over argmin Ax − b .
The stack of tasks
37. Introduction
Theoretical foundations
Software
Moore Penrose pseudo-inverse
Given a matrix A ∈ Rm×n, the Moore Penrose pseudo inverse
A+ ∈ Rn×m of A is the unique matrix satisfying:
AA+
A = A
A+
AA+
= A+
(AA+
)T
= AA+
(A+
A)T
= A+
A
Given a linear system:
Ax = b, A ∈ Rm×n
, x ∈ Rn
, b ∈ Rm
x = A+b minimizes
◮ Ax − b over Rn,
◮ x over argmin Ax − b .
The stack of tasks
38. Introduction
Theoretical foundations
Software
Hierarchical task based control
Resolution of the first constraint:
˙T1 = J1 ˙q +
∂T1
∂t
= −λ1T1 (1)
J1 ˙q = −λ1T1 −
∂T1
∂t
(2)
˙q1 −J+
1 (λ1T1 +
∂T1
∂t
) (3)
Where J+
1 is the (Moore Penrose) pseudo-inverse of J1.
˙q1 minimizes
◮ J1 ˙q + λ1T1 + ∂T1
∂t = ˙T1 + λ1T1
◮ ˙q over argmin J1 ˙q + λ1T1 + ∂T1
∂t
Hence,
◮ if λ1T1 + ∂T1
∂t is in Im(J1), (1) is satisfied
The stack of tasks
39. Introduction
Theoretical foundations
Software
Hierarchical task based control
Resolution of the first constraint:
˙T1 = J1 ˙q +
∂T1
∂t
= −λ1T1 (1)
J1 ˙q = −λ1T1 −
∂T1
∂t
(2)
˙q1 −J+
1 (λ1T1 +
∂T1
∂t
) (3)
Where J+
1 is the (Moore Penrose) pseudo-inverse of J1.
˙q1 minimizes
◮ J1 ˙q + λ1T1 + ∂T1
∂t = ˙T1 + λ1T1
◮ ˙q over argmin J1 ˙q + λ1T1 + ∂T1
∂t
Hence,
◮ if λ1T1 + ∂T1
∂t is in Im(J1), (1) is satisfied
The stack of tasks
40. Introduction
Theoretical foundations
Software
Hierarchical task based control
Resolution of the first constraint:
˙T1 = J1 ˙q +
∂T1
∂t
= −λ1T1 (1)
J1 ˙q = −λ1T1 −
∂T1
∂t
(2)
˙q1 −J+
1 (λ1T1 +
∂T1
∂t
) (3)
Where J+
1 is the (Moore Penrose) pseudo-inverse of J1.
˙q1 minimizes
◮ J1 ˙q + λ1T1 + ∂T1
∂t = ˙T1 + λ1T1
◮ ˙q over argmin J1 ˙q + λ1T1 + ∂T1
∂t
Hence,
◮ if λ1T1 + ∂T1
∂t is in Im(J1), (1) is satisfied
The stack of tasks
41. Introduction
Theoretical foundations
Software
Hierarchical task based control
Resolution of the first constraint:
˙T1 = J1 ˙q +
∂T1
∂t
= −λ1T1 (1)
J1 ˙q = −λ1T1 −
∂T1
∂t
(2)
˙q1 −J+
1 (λ1T1 +
∂T1
∂t
) (3)
Where J+
1 is the (Moore Penrose) pseudo-inverse of J1.
˙q1 minimizes
◮ J1 ˙q + λ1T1 + ∂T1
∂t = ˙T1 + λ1T1
◮ ˙q over argmin J1 ˙q + λ1T1 + ∂T1
∂t
Hence,
◮ if λ1T1 + ∂T1
∂t is in Im(J1), (1) is satisfied
The stack of tasks
42. Introduction
Theoretical foundations
Software
Hierarchical task based control
Resolution of the first constraint:
˙T1 = J1 ˙q +
∂T1
∂t
= −λ1T1 (1)
J1 ˙q = −λ1T1 −
∂T1
∂t
(2)
˙q1 −J+
1 (λ1T1 +
∂T1
∂t
) (3)
Where J+
1 is the (Moore Penrose) pseudo-inverse of J1.
˙q1 minimizes
◮ J1 ˙q + λ1T1 + ∂T1
∂t = ˙T1 + λ1T1
◮ ˙q over argmin J1 ˙q + λ1T1 + ∂T1
∂t
Hence,
◮ if λ1T1 + ∂T1
∂t is in Im(J1), (1) is satisfied
The stack of tasks
43. Introduction
Theoretical foundations
Software
Hierarchical task based control
In fact
∀u ∈ Rn
, J1 ˙q1+(In − J+
1 J1)u = J1 ˙q1
therefore,
˙q = ˙q1 + (In − J+
1 J1)u
also minimizes J1 ˙q + λ1T1 + ∂T1
∂t .
P1 = (In − J+
1 J1) is a projector on J1 kernel:
J1P1 = 0
∀u ∈ Rn, if ˙q = P1u, then, ˙T1 = ∂T1
∂t .
The stack of tasks
44. Introduction
Theoretical foundations
Software
Hierarchical task based control
In fact
∀u ∈ Rn
, J1 ˙q1+(In − J+
1 J1)u = J1 ˙q1
therefore,
˙q = ˙q1 + (In − J+
1 J1)u
also minimizes J1 ˙q + λ1T1 + ∂T1
∂t .
P1 = (In − J+
1 J1) is a projector on J1 kernel:
J1P1 = 0
∀u ∈ Rn, if ˙q = P1u, then, ˙T1 = ∂T1
∂t .
The stack of tasks
45. Introduction
Theoretical foundations
Software
Hierarchical task based control
In fact
∀u ∈ Rn
, J1 ˙q1+(In − J+
1 J1)u = J1 ˙q1
therefore,
˙q = ˙q1 + (In − J+
1 J1)u
also minimizes J1 ˙q + λ1T1 + ∂T1
∂t .
P1 = (In − J+
1 J1) is a projector on J1 kernel:
J1P1 = 0
∀u ∈ Rn, if ˙q = P1u, then, ˙T1 = ∂T1
∂t .
The stack of tasks
46. Introduction
Theoretical foundations
Software
Hierarchical task based control
In fact
∀u ∈ Rn
, J1 ˙q1+(In − J+
1 J1)u = J1 ˙q1
therefore,
˙q = ˙q1 + (In − J+
1 J1)u
also minimizes J1 ˙q + λ1T1 + ∂T1
∂t .
P1 = (In − J+
1 J1) is a projector on J1 kernel:
J1P1 = 0
∀u ∈ Rn, if ˙q = P1u, then, ˙T1 = ∂T1
∂t .
The stack of tasks
47. Introduction
Theoretical foundations
Software
Controlling the second task
We have
˙q = ˙q1 + P1u
˙T2 = J2 ˙q +
∂T2
∂t
˙T2 = J2 ˙q1 +
∂T2
∂t
+ J2P1u
We want
˙T2 = −λ2T2
Thus
−λ2T2 = J2 ˙q1 +
∂T2
∂t
+ J2P1u
J2P1u = −λ2T2 − J2 ˙q1 −
∂T2
∂t
The stack of tasks
48. Introduction
Theoretical foundations
Software
Controlling the second task
We have
˙q = ˙q1 + P1u
˙T2 = J2 ˙q +
∂T2
∂t
˙T2 = J2 ˙q1 +
∂T2
∂t
+ J2P1u
We want
˙T2 = −λ2T2
Thus
−λ2T2 = J2 ˙q1 +
∂T2
∂t
+ J2P1u
J2P1u = −λ2T2 − J2 ˙q1 −
∂T2
∂t
The stack of tasks
49. Introduction
Theoretical foundations
Software
Controlling the second task
We have
˙q = ˙q1 + P1u
˙T2 = J2 ˙q +
∂T2
∂t
˙T2 = J2 ˙q1 +
∂T2
∂t
+ J2P1u
We want
˙T2 = −λ2T2
Thus
−λ2T2 = J2 ˙q1 +
∂T2
∂t
+ J2P1u
J2P1u = −λ2T2 − J2 ˙q1 −
∂T2
∂t
The stack of tasks
50. Introduction
Theoretical foundations
Software
Controlling the second task
Thus
−λ2T2 = J2 ˙q1 +
∂T2
∂t
+ J2P1u
J2P1u = −λ2T2 − J2 ˙q1 −
∂T2
∂t
u = −(J2P1)+
(λ2T2 + J2 ˙q1 +
∂T2
∂t
)
˙q2 ˙q1 + P1u
= ˙q1 − P1(J2P1)+
(λ2T2 + J2 ˙q1 +
∂T2
∂t
))
minimizes ˙T2 + λ2T2 over ˙q1 + Ker J1.
The stack of tasks
51. Introduction
Theoretical foundations
Software
Controlling the second task
Thus
−λ2T2 = J2 ˙q1 +
∂T2
∂t
+ J2P1u
J2P1u = −λ2T2 − J2 ˙q1 −
∂T2
∂t
u = −(J2P1)+
(λ2T2 + J2 ˙q1 +
∂T2
∂t
)
˙q2 ˙q1 + P1u
= ˙q1 − P1(J2P1)+
(λ2T2 + J2 ˙q1 +
∂T2
∂t
))
minimizes ˙T2 + λ2T2 over ˙q1 + Ker J1.
The stack of tasks
55. Introduction
Theoretical foundations
Software
Libraries
◮ jrl-mathtools: implementation of small size matrices,
◮ to be replaced by Eigen
◮ jrl-mal: abstract layer for matrices,
◮ to be replaced by Eigen
◮ abstract-robot-dynamics: abstraction for humanoid
robot description,
◮ jrl-dynamics: implementation of the above abstract
interfaces,
◮ jrl-walkgen: ZMP based dynamic walk generation.
The stack of tasks
56. Introduction
Theoretical foundations
Software
Libraries
◮ jrl-mathtools: implementation of small size matrices,
◮ to be replaced by Eigen
◮ jrl-mal: abstract layer for matrices,
◮ to be replaced by Eigen
◮ abstract-robot-dynamics: abstraction for humanoid
robot description,
◮ jrl-dynamics: implementation of the above abstract
interfaces,
◮ jrl-walkgen: ZMP based dynamic walk generation.
The stack of tasks
57. Introduction
Theoretical foundations
Software
Libraries
◮ jrl-mathtools: implementation of small size matrices,
◮ to be replaced by Eigen
◮ jrl-mal: abstract layer for matrices,
◮ to be replaced by Eigen
◮ abstract-robot-dynamics: abstraction for humanoid
robot description,
◮ jrl-dynamics: implementation of the above abstract
interfaces,
◮ jrl-walkgen: ZMP based dynamic walk generation.
The stack of tasks
58. Introduction
Theoretical foundations
Software
Libraries
◮ jrl-mathtools: implementation of small size matrices,
◮ to be replaced by Eigen
◮ jrl-mal: abstract layer for matrices,
◮ to be replaced by Eigen
◮ abstract-robot-dynamics: abstraction for humanoid
robot description,
◮ jrl-dynamics: implementation of the above abstract
interfaces,
◮ jrl-walkgen: ZMP based dynamic walk generation.
The stack of tasks
59. Introduction
Theoretical foundations
Software
Libraries
◮ jrl-mathtools: implementation of small size matrices,
◮ to be replaced by Eigen
◮ jrl-mal: abstract layer for matrices,
◮ to be replaced by Eigen
◮ abstract-robot-dynamics: abstraction for humanoid
robot description,
◮ jrl-dynamics: implementation of the above abstract
interfaces,
◮ jrl-walkgen: ZMP based dynamic walk generation.
The stack of tasks
60. Introduction
Theoretical foundations
Software
dynamic-graph
◮ Entity
◮ Signal: synchronous interface
◮ Command: asynchronous interface
◮ Factory
◮ builds a new entity of requested type,
◮ new entity types can be dynamically added (advanced).
◮ Pool
◮ stores all instances of entities,
◮ return reference to entity of given name.
The stack of tasks
61. Introduction
Theoretical foundations
Software
dynamic-graph
◮ Entity
◮ Signal: synchronous interface
◮ Command: asynchronous interface
◮ Factory
◮ builds a new entity of requested type,
◮ new entity types can be dynamically added (advanced).
◮ Pool
◮ stores all instances of entities,
◮ return reference to entity of given name.
The stack of tasks
62. Introduction
Theoretical foundations
Software
dynamic-graph
◮ Entity
◮ Signal: synchronous interface
◮ Command: asynchronous interface
◮ Factory
◮ builds a new entity of requested type,
◮ new entity types can be dynamically added (advanced).
◮ Pool
◮ stores all instances of entities,
◮ return reference to entity of given name.
The stack of tasks
63. Introduction
Theoretical foundations
Software
Signal
Synchronous interface storing a given data type
◮ output signals:
◮ recomputed by a callback function, or
◮ set to constant value
◮ warning: setting to constant value deactivate callback,
◮ input signals:
◮ plugged by an output signal, or
◮ set to constant value,
◮ warning: setting to constant value unplugs,
The stack of tasks
64. Introduction
Theoretical foundations
Software
Signal
Synchronous interface storing a given data type
◮ output signals:
◮ recomputed by a callback function, or
◮ set to constant value
◮ warning: setting to constant value deactivate callback,
◮ input signals:
◮ plugged by an output signal, or
◮ set to constant value,
◮ warning: setting to constant value unplugs,
The stack of tasks
65. Introduction
Theoretical foundations
Software
Signal
Synchronous interface storing a given data type
◮ output signals:
◮ recomputed by a callback function, or
◮ set to constant value
◮ warning: setting to constant value deactivate callback,
◮ input signals:
◮ plugged by an output signal, or
◮ set to constant value,
◮ warning: setting to constant value unplugs,
The stack of tasks
66. Introduction
Theoretical foundations
Software
Signal
Synchronous interface storing a given data type
◮ output signals:
◮ recomputed by a callback function, or
◮ set to constant value
◮ warning: setting to constant value deactivate callback,
◮ input signals:
◮ plugged by an output signal, or
◮ set to constant value,
◮ warning: setting to constant value unplugs,
The stack of tasks
67. Introduction
Theoretical foundations
Software
Signal
Synchronous interface storing a given data type
◮ dependency relation: s1 depends on s2 if s1 callback
needs the value of s2,
◮ each signal s stores time of last recomputation in member
s.t
◮ s is said outdated at time t if
◮ t > s.t , and
◮ one dependency s dep of s
◮ is out-dated or
◮ has been recomputed later than s: s dep.t > s.t .
◮ reading an out-dated signal triggers recomputation.
◮ New types can be dynamically added (advanced)
The stack of tasks
68. Introduction
Theoretical foundations
Software
Signal
Synchronous interface storing a given data type
◮ dependency relation: s1 depends on s2 if s1 callback
needs the value of s2,
◮ each signal s stores time of last recomputation in member
s.t
◮ s is said outdated at time t if
◮ t > s.t , and
◮ one dependency s dep of s
◮ is out-dated or
◮ has been recomputed later than s: s dep.t > s.t .
◮ reading an out-dated signal triggers recomputation.
◮ New types can be dynamically added (advanced)
The stack of tasks
69. Introduction
Theoretical foundations
Software
Signal
Synchronous interface storing a given data type
◮ dependency relation: s1 depends on s2 if s1 callback
needs the value of s2,
◮ each signal s stores time of last recomputation in member
s.t
◮ s is said outdated at time t if
◮ t > s.t , and
◮ one dependency s dep of s
◮ is out-dated or
◮ has been recomputed later than s: s dep.t > s.t .
◮ reading an out-dated signal triggers recomputation.
◮ New types can be dynamically added (advanced)
The stack of tasks
70. Introduction
Theoretical foundations
Software
Signal
Synchronous interface storing a given data type
◮ dependency relation: s1 depends on s2 if s1 callback
needs the value of s2,
◮ each signal s stores time of last recomputation in member
s.t
◮ s is said outdated at time t if
◮ t > s.t , and
◮ one dependency s dep of s
◮ is out-dated or
◮ has been recomputed later than s: s dep.t > s.t .
◮ reading an out-dated signal triggers recomputation.
◮ New types can be dynamically added (advanced)
The stack of tasks
71. Introduction
Theoretical foundations
Software
Signal
Synchronous interface storing a given data type
◮ dependency relation: s1 depends on s2 if s1 callback
needs the value of s2,
◮ each signal s stores time of last recomputation in member
s.t
◮ s is said outdated at time t if
◮ t > s.t , and
◮ one dependency s dep of s
◮ is out-dated or
◮ has been recomputed later than s: s dep.t > s.t .
◮ reading an out-dated signal triggers recomputation.
◮ New types can be dynamically added (advanced)
The stack of tasks
72. Introduction
Theoretical foundations
Software
Signal
Synchronous interface storing a given data type
◮ dependency relation: s1 depends on s2 if s1 callback
needs the value of s2,
◮ each signal s stores time of last recomputation in member
s.t
◮ s is said outdated at time t if
◮ t > s.t , and
◮ one dependency s dep of s
◮ is out-dated or
◮ has been recomputed later than s: s dep.t > s.t .
◮ reading an out-dated signal triggers recomputation.
◮ New types can be dynamically added (advanced)
The stack of tasks
74. Introduction
Theoretical foundations
Software
dynamic-graph-python
Python bindings to dynamic-graph
◮ module dynamic graph linked to
libdynamic-graph.so
◮ class Entity
◮ each C++ entity class declared in the factory generates a
python class of the same name,
◮ signals are instance members,
◮ commands are bound to instance methods
◮ method help lists commands
◮ method displaySignals displays signals
◮ class Signal
◮ property value to set and get signal value
◮ remote interpreter to be embedded into a robot controller
(advanced)
The stack of tasks
75. Introduction
Theoretical foundations
Software
dynamic-graph-python
Python bindings to dynamic-graph
◮ module dynamic graph linked to
libdynamic-graph.so
◮ class Entity
◮ each C++ entity class declared in the factory generates a
python class of the same name,
◮ signals are instance members,
◮ commands are bound to instance methods
◮ method help lists commands
◮ method displaySignals displays signals
◮ class Signal
◮ property value to set and get signal value
◮ remote interpreter to be embedded into a robot controller
(advanced)
The stack of tasks
76. Introduction
Theoretical foundations
Software
dynamic-graph-python
Python bindings to dynamic-graph
◮ module dynamic graph linked to
libdynamic-graph.so
◮ class Entity
◮ each C++ entity class declared in the factory generates a
python class of the same name,
◮ signals are instance members,
◮ commands are bound to instance methods
◮ method help lists commands
◮ method displaySignals displays signals
◮ class Signal
◮ property value to set and get signal value
◮ remote interpreter to be embedded into a robot controller
(advanced)
The stack of tasks
77. Introduction
Theoretical foundations
Software
dynamic-graph-python
Python bindings to dynamic-graph
◮ module dynamic graph linked to
libdynamic-graph.so
◮ class Entity
◮ each C++ entity class declared in the factory generates a
python class of the same name,
◮ signals are instance members,
◮ commands are bound to instance methods
◮ method help lists commands
◮ method displaySignals displays signals
◮ class Signal
◮ property value to set and get signal value
◮ remote interpreter to be embedded into a robot controller
(advanced)
The stack of tasks
78. Introduction
Theoretical foundations
Software
dynamic-graph-python
Python bindings to dynamic-graph
◮ module dynamic graph linked to
libdynamic-graph.so
◮ class Entity
◮ each C++ entity class declared in the factory generates a
python class of the same name,
◮ signals are instance members,
◮ commands are bound to instance methods
◮ method help lists commands
◮ method displaySignals displays signals
◮ class Signal
◮ property value to set and get signal value
◮ remote interpreter to be embedded into a robot controller
(advanced)
The stack of tasks
80. Introduction
Theoretical foundations
Software
dynamic-graph-tutorial
>>> from dynamic graph.tutorial import InvertedPendulum, FeedbackController
>>> a = InvertedPendulum (’IP’)
>>> b = FeedbackController (’K’)
>>> a.displaySignals ()
--- <IP> signal list:
|-- <Sig:InvertedPendulum(IP)::input(double)::force (Type Cst) AUTOPLUGGED
‘-- <Sig:InvertedPendulum(IP)::output(vector)::state (Type Cst)
>>> a.help ()
Classical inverted pendulum dynamic model
List of commands:
-----------------
getCartMass: Get cart mass
getPendulumLength: Get pendulum length
getPendulumMass: Get pendulum mass
incr: Integrate dynamics for time step provided as input
setCartMass: Set cart mass
setPendulumLength: Set pendulum length
setPendulumMass: Set pendulum mass
>>> a.help (’incr’)
incr:
Integrate dynamics for time step provided as input
take one floating point number as input
>>>
The stack of tasks
81. Introduction
Theoretical foundations
Software
dynamic-graph-tutorial
>>> from dynamic graph.tutorial import InvertedPendulum, FeedbackController
>>> a = InvertedPendulum (’IP’)
>>> b = FeedbackController (’K’)
>>> a.displaySignals ()
--- <IP> signal list:
|-- <Sig:InvertedPendulum(IP)::input(double)::force (Type Cst) AUTOPLUGGED
‘-- <Sig:InvertedPendulum(IP)::output(vector)::state (Type Cst)
>>> a.help ()
Classical inverted pendulum dynamic model
List of commands:
-----------------
getCartMass: Get cart mass
getPendulumLength: Get pendulum length
getPendulumMass: Get pendulum mass
incr: Integrate dynamics for time step provided as input
setCartMass: Set cart mass
setPendulumLength: Set pendulum length
setPendulumMass: Set pendulum mass
>>> a.help (’incr’)
incr:
Integrate dynamics for time step provided as input
take one floating point number as input
>>>
The stack of tasks
82. Introduction
Theoretical foundations
Software
dynamic-graph-tutorial
>>> from dynamic graph.tutorial import InvertedPendulum, FeedbackController
>>> a = InvertedPendulum (’IP’)
>>> b = FeedbackController (’K’)
>>> a.displaySignals ()
--- <IP> signal list:
|-- <Sig:InvertedPendulum(IP)::input(double)::force (Type Cst) AUTOPLUGGED
‘-- <Sig:InvertedPendulum(IP)::output(vector)::state (Type Cst)
>>> a.help ()
Classical inverted pendulum dynamic model
List of commands:
-----------------
getCartMass: Get cart mass
getPendulumLength: Get pendulum length
getPendulumMass: Get pendulum mass
incr: Integrate dynamics for time step provided as input
setCartMass: Set cart mass
setPendulumLength: Set pendulum length
setPendulumMass: Set pendulum mass
>>> a.help (’incr’)
incr:
Integrate dynamics for time step provided as input
take one floating point number as input
>>>
The stack of tasks
83. Introduction
Theoretical foundations
Software
dynamic-graph-tutorial
>>> from dynamic graph.tutorial import InvertedPendulum, FeedbackController
>>> a = InvertedPendulum (’IP’)
>>> b = FeedbackController (’K’)
>>> a.displaySignals ()
--- <IP> signal list:
|-- <Sig:InvertedPendulum(IP)::input(double)::force (Type Cst) AUTOPLUGGED
‘-- <Sig:InvertedPendulum(IP)::output(vector)::state (Type Cst)
>>> a.help ()
Classical inverted pendulum dynamic model
List of commands:
-----------------
getCartMass: Get cart mass
getPendulumLength: Get pendulum length
getPendulumMass: Get pendulum mass
incr: Integrate dynamics for time step provided as input
setCartMass: Set cart mass
setPendulumLength: Set pendulum length
setPendulumMass: Set pendulum mass
>>> a.help (’incr’)
incr:
Integrate dynamics for time step provided as input
take one floating point number as input
>>>
The stack of tasks
84. Introduction
Theoretical foundations
Software
dynamic-graph-tutorial
>>> from dynamic graph.tutorial import InvertedPendulum, FeedbackController
>>> a = InvertedPendulum (’IP’)
>>> b = FeedbackController (’K’)
>>> a.displaySignals ()
--- <IP> signal list:
|-- <Sig:InvertedPendulum(IP)::input(double)::force (Type Cst) AUTOPLUGGED
‘-- <Sig:InvertedPendulum(IP)::output(vector)::state (Type Cst)
>>> a.help ()
Classical inverted pendulum dynamic model
List of commands:
-----------------
getCartMass: Get cart mass
getPendulumLength: Get pendulum length
getPendulumMass: Get pendulum mass
incr: Integrate dynamics for time step provided as input
setCartMass: Set cart mass
setPendulumLength: Set pendulum length
setPendulumMass: Set pendulum mass
>>> a.help (’incr’)
incr:
Integrate dynamics for time step provided as input
take one floating point number as input
>>>
The stack of tasks
85. Introduction
Theoretical foundations
Software
dynamic-graph-tutorial
Package provides
◮ C++ code of classes InvertedPendulum and
FeedbackController,
◮ explanation about how to create a new entity type in C++,
◮ information about how to create a command in C++,
◮ information about how to create a python module defining
the bindings in cmake,
◮ python script that runs an example.
The stack of tasks
86. Introduction
Theoretical foundations
Software
dynamic-graph-tutorial
Package provides
◮ C++ code of classes InvertedPendulum and
FeedbackController,
◮ explanation about how to create a new entity type in C++,
◮ information about how to create a command in C++,
◮ information about how to create a python module defining
the bindings in cmake,
◮ python script that runs an example.
The stack of tasks
87. Introduction
Theoretical foundations
Software
dynamic-graph-tutorial
Package provides
◮ C++ code of classes InvertedPendulum and
FeedbackController,
◮ explanation about how to create a new entity type in C++,
◮ information about how to create a command in C++,
◮ information about how to create a python module defining
the bindings in cmake,
◮ python script that runs an example.
The stack of tasks
88. Introduction
Theoretical foundations
Software
dynamic-graph-tutorial
Package provides
◮ C++ code of classes InvertedPendulum and
FeedbackController,
◮ explanation about how to create a new entity type in C++,
◮ information about how to create a command in C++,
◮ information about how to create a python module defining
the bindings in cmake,
◮ python script that runs an example.
The stack of tasks
89. Introduction
Theoretical foundations
Software
dynamic-graph-tutorial
Package provides
◮ C++ code of classes InvertedPendulum and
FeedbackController,
◮ explanation about how to create a new entity type in C++,
◮ information about how to create a command in C++,
◮ information about how to create a python module defining
the bindings in cmake,
◮ python script that runs an example.
The stack of tasks
90. Introduction
Theoretical foundations
Software
sot-core
Class FeatureAbstract
◮ function of the robot and environment states
◮ position of an end-effector,
◮ position of a feature in an image (visual servoing)
◮ with values in a Lie group G (SO(3), SE(3), Rn,...),
◮ with a mapping e from G into Rm such that
e(0G) = 0
The stack of tasks
91. Introduction
Theoretical foundations
Software
sot-core
Class FeatureAbstract
◮ function of the robot and environment states
◮ position of an end-effector,
◮ position of a feature in an image (visual servoing)
◮ with values in a Lie group G (SO(3), SE(3), Rn,...),
◮ with a mapping e from G into Rm such that
e(0G) = 0
The stack of tasks
92. Introduction
Theoretical foundations
Software
sot-core
Class FeatureAbstract
◮ function of the robot and environment states
◮ position of an end-effector,
◮ position of a feature in an image (visual servoing)
◮ with values in a Lie group G (SO(3), SE(3), Rn,...),
◮ with a mapping e from G into Rm such that
e(0G) = 0
The stack of tasks
93. Introduction
Theoretical foundations
Software
sot-core
Class FeatureAbstract
◮ function of the robot and environment states
◮ position of an end-effector,
◮ position of a feature in an image (visual servoing)
◮ with values in a Lie group G (SO(3), SE(3), Rn,...),
◮ with a mapping e from G into Rm such that
e(0G) = 0
The stack of tasks
102. Introduction
Theoretical foundations
Software
Packages specific to robots
sot-hrp2
◮ defines a class Robot that provides
◮ ready to use features for feet, hands, gaze and center of
mass,
◮ ready to use tasks for the same end effectors,
◮ an entity Dynamic,
◮ an entity Device (interface with the robot control system)
sot-hrprtc-hrp2
◮ provide an RTC component to integrate sot-hrp2 into the
robot controller.
The stack of tasks
103. Introduction
Theoretical foundations
Software
Utilities
◮ dynamic graph.writeGraph (filename): writes the
current graph in a file using graphviz dot format.
◮ dynamic graph.sot.core.FeaturePosition wraps
two FeaturePoint6d: a value and a reference,
◮ MetaTask6d:
◮ MetaTaskPosture:
◮ MetaTaskKine6d:
◮ MetaTaskKinePosture:
◮ MetaTaskCom:
The stack of tasks
104. Introduction
Theoretical foundations
Software
Utilities
◮ dynamic graph.writeGraph (filename): writes the
current graph in a file using graphviz dot format.
◮ dynamic graph.sot.core.FeaturePosition wraps
two FeaturePoint6d: a value and a reference,
◮ MetaTask6d:
◮ MetaTaskPosture:
◮ MetaTaskKine6d:
◮ MetaTaskKinePosture:
◮ MetaTaskCom:
The stack of tasks
105. Introduction
Theoretical foundations
Software
Utilities
◮ dynamic graph.writeGraph (filename): writes the
current graph in a file using graphviz dot format.
◮ dynamic graph.sot.core.FeaturePosition wraps
two FeaturePoint6d: a value and a reference,
◮ MetaTask6d:
◮ MetaTaskPosture:
◮ MetaTaskKine6d:
◮ MetaTaskKinePosture:
◮ MetaTaskCom:
The stack of tasks
106. Introduction
Theoretical foundations
Software
Utilities
◮ dynamic graph.writeGraph (filename): writes the
current graph in a file using graphviz dot format.
◮ dynamic graph.sot.core.FeaturePosition wraps
two FeaturePoint6d: a value and a reference,
◮ MetaTask6d:
◮ MetaTaskPosture:
◮ MetaTaskKine6d:
◮ MetaTaskKinePosture:
◮ MetaTaskCom:
The stack of tasks
107. Introduction
Theoretical foundations
Software
Utilities
◮ dynamic graph.writeGraph (filename): writes the
current graph in a file using graphviz dot format.
◮ dynamic graph.sot.core.FeaturePosition wraps
two FeaturePoint6d: a value and a reference,
◮ MetaTask6d:
◮ MetaTaskPosture:
◮ MetaTaskKine6d:
◮ MetaTaskKinePosture:
◮ MetaTaskCom:
The stack of tasks
108. Introduction
Theoretical foundations
Software
Utilities
◮ dynamic graph.writeGraph (filename): writes the
current graph in a file using graphviz dot format.
◮ dynamic graph.sot.core.FeaturePosition wraps
two FeaturePoint6d: a value and a reference,
◮ MetaTask6d:
◮ MetaTaskPosture:
◮ MetaTaskKine6d:
◮ MetaTaskKinePosture:
◮ MetaTaskCom:
The stack of tasks
109. Introduction
Theoretical foundations
Software
Utilities
◮ dynamic graph.writeGraph (filename): writes the
current graph in a file using graphviz dot format.
◮ dynamic graph.sot.core.FeaturePosition wraps
two FeaturePoint6d: a value and a reference,
◮ MetaTask6d:
◮ MetaTaskPosture:
◮ MetaTaskKine6d:
◮ MetaTaskKinePosture:
◮ MetaTaskCom:
The stack of tasks
114. Introduction
Theoretical foundations
Software
Running the stack of tasks into OpenHRP-3.1
You need to install:
◮ ros-electric
◮ OpenHRP-3.1
you will find instructions in https://wiki.laas.fr/robots/HRP/Software
Then follow instructions in sot-hrprtc/README.md:
https://github.com/stack-of-tasks/sot-hrprtc-hrp2
The stack of tasks
115. Introduction
Theoretical foundations
Software
Running the stack of tasks into OpenHRP-3.0.7
Assumptions
◮ OpenHRP 3.0.7 is installed
◮ The Stack of Tasks has been installed thanks to previous
slide with install sot.sh in the directory:
/home/ user / devel / ros unstable
◮ Your /opt/grx3.0/HRP2LAAS/bin/config.sh is well setup.
The golden commands
$>roscore
#Launching HRP2 simulation with OpenHPR
$>roslaunch hrp2 bringup openhrp bridge . launch robot := hrp2 14
mode:= d g w i t h s t a b i l i z e r simulation := true
$>rosrun dynamic graph bridge run command
$>>> . . . # create the solver ( see next s l i d e )
$>rosservice c a l l / start dynamic graph
The stack of tasks
116. Introduction
Theoretical foundations
Software
Running the stack of tasks into OpenHRP-3.0.7
Initialize the application: create tracer and solver
[ INFO ] [ WallTime : 1370854858.786392] waiting for
service . . .
I n t e r a c t i n g with remote server .
>>> from dynamic graph . sot . a p p l i c a t i o n . v e l o c i t y .
precomputed tasks import i n i t i a l i z e
>>> solver = i n i t i a l i z e ( robot )
>>> robot . i n i t i a l i z e T r a c e r ( )
The stack of tasks
117. Introduction
Theoretical foundations
Software
Running the stack of tasks into OpenHRP-3.0.7
Build the graph including the pattern generator
[ INFO ] [ WallTime : 1370854858.786392] waiting for
service . . .
I n t e r a c t i n g with remote server .
>>> from
dynamic graph . sot . pattern generator . walking
import CreateEverythingForPG , walkFewSteps
With meta selector
The stack of tasks
118. Introduction
Theoretical foundations
Software
Running the stack of tasks into OpenHRP-3.0.7
Create the graph
>>> CreateEverythingForPG ( robot , solver )
At t h i s stage
( ’ modelDir : ’ ,
’ ˜ / devel / ros−unstable / i n s t a l l / share / hrp2−14 ’ )
( ’modelName : ’ , ’ HRP2JRLmainsmall . wrl ’ )
( ’ s p e c i f i c i t i e s P a t h : ’ ,
’ HRP2SpecificitiesSmall . xml ’ )
( ’ jointRankPath : ’ , ’ HRP2LinkJointRankSmall . xml ’ )
After Task for Right and Left Feet
The stack of tasks