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  , 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.
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.
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  .
|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):
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.
 Brian Bagnal, Maximum LEGO NXT, Building Robots with Java Brains