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.
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