Go Down

Topic: PID Velocity Control, Drives Motor Backwards. What could be the reason?  (Read 115 times) previous topic - next topic

Graubelb

Hi,
I encountered a strange behavior in using the PID V1 Library. I use it for Velocity control of drive wheels until now only in PI mode. Sometimes the controller drives the motor backwards when it is ordered forward. If I order "full" forward this doesnt happen, but when ordering small forward velocity it does happen, sometimes.

So if I order 0.03 m/s (= ca50%) forward I get ~-0.01, and it doesnt recover from there until I reset the PID.

This happens with several different motor/encoder combos, so it doesnt seem to be damaged or faulty hardware. This sometimes also evolves from a correct movement. First it starts fine and then simlply reverses or stops, but in absolutly no relation to what it is actually doing (the scale of the issue is way to big to be noise, I think). 

P=1.7, I=1.2. D=0; Motorcommands are -+400, and setpoint is converted 0.03 m/s = setpoint 30, as is input.

Any Ideas what this could be all about? Thanks.


wildbill

You'll need to post your code and give some details about how you are measuring speed. But guessing, if you're over speed, the PID will back off on the value it is commanding the motors with. If it's still over speed, it will back off more and it seems that at low speeds it may back off enough that it's asking for negative speed (going backwards).

MarkT

If the I term is non-zero and the velocity sensing isn't lying to the system, it must eventually recover to forwards velocity, as the integral error will rise without limit until it dominates and corrects the issue.

Measuring low speeds can be tricky, as most methods have latency that increases as the speed falls, and long latency periods destabilize any control loop.
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]

Graubelb

Thanks for the replies.

The Code is PID_v1 library. Speed is meassured with a intervaltimer/ticks. But at first it was an interrupt/timing calculation. The same problem with both. I changed it because I thought that noise may generate a big positive error (single tick due to vibration etc., by summing the ticks over 20ms/50ms this kind of errors should be minimised) . But as this situation goes on for several seconds (until i reset it) with bouth methods I dont think noise will generate such a constant behaviour.

The input reads out fine (as far as visual observation allows), it shows the wrong behaviour/right vel and the setpoint is fine as well.

I use quadrature encoders and library.


MarkT

The problem with using ticks is how do you ever register a zero speed?  The raw tick times have to be processed to provide a velocity estimate, in particular that velocity estimate has to tend towards true zero if no more ticks come in.
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]

Graubelb

As for now I use a intervaltimer. So zero ticks = zero vel. With the other method I reset the pid when ordering zero and set output and input to zero. That wasnt the issue. 

UPDATE: What I found now is that the relation betwenn P and I has significant influence on the issue. The wider the spread between P and I the worse the problem. Maybe its even a mechanical problem and the gears break loose at different forces in different directions. However in that case I would expect a hard reaction not a mild one. It seems like a big I is countered by P or the other way arround, so that there is a little net negative output.


Go Up