Control Engineering

Charlie Masi

How do you simulate a robot?
March 3, 2008

Let me start by admitting that simulating a whole robot is a lot more complex than the simple mechatronic systems I’ve done in the past. That’s a quantitative difference, however, rather than a qualitative one. The approach is the same. In this entry, I’ll only have room to outline the main steps.
The first thing to realize is that the robot does not exist by itself. It is closely coupled to its environment (It’s a Zen thing!), so you have to simulate the environment as well.

Another thing to realize is that, while the ultimate goal is motion in a three-dimensional environment, that’s not the “natural” dimensional space for the robot. A big part of the problem will be to translate back and forth between the robot’s generalized coordinates (axis motions) and the three-space of the outside world.

Basically, what you’re going to do is write down an equation of motion (in generalized coordinates) for the robot that will transform a set of control inputs into a set of motions. The control inputs will appear as an N-dimensional vector, the resulting motion will appear as an M-dimensional vector (maybe M = 3, and maybe not), and the robot will appear as an NxM matrix. Finally, you will apply transformation operators to map the motions back into three-space as needed.
A third thing to realize is that your robot model will not completely replicate the actual robot. You do, however, have control over how closely the model matches the real robot. Making the model “better” (a closer match) requires work.…

Start by counting the robot’s internal degrees of freedom. A degree of freedom is any movement—intentional or not—the thing can make. Start with the intentional ones, such as controlled movement of each joint. Then, add in the usual mechanical errors, such as bearing runout. Finally, look at the elastic-body motions, such as spar-bending motions. You can see that, for a simple six-axis robot, you’ve got a ton of degrees of freedom to deal with.

Happily, you don’t have to model them all. At least, you don’t have to model them all at once. Use what applied mathematicians call a perturbation approach. Start with the largest motions, then treat smaller motions as perturbations on the larger motions. Think Taylor series: start with the big terms and add smaller ones as needed.
For your robot model, the big terms will hopefully be the intentional motions. If not, revisit your mechanical design. Otherwise, controlling the thing will be like pushing a rope.

The gripper’s trajectory in the 5-dimensional (x,y,z,θ,Φ) “real” space is the input information. Required changes in control (configuration) space (D1,D2,D3,D4,D5,D6) are what we want to calculate. The way we’ll make it happen, mathematically, is to form a sensitivity matrix, with each element in the matrix being how much one of the space variables changes with a given change in one of the control variables. That’s something that can be worked out with “simple” solid geometry.

The problem is that, while the sensitivity matrix is fairly easy to calculate, it will only tell us what motion will result from a given set of changes in configuration space, not what configuration changes we need to make to achieve a set of real-space motions. Luckily, one of my heroes, Carl Friedrich Gauss, showed us how to invert the sensitivity matrix in the early 19th Century using a technique now called “Gauss elimination.” The result is a transfer matrix that will calculate required configuration changes to achieve the motion.

So, here’s what you do. Break the trajectory into lots of little tiny bits, then use the transfer matrix to calculate, for the starting point of each bit, the configuration changes needed to reach the end point. Then, do the same thing again, using the ending point as the new starting point. Making the bits small enough—especially where the trajectory has high curvature—controls the error arising from the fact that the robot actuators aren’t really linear.
Of course, the sensitivity matrix isn’t the same throughout the robot’s range of motion. You’ll need a different set of matrix elements at each position. Luckily, the values won’t change too rapidly, so you can work out complete matrices for a relatively small number of (D1, … ,D6) configurations, then interpolate between them.

So that’s the robot model itself, which is a mathematical model. To simulate the thing, you can use a tool like National Instruments’ LabView. Create a LabView virtual instrument (VI) that will take as inputs the present position in both “real” space and robot-configuration space, and the ending point for the next “tiny little bit” of trajectory, and compute the configuration changes to make it happen. Inside that VI will be sub-VIs that perform the mathematical calculations.

It’s worth noting that the current version of LabView has a scripting node and development environment (called LabView MathScript) that allow you to run m-file scripts you may have written in other programming languages—such as Matlab from The MathWorks — in LabView VIs and sub-VIs. This is particularly helpful in this case because making nasty linear algebra calculations is what m-file coding is all about, whereas it can be … shall we say “clumsy” … in pure LabView graphical code. So, I recommend doing the math in Matlab or LabView MathScript and wrapping that up in a LabView scripting VI.

Posted by Charlie Masi on March 3, 2008 | Comments (0)