Two Wheel Dynamic Balancing Robot
you will have to use the COM3 of the BX- 24 in order to
configure the serial port in this fashion.
To talk to the Roboteq, you are required to send 10 “CR”
characters to slave it to serial port command mode and then
you will have to split data to it — even if it’s garbage, it needs
data within two seconds to keep the watch dog protection
from kicking in and shutting down the motors. You could
turn off the watch dog protection, but I don’t recommend it
— should your MCU fail, the unit can go mad and do crazy
stuff. If you keep the watch dog timer enabled, it will offer
extra safety in the system. So, it is worth the difficulty of
sending data constantly to the unit to keep this protection.
If you plan to use a lot of power, make sure to use the
right cable and connectors. The emergency stop button — or
dead man switch — is connected to the supply lines of the
Roboteq unit. This unit has the option to supply its voltage
either from an external source or from the motor batteries. I
use the motor batteries and, in this configuration, the two
external supply wires can be used as an off switch if you
short them. I connected two switches in parallel for the kill
switch — one for normal ON/OFF operations and the other
one for the emergency stop.
The ON/OFF is very useful when testing the MCU, as you
do not want power in your motors. I used another battery
( 13 volt) to supply the voltage to the MCU (the BX- 24 has an
onboard regulator for +5V). The grounds are joined together
from the motor batteries, PWM module, MCU, and the
chassis. This will ensure a proper common ground. If you
don’t have proper grounding when testing, be careful when
you unplug the serial port cable or external power supply; it
can make your robot do crazy things because the ADC is very
dependent on the reference to zero and this reference comes
from the ground. Also, if you don’t use a BX- 24, be sure to
check your settings for the Aref (analog reference) pin.
The IMU sensors are mounted very close to the pivot point
of the unit. This helps prevent the accelerometers from moving
forward when the unit tilts. If you put them on the top and the
robot tilts, it will suffer from some linear acceleration due to
the arc that is produced. The closer the IMU is to the pivot
point, the fewer problems it will have with linear accelerations.
When the IMU sensors report an angle, the controller
needs to immediately apply a proportional force in the same
direction in order to restore the platform’s balance, as seen
in Figure 4, where:
F = The proportional force provided in reference to the angle.
G = Gravity.
X = The resulting phenomena caused by moving the motors
toward the angle error.
Also, notice that when the motors move in a certain
direction, they produce counter torque and this force is
applied inversely proportional to the direction the wheels are
turning; this force will move the mounting plate (in this case,
How fast the wheels move is also determined by their
momentum. When torque exceeds the wheels’ momentum,
Figure 5. Balancing the load.
they rotate in the opposite direction; the more torque
required to compensate the angle, the faster the wheels will
move in a certain direction to create the needed torque to
keep the platform from tipping. So, in reality, the balancing
act can be explained in many ways and this will depend on
how you visualize and attack the problem, but the resulting
solution will most likely be the same. A force is required to
counteract the angle error and that force needs to be inversely
proportional to the force that is tilting the platform.
One of the forces that can change the angle of the
platform is gravity — someone pushing it or a change in the
center of gravity. That’s why it’s called a dynamic balancing
platform — it constantly compensates for changes in the
angle to keep the unit in balance. This might mean that the
platform itself may not be leveled or parallel to the ground,
but, when the motors produce zero torque and the angles no
longer change, then the unit is in balance.
If the desired angle is not in the center of gravity, then
the motors will need to move, tilting to keep the angle in the
platform as close to the desired angle as possible. If you want
the platform to hover, the variable “center of gravity” in software
will be equal to the physical “center of gravity” of the unit;
however, if you want it to move forward, the software
variable will be a bit off from the physical one. How little or
how much off it is will determine how fast the robot will go.
If this sounds complicated, don’t get scared; it’s really
more simple than it seems. Let’s illustrate another example to
demonstrate that “level” doesn’t always mean “balanced”:
Notice how the stick is not exactly at its measurable center,
but a bit off to the left to compensate for the weight that it
added on the right cap of the stick. This same principle
Figure 6. The result of overreacting to the reaction force.
SERVO 07.2004 31