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

> -----Original Message-----
> From: Klas Nilsson [mailto:[email protected]]
> Subject: Re: [Orocos] Re: dynamics: comment about MBdyn...
> 
> 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.

If I understand you correctly, you are really looking for a good
co-simulation harness to wrap around code generated from a declarative
representation of the model.  This seems like an excellent approach.  The
problem is that Simulink's "simstruct.h" or S-function interface is only a
de-facto standard for co-simulation (and not based on open source technology
either).  So to me, the open question is what would the co-simulation
interface be?  There is something called "DSBlock" that was developed at DLR
(http://www.modelica.org/DSblock/dsblock4.0a.shtml).  This is a potential
candidate.  I think this is what Dymola uses internally.

This is also an issue for me (having a nice standard co-simulation
interface) so I'd be quite happy to see someone pick this up and define a
co-simulation interface based on open source.  Ideally, I'd like to see the
appropriate interface definitions and maybe a crude implementation (at least
to act as a testbed for compliance).

One "gotcha" to watch out for is simultaneously co-simulating several
systems.  Where most of these systems fall down (in my opinion) is that they
try to apply co-simulation too finely.  In other words, they develop one
component model in one environment, another component in another environment
and then build a system by co-simulating the two components.  This is
problematic (especially in domains like robotics where DAEs are quite
common) because dealing with algebraic loops and Jacobians is a real
problem.

Co-simulation with control code is a completely different story because the
reality is that the controls almost always "co-simulate" with mother nature
anyway (i.e. there are no true algebraic loops *through* the control
system).

My advice: If you want to develop a harness for co-simulation of plant
models along with control, try as hard as you can to specify the entire
plant as one system and don't simultaneously co-simulate several subsystems
or 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.

Certainly.

> Still, the Modelica approach should not be used as 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).

Unfortunately, this is a self-fulfilling prophecy.  I'd still really like to
see a free tool that could do this but am seemingly powerless to convince
anyone to actually implement one.

> * 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..).

Quite possibly.  Keep in mind that Modelica has both imperative and
declarative semantics so it wouldn't be impossible, but I can certainly
understand that it may not be convenient to use Modelica in such cases.  I
have no problem with that.

> 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.

I've talked with some people at Scilab and they also have an interest in
Modelica.  Perhaps they would be interested in developing a co-simulation
harness as well.

> Bye, Klas

--
Mike