Troubled by rigorous theory vs. "seat of your pants" control argument

[Rich Grise]

There, in plain public view, I have admitted my wrongness.

This is what grownups do.

Cheers!
Rich

 

[Chris Carlen]

It strikes me that your app needs control that will meet certain
specs. And if it gets one designed by peeing in the wind, there is no
way to know if it will meet those specs. And if it seems to work there
will still be no way to know how it may misbehave under certain
conditions, nor to draw up its real performance specs, nor to assess
how it will behave with another machine of near but not identical
performance. Thus a pee in the wind approach is not going to meet the
requirements of the task.

That looks to me like a simple concept that any engineer will follow
with ease.

Regards, NT

Exactly. This is why I like to learn the background theory behind a
subject and be able to model and understand it, instead of "cookbook"
engineering a solution that may work but I don't know why.

Good day!


--
____________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
[email protected]

 

[Chris Carlen]

This is what grownups do.

Uh-oh. Now I'm *really* assiciated with bad company ;-)


--
____________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
[email protected]

 

[Terry Given]

Terry Given wrote:

-- snip --

the method used to design your controller will have a huge impact. If you
plan on designing an "analogue" controller then (say) transforming into the
z-domain for implementation, then the type of transformation you use is
important - a bilinear transform controller can have a much lower sample
rate than a backward-difference transform controller, which needs around 20x
sample rate to function effectively. There are a wide variety of tricks for
solving this problem, but sampling faster is the easiest one. An all digital
design can easily incorporate this delay [IIRC augment your state variables
with a new variable, which is the delayed state eg v(n)=u(n-1)].

The only time I'd advocate transforming an analog controller into the
z-domain would be if you're replacing it with a digital controller
that's supposed to do _exactly_ the same thing. The closest I've ever
come to this is to write a digital control algorithm with the same
filters as the analog controller it was replacing, then tune it up
empirically based on the plant's frequency response as seen by the

software.


Alas, in practice the former gets done a lot. Its definitely the hard way
though.

Generally I model the plant in continuous-time then (if it's a linear
plant, which is a big if) I make an exact z-domain model of it and
design my control system -- but I still end up tuning it with empirical
data at the end, if I want to get good performance. Even a nonlinear
plant can sometimes be handled this way, by linearizing the
continuous-time system around the "typical" operating point, and
transforming _that_ exactly.

