RE: Design draft for kinematics/dynamics library...

On Mon, 12 May 2003 [email protected] wrote:

Thanks for your feedback! (But don;t forget to put your name in the
posts: our very strict anti-spam procedure removes your complete
email-identity...)

[...]
> 1) You talk about the difference between "users" and "developers"
> and later on about "Library structure decoupling".  One of the
> design goals in Modelica was for model developers to be able to
> encapsulate the details of their models such that end users do not
> need to worry about implementation details.  Modelica has been, in
> my opinion, very successful in this regard.  Furthermore, you
> mention "interfaces" as well.  This "interface" concept is formally
> defined in Modelica and allows, for example, two components with the
> same interface to be substituted.
Indeed. Modelica is nothing else but interfaces, I would say. (And not
too bad ones at all, I agree on that.) Of course, it is also the "file
description" of the models and the interfaces. So, I have no problem
with people using the Modelica syntax for model description. However,
Modelica does not provide code, and as far as I can see, there is no
intention of doing so. Therefore we _have_ to go ur own way. Without
compromising the possibility of exporting/importing information in
Modelica-format.
The big difference between Modelica and my design is that the latter 
focuses on the _software engineering_ aspects, and Modelica only on
the modelling. Both are complementary, of course.
Another difference is that we need a much larger set of geometric
primitives; for example, I don't think that Modelica will want to
include the concept of logarithm and exponential of position and
velocity, respectively.

> But, I'm a bit confused
> between your description of "Objects" and "Connector" because it
> seems to me that a revolute joint (as a motion constraint) should be
> in "Connector" but you list it as an example of an object.  
Wait, there might be some confusion here: Object-Port-Connector is the
modelling paradigm in which one makes a distinction between these
three sort of "things". In the section where I place the revolute
joint as an object, I still talking in gneral, and not specifically
for dynamics. For example, a revolute joint can be a _graphical_
building block that can be connected to a link, and as such has ports
itself that can be connected to the ports of a link. All these ports
being graphical entities.
When speaking in the context of dynamics, "revolute joint" indeed
means a _constraint_ on both objects (rigid body links).

This is also an example of where the scope of my design is much
broader than that of Modelica.

> Finally, what you call a "Port" is what is typically
> called a "connector" in Modelica.  
I know. And I think this is a istake of Modelica! An element to which
things can be connected is _not_ a connecTOR, because this latter word
expresses an _activity_, while the port is a passive entity. Mayeb
this might sound overkill to you, but it is again a sign that the
_software engineering_ is not of a too high level. (I hope my
suggestions will ultimately be of a higher lever, but I am not so
sure of that :-)


> 4) You mention the ability to couple components from different
> domains (what you call "Multi-domain flexibility).  This is one of
> the main reasons why we chose to use Modelica within our group.  To
> see an example of how this multi-domain functionality can be used in
> Modelica in conjunction with a robotics example, you might want to
> download the demo of Dymola and look at the "Demos->Robot" example.
I know this. Of course. You don't have to convince me that a thing
like Modelica is useful: I am more than convinced of that. I repeat
what I miss in Modelica: the explicit software engineering focus.

> 5) Your discussion of Object-component decoupling is, as far as I
> can tell, not covered in Modelica although I think it is there
> implicitly.  

Probably it was there _implicitly_ too when Matworks made Simulink :-)
My experience and conviction is that you get non-distributable code if
this decoupling isn't there _explicitly_. 


> 6) Under "Geometry", many of the object and data types you describe
> are present in the Multibody systems library (e.g. frames, vectors,
> orientations and rigid bodies).
Many. But not at all all the ones one really need in a general-purpose
robotics system.

