Feaature Request: Limit Wind-up

[jwatte]

I am driving motors with some amount of friction, which means that to get to the desired velocity, a bit of I in the PID would be ideal.
However, I also see the problem that, after I command the controllers to stop, they roll backwards a little bit because of the wind-up in the I controller.
My current work-around is to increase the P and increase D a bit to compensate, but that feels sub-optimal.

Is there some way to either limit the maximum amount of wind-up to something smaller than the present limit, or some way to get the wind-up to dissipate itself fairly quickly (over half a second or so, perhaps through a leaky bucket?)

[Basicmicro Support]

Currently there is no option to adjusted the integral maximum in velocity control. The integral maximum is back calculated based on the PWM duty cycle. If the new integral would cause the PWM to saturate(eg go over 100%), then the previous integral is used instead.

Also the integral is leaky. If the error is 0, the integral windup will disipate(even in worse case conditions) in about 8 cycles(each cycle is 1/300ths of a second).

For velocity control, I recommend only using P and I. If you are using D you may have either your P or I set too high. What values have you manually tuned? Have you tried using the autotuner? If so what values does it give?

[jwatte]

Also the integral is leaky

Oh, that's great! I seem to recall asking about this a few years ago, and at the time, the wind-up was described as a counter with a fixed maximum value. I personally really like leaky integrators!

I can't use auto-tune, because this is on a smallish rover (16"x16" wheel base) that can't fit a full PC (to run Ion MC software.) I tune by manually poking values at it and see how it does. I have to turn I up a fair bit for it to stand still on a 20% slope, which is my worst case. I up the D a little bit mainly out of conservatism -- I'd rather have an over-dampened system than an oscillating system.

I currently have four hand-edited profiles to run with, and they all more or less work. I'd just like the bot to "back up" less when it stops on a slope, yet stay standing still.
The first profile doesn't stand still (because no I) but each of the others "work," with the rubber-banding artifact when stopping.

Code: Select all

struct PidSet {
  uint32_t d;
  uint32_t p;
  uint32_t i;
};
static PidSet pidSets[4] = {
    { 0x00010000UL, 0x00140000UL, 0x00000000UL },  // doesn't stop on grade
    { 0x00020000UL, 0x00400000UL, 0x00010000UL },  // just barely stops after going pretty far
    { 0x00030000UL, 0x00180000UL, 0x00040000UL },  // works fine
    { 0x00040000UL, 0x00400000UL, 0x00100000UL },  // works fine
};

Perhaps a combination I should be shooting for would be:
0x00010000UL, 0x00400000UL, 0x00040000UL
combining the fast-response P and the sufficient I to stand still, with a small amount of damping.

Btw: I have two controllers driving two wheel pairs (four independently driven and steered wheels) so there could be two controllers fighting each other in the worst case, although I use math + blending to reduce the risk of it, and why wheels are so spongy there is quite a bit of damping between the two "semi-linked" systems.

[Basicmicro Support]

I feel your P values are a little low.

In most of my tuned motors I found P to be about 10 times higher than I. Have you tuned by increasing P(I and D at 0) until the motors start to continously oscilate and then back off by 1/3rd? If not Id give that a try. Then set your I to about 1/10 the P value and leave D at 0.

Then if the motors still feel too agressive reduce P and I proportionally(eg I always at about 1/10th P). Reducing like this should get you to a point where you have good position holding(even on a slope) but without any oscilation and with only a little spongyness.

[jwatte]

Alright, I'll give that another go-around. Thanks for the advice!
Another perhaps-relevant factor is that I'm not very aggressive in the acceleration I specify. (I'm a little more aggressive when decellerating.)
I use QPPS/2 for acceleration and QPPS*2 for decelleration, but those values alone don't say much unless you also know the motor power and traction and rover weight and weight distribution parameters...