yep analyses are never exact, everything is non-linear to some extent
(usually in the way that causes the most problems and of course
everything varies. But when it comes to simple PID controllers, in many
cases it is not too hard to directly calculate the Kp, Ki and Kd gains
required for a given crossover frequency and phase+gain margins, giving you
a good basis for "fiddling"

In general making the sampling rate faster will make the design job
easier, and require higher precision in all your filters. If you can
spend the money on a fast machine that has the capacity for 32-bit
computation then go collect your bonus. If you need to squeeze pennies
out of the controller (which I suspect will happen eventually if this is
an automotive application) then you should sample as slowly as you can
get away with (which is where my feed-forward or even adaptive
feed-forward suggestion came from).

yes. many companies have gotten in the crap by sampling too fast, either
because of the required filter resolution (well spotted!) or computational
overhead.

cheers
Terry

 

[Paul Hovnanian P.E.]

[snip]

lots of studies have been done on the effect of automated control in
industry. They all end up saying about the same thing - 1/3 of all
controllers improve processes, 1/3 have no net effect, and 1/3 make the
process substantially worse. And the reasons are always the same - badly
tuned controllers (this has fueled the demand for self-tuning controllers, a
jolly good trick). I have watched plenty of guys tune motor controller PID
loops in industry, and they ALL do it "empirically" ie by making it up as
they go along, often for no apparent reason (usually based on what has
worked before).

If the symptoms of an unstable control system aren't serious, that
approach will work. But see how many fly-by-wire flight control systems
they'll let you tweak until the damn thing stays airborne.

Sadly, the software people are winning the battles in many companies.
One day, they are Cobol programmers working for the finance department,
the next they are implementing autopilots.
[/QUOTE]

 

[Terry Given]

The guy has a point; in my experience it's far more likely to come across
problems where something like a PID loop or some 'heuristic' based
controller will solve the problem. However, if you know classical control
theory and can properly apply it, you'll be able to make noticeably more
money solving problems where such approaches fail miserably. In fact, it
seems as though control systems is one of the areas where consultants who
know what they're doing never run out of clients whose own employees failed
to make the system work due to assuming that all systems can be controlled
with simple algorithms.

See Jim Thompson's post a week or so ago about getting a company to pay
through the nose for a control systems fix!

I went to a seminar on motor control by Prof. Joachim Holz a fair few years
back. During the inevitable group discussion at lunchtime, many people
(myself included) asked how to analytically tune a PID controller. We ranged
from fairly junior (me) to quite senior engineers, and the interesting thing
we had in common was that NOBODY at our firms ever analytically tuned PID
controllers, even though they were our stock in trade (we all were involved
in motor control). Prof. Holz was amazed at our ignorance, and in about
5mins flat (using a placemat not a napkin showed us all how easy it is to
do - that was a turning point for me wrt control systems. It took me a few
hours to figure it out for per-unitised control systems, but it still works.
Nice to be able to choose Fcross and damping factor, then directly calculate
gains.

 

[Terry Given]

Well spotted? It's an issue that only seems trivial to those who have
yet to be bitten by that particular dog.

had I been less lazy, I would have written (well worth mentioning) instead.
I certainly wont forget my run-ins with this particular dog.

[for edification of others:]
Its not just filters, of course. Any integrator has this problem - for the
same time-domain response, as an integrator runs at a faster rate, the
amount it accumulates each time must get smaller. A simple hand calculation
shows this:

y(k*Ts) = x(k*Ts) + y((k-1)*Ts)

is a discrete integrator at sample rate Ts (often the *Ts is left omitted,
for "clarity" ie spreading confusion)

choose y(0)=0, x(k*Ts) = 1

the output is of course:
1 t=1*Ts
2 t=2*Ts
3 t=3*Ts
4 t=4*Ts
5 t=5*Ts
6 t=6*Ts
.....

sample at twice the rate Ts' = Ts/2, and the output is
1 t=1*Ts'
2 t=2*Ts' = 1*Ts
3 t=3*Ts'
4 t=4*Ts' = 2*Ts
5 t=5*Ts'
6 t=6*Ts' = 3*Ts
.....

which can be written as
2 t=1*Ts
4 t=2*Ts
6 t=3*Ts
.....


so for the same output response with twice the sample rate we would need:

y(k*2*Ts) = x(k*2*Ts) + 0.5*y((k-1)*2*Ts)

presuming I havent made a mistake, the general solution for some new sample
time Tx is:

y(k*Tx) = x(k*Tx) + (Ts/Tx)*y((k-1)*Tx)

filters and the like get even trickier - quantisation restricts the possible
locations of poles/zeroes, which can make theoretically stable filters
unstable. Bucketloads of work has been done on trying to figure out what
resolution is required for any given job....Peter Brackett can probably
inform us further.....

Note that the advise was for a (presumed) high-volume application. For
a low-volume application you should just spend tons of money on the
processor, sample fast, and pay for it all with the reduced engineering
time.

Tim Wescott

hell yes. Some of these "whiteware" DSPs have amazing features, for <
US$10 - if you look carefully. Alas, most "designers" simply use the chip
they are most familiar with (plenty of merit in this approach, if the chip
is suitable)

 

[Tim Wescott]

lots of studies have been done on the effect of automated control in
industry. They all end up saying about the same thing - 1/3 of all
controllers improve processes, 1/3 have no net effect, and 1/3 make the
process substantially worse. And the reasons are always the same - badly
tuned controllers (this has fueled the demand for self-tuning controllers, a
jolly good trick). I have watched plenty of guys tune motor controller PID
loops in industry, and they ALL do it "empirically" ie by making it up as
they go along, often for no apparent reason (usually based on what has
worked before).

-- snip --

I was in a local panel discussion a few years ago about control systems
where the panel consisted of me (custom embedded motion control
designer), a software engineer who specialized in GUI's for embedded
controllers, and a process control engineer for one of the local forest
products company.

It turns out that at most mills those controllers must be tuned by union
millwrights -- the engineer who specifies them _may not_ touch the
knobs, lest they be taking bread out of an honest workingman's mouth
(you can tell I'm highly pro-union, eh?). Furthermore, it's the
_millwright_ who decides when and how the controller should be tuned, so
if the 3rd-shift guy gets drunk and @#$%s it up it may not be discovered
for days.

That having been said there is a fairly good empirical method for tuning
a PID loop that generally works if you can stop yourself from trying for
too much performance. It's detailed in my paper "PID Without a PhD"
which you can get to from
http://www.wescottdesign.com/articles/pidwophd.html. Using this method
_will not_ give you an optimal tune, and it doesn't guarantee the
world's best phase and gain margins, but if done carefully and
responsibly it's a heck of a lot better than nothing.

 

[Joel Kolstad]

I once worked with a system whereby the programmer had,
independantly, invented the proportional controller (not that he would
believe it) and had the lowest gain possible (every loop he would add 1
to output if input > setpoint etc).

Actually, this is an integral-only system. I've used them myself... for
stuff like heaters/lightbulbs where I _wanted_ the aesthetic effect of being
able to see something heat up. I imagine my loop bandwidth was down around
0.1Hz?

Funnily enough the performance was
crap. but do you think I could get the guy to open a control systems
text, or implement a different gain, or even , PI controller - now way!

I don't believe people with comp. sci. degree necessarily ever take anything
resembling a control course these days? Even if you did get him to open a
book, at the first sign of a Laplace or Fourier transform of the use of
phasors he would have run screaming from the room.

 

[Tim Wescott]

Actually, this is an integral-only system. I've used them myself... for
stuff like heaters/lightbulbs where I _wanted_ the aesthetic effect of being
able to see something heat up. I imagine my loop bandwidth was down around
0.1Hz?




I don't believe people with comp. sci. degree necessarily ever take anything
resembling a control course these days? Even if you did get him to open a
book, at the first sign of a Laplace or Fourier transform of the use of
phasors he would have run screaming from the room.

Computer science still avoids control. Most universities no longer have
EE departments, however, they're "Electrical and Computer Engineering"
departments. This doesn't mean that people learning 'C' are learning
filters, but it's something.

 

[Paul Hovnanian P.E.]

[snip]

Computer science still avoids control. Most universities no longer have
EE departments, however, they're "Electrical and Computer Engineering"
departments. This doesn't mean that people learning 'C' are learning
filters, but it's something.

At the behest of most corporations, computer science is
compartmentalized and kept apart from any other discipline. Not only
engineering, but finance, manufacturing, etc. are kept separate from
software development. Its back to the old days, with computers in back
rooms, tended to by armies of technicians with white coats, because
nobody else could possible understand how a computer works. ;-)

In reality, this seems to be a reaction to the (perceived) high cost of
software skills. Attempts are made to separate hardware and software so
that the software development could be put out for bid and (hopefully) a
few bucks shaved off the project.

 

[Terry Given]

[snip]

lots of studies have been done on the effect of automated control in
industry. They all end up saying about the same thing - 1/3 of all
controllers improve processes, 1/3 have no net effect, and 1/3 make the
process substantially worse. And the reasons are always the same - badly
tuned controllers (this has fueled the demand for self-tuning controllers, a
jolly good trick). I have watched plenty of guys tune motor controller PID
loops in industry, and they ALL do it "empirically" ie by making it up as
they go along, often for no apparent reason (usually based on what has
worked before).

If the symptoms of an unstable control system aren't serious, that
approach will work. But see how many fly-by-wire flight control systems
they'll let you tweak until the damn thing stays airborne.

Sadly, the software people are winning the battles in many companies.
One day, they are Cobol programmers working for the finance department,
the next they are implementing autopilots.

yeah, it only tends to happen where there arent hugely adverse consequences.
classical SISO control is a mature field, you shouldnt have to guess. I once
worked with a system whereby the programmer had, independantly, invented the
proportional controller (not that he would believe it) and had the lowest
gain possible (every loop he would add 1 to output if input > setpoint etc).
Funnily enough the performance was crap. but do you think I could get the
guy to open a control systems text, or implement a different gain, or even ,
PI controller - now way! In the end I gave up, and left the programmer
suffer the consequences (project slippage, eventually cancellation) of his
stupidity. Warning management didnt help either.

Cheers
Terry

 

[Rich Grise]

It strikes me that your app needs control that will meet certain
specs. And if it gets one designed by peeing in the wind, there is no
way to know if it will meet those specs. And if it seems to work there
will still be no way to know how it may misbehave under certain
conditions, nor to draw up its real performance specs, nor to assess
how it will behave with another machine of near but not identical
performance. Thus a pee in the wind approach is not going to meet the
requirements of the task.

That looks to me like a simple concept that any engineer will follow
with ease.

I designed an SCR phase-controlled battery charger using the timer
in a 68HC11 once. It hunted. So, I was all set to start screwing
around with various transfer functions and stuff in firmware, and
while I was mulling, my client went over and clipped a .47 cap from
the sense line to ground. It stopped hunting, so changed that part
of the design. I don't think he sold any - it was too expensive, and
apparently people who have to recharge fleets of forklifts don't
really care about 3 programmable levels of charge profile. )-;

Cheers!
Rich

 

[Rich Grise]

Sadly, the software people are winning the battles in many companies.
One day, they are Cobol programmers working for the finance department,
the next they are implementing autopilots.

Speaking of COBOL, I've only had a couple of encounters with it. One
was when a contract programmer came in to do the company's bookkeeping
software - I spotted some COBOL on her screen one day, and I mused,
to the office in general, "Why do I get the feeling that I'm watching
her try to create a mnemonic memory device using stone axes and
animal skins?"

The other time there was a gal who asked if I could tutor her, but it
turned out to be a ruse - she just wanted to get in my knickers. ;-)

