Re: Re: dynamics: comment about MBdyn...

Michael, thanks, very good comments; I completely agree with you!

All, what about having orocos components (and library modules) that are to be 
filled in by the output from code generation from Modelica models (e.g. by using 
Dynola or similar tools). Such a component would need to provide the internal 
structure needed for runtime evaluation (compare with simstruct.h for simulink), 
and the execution framework provided by orocos would need to be modeled in 
modelica (events in modelica corresponding to the events triggering orocos 
control samples, etc.) but that should be very few lines of code. Then the 
modelica models would encapsulate symbolic (in the model-declarative sense, not 
to be confused with the so called symbolic properties of objects in orocos which 
I think is only meta-information about software objects) information concerning 
dynamics/kinematics/.., and symbolic tools like Maple and Dymola could be used 
for manipulation&optimization of symbolic components into subsystems and 
executable orocos components.

 From a project point of view, developing hand-written components as being done 
today could still be the best starting point, but supporting generation from 
Modelica opens new possibilities for design-time and compile-time compositions. 
Still, the Modelica approach should not be used a a foundation for orocos, for 
two reasons:
* There are no free tools, and no good such tools as Dymola can be expected 
within the next years (to build one orocos library/module once you need one 
license, and to do symbolic optimization of subsystems you also have to pay).
* Flexible or intelligent control systems need a dynamically on-line changing 
structure, including a lot of code that are not very suitable to express in 
Modelica, that does not fit with the declarative nature of Modelica (unless you 
want to embedd Dymola in your system..).

Also from Scilab (the only free tool I know that includes features corresponding 
to simulink) generation of orocos components would be desirable (to comply with 
the same execution interface as from Modelica), but for the case of composing 
control blocks internally expressed in imperative form, thus preserving the 
model/design structure during execution.

Bye, Klas

PS
Note that in the two cases (Modelica and Scilab) above, composition cannot 
result in components damaging data (or code) for other components, but if the 
user writes application code in e.g. C/C++ anything can happen. Hence, 
scalability is limited. That is why orocos also need a real-time Java (or in any 
other accepted compiled safe programming language without constructs preventing 
hard real time) programming interface, but that is another story. DS
-----------------------------------------------------------------------
    o--<    mail: Klas Nilsson, Department of Computer Science
     \      Lund Institute of Technology, Box 118, S-221 00 LUND, Sweden
      O     phone: +46-(0)46-2224304 (work), +46-(0)46-370160 (home)
+->>[_]    mailto:[email protected]   http://www.cs.lth.se/~klas
|
+-------<< Real-time << components << control << users << languages.