In this lab session we will try to make a self-balancing LEGO robot inspired by Steve Hassenplug's original Legway controlled by the RCX [1].
Duration of activity: 7 hours
Group members participating: Ole Rasmussen, Kasper Sørensen
Duration of activity: 7 hours
Group members participating: Ole Rasmussen, Kasper Sørensen
 |
| Figure 1: The NXTWay self-balancing robot inspired by Steve Hassenplug's Legway |
Goal
To complete the exercises for Lego Lab 5.
Plan
Since our goal is to complete the exercises for this weeks lab the plan will be to complete each exercise in sequence:
- Self-balancing robot with light sensor
Constructing and experimenting with a self-balancing NXT robot using a light sensor - Choice of parameters on-the-fly
Expand the self-balancing robot with the ability to change parts of it's source code (constants) on-the-fly via Bluetooth. - Self-balancing robot with color sensor
Experiment with using the color sensor instead of the light sensor for the balancing robot. - Alternative self-balancing robot - horizontal NXT unit
Constructing and experimenting with an alternative self-balancing NXT robot using a light sensor. This robot will have the NXT laying down and an overall different construction.
1. Self-balancing robot with light sensor
We will construct the LEGO robot, NXTway, suggested by Phillippe Hurbain [2] and use the java program Sejway.java from Brian Bagnall [3] on this robot. Then we will experiment with it and try to find out under which conditions it works best.
1.1 Factors
Phillippe Hurbain [2] describes three factors that may influence the workings of the self-balancing robot:
- Lighting conditions: the ambient light may influence the light readings from the sensor. If artificial lighting is used it's also possible that the type of light emitted has an effect. For example Phillippe mentions that fluorescent light is best because it emits very little infrared light that can influence the light sensor.
- Surface: the surface on which the light reflects may affect the light sensor readings. According to Philippe a clear and non-uniform surface is best.
- Equilibrium position: the robot needs to be calibrated to an offset/equilibrium that is perfectly balanced by manually placing it in the desired position. One should be careful when doing this.
1.2 Results
We have tried following Philippes advice and have observed that it was extremely difficult to make the robot balance even in a completely dark room or a room only with fluorescent light. We tried several surfaces: carpet, wooden table, whiteboard; on the carpet it turned out to be impossible to make it balance even for a second, due to the fact that the light readings from the carpet varied too little at different angles. On the whiteboard we were able to make the robot balance for a few seconds as can be seen in the video in figure 2.
| Figure 2: The constructed NXTway in action |
As can be seen from the video the main problem with the balancing is that the robot isn't able to properly counteract the loss of balance; after loosing the balance it will keep driving in the direction of overbalance. This is generally the correct strategy but we believe the specific problem here was that the robot didn't generate enough acceleration to counteract the overbalancing. Since the robot was already providing max power to the motors the only way to increase acceleration that we could think of, was to use wheels of another size. Figure 3 shows the different types of wheels we tried. Of all these it turned out to be the largest wheels that were the best - this makes sense since larger wheels means the robot will move faster and thus also accelerate faster when provided with a quick burst of power. With the larger wheels we were able to make the robot balance a bit longer than before. Figure 4 shows this. The problem with larger wheels is that, due to the increase in acceleration, it will also oscillate more but we couldn't figure out a way to counteract this except adjusting the PID controller itself. We should add that we moved the sensor a bit downwards compared to the robot body to compensate for the increased distance with the larger wheels. This may be a factor affecting the experiment since the distance from the sensor to the ground isn't exactly the same with the large wheels as it is with the standard wheels - even with our height adjustment.
 |
| Figure 3: Wheel sizes used for the self-balancing robot |
| Figure 4: Our modified NXTway with larger wheels |
To sum up: we tried following Phillippes advice but it was still extremely difficult to make the robot balance perfectly. It was impossible to make the robot balance on carpet but on a whiteboard or table it was much better. Using larger wheels improved the balancing time at the cost of more oscillations.
2. Choice of parameters on-the-fly
We have expanded the program for the self-balancing robot such that we can adjust the constants (P, I, D etc) on-the-fly from a PC instead of constantly downloading new programs to the NXT brick. This will make it more convenient to work with and debug in the future.
We have implemented the expansion by using the PCarController.java and BTControlledCar.java java classes. These classes use Bluetooth to communicate between a PC and a NXT. We modified the PC program (PCarController.java) such that we can control the following four values on our NXT: the offset (light value of balance point), kP, kI and kD where the k-values are the constants in our PID controller. The PC GUI is shown on figure 5. Figure 6 shows a video of the robot being controlled from the PC.
Since our source code is almost identical to PCarController.java and BTControlledCar.java except the addition of a few extra controllable variables and running a new Thread on the NXT, we won't show it here.
 |
| Figure 5: The PC GUI for controlling the robots constants |
| Figure 6: The robot being controlled from the PC (figure 5). Legend: O - offset, P,I,D - PID constants |
3. Self-balancing robot with color-sensor
We exchanged the light sensor on our NXTway with a color sensor from the NXT 2.0 set to see if it made the robot balance better.
3.1 Results
The ColorSensor
class in leJOS has different properties that affects the operation of the color sensor. One of these properties is the mode of the sensor that determines what colors it will use as flood light and also how the final light value is calculated from these colors. For our tests we tried these different modes:
class in leJOS has different properties that affects the operation of the color sensor. One of these properties is the mode of the sensor that determines what colors it will use as flood light and also how the final light value is calculated from these colors. For our tests we tried these different modes:
- Colorfull mode: The sensor outputs all supported colors (like a rainbow) and uses these to calculate a final light value by taking an average of the color response
- Red mode: The sensor outputs a red light and reads the returned value as is
- Blue mode: The sensor outputs a blue light and reads the returned value as is
- Green mode: The sensor outputs a green light and reads the returned value as is
In colorfull mode it was impossible to make the robot balance since the light readings would only vary very little with large changes in the angle of the robot. In green and blue mode the change in light vales was much wider when varying the angle of the robot but still not as good as the variation from the standard light sensor. The mode that turned out to work the best was the red mode. This is the same mode the standard light sensor uses, and not surprisingly the results with the color sensor in this mode were the exact same as with the standard light sensor; the robot was just as good (or bad) at balancing with the color sensor as with the light sensor.
4. Alternative self-balancing robot - horizontal NXT unit
We will here test an alternative NXT segway kind of robot. We will construct the NXT Rider [4] and see how well it can be controlled with the program of Philippe Hurbain.
Results
Constructing the NXT Rider was much easier then constructing the LegWay, since the building instructions were very superior. We locked the rider in place, as suggested by the buildings instructions. The program of Phillippe Hurbain would not be able to control the third motor which moved the rider.
Our initial test run showed that the robot were able to stay upright for longer times. We began to experiment with the PID controller constants, using Bluetooth to send over new values to the NXT.
We ended up with a configuration with P = 50, I = 50 and D = 33. We could then observe that if the robot had it's balance, it would keep upright and never fall down. However, if we were to push it too much, it would not be able to accelerate fast enough, and thus have the same problem as the LegWay. A test run can be seen in Figure 7.
| Figure 7: Test run of our final LegWay robot |
We think that we might have been able to make the NXT Rider handle harder pushes if we could use larger wheels. We did not test this though.
References
- [1] Steve Hassenplug, LegWay
- [2] Philippe Hurbain, NXTway
- [3] Brian Bagnall, Maximum Lego NXT - Building Robots with Java Brains, Chapter 11, 243 - 284
- [4] nxtprograms.com, NXT Segway with Rider
