Essay on PID Motor control

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

Yes,

Flowcharts an an invaluable communications tool.

Mike

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

|-]

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 ----- From: "mlw" Newsgroups: comp.robotics.misc Sent: Friday, January 27, 2006 12:32 AM Subject: Re: Essay on PID Motor control

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.

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.

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.

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