In the exciting previous post we looked at how to go about generating a Jacobian matrix, which we could use to transformation both from joint angle velocities to end-effector velocities, and from desired end-effector forces into joint angle torques. I briefly mentioned right at the end that using just this force transformation to build your control signal was only appropriate for very simple systems that didn’t have to account for things like arm-link mass or gravity.

In general, however, mass and gravity must be accounted for and cancelled out. The full dynamics of a robot arm are

where is joint angle acceleration, is the control signal (specifying torque), is a function describing the Coriolis and centrifugal effects, is the effect of gravity in joint space, and is the mass matrix of the system in joint space.

There are a lot of terms involved in the system acceleration, so while the Jacobian can be used to transform forces between coordinate systems it is clear that just setting the control signal is not sufficient, because a lot of the dynamics affecting acceleration aren’t accounted for. In this section an effective PD controller operating in joint space will be developed that will allow for more precise control by cancelling out unwanted acceleration terms. To do this the effects of inertia and gravity need to be calculated.

**Accounting for inertia**

The fact that systems have mass is a pain in our controller’s side because it introduces inertia into our system, making control of how the system will move at any given point in time more difficult. Mass can be thought of as an object’s unwillingness to respond to applied forces. The heavier something is, the more resistant it is to acceleration, and the force required to move a system along a desired trajectory depends on both the object’s mass and its current acceleration.

To effectively control a system, the system inertia needs to be calculated so that it can be included in the control signal and cancelled out.

Given the robot arm above, operating in the plane, with the axis extending into the picture where the yellow circles represent each links centre-of-mass (COM). The position of each link is COM is defined relative to that link’s reference frame, and the goal is to figure out how much each link’s mass will affect the system dynamics.

The first step is to transform the representation of each of the COM from Cartesian coordinates in the reference frame of their respective arm segments into terms of joint angles, such that the Jacobian for each COM can be calculated.

Let the COM positions relative to each segment’s coordinate frame be

The first segment’s COM is already in base coordinates (since the first link and the base share the same coordinate frame), so all that is required is the position of the second link’s COM in the base reference frame, which can be done with the transformation matrix

Using to transform the gives

To see the full computation worked out explicitly please see my previous robot control post.

Now that we have the COM positions in terms of joint angles, we can find the Jacobians for each point through our Jacobian equation:

.

Using this for each link gives us:

.

Kinetic energy

The total energy of a system can be calculated as a sum of the energy introduced from each source. The Jacobians just derived will be used to calculate the kinetic energy each link generates during motion. Each link’s kinetic energy will be calculated and summed to get the total energy introduced into the system by the mass and configuration of each link.

Kinetic energy (KE) is one half of mass times velocity squared:

where is the mass matrix of the system, with the subscript denoting that it is defined in Cartesian space, and is a velocity vector, where is of the form

and the mass matrix is structured

where is the mass of COM , and the terms are the moments of inertia, which define the object’s resistance to change in angular velocity about the axes, the same way that the mass element defines the object’s resistance to changes in linear velocity.

As mentioned above, the mass matrix for the COM of each link is defined in Cartesian coordinates in its respective arm segment’s reference frame. The effects of mass need to be found in joint angle space, however, because that is where the controller operates. Looking at the summation of the KE introduced by each COM:

and substituting in ,

and moving the terms outside the summation,

Defining

gives

which is the equation for calculating kinetic energy in joint space. Thus, denotes the inertia matrix in joint space.

Now that we’ve successfully calculated the mass matrix of the system in joint space, we can incorporate it into our control signal and cancel out its effects on the system dynamics! On to the next problem!

**Accounting for gravity**

With the forces of inertia accounted for, we can now address the problem of gravity. To compensate for gravity the concept of conservation of energy (i.e. the work done by gravity is the same in all coordinate systems) will once again be pulled out. The controller operates by applying torque on joints, so it is necessary to be able to calculate the effect of gravity in joint space to cancel it out.