Cheers!
Rich

 

[Rich Grise]

Computer science still avoids control. Most universities no longer have
EE departments, however, they're "Electrical and Computer Engineering"
departments. This doesn't mean that people learning 'C' are learning
filters, but it's something.

Oh, I don't use 'C' for filters any more, since I got Linux. Now
I just use grep.

;->
Rich

 

[Terry Given]

[snip]

Computer science still avoids control. Most universities no longer have
EE departments, however, they're "Electrical and Computer Engineering"
departments. This doesn't mean that people learning 'C' are learning
filters, but it's something.

At the behest of most corporations, computer science is
compartmentalized and kept apart from any other discipline. Not only
engineering, but finance, manufacturing, etc. are kept separate from
software development. Its back to the old days, with computers in back
rooms, tended to by armies of technicians with white coats, because
nobody else could possible understand how a computer works. ;-)

In reality, this seems to be a reaction to the (perceived) high cost of
software skills. Attempts are made to separate hardware and software so
that the software development could be put out for bid and (hopefully) a
few bucks shaved off the project.

Paul Hovnanian mailto[email protected]

Interesting. multi-disciplinary education is pretty much mandatory for an
engineer, we have to talk to all sorts of people - electrical, mechanical,
civil, thermal, control, chemical, computing, finance, quality......

