wiki:WikiStart/OngoingWork/ROSIntegration

Work to do

  • build system
    • allow building ROS packages in autoproj
  • transparent integration of ROS messages and oroGen types
    • allow ROS messages to be used in oroGen
    • provide a framework to convert oroGen types to/from ROS messages
  • Ruby library to manipulate ROS nodes
    • use the orocos ROS transport for the dataflow part (depends on ROS/oroGen integration)
    • implement service calls (not sure how to do it yet)
  • integration in the higher-level tooling (Roby). Possible problems:
    • ROS does not support dynamic reconnections (will have to stop/start the node)
    • ROS does not have a separate process and task lifecycle (you have to kill the node to stop the processing)

Plan

At least at the beginning, the build system integration is a "nice to have", not a "should have". In practice, it means that either (i) it will be too painful to have both and I'll scratch my own itch or (ii) it will be done when everything else is already done.

  1. ROS integration in oroGen
    • use ROS debian packages for starter (no autoproj-based compilation of ROS stuff)
    • provide a general framework to convert oroGen interface types to an arbitrary type (would apply for instance to opaques and/or ROS messages)
    • use it to convert oroGen types to/from ROS messages
    • look into the current ROS transport. Adapt to allow arbitrary types to be used there. Will need to pass some metadata to the transport (e.g. frames are included in ROS messages and are not in Rock types)
  1. Ruby library to manipulate ROS nodes
    • if the oroGen integration is done, we have the dataflow for free (topics)
    • use oroGen specifications to represent ROS nodes. In principle, nothing forbids to handle this (a ROS node is a subset of what a taskcontext provides).
      • this will probably depend on the cleanup of the oroGen loading mechanisms (long overdue anyways)
    • runtime inspection should be doable by either using the XMLRPC API (not everything seems to be available there though). Otherwise, we'll have to wrap the ROS C++ API in Ruby
    • naming (TaskContext.get) can be accessed through XMLRPC. Easy in Ruby, and the orocos.rb already supports having multiple ways to resolve names.
    • property interface will require a bit of standardization when running the ROS nodes. Ideally, we would remap all the ROS node configuration parameters in a private namespace which is the ROS name itself, and then do a name mapping between "virtual" properties declared in the oroGen spec to /rosnode_name/property_name on the configuration server.
  1. Integrate ROS nodes in the supervision layer
    • weirdly, my guess is that it is going to be the least work since the previous point provides us with an orocos.rb-compatible API to ROS nodes
    • only changes:
      • connections have different properties. The supervision will have to recognize that there are some dynamic constraints on the components when changing connections. This would be useful anyway as it would allow the specify that e.g. oroGen components should be restarted when a port gets connected/disconnected.
      • will have to represent the nodes as single tasks in the Roby plan, instead of separating between the task and the deployment.
Last modified 8 years ago Last modified on 09/05/11 14:12:21