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.

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.