From: Richard M. <mu...@cd...> - 2011-06-18 01:02:15
|
Eike, I'm working on integrating some of the functionality that you contributed to the python-control package. Your new convention for simulation inputs and outputs has a lot of nice features, but it does "break" current code (eg, try running examples/pvtol-nested.py). In addition, it is not compatible with the way MATLAB or scipy.signal does things, which could be confusing. As a general principle, I think that if a user imports control.matlab, they should get as MATLAB like an environment as possible (since control.matlab is the MATLAB emulation module in the package). However, I see now reason why we need to maintain MATLAB compatibility within the underlying library itself, where we can do things in a more python-like way. But breaking the convention used by scipy.signal could get confusing... Here is one possible fix: * We move your current lsim, initial, step and impulse code into a separate module (timesim.py or something) in the control-python package. * We create version of the code in matlab.py that convert the arguments from MATLAB (and scipy.signal) form into the form you use, and back. * In addition, we could include a flag in all of the simulation routines that let them swap around the convention if the flag was turned out (eg, 'scipy-signal-convention = true' would make things work in the way that is compatible with the signal module). This approach has the advantage that we get a pretty clean interface for python users, but something that is consistent with MATLAB in the emulation library. On the other hand, it could be incredibly confusing for people who use both interfaces. Let me know what you think about this (others on the list as well). If we do decide to switch the way time series are represented from the current version, we would have to update the version number to something like 0.5a (instead of 0.4d) since we would be breaking existing code. -richard On 12 May 2011, at 16:11 , Eike Welk wrote: > Hello! > > I have written a patch for the Python Control Systems Library with the > following contents: > > * An implementation of the four simulation functions ``lsim``, ``step``, > ``initial``, and ``impulse`` of the module ``matlab``. > > * It also adds a function ``dcgain`` to the ``matlab`` module, which computes > the gain of a linear system for steady state and constant input. > > * The patch contains a bug fix for class ``StateSpace``, which enables it to > work properly together with Scipy's ``signal`` module. > > * The simulation functions' return values are changed (back?) to arrays, > because matrices confuse Matplotlib. > > http://sourceforge.net/tracker/?func=detail&aid=3301246&group_id=282523&atid=1198311 > > > Would you include my patch into the library? > > What do you think about the parameter convention below? IMHO a detailed > section that explains the used convention should be included in the module's > documentation. The documentation of the individual functions should link to > it. > > What is the proper communication channel for the library's developers? > > If you include my patch, my next step would be to extend ``lsim`` to MIMO > systems (by copying the code from ``scipy.signal.lsim2``); and to convert the > module's documentation to proper reStructuredText. > > > Implementation Notes > ------------------- > > The implementation is centered around ``lsim``, which checks the parameters > thoroughly, and generates useful error messages. It then calls > ``scipy.signal.lsim2`` to solve the differential equations. The other > simulation functions (``step``, ``initial``, ``impulse``) are small and call > ``lsim``. > > > Parameter Convention > -------------------- > > The new convention for parameters and return values harmonizes with the way > how the system equations are written. It can be generalized to MIMO systems, > and it also works well with Matplotlib: > > All parameters can be arrays, matrices, or nested lists. > > The time vector is either 1D, or 2D with shape (1, n):: > > T = [[t1, t2, t3, ..., tn ]] > > Input, state, and output all follow the same convention. Columns are different > points in time, rows are different components. When there is only one row, a > 1D object is accepted or returned, which adds convenience for SISO systems:: > > U = [[u1(t1), u1(t2), u1(t3), ..., u1(tn)] > [u2(t1), u2(t2), u2(t3), ..., u2(tn)] > ... > ... > [ui(t1), ui(t2), ui(t3), ..., ui(tn)]] > > Same for X, Y > > The initial conditions are either 1D, or 2D with shape (j, 1):: > > X0 = [[u1] > [u2] > ... > ... > [uj]] > > So, U[:,2] is the system's input at the third point in time; and U[1] or > U[1,:] is the sequence of values for the system's second input. > > As all simulation functions return array plotting is convenient:: > > t, y = step(sys) > plot(t, y) > > The output of a MIMO system would be plotted like this:: > > t, y, x = lsim(sys, u, t) > plot(t, y[0], label='y_0') > plot(t, y[1], label='y_1') > > > Yours, > Eike. > <make-matlab-work.patch> |