Essay on PID Motor control

Yes, I know. In past projects I have put a clamp on the effect of the integral affect on the calculation, but I wanted to leave it as simple as possible.

Yes, it would be. I've gotten that same feedback from some other people.

Interestingly, I have always tuned PID systems with the classic P followed by I followed by D. When you said I may have it reversed, I thought, "no I don't, what is he talking about?" I googled, and, in fact, found a couple examples where it is P followed by D as you suggest.

That's should be an intersting study to see which method is better suited for mobile robotics. When I get some time, I should experiment.

The problem is that neither method will be exact unless your robot is on a smooth and predictable surface. It will encounter variable surface resistance and load which will almost certainly affect response characteristics of the system.

Why are you suggesting a book?

The purpose of the essay was to describe PID for hobbyists who might not be interested in the math. It isn't that I don't know the math, but describing PID in conceptual terms as well as simple algebra (added later)

In my code, which has drifted from the text over the months, I like the idea of adding differential filtering, that's pretty easy. I was considering an "auto-tuning" version, but that would alter the code quite a bit and complicate it further.

Reply to
mlw
Loading thread data ...

and on 27 Jan 2006:

A couple of questions:

1) Is the algorithm as published not the same as the one tested? I.e., the one that "works pretty well" does not clamp the integral term?

I ask because my experience is that PID controllers will not work at all, or only for a short time, without limiting the growth of the "I" term.

2) Did you test the algorithm/robot behavior for other than the ability to drive a straight line? For example, ability to maintain constant velocity while climbing over obstacles, or with one wheel on a low friction surface (hardwood, concrete) and another on a high friction surface (carpet, gravel) ?

PID controls must be able to adjust the robot's response to two different types of input. One is when the control changes, as when the robot is instructed to change speeds. The other is when the environment changes, as when the robot must climb over something, or passes from concrete to grass, or linoleum to carpet, etc.

3) Do you have any data on how well your algorithm responds to these sorts of real world surfaces?

best regards, dpa

Reply to
dpa

Well, PID has some bothersome border conditions, for sure.

I actually stated that is is a problem.

That isn't technically a PID control, that is a much greater topic encompassing auto tuning, error detection, path planning, etc. The PID algorithm is a mathematical model for feedback control, it is not necessarily the full articulation of a control process.

The algorithm responds as any PID algorithm would. The whole control process is a very much larger topic.

Reply to
mlw

Hello,

Thanks for the reply.

I still did not get the basic information I'm seeking, to wit:

thanks dpa

Reply to
dpa

I'm not sure I understand what you are asking, the algorithm presented is basically the algorithm implemented in the code that you can download.

It works pretty well within the confines of a classic PID algorithm.

What are you asking?

Reply to
mlw

Your webpage is offered as a practical guide for implementing a PID control loop on a mobile robot. I'm asking if you have actually done that yourself, and if so, to describe the behavior of the robot so produced.

It seems from your response, "The algorithm responds as any PID algorithm would" that the asnwer is no. Is that correct?

When asked specifics as to your robot's behavior, you reply:

But that does not square with my experience. So I am attempting to understand your experience. Fair enough?

For example here is a video of one of my robots set to creep along at about 1/20th full speed, well below the minimal torque range of the motors without PID. That is, the robot will not move at all this slowly without the speed controller:

As you can see, when I put my shoe in front of one of the wheels, the PID controller must ramp up the voltage for the motor, both in order to have sufficient torque to climb over the shoe, and in order to keep the robot going in a straight line.

Similarly, when the wheel passes over the shoe, the PID controller must ramp the voltage back down in order to match the original requested velocity.

The video also includes a more realistic clip of the robot climbing over a curb at "cruising speed" and again at 1/20th speed, and maintaining a constant velocity on a low friction surface (concrete) and a hi friction surface (wood chips).

This is, it seems to me, the prime motivation to implement a PID-style control loop. The ability to drive a straight line is a side effect. Hence my questions about the performance of the algorithm that you have published, in real-world circumstances.

best regards, dpa

Reply to
dpa

First of all, I wouldn't call it "Practical Guide" so much as a treatment of the PID algorithm for hobbyists.

My statement is that it is a PID algorithm and behaves as such.