I am constantly amazed (and disgusted) at the piss-poor performance of
virtually all software. Some software (matlab springs to mind) is absolutely
brilliant - robust, reliable and they fix problems. Most sw however is just
shit. I have lost count of the number of times I read sw documentation that
says "pull down the Blah menu" only to discover it doesnt even
exist.....Mathcad or protel users will no doubt have plenty to say about
this.....

as part of my EE education I studied sw engineering for 3 years. We learned
that abotu 80-90% of all software projects NEVER work/are completed/are
delivered. clearly programmers dont learn project management.

I actually think the problem is very subtle - sw is LICENSED, not sold. Most
countries have consumer protection laws that require stuff to actually do
the job it is sold for. Because sw isnt sold, these laws do not apply, and
the first bit in any sw EULA says, in effect, that the software may or may
not work properly, and too bad if it doesnt. People dont put up with this
shit from any other branch of engineering.

I would actually argue that sw performance is SO BAD it doesnt deserve to be
called engineering. This is despite the fact that the techniques for writing
good code have been well known for decades (just like the tricks for good OS
design .

My experience working with comp. sci. grads is that they know lots about
APIs etc. but **** all about design. how to write sw functions is not too
much of an issue - the real important question is what to do (witness
Outlook and its stupid database structure for emails. I mean Duh, what the
hell is the disk OS doing.....)

I'd better stop ranting now, before I get carried away and turn out a
Kazinski-esque diatribe.....

(my favourite quote from the clinton/lewinski affair, other than "close but
no cigar" is a little limerick that won a contest rhyming lewinski and
kazinski:

Clinton and Lewinski have shown,
what Ted Kazinski has long since known,
that an intern is better,
than a bomb in a letter,
given the chance to be blown.

cheers
Terry

 

[Paul Hovnanian P.E.]

[snip]


My experience working with comp. sci. grads is that they know lots about
APIs etc. but **** all about design. how to write sw functions is not too
much of an issue - the real important question is what to do (witness
Outlook and its stupid database structure for emails. I mean Duh, what the
hell is the disk OS doing.....)

There seems to be a philosophy aimed at keeping software development
apart from all other disciplines. In the companies I have worked at,
software engineers were supposed to be interchangeable, between the
accounting department and flight controls engineering. In order to
encourage this level of portability, it was necessary to make sure that
the software people never obtained significant levels of domain
knowledge.

Engineers (electrical, mechanical, etc.) were taught software skills to
use as tools. In order to use a tool, you have to understand the
application to which you are applying it. Pure software engineering is
like learning how to use a socket wrench without bothering to learn how
an auto engine works.

 

[onestone]

I am constantly amazed (and disgusted) at the piss-poor performance of
virtually all software. Some software (matlab springs to mind) is absolutely
brilliant - robust, reliable and they fix problems. Most sw however is just
shit. I have lost count of the number of times I read sw documentation that
says "pull down the Blah menu" only to discover it doesnt even
exist.....Mathcad or protel users will no doubt have plenty to say about
this.....

as part of my EE education I studied sw engineering for 3 years. We learned
that abotu 80-90% of all software projects NEVER work/are completed/are
delivered. clearly programmers dont learn project management.

I actually think the problem is very subtle - sw is LICENSED, not sold. Most
countries have consumer protection laws that require stuff to actually do
the job it is sold for. Because sw isnt sold, these laws do not apply, and
the first bit in any sw EULA says, in effect, that the software may or may
not work properly, and too bad if it doesnt. People dont put up with this
shit from any other branch of engineering.

How screwed up this situation really is came to light about a year ago.
Here in Australia we have some fairly solid consmer laws. We also have a
software retail industry that refuses to refund or accept returns of
software for any reason. The fear being that you've illegally copied the
code and now want your money back. This backfired, and revealed a hole
in the entire licensing process. Since the License is invariably
contained on the installation disk, and since it cannot be read until
installation, the law deems it unreasonable to expect a purchaser to
agree to something they haven't yet been able to see or evaluate when
their is no recourse should you not acceopt the license. ie if they
won't refund my money because I don't accept the license then the law
deems me to have bought the software, since the license terms were not
made known to me until after purchase, I am the owner of that software,
and therefore free to do as I please with it. Including making and
selling copies. Of course you'd better have deep pockets , or be a
lawyer to push this, unless, as in my case I had the Australian consumer
council fighting for me. Under Australian law the retailer, not the
manufacturer of the product is my poj tof legal redress. Therefore if a
legally appointed retailer will not refund your purchase price when the
license proves to be unacceptable the manufacturer can do nothing about
it. Even were the license made available to read prior to purchase, it
is not a reasonable license unless opportunity is given to first
evaluate the product.

I would actually argue that sw performance is SO BAD it doesnt deserve to be
called engineering.

Absolutely agree 100%. Software engineer on a job application normally
merits file 13.

Al

 

[Guy Macon]

Since the License is invariably
contained on the installation disk, and since it cannot be read until
installation, the law deems it unreasonable to expect a purchaser to
agree to something they haven't yet been able to see or evaluate when
their is no recourse should you not acceopt the license. ie if they
won't refund my money because I don't accept the license then the law
deems me to have bought the software, since the license terms were not
made known to me until after purchase, I am the owner of that software,
and therefore free to do as I please with it. Including making and
selling copies.

That last bit would be in violation of the Universal Copyright Convention
(UCC) and the Berne Convention for the Protection of Literary and Artistic
Works (AKA the WIPO Copyright Treaty). Austalia signed both treaties.

 

[Kevin Aylward]

Terry Given wrote:
[snip my anti-sw diatribe]

How screwed up this situation really is came to light about a year
ago. Here in Australia we have some fairly solid consmer laws. We
also have a software retail industry that refuses to refund or
accept returns of software for any reason. The fear being that
you've illegally copied the code and now want your money back. This
backfired, and revealed a hole in the entire licensing process.
Since the License is invariably contained on the installation disk,
and since it cannot be read until installation, the law deems it
unreasonable to expect a purchaser to agree to something they
haven't yet been able to see or evaluate when their is no recourse
should you not acceopt the license. ie if they won't refund my money
because I don't accept the license then the law deems me to have
bought the software, since the license terms were not made known to
me until after purchase, I am the owner of that software, and
therefore free to do as I please with it. Including making and
selling copies. Of course you'd better have deep pockets , or be a
lawyer to push this, unless, as in my case I had the Australian
consumer council fighting for me. Under Australian law the retailer,
not the manufacturer of the product is my poj tof legal redress.
Therefore if a legally appointed retailer will not refund your
purchase price when the license proves to be unacceptable the
manufacturer can do nothing about it. Even were the license made
available to read prior to purchase, it is not a reasonable license
unless opportunity is given to first evaluate the product.


Al

Hi Al,

I hadnt thought of that. In NZ we too have excellent consumer
legislation,, along similar lines - the contract is between the
purchaser and the seller, the manufacturer doesnt enter into it (none
of this "go complain to the manufacturer" bullshit I had to put up
with in MA). IIRR it is the law of torts which says you cannot enter
into a contract without being made aware of its provisions first. An
inability to read the license agreement certainly fits that bill, so
I will file that away, and use it the next time i buy sw i dont like.

(Funnily, many music stores wont give you a refund if you dont like
the cd, but will if its damaged....duh, clearly the solution if you
buy the wrong CD is to scratch it, then ask for your money back.
Smart music stores let you change your mind.)

So we've got a little bit of consumer protection, but until the loop
is closed with the sw "manufacturer," the current appalling state of
affairs will continue unabated.

One snippet about the UK is that having a licence that implies that you
are giving up your statuary rights, e.g. suitability for purpose etc is
a *criminal* offence. A UK licence that notes some restrictions,
requires some sort of notice that "your statatory consumer rights are
not effected". This type of notice is often seen in shops to avoid the
connotation when they have other signs saying "no refunds", when they
mean no refund for goods with no faults. Many states in the US allows
one to waive consumer rights, in the UK such waivers are always invalid.
Software is treated in the same way as any other physical goods as far
as consumer protection is concerned in the UK, although the majority of
the consumers don't seem to know this, or their rights. Indeed, there is
a fair contracts law that allows unreasonable clauses to be struck out.

Kevin Aylward
[email protected]
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.