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