Hi, I am trying to figure out how to make my car go straight , and find that some people use PID control
with motor encoder, it seems really accurate. The principle is the speed gradually decrease when it reach the target degree,right ?
I use another method:slow&constant speed , rotate the wheel until it reach the target. I found it always has a little error, the wheel will not rotate fully 360 degrees,it stop around maybe 355 degrees,after rotating few turns, the errors accumulate and become a big error.
What's the CRITICAL difference between PID control and my method ?
My encoder's resolution is 48 pulses per wheel rotation. I want it to do one rotation,but it always has extra 4 pulses after stop function(stopRL) so I give it 44.
What's the CRITICAL difference between PID control and my method ?
The PID method works, if properly programmed, and yours doesn't.
That is because the "coasting period" after you issue the stopRL() command is not very predictable. It depends on the motor and gear characteristics, as well as the speed and mass of the vehicle.
The PID works on actual error and corrects for it by observing the rotation angles. Angle errors
do not accumulate. Your method has angle error that will ever increase. Moving slowly makes
it worse as motors' low speed behaviour is more sensitive to friction.
However it relies on the two wheels being identical and perfect grip with the surface.
yangkai:
I use another method:slow&constant speed , rotate the wheel until it reach the target. I found it always has a little error, the wheel will not rotate fully 360 degrees,it stop around maybe 355 degrees,after rotating few turns, the errors accumulate and become a big error.
The reason for the pesky error that doesn't go away reveals itself from some mathematics into control systems. If you do (or later do) some control theory - we just learn that the final stabilised 'error', which is the DIFFERENCE between your desired input (and which also usually happens to be the desired output) AND the 'actual' output, will become ZERO (ie. this is usually what we usually want) provided that the mathematical model of our control system contains suitable mathematic terms that allow that error to become zero. So, in the control theory, they talk about stuff like "needing 1 integrator in the open loop system to give zero steady-state error in response to a stepped change in input signal". And more integrators are needed for response to a linear ramp-like input. Things like that.
The 'PID' controller actually introduces an integrator. They also throw in terms like 'adds a pole at the origin in the open loop transfer function', which means the same kind of thing.
Anyway, if the system hasn't got a certain characteristic (behaviour), then the final error (after waiting for some long enough time) won't be zero. And this is what is happening in your system. It's like getting there...but just needs 1 extra mathematical term to help it along.... which is an 'integrator' component. This can be added as a hardware component.... or these days, it can be implemented through software (instead of hardware, even though the analog control signals from the software output ends up being generated by hardware anyway).
I have a question about wheel position overshoot, If the car moves forward, and the the final target position overshoot , It should change the direction by backward function immediately,right? Because I cant give the pwm negative value to rotate reverse way.
Thanks! And the dt would be very small(maybe 0.17ms) ,right? kd*(error-last_error)/dt & kp*(errorsum)*dt ,what values of kp&kd are suggested to begin to try?
I use only p control now , it changes so fast , barely changes the speed before reach the target,and easily oscillates back and forth around the target.
If I give the pwm 0 value when wheel reach the target ,dose it means I dont need stop function anymore when it reach the target?