Control & Robotics Master Manipulator Modeling & Control

Manipulator Modeling & Control

1 Content of this lab

The goal of this lab is to program in C++ the three fundamentals models for robot manipula-
tors:
ˆ Direct Geometric Model: what is the pose of the end-effector for a given joint configura-
tion?
ˆ Inverse Geometric Model: what joint values correspond to a given end-effector pose?
ˆ Kinematic Model: what is the velocity screw of the end-effector when the joints move?
These models will be applied on three different robots, and used to perform basic point-to-point
control.

As it is not a lab on C++, most of the code is already written and you only have to fill the
required functions:
ˆ Robot::init wMe() to initialize the fixed transform between the wrist and end-effector
ˆ Robot::fMw(q) for the direct geometric model wrist-to-fixed frame
ˆ Robot::inverseGeometry(M) for...well, the inverse geometry
ˆ Robot::fJw for the kinematic model wrist-to-fixed frame

1.1 Installing and loading the lab in Qt Creator

This project uses the ROS1 framework which imposes some particular steps to configure the
environment. An actual ROS course will be held in the second semester, for now just configure
as follows:
1. Open a terminal and create (if needed) a ROS workspace: mkdir -p ∼/ros/src
2. Go inside this folder cd ∼/ros/src
3. Download this repository: git clone https://github.com/oKermorgant/ecn manip.
4. Compile the workspace: cd .. && catkin build
5. Create the QtCreator configuration file: cd src/ecn manip && gqt
6. Open QtCreator and load the ∼/ros/src/ecn manip/CMakeLists.txt file
7. The files should be displayed and ready to run
8. Compilation is done by clicking the bottom-left hammer
9. Run your program with the green triangle. It can be stopped by clicking on the red
square
1
Robot Operating System, http://www.ros.org

O. Kermorgant 1
Control & Robotics Master Manipulator Modeling & Control

1.2 Expected work

The only files to be modified are:
ˆ control.cpp: main file where the control is done depending on the current robot mode
ˆ robot turret.cpp: model of the RRP turret robot
ˆ robot kr16.cpp: model of the industrial Kuka KR16 robot
ˆ robot ur10.cpp: model of the Universal Robot UR-10
We will use the ViSP2 library to manipulate mathematical vectors and matrices, including
frame transforms, rotations, etc. The main classes are detailed in Appendix A.
At the end of the lab, you should upload them through the portal on my website

2 The robots
Three robots are proposed with increasing complexity. You should start with the Turret, then
the Kuka KR16 then the UR-10.
For each of these robots, the table of Modified Denavit-Hartenberg parameters should be de-
fined. As we saw during the lectures, once you have the table then the Direct Geometric and
Direct Kinematic Models can be almost automatically derived. A tool is provided in this pack-
age to generate C++ code for the Geometric and Kinematic models, see Appendix B for details
on this tool.
The fixed frame and the end-effector frame are imposed by the schematics. All intermediary
frames have to be placed according to MDH convention, with a final fixed transform between
the wrist and end-effector frames.

2.1 Turret RRP robot

This is a very simple robot to begin the modeling, as shown in the figure.
The fixed frame F0 and end-effector frame Fe are imposed, as well as the
joint direction.
The constant values for this model are: b = 0.5 m and d = 0.1 m.

All computation may be done first without using the Denavit-Hartenberg

parameters as the robot is quite simple.
b

2
Visual Servoing Platform, http://visp.inria.fr

O. Kermorgant 2
Control & Robotics Master Manipulator Modeling & Control

2.2 Kuka KR16 anthropomorphic robot

This robot is a classical 6R architecture with a spherical wrist, as shown in the next figure:

Figure 1: Model of the Kuka KR16 with imposed fixed and end-effector frames

The wrist frame is typically at the common point between joints 4, 5 and 6. The constant
transform w Me between the wrist and the end-effector should include the 0.158 distance and
potential rotations.

2.3 Universal Robot UR-10 anthropomorphic robot

This robot is a less classical 6R architecture, without spherical wrist. A tool is also attached
with an arbitrary end-effector offset.
The Inverse Geometry is given for this robot. The constant transform w Me between the wrist
and the end-effector should include the 0.1922 distance and potential rotations.

O. Kermorgant 3
Control & Robotics Master Manipulator Modeling & Control

Figure 2: Model of the UR-10 with imposed fixed and end-effector frames

2.4 Running the simulation

Once everything is installed and compiled, the base simulation can be run from a terminal (only
1 line depending on the robot you work on):
1 roslaunch ecn_manip turret.launch
2 roslaunch ecn_manip kr16.launch
3 roslaunch ecn_manip ur10.launch

This will display two windows:

ˆ RViz is the 3D simulator to show the current configuration of the robot. It will also
display the base and end-effector frames, and the one that you compute. You can thus
easily check if the computation is fine.

