There's a few details on system theory at the front of this note;
developers interested in the
controls toolbox should scroll to the end of this note for some of my
own questions and observations
on the OCST (octave control systems toolbox)
On Thursday, November 6, 2003, at 10:56 AM, Doug Stewart wrote:
A S Hodel wrote:
> The reason behind octave's restriction is to ensure the ability to
> convert between
> rational polynomial representations (tf, zp) and state-space
> representations. That is,
> a PID in the form described is not physically realizable, that is, the
> transfer function
> is not proper. A hardware (or software)
> implementation requires an extra pole with very fast settling time
> (relative to open loop
> poles and closed loop design poles).
>
With all due respect to A S Hodel, I will just note that my students
build and test this PID opamp circuit every year and then they model
it in "C" and so it is realizable. Also you can buy them off the shelf
for industry.
I'm well aware of such systems. I stand by my statement that (a s^2 + b
s + c ) / s is not
physically realizable, nor is any rational polynomial n(s)/d(s) where
degree(n) > degree(d).
Consider these observations:
- An op-amp has its own frequency response with a cut-off frequency
around 1e5 to 1e6 Hz.
It's a nonlinear circuit, but can be approximated by a pole (or
poles) deep in the left half complex plane.
- The idealized model (algebraic loop) typically used in sophomore
circuits classes is ok as
long as one works in telephone-frequency audio or lower frequencies.
- More details on op-amps and other microelectronic circuits and their
small-signal models can
be found in microelectronics by, e.g., (1) Richard C. Jaeger, (2)
Streeman, or (3) Sedra and Smith.
The dynamics of an op-amp (and, for that matter, ANY semiconductor
based circuit) is due in part
to the capacitance inherent in any p-n junction. My area of
expertise is control systems/numerical
methods, but my "lunch buddy" has been teaching microelectronics for
nearly two decades, so this is a
regular topic of conversation for me.
- d/dt is a borderline non-causal operation, since backward
differentiation (f(t) - f(t - delta) )/(delta)
doesn't work until delta is exactly 0. That is, a pure PID is not
physically realizable.
- Finally, the existence of a fast pole deep from a physical PID in the
left half plane (eventually)
will have an impact on a system's root locus, so a proper treatment of
a PID ought to include some
treatment of its behavior.
Now for the real question.
This conversion between tf zp ss representations is where the work
will be needed.
Would it be OK if we checked for proper form at the start of the
conversion and reported an error at this point?
This could be done. Conversions to and from state space often happen in
the process of doing
block diagram manipulations, e.g., sysgroup, sysadd, sysmult, etc.
After reading the many posts on how to handle empty matrices (0x0 is not
0 x n nor is it n x 0 ... etc),
I'm wondering what the "best" way to handle non-proper systems is. The
issues are speed and
numerical accuracy. I occasionally sacrificed the 2nd of these for the
first, e.g., sysmult( tf1, tf2)
just multiplies the two polynomials rather than doing a sysgroup,
sysconnect operation.
OR
Should we allow improper form for zp ss and tf and only do the
checking when we try and get a time space result ie. "step impulse
bode? rlocus?".
Bode(PID) (even if it's non-proper) should be fine. rlocus might also
work o.k.. However, this approach
will run into problems as outlined above. I think this needs to be dealt
with in a more comprehensive
fashion.
All that said, these are good questions. Other questions to ask
(they;'ve been on my mind for
several years, but I just haven't had time to address them):
- Since Octave now appears to be supporting cell data structures, should
the OCST be rewritten
to support MIMO tf and zp formats? Currently MIMO systems can only be
implemented in state space
form. If this is done, one wonders how to handle MIMO "minimal
realization" issues: for example,
since a PID is not physically realizable, how should one handle a
command like
minreal ( sysgroup (PID1, PID2, PID3) );
Normally, I'd go to state space and extract controllable/observable
subspaces, but that gets
lost here.
- Octave's OCST was written before either Octave of MATLAB had
user-defined data types (we
wrote most of it around 1993-1995), so it just uses a structure
variable. Octave has some ability
for user-defined data types in C++ class structures. MATLAB has
user-defined data types in
m-file form (a subject of occasional discussion in the octave mailing
lists). Is it worth the
effort to implement a linear system data type directly in Octave (or
octave-forge), then rewrite
the current toolbox to use the corresponding member functions, or
should we stick with the
current data structure?
- Octave's OCST was written to permit mixed sampled-data and continuous
time systems.
I did this to maintain compatibility with a NASA-internal simulation
tool that, as far as I know,
is no longer used (they've migrated to simulink in order to match
industry) and is export-controlled,
so it will likely not ever be made public domain. Is there any
reason to maintain "mixed" systems (continuous and discrete-time
states and outputs)?
- Should we change octave's OCST function names to match those of
MATLAB, where possible?
For example, one could use ss, zpk, tf instead of ss2sys, zp2sys, and
tf2sys. However,
unless we define a new data type, we're stuck with sysadd, sysmult,
sysgroup, sysconnect,
etc.
With all of these questions and the ongoing discussion/revision of
is_stabilizable, dare, etc.,
it sounds like the OCST is due for a revisit ... with due attention to
such references as
@article{lau85,
author = {A. J. Laub},
title = {Numerical Linear Algebra Aspects of Control Design
Computations},
journal = {{IEEE} Transactions on Automatic Control},
year = 1985,
volume = {AC-30},
number = 2,
pages = {97--108},
month = {February}
}
@book{patlauvan94,
editor = {R. V. Patel and A. J. Laub and P. M. Van Dooren},
title = {Numerical Linear Algebra Techniques for Systems and Control},
publisher = {{IEEE} Press},
year = 1994
}
etc.
A. S. Hodel, Associate Prof. Elect. & Comp. Eng., Auburn University