@@ -114,7 +114,7 @@ Later on we noticed that two java programs to use as inspiration were actually p
We ended up writing (basically through capy-paste though) four programs; ***PICcontroller.java***, ***PCconnection.java***, ***Sejway.java*** and ***NXTSegwayRunner.java***.
The ***PIDcontroller.java*** is the PC GUI to enable PC control of variables used on the NXT. This program sets up a GUI with six fields and two buttons. The first two fields contains name and bluetooth device ID, which is used when clicking the 'connect'-button, as this action starts NXT communication with the given device ID and sets up a dataOutPutStream [TODO ref].
The last four fields are input fields for P, I, D and SP respectively, where SP is the calibration setpoint that the NXT program will aim for - i.e. it's offset. The last variable was added to the PC controller, as we wanted to avoid box-calibration which we suspected didn't entirely remove the button-push error of the calibration.
The last four fields are input fields for *P*, *I*, *D*, and *SP* respectively, where SP is the calibration setpoint that the NXT program will aim for - i.e. its offset. The last variable was added to the PC controller, as we wanted to avoid box-calibration which we suspected didn't entirely remove the button-push error of the calibration.
The ***PCconnection.java*** is inspired from the ***Tracker.java*** and therefore is responsible for retrieving the parameters send from the pc through the datastream and forwarding them to a running ***Sejway.java*** instance.
...
...
@@ -161,7 +161,7 @@ We tried to change the i-value - which was 4 initialy
7: - maybe better
8: poorer
We decided to test the effect of different values for the parameters using a technique inspired by grid search: We selected a range of values to try out for each parameter (*setpoint*, *p*, *i*, and *d*) and then varied one parameter while keeping the others fixed. We began by testing different values with rather large intervals in between, including extreme values (values far away) on either side of the value provided in the code used as inspiration. According to which values gave the best results we then made the search around these values more fine-grained.
We decided to test the effect of different values for the parameters using a technique inspired by grid search: We selected a range of values to try out for each parameter (*setpoint*, *P*, *I*, and *D*) and then varied one parameter while keeping the others fixed. We began by testing different values with rather large intervals in between, including extreme values (values far away) on either side of the value provided in the code used as inspiration. According to which values gave the best results we then made the search around these values more fine-grained.
*Setpoint:*
Noting that the value measured by the robot initially was around 580, we started with a value of 500 to see the effect. We then tried a value of 750 (simply to try something somewhat in the middle between 500 and the highest possible value of 1023). Seeing how poorly both of these affected the robot's performance, we then tried a value of 600 which made the robot perform a lot better. After this, we started narrowing in between 600 and 550, ending at a value of 577. After a while of testing, we noticed that the robot was casting a shade depending on the direction that the light was coming from. This has most likely affected the light readings, but we have not taken this further into account except for th awareness that the accuracy of our measurements need to be taken with a grain of salt. Repeated experiments could alleviate the problem.
...
...
@@ -236,7 +236,7 @@ Further exploration might have included testing the color sensor in different co
---
The offset was measured by placing the robot against a wall, and observing the value over a period of time. The reading varying between 597 and 598, with 598 occuring the most. The offset for angular velosity is therefore 600 - 598 = 2. ***(Nicolai: Is this right? Ida: Tænker du på, om det skal være negativt eller ej? Jeg vil tro, at det skal være positivt. Har rettet, men vi kan sagtens rette tilbage.)***
The offset was measured by placing the robot against a wall, and observing the value over a period of time. The reading varying between 597 and 598, with 598 occuring the most. Our sensor's offset for angular velosity is therefore 598.
To test the drift, we began by starting ***GyroTest.java*** and letting it run for 10 minutes to check if the sensor developed heat which could then maybe result in a drift of the reading value. This didn't seem to be the case - in the end, the sensor readings were still shifting between 597 and 598.
...
...
@@ -249,7 +249,7 @@ Afterwards, we modified ***GyroTest*** to let both motors run while the program
*Table 2: Data on readings from the gyro sensor*
There seems to be no significant difference between the robot with and without wheels - 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.
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, this is only a marginal change and if time permitted we shoul probably run several long tests to obtain an overall average and use that.
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.