ˆ The other window is composed of 4 panels:

– Buttons at the top left to change the current exercise

– Sliders at the bottom left to manually control the robot (exercises 1 and 2)
– Sliders at the top to change the switching time of the position control (exercises 3+)
– A plotting region with two tabs, one for the operational space and one for the joint
space. The joint space is displayed in a normalized fashion, depending on the joint
limits (upper and lower dotted lines)

O. Kermorgant 4
Control & Robotics Master Manipulator Modeling & Control

3 Building the models

The main code
In the file control.cpp, the if - else if blocks correspond to the 6 exercises to be done for
each robot. Note that if they work for the Turret robot, then they should work for all robots
as long as the model is correct.
The current exercise is changed by using the buttons in the GUI.

Exercise 1: Checking the Direct Geometric Model

In this exercise, the robot follows the manually given joint positions. The task is to build and
print the direct geometric model, depending on the current value of q. This is to be done in
two functions:

ˆ Robot::init wMe() where you have to write the constant matrix w

Me from the end-
effector to the wrist frame

ˆ Robot::fMw(q) where you have to write and return the transform M between the fixed
and wrist frame

Once you have computed the M matrix, the code calls robot->checkPose(M); in order to print
both your matrix and the true one. No need to tell that they should be equal.
What can be told is that it is useless to continue until they are.

Exercise 2: Checking the Direct Kinematic Model (Jacobian)

If you select Manual Operational Velocity in the GUI then the sliders allow you to give a
desired operational velocity (ie twist) for the end-effector.
This velocity is e ve and is defined in the end-effector frame.
The robot Jacobian has to be defined in the function Robot::fJw(q) that should return the
Jacobian of the wrist in the fixed frame.

In the main code, the commanded velocity then to be mapped to the joint velocity in two steps:
 f 
f ∗ Re 0 e ∗
1. Map to the fixed frame: ve = ve
0 f Re
Call M.getRotationMatrix() to get this rotation.
The ecn::putAt function may be of good use.

2. Map to the joint space: q̇ = J+ .f ve∗

Call robot->fJe(q).pseudoInverse() to get the Jacobian pseudo-inverse

You can check that the end-effector is able to follow straight 3D lines in x, y or z direction in
its own frame. Similarly, it should be able to rotate around x, y or z. This means the Jacobian
computation is correct.

O. Kermorgant 5
Control & Robotics Master Manipulator Modeling & Control

Exercise 3: Checking the Inverse Geometric Model

If you select Direct point-to-point in the GUI then the robot will receive two operational
setpoints, at a given sampling time that can be changed with the Switching time slider in
the GUI. The current setpoint is in the matrix Md and its corresponding joint position is in the
vector qf.
Nothing has to be done in the main code, but of course the Robot::inverseGeometry(M)
function has to be filled in order to compute the actual inverse geometry solution. The robot
will try to have all joints reach their desired value as soon as possible, which will lead to a
discontinuous motion.

In practice, this exercise is to check that the Inverse Geometric Model is correct: the robot
should reach the desired pose.

When computing the inverse geometry, try to find a solution as near as possible to the passed q0.

Many useful functions are available to solve classical trigonometric equations. They are detailed
in Appendix C.

A given potential solution should be stored using addCandidate({q1, q2, ..., qn});
At the end of the Inverse Geometry function, use return bestCandidate(q0); that will pick
the candidate that is the nearest from the current joint position and also within joint limits.

Exercise 4: Interpolated point-to-point control

In this exercise the previous pose setpoint M0 and its corresponding joint position q0 should be
used to interpolate the joint positions.

Here the goal is to compute the current setpoint qc = q0 + p(t)(qf − q0 ). The interpolation
function p(t) was defined during the lectures and should take into account the maximum joint
velocity and acceleration that are stored in the vMax and aMax vectors. Basically this amounts
to computing the minimum time tf needed to reach qf from q0 . This computation should be
done in the if(robot->newRef()) and then used to compute the current qCommand.

Exercise 5: Operational control through Inverse Geometric Model

Exercises 3 and 4 lead to the correct pose but not in a straight 3D line. Indeed the robot is
only controlled in the joint space with no constraints between the two extreme poses.
In this exercise, the goal is to perform the interpolation not in the joint space but in the
Cartesian space. In practice, we will compute many poses between M0 and Md and command
the robot to reach sequentially all these poses. As they will be pretty close one from each other,
the resulting motion will be close to a straight line.
The robot->intermediaryPose(M0, Md, alpha) function returns a pose between M0 and Md,
where alpha is between 0 and 1 and should be computed from t, t0 and tf = 1 s.
Then, the inverse geometry of this pose should be sent to the robot as joint position setpoint.

