The Need For Balance

Umashankar Nagarajan's thesis explains why robots in human environments should be dynamically balanced. Simply put, it is because dynamically balanced robots can be of human-like heights and still move nimbly in human spaces whereas statically balanced robots require larger bases to support any given height. To be able to balance, Godfrey must have an Inertial Measurement Unit (IMU) to measure the linear accelerations and angular changes as he moves. I choose to purchase a Sparkfun 9 Degrees of Freedom - Razor IMU.

In addition to a 3-axis accelerometer, 3-axis gyroscope and 3-axis magnetometer (to find north) the IMU has a built-in 8MHz ATmega328. This allows embedded software that initializes the sensors and then communicates their values through a serial port. Sparkfun has preloaded it with some firmware goodies that make it immediately usable. They also supply links to other projects with additional software you can load into the IMU. I connecting the IMU to my Mac using a FTDI Basic Breakout.

After playing with the Sparkfun firmware, I read and loaded the software from AHRS/Head-tracker using 9DOF Razor IMU. Even though I am not interested in a head tracker, its software is extremely helpful for getting a feel of the IMU and where the limitations are in these devices. I highly recommend their graphical test app. It lets you move the device around and see the results of the gyros on your screen. One important thing to notice is that the gyroscopes drift over time and will not come back to the exact same starting location after many motions.

The webpage also explains how to calibrate your IMU. The reason to calibrate becomes clear as you do the process and read their source code. These devices do not give the same output value for the same physical input. For example, if you point one accelerometer axis straight down you can measure the 1G pull the earth is making on the accelerometer. If you invert the axis 180 degrees, you measure its inverse. Ideally, these numbers would have the same magnitude of input (1G in this case). Sadly my device gave 258 and -270 for the X axis, 282 and -248 for y and 221 and 294 for the z. On some of these axes there is a discrepancy of over 20%. Looking at the head tracker code you can see them use some simple algebra to compensate for the differences using calibration values.

Eventually I will carefully go over each of the spec sheets for these devices to better understand their behavior. For now I have a basic sense of what they do and their limitations.

The next post will talk about the software I wrote for Godfrey's IMU.

Lessons Learned

• Gyroscopes drifts over time and therefore cannot be the sole input used to balance Godfrey. If it was used as the sole input, Godfrey would start out vertically and slowly drift and fall over as the errors in the gyro added up. I will need to use an accelerometer to measure the direction of the center of the earth and use that to compensate for the gyro drift.
• Any algorithms I use will either have to handle the innate errors in the sensors or I will have to calibrate to the specific instances of the chips I am using. I would prefer handling the innate errors because that will be easier to build and deploy.
• Having the built-in ATmega328 is great for learning and testing, but in the final product it is unnecessary. Having the CPU adds an unnecessary piece of code to to written and programmed into the device. It also consumes a serial port on the motor base CPU. This CPU should be able to talk to these chips directly and still have more then enough computer cycles to handle its other tasks.