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

> On Fri, 9 May 2003 [email protected] wrote:
> 
> > As far as I can see from what you have put together almost everything you
> > are talking about has already been accomplished in Modelica.  I could be
> > wrong of course, but that is my impression from looking at the site.  I'm
> > more than happy to discuss the details if you think that my impression is
> > incorrect.  If my impression is correct but, for some reason, Modelica
> > doesn't meet your needs so you feel the need to embark on this kind of
> > project, I'd also be interested in hearing why you think it doesn't meet
> > your needs.
> > 
> It would be more useful (and fair) if _you_ explained why Modelica
> covers everything already :-) 

Fair enough.

Caveat: I'm not an expert in robotic systems and that is why I was sincerely asking you what you felt was missing.

OK, now I'll present the things that appears (in my quick glance at your site) to be very similar to what is already available in Modelica:

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.

2) You talk about "Semantic Decoupling".  This is present in Modelica almost exactly as you describe.  Modelica allows includes sets of primitives that allow you to describe the objects and connections (instantiation and the "connect" command), another set of semantics for allowing you to association physical meaning (type definitions with physical units, connector definitions, etc).  Ultimately, what you call the "Numeric" aspect is completely independent of the first two and is a tool dependent issue unrelated to the description of the model physical and topology.

3) For "Inter-connection" decoupling, these same concepts exist in Modelica but with different names.  For example, in the Multibody library in Modelica (http://www.modelica.org/library/ModelicaAdditions/docu/ModelicaAdditions_MultiBody.html) what you call "Objects" are called "Parts".  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.  Also in the Multibody library you will find library of "Joints" that seem to correspond to your "Connector" object.  The terms "Parts" and "Joints" from the Multibody library are terminology specific to that library.  Finally, what you call a "Port" is what is typically called a "connector" in Modelica.  In summary, the mapping is "Objects->ModelicaAdditions.Parts", "Ports->connector", "Conn
 ector->Joints".

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.  Along with the mechanical multibody aspect of this model the example also includes detailed models of the underlying control system and electric circuits.  In case you don't want to bother with the demo of Dymola, here are the links directly to the interesting subsystems I mentioned:

http://www.modelica.org/library/ModelicaAdditions/docu/ModelicaAdditions_MultiBody_Examples_Robots_r3_Components.html#ModelicaAdditions.MultiBody.Examples.Robots.r3.Components.MechanicalStructure

http://www.modelica.org/library/ModelicaAdditions/docu/ModelicaAdditions_MultiBody_Examples_Robots_r3_Components.html#ModelicaAdditions.MultiBody.Examples.Robots.r3.Components.Motor

http://www.modelica.org/library/ModelicaAdditions/docu/ModelicaAdditions_MultiBody_Examples_Robots_r3_Components.html#ModelicaAdditions.MultiBody.Examples.Robots.r3.Components.Control

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.  Because all current Modelica tools have no mapping of components to objects (in other words, they implement only Modelica components and never any C++ code), there really isn't a way for such coupling to appear in the first place.

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

7) You mention "1D", "2D" and "3D" formulations.  In Modelica, there is a different library that supports strictly 1-D mechanical systems (both translational and rotational).  The Multibody library allows those kinds of components to be inserted into revolute and prismatic joints so that you don't have to create a 3D revolute joint with backlash but can instead simply include a revolute joint and the put the 1D rotational backlash component in parallel with the revolute joint.

8) In Section "5.3" of your document you mention one particular architecture "Serial6Joints".  I mentioned the robot example in item #4 above.  If you download the demo of Dymola and look at the example, you will see that it is a "Serial6Joints" architecture.

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

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

> Seriously though:
> - Just tell me where I can find any serious motion generation
>   in Modelica, or kinematic family functionality

I'm not sure exactly what you need (I'm not a robotics person so while the exact functionality may be clearly conveyed to most people by your terminology, I can only speak to its superficial meaning).  The ModelicaAdditions library defines a range of components like reference frames, parts and joints along with the physical connector definitions used between these elements.

> - there is a difference between supporting the _modelling_ of systems
>   and offering a _control system_ for them. Modelica has, as far as I
>   know, no serious robotics-oriented control vision, above the
>   "Simulink" level.

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.  Modelica supports modeling of systems defined using Hybrid DAEs.  This allows you to model such diverse systems as digital circuits, Petri nets, Z-domain transforms, etc.  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.  Perhaps you are even interested in integrating embedded control into your robotic simulations.  In any case, if you elaborate I could certainly try to address this.  I'm not trying to be difficult, I just don't know what kinds of functionality you need in robotic control.

> - but the real reason I am (more than) a bit shy to commit to Modelica
>   should be obvious: Modelica has shown very little interest in
>   becoming an open source activity.

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

But, I know that this isn't exactly what you are getting at.  What you want are open-source **implementations** of Modelica.  Keep in mind that the Modelica Association has no more control over whether anyone creates an open-source Modelica implementation than the C++ standardization committee can control what happens with gcc.  Each group only has the power to dictate what the language is now what 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.

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".  Furthermore, I'm currently attempting to build an alpha version of it on my machine right now.  What the exact license will be for this software, I cannot tell you.  All I can tell you is that I have heavily lobbied this group to make the software available as "open source" and they seem to have agreed.  I can put you in touch with them if you like.

CONCLUSION
----------

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 and I'm willing to help you identify that boundary if you are interested.

> Herman

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