Thread scheduler for PID period control ?
 

We are trying to optimize our custom PID loop and appear to be getting conflicting data that I am hoping someone can clarify.

1) From numerous CD threads, I believe that the standard teleopPeriodic time is initiated from the drivers station at approximately a 20ms rate. However, at least two threads mention a 50ms periodic rate (older IFI rate?).
2) I have seen several threads which recommend using a separate thread based on the OS scheduler for tighter tolerance. Team 358 "Timing is Everything" white paper is an excellent reference. 10ms seems like a common period for PID.
3) The PID_control class does use the scheduler to create its own thread. I thought I saw on CD the default period was 20ms, but the Java Docs say it is 50ms.

So now here is our confusion.
4) We set up a timed PID thread with period 10ms. We set up a delta time measurement in both the teleop periodic and timed PID loops and plotted the delta times. The timed loop was 20ms +/- 4ms and the periodic was closer to 50ms +20/-10ms. Setting the period to 20ms gave about the same response.
This was done using Java on the older 8 slot cRIO on our test chassis. We do not yet have access to the production 4 slot cRIO. I can believe the old cRIO cant do the 10ms period but that does not explain the 50ms for the drivers station. I have not hooked up a scope to a DSC pin to confirm that the time reported by the OS is accurate.

The timing is clearly faster and more consistent with the timed loop, but I hate unexplained behaviors.

Does anyone know if the periods on the older cRIO were different and if the driver station software adapts? Is the delta time reported by the OS accurate? What period are people using for PID loops?

Re: Thread scheduler for PID period control ?
 

The TeleOp period is 20ms (50Hz).

The default period for Java PID thread is 50ms (or at least it was in 2013).

Excerpt from 2013 PIDcontroller.java:

Re: Thread scheduler for PID period control ?
 

Could you give some additional detail on how you set up the delta time measurement?

For example, did you do it like this:

or like this:

or something else?

Re: Thread scheduler for PID period control ?
 

In addition, what method did you use to get the time?



What computer did you run the DS on?

Re: Thread scheduler for PID period control ?
 

We did it like this:

Re: Thread scheduler for PID period control ?
 

It was a windows 7 lenovo - not sure the exact model but not more than two years old and definitely not a netbook. We did this tethered, not on WiFi.

Re: Thread scheduler for PID period control ?
 

I just ran the following code:

And got the following output:

How does your test differ?

Re: Thread scheduler for PID period control ?
 

I took the liberty of plotting it. Attached.

Re: Thread scheduler for PID period control ?
 

That is what I expected, which is why I was confused. I should get the 4 slot cRIO today and will retry. I know the older 8 slot was slower, but it seems strange that they would change the driver station behavior to update less often.

Re: Thread scheduler for PID period control ?
 

My test was run on an 8-slot. The 8-slot has less ram, but the same processor. In this test, it is not slower.

Re: Thread scheduler for PID period control ?
 

Thanks for the feedback, i will have them re-run the test. BTW: what period do you use for your PID loops?

Re: Thread scheduler for PID period control ?
 

The major difference is we are reading an I2C 9DOF IMU model GY85. Works great, but maybe the I2C is slowing things down. I did a quick estimate and thought the time would be about 1 to 2ms, but maybe there is more overhead than I guessed.

I guess we just need to try the measurements again.

Re: Thread scheduler for PID period control ?
 

Just to reiterate. The 8-slot has less RAM and is a model variation of the same FreeScale processor, meaning it has a less cache. For most situations, it is the same speed.

Greg McKaskle

Re: Thread scheduler for PID period control ?
 

When you create a task and put it in a loop with a delay, the delay is subject to the resolution of the system clock (which is 10ms). So a request to delay for 20ms would have considerable variation. The system is waiting for two clock ticks which could happen in a little over 10ms or a little under 30ms.

The PID class does not use delays, instead it uses the timer OS libraries (last I looked). These fire in the context of the tick timer interrupt routine and are more periodic. The first PID timer callback may run at a variable time after enabling but it will run very periodically afterwards. Does that make sense?

The operating system does have a higher resolution timer (the auxiliary timer) for custom purposes. It is not used by the base OS. And perhaps NI built a service on top of the the auxiliary timer. Plus there is normally a third timer only used for timestamps. But the base timers work as described above.

The periodicity of the messages from the DS is dependent on many things. Ethernet is not strictly deterministic. The teleop loops start after a semaphore is given once the code on the cRIO processes an incoming message and the data is available.

HTH

Re: Thread scheduler for PID period control ?
 

I am not sure why but the autogenerated code from RobotBuilder does not include the feed forward gain, Kf, and the loop period, so they default to 0 and 50ms.

Here is a code snippet:
public Launch() {
super("Launch", Kp, Ki, Kd, Kf, 0.01);

Note that we had 0.005 as the period at first and it was acting squirrely. I think we were having the PID loop take too much of the CPU time. When we backed off to 10ms, life was good.

YMMV.

Joe J.

Re: Thread scheduler for PID period control ?
 

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.

Re: Thread scheduler for PID period control ?
 

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.

Re: Thread scheduler for PID period control ?
 

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

Re: Thread scheduler for PID period control ?
 

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.

Re: Thread scheduler for PID period control ?
 

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

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

Re: Thread scheduler for PID period control ?
 

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

Re: Thread scheduler for PID period control ?
 

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.

Re: Thread scheduler for PID period control ?
 

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!

Re: Thread scheduler for PID period control ?
 

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.