At the forefront of Artificial Intelligence
  Home Articles Reviews Interviews JDK Glossary Features Discussion Search
Home » Articles » Robotics » LEGO Mindstorms

Legway: Building a Self-Balancing Robot with Standard Parts

From the recent review of the Mindstorms RIS 2.0, I was interested in trying my hand a something a little more challenging than following instruction manuals. I decided to follow the hordes of people inspired by Steve Hassenplug's Legway - a self-balancing robot itself inspired by Dean Kamen's Segway. Steve's excellent invention uses a custom EOPD (electro-optical proximity detector) sensors and brickOS (formerly, legOS) to ensure the robot can quickly and accurately maintain balance. My challenge was to do this by just using the standard light sensors and firmware. The result speaks for itself:

Click for larger image

Granted, the robot was nowhere near as stable as Steve's version, and the robot doesn't really balance, more postpones falling for as long as it can! Nevertheless, the robot can stay upright for about 10-15 seconds.

Construction

The robot is extremely simple, with the two motors firmly attached to the base of the RCX unit. The robot also uses two light sensors arranged as symmetrically as possible along the base, between the motors. The sensors are mounted so that they are not flush with the motors, but jut out to be as close to the ground as possible without allowing the robot to rest on them. I have provided some high-resolution renders (courtesy of ML-CAD, L3P, L3PAO, LGEO, and POV-Ray!) and CAD perspective drawing, as well images of the actual model to give you a better idea of the construction:

Perspective CAD drawing 3/4 Front 3/4 Rear
3D rendering of Legway at rest Photo of sensor arrangement The light sensors at work

Programming

As mentioned, I wanted to use the existing firmware, so this meant doing the programming either in the Mindstorms GUI or to use a language like NQC. I choose to use NQC since I am more comfortable with scripted languages (as opposed to drag-and-drop, visual programming) and felt that NQC might offer a small speed advantage. I set about creating a very simple program that simply caused the robot to move backwards if the rear sensor was close to the ground, or forwards if the front sensor was close to the ground. All the thresholds were hardcoded for simplicity. With a little tweaking, it worked!

Next, I expanded the robot by adding a touch sensor to act as a button, then added the necessary code to create a startup calibration process. Firstly, you would tip the robot back then press the touch sensor. The RCX would record the current value of the rear light sensor and use it the threshold. Similarly, you would then tip the robot forward and the same procedure would occur.

Unfortunately, this didn't work. After much experimentation, I commented out the calibration code and made the thresholds constants again. The robot worked! From this I can only assume that the speed at which the robot must check the light sensors has to be so fast that accessing the memory within the loop caused a large enough delay to throw the robot off balance.

Therefore, the code is very basic, and must be calibrated by hand, using the View button on the RCX and updating the constants accordingly. This is relatively simple, and the resultant effect is worth it. Here is the RCX code:

#define SENSOR_3_THRESHOLD 49
#define SENSOR_1_THRESHOLD 45

task main ()
{
  // Setup everything
  SetSensor(SENSOR_1, SENSOR_LIGHT);
  SetSensor(SENSOR_2, SENSOR_TOUCH);
  SetSensor(SENSOR_3, SENSOR_LIGHT);
  SetPower(OUT_A+OUT_C, OUT_FULL);

  // Now balance!
  until(false) {
    if (SENSOR_1 >= SENSOR_1_THRESHOLD) {
      OnFwd(OUT_A);
      OnRev(OUT_C);
      Wait(1);
    }
    if (SENSOR_3 >= SENSOR_3_THRESHOLD) {
      OnRev(OUT_A);
      OnFwd(OUT_C);
    }
  }
}

Balancing doesn't get much simpler than that. In fact, anything more complicated will cause the main loop to slow down and the robot to loose its balance (quicker). I'd definitely be interested to hear about anyone else's attempts at a Legway using standard components.

Last Updated: 10/11/2004

Article content copyright © James Matthews, 2004.
 Article Toolbar
Print
BibTeX entry

Search

Latest News
- Generation5 10-year Anniversary (03/09/2008)
- New Generation5 Design! (09/04/2007)
- Happy New Year 2007 (02/01/2007)
- Where has Generation5 Gone?! (04/11/2005)
- NeuroEvolving Robotic Operatives (NERO) (25/06/2005)

What's New?
- Back-propagation using the Generation5 JDK (07/04/2008)
- Hough Transforms (02/01/2008)
- Kohonen-based Image Analysis using the Generation5 JDK (11/12/2007)
- Modelling Bacterium using the JDK (19/03/2007)
- Modelling Bacterium using the JDK (19/03/2007)


All content copyright © 1998-2007, Generation5 unless otherwise noted.
- Privacy Policy - Legal - Terms of Use -