PID derivative value oddity

[Zatnikitelman]

I'm working on tuning an autopilot for a launcher in Orbiter, and I'm breaking out the data into a table to see what effects the variable changes are having. One thing I noticed though when the vehicle approaches the setpoint, the error rate remains the same. Here's the data:

simt|current|error|rate
25.765484|89.988951|0.011049|-1.022837
25.772039|89.998118|0.001882|-1.39849
25.779284|90.006247|-0.006247|-1.121982
25.785579|90.015207|-0.015207|-1.423363

And here's the code for generating the rate from the error

rate = ((error - olderror) / (simt - oldtime));

As I said, I would expect the rate to change from negative to positive when the controller crosses the 0 error mark ("current" is the current heading of the vehicle, and it's set to 90 so 0 error is in between those middle two timesteps). Am I calculating the rate incorrectly? Or is this actually right?

Thanks!

 

[martins]

Your definition of "error" is a bit unconventional. Usually an error is defined as >= 0, e.g. the absolute value or the square of the difference between current and target. In your case it's just the difference between current and target, which means that your "rate" is just the angular velocity (the "target" values drop out in the difference). This won't change sign when you move across the target direction.

 

[Urwumpe]

According to the data, the rate seems to be approximately right - of course, its a linear approximation with a lot of jitter because of varying time steps.

The "rate of change" tells you the slope of the plot. So, if your error is decreasing into the negative, the rate of change will be negative, even if your error passes zero.

For having a zero rate of change, the error would need to be constant or change from decreasing to increasing error for example.

As small reminder:

---------- Post added at 18:11 ---------- Previous post was at 18:04 ----------

Your definition of "error" is a bit unconventional. Usually an error is defined as >= 0, e.g. the absolute value or the square of the difference between current and target. In your case it's just the difference between current and target, which means that your "rate" is just the angular velocity (the "target" values drop out in the difference). This won't change sign when you move across the target direction.

Its actually the correct definition of an error value for control loops. It is not a quantification how good the model fits to the real data, but how the current flight state differs to the expected flight state.

In the PID sense for example:

P = difference in pitch rate
I = accumulated pitch rate error ~ difference between target pitch and current pitch angle
D = rate of change in the pitch error ~ difference between planned pitch axis acceleration and measured pitch axis acceleration.

(X ~ Y means in this text: X = what it formally means. Y = what works good enough for committee work.)

 

[Zatnikitelman]

But how would that work for a directionally-dependent system like setting thrusters to hold a heading? Let's say my target is 90 and I'm at 89 which makes my error 1, I should thrust right. But if it overshoots and gets to 91, my error as absolute value would still be 1, so how would I know to thrust left? Would I need a second conditional, something like If (current-error < 0){left_thrusters}?

 

[martins]

To express it in terms of a damped harmonic oscillator (which I guess is conceptually similar to a PID problem):

[math]
m \ddot{x} = -\alpha x - \beta \dot{x}
[/math]

where [math] m \ddot{x}[/math] is the force you want to apply to correct the error, [math]x[/math] is the directional error, and [math]\dot{x}[/math] is the angular velocity (your rate). alpha and beta are design parameters that you can optimise for critical damping.

 

[Urwumpe]

To express it in terms of a damped harmonic oscillator (which I guess is conceptually similar to a PID problem):

It is actually roughly the mathematical foundation for all control problems.

 

[Thorsten]

It is actually roughly the mathematical foundation for all control problems.

It does make sense to visualize them as potentials which need to be minimized, but the harmonic oscillator really only captures the most simple ones (the damped harmonic oscillator is the equivalent of a PD controller).

There's lots of very useful stuff beyond PIDs (chained controllers, anharmonic potentials, fuzzy control,...).