Quote:
Originally Posted by autox_vette
With the gyro initialization in the begin VI, the PID would become unstable around 20% of the time. With the gyro initialization disabled, the PID would never become unstable. The only resource that I can see in common between the two would be processing. Given the problems that were seen in the Einstein follow up from 2012 with gyro initialization hanging and using too much CPU, it was decided that it could be a similar issue. Note, this was only the gyro initialization code in the begin VI. The gyro was only read when a button was pressed (which was never occurring because we were in autonomous).
|
It might be helpful if you posted your code before the change and described exactly what you removed.
118's problem was due to an infinite loop in their own code. It's unlikely that you wrote your gyro initialization code the same way. My gyro initialization consists of a gyro open in Begin and a gyro reset at the beginning of autonomous. How much more initialization are you doing?
I would use the
Driver Station Log Viewer to compare the operating environment when with the old code when it worked and when it didn't as well as after your change. It will show you CPU utilization as well as network statistics. It will also show errors reported by the code.
Are you using the LabVIEW PID VIs or did you write your own? The LabVIEW PID VIs can be configured to assume either a constant call rate or too measure the time since last call, in order to correct for inconsistent timing.
You may find Team 358's
Timing is Everything whitepaper helpful for comparing different wait methods.
You may find that you can increase the D term to improve stability with only slight decrease in spinup time. Alternately, you may be able to use an alternate control method (such as
Bang-Bang Control which has the fastest possible spinup, without stability problems as long as your shooter wheel has enough inertia.