@@ -123,15 +123,16 @@ We ended up writing (or rather: mainly copy-pasting) four programs; ***PICcontro
...
@@ -123,15 +123,16 @@ We ended up writing (or rather: mainly copy-pasting) four programs; ***PICcontro
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 ***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 ***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 ***PCconnection.java*** [12] is inspired from the ***Tracker.java*** and is therefore responsible for retrieving the parameters sent from the pc through the datastream, as well as for forwarding them to a running ***Sejway.java*** instance.
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.
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*** [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.
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. For this reason, the two classes previously described extend 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 using a by-hand-calibrated setpoint. We quickly realized that this method didn't enhance our understanding of the different variables and neither of 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).
To systematically observe which values of P, I and D work better for our robot we needed to have a best possible starting point (i.e. the robot being in equilibrium), wherefore we set out to find a good setpoint.
To systematically observe which values of P, I and D worked better for our robot we needed to have a best possible starting point (i.e. the robot being in equilibrium), and we therefore began by trying to find a good setpoint.
##### Finding a good setpoint
##### Finding a good setpoint
To find the best possible setpoint we decided to use the PID values of Bagnall's initial program (p = 28, i = 4, d = 33) and then trying to narrow our way into the best possible value by starting with a (from our prior experience) low- and high value. This resulted in the observations presented in table 1.
To find the best possible setpoint we decided to use the PID values of Bagnall's initial program (p = 28, i = 4, d = 33) and then trying to narrow our way into the best possible value by starting with a (from our prior experience) low- and high value. This resulted in the observations presented in table 1.
