WPI PIDController doesn't account for varying dT?

[FRC4ME]

I was looking through WPI's PIDController code and noticed that they do not incorporate dT into the calculations anywhere. For example, the calculate() method contains the line:

m_totalError += m_error;

Shouldn't it be like this?

m_totalError += m_error * m_period;

The way it is now, changing the period of the PID loop would require resetting of the I and D constants. Multiplying the integral by the period and dividing the derivative by the period would remove this inconvenience.

[yoyodyne]

I'm no PID expert, but the output of the PID (at least the P part) has no bearing on the dT. I think that you want to set dT long enough so that the physical system will have started to respond to the last setting and more or less leave it alone and then adjust the gains. We typically test this by running a motor at control setting X and then jump to setting Y and plot the output of the sensor providing feedback. We then set dT to the time it takes the system to reach about 60% response. There is probably a better way to determine the right value for dT but it seems to allow us to stay stable and respond reasonably fast.

Greg

[Tom Bottiglieri]

Originally Posted by FRC4ME

I was looking through WPI's PIDController code and noticed that they do not incorporate dT into the calculations anywhere. For example, the calculate() method contains the line:

m_totalError += m_error;

Shouldn't it be like this?

m_totalError += m_error * m_period;

The way it is now, changing the period of the PID loop would require resetting of the I and D constants. Multiplying the integral by the period and dividing the derivative by the period would remove this inconvenience.

How often do you change the period?

[Tom Bottiglieri]

Originally Posted by FRC4ME

Shouldn't it be like this?

You could always change this and recompile it for yourself.

Or better yet, you could change this and submit it to the sourceforge project. If there's not a specific reason they left this functionality out, I'm sure it will get accepted.

[FRC4ME]

Originally Posted by TomBot

You could always change this and recompile it for yourself.

Or better yet, you could change this and submit it to the sourceforge project. If there's not a specific reason they left this functionality out, I'm sure it will get accepted.

We have changed it for our team's use, and I feel like changing the library would be a bad idea as it would break the PID loops that teams have already tuned.

I understand that it isn't a big deal and there aren't many reason to change the period. I was just curious to see if, as you say, there is a specific reason WPI left this out that I'm not seeing.

Sorry if I sounded rude in any way by mentioning this.

[AustinSchuh]

I believe that the reason that WPI left the dT part out is that since VxWorks is a real time OS, it's perfectly reasonable to assume that dT won't change very much.

A good exercise is to measure dT and see how much it actually varies.

If you were to submit a patch, you could scale the constants up and down internal to the loop by 50.0. KI should be 50 times larger, and KD should be 50 times smaller (provided I'm doing my math right, and assuming 50 Hz). That would preserve backwards compatibility.

[Jared Russell]

It is a matter of preference. If you update your 50Hz PID to be 100Hz, do you want to scale your Ki and Kd, or do you want the API to do it for you?