Hello. This is the first year we have attempted using gyros, PID, and while loops to navigate in autonomous. I think I have it right and the code does seem to work properly (I’m using a test bed as the robot is currently bagged) but I could use a second opinion to tell me if I’m doing anything wrong.
The routine is supposed to drive straight for a certain time, turn 60 degrees towards the low goal, drive straight for a certain time, and shoot the boulder. It uses a flat sequence structure with while loops in the frames that require iterative functions.
Resetting the gyro - Does this require some time or is it instantaneous? Where is the best place to reset this?
Reading gyro data - Does gyro data need to be read in each separate while loop?
Using wait.vi and loop iterations to keep time - I set the loop to iterate every 10 ms and to terminate when it reaches 500 iterations. I assume this will be 5 seconds. Is there any reason this would not be 5 seconds? Is there a better way to do this?
While I don’t have answers to all of your questions I would like to point out that the gyro reports angles in the range of 0-360 degrees. You’ll probably want to normalize any readings greater than 180 degrees to their negative equivalents in order to get the PID vi in drive straight to work properly. Simply compare the reported gyro angle to 180 degrees. If greater than 180 degrees then subtract 360 and voila you get reported angles from -179.999 to +180. That way a reported angle of 350 degrees gets converted to -10 degrees which I believe the PID vi can make sense of.
Hope this helps.
Nope. It will continue past 360 degrees on the second time around as the documentation you provided indicates. (Edit, OK so I did misspeak regarding the total range as it will go past 360 going around again) I’m focusing on what happens when the PID setpoint is 0.0 but the gyro sees a leftward turn and reports a process variable toward 360 degrees which I think will cause the PID vi to get confused.
I don’t think I’ve seen the gyro vi report angles less than zero.
The angles published to the dashboard from the Gyro Get Angle vi did return negative values and the motor did seem to compensate correctly for these. Is it possible that this -180 to +180 feature is built into the gyro Get Angle vi?
Well if that’s the case then I’ve learned something new. I just never noticed the negative values before. However I’ve just seen some other LabView code that supports what you are saying.
Much humbled. Sorry for the mis-information.
the gyro sees a leftward turn and reports a process variable toward 360 degrees … I don’t think I’ve seen the gyro vi report angles less than zero.
Given the rationale stated in the WPILib documentation, it’s hard to imagine the gyro would report anything other than angles less than zero when that occurs.
The post and thread I linked above shows how to turn any angle into +/-180 degrees.
If you compute the angle error ( = target-gyro ) and feed that error into the computation, it will give you the setpoint you should use to go the shortest angle to get to your target (or just see below).
I think it is built into WPILib PID. See “set continuous”.
Since no one has yet directly answered your questions I’m going to go out on a limb here and attempt to answer.
You could place the reset in the first frame of the sequence but I think it’s OK where you have it. Not sure though if the reset is instantaneous but from what I’ve seen it only takes some fraction of a second.
Yes you need to read the gyro in each while loop. When a while loop is active the while loops in the other frames in the sequence structure are not executing.
This has been a common technique shown in examples from previous years. I think your assumption of a 5 second loop time is correct. I see no reason to change it.
Sorry if we hijacked your thread. Hope this helps.