Sure, you seem to be talking about a larger control system and not the PID algorithm. The PID algorithm is a component of a larger control system.

OK, so?

Yes, and I bet that P = E*EG + I*IG + D*DG does not encompass your system.

Yup.

OK

The response of my system is similar with the caveat that loads do not exceed the normal capacity of the wheel motors. The interesting (to me at least) part of the system is that it runs in a non-real time system.

The essay is not "here use my system" is more of a "Here's a description that's easy to understand."

Reply to
mlw

Except you don't really know that because, as best I can gather, you have not actually implemented and tested your code in a real, physical robot.

That's all I was trying to determine.

best luck with your project, dpa

Reply to
dpa

Have you been to the site? I have implemented and tested the code in a "real physical robot." The PID algorithm described is part of a larger control system. You can even download the code.

formatting link

Reply to
mlw

Great!

Can you describe the behavior of your robot, other than to say that it can drive in a straight line for hours while keeping chalk lines on the wheels in sync?

Data is more helpful than unsupported assertion like "the response of my system is similar."

In particular, do you have data on the system's response to:

1) Abrupt changes of control input, and 2) Abrupt changes of the environment (such as going from a low friction to a high friction surface, or climbing over an obstacle.)

I don't understand why is this so difficult for you to answer.

Have you run the robot enough to collect such data? Do you have plans to do so? Will you publish the results?

A video of the robot/algorithm in action would go a long way toward answering these questions.

I can host that video on my website if that is a problem.

best regards, dpa

Reply to
dpa

The two wheels will rotate at the same speed without loss of position. That checks that the system isn't losing data.

"unsupported assertion?" Hmmm, what the hell are you trying to say? I wasn't liking your tone before, now it sounds like an accusation.

That is a higher level robotic control and path planning issue.

Technically it does what it should but the wheels are too smooth and slip.

Because your tone is accusing. I have published the article and the source code, if you don't believe it works, test it for yourself if you don't believe.

Not so much "collect data" as hook a couple scopes on to the various signals in the system and watch the behavior while manually altering load and control settings. Then making simple programs to execute a series of moves and verify that the data points were met when executed. Odometry is a problem because of smooth wheels and hardwood floors.

I think the results are more or less meaningless. This is a hobby not a product. If I were doing this code for a client, then I would probably do something like that, but for now, this is just for fun.

Maybe if I ever get around to it, this is a hobby, that that just seems like work.

I have a good site infrastructure through my main business already.

Reply to
mlw

we agree.

best dpa

Reply to
dpa

Just wanted to let dpa know that there *are* people on the net (I, for one) who very much appreciate his effort in publishing this essay. Please let the critical questions of mlw not keep you from enjoying your hobby and continuing to publish and discuss any results you achieved.

And mlw: nobody is stopping you from doing some work yourself to find the answers some of to the good questions that you raised. dpa has put all the information needed to get started in his essay, and even published the source code. If you publish these answers, I'm sure there will be helpful people in this ng that will be happy to review & criticize them ;-)

Peter

Reply to
Peter Baltus

It is funny, I am a computer consultant for a living. I design software and systems for people for pretty good money.

What I find annoying about the whole dpa dialog is that he is asking for a precision for which the system was not designed, and because it does not have it, he thinks it is without merit and is down right rude about it. Geez the wheels axle load varies as the wheel turns, how can you benchmark something like that? In the field of mobile robotics, and hobbyist robotics at that, the idea of precision is more or less a joke.

Slippery wheels, irregular floors, and obstacles make PID such a small part of the overall motion system. PID is a lot like PLL in the radio world. PLL is a very good mechanism to tune a receiver but it is not the system as a whole. PID is a closed loop control system, nothing more. My essay covers the theory of how that works for someone who may not be interested in calculus. When you start talking about odometry and other issues, you get beyond the subject and a much much more lengthy and complex discussion.

If I were doing this to make money beyond blogbits, it would have been a different project with different priorities. Specifically, I would have used precision parts and encoders. I probably still would have had a goal of using a "non-realtime" system.

As it is, the "$500 robot" is a project in the works during my spare time, and almost anyone can download the code and build something like it from the crap they have laying around.

formatting link
I still like it, and I still think the essay is a good start for someone curious. dpa, not withstanding, of course.

Reply to
mlw

I agree with the point about a few well placed equations... and would add a block diagram picture here or there too.

TC

Reply to
TC

Hi

Seems to be some difference of opinion here as to the common PID capabilities of mobile robots, and specifically as to the performance of hobby mobile robots.

Here's a few hobby robots that can accomplish the trivial PID tasks of maintaining constant velocity while moving from a low to high friction surface, responding smoothly to abrupt changes in the control stream, as well as abrupt changes in the environment:

This is a video of the six-wheel robot posted previously.

Here's its homepage:

This one's a standard two-wheel differential drive with a castering tailwheel.

This one's a LEGO robot.

Even the LEGO robot has all the capabilities that have been referred to in this thread as precision capabilites that are supposedly outside the realm of hobby robot builders.

I politely and respectfully disagree.

enjoy your Sunday, dpa

Reply to
dpa

You seem to be confused as to what was said in another part of this thread. The "PID" algorithm is only part of a much larger system, like PLL on an FM receiver, it only provides the closed loop feedback control for a larger system.

The $500 robot's PID control system maintains pretty good velocity control over a wide range of loads within the capabilities of drive system. On a clean regular surface, it drives straight, rotates 90 degrees when programmed opposing 45 degrees on each wheel. Just like any other dual wheel system would. Drive it on rugs and hard wood floors, its kind of funny to watch.

The problem is that, even though it is as precise as the encoders make it, the wheels are not, the floor isn't, and the contact between wheel and surface is not always assured. Wheels slip and drift, this is a common problem in all mobile robots.

When a wheel encounters a run on the floor, if you push too hard, it just spins in place, if you push more slowly you maintain friction and travel over the run. Remember, the robot weighs about 50 lbs, this is not a trivial control application like mindstorms or other microbots.

One can move a wheel exactly one revolution, but that does not mean that you will move PI*R distance.

Reply to
mlw

PID is one of those "mystery things" that really isn't all that mysterious. I think it is somewhat related to the necessity to look at the granularity of a problem that is being solved. It seems the smaller the time granules, the harder it is for a lot of people to understand.

The one thing that I see that MLW has done that obfusicates things is polling the error asynchronously. This is ok in a PID loop, but greatly complicates other transfer functions. Generally, PID is performed synchronously. In the least, it allows easy graphing of the results, in the worst, it makes implementing other transder functions easier.

I still haven't had the time to filter through all these threads and determine why there is no limit term on the integration. If I had the choice of implementing either an integral limit, or simple feedforward, I would have chosen the limit.

On a side note, gains are generally referred to as Kp, Ki, Kd.

I have seen MLW direct a lot of hostility towards DPA. Unfortunately, DPA is a robotics God, up there with the likes of Alex G. Dan M. and Gordon M. , he just doesn't show his face here that often. I doon't care how long anyon has been doing this as a profession blah blah blah, there is a lot to learn from the masters of the craft. I hope that this doesn't dissuade DPA from interjecting his wisdom into this otherwise wilted corner of Usenet.

Reply to
blueeyedpop

Well, yes, I have found flowcharts useful. Thanks for asking.

You invite people to critique, then snap at them when they do. Sounds more like an invitation to an arguement clinic.

Reply to
blueeyedpop

I don't believe I snapped, although I did take exception to dpa's attitude. It was completely dismissive in a way that was not productive.

The essay was by no means meant to encompass the whole of motion control. That is such a HUGE topic that one could not possibly cover it with a simple web page. Take for instance the criticism of not limiting the integral part of the equation, I have never done that at the PID level, I have typically done that outside the main loop at more of a monitor level where you detect and control run-away conditions. Its a good idea, and just Thursday, an old friend mentioned that that's how he does it. I have tended to think of PID as a simple math problem done in an interrupt handler (I know the system I wrote is different, but old thinking dies hard.) where you are quick and efficient at interrupt time, and do extensive processing later.

The problem I had with dpa's comments is that they were fairly accusatory, don't you think? He calls into question whether or not I even did it. I'm sorry, but if you go over the dpa/mlw thread he is really on the offensive and that is not "constructive" criticism in my book and I took offense to it.

Reply to
mlw

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.