Thread scheduler for PID period control ?

[tinybob20]

Hi,

we tried using the getFPGATimestamp() instead of the basic .get(), and we were able to get values around 11 - 16 ms for our timed PID loop with the scheduler set to 10ms.

in teleopPeriodic we got values around 21 - 23 ms.

[gpetilli]

Originally Posted by Joe Ross

I just ran the following code:

    double prevTime = 0;
    public void teleopPeriodic() {
        double time = Timer.getFPGATimestamp();
        System.out.println(time-prevTime);
        prevTime=time;
    }

How does your test differ?

Joe,

Post #16 above is from the student we had redo the test. The differences between our original test and this one are switching from an OS timer to the FPGA timer like your code and the new test has the full PID drive code. The ~50ms DS measurement that originally had me questioning what was going on is now ~20ms as expected.
The timed loop measurement is also faster (11->16ms instead of >20ms) , but not the 10ms that we asked for. At this point we intend to set the timed PID loop to 15ms instead of 10ms to hopefully stay within the computation limit of the cRIO. Thanks for your help and example code for more accurate measurements.

[Greg McKaskle]

The timer doesn't control the rate of the loop. It merely measures the time from one execution to the next. If you have code within teleop that takes more than 20ms to run, you will skip DS updates. I see this quite often on team DS logs, even teams from Einstein. It would be odd that the periodic is not a multiple of 20ms. And unless the network and/or DS are stressed out, I'd expect jitter numbers like Joe showed above.

I'm not sure how Java PID does its scheduling, and when teams spawn another thread and set its rate, I'm not sure what they are using to schedule.

Team 358's article is about timing using LabVIEW. LabVIEW has two different schedulers. One has ms level resolution and is used for general VI execution. It uses a pool of threads at various priorities, and the LV wait and wait ms functions and a plain while loop will operate in this scheduler. The TimedLoop uses its own scheduler that runs at an elevated priority and has advanced scheduling options -- quite advanced. It can schedule at sub millisecond periods and implements a variety of policies. Only Timed structure code runs in this scheduler.

The timed loop is also instrumented so that it is easy to determine start and stop times, missed deadlines, adjust priorities and other things. I'd highly recommend that you instrument your PID not only to measure its actual period, but also its execution time. You could also do this with a profiler if you have one. This will let you know the cost of the operation you are scheduling.

Greg McKaskle

[gpetilli]

Originally Posted by Greg McKaskle

The timer doesn't control the rate of the loop. It merely measures the time from one execution to the next. If you have code within teleop that takes more than 20ms to run, you will skip DS updates. I see this quite often on team DS logs, even teams from Einstein. It would be odd that the periodic is not a multiple of 20ms. And unless the network and/or DS are stressed out, I'd expect jitter numbers like Joe showed above.

I'm not sure how Java PID does its scheduling, and when teams spawn another thread and set its rate, I'm not sure what they are using to schedule.

Team 358's article is about timing using LabVIEW. LabVIEW has two different schedulers. One has ms level resolution and is used for general VI execution. It uses a pool of threads at various priorities, and the LV wait and wait ms functions and a plain while loop will operate in this scheduler. The TimedLoop uses its own scheduler that runs at an elevated priority and has advanced scheduling options -- quite advanced. It can schedule at sub millisecond periods and implements a variety of policies. Only Timed structure code runs in this scheduler.

The timed loop is also instrumented so that it is easy to determine start and stop times, missed deadlines, adjust priorities and other things. I'd highly recommend that you instrument your PID not only to measure its actual period, but also its execution time. You could also do this with a profiler if you have one. This will let you know the cost of the operation you are scheduling.

Greg McKaskle

Yes, we understand that the timer is a free-running stop watch that we are using to instrument our loops. This is why in the OP we were concerned that the teleopPeriodic was reporting 50ms on a program that did nothing but report the time while running tethered. Switching to the FPGA timer now correctly reports a 20ms teleopPeriodic rate.

What we are trying to do is create another thread outside of teleopPeriodic for doing the PID calculations at a faster, more consistent rate. We believe we have accomplished this in JAVA. We were hoping to achieve a 10ms period but appear to be processor limited to 15ms. This seems like a long time given other teams are talking about 5ms loops (not sure if they measured actual loop times). We do have some calculations in our loop, but I would not have expected it to limit the period by so much. We are looking into the bottleneck but time on the robot is limited with bag & tag in a few days. Worst case, the performance with 15ms seems fine for competition.

[Ether]

Originally Posted by gpetilli

What we are trying to do is create another thread outside of teleopPeriodic for doing the PID calculations at a faster, more consistent rate.

Just a heads-up in case you have not yet seen this post:

http://www.chiefdelphi.com/forums/sh....php?p=1342439

[Greg McKaskle]

What is your CPU usage when doing the 15ms PID and the rest of your robot code? It is on the charts tab.

If you make it easy to change the period of the PID, you can decrease it and watch the CPU. This will also help understand whether the PID loop is waiting on I/O or CPU bound. Again, it may be useful to know the time spent within the PID routine, so if you add your getFPGA timing to the top and bottom of the function and display that delta as well.

Greg McKaskle

[gpetilli]

Originally Posted by Greg McKaskle

What is your CPU usage when doing the 15ms PID and the rest of your robot code? It is on the charts tab.

If you make it easy to change the period of the PID, you can decrease it and watch the CPU. This will also help understand whether the PID loop is waiting on I/O or CPU bound. Again, it may be useful to know the time spent within the PID routine, so if you add your getFPGA timing to the top and bottom of the function and display that delta as well.

Greg McKaskle

Agreed. We have a variable dt that sets the period for the timed loop as well as changes the PID values. We just need time on the robot to finish our tuning.

[TravSatEE]

I'd like the OP or any others that have done PID loop timing changes to share what inputs/outputs they are using. What do these custom PID loops do on the robot (drive, interact with game/field items)? I am curious as to what needs a custom timing rate, as I haven't done anything myself that needed this for a PID controller. What was the behavior that led you to believe you needed a faster timing rate? If you post your code repositories publicly, please share the URL so I can try to follow along with what you did. One of the posts mention a change of "PID values" (I assume the coefficients), why did you do this? Thanks!

[gpetilli]

Originally Posted by TravSatEE

I'd like the OP or any others that have done PID loop timing changes to share what inputs/outputs they are using. What do these custom PID loops do on the robot (drive, interact with game/field items)? I am curious as to what needs a custom timing rate, as I haven't done anything myself that needed this for a PID controller. What was the behavior that led you to believe you needed a faster timing rate? If you post your code repositories publicly, please share the URL so I can try to follow along with what you did. One of the posts mention a change of "PID values" (I assume the coefficients), why did you do this? Thanks!

We are controlling a Killough style holonomic drive (which depends on wheel "slippage") by using two orthogonal instrumented follower wheels (no encoders on gearbox) plus a 9DOF IMU sensor ($16 GY-85). For the X&Y translation velocity PD we use the velocity from followers plus the accellerometer on the IMU. For rotation velocity PI we use the gyro and compass on the IMU.

We found that the 20ms "periodic" loop rate varied too much for repeatable control - it was difficult to tune the overshoot vs. accuracy since we are controlling velocity but observing the integrated distance. We evaluated timed loops and found them to be significantly more consistent. The standard PID loop uses timed loops but defaults to 50ms, which is way too long for good control. There was a visible difference in the overshoot going from a timed loop of 20ms to 10ms, however measurements showed we were really only achieving 14ms. Our competition bot has the loop set for 15ms, is extremely responsive and exhibits very little overshoot.