Date: 7th/12th of March 2013
Participating group members Thursday: Thomas Winding and Kenneth Baagøe.
Participating group members Tuesday: Thomas Winding, Kenneth Baagøe and Morten Djernæs Bech.
Activity duration:
6 hours Thursday 7th of March 2013
3 hours Tuesday 12th of March 2013
Overall goal
The overall goal of this lesson is building and programming a Segway-inspired self-balancing NXT robot.
Overall plan
To achieve our goal we will use the information provided here:
Self-balancing robot with a light sensor
Goal
To build a self-balancing robot that will adjust its balance according to measurements from a light sensor.
Plan
We will build a robot inspired by Phillippe Hurbain [1] and run the program made by Brian Bagnall [2] on it. Furthermore we will try to adhere to the guidelines that Phillippe Hurbain propose and observe whether that helps on the operation of the robot.
Result
The robot tips over very easily, even when we tried in a dark room on a non-uniform surface as suggested by Phillippe Hurbain. There are two major influences on this: Phillippe Hurbain suggests starting the program when the robot is perfectly balanced. Attaining a perfect balance is hard to do when simply starting the program by hand, even pushing the enter button on the robot will bring it at least somewhat out of balance and thus skew the measurement that the robot balances by. Besides the aforementioned the program is also configured to Brian Bagnalls hardware and we suspect that there might be subtle differences compared to ours, which could cause problems in the balancing.
Changing the values of the parameters from a PC
Goal
Changing the values for the PID controller in the program mentioned above, from a PC via a GUI.
Plan
Drawing inspiration from the provided BTcontrolledCar and PCcarController programs, we will program a GUI that is able to take input from a user and supply these values to the PID controller.
Results
Using the GUI to provide new values for the program over a Bluetooth connection works fine, there are, however, some shortcomings in the program that we hoped to implement, but haven’t. One thing we might implement later is the ability to change the different values for the PID controller on the fly instead of having to restart the program on the robot every time a change is wanted.
Changing the values of the parameters from a PC revisited
Revisiting the shortcomings mentioned above, a program for the robot, which is able to change the kP, kI, kD and scale values on the fly has been made (BTbalance2.java). This operates over Bluetooth and works in tandem with PCcarBalance.java Standard values are the ones provided by Brian Bagnall. To ease calibration of the robot, a three second grace period was added after pressing the enter button which is signaled first with two beeps and lastly a beep sequence to signal the start of the balancing. Furthermore the offset, set by the calibration, is changeable by pressing the left button (decrease) and the right button (increase). However, when exiting the program via a press on the escape button, the robot writes out a large amount of exceptions, the cause of which we were unable to locate.
Running this program on the robot and trying different values for the PID controller, we were able to get the robot to balance for 10-20 seconds on a white surface in a room lighted with fluorescent light. One of the better runs is demonstrated in the video below (values used were: Offset: 542, kP: 53, kI: 2, kD: 36, scale: 18). The fluorescent light did cause some trouble in that the robot would cast a shadow which moved when the robots position changed in comparison to the lights. This meant that it would sometimes recieve a very different reading if the robot moved so that the shadow no longer was where the light sensor measured. We remedied this by running the robot in a dark room where we could sometimes achieve a balancing time of 30-40 seconds.
Self-balancing robot with gyro sensor
Goal
Balance the robot, with the same design used in the previous exercises, using a gyro sensor.
Plan
Follow the AnyWay NXT-G code and translate it to Java.
Result
After translating the NXT-G example to Java, the program unfortunately did not function properly as the robot would instantly move forward at full speed when started and thus tip over.
We will continue on this assignment on Thursday 14th of March 2013.
References
[1] http://www.philohome.com/nxtway/nxtway.htm
[2] http://variantpress.com/books/maximum-lego-nxt/