Quote:
Originally Posted by Alan Anderson
Are we looking at the same files? The "20 ms" roboRIO data shows many records with times in the high 20s and 30s, and some greater than 40 ms. I wasn't able to get them all to match up to show a clear smoking gun of simple timing jitter, and I'd still like to see how long the loop contents actually took to run.
|
Look at the average and standard deviation data posted. All of the three files have an average that is less than the loop time programmed in the wait for next multiple.
Quote:
Originally Posted by Alan Anderson
The P term is unaffected by loop time. The I term would indeed be overrepresented with a shorter than expected loop time, but the D term would have a reduced effect.
|
Had to look this up, but you are correct, there is no delta-t term in the P.
Quote:
Originally Posted by Alan Anderson
It appears that you were using the built-in SRX closed loop control, so any inconsistencies in your robot code's timing should be irrelevant.
|
No, we did not even have a SRX on the bot. The point was we started the conversation and code with simple NXT solution and it finished with reviewing the SRX whitepaper on the internal PID code CTE published. We implemented the SRX "IZone" feature in Labview, and drove a talon SR via PWM. This whole paragraph, was probably off topic to the conversation at hand, but sometimes I work that way.
So the conversation at hand, is based on the averages for the loop time, and standard deviation from our 2014 code on a cRio, and our 2014 code on the roborio, in the same 50ms loop.
The cRio data:
2014 Avg = 49.9796 with STD = 0.21929
The roboRIO data:
2014 Avg = 49.95124 with STD = 0.7159
The deviation of the loop by the roboRio is a factor of 3.2646 less repetitive than the same code on the cRio.