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

> -----Original Message-----
> From: Herman Bruyninckx [mailto:[email protected]]
> Subject: RE: [Orocos] Re: dynamics: comment about MBdyn...
> 
> [...]
> > Interesting, we have already talked (within the Modelica design
> > group) about the possibility of supporting impulses.  
> 
> Seems to be easy: since there is no real good model of mechanical
> impulse, any approach will do :-) I've seen real-time simulation of
> humanoid robots with tens of degrees of freedom, in which the user can
> give impulses, resulting in behaviour that _looks_ realistic. But
> isn't, because the impact model is arbitrary. (Or rather, too complex
> and with too many application-specific parameters.)

Keep in mind that in Modelica, we are not talking about a "model" of impulses or impact.  We are talking about mathematical impulses.  It is still up to the modeler to decide what the "model" is (e.g. coefficient of restitution, perfectly elastic, perfectly plastic, etc.).  The point is that they can express behavior that involves impulses (e.g. velocities changing value discontinuously) and the rest of the system will respond appropriately (i.e. compute the total instantaneous momentum transfer required to achieve the result and make sure that momentum was conserved by changing other velocities instantaneously).  This isn't just about mechanical systems, impulses are very useful in many domains (electrical systems, combustion, etc).

> > another level of "freedom" and these can be handled symbolically
> > rather than numerically.  The result is the ability to do things
> > like contact without (necessarily) having to deal with stiffness.

> No, using impact to do smooth contacts (i.e., constraints!) is not a
> good idea. Impact models are only good for "particle like"
> interaction, like in ODE (<http://opende.sourceforge.net/>).

Again, I'm not talking about a specific model, I'm talking about mathematical expressiveness.  I agree, you don't want to treat the interaction as strictly impact.  But, with impulses you might model the initial collision as a perfectly plastic interaction (no bouncing) and then switch to a mode where the two surfaces are constrained to stay together until the reaction forces become positive and then you switch to another model where they are free bodies again.  This is exactly how clutches are modeled except for the impulse part.

> [...]
> > > I think that the "problem" in Modelica lies with the
> > > fact that the connection information is decoupled 
> (erroneously so!)
> > > from the constitutive relationships and/or the constraints of the
> > > objects. And the processing afterwards to correct for 
> this decoupled
> > > information is (moderately) costly.
> > 
> > I'm not sure why you think this is really an error.  Keep in mind
> > that in Modelica all connections are constraint relationships.  If
> > your "connection" has behavior associated with it (e.g. elasticity)
> > then it isn't a connection, its a component.
> Right! What I meant with being "decoupled" is that the information
> about connections is in a separate place in the file, instead of being
> at the same block where the constitutive relationships are of the real
> physical body that one models. Having separate file positions for
> information that physically belongs together is asking for troubles; in
> this case, the troubles are the more involved processing of the model
> that has to take place: the processing has to find out what belongs to
> what, while a real "object oriented" model would keep this information
> together. A (good) XML schema would do this, for example :-)

I don't believe any of this.  Much of what you say is completely arbitrary.  There is far too much language in this discussion about the "right" way to do things or the "real" way to do things.  I really think you need to have more appreciation for the fact that designs bring with them plenty of aesthetics and other subjective influences.  No human endeavor is ever as clear cut as you always imply.

Furthermore, I still don't think your argument is at all compelling.  Each modeling model contains a set of declarations first and then zero or more equation and/or algorithm sections.  This is very much like the model you will see in Java and C++ where you have members (declarations) and methods (code).  So invoking arguments like "this isn't a real object oriented model" I think are just a waste of bits.

Finally, ignoring the comparisons with C++ and Java altogether, I think you need to give the people in the Modelica effort much more credit than you have.  I have no "pride" wrapped up in this particular point because all this was decided and formalized before I ever heard of Modelica.  But when you continually imply that the design of Modelica is "wrong" (meta-data, too much coupling, not enough coupling, etc), I think you not only fail to recognize that there is some level of inherent arbitrariness in any design but also that perhaps there are details of the decision making in the design that you are just not seeing.  Personally, I can think of several arguments to support the Modelica design and refute your notion that it is wrong, but I just don't have the time to get into it.

> [...]
> > 1) Annotations are exactly equivalent to XML (i.e. syntax +
> > structure - prescribed meaning).  As such, they are no better or
> > worse really.
> They are because there is no "schema" involved. 

There is a schema for the graphical annotations although I agree with you that in general there is not formal way of associating a schema with the annotations.  Within the group, the informal association uses record definitions (as you can see in the Modelica v2.0 specification).  I would probably support a proposal to optionally allow a formal association between record definitions and annotations.  Why don't you make a formal proposal?

> Herman

--
Mike