RE: Open source robot controllers

> A minor clarification.  Modelica covers the kinds of 
> requirements you describe for connectors.  In addition, there 
> are a (currently informal, I think) set of annotations that 
> allow Modelica models and hierarchies to be represented and 
> connected graphically.  These are implemented by Dymola 
>(http://www.dynasim.se) and MathModelica (http://www.mathcore.com).
>
>The code generation approach you describe is implemented in Dymola although
that is not a strict ?
>  Modelica requirements.
>
> Finally, Modelica goes beyond just requiring pairs of effort and flow
variables.  For example, in 
> multi->body systems it is often necessary to express these quantities as
vectors.  Furthermore, in 
> thermodynamic system (my area) we often have far more complex connectors
where the flow and non-flow 
> variables are not balanced.  Modelica covers all these possibilities very
nicely.

As I have also said in Leuven, I invite you to have a look at 20sim
www.20sim.com which does allow this all. Furthermore, the multibody modeling
is based on Lie-Groups and screws and this make it very easy for hyrarchical
modeling of multibody systems. We are still working on the multibody part
and the next step will be flexible structures.

> Just one: don't fall in the trap of Simulink, and make sure that you
> impose the constraints that physics imposes. Because I have 
> seen way too many people make spagetti code with a `tool' à la Simulink
:-( Way too
> many...

I agree!! That is nothing !

>I would like to jump in and comment that the key here is to recognize the
inherent differences between 
> control system designs and physical designs.  There are differences both
in the graphical 
> representation and in the underlying structure and causality.  I only
mention this because it seems as
> though 'Overflow' is designed around control systems and so it may be
quite reasonable to have a 
> Simulink interface.  I would agree with Herman that the 'trap' for these
tools is that they do not 
> recognize the need to recognize not only the controller but also the
plant.  While you can represent a 
> considerable amount of physical behavior using block diagrams, they are
not the best medium for 
> representing physical systems/behavior.  My caution to anybody developing
a control system tool is to >  
> not forget about the plant. :-)

VERY GOOD POINT !!! :- >

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Dr.ir. Stefano Stramigioli
Associate Professor

Faculty of Electrical Engineering
Drebbel Institute

P.O. Box 217
NL-7500 AE Enschede
The Netherlands

Tel. +31 (53) 4892794/4892606 
Fax. +31 (53) 4892223 

Email [email protected]
WWW: http://www.rt.el.utwente.nl/smi

ICQ: 7864978
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%