help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sys variables for control theory


From: A S Hodel
Subject: Re: sys variables for control theory
Date: Thu, 6 Nov 2003 22:54:25 -0600

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



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------



reply via email to

[Prev in Thread] Current Thread [Next in Thread]