PiTeR balancing and driving
To balance the robot, we use what is called a PID controller. PID stands for Proportional, Integral, Derivative. Here is how it works:
To keep the robot vertical, the controller reads the angle measured by the Inertial Measurement Unit (IMU). It then uses the motor controller to output current to drive the motors forwards or backwards to produce just the right amount of torque to counteract any deviation from the desired upright angle. The right amount of torque is produced by tuning the three P, I and D constants shown above. The error value is simply the difference between the desired angle (which, when balancing we could consider as being zero degrees) and the actual angle measured which could be greater or less than zero depending on whether the robot is tipping forwards or backwards.
Now let's think about getting the robot to move forwards. How does a human do it? The answer is that a walking human is in a perpetual state of falling forwards. In other words we deliberately put our centre of gravity in front of our feet and fall forwards. Our brain then moves a foot forward to catch us and we again allow our centre of gravity to get in front of our feet, then we move our other foot, rinse, repeat and we’re walking! Small wonder it takes babies a year or so to figure out how to do this.
Our robot is going to work exactly the same way. To move forwards, we will deliberately put the angular set point so that the robot centre of gravity is in front of our hub axis. We can leave our newly tuned balancing PID circuit to keep the robot at the desired set point. However, to do so the PID algorithm will have to continually rotate the wheels in a forward direction to keep the angle from getting bigger. Voila! Our robot is traveling forwards.
To slow down, we reverse the action and put the set point so that the centre of gravity is behind the hub axis. Reversing is more of the same, but what about standing still? It follows that we’re going to be standing still when the set point causes the centre of gravity to be exactly over the hub axis.
To control the angle set point, we will introduce a second PID controller. This is called a PID controller cascade.
You may have guessed by now that the angle controller we just tuned is going to be the downstream PID controller in our cascade. It takes the set point and actual angle from the IMU as input and outputs torque to the wheels. The upstream PID controller takes as its set point the desired robot speed. This comes directly from the human driver of the robot. The controller also reads the actual wheel speed as measured by the encoders. It outputs the angle set point and the downstream PID controller does its thing. When standing still, the desired speed set point is zero. The robot will now find its own balance angle zero point where the wheel movement is zero (or as close to it as backlash will allow). Movement forwards or backwards is then achieved by altering the desired speed set point. The upper speed limit is that which requests an angle which requires more torque to recover from than the motors can provide. We find this by experiment and set it as an upper limit in our input to the upstream PID.
The wheel speed PID controller also needs to be tuned, but it is nowhere near as sensitive as the balancing PID controller. The reason for this is that the angle control is a dynamically unstable system; gravity is continually trying to take the robot away from its ideal setpoint. The case of the wheel speed controller is different. If we were trying to stand still and we didn't apply any current to the motors other than to balance, friction would in theory eventually bring the robot to a halt, so there is no force trying to make the robot move.