O. Kermorgant 6
Control & Robotics Master Manipulator Modeling & Control

Exercise 6: Operational control through Jacobian

In this exercise the goal is still to follow a straight line between the two points, but this time
by sending a joint velocity command.

As seen in class, this command should make the end-effector approach its desired pose. The
steps are:

1. Compute the pose error in the desired frame: e∗

Me = f M−1 f
e∗ . Me

ˆ in the code, f Me∗ corresponds to Md and f Me to M

ˆ In practice we use the (t, θu) representation with p.buildFrom()

2. Compute the desired linear and angular velocities: v = −λf Me∗ t, ω = −λf Me (θu)
 
+ v
3. Map these velocities to the joint space: q̇ = J
ω
λ is a gain that can be changed from the GUI. Increasing it will lead to a faster convergence.
It can be obtained through robot->lambda().

O. Kermorgant 7
Control & Robotics Master Manipulator Modeling & Control

A Using ViSP
ViSP is a library for Visual Servoing (wait for the M2 Robotics to know more!) and also
includes all necessary tools to play with mathematical vectors, matrices and 3D transforms.
The full documentation is here: http://visp-doc.inria.fr/doxygen/visp-3.1.0/classes.html.
The main classes to be used are:

ˆ vpMatrix: a classical matrix of given dimensions, can be multiplied with other matrices
and vectors if the dimensions are ok. The pseudo-inverse of matrix M is available with
M.pseudoInverse()

ˆ vpColVector: a column vector of given dimension

ˆ vpHomogeneousMatrix: the classical 4 × 4 3D transform matrix

Most of the model computation is about initializing a matrix or vector to correct dimensions
(which is already done) and fill its elements with formulae.
To write 1 at element (i,j) of matrix M, just write M[i][j] = 1;
Similarly, to write 1 at element (i) of vector q, just write q[i] = 1;

3D transforms can be easily changed between homogeneous matrix, rotation matrix, translation
vector or θu vector. Another type called a pose vector consists in the full (t, θu) vector of
dimension 6:
1 vpHomogeneousMatrix M;
2 vpPoseVector p;
3 vpRotationMatrix R;
4 vpTranslationVector t;
5 vpColVector tu(3);
6
7 M.getRotationMatrix()*t; // extract the rotation part from M and multiply with t
8 p.buildFrom(M); // build (t, theta-u) from M
9 t = M.getTranslationVector(); // extract the translation part
10
11 // copy the theta-u part of p into tu
12 for(int i = 0; i < 3; ++i)
13 tu[i] = p[i+3];
14
15 // compute inverse transform
16 M = M.inverse();

Two utility functions are provided to put a matrix or vector into a bigger one:

ˆ void ecn::putAt(M, Ms, r, c): Writes matrix Ms inside matrix M, starting from given
row and column.

ˆ void ecn::putAt(V, Vs, r): Writes column vector Vs inside vector V, starting from
given row. These two functions do nothing but print an error if the submatrix or vector
does not fit in the main one.

O. Kermorgant 8
Control & Robotics Master Manipulator Modeling & Control

B Code generation from Modified Denavit-Hartenberg

parameters
The core of robot modeling is to build the MDH table. From this, the DGM and KM can
be derived automatically. The Inverse Geometry still has to be done by hand (even if some
advanced tools allow code-generation for the IG resolution).
As it is quite tedious to have to compute all matrices when a solution of MDH is investi-
gated, a tool is provided to generate the C++ code. An example can be found in the file
dh example.yml:
1 notation: [alpha, a, theta, r]
2 joint:
3 1: [0, 0, q1, 0]
4 2: [-pi/2, 0, 0, q2]
5 3: [pi/2, 0, q3, r3]
6 4: [-pi/2, a4, q4+pi/2, 0]

