help with throttle PID

[Minuteman]

Like the rest of you, I'm thinking of improvements for next year, and at the top of the list is PID throttle control. I currently use open loop control. I would like to start out with a proportional only controller, but I'm hung up on a concept. The output should be the error (set speed - current speed) multiplied by Kp.  As the error goes to zero (you approach the set speed) your output "force" goes to zero as well, and the car slows down--right? You can never reach the set speed.

So then you set the gain high enough that it essentially approaches and blows through the set point, then coasts until the speed drops, and continues to oscillate...is that how it's supposed to work? (speed up, slow down, speed up, etc...) Doesn't seem too efficient.

Can someone help me understand this?

[Keithrb]

If you are only using the P controller then I think that is exactly what will happen, you need at least 1 of the others, probably I to make it smooth.

[John Leichty]

You could also try adding in a fixed model of the system to the controller, for instance a linear throttle equation based on the speed setpoint. That way when your error is zero you still have some throttle applied.

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/80dcc1a3-5b60-4182-bd06-5aa76fc43008%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Ted Meyers]

That's exactly what I ended up doing (adding a constant factor based on desired speed -- I just couldn't get it to behave by tuning the PID controls).  Still didn't get it working great, a large part of the problem is that its really hard to tune when one is running down the street alongside the bot.  Need a treadmill!

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/CAHpHxZchfsxncv3E%2Bs1viYsmp34-v4ENKG%3Dw4mGvJOExDhOALg%40mail.gmail.com.

[Michael Shimniok]

On 06/25/2014 09:07 AM, Minuteman wrote:
> Like the rest of you, I'm thinking of improvements for next year, and
> at the top of the list is PID throttle control. I currently use open
> loop control. I would like to start out with a proportional only
> controller, but I'm hung up on a concept. The output should be the
> error (set speed - current speed) multiplied by Kp. As the error goes
> to zero (you approach the set speed) your output "force" goes to zero
> as well, and the car slows down--right? You can never reach the set speed.

You're spot on for Proportional constant, only. But there's more than
just P to PID. Here's my relevant code:

float output = config.escZero + (config.speedKp * error) +
(config.speedKi * integral) + (config.speedKd * derivative);

You add to the center value of the servo, 1500us. And you're right,
the system, with Kp only, will arrive at a steady state where actual
speed is less than target speed. At first, error is high, you get lots
of throttle. As you get close, throttle backs off. But you can't reach
target speed because as error goes to zero, throttle goes back to
center. But as you slow down, error increases again. So what typically
happens is that there's a steady state where error and throttle balance out.

To solve that problem, you bring in the Integral part of the PID.
Integral adds the error at every time step. So the longer the speed is
below the target, the more throttle is applied. What that effectively
does is gets you really close to the target speed.

The Derivative term makes sure you're not approaching the set point too
fast or too slow (depending on how you set the constant). I don't
actually use the D term, just P and I and I get a little bit of
oscillation around the setpoint, still, without having spend much time
tuning.

Here's my full code:

// PID loop for throttle control
//
http://www.codeproject.com/Articles/36459/PID-process-control-a-Cruise-Control-example
float error = desiredSpeed - nowSpeed;
// Keep track of accumulated error, but only if we're not
sitting still, due to
// being at the line with manual control enabled.
if (nowSpeed > 0.5)
integral += (error * speedDt);
// determine the amount of change from the last time checked
float derivative = (error - lastError) / speedDt;
// calculate how much to drive the output in order to get
to the
// desired setpoint.
float output = config.escZero + (config.speedKp * error) +
(config.speedKi * integral) + (config.speedKd * derivative);
if (output > config.escMax) output = config.escMax;
if (output < config.escZero) output = config.escZero;
esc = (int) output;
// remember the error for the next time around so we can
compute delta error.
lastError = error;


Michael

[Minuteman]

Thanks for all the replies.

@John: I didn't see you at AVC this year...maybe next year? I guess what you're talking about is known at "feed forward" (?). I think I will give that a try. According to the PID wiki:

Feed-forward[edit]

The control system performance can be improved by combining the feedback (or closed-loop) control of a PID controller with feed-forward (or open-loop) control. Knowledge about the system (such as the desired acceleration and inertia) can be fed forward and combined with the PID output to improve the overall system performance. The feed-forward value alone can often provide the major portion of the controller output. The PID controller primarily has to compensate whatever difference or error remains between the setpoint (SP) and the system response to the open loop control. Since the feed-forward output is not affected by the process feedback, it can never cause the control system to oscillate, thus improving the system response without affecting stability. Feed forward can be based on the setpoint and on extra measured disturbances.

@Michael: To reach the set point, all of your output would come from the integral term, as the Proportional would be 0 by definition. That seems odd--does it lead to problems with windup? The feed forward idea seems very intuitive to me, but depends on a decent mapping of input to output a priori. I'll probably try both.

[Michael Shimniok]

