Team NXT Generation: Final Project

Lesson 3

Date: 15/05 2014

Duration of activity: 09.15 - 14.45

Group members participating: Pætur Askildsen, Christian Hansen, Søren Gregersen, Søren Ditlev and Alexander Rasmussen

Goal

Start work on our tube-balancing robot.

Plan

Find a suitable tube, that is large enough to fit the 16.5 cm wide car. Alexander and Søren G. will be set on this task
Construct the tube-balancing robot, a robot that can balance on top of the tube. Søren G. and Alexander will also do this.
Build a Bluetooth remote control for the car inside the tube and work on the code for the remote controller and the car inside the tube. Pætur will work on this.
Understand, tweak and error-check the code found last time [1] including a PID-controller for the balancing robot and and begin transforming this code into a tube-balancing context usage. Søren D. and Christian will work on this.

Results

Finding a tube

We were able to get our hands on large polystyrene tube. It is 35 cm in diameter which is large enough for our purpose. Furthermore the polystyrene is a very light material which makes the tube lightweight as well, this might be an advantage because it makes it easier for the robot inside the tube to make the tube roll. It may also be a disadvantage, as a heavier tube would result in slower turns, thus giving the tube balancing robot more time to adjust. This logic is derived from information found in session 1, where we found out about the ball for ballbots:

A high friction coefficient of its surface and a low inertia are essential. The CMU Ballbot[3] and Rezero[27]) used a hollow metal sphere with poly-urethane coating. B.B. Rider[22]used a basketball, while BallIP[24] and Adelaide Ballbot[35] used bowling balls coated with a thin layer of rubber. [2].

Figure 1: The polystyrene tube used in the project

Constructing the Tube-Balancing Robot

We constructed a car which we think have the specifications needed to balance on the polystyrene tube. The wheelbase of the car is 25 cm, see figure 2. The axles are tipped 45 degrees to accommodate the curvature of the tube. The car is driven by a single motor since we only need control in one axis - back and forth. At the front end of the car we have only mounted a single wheel, we did this to give the car a more dramatic look, but it does not compromise the balance of the car significantly. At the very center of the car we mounted the gyroscope so that it is perfectly leveled with the car’s alignment to the tube.

Figure 2: The first version of the balancing robot.

The first tests quickly showed, that the robot was not working well with only one front wheel, since it quickly turned right [3], link to video. Our assumption that one wheel does not compromise the balance of the car was wrong. Therefore one additional wheel was mounted on the car, and the third version can be seen in figure 3 below.

Figure 3: The second version of the balancing robot, now with two wheels both at the front and rear end of the car.

The remote controller

The car inside the tube shall only drive forwards and backwards, therefore we built a remote controller with one lever that is connected to a NXT motor. This construction was just a fast mockup for testing and it can be seen in figure 4.

Figure 4: The bluetooth remote to control the car inside the tube

The inspirational code

The inspirational code can be found here in two zip-folders [1]. The LegoControl.zip contains the code for a remote controller and the Legway.zip contains the code for the LegWay that is controlled by this remote controller. Our balancing robot shall not be remote controlled but the car inside the tube shall be remote controlled. This means that the code in Legway.zip has been split in two parts: One with the balancing robot and the other with the remote controlling.

Code for the balancing robot, including PID-controller

The code for the balancing robot has been reorganized and variables have been renamed. The code has been commented on by comparing it to the original NXC code [4] which helps us understand the code written by others. Now the code for the balancing robot is easily understood. This code clean-up procedure was also to remove any unnecessary code.

The 4-parameter linear balancing equation from HiTechnic HTWay Version 1.1. [4] , see figure 5 for code translated to Java, is used as input to a PID-controller, see figure 6, instead of using this directly to power the motor, which is the approach HTWay uses. For the PID-controller we have omitted the time constant, dT, for the integral and derivative term as described in [5].

Figure 5: The linear balancing equation, used as input to a PID-controller.

Figure 6: The PID-controller.

Code for the remote controller

All the code for the remote controlling has been combined into one project of its own apart from the code for the balancing robot. Here comments have been added and unnecessary code has been removed as well as code has been added. An example of this that the remote controlled LegWay could drive forwards and turn, but our remote controlled car shall drive forwards and backwards, so all code for turning has been removed and the code for making it drive backwards has been added.

The original remote controller was calibrated at each launch, which is necessary because it uses the tacho counter to calculate the speed. We decided to stick with the calibration of the remote controller since this also makes it possible to rebuild the controller without having to rewrite the code for it controller. However we had to alter the code for calibrating the remote so that the car inside the tube can drive backwards as well.

The calibration is a two-step process and the instructions for calibrating the remote controller are shown on the display on launch and they are as follows:

Set the lever to the lowest position and press Enter
Set the lever to the highest position and press Enter

The values from the tacho counter in this two step calibration are mapped to the highest possible speed backwards and the highest possible speed forwards, which are -100 and 100 respectively. The code for the calibration can be seen in figure 7.

Figure 7: The calibration of the remote controller.

Conclusion

Today we have made two versions of the balancing robot. The first one with only one front wheel, and the second with two front wheels. We found that the first version was not stable enough to drive on the tube. We have also succeeded in adapting the code to our tube-balancing context so it made the robot drive on the tube for a few seconds. From now on there is a lot of trial and error tuning the parameters, possibly also understanding and adjusting the code more.

The remote control has also been built. The calibration of the remote controller has been programmed but there is still some programming to do before it works. Remember that the remote control should be used to drive the car inside of the tube.

Plan for next session(s)

Adjust the code so that the balancing robot only uses the gyro readings and not the tacho counter (we have a hypothesis that the tacho counter is only necessary when the robot, in the LegWay, needs to balance on the floor). Tacho counter may not be needed since we want to make less subtle movements, in order to react on the tubes movements. The PID-parameters should also be adjusted.

We want to get the remote controller to communicate with the car inside the tube using Bluetooth. Hopefully the remote controller can be finished next time.

The steps should be prioritized as follows, so we start out simple: