Goals of the meeting: discuss the future or the Orocos toolchain w.r.t. Rock and ROS.

Identified major goals

• make Orocos components usable across all use cases (ROS, Orocos and Rock). There should be no "rock-only" or "ros-only" components
• make as much as the Rock toolchain usable with "plain Orocos components" (see below)
• make the parallel usage of the three cases (Orocos toolchain, Orocos in ROS and Rock) as painless as possible

Sharing installations of the orocos toolchain

The main issue is the ability to compile the toolchain and components only once, e.g. in a Rock installation, and use them in ROS or vice-versa.

• already existing ignore_packages mechanism. Need to create a wiki page on how to set it up for sharing an orocos installation. Manual, but should be working.
• more automatic mechanisms:
  • allow dependencies between autoproj installations. Fully automatic for orocos toolchain/Rock interoperability
  • point to a prefix and have autoproj find out things (for ROS installs)

Sharing Orocos components across use-cases

Using rock components on plain Orocos should just work [needs testing and documentation].

Using rock tools on plain Orocos

The use of orogen or typegen would be required

• as far as we know, there is no missing "core" functionality in orogen to make typegen usable for "core" orocos libraries like KDL. Need to make some functionality such as opaques available to typegen though (only available to orogen currently). This can be done through the ability to make typegen load an oroGen SL file (trivial)
• allow passing -I options directly to both oroGen and typeGen
• mechanism to define "side-loading" typekits that define constructors and operators separately for scripting
• the core of the Rock tooling is orocos.rb. Need to test and update orocos.rb so that it can work without a model. Method: update the test suite by mocking TaskContext#model to return nil and/or getModelName to not exist. From there, test tools like oroconf and vizkit

Dataflow between ROS and Rock / plain Orocos

• need data conversions: one must be able to publish a C++ type over a ROS topic and vice-versa
• typegen generation for ROS messages
• type specification when creating ROS streams (since the ROS topic and the orocos port might have different types)
• type conversions on the data flow: use already existing constructor infrastructure to do the conversion, need to create the channel element and change the connection code
• add type conversion support in oroGen (equivalent system than opaques)

Other discussed topics

• make TypeInfo very thin so that we can register it once per type and never change it. Only transports / constructors / ... could then be overriden
• make the deployer a library