While doing some soul searching recently, I realised that in previous posts I’ve glossed over actually deriving transform matrices, and haven’t discussed a methodical way of going about it. If you’ve ever tried working out transforms you know they can be a pain if you don’t know have a set process to follow. Although I’ve given a bunch of examples in previous posts, this post is intended to clear up any confusion that crops up when you’re trying to work out the transforms for your own robot. This is far from an absolute guide covering all the cases, but hopefully it gives a firm enough footing that you can handle the rest.
Note: I’m only going to be dealing with revolute joints in this post. Linear joints are easy (just put the joint offset in the translation part of the transform matrix) and spherical joints are
horrible death beyond the scope of this post.
First thing’s first, quick recap of what transform matrices actually are. A transform matrix changes the coordinate system (reference frame) a point is defined in. We’re using the notation to denote a transformation matrix that transforms a point from reference frame 1 to reference frame 0. To calculate this matrix, we described the transformation from reference frame 0 to reference frame 1.
To make things easier, we’re going to break up each transform matrix into two parts. Unfortunately I haven’t found a great way to denote these two matrices, so we’re going to have to use additional subscripts:
- : accounting for the joint rotation, and
- : accounting for static translations and rotations.
So the matrix accounts for transformations that involve joint angles, and the matrix accounts for all the static transformations between reference frames.
Step 1: Account for the joint rotation
When calculating the transform matrix from a joint to a link’s centre-of-mass (COM), note that the reference frame of the link’s COM rotates along with the angle of the joint. Conversely, the joint’s reference frame does not rotate with the joint angle. Look at this picture!
In these pictures, we’re looking at the transformation from joint i’s reference frame to the COM for link i. denotes the joint angle of joint i. In the first image (on the left) the joint angle is almost 90 degrees, and on the right it’s closer to 45 degrees. Keeping in mind that the reference frame for COM i changes with the joint angle, and the reference frame for joint i does not, helps make deriving the transform matrices much easier.
So, to actually account for joint rotation, all you have to do is determine which axis the joint is rotating around and create the appropriate rotation matrix inside the transform.
For rotations around the x axis:
For rotations around the y axis:
For rotations around the z axis:
And there you go! Easy. The should be one of the above matrices unless something fairly weird is going on. For the arm in the diagram above, the joint is rotating around the axis, so
Step 2: Account for translations and any static axes rotations
Once the joint rotation is accounted for, translations become much simpler to deal with: Just put joint i at 0 degrees and the offset from the origin of reference frame i to i+1 is your translation.
So for the above example, this is what the system looks like when joint i is at 0 degrees:
where I’ve also added labels to the and axes for clarity. Say that the COM is at , then that is what you set the translation values to in the .
Also we need to note that there is a rotation in the axes between reference frames (i.e. and do not point in the same direction for both axes sets). Here the rotation is 90 degrees. So the rotation part of the transformation matrix should be a 90 degree rotation.
Thus, the transformation matrix for our static translations and rotations is
Step 3: Putting them together
This is pretty easy, to compute the full transform from joint i to the COM i you just string together the two matrices derived above:
where I’m using simplified notation on the left-hand side because we don’t need the full notation for clarity in this simple example.
So when you’re transforming a point, you left multiply by :
which is not great notation, but hopefully conveys the idea. To get our point into the reference frame of joint i, we left multiply the point as defined in the reference frame of COM i by .
So there you go! That’s the process for a single joint to COM transform. For transforms from COM to joints it’s even easier because you only need to account for the static offsets and axes rotations.
It’s always nice to have examples, so let’s work through the deriving the transform matrices for the Jaco2 arm as it’s set up in the VREP. The process is pretty straight-forward, with really the only tricky bit converting from the Euler angles that VREP gives you to a rotation matrix that we can use in our transform.
But first thing’s first, load up VREP and drop in a Jaco2 model.
NOTE: I’ve renamed the joints and links to start at 0, to make indexing in / interfacing with VREP easier.
We’re going to generate the transforms for the whole arm piece by piece, sequentially: origin -> link 0 COM, link 0 COM -> joint 0, joint 0 -> link 1 COM, etc. I’m going to use the notation and to denote link i COM and joint i, respectively, in the transform sub and superscripts.
The first transform we want then is for origin -> link 0 COM. There’s no joint rotation that we need to account for in this transform, so we only have to look for static translation and rotation. First click on link 0, and then
- ‘Object/item shift’ button from the toolbar,
- the ‘Position’ tab,
- select the ‘Parent frame’ radio button,
and it will provide you with the translation of link 0’s COM relative to its parent frame, as shown below:
So the translation part of our transformation is .
The rotation part we can see by
- ‘Object/item rotate’ button from the toolbar,
- the ‘Orientation’ tab,
- select the ‘Parent frame’ radio button,
Here, it’s not quite as straight forward to use this info to fill in our transform matrix. So, if we pull up the VREP description for their Euler angles we see that to generate the rotation matrix from them you perform:
where the matrix is a rotation matrix around the axis (as described above). For this works out to no rotation, as you may have guessed. So then our first transform is
For the second transform matrix, from link 0 to joint 0, again we only have to account for static translations and rotations. Pulling up the translation information:
we have the translation .
And this time, for our rotation matrix, there’s a flip in the axes so we have something more interesting than no rotation:
we have Euler angles . This is also a good time to note that the angles are provided in degrees, so let’s convert those over, giving us approximately . Now, calculating our rotation matrix:
which then gives us the transform matrix
And the last thing I’ll show here is accounting for the joint rotation. In the transform from joint 0 to link 1 we have to account for the joint rotation, so we’ll break it down into two matrices as described above. To generate the first one, all we need to know is which axis the joint rotates around. In VREP, this is almost always the axis, but it’s good to double check in case someone has built a weird model. To check, one easy way is to make the joint visible, and the surrounding arm parts invisible:
You can do this by
- double clicking on the joint in the scene hierarchy to get to the Scene Object Properties window,
- selecting the ‘Common’ tab,
- selecting or deselecting check boxes from the ‘Visibility’ box.
As you can see in the image, this joint is indeed rotating around the axis, so the first part of our transformation from joint 0 to link 1 is
The second matrix can be generated as previously described, so I’ll leave that, and the rest of the arm, to you!
If you’d like to see a full arm example, you can check out the tranforms for the UR5 model in VREP up on my GitHub.