> 9) In Section "6", you talk about "Generic dynamical systems in the
> mechanical domain".  Again, you talk about the concepts of "Object,
> Port and Connector".  These are the same goals, concepts and ideas
> behind Modelica (although the scope is broader than mechanical
> systems).  Formulating a way of describing this kind of behavior in
> a generic way is, in my opinion, very hard.  All I can say is that I
> would encourage you to leverage all the work that has been done by
> people from a variety of domains in coming up with the details
> included in the Modelica specification.  
I think I did :-) At least, as far as I know, and as far as people
have published their ideas. You seem to suggest that I am reinventing
the wheel and don't know about developments such as Modelica... That's
not at all true :-)

> Keep in mind that *I*
> didn't play any significant role in the development of the Modelica
> language so I'm not boasting here.  I'm just trying to point out
> that I think they did a great job and that is exactly why we chose
> to adopt it.
You adopt it to do what? Modelling? Okay. Software implementation? I'm
not so sure about that... But if I _had_ to choose one project to base
my developments on, I would choose Modelica too!

> 10) A general comment:  In looking at your proposal, it appears to
> me that what you are interested in doing is developing some kind of
> C++ framework for modeling robot systems.  
Indeed. And with a little more effort, many of these things should be
resuable in other than robotics domains too.

My experience (I
> developed a C++ framework for Finite Element Analysis and
> Sensitivity Analysis as part of my Ph.D.) is that while it is
> possible, there are significant gains to be made by working at a
> higher level.  Modelica really allows you to distill the problem
> down to the important elements (physical interfaces, DAEs, etc)
> without being constrained by what is possible to express easily in
> C++.
I'm not at all bound to C++, though there is no alternative at this
moment if you want to use the library in real-time control too...
And I see no reason why these "higher levels" are not compatible with
C++ implementations?

[...]
> I can see there is a difference between modeling and control, but I
> was commenting mainly on your proposal and I didn't notice anything
> on your web page about controls.  
Uh? Our project is called "Open Robot CONTROL Software", so the focus
on control should be obvious :-)

> My guess is that what you are looking for is
> perhaps a way of describing state charts or perhaps a general
> discrete event modeling system.  
This is indeed one of the components that we need.

> I completely understand your position here...but, I think you
> misunderstand the situation.  The Modelica Association (the group
> responsible for developing the Modelica language) is *completely
> open*.  You can download the specification for free of the web site,
> you can download the Modelica standard library and the
> ModelicaAdditions libraries from the web site (both are distributed
> as open source...hosted on SourceForge).  Going even further, all
> conference and workshop proceedings are available for free on the
> Modelica site.  Finally, anyone wanting to attend a Modelica design
> meeting would be happily accepted.  I am quite confident that there
> is no way that the Modelica Association could be any more "open".

Well... I get a different impression when I read things like "The
Modelica Association owns and administrates incorporeal rights related
to Modelica, including but not limited to trademarks, the Modelica
Language Specification, Modelica Standard Libraries, etc., which
should be generally available for the promotion of industrial
development and research."
I even have no clue how far "incorporeal rights" go...

[...]
> implementations are created.  Speaking as the Secretary of the
> Modelica Association, I can tell you I would be THRILLED to have an
> open source implementation of Modelica and I have been lobbying many
> people behind the scenes to produce such an implementation.
I will try to make a FP6 proposal for a follow-up project of Orocos,
with the whole control scope as focus, not just robotics. And such a
tool would be part of that proposal :-)

> All that being said, you should be aware that there is a group at
> Linköping that is developing something they are calling "Open Source
> Modelica".  

I have been in contact with them, some time after they presented this
idea on one of the Modelica meetings. But nothing has come out of
these contacts. Some weeks ago, I tried to find some more information
but found nothing... I would be very interested to learn that they do
continue :-)

> I cannot claim Modelica addresses everything you want to do already.
> My point is that much of what you are describing has taken the whole
> Modelica group over 6 years to get where it is (which is not, in my
> opinion, complete).  I'm just suggesting that you leverage what
> already exists so you can focus on the things that don't yet exist
That's exactly what I tried to do: I think that there is nothing in
Modelica that I don't cover also. But I paid more atention to the
software engineering, and not just the modelling.

Herman Bruyninckx

-- 
  K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480