NXT Programming, Lesson 4

---

Date: 26 09 2008
Duration of activity: over 3 hours
Group members participating: all group members

---

1. The Goal

The goal of the lab session's work is to try to build a robot capable of balancing as well as possible.

2. The Plan

• Analyze given examples for balancing robot


• Rebuild Thomas to become a balancing robot


• Adjust given source code for our robot

3. The Results

3.1. Analysis of alternative sensor options

Before our group started building a new robot for balancing, we considered other options for a sensor than the light one. As it was suggested in Brian Bagnal's book chapter [1] , a tilt sensor could have been a reasonable option as it does not depend on the environment as much as the light sensor (because of light levels or floor patterns). Unfortunately, we didn't have one and we didn't have luck finding it, so we decided to take some other option.

Next thing we considered was a rotation sensor. The idea was to measure the shift of an angle with respect to the robot's mass center. At first this seemed like a very simple and good way, to make Thomas balance, but after researching the topic we found several issues.

First of all the rotation sensor in the NXT set is part of the motor, and does therefore resist a manual rotation of the sensor. For this reason gravity will not be strong (fast) enough to make the rotation-counter turn and let Thomas conclude it is tilting to one side.

The old RCX sensors is a separate module and do not have this internal force-resistance. And unlike the pressure-sensor these are lying around in the legolab. But after further reaching into the sensor we found a cut-through picture of the sensor, which shows that the sensor only is able to count full rotations -- unlike the new NXT-model. This of course makes it unable to measure the small change in angle needed for correcting tilting.
Lego® Rotation Sensor Internals
It may be possible to measure angle-change to some degree, by making a big gear turn by the force of gravity turning a little gear connected to the rotation sensor. Therefore small changes in angle would make the big gear turn a little, but maybe make the little gear turn several times. This all though doesn't seem like a stable way to go.

And finally, after some research into the leJOS API we would out the old RTX rotation-sensor isn't even supported in leJOS NXT. Search For "RCX Rotation Sensor" on this page.

Because of this, we decided to make things work with the light sensor.

3.2. Robot construction

Our group's robot Thomas was constructed to be a two-wheeled robot with a mounted light sensor. To construct everything reasonably correctly, we have followed the instructions that were given in Brian Bagnal's book chapter [1] .

These are the photos of Thomas new looks:

3.1. Figure: The front of Thomas	3.2. Figure: The side of Thomas	3.3. Figure: The back of Thomas

3.3. Analysis of sensor readings

The idea of analyzing the sensor's readings was to determine the balance center of the robot. The given code Sejway.java suggests to start from the robot's balancing position, which is hard to find by hand. During the experiments with balancing, it was reasonable to hardwire a predetermined 'mass center' for the robot into the source code, for the sake of testing speed.

This is what we got:

3.4. Figure: Thomas goes all the way from front to back (in a linear movement) and rests a little at the balancing point.

3.5. Figure: Thomas is balancing around the balance center.

3.4. P I D values

The point of all this work was to correctly adjust KP, KI, and KD values in the code to make Thomas balance by himself. These short movies show moments of robot trying to desperately balance (while is given some experimental pid values):





4. Conclusion

We weren't able to make Thomas balance, and the rather high number of constants to adjust made the job somewhat insurmountable and dissatisfying. Also, the theory didn't seem to apply: We could not make Thomas oscillate around the balancing point by just adjusting the P factor, as is the suggested procedure.

We did however take the time needed to plot graphs of the tilting action, and this provided a step on the way to understanding why Thomas kept rolling over.

5. References

[1] Brian Bagnal, Maximum LEGO NXT, Building Robots with Java Brains

---