While the effect of gravity in joint space isn’t obvious, it is quite easily defined in Cartesian coordinates in the base frame of reference. Here, the work done by gravity is simply the summation of the distance each link’s center of mass has moved multiplied by the force of gravity. Where the force of gravity in Cartesian space is the mass of the object multiplied by -9.8m/s along the axis, the equation for the work done by gravity is written:

where is the force of gravity on the th arm segment. Because of the conservation of energy, the equation for work is equivalent when calculated in joint space, substituting into the above equation with the equation for work:

and then substitute in using ,

and cancelling out the terms on both sides,

which says that to find the effect of gravity in joint space simply multiply the mass of each link by its Jacobian, multiplied by the force of gravity in space, and sum over each link. This summation gives the total effect of the gravity on the system.

**Making a PD controller in joint space**

We are now able to account for the energy in the system caused by inertia and gravity, great! Let’s use this to build a simple PD controller in joint space. Control should be very straight forward because once we cancel out the effects of gravity and inertia then we can almost pretend that the system behaves linearly. This means that we can also treat control of each of the joints independently, since their movements no longer affect one another. So in our control system we’re actually going to have a PD controller for each joint.

The above-mentioned nonlinearity that’s left in the system dynamics is due to the Coriolis and centrifugal effects. Now, these can be accounted for, but they require highly accurate model of the moments of inertia. If the moments are incorrect then the controller can actually introduce instability into the system, so it’s better if we just don’t address them.

Rewriting the system dynamics presented at the very top, in terms of acceleration gives

Ideally, the control signal would be constructed

where is the desired acceleration of the system. This would result in system acceleration

which would be ideal. As mentioned, because the Coriolis and centrifugal effects are tricky to account for we’ll leave them out, so the instead the control signal is

Using a standard PD control formula to generate the desired acceleration:

where and are our gain values, and the control signal has been fully defined:

and we’ve successfully build an effective PD controller in joint space!

**Conclusions**

Here we looked at building a PD controller that operates in the joint space of a robotic arm that can cancel out the effects of inertia and gravity. By cancelling out the effects of inertia, we can treat control of each of the joints independently, effectively orthogonalizing their control. This makes PD control super easy, we just set up a simple controller for each joint. Also a neat thing is that all of the required calculations can be performed with algorithms of linear complexity, so it’s not a problem to do all of this super fast.

One of the finer points was that we ignored the Coriolis and centrifugal effects on the robot’s dynamics. This is because in the mass matrix model of the moments of inertia are notoriously hard to accurately capture on actual robots. Often you go based off of a CAD model of your robot and then have to do some fine-tuning by hand. So they will be unaccounted for in our control signal, but most of the time as long as you have a very short feedback loop you’ll be fine.

I am really enjoying working through this, as things build on each other so well here and we’re starting to be able to do some really interesting things with the relatively forward transformation matrices and Jacobians that we learned how to build in the previous posts. This was for a very simple robot, but excitingly the next step after this is moving on to operational space control! At last. From there, we’ll go on to look at more complex robotic situations where things like configuration redundancy are introduced and it’s not quite so straightforward.

Hello,

If I know the CoM of individual links , and I need to get the jacobian of the center of mass , how would I get the com of the whole robot ?

If I have a planar link , say a 2 link robot as you’ve shown, CoM (of the whole robot) would be given by summation of the two individual COMs of the links ?

[Generally ,For a rigid body one could say summation of (mass * lengths)/ summation of (masses). ]

Yup! Exactly right, you can find the CoM of the whole robot by summing (transformations for each link’s CoM * their CoM) / sum of CoMs. There’s an illustration here: http://www.elysium-labs.com/robotics-corner/learn-robotics/biped-basics/center-of-mass/

Hi Travis! Great posts along with great explanations!

But I think you have messed up Tcom1. The transformation matrix you have used is incorrect. I think the Rotation part of it should be

|cos(-theta0) 0 sin(-theta0) |

| 0 1 0 |

|-sin(-theta0) 0 cos(-theta0) |