The command to be run is: rosrun ecn manip dh code.py <name of the file>.
In the case of the above MDH table, it leads to these outputs:
1 // Generated Jacobian code
2 const double c1 = cos(q[0]);
3 const double c1p3 = cos(q[0]+q[2]);
1 // Generated pose code 4 const double s1 = sin(q[0]);
2 const double c1 = cos(q[0]); 5 const double s1p3 = sin(q[0]+q[2]);
3 const double c1p3 = cos(q[0]+q[2]); 6 J[0][0] = -a4*s1p3 - q[1]*c1;
4 const double c4 = cos(q[3]); 7 J[0][1] = -s1;
5 const double s1 = sin(q[0]); 8 J[0][2] = -a4*s1p3;
6 const double s1p3 = sin(q[0]+q[2]); 9 //J[0][3] = 0;
7 const double s4 = sin(q[3]); 10 J[1][0] = a4*c1p3 - q[1]*s1;
8 M[0][0] = -s4*c1p3; 11 J[1][1] = c1;
9 M[0][1] = -c4*c1p3; 12 J[1][2] = a4*c1p3;
10 M[0][2] = -s1p3; 13 //J[1][3] = 0;
11 M[0][3] = a4*c1p3 - q[1]*s1; 14 //J[2][0] = 0;
12 M[1][0] = -s4*s1p3; 15 //J[2][1] = 0;
13 M[1][1] = -s1p3*c4; 16 //J[2][2] = 0;
14 M[1][2] = c1p3; 17 //J[2][3] = 0;
15 M[1][3] = a4*s1p3 + q[1]*c1; 18 //J[3][0] = 0;
16 M[2][0] = -c4; 19 //J[3][1] = 0;
17 M[2][1] = s4; 20 //J[3][2] = 0;
18 M[2][2] = 0; 21 J[3][3] = -s1p3;
19 M[2][3] = r3; 22 //J[4][0] = 0;
20 M[3][0] = 0; 23 //J[4][1] = 0;
21 M[3][1] = 0; 24 //J[4][2] = 0;
22 M[3][2] = 0; 25 J[4][3] = c1p3;
23 M[3][3] = 1.; 26 J[5][0] = 1.;
24 // End of pose code 27 //J[5][1] = 0;
28 J[5][2] = 1.;
29 //J[5][3] = 0;
30 // End of Jacobian code

This is exactly what you would get by doing the manual computation from the initial table,
which I hope is quite appreciated.

Fixed transforms for initial and end-effector frames can also be written with keys f: and e:

If passing --display the script will display the direct geometry with classical math notations.
It can be useful for the inverse geometry computation.
For a 6-DOF robot, passing --wrist will display useful information to benefit from a spherical
wrist: math expressions for 0 t6 (q1 , q2 , q3 ) and 3 R6 (q4 , q5 , q6 ), and code for 0 R3 (q1 , q2 , q3 ).

O. Kermorgant 9
Control & Robotics Master Manipulator Modeling & Control

C Trigonometric solvers
The code contains solvers for all types of trigonometric equations (except type 1 that is obvious).
They take as argument the coefficients of the equations. They return:

ˆ A std::vector<double> for equations of 1 unknown (types 2 & 3).

We can go through the valid solutions with:
1 // assume q1 should ensure type 2: X.sin(q1) + Y.cos(q1) = Z
2
3 for(double q1: solveType2(X, Y, Z))
4 {
5 // here q1 is a valid solution, may be used to deduce other joint values
6 }

ˆ A std::vector<JointSolution> for equations of 2 unknowns (types 4 to 8).

In this case, the valid solutions can be explored with:
1 // assume q1 and q2 should ensure type 6 equation:
2 // W.sin(q2) = X.cos(q1) + Y.sin(q1) - Z1
3 // W.cos(q2) = X.sin(q1) - Y.cos(q1) - Z1
4
5 for(auto qs: solveType6(X, Y, Z1, Z2, W))
6 {
7 // here a (q1,q2) solution is available in qs.qi and qs.qj
8 }

Furthermore, a function allows retrieving the 12 elements of 0 Mn∗ from the matrix f Me∗ given
to the inverse geometry solver:
1 const auto [xx,xy,xz,yx,yy,yz,zx,zy,zz,tx,ty,tz] = explodeMatrix(fMe_des);

This function output the matrix terms according to:

 
xx yx zx tx
0
xy yy zy ty 
Mn∗ = 0 Mf f Me∗ e Mn =  
xz yz zz tz 
0 0 0 1

O. Kermorgant 10
Control & Robotics Master Manipulator Modeling & Control

Below are listed the syntax for all trigonometric solvers:

Returns
Type Equation Syntax
(vector of)

1 Xqi = Y does not exist qi

2 Xsi + Y ci = Z solveType2(x, y, z) qi

X1 si + Y1 ci = Z1 solveType3(x1, y1, z1, x2, y2,

3 qi
z2)
X2 si + Y2 ci = Z2

X1 qj si = Y1
4 solveType4(x1, y1, x2, y2) (qi , qj )
X 2 q j ci = Y 2

X1 si = Y1 + Z1 qj solveType5(x1, y1, z1, x2, y2,

5 (qi , qj )
z2)
X2 ci = Y2 + Z2 qj

W sj = Xci + Y si + Z1
6 solveType6(x, y, z1, z2, w) (qi , qj )
W cj = Xsi − Y ci + Z2

W1 cj + W2 sj = Xci + Y si + Z1
7 solveType7(x, y, z1, z2, w1, w2) (qi , qj )
W1 sj − W2 cj = Xsi − Y ci + Z2

Xci + Y cij = Z1
8 solveType8(x, y, z1, z2) (qi , qj )
Xsi + Y sij = Z2

O. Kermorgant 11