Loop timing crio vs. roborio.

[MrRoboSteve]

FWIW, I teach our programmers (C++) to never depend on the grand loop timing in the robot, always using timers to calculate time offsets. There's no stated SLA around the timing, and I have always been concerned that behavior on the field would vary from tethered operation in a meaningful way.

[wt200999]

The difference could be from quite a number of factors. The most obvious one would be the difference in the loop times. Another big factor is the difference in what is running in the background and how it is being scheduled.

You should expect jitter from using the "Wait Until Next ms Multiple", this is similar to the problem of using Thread.sleep() in Java. If you need more accurate timing you need to use a timed loop structure, which will also tell you if the loop runs too long and a couple of other useful things.

Along with the paper from 358 link, this paper from NI has some useful info on the wait functions in LabVIEW RT.

[Jared Russell]

I posted about an issue in the Java implementation here. The actual task was not using a hardware interrupt for timing, but rather Thread.sleep(). Is it possible that the 2015 LabVIEW code is doing something similarly non-optimal?

[Tom Line]

Originally Posted by Jared Russell

I posted about an issue in the Java implementation here. The actual task was not using a hardware interrupt for timing, but rather Thread.sleep(). Is it possible that the 2015 LabVIEW code is doing something similarly non-optimal?

By design. As someone else already stated, the metronome, or 'wait' in Labview means 'execute no FASTER' than your set time. It does not enforce timing, and if enough CPU is used elsewhere the loop times will vary. Our CPU usage this year was around 65%, and we could count on the wait loops to be very consistent.

If you require accurate timing, a timed-loop structure will give you sub-millisecon d accuracy at the price of substantially higher CPU utilization.

[ayeckley]

Originally Posted by Tom Line

Our CPU usage this year was around 65%, and we could count on the wait loops to be very consistent.

Ditto the experience here. We experienced less "jitter" (probably not really the correct application of the term, but you get the picture) this year than we historically did with the cRIO. Sorry, no metrics to support that.

[tr6scott]

Originally Posted by Tom Line

By design. As someone else already stated, the metronome, or 'wait' in Labview means 'execute no FASTER' than your set time.

Yet in all of the data the avg loop time is less than the set loop time. In the roborio 20ms loop time, there are loop times of 8,9 & 10ms.

This effectively, doubled the PID gains for these loops... Again we really did not see any issue with the elevator with stability.. and as MrRoboSteve pointed out it is probably a better solution to incorporate the delta-t at this high school level, just in case the field impacts the control.

We had no programmers with calc yet this year, so we used NXT lego line following example as the start of the conversation, and 3 weeks later, ended with the white paper on the SRX internal PID code. The elevator code ended up with a separate P gain for raising the elevator, and a lower P gain for lowering the elevator, along with the SRX "IZone" implemented. This gave a very quick reacting and stable control for the elevator system. The mechanical gear ratio went from 35:1 minicim at Waterford, to 20:1 CIM at Championships.

[Alan Anderson]

Originally Posted by tr6scott

Yet in all of the data the avg loop time is less than the set loop time. In the roborio 20ms loop time, there are loop times of 8,9 & 10ms.

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.

This effectively, doubled the PID gains for these loops...

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.

Again we really did not see any issue with the elevator with stability..

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.

[tr6scott]

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.

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.

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.