Can you please check? The final value of Tcom1 is wrong anyway if you multiply the matrices given. Hope I have been of help. 🙂

Hmm, it’s possible! There’s a lot of equations going on and I have definitely made mistakes. But I don’t think that’s going on here, if you look back at my previous post https://studywolf.wordpress.com/2013/09/02/robot-control-jacobians-velocity-and-force/ you can see how you get the answer from multiplying the matrices given. And if you check out my first one https://studywolf.wordpress.com/2013/08/21/robot-control-forward-transformation-matrices/ it shows how I came up with the rotation part for Tcom1.

If there’s still something that catches you as wrong though please let me know! It’s important to me that all the math is correct and I really appreciate people taking the time to work through and double check everything!

Hey Travis,

Can you please clarify this equation

\textbf{W}_g = \Sigma^n_{i=0} (\textbf{F}_{g_i}^T \dot{\textbf{x}}_i)

I don’t know if you are bringing this from somewhere in the previous tutorial but isn’t the work done equal to force * distance, instead of force * velocity as shown in the equation. Am I missing something?

Hi Adnan,

nope you’re not missing anything from another section! Rather it’s that work is equal to force * velocity if we’re considering the work that’s done at some _instant_ of time, which we are! This is because for some instant of time the distance that you’ve move is your velocity. They talk about it a bit more here: http://en.wikipedia.org/wiki/Work_(physics)#Mathematical_calculation

Hope that helps!

[…] in the dynamics of the system, as defined in the previous post, but ignoring the effects of gravity for now, […]

[…] was defined in the previous post, and is defined two posts ago, and and are gain terms, usually set such that , and adding in the null space control signal and […]

Hi Travis!

In your last 2 equations you write that the desired acceleration are the gains values times the error of joint position and error of joint velocity.

But trying to see the physical meaning I see it should be: real acceleration (q_dot_dot) is equal to desired acceleration PLUS these gains times these errors.

Because as you described it in the last formula it would mean that when there is no error in position and velocity there is no desired acceleration.

Please see slide 8 in this presentation: http://www.in.tum.de/fileadmin/user_upload/Lehrstuehle/Lehrstuhl_XXIII/Layout/SBRML_Part2_Task_Space_Control.pdf

What do you think?

Btw Nice job! and greets 🙂

Hi Jaime, greetings!

Humm so I think there may be a bit of confusion about what the last two equations describe. The last two equations here describe the form of the control signal, not the actual dynamics of the system. When you work the control signal (which is the desired acceleration wrapped up with the gravity and inertia compensation terms) into the actual dynamics of the system (described a few lines above), then you’re right. The real acceleration of the system includes the actual dynamics of the system plus these terms added from the control signal. But as they’re written the last two equations only describe the desired control signal, not the real acceleration of the system. Does that help clarify things? 🙂

In the presentation you’ve linked they’re describing the desired acceleration in operational space, and then calculating the corresponding force in operational space, and then translating that into joint torques. Here, we’re still dealing with things in joint space only, but in the next post we discuss operational space control, and you’ll see we actually end up with the same form of equation. Hope that helps! Thanks for the comment!

[…] then using our equations for calculating the system’s inertia and gravity we create our _calc_Mq and _calc_Mq_g […]

Hi, first of all: great job of explaining robotic relevant topics 😉

I think that you forgot the link lengths when stating the coordinates of the respective CoMs.

Glad you found it useful!

Hummm, I’m not sure exactly where you’re referring to. After the first figure, where com_0 and com_1 are defined?

I was wondering about the same section. For instance, if you assume your COM_0 is halfway along the 0th link, then the COM_0 X component should be something like 1/2 * L0 * cos(q0).

Ah I see. You’re right it’s not super clear, when writing I intended that the 1/2 and 1/4 were absolute distances, not relative to the length of L0 or L1.

Hmm, it’s on my list to do a rework of this for clarity, I’ll add this to the list of things to change! Thanks for your feedback!