Tip - Now with Stereo Video Camera Pair - Balancing using inertial measurement unit
February 24, 2004
(click on images to enlarge & use browser back button to return to this page)
Tip, my two wheeled balancing robot, continues to evolve from its beginning in late October, 2003.
As a member of the Dallas Personal Robotics Group, I have received generous coaching on the subject of balancing robots from David Anderson, another member, who has spent the last three years developing a two-wheeled balancing robot of his own, nBot that has been featured as the NASA Cool robot of the week and is well documented on David's site. Thanks to David's help, I have enjoyed learning this science/art at a greatly accelerated pace.
Tip's balance and drive software continues to evolve. As of February 19th, Tip balances using an inertial measurement unit (IMU) composed of a gyroscope and an accelerometer to obtain tilt angle.
Previously a feeler was used and was the first reliable means for balancing the robot. Note that the feeler provides no support for the robot which falls over quickly upon power-down.
Tip - Using Feeler To Balance - Jan. 1, 2004
The first step in building Tip was to create a simulation. I used Delphi, a Visual Object Pascal tool, to write a simulation program. The robot is modeled as a system composed of two masses. A wheel and platform mass and a body mass located at a specified distance above the wheel center. The simulation assumes that the robot wheels do not slip. The moment of inertia is calculated for the body mass and the wheel mass is considered to be a translating mass only with no consideration for wheel/motor rotational inertia.
The simulation provides wheel encoder counts (displacement) from which velocity can be derived. Also, tilt angle provided from which tilt angular velocity can be derived. The system error is derived from these four terms which creates a resultant motor torque demand. Which is met with an ideal motor torque, limited by a variable to help model situations where a motor cannot meet the torque requirement.
Simulation October 2003
Later, I began work on a 3D simulation of Tip using Delphi and with an interface to the OpenGL library implementation running under Microsoft Windows. For the time being I have suspended work on the simulations to pursue development of the "real" Tip, but may resume simulation development in the future as it may help with further development.
Simulated DPRG Contest Arena - November 2003
Tip uses an 8 bit RISC processor (Atmel Mega32) to perform all of the calculations necessary to balance and move about in its environment. Tip is programmed in C using a very handy and low-cost development environment AtMan AVR by Atman Electronics which provides an IDE and code wizards for Atmel AVR microcontroller development using the Freeware GNU C Compiler.
I use the Atmel SDK500 for flash programming the Atmel microcontrollers that I have been using in my robot projects over the past year. The programmer provides sockets for programming devices on the board and also a 6 pin cable for in-circuit programming which is the method I use for programming Tip's microcontroller.
The Mega32 provides 32K of Flash memory and a 2K bytes of RAM. Most instructions execute in a single cycle and the processor does have a 2 cycle 8x8 bit multiplier, but due to extensive use of extended precision arithmetic 16 and 32 bit and some 32 bit floating point operations, performance is somewhat limited. For example, adding two 32 bit integers stored in RAM does require on the order of 35 clock cycles.
I am clocking the CPU at 8 MHz, but may double to 16 MHz to speed my motion controller update rate which is presently 25 Hz. I may still have CPU time available for faster update rate, but cannot remember since memory fades and documentation requires effort to produce.
Tip's two Pittman 9000 series motors are 5.9:1 gear reduced and optically encoded providing 3,000 counts per wheel revolution or about 187 counts per linear inch of travel with its 5.1" diameter wheels.
Motor power is derived from 20 Ni-MH "AA" Cells providing a nominal motor voltage of approximately 25 volts. The processor is powered from 4 separate "AA" Ni-MH cells, which I do not regulate.
Motor drive is accomplished by PWM at about 8000 Hz switched by two Allegro 3 amp NMOS H-Bridges. The parts are so efficient that they do not need heat sinks.
Tip can communicate serially with a dumb terminal or computer program for setting/reading variables and executing commands. This communication was previously wired, but now wireless thanks to an Air Cable wireless link. The Air Cable talks Bluetooth amongst its selves, but to the user it appears as a serial cable with just a little transmission delay of like about 10 ms.
The angle feeler is simply an arm connected to potentiometer which is connected as a variable voltage divider providing a voltage proportional to the tilt angle of the robot.
Tip expects to be held in a balanced position on power-up. It samples the tilt potentiometer a few times and averages to obtain a bias subtracted from subsequent tilt readings.
For "my" IMU implementation I am using the gyroscope and accelerometer module from a 2 Degree of Freedom IMU produced by Rotomotion, LLC. Also, I am using the Kalman filter code written by Rotomotion's founder Trammell Hudson. The Kalman filter uses magic to tie both gyro and accelerometer together to produce angular orientation information with a minimum of error.
The Rotomotion module uses a Tokin CG-16D gyro rated at a maximum angular rate of 90 degrees per second, which appears to peform well, although I have not characterized loss of balance in extreme situations, i.e. sensor failure versus robot drive limitations. The accelerometer used is an Analog Devices ADXL202 (analog output used - not PWM digital) , the outputs of these devices are amplified and low-pass filtered by the Rotomotion module.
The gyroscope is very good at tracking rotational rate which can be integrated to deduce angular position, but with some difficulty in determining/maintaining absolute orientation. The accelerometer which is effectively a mass "sitting" (compressing) a spring which when tilted allows the spring to expand until the system is tilted over 90 degrees at which time the spring extends to its natural length. The length of the spring is reported as an analog voltage which is measured by the microcontroller. If the robot is accelerating or decelerating the spring will compress or stretch producing incorrect tilt information. Through some magic I do not yet understand, the gyro and the accelerometer data are used to produce an estimate of absolute angular position by the Kalman filter.
I am guessing the fact the acceleration nets to zero over a long time period, and this helps a filtered version of the accelerometer reading to acquire absolute tilt, with gyro input providing short term incremental data. If that is right, I don't yet understand exactly how that happens.
My Host PC interface includes a display to compare IMU tilt information versus potentiometer information. I am hoping to use this to characterize any problems with the IMU failing in extreme situations. One thought is increasing moment of inertia of robot will slow its tilt rate if that is a limiting factor in balance.
The earlier configuration (shown below) did hold position, but was too "safe" in its geometry, so I modified the robot to make it obvious that the robot should not have a chance of statically balancing by moving its center of gravity higher.
First time balancing with feeler - December 2003
At present (2/23/2004) , I am continuing to work on Tip's balance and driving software while writing software for off board image processing for Tip's stereo video camera pair.
Tip uses two low-cost MOS color video cameras that are time multiplexed. Their video is transmitted via an X-10 wireless video camera transmitter to a host computer equipped with a receiver and video digitizer. The cameras are not frame synchronized and thus frame rate is limited. This is because the digitizer requires a few frame times to re-sync on each camera as Left/Right camera views are transmitted.
I suspect I will be using one camera alone for the short term as I can acquire and process 20-30 frames per second on the remote host versus about 2 to 3 stereo pairs due to the frame sync problem. Also, a problem with the stereo pairs is that they are not acquired at the same instant of time adding complexity to the image processing particularly if the robot or objects in view are in motion.
I will have some MPEG video up on this site soon. Tip really does balance!