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.

Just to be clear, Modelica allows you to describe the behavior of components
with equations and algorithms.  Furthermore, you can write functions in
Modelica.  It may not be sufficient if you are developing embedded control
systems, but it still seems like it could compliment what you are trying to
do.

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

But what you describe in that document seems to me to be almost exclusively
on the modeling.  I get the impression from reading your "Object-component
decoupling" section that you think the software engineering should be
completely decoupled from the physical representations.  But on the other
hand, much of what you talk about seems to be in building in domain/problem
specific details into the underlying framework (something that is quite
explicitly *not* done with Modelica implementations).  I guess that leaves
me a little confused still about where the boundary between software
engineering and modeling really exists in your proposal.

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

I'm still not clear why this is an issue.  In Modelica, the only built-in
types are "Real", "String", "Boolean" and "Integer".  All other types are
derived through inheritance from these.  So if you want to define a data
type for the logarithm of position, you can do it easily enough as:

type PositionLogarithm=Real(quantity="Logarithm of position", unit="...");

model Robot
  PositionLogarithm origin[3] "A vector containing the log of position";
  ...
end Robot;

You can define functions and complex data structures in Modelica as well in
order to represent other aspects of your proposed framework.

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

I figured that is what you meant.

Now that you mention graphics, I would point out that this is yet another
area of Modelica that you could potentially leverage since the specification
includes a description of how graphical annotations should be specified.
Furthermore, the graphical annotations are just a special case use of the
general purpose annotation system for handling meta-data within your model
(which might also be useful to you).

> > Finally, what you call a "Port" is what is typically
> > called a "connector" in Modelica.  
> I know. And I think this is a mistake 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.

The funny thing about vocabulary is that one person thinks a given name is
appropriate while another person thinks it isn't.  We see this in the
Modelica Association at every design meeting.  We always joke about the fact
we all agree on the need for certain features, we all agree on the semantics
of the feature (i.e. it should work like this...) but we spend the majority
of our time trying to come up with appropriate names.  This is quite a
challenge (especially when dealing with several engineering domains because
each has its own vocabulary).  Personally, I think "connector" in Modelica
is completely intuitive.  You are free to disagree, but recognize that is
isn't quite so cut-and-dry.  You seem to be advocating the "connector" is a
verb or perhaps as a noun used to describe something that does the
connecting, while I would argue it fits perfectly with concept of a passive
entity because I think of it as a noun describing an object (e.g.
http://dictionary.cambridge.org/define.asp?key=16251&dict=CALD).

> Maybe 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 :-)

This seems like a value judgement and it isn't clear to me what school of
thought you are using as the basis for such a judgement.  In my experience,
vocabulary is a very arbitrary basis for making judgements like this.

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

We may be arguing at cross-purposes here.  In terms of practical modeling
with Modelica, I think of the process as a two step process.  First, there
is the process of reading in the Modelica model and applying all the
semantics of the Modelica language.  The next phase is taking the results of
that semantic analysis and finding a way to solve the underlying behavior
described in the model.  This is rather abstract so let me be a little more
concrete.  What many people don't realize about this is that the "result"
from the first phase is not a description of the underlying components and
how they are connected together (as some might think), but rather a
"flattened" system of hybrid differential-algebraic equations.  By the time
you are ready to enter the second (solution) phase, the problem is no longer
described in physical terms but in mathematical terms.  I'm not saying this
is the right way or the only way to do things, I'm just saying this is how I
think of it and this is probably the easiest way to approach solving
problems with Modelica.

I mention all this because you are emphasizing the software engineering
aspect and it seems to me that the software engineering plays a major role
only in the second phase whereas the web page I was commenting on seems to
be describing larging the physical domain details.

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

I don't follow you here.  It seems to me that you are implying some sort of
inherently proprietary component to this approach.  If so, I don't see the
connection.  If not, I don't know what you are getting at.
 
> > 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.

Sure, but the Multibody systems library is not the Modelica language.  It is
an example of a library written in Modelica.  I'm just saying that the
Multibody system library is an example of how to do robotics and a
demonstration that much of the kinds of things anyone would do in robotics
are supported by the language.  While you may not be able to get by with
strictly extending the existing library, I suspect you could reuse quite a
few ideas and definitions.  I'm just trying to point out that the Modelica
language allows you to describe these things.

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

Yes, modeling.  Writing software in Modelica itself isn't really a practical
option (at least at this point in the language development).

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

The best example I can think of as an issue that I used to wrestle with all
the time was capturing the symbolic information about the problem.
Specifically, I wanted to capture the mathematical structure of the problem
to the point where I could get important symbolic information out (to
support things like dependency analysis and symbolic differentiation).

What I found was that I could use lots of C++ tricks along with operating
overloading, etc. to create a symbolic data structure from C++ code.  But it
took lots of work to cleverly craft such a system, it wasn't that natural
for model developers (who needed to understand some of the details about
these C++ tricks) and it ended up being horribly slow.

As I pointed out earlier, in Modelica the implementation phase (the second
phase) would deal with the mathematical structure of the problem, not with
the physical structure.  In other words, once you get to the implementation
stage in a Modelica project, you wouldn't think of it as an implementation
for robot systems but as an implementation for processing hybrid DAEs.  The
point is that the C++ framework would not resemble the physical problem
domain (i.e. robots).  This seems very much inline with your
"Object-component decoupling" principle.

> [...]
> > 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 :-)

Yes, fine.  But since the abstract of your proposal specifically covers
"kinematics and dynamics of both simple and advanced mechanical motion
systems: (i) basic mathematical concepts and representations that are
relevant to motion modelling and specification", I was commenting on the
modeling.

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

This is an area where only a little work has been done in Modelica.  Other
groups I know of have adopted UML for activities like this.  While Modelica
allows you to express discrete event behavior, it isn't clear to me that you
would necessarily want to apply it to embedded systems (if that is your
goal).  It may even be necessarily to capture this kind of behavior with
some higher-level modeling formalism specifically for state charts, etc. and
then have a way of exporting it as Modelica code if you want to integrate it
into a model of a system.  These are interesting topics and represent an
area where the Modelica Association would be interested in
feedback/participation.

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

All that is saying is that we protect the rights to the name so that another
company cannot come along and assume control of all software/projects using
the name.

You might take issue with the legal verbiage but it doesn't change the fact
that the Modelica libraries are distributed under a license that starts
"Redistribution and use in source and binary forms, with or without
modification are permitted, provided that the following conditions are
met:..." and the conditions are very similar to conditions used for most
other open source licenses.

The reality is that these kinds of legal protections are necessary to avoid
predatory business practices.  Eric Raymond tried, unsuccessfully, to
trademark the term "Open Source" (for exactly the same reasons!).  We spent
a huge amount of money to get those protections in place (money I would have
much rather spent on other things like development of more open source
libraries) to protect users of the Modelica name only.  The goal here is to
prevent a hostile third party from coming in at some later point after we
have several Modelica tools and disrupting the market by claiming the name.

Honestly, I don't think it is really fair to claim that we aren't "open"
based on the language you are quoting.  Look at OMG, they do the same thing
(and I don't blame them).  You don't have an issue using CORBA even though
the OMG has *pages* of legal verbiage (e.g. "OMG Members and others with
permission may use OMG's trademarks and logos strictly in accordance with
these Guidelines. Use of OMG trademarks and logos other than in accordance
with these Guidelines is a violation of OMG's rights and is strictly
prohibited. OMG reserves the right to revise these Guidelines from time to
time, without notice.")

If you judge us by our actions, I cannot see how you could fault us.

> [...]
> > 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 :-)

I'll tell you the same thing I'll tell everyone I talk to about creating a
tool based on Modelica (open-source or commerical).  "If there is anything I
can do to help, let me know."

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

Well, you and I have had the same problem.  But, they came through last week
and delivered an alpha version of their software.  The biggest benefit of
the software (for me) is the ability to handle the first phase of processing
(i.e. getting the "flattened hybrid DAE" information out).  Try contacting
them again now that they have something.

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

I guess I'd be more satisfied if you used the language itself.  The idea
behind starting the Modelica effort was to stem the proliferation of
modeling languages/tools that all used very similar concepts.  That was the
spirit of the project.

Ultimately, the choice is yours and I will respect whatever you decide to
do.  My point in this discussion is really just to make it clear that I
think that Modelica compliments what you are doing and to give you a point
of contact in case you are interested in pursuing that.  I really don't want
to spend any more time debating the issue (although I will always be happy
to answer specific questions anyone might have).

Good luck in whatever you choose to do.

> Herman Bruyninckx

--
Michael Tiller