RE: Modelica

> From: Herman Bruyninckx [mailto:[email protected]]
> Subject: RE: [Orocos] Modelica
> 
> 
> 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?


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

If you can provide me with more detail about what it is you would like to do, I can attempt to provide you with additional information about how those details may be related to Modelica.

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

One way you might be able to integrate Modelica models into such a system would be to simply refer to the models and elements by name from XML.  For example:

// Recording details of a simulation carried out...
<simulation>
  <model name="MyRobots.Experiment1.MinimumPower"/>
  <CPU type="PentiumII" time="43" units="seconds"/>
  <version_info>  // Record which version of which files were used
    <version number="1.3" file="package.mo"/>
    <version number="1.3.3.2" file="MyRobots/package.mo"/>
    ...
  </version_info>
</simulation>

Or

<task type="optimization">
  <model name="MyRobots.Experiment1.MinimumPower"/>
  <design_variable name="robot.arm_length" min="0.1" max="1.0" init=".5"/>
  <design_varaible .../>
  <objective type="minimize" name="max(robot.arm.current)"/>
</task>

In these examples, only references to the Modelica models are used (names of models, names of parameters).  This is an example of using XML at the top level to provide all the necessary associations (which XML is a natural choice to do) without necessarily using XML as the native representation for the detailed and domain-specific content.

A tool reading this XML may not care about the actual contents of the model "MyRobots.Experiment1.MinimumPower" but if they do, there is nothing that prevents them from using a Modelica parser to extract additional information about that model.

My suspicion is that you deal, in robotics, with many of the same issues that we deal with in powertrain modeling and simulation.  Issues related to organizing data, describing complex analyses, integrating different simulation tools, etc are quite difficult.  The problem I see with trying to encompass all of this with an XML schema is that I would be concerned with the resources necessary to recreate all the intellectual content of the various existing pieces (e.g. Modelica).  Obviously, this has to be weighed against the awkwardness of using/creating a patchwork of existing tools and technologies which are not very coherent when "integrated".

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

Agreed.  I did not mean to imply it would solve all of your problems.  However, in my opinion a carefully constructed framework involving a few well delineated standards/specifications would be superior to a completely seamless framework that had to be developed to encompass a wide range of heterogeneous entities.

> 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 tend to agree that too many annotations would be a mess.  But, let me play devil's advocate for a moment.  At its core, XML is a means for providing structured data and validating it.  I would like to point out that Modelica has a restricted class called a "record" which is slightly more flexible than a struct in "C".  Let me demonstrated an analogy between Modelica and XML.  Imagine you had the following XML code (remember, I know nothing about robots...):

<robot type="Welder" name="welder32">
  <base>
    <coord x="3.2" y="5.5" z="0"/>
    <material name="steel"/>
  </base>
  <joint name="j1">
    <coord x="3.2" y="5.5" z="0"/>
    <material name="steel"/>
  </joint>
  <joint name="j2">
    <coord x="5.5" y="17.2" z="-2.5"/>
    <material name="steel"/>
  </joint>
</robot>

I am not up on my DTD syntax and I gather than in the XML world there are now at least two accepted was of specifying schemas.  So, let me just "say" what the schema for my example is.  Imagine that you have a type called a robot and that each robot has exactly one base and multiple joints (ignoring completely what connects the joints).  Both the base and the joints and coordinates and a material associated with them.  I could describe a parallel schema in Modelica as follows:

record Part "A generic robotic part"
  Real coords[3] "Coordinates";
  String material "Material used in construction";
end Part;

record Base "A part used specifically as the base of a robot"
  extends Part;
end Base;

record Joint "A part used specifically as a joint in a robot"
  extends Part;
end Joint;

record Robot "A robot and what it is composed of"
  String type "What type of robot is this";
  String name "What is the name used to refer to this particular instance";
  Base base "Information about the base";
  Joint joints[:] "Information about the joints";
end Robot;

Think of this as a "schema" in Modelica.  The strings here are used optional and can be used to provide a more thorough explanation of a particular element.  In Modelica, you can create named instances of these records as in:

record MyPart
  extends Part(coords={3.2,5.5,0},material="steel");
end MyPart;

Or, you can just express a particular robot as a series of (anonymous) modification/specializations on the base robot type:

record MyRobot
  extends Robot(type="Welder",name="welder32",
                base(coords={3.2,5.5,0},material="steel",
                joints(coords={{3.2,5.5,0},{5.5,17.2,-2.5}},
                       material={"steel","steel"}));
end MyRobot;

This gives you the structured data and validation capabilities.  I just point this out as an example, not to advocate it for your particular application.  In addition to the baseline XML capabilities, Modelica has some unique capabilities as well.

First, it is clear from the data what the types of the elements are (i.e. not need to look back at the schema to find out whether something is a real or a string).

In addition, Modelica has fairly elaborate array specification syntax which is quite convenient.

Finally, Modelica has a mechanism for redeclaring/replacing components and types.  The best thing I can compare this to is the "template" system in C++.  Extending the example above, you might define some addition records of the form:

record WelderBase
  extends Base;
  Boolean has_GFI "Has a ground fault interrupt circuit";
end WelderBase;

If I were to define an alternative Robot "template" like this:

record Robot "A robot and what it is composed of"
  String type "What type of robot is this";
  String name "What is the name used to refer to this particular instance";
  replaceable Base base "Information about the base";
  Joint joints[:] "Information about the joints";
end Robot;

I could then create a more specialized version of "Robot" as follows:

record WelderRobot
  extends Robot(redeclare WelderBase base);
end WelderRobot;

In other words, the "base" component in the "Robot" record above is template-ized so that I can create variations of it easily without have to retype everything.

I mention most of this because I think most of the Modelica Association probably agree that issues related to describing system dynamics using Modelica have mostly been resolved and it has already been used quite successfully in real-world applications.  The next big challenge, once you have this great modeling capability, is managing all the data (both input and output).  My interest is in finding out how far we can *comfortably* go in using some of Modelica's existing capabilities to handle data management.

For me, it boils down to this.  We already use Modelica for describing system dynamics and it is, in my opinion, the best way to describe system dynamics so we are not considering using anything else for this.  So the question for us is how do we integrate this with a system for managing data and where is the overlap?

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

I understand and I do not dispute any of this.

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

My only comment would be that you may want to limit the depth of this validation.  As I mentioned above, you could refer to Modelica models by name and just make sure that, for example, the name is specified and in most cases not validate the Modelica code itself (although that could always be an option).

> Herman

--
Mike