On 06/25/2014 10:44 AM, Minuteman wrote:
> @Michael: To reach the set point, all of your output would come from
> the integral term, as the Proportional would be 0 by definition. That
> seems odd--does it lead to problems with windup? The feed forward idea
> seems very intuitive to me, but depends on a decent mapping of input
> to output a priori. I'll probably try both.

It does seem odd, I agree. If my understanding is correct, the integral
term causes the system to arrive at a steady state much closer to the
setpoint so that the continuous addition of some tiny error results in
enough throttle to keep it at that error amount (if it's at the setpoint
with zero error, the integral is 0 and throttle goes back to center).

What I observe in the actual vehicle, with the constants I have set
presently, is that the vehicle comes up to speed moderately quickly and
stays around that speed give within some range. I don't recall what the
range is but it's not that big. That was this year. A couple years ago I
was getting very rapid acceleration and it would stabilize at a speed
lower than my setpoint.

Feed forward is interesting. It'd be nice to set the throttle to some
known value based on target speed and then correct with PID from there.
Or something like that.

It also might be worth looking into targeting a particular acceleration,
although I'd imagine that would be a very noisy signal.

[John Leichty]

Yeah, I had too much going on this time around, plus it completed my steady decline since 2011 (placing, not finishing, not racing, and not coming). So hopefully next year!

Right, this is feed forward. The linear model will probably be sufficient though some time-dependent model that knows about inertia would give better performance when trying to change speed.

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/f5f5713e-c491-42ff-8bf5-8f4ba2bab137%40googlegroups.com.

[Thomas Roell]

Is there somewhere a SW solution that would look at some run to run data and help adjust the PID constants ?

I had tried that for steering (gave up, used a simple proportional control that was good enough; throttle was fixed). But having limited time and no good quantitative criterias as to whether a run was better or not left me scratching my head.

- Thomas

[Matthew Mucker]

There's a good discussion of PID (and other robotic algorithms) on the free Udacity course, "Artificial Intelligence for Robotics." Michael referred me to that course to learn about the Kalman filter, and I was very impressed with it. If you have a few minutes sometime, check it out. I think you'll find it useful. (There is a link that allows you to go straight to the lecture on PID.)

[Michael Shimniok]

On 06/25/2014 01:13 PM, Matthew Mucker wrote:

There's a good discussion of PID (and other robotic algorithms) on the free Udacity course, "Artificial Intelligence for Robotics." Michael referred me to that course to learn about the Kalman filter, and I was very impressed with it. If you have a few minutes sometime, check it out. I think you'll find it useful. (There is a link that allows you to go straight to the lecture on PID.)

Yes, the PID lecture is great! So is the Kalman Filter part.

To follow up on PID, I did a super simple simulation in GNU Octave. The plot shows velocity and the added pulse width due to integral and proportional terms. In other words, you add integral and proportional output to 1500 and that's your total servo pulse width. Make sense?

The simulation is really simple because it assumes that servo pulse width linearly relates to motor torque and it assumes a resistive force (rolling, wind?) that's linearly related to speed.  But, at least it gives you an idea of the relative contributions of P and I output terms.

For more detail I'm attaching the data file. I'm also attaching the Octave script. You can see in the dat file that error approaches zero. The integral constant is not very large but because error is accumulated, total contribution is pretty big even with small errors. If speed were to overshoot, the integral would be reduced and so output would reduce, too.


Michael

[Josh Pieper]

I'm a little late to the party, but a while ago I wrote up a
description of our open loop model for the feedforward term in
velocity control. It controls based on both speed and acceleration in
order to accurately track speed as a function of position. It is
probably overkill for AVC, where accurate deceleration isn't as
important, but possibly instructive nonetheless.

http://joshp.no-ip.com:8080/blog/robots/20121121-savage-improved-velocity.html
http://joshp.no-ip.com:8080/blog/robots/20121123-savage-velocity2.html
http://joshp.no-ip.com:8080/blog/robots/20121125-savage-velocity3.html

Also, I highly recommend developing the ability to record inputs,
outputs and intermediate values for later analysis. Tuning a car by
watching how it drives as you run alongside just isn't terribly
effective.

Regards,
Josh

Minuteman wrote:
> Thanks for all the replies.
>
> @John: I didn't see you at AVC this year...maybe next year? I guess what
> you're talking about is known at "feed forward" (?). I think I will give
> that a try. According to the PID wiki:
>
> Feed-forward[edit

> <http://en.wikipedia.org/w/index.php?title=PID_controller&action=edit&section=24>
> ]

>
> The control system performance can be improved by combining the feedback

> <http://en.wikipedia.org/wiki/Feedback> (or closed-loop) control of a PID
> controller with feed-forward
> <http://en.wikipedia.org/wiki/Feed_forward_(control)> (or open-loop)

> control. Knowledge about the system (such as the desired acceleration and
> inertia) can be fed forward and combined with the PID output to improve the
> overall system performance. The feed-forward value alone can often provide
> the major portion of the controller output. The PID controller primarily

> has to compensate whatever difference or *error* remains between the

[Russ Johnston]

I'll put in my $.02 too.

