[ros-users] [Orocos-users] Joint controller manager

[Herman Bruyninckx]

On Mon, 28 Jan 2013, Jonathan Bohren wrote:

> On Mon, Jan 28, 2013 at 11:51 AM, Herman Bruyninckx
> <Herman.Bruyninckx at mech.kuleuven.be> wrote:
>       On Mon, 28 Jan 2013, Jonathan Bohren wrote:
>
>             Based on this thread, and from what I know about other efforts
>             going on in the
>             community, I just went ahead and created a google group called
>             "ros-robot-control-sig"
>             [1].
>             My thought is that purpose of this group should be to
>             coordinate efforts on a common
>             interface for robot control in a ROS-based system as well as a
>             common realtime-friendly
>             and simulation-friendly controller architecture. While
>             different platforms will always
>             call for different architectures, it would be great if the
>             different systems spoke the
>             same ROS interfaces, and if similar computation platforms could
>             use the same libraries
>             for control.
> 
> 
> Allow me to disagree... Putting the design of interfaces (and "topic" data
> structures) at the level of a programming language as the most important
> design decision is wrong: robotics is one of the few technology domains
> (together with computer vision and machine learning) where software and
> systems are made 100% by compilers and hand-written libraries; other
> domains (automative, aerospace, mechatronics and control,...) start with
> standardizing _models_ (and their semantics), and _generate_ code from
> there.
> 
> 
> No, I agree entirely. I should have been more clear. When I refer to ROS interfaces, I
> mean the interfaces that we can use to connect the operation of these controllers to
> higher-level execution systems. In my experience, moving to something more model-based
> and _not_ heavily multithreaded is definitely the way to go.
>  
>       What I now see happening all the time (and especially in the context of
>       so-called "hackathons") is that developers _have_ to look at each others'
>       implementations in order to make components/nodes work together, since the
>       _meaning_ of the topics is not ambiguously defined. (Similar problems occur
>       at the level of the "actions": too many configuration parameters are in the
>       "code" and not in the "model".)
> 
>  
>       And finally, the data topics on their own never fully represent an
>       _interface_ between two concurrent activities: there just represent
>       functional
>       data flow, but also discrete coordination, bi-lateral QoS
>       adaptations, introspection, and data buffering policies are parts of the
>       interaction between components.
> 
> 
> I agree, semantic information about the data is _critical_.

Thank you for agreeing. The logical next step is to focus first on the
semantics, hence a "model". Unfortunately, this is not a common reflex in
the ROS/Orocos universe. But things are slowly changing; this concrete
topic could be a good start for a more visible effort in this direction.

Side note: within (but fully independent of) the Orocos context, Tinne De
Laet has made a complete "model-based stack", with a formal model that can
be connected to existing KDL code, while introducing checking of all
constraints in the model:
  <http://www.orocos.org/wiki/geometric-relations-semantics-wiki>
She has also had summer interns that made two prototype tools, one in
Eclipse (via Xcore/Xtext and OCL), another one via Prolog (using the same
Xcore formal model). So, we know that it _can_ be done, bottom up, and with
C++-biased developers, and without loosing any runtime efficiency :-)

> -j

Herman