Chief Delphi - PID Loop Question

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - PID Loop Question (http://www.chiefdelphi.com/forums/showthread.php?t=90061)

Re: PID Loop Question

Quote:

Originally Posted by Ether (Post 1008825)

I'll take a crack at answering my own question.

If the center of mass is not equidistant from all four wheels, then during conditions of acceleration the wheel(s) to which the CoM is closest will see a greater effective inertia. If there is no (or minimal) acceleration, the only effect would be an increase in rolling resistance which may or may not be significant depending on the flooring material and the wheels.

Sounds like a nice explanation. In addition, if you are at the traction limit, the wheels with more normal force on them will be able to contribute more to the acceleration of the robot, and should have a more aggressive controller to do that.

Re: PID Loop Question

The topic of doing speed control via PID has come up several times in recent weeks. I have referred people to this thread: http://www.chiefdelphi.com/forums/sh...&highlight=PID

To quote myself:

Quote:

A couple things to keep in mind here:

The standard POSITION PID loop might look something like this:

output = Kp*e_pos + Ki*e_pos_sum + Kd*e_pos_delta;

Where output is the output.
e_pos is the error in position = desired_pos - actual_pos
e_pos_sum is the sum of the position errors = e_pos_sum + e_pos
e_pos_delta is the derivative of the error = e_pos - e_pos_last

This loop, if well tuned, should provide pretty good position control. But what about VELOCITY? Speed is the first derivative of position - so we could differentiate the position loop with respect to time to obtain a velocity controller.

I will use the D() operator to represent taking the time derivative.

D(output) = Kp*D(e_pos) + Ki*D(e_pos_sum) + Kd*D(e_pos_delta);

So far so good. What's the derivative of the output? Well, that's the change in output over time, so D(output) = output - output_last.

Whats the derivative of e_pos? Remember that e_pos itself is (desired_pos - actual_pos). It's derivative would simply replace "pos" with "vel".

e_vel = D(e_pos) = desired_vel - actual_vel.
e_vel_sum = D(e_pos_sum) = e_vel_sum + e_vel.
e_vel_delta = D(e_pos_delta) = e_vel - e_vel_last.

Putting it all together, you get:

output - output_last = Kp*e_vel + Ki*e_vel_sum + Kd*e_vel_delta;

Let's rearrange...

output = output_last + Kp*e_vel + Ki*e_vel_sum + Kd*e_vel_delta;

or...

output += Kp*e_vel + Ki*e_vel_sum + Kd*e_vel_delta;
(assuming output is global or static and persists between loop iterations)

The key is the "+=" in the final equation. E.g. your PID loop output should be the DELTA to the motor PWM. If you use the output directly, you essentially only took the time derivative of one side of the (well understood) position PID equation. You can still tune it to work, but Kp, Ki, and Kd no longer represent what you thought they did.

In simpler terms, position PID uses motor PWM (~= speed, the time derivative of position) as the quantity being output. Thus, velocity PID uses motor acceleration (the time derivative, or DELTA in motor PWM) as the quantity being output.

Re: PID Loop Question

So how would one go about tuning a speed-based PID? I mean, the thing is on the ground and moving, and if you have multiple PID loops going, each one will affect the others, right? It just seems like it would be a huge pain to tune. Someone have a method they wouldn't mind sharing?

Re: PID Loop Question

Quote:

Originally Posted by Geek 2.0 (Post 1008956)

And there lies one problem with the application of PID control... Unless you have developed a mathematical model of the whole system, an analytical/simulation solution is fairly hard to come by.

Now, to specifically answer your question I'd probably do something like the following. Note that I haven't done this specifically for multiple loops so take it all with a grain of salt. I'm sure someone here has more experience in this regards as most of my experience with successful loops has come with a fully modeled system. Most importantly you are going to want telemetry data on the system's response as you are tuning. Without this you'll be taking a stab in the dark saying "I think that was better..".

1. Assuming multiple control loops, tune them using the same constants throughout. Unless the system each controller is controlling is vastly different, this should get you pretty close.

2. Once you've gotten pretty close with each controller, analyze your telemetry data and tune from that making only ONE change at a time and proceeding to test and analyze. Rinse and repeat as needed.

For example, lets say you have two control loops, one for the speed of the left drive wheels and one for the right drive wheels. You've tuned them using the same constants, however your telemetry (and probably physical observations) indicate that your right drive wheels speed up slightly slower than the left leading to the robot veering to the left before the right wheels catch up and straighten out. In this situation I would probably increase Kp slightly to improve the rise time.

Again, this is all in theory and assumes an understanding of manually tuning of a PID controller. If I remember correctly back in 2005 my team used a control loops on the speed of our drive wheels. We only used one controller for both however and achieved acceptable results. The robot was fairly equally balanced though so your mileage may vary. I'd definitely suggest trying to tune them the same first and then if that doesn't work, go for individual tuning of the loops.

Re: PID Loop Question

How I tuned the gain of our drivetrain, on a practice bot (to get the code right):

1. Run the robot in each direction to determine the maximum forward/reverse speed of the slower side (since that limits the forward/reverse speed)
2. Setup LabVIEW to graph the Sensor, Setpoint, Delta, and Output (basically just open the VI that shows the graph, and open the constants VI as well)
3. Set the gain to a known in-range number (in my case, that was 0.01)
4. Jack up the gain until the graphs show a reasonable rise time and minimum overshoot.
5. Decide if I need to write a gain scheduler (and I decided to, so I did write a linear gain scheduler)
6. Tune the gains again (go back to 4) for each end of the spectrum, and check that the performance is good in all zones
7. See how the extreme and precise response is, and decide what to do about those. I found that with an I only, the robot backs up slightly when stopping (integral windup), so I wrote some code to handle sign mismatches between setpoint and sensor differently.
8. Drive it again and tune, repeat until perfect.

On the chassis I tested (34 lbs chassis w/ everything but 1 front bumper and the battery, + 50lbs in weights) with 6" kit wheels and a 1-speed, I was fine with 1 set of constants. I assume I will need to tune High and Low separately, but that comes when the robot is done.