Orocos developers meetup at ERF

Table of Contents

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)

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

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

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)