To the original question I don't set my power directly based on the crosstrack error but I use it to add or subtract power to/from the motor (I had a problem with windup so I set ki to 0)

    motorPower += (kp * crossTrackError) + (ki * cumulativeError);

works really well with my odometry.

Russ

[Minuteman]

@Russ: That sounds like another endorsement for the feedforward approach. I will be giving it a try. Thanks

[Sawyer Larkin]

This is correct. When using PI, or PID control and the system is in close to a steady state, virtually all control output will be from the I term. This is why when trying to tune a PI it is almost always necessary to have the I term slightly above 0, even when starting tuning on the P term.

Here is another great reference for PID loops:
http://brettbeauregard.com/blog/2011/04/improving-the-beginners-pid-introduction/

A lot of the "corrections" to the normal PID algorithm are related to changing Tuning Terms on the fly but it is still a worthwhile read.

I almost understood PID loops, till I really got the purpose and operation of the integral term, now I again think I know how they work (silly rabbit...)

[Aakash Sahai]

For our entry this year (AutoAuton), I decided to go for PID control only for steering and used a more intuitive and open-loop approach towards the throttle control that worked fine. It was the first year and started working on it in April so there was very little time to brush up on control theory from undergrad classes 25+ years ago, so this year was more of a experimentation and re-learning experience. I am sure you guys are nice enough to ignore my naivety, as I catch up with the experts here :)

The course at AVC was level so it did not matter much that there was no "cruise control", but it has bugged me as well that without any closed loop control system for throttle a more complicated course may not be navigable. So I have been giving some thought to this problem, just like you are, and here is my take:

First of all, if you directly tie the throttle input to the output of your PID control, it is bound to have the issue that you articulated so well. We need to model it properly, first.  Let's see how we drive as humans - with our eye on speedometer and foot on the pedal. We press the pedal until we reach the desired speed, and then keep the foot there as long as we are going at about the desired speed. Note we don't move our foot to reduce the throttle to idle once we reach the desired speed - we keep it steady at that level. If we hit a slightly downward slope, car speeds up, and we lift our foot a little to ease off of gas. If we hit an uphill slope we depress the pedal to increase the throttle and so on. Also noteworthy is that how hard we press the pedal as we start moving has nothing to do with the speed we desire to reach, but with the acceleration or how fast we desire to reach the speed.

So, our control algorithm is actually changing the delta (i.e. relative) movement of the pedal from steady state, and does not tell us anything about the absolute movement of the pedal. That is how a throttle PID ought to work too. Let us say we start from stand still. One might calculate an initial throttle value based on the acceleration needed to get to the desired speed. Thereafter the deltas to this initial throttle value shall be computed from the values coming from the PID. That is, the output of PID control shall be added to the initial throttle value. My intuitive feeling is that it does not matter what initial value we pick for the throttle, the integral term would catch up after a few cycles and adjust the throttle to right value to maintain the speed. Tuning this PID would be fun!

These are just my thoughts. Waiting for the weekend to code and try it out :-) I hadn't had time before the competition to see how good are ground speed measurements from the GPS. First task is to establish that to have a good reference for the speed, as the design is pretty simple at the moment with no Gyro/Accelerometer/wheel-position-encoders involved and hence no sensors to truly implement any level of dead reckoning. I would share my findings, but if someone else tries this approach, or has feedback, please do share.

Cheers!

[Michael Shimniok]

On 06/27/2014 02:48 PM, Aakash Sahai wrote:
> So, our control algorithm is actually changing the delta (i.e.
> relative) movement of the pedal from steady state, and does not tell
> us anything about the absolute movement of the pedal. That is how a
> throttle PID ought to work too. Let us say we start from stand still.
> One might calculate an initial throttle value based on the
> acceleration needed to get to the desired speed. Thereafter the deltas
> to this initial throttle value shall be computed from the values
> coming from the PID. That is, the output of PID control shall be added
> to the initial throttle value. My intuitive feeling is that it does
> not matter what initial value we pick for the throttle, the integral
> term would catch up after a few cycles and adjust the throttle to
> right value to maintain the speed. Tuning this PID would be fun!

I think I get where you're headed. What are your thoughts on stability?

Meanwhile, here's my PID simulator (for Octave).
https://code.google.com/p/bot-thoughts-ugv/source/browse/trunk/Software/Analysis/Octave/pid.m

It is a full PID now. Source the file, then call

pid(time, setpoint, Kp, Ki, Kd);

If nothing else, playing with it awhile gives you a sense of how the
constants affect the resulting speed.

Michael

[Russ Johnston]

@Aakash sounds like you have come to the same conclusions as me. What I found in my testing is that the Integral term really is covered by the Proportional term in this scenario because you are adding or subtracting from the motor power if you have error so you really don't get a persistent error. I set my ki term to 0 and had very good results.

Russ

--
You received this message because you are subscribed to a topic in the Google Groups "diyrovers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/diyrovers/IYuaZgp2tMg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to diyrovers+unsubscribe@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/53ADF6D5.1070308%40gmail.com.