dynamics: comment about MBdyn...

Some weeks ago, there were some posts about the free software dynamics
package MBDyn <http://www.aero.polimi.it/~mbdyn/index.html>, and I
took a closer look at it... Since there is apparently no mailinglist
for MBDyn, and since the topic might be of interest to some Orocos
people, I post my comments here, but address the MBDyn developers in
the second person :-)

I have read with much interest the documentation that is available on
the MBdyn webpage, and I am impressed by the functionality you have
already. Of course, I do have lots of questions and comments... :-)

First of all, I am personally quite a bit biased by the Bond Graph
approach, both because I have many good friends that work in this
area and so I know it better than other domains, and because I really
think it is the best fit for an "object-oriented" software engineering
solution to general purpose dynamics software.

Probably the most visible effect of this bias is that I am looking for
separation of software modules between 
- structure and dynamical properties (i.e., modelling the
  interconnectivy separately from the dynamics attached to nodes in
  the connectivity graph(s)).
- what is application-dependent (e.g., the fact that MBdyn and Orocos
  work basically in the mechanical domain) and application-independent
  things (such as the tools to model and build connected dynamical
  systems, the needs for symbolic pre-processing of DAE systems, the
  GUI, etc.).

My basic remark is that you have a very tight "coupling" between
stuff that should be decoupled. For example, modelling, simulation,
and file IO; topology and properties; mathematical representations and
models; particular mathematical library dependencies; etc.
It is my strong believe that this leads to unmaintainable projects,
unless maintained only by the original developers.
(Our own robot control software was in the same condition, so I know,
and I also know that _that_ is the most important reason I tried
to start up Orocos :-)

Here follow more detailed technical things. (The order is quite
random.) Some of them are real questions, to which I think you might
give an answer; some others are more open issues listed here for
further thought and discussion :-)

About the "input" manual.
That PDF document renders very slowly because you don't use PDF
fonts, but bitmapped fonts. It's better to use "pdflatex" or "dvips
-Ppdf" for production of the PDF file.)
When trying to (pdf)latex the TeX files myself, I encountered the
error that the file "version.tex" is not found. Another error: you use
"time_step" instead of "time\_step".
"sintax"-> "syntax"
Line 615 of data.tex needs an ending "}" for the \emph.
The reference MASARATI-LANZ-MANTEGAZZA-2001 is not included.

About discussion of symbolic needs. 
- Where exactly do you need symbolic support? I mean, what do you use
  it for, and what do you _want_ to use it for in the future?
  (I guess for the reduction of sets of DAEs to computationally
   deterministic smaller sets?)
- Are these symbolic needs decomposable in smaller modules, that can
  be developed and used independently?

About File IO.
- Structure of models and their properties?
- Useful to transform to XML + Schema?
- Reuse of shared objects and properties with Orocos?
- Useful to separate files in functionally decoupled files:
  - physical modelling.
  - data
  - integrator properties
  - simulation properties (initial values, timing, logging, ...)
- What exactly is "control data"? ("The control data block mostly
  contains information about the problem that is required to ensure
  that a consistent model will be generated."
  - aren't all generated models consistent by construction? Is this
    possible/desirable?
- "Nodes": generic frameworks such as Bond Graphs and Modelica offer
  already well-developed terminology and definitions, so it could be
  interesting to follow those. Personally, I am very interested in
  discussing this in detail.
- "Elements"...? Seems to me that nodes describe the "connectivity"
  of a dynamic system ("bonds in Bond Graph parlance) and elements
  describe the "constitutive relationships" of dynamic objects (=
  energy storing elements, and energy tranforming elements).
- "Drivers": these represent two concepts, I think:
  - "sources" of motion or force.
  - particular "setpoint generation algorithms" (linear, cubic, ...).
  I think this coupling is not good.
- you only seem to use "constitutive relationships" for elastic
  and viscous elements; I think also the inertial properties are
  "constitutive relationships", so should be modelled by the same
  software objects. (Which leads straightforwardly to Bond Graphs :-)

Peter Soetens is about to finish a very powerful (both in
efficiency and in scope) library for "property management", i.e.,
the setting and getting of properties of objects in a complex software
syste, with interfaces to XML parsing etc. I guess it should be
directly useable in MBdyn too.
your file syntax is very much position dependent (see the simple
example of the free body on p. 5), which is very error-prone; I
would definitely suggest to add the name of the property to the value,
as would be normal in an XML-based model. It should also be
possible/required to add the physical units, I guess.

About some code.
- I browsed through it for an hour or two, but it is not so easy to
  grasp what every file is supposed to encode. And the reason is that
  I have no "large scale" framework (Modelica, Bond Graphs) to attach
  the terminology and the objects to. I really think this is vital for
  the survival of a complex piece of code such as MBdyn: using
  terminology which is very well documented in these two big
  frameworks...
- most of the comments in the files are in Italian. Not so much of a
  problem for me, but it might be difficult for most people :-)
- I guess that the code in which you use ASSERTs and THROWs is 
  only used during setup or configuration? (Otherwise you will get
  some efficiency problems in your RTAI integration, I guess.)
- do you have some documentation about all the math library "wrapping"
  you have done? This would be highly relevant information for Orocos
  (and many other projects), because we have to do it to :-)
- if I am not mistaken, you use operator overloading for matrix
  multiplications? Also not real-time safe, in principle. (But the
  places where I have seen it used are not real-time parts of the
  code.)
- what is a "DriveHingeJoint"?
- what are the differences between a "ElasticHingeJoint" and a
  "DeformableHingeJoint"?
  (My BG bias tells me to decouple these things in a separare ideal
   joint and a separare elastic element :-) )
- I see files that depend on Ginac in the same directory as
  non-dependent files; I think it would be very worthwhile to separate
  the symbolic functionalities from the numeric.
  Similar remarks for dependencies on sockets and file IO.
- I couldn't guess what the TplDrive stuff is all about...
- you have a "struct" directory; what does "struct" stand for?
  (I guess a/the finite-dimensional subset of the mechanical domain?)
- in the "elec" directory I had expected to see electrical object
  models, but I encounter stuff like "DynamicForgettingFactor" and
  "GPCInv"...



About PDE modelling and simulation.
What we miss (well, nobody really _misses_ it at this moment :-)
in the Orocos community are the "inifinite dimensional"
dynamical objects, (with the Timoshenko beam as the classical
example), which requires PDEs instead of ODEs. So, it would be very
useful to brainstorm about how to incude both in the same software
structure.
  
About the MBdyn Tutorial.
- Free rigid body
  Why separate the inertial stuff from the momentum stuff? THese
  things are both inherent properties of a mechanical body, so I would
  model and store them together.
  Or, do you mean that the "degrees of freedom owner" is a
 "junction" in Bond Graph terms, and that you can attach several
 inertial components ("I" objects in BGs) to the same junction?

- the "body" example on p. 5 seems to suggest a strong coupling
  between the specification of the dynamics and the topology.

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