RE: Modelica

Herman Bruyninckx <[email protected]>
Newsgroups gmane.science.robotics.orocos.user
Message-ID <Pine.LNX.4.33.0107301800110.7655-100000@pc25-213.mech.kuleuven.ac.be>
On Mon, 30 Jul 2001, Tiller, Michael (M.M.) wrote:

[...]
> My area is not robotics so I am not really familiar with the
> existing tools in this area or the existing specification formats.
> I would point out that Modelica includes a very nice feature called
> "annotations" that allow you to embellish a Modelica description
> with additional details that are tool specific.
>
> Because this is not my area, I am struggling to understand what the
> deficiencies are.  Do you have a "design objectives" document
> anywhere that describes, in a broad sense, what you hope to achieve
> with this project?

First of all, I appreciate your critical comments very much! I would
like to see more of these all other aspects of the project. Because
the project is exactly in the stage of making the "design objectives"
as clear and general as possible. Up to now, I've made this design
`document' on-line on the website at <www.orocos.org>, but I got almost no
feedback and critical comments from others :-)

So, back to the real subject of the message: your remarks about Modelica
represent my personal questions and uncertainties quite well too (and
that of most others, I think): what exactly can Modelica bring us?
What exactly are its deficiencies? (If any.) What exactly is
available/needed/desirable as computer tools to work with Modelica?

I don't have enough hands-on experience with either Modelica, Dymola,
20sim, or other relevant tools and languages to have an authorative
opinion about these matters :-)

About your XML comments: I didn't say it explicitly, but, of course,
raw XML is not really what I would like to have users program in :-)

The advantages of XML are what you mentioned: standardized language,
with lots of tools for all possible platforms.

So, I thought it would be worthwhile to have a robotics XML DTD
(Document Type Definition, i.e., a specification of what is
expressable in a certain XML language, and what rules the language has
to obey; I have some links to existing efforts in this area on the
orocos web site). This robotics XML language would be the
configuration/modelling/specification language of Orocos, but only on
the implementation level; i.e., for use between software agents, not
between humans, or between a human and the software.

In addition, modelling of the dynamical system is only an (important)
part of the robotics language, but not everything. So Modelica will
most probably not be able to cover all our needs (for example:
trajectory generation specification; configuration of software
components; ...).
This is not an inherent shortcoming of Modelica, of course, but since
we need more than what is offered by Modelica, I thought it would be
wise to try to come up with a totally XML-based language. Anyway, for the
modelling part, an interface to Modelica is useful/desirable.

Of course, Modelica's annotation feature allows to integrate
``everything'' into the language, but this will soon become a mess, I
think, so I would avoid using this feature if possible.

I am open to discussion!

> As I pointed out in a separate message, it would be possible to
> serialize the AST from a Modelica parser into XML (actually, I know
> of a group that is already attempting to do that).  That being said,
> I think that approach is somewhat awkward.  It is not clear to me
> why XML is so important for this project.

My motivation is: it is a good and _real_ standard that is well
supported, and that has all features for the modelling, specification,
control, sensing, planning, ... needs of the project. Nothing more.
But also nothing less.

> Is there some absolute requirement that all details be written in XML?

No! As I explained above, I see its use mainly (only) at the `hidden'
layers of the project; certainly not in the user interfacing.
But having a DTD allows for quick checking of (formal) correctness of
data, which is a valuable, although minimal requirement for the
consistency of an orocos system.

> I understand it is easy to parse and there
> are many tools available, but it seems to me that an "absolute"
> requirement would ignore the fact that it would have to be weighed
> against the existing tools and intellectual content of existing
> specifications.

I agree. And this is one of my motivations too: try to reuse what
exists, after a critical discussion of the costs and the benefits.
It would be nice if we could come to some (preliminary?) conclusion at
the orocos meeting...

Herman

-- 
"I decry the current tendency to seek patents on algorithms. There are
 better ways to earn a living than to prevent other people from making
 use of one's contributions to computer science."  D.E. Knuth, TAoCP 3
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.