[Rock-dev] Plan for integration of ROS nodes into Rock

Sylvain Joyeux sylvain.joyeux at dfki.de
Thu Sep 1 19:12:36 CEST 2011


On 09/01/2011 05:01 PM, Peter Soetens wrote:
> (please post the non-https url)
Ah ... yes.
> - allow building ROS stacks in autoproj ? Will you use the concepts of stacks?
Don't know yet. I have two options: either see only packages and have a 
system to convert tasks to autoproj metapackages (so that one can tell 
autoproj to build ros.<stack_name> to get a whole stack). Or see stacks 
as packages (which is what they are used for in ros anyways).
> - What do you mean by 'orogen type' ? is it a C/C++ header with data type defs
> ? Would this mean that you want to support a work-flow, where the user looks at
> a ROS message, then specifies a similar C struct (independent of ROS) and then
> allow orogen to 'map' these ?
Yes. Kind of. What I want is that people develop normal orogen 
components and when they want to talk to ROS nodes they are able to map 
*their* types to the ROS messages of the nodes they want to talk to.
> Wouldn't it be sufficient to generate a ros-
> independent C/C++ header from the ROS .msg file ?
No, because I don't want people to be FORCED to use ROS messages. Or to 
even know about ROS from the start. And since the goal is to be 
compatible with Rock, which does not and will not use ROS messages, it 
makes sense.

In the long run, the infrastructure built this way will be WAY more 
extensible as it will allow to talk to other frameworks than ROS.
> - Why do you want to implement service calls ? (cfr not using operations)
I don't understand "cfr not using operations" ...

I want to implement service calls because they are essential to 
configure / interact with the nodes.
> - What do you mean with not supporting dynamic reconnections of ROS nodes ?
Well, AFAIK, you can't dynamically remap ROS topics. I.e. you can't 
decide that two nodes talk to each other at some point and then stop 
talking to each other at another point. This is essential to dynamic 
system reconfiguration (which is the root of the whole rock high-level 
supervision layer).

-- 
Sylvain Joyeux
Space&  Security Robotics

!!! Achtung, neue Telefonnummer!!!

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 178-454136
Fax:   +49 (0)421 218-454150
E-Mail: robotik at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.:    DE 148646973
Steuernummer:  19/673/0060/3
-----------------------------------------------------------------------



More information about the Rock-dev mailing list