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