Equibot the Balancing Robot

Equibot is a balancing robot a bit like a small scale Segway. It is based around a ATMega32 RISC Microcontroller.

Parts list:

  • Sharp GP2D120 Infrared Ranger
  • Embmega32 Development Board from Futurlec (with programming cable).
  • Pololu Dual Serial Motor Controller
  • Hitec HS-311 servo (x2)
  • Acrylic sheet from TAP Plastics.
  • Solderless breadboard from Radio Shack.
  • Screws and spacers from Ace Hardware.
  • 6 NiMh AA batteries with connectors.
  • 7845 5V regulator
  • 3" foam wheels from Hobby Engineering.
  • Metal frame from Hobby Engineering.
  • Hamamatsu P5587 IR sensors (optional)


Construction of the main robot was straightforward. The most complex part was building the quadrature encoder for one of the servos.

The base is built from acrylic sheet. $1/lb from the scrap bin. Cut to shape by scoring the plastic and snapping it. I used a drill (Dremel) to make holes for screws.


6 NiMh batteries. I used the new 15 minute recharge type available from just about anywhere. I use a 7845 5V regulator to provide power to the microcontroller and sensors. The motor controller gets power directly from the batteries as it has its own regulator. I ought to have placed some capacitors across the regulator but everything is well behaved without - even with the microcontroller running at 16MHz.


Equibot has just one sensor: the Sharp infrared ranger. This is positioned facing downwards to measure distance to the floor. The output from this device is used to decide which way the robot is leaning.


Standard Hitec HS-311 servos. They were both modified for 360 degree rotation and the input power was connected directly to the motors so that they could be controlled by PWM. One of the servos also has a quadrature encoder built into it. See the encoder web page for more details. I originally intended for the output from this controller to be used in the controller but ultimately I used it only to investigate the motor response so it's not actually used when running. The following displays how the motor speed, as measured by the encoder, depends on pulse width.

Unloaded motor speed vs. PWM pulse width.

Notice how for low voltages the motor doesn't move at all.


Using AVR-GCC under Windows XP. The ATMega32 has 32K of program space as well as 2K of RAM - plenty for programming in C or C++. In anticipation of doing some complicated development I used floating point arithmetic throughout the code. The required floating point routines provided by the gcc libraries all fit in 32K.

I use a PI (proportional-integral) controller. More details soon... An important point to note is that a PI controller makes small adjustments to correct small errors. Using a small pulse size, however, results in zero motion, as can be seen from the graph above. To make the controller work the motor response was approximately linearised using a simple function.

float fixdrive(float x) {
	if (x<0) {
		x -= threshold;
	} else if (x>0) {
		x += threshold;

Equibot has a 'console' that allows its parameters to be controlled by connecting a terminal to its serial port. That way the code doesn't need to be recompiled each time.

The hardware in equibot is probably right at the edge of what is suitable for this task. The servos aren't powerful enough to right the robot once it falls more than a few degrees, even when running at full power. So no amount of clever software can ever restore equibot to equilibrium when it falls this much. The IR rangefinder only updates at 25Hz. In 0.04s it can move quite a bit. Additionally the power distribution isn't great. Driving the motors causes a current drain that changes the sensor readings significantly even though the digital and ADC electronics have their own 5V regulator. And Equibot has never performed as well as it did on the first day when it would stay upright for as long as I left it. Any future development will require a slightly different design.





Feel free to email me (Dan Piponi) at stirfry (at) sigfpe.com.
Back to Home.