Our robots are designed with a very natural input to movement velocity control system. It is very similar to a First Person Shooter (FPS) game where pushing a forward button, a velocity signal (a jog signal) is sent to the base, and the robot will go forward. When the button is released, the jog signal ends, and the robot will come to a stop. From a user experience point of view, velocity control is the most intuitive and responsive approach to controlling the robot.
What’s good?
The velocity is calculated by an absolute encoder and controlled using a Proportional - Integral - Derivative (PID) algorithm. The proportional term is for the fast response time whenever a jog signal is sent and the Derivative term is for stability. The most important term is the Integral. The integral term ensures that the motor reaches the user’s desired velocity, meaning that the motor will be able to draw more current dependent upon the current torque applied to the wheel.
This graph shows what happens when a stall torque is applied to a velocity PID controlled motor. On the left, the Integral term causes the motor to output more and more torque (until it reaches 100% at 1024) to combat the stall torque. On the right is the velocity measurement of this motor during the test. As you can see, it took around 100ms for the motor to re-adjust to its desired velocity when the stalling torque was removed.
Another beautiful thing about velocity control, is that we can control how much velocity increment we want in every computation cycle. In other words, we can control the acceleration of the motor whenever a jog signal is received.
This is how the normal operation without the velocity ramp looks like. During the test, the motor is controlled to operate in one direction, switch to the opposite direction, then come to a complete stop. On the left is the angle travelled by the motor, which is very sharp and abrupt. On the right is the motor’s output, which is also sharp and abrupt, as expected.
Now, for the velocity ramped control. The angles are all smoothed out and the output on the left is noisy due to precision. This is going to be discussed next.
What’s bad?
You might have started to wonder what the trade-off is for this awesome type of control that we were using. Well, we spent a significant amount of time trying to figure out what was wrong with the system when our drive base did not go straight. We eventually found out that the trade-off for this control model requires a significantly high precision.
The most annoying precision issue that we encountered was the rounding issue. For our motor’s drive board, we are using a fixed-point microprocessor, which means that all of the fractions are thrown away during computation.
So what is the rounding issue? Say we have an 8-bit data presentation of 15: 0000 1111. Then we want to shift the data down by 2-bits (or divided by 4), we will have 0000 1111 >> 2 = 0000 0011, which is 3. Now what if we have an 8-bit data presentation of -15: 1111 0001. Then if we do the same thing, shift the data down by 2-bits (or divided by 4), we will have 1111 0001 >> 2 = 1111 1100, which is now -4(?!).
Okay so we found a rounding issue there, what’s the big deal? Well the big deal is because it is velocity based and PID controlled, a small difference in the velocity will result in a big change in the position overtime (because velocity is a time derivative of the position).
This is the graph of the travelled angle difference between the two base’s motors. The huge slopes on the left and right (during acceleration and deceleration) was caused because of the rounding issue. Because we are using differential drives, the left motor is supposed to have a negative velocity, which makes it go faster than the right motor during velocity ramped computation phases.
What to avoid?
As mentioned above, the velocity is a time derivative of the position. The clock is also a very important factor that affects this control model. Trust us when we say this, we have spent a very long time trying to figure out this issue.
As you can see here, the left shows the difference in the clocks for the two motors, and on the right is the difference between the travelled angle by the two motors. The slopes are almost identical. The reason is, that we computed the velocity based on the microprocessor’s clock, so any difference in the clocks will result in a difference in the velocity, even though the measured velocities are still the same.
This issue is really subtle, which is why it was really hard for us to find. The microprocessor’s datasheet does state that the clock will differ by ±1% for each processor, which is considerably big for our application. Our solution? Use a lower error tolerance external clock source.