Thread scheduler for PID period control ?

[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?

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.

[Greg McKaskle]

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

[wireties]

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

[Joe Johnson]

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.

[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.