RE: Open source robot controllers

> From: Herman Bruyninckx 
> Subject: Re: [Orocos] Open source robot controllers
> 
> 
> On 24 Sep 2001, Dominic Létourneau wrote:
> 
> > I have read the description of the OROCOS project and it seems very
> > interesting.
> 
> It's still without any code though :-)
> 
> > http://freespeech.sourceforge.net/FreeSpeech/html/Overflow/
> 
> Thanks! I added the link to the Orocos web page.
> 
> I'm looking for such a builder interface: draw a schematic, and you
> get a program. But I want to have something better than Simulink, in
> the sense that the user can only draw what is physically meaningful.
> That is, the `ports' between parts should be compatible, and an
> `effort' port should be accompanied by a `flow' port. I guess this is
> within the design scope of Overflow?
> 
> The physics of robotics (and other areas) is that blocks exchange
> energy, as a `dual' pair of `effort' (force, voltage, ...) and `flow'
> (velocity, current, ...). I want to impose this constraint when
> drawing schemes. And I want to have a coupling with an engine that can
> work on the graph structure that one builds, in order to come up with
> the best computational scheme. So, I will closely follow what you are
> doing :-)
> 
> It could be interesting for you to take a look at modelica.org, for
> the modelling language. I do have some objections against the precise
> way they are doing things, but it's by far the most advanced thing at
> this instant.
> 
> So, I hope we can share some efforts :-)

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.

> > http://www.gel.usherb.ca/laborius) to release a project that will be
> > called RobotFlow that will include robotic libraries 
> containing blocks
> > to build robot controllers from low level actuators / 
> sensors control to
> > high level AI controllers (TCA, Subsumption, etc.)
> 
> That's very complementary to the Orocos goals :-) ! Great! Orocos
> concentrates on the building blocks. We are working on software
> framework designs for motion control, task execution, component
> commmunication and kinematics.
> 
> > I hope this information can be of any help. If you have any 
> questions or
> > comments, don't hesitate to contact me.
> 
> 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 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. :-)

> The orocos approach will be a bit different, in that `senior' people
> will design frameworks that less-experienced users can fill in; we
> won't allow `anything' to be put together :-) Of course, there will be
> many frameworks, such that the user is not limited. (But
> ``guided''...)
> 
> Good luck!
> 
> Herman Bruyninckx