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

Herman Bruyninckx <[email protected]>
Newsgroups gmane.science.robotics.orocos.user
Message-ID <Pine.LNX.4.44.0307152153510.3379-100000@srv04.mech.kuleuven.ac.be>
On Tue, 15 Jul 2003, Tiller, Michael (M.M.) wrote:

[...]
> 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 certainly a candidate, in the sense that it captures the
required information. But I think defining the "software classes" to
which these descriptions have to translated in the important thing;
there must be translators to various forms of these descriptions
(i.e., XML, Bond Graph, graphical editors, etc.)

BTW, what do you mean with the "co" in "co-simulation"?
And with "harness" in "a harness for co-simulation"?

> 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.
Aren't these problems to be solved via the "symbolic processing" we
discussed about? (I mean: are there any _other_ possibilities to solve
these difficulties than symbolic processing?)

> 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).
Can you elaborate on this a bit more, please?

[...]
> > * 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.

You're doing a good job :-) But we will have to wait some more: as I
say very often, open source is not very good at coming up "out of the
blue" with designs for complex systems (unless the design is clear
from closed systems to which many developers have access). So, I hope
these Orocos discussions will eventually result in a clear enough
design that somebody will make a prototype for in a months or two...
All it takes is somebody with a good student to get things going.
(And I know most professors do not yet have the reflex to let their
students look around for free software projects to help out in this
way. Everybody would gain, I think.)

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

I think the existence of FSM and events in Modelica are enough to cope
with all these "hybrid" things.

[...]
> 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.
> 
Of course there are many people on their mailinglist with this
interest. We should be able to connect to them one way or another.
(There does remain the license problem with Scilab: it is _not_ open
source; an insider told me that it's one single authorative person
within INRIA that is keeping all their software from being open source...)

Herman

-- 
  K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.