@@ -122,14 +122,14 @@ Later on we noticed that two java programs to use as inspiration were actually p
...
@@ -122,14 +122,14 @@ 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***.
We ended up writing (basically through capy-paste though) four programs; ***PICcontroller.java***, ***PCconnection.java***, ***Sejway.java*** and ***NXTSegwayRunner.java***.
The ***PIDcontroller.java*** [9] 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.
The ***PIDcontroller.java*** [11] 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.
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 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*** [10] 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.
The ***PCconnection.java*** [12] 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.
The ***Sejway.java*** [11] program is a modification of Bagnall's Sejway program, where the PID variables are set through setter-methods called by outsiders - in our case the PCconnection instance. This program thereby controls the actual balancing abilities of the robot.
The ***Sejway.java*** [13] program is a modification of Bagnall's Sejway program, where the PID variables are set through setter-methods called by outsiders - in our case the PCconnection instance. This program thereby controls the actual balancing abilities of the robot.
As both these programs can't run simultanously on the NXT, we also made the ***NXTSegwayRunner.java*** [12] program which simply creates a Sejway instance, starts it and creates and starts a PCconnection instance with a reference to the Sejway instance. This also means that the upper two classes extends Thread to enable simultaneous execution.
As both these programs can't run simultanously on the NXT, we also made the ***NXTSegwayRunner.java*** [14] program which simply creates a Sejway instance, starts it and creates and starts a PCconnection instance with a reference to the Sejway instance. This also means that the upper two classes extends Thread to enable simultaneous execution.
#### Search for good PID parameters
#### Search for good PID parameters
After implementing the programs enabling easy PID parameter search, we started playing around with different values for P, I and D by using a by-hand-calibrated setpoint. We quickly realized that this method didn't enhance our understanding of the different variables and neither the robot's ability to self-balance. We therefore decided to use a more systematic way of testing and deciding on variable values than this approach based on gut feeling and experience (the latter of which we had very little).
After implementing the programs enabling easy PID parameter search, we started playing around with different values for P, I and D by using a by-hand-calibrated setpoint. We quickly realized that this method didn't enhance our understanding of the different variables and neither the robot's ability to self-balance. We therefore decided to use a more systematic way of testing and deciding on variable values than this approach based on gut feeling and experience (the latter of which we had very little).
...
@@ -232,7 +232,7 @@ Gyro sensors does not only vary in offset value, they also vary in measured valu
...
@@ -232,7 +232,7 @@ Gyro sensors does not only vary in offset value, they also vary in measured valu
To test the drift of our sensor, 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.
To test the drift of our sensor, 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.
Afterwards, we modified ***GyroTest*** [13] to let both motors run while the program was running, in order to see the effect of the resulting voltage drop. We also added a data logger to the program to gather information for later observations. We used this to calculate the average reading and the average drift, presented in table 2 below. Two cases were investigated: In the first case, the robot was un-modified. In the second case, the robot's wheels were taken off to. We took off the wheels in the hopes that this would lessen the vibrations of the robot resulting in a more stable position.
Afterwards, we modified ***GyroTest*** [15] to let both motors run while the program was running, in order to see the effect of the resulting voltage drop. We also added a data logger to the program to gather information for later observations. We used this to calculate the average reading and the average drift, presented in table 2 below. Two cases were investigated: In the first case, the robot was un-modified. In the second case, the robot's wheels were taken off to. We took off the wheels in the hopes that this would lessen the vibrations of the robot resulting in a more stable position.
