Essay on PID Motor control

Mitch Berkson wrote:


Ahhh, the benefit of a crosshair interesting, I'm thinking. The horizontal line is nothing more than an infinite number of dots and I can range find across a field of view.
I have a couple ideas about the vertical line that I can't articulate until I do some experimenting.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
As with all code, a flowchart would be a bonus

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Dale T Stewart wrote:

Really? I've *never* found flow charts useful, have you?

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
blueeyedpop wrote:

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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.
<Read Feedback> | <Calculate Positional Error> | <Multiply Positional Error by Corrective Factor>
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.

more
attitude.
just
tended
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Sun, 29 Jan 2006 18:54:14 -0800, blueeyedpop wrote:

I had instructors in college who wanted us to flowchart during design. I found them pretty useless from the perspective of designing the code (psuedo code is great, though). Anything simple enough to flow chart didn't need one, and anything complex enough to require the flow chart got too unweildy too quickly.
However, for explaining the code after the fact to someone else, I find flowcharts invaluable. So, IMO, as a design tool, I personally don't care for flow charting. However, as a teaching tool, I give them two thumbs up.
Oh, and on the DPA vs MLW thing, it appears to me DPA was simply trying to get clarification as to whether MLW actually ran the code on his robot or not. I thought you took that completely the wrong way, MLW. Lighten up.
-Brian
--
Brian Dean
ATmega128 based MAVRIC controllers
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Yes,
Flowcharts an an invaluable communications tool.
Mike

in
up.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Well as a former teacher of 10 years experience,... a picture says a thousand words. Maybe you don't find flow charts useful, but as a teaching aid, many DO.
Cheers
|-]
Dale

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Dale T Stewart wrote:

I'm replying to both posts, I hope that is OK. Also, this post expresses opinion about flow charts, not suggestions about the essay. I appreciate any attention given and appreciate and advice given. The topic of flow charts, however, is one in which I have strong opinions.
My grip with flow charts was well stated by someone else in this thread.
If the process can be flowcharted, it is probably so simple that it doesn't need one. If the process is complex, the flow chart is too cumbersome to manage.
Now, I have no problem with illustrations, that would be fine, but not exactly my forte' Illustrations and animation are wonderfully informative and entertaining, but don't convey as much information as the written word.
As for Einstein and Hawking using illustrations, I think you are largely mistaken. You imply that they used illustrations heavily to convey complex theories when, in fact, they do not as much as you think.
In the book, "Relativity, The Special and The General Theory, A Clear Explanation that Anyone Can Understand" by Albert Einstein, I see five, and only five, items that are neither math nor text. The figures are simple graphs. So, in a book of 157 pages, there are 5 illustrations, or one in about 34 pages. I'd have to write about 30 more pages to justify a single illustration to keep up with Einstein.
In the book, "A Brief History of Time ..." (first edition), there are 34 illustrations and the book itself is 182 pages. Hawking is far more liberal with his drawings, but then again, he probably has illustrators, but still, that's one illustration every five or so pages, but most chapters don't have any.
<RANT> Flow charts, IMHO, are no more than the GUI equivalent of pseudocode, and as valuable as any GUI-fication of inherently textual information, and pseudocode is as inherently valuable as any pseudo-anything. </RANT>
Seriously, maybe it is just that I've been a software engineer for 20+ years, and I have yet to see a flowchart outside a sales presentation. pseudo code is better, and real code is betterer. I have made the real code available.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
mlw wrote: ...

And thus it was followed by a plethora of relativity books with lots of illustrations and graphs by other authors as the idea that it was a clear explanation that anyone can understand was being a bit optimistic.
...

Perhaps some things lend themselves to flow charts and other things don't. I remember when first learning programming I found a flow chart of an expression evaluator helpful in untangling the code. And I also found it useful when learning about nested loops. And I found using nested boxes made it easier to see the overall structure of the code.
+---------------------+ | WHILE | | +----------+ | | | IF THEN | | | | | | | | ELSE | | | | | | | | END IF | | | +----------+ | | +---------------+ | | | IF THEN | | | | +----------+ | | | | | IF THEN | | | | | | | | | | | | ELSE | | | | | | | | | | | | END IF | | | | | +----------+ | | | | END IF | | | +---------------+ | | END WHILE | +---------------------+
While learning I wrote a program that would create such boxes and check that each IF had an END IF etc. automatically fixing up any indentation required.
I agree real code is better then pseudo code for I found it a real chore translating it into real code. I even wrote a program to help with that and fix any indentation mistakes.
eg. psuedo code,
IF A = B THEN S = S + 1 END IF
became,
if (A == B) { S = S + 1; }
As a BASIC programmer I would do silly things like, if (A OR B), which the automatic translator or experienced programmer would not do :) The most common mistake I made while learning C was to remember the semi colon.
Now if, for example, I wanted to explain how the Bresenham's line drawing algorithm worked I would not just give the code. I would explain it with words and maybe some illustrations as well so it was clear how a decision variable was being used to determine when and where to draw the next pixel. A good explanation would be sufficient for a programmer to quickly write their own version without ever seeing a coded example.
Indeed an human language explanation I think is often the best way.
e.g. Search the list for two items with the closest centroids.
Now the above can easily be translated into code by an experienced programmer or indeed given the code translated into the above explanation of what the code was doing. Reverse translation from code to explanation is however not so easy for a beginner or someone who has limited programming experience.
I also suspect that a professional programmer can untangle code faster and with ease compared with an hobby programmer who only programs on those occasions that require it for some project but doesn't do it regularly on a wide range of problems. And thus for a beginner or a hobbyist who has limited programming experience or know how a human language explanation I think is required.
Also if the person lacks the background knowledge, say in math, no amount of code or explanation is going to help.
-- JC
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
By the way, Albert Einstein was a great communicator of his ideas, as was Hawkins, Pembrose, exceptional geniuses. They all thought and communicated with pictures - flow charts are are an example of such a teaching technique. Einstein used simple illustrations so that non-physicists could underwstand complex concepts. Hawkins is now Lucasian Professor of Mathematics at Cambridge, a position once held by Sir Isaac Newton, so I guess he is an efffective teacher too, much better than I could hope to be.
If you want others to understand what you are propounding, then a number of techniques need to be employed to effectively communicate your ideas and theoretical concepts.
Hope this helps (everyone).
Cheers
|-]
Dale ----- Original Message -----
Newsgroups: comp.robotics.misc Sent: Friday, January 27, 2006 12:32 AM Subject: Re: Essay on PID Motor control

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
mlw wrote:

Notes:
There's no filtering for the D term. Unless you have an encoder with a huge number of counts per rev, you'll have considerable quantization noise in the D term. Usually, you put a low-pass filter in to damp that noise, even though it costs you some lag.
The problems mentioned in "Warning Read This Before Operating!" are because the code doesn't have what's called "antiwindup". There are ways to keep the I term from building up improperly.
Some examples, with a motor and some graphs, would make it much clearer what's going on.
In the section on tuning, you have the integral and differential gains reversed, I think.
I recommend buying "Control System Design Guide", by George Ellis. Preferably the slim first edition, which was more concise than the second one. This is a practical guuide to motor control, not a control theory text.
                John Nagle
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
John Nagle wrote:

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I'm a bit confused.
On 24 Jan 2006 mlw wrote:

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
dpa wrote:

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Hello,
Thanks for the reply.
I still did not get the basic information I'm seeking, to wit:

thanks dpa
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
dpa wrote:

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?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Hello,
mlw wrote:

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:
<http://www.geology.smu.edu/~dpa-www/robo/jbot/jbot_slow.mpg>
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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
dpa wrote:

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."
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.