On Mon, Jan 28, 2013 at 11:51 AM, Herman Bruyninckx <
Herman.Bruyninckx@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_.

-j

-- 
Jonathan Bohren
PhD Student
Dynamical Systems and Control Laboratory
Laboratory for Computational Sensing and Robotics
The Johns Hopkins University

(707) 520-4736
jbo@jhu.edu