Essay on PID Motor control

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.

Hello,

Thanks for the reply.

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

thanks 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?

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

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."

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

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.

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:

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

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.

we agree.

best 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

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.

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

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

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.

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.

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.

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.

I really try to stay neutral, but in my opinion you quickly take umbrage to comments made in this arena. I have see many conversations involving you take on flaming characteristics of near epic proportions. I honestly had you blocked, not wanting to deal with the static, but C.R.M. has been a crypt lately, and either my Windoze registry freaked, or you changed email addresses, and I started seeing your posts again.

Part of the issue of the debate in my mind, is that "classical" PID uses an L term on I, and therefore deserves to be covered. You chose to omit this, but it really is the essence of making PID's I term behave well. It cast an ignorant light on you whether it is deserved or not. Your insistance on omitting it further tarnished you.

It is good that you are covering the subject at all. Taking time to share your experiences and opinions. For that I commend you. You approach a classic problem in a non-classical way by scaling all your gains according to the period between updates. I personally wouldn't do it, but that is because I am a microcontroller guy with access to much more synchronous systems.

Flowcharts...

In my opinion, freakishly useful. When properly presented, allows one to take a macroscopic view of an entire system. Visualization is a science in itself. If Dale had said a powerpoint presentation, I would be in your camp most likely, but between psuedocode and flowcharts, you can make the average joe understand some very complicated subject ares by taking them through the whole process in a very rough outline. A flowchart is a list, with pointers to different points in the list.

etc. That is 1/4 of the whole ball of wax.

You then go on to explain in detail what each step means, but it gives someone a visual reference.