@@ -107,7 +107,7 @@ In order to optimize our experimentation with various PID values for the program
### Choosing parameters on the fly
---
#### Making the programs
To make a GUI that runs on a computer and communicates variable values with the program running on the NTX we retrieved the ***TrackerController.java*** and the ***Tracker.java*** from [lesson 2](TODO ref) which was used respectively for controlling the PID values used on the NTX and receiving and using these values in a PID controller for the ultrasonic sensor. The ***TrackerController.java*** hence became the inspiration for our PC GUI and the ***Tracker.java*** for the NXT program responsible for receiving the sent values.
To make a GUI that runs on a computer and communicates variable values with the program running on the NTX we retrieved the ***TrackerController.java*** and the ***Tracker.java*** from [lesson 2](http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson2.dir/Lesson.html) which was used respectively for controlling the PID values used on the NTX and receiving and using these values in a PID controller for the ultrasonic sensor. The ***TrackerController.java*** hence became the inspiration for our PC GUI and the ***Tracker.java*** for the NXT program responsible for receiving the sent values.
Later on we noticed that two java programs to use as inspiration were actually provided in the lesson plan, but at this point we had already written the program ourselves and therefore chose to ignore the supplied programs as we would rather continue with our experiments.
...
...
@@ -231,7 +231,7 @@ Afterwards, we modified ***GyroTest*** to let both motors run while the program
There seems to be no significant difference between the robot when whearing weels and when not - there is only a difference of 0.1 between the average readings in the two cases. We concluded that the average drift was negligible in both cases.
It is interesting that the average reading this time (in both cases) was closer to 597 than to 598, as opposed to what we concluded from the preceding run. However, we were not necessarily wrong in our observation as 598 could simply result from that specific testing situation being an extreme with respect to the average.
Based on code presented in [Ref for lesson plan], we tried implementing integration to calculate the angle of the gyro based on the sample interval and the motion readings of the gyro. The result was, however, extremely inaccurate, and would for some reason slowly slide in one direction, even when the gyro was motionless. We assumed this to be a result of the constant small speed readings made by the gyro even when still, but these should work in both directions as the offset remains the same despite fluctuations to either side, so the drifting angle is a mystery to us.
Based on code presented in [the lesson plan](http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson5.dir/Lesson.html), we tried implementing integration to calculate the angle of the gyro based on the sample interval and the motion readings of the gyro. The result was, however, extremely inaccurate, and would for some reason slowly slide in one direction, even when the gyro was motionless. We assumed this to be a result of the constant small speed readings made by the gyro even when still, but these should work in both directions as the offset remains the same despite fluctuations to either side, so the drifting angle is a mystery to us.
We would have attempted to amend the inaccurate angle calculation and then use this as a means of creating a balancing robot using the gyro sensor, but at this point we had simply spent too much time on the exercises and were forced to cut our gyro implementation short and leave it at this. Had we had the time to continue, our ideas regarding the implementation of a balancing robot included combining the different sensors to have a form of "second opinion" to take into account when responding to the gyro sensor's readings.
