Detailed Roadmap

These pages outline the roadmap for RTT-2.0 in 2009. We aim to have a release candidate by december 2009, with the release following in januari 2010.

  • A work package is divided in tasks with deliverables.
  • All deliverables are public and are made public without delay.
  • All development is done in git repositories.
  • For each change committed to the local git repository, that change is committed to a public repository hosted at within 24 hours.
  • For each task and at the end of each work package, all unit tests are expected to pass. In case additional unit tests are required for a work package, these are listed explicitly as deliverables.
  • The order of execution of tasks within a work package is suggestive and may differ from the actual order.
  • In case a task modifies the RTT API or structure, the task's deliverable implicitly includes the adaption to aforementioned modifications of following parts of OCL: CMake Build system; directories: taskbrowser, deployment, ocl, hardware, reporting, helloworld, timer, doc, debian.
  • These changes are collected in the ocl-2.0 git repository.
  • When the form of a deliverable is 'Patch set', this is equivalent to one or more commits on the public git repository.

WP1 RTT Cleanup

This work package contains structural clean-ups for the RTT source code, such as CMake build system, portability and making the public interface slimmer and explicit. RTT 2.0 is an ideal mark point for doing such changes. Most of these reorganizations have broad support from the community. This package is put up front because it allows early adopters to switch only at the beginning to the new code structure and that all subsequent packages are executed in the new structure.

Links : (various posts on Orocos mailing lists)

Allocated Work : 15 days


1.1 Partition in name spaces and hide internal classes in subdirectories.

A namespace and directory partitioning will once and for all separate public RTT API from internal headers. This will provide a drastically reduced class count for users, while allowing developers to narrow backwards compatibility to only these classes. This offers also the opportunity to remove classes that are for internal use only but are in fact never used.

Deliverable Title Form
1.1.1 Internal headers are in subdirectories Patch set
1.1.2 Internal classes are in nested namespaces of the RTT namespace Patch set

1.2 Improve CMake build system

Numerous suggestions have been done on the mailing list for improving portability and building Orocos on non standard platforms.

Deliverable Title Form
1.2.1 Standardized on CMake 2.6 Patch set
1.2.2 Use CMake lists instead of strings Patch set
1.2.3 No more use of Linux specific include paths Patch set
1.2.4 Separate finding from using libraries for all RTT dependencies Patch set

1.3 Group user contributed code in rtt/extras.

This directory offers variants of implementations found in the RTT, such as new data type support, specialized activity classes etc. In order not to clutter up the standard RTT API, these contributions are organized in a separate directory. Users are warned that these extras might not be of the same quality as native RTT classes.

Deliverable Title Form
1.3.1 Orocos rtt-extras directory Directory in RTT

1.4 Improve portability

Some GNU/GCC/Linux specific constructs have entered the source code, which makes maintenance on and portability to other platforms a harder task. To structurally support other platforms, the code will be compiled with another compiler (non-gnu) and a build flag ORO_NO_ATOMICS (or similar) is added to exclude all compiler and assembler specific code and replace it with ISO-C/C++ or RTT-FOSI compliant constructs.

Deliverable Title Form
1.4.1 Code compiles on non-gnu compiler Patch set
1.4.2 Code compiles without assembler constructs Patch set

1.5 Default to activity with one thread per component

The idea is to provide each component with a robust default activity object which maps to exactly one thread. This thread can periodically execute or be non periodic. The user can switch between these modes at configuration or run-time.

Deliverable Title Form
1.5.1 Generic Activity class which is by default present in every component. Patch set
1.5.2 Unit test for this class Patch set

1.6 Standardize on Boost Unit Testing Framework

Before the other work packages are started, the RTT must standardize on a unit test framework. Until now, this is the CppUnit framework. The more portable and configurable Boost UTF has been chosen for unit testing of RTT 2.0.

Deliverable Title Form
1.6.1 CppUnit removed and Boost UTF in place Patch set

1.7 Provide CMake macros for applications and components

When users want to build Orocos components or applications, they require flags and settings from the installed RTT and OCL libraries. A CMake macro which gathers these flags for compiling an Orocos component or application is provided. This is inspired on how ROS components are compiled.

Deliverable Title Form
1.7.1 CMake macro CMake macro file
1.7.2 Unit test that tests this macro Patch set

1.8 Allow lock-free policies to be configured

Some RTT classes use hard-coded lock-free algorithms, which may be in the way (due to resource restrictions) for some embedded systems. It should be possible to change the policy to not use a lock-free algorithm in that class (cfr the 'strategy' design pattern'). An example is the use of AtomicQueue in the CommandProcessor.

Deliverable Title Form
1.8.1 Allow to set/override lock-free algorithm policy patch

CMake Rework

This page collects all the data and links used to improve the CMake build system, such that you can find quick links inhere instead of scrolling through the forum.

Thread on Orocos-dev : (in case you like to scroll)

CMake manual on how to use and create Findxyz macros :

List of many alternative modules :

An alternative solution for users of RTT and OCL is installing the Orocos-RTT-target-config.cmake macros, which serve a similar purpose as the pkgconfig .pc files: they accumulate the flags used to build the library. This may be a solution for Windows systems. Also, CMake suggests that .pc files are only 'suggestive' and that still the standard CMake macros must be used to fully capture and store all information of the dependency you're looking at.

Directories and namespace rework

The orocos/src directory reflects the /usr/include/rtt directory structure, I'll post it here from the user's point of view, so what she finds in the include dir:

Abbrevs: (N)BC: (No) Backwards Compatibility guaranteed between 2.x.0 and 2.y.0. Backwards compatibility is always guaranteed between 2.x.y and 2.x.z. In case of NBC, a class might disappear or change, as long as it is not a base class of a BC qualified class.

Directory Namespace BC/NBC Comments Header File list
rtt/*.hpp RTT BC Public API: maintains BC, a limited set of classes and interfaces. This is the most important list to get right. A header not listed in here goes into one of the subdirectories. Please add/complete/remove. TaskContext.hpp Activity.hpp SequentialActivity.hpp SlaveActivity.hpp DataPort.hpp BufferPort.hpp Method.hpp Command.hpp Event.hpp Property.hpp PropertyBag.hpp Attribute.hpp Time.hpp Timer.hpp Logger.hpp
rtt/plugin/*.hpp RTT::plugin BC All plugin creation and loading stuff. Plugin.hpp
rtt/types/*.hpp RTT::types BC All type system stuff (depends partially on plugin). Everything you (or a tool) need(s) to add your own types to the RTT. Toolkit.hpp ToolkitPlugin.hpp Types.hpp TypeInfo.hpp TypeInfoName.hpp TypeStream.hpp TypeStream-io.hpp VectorComposition.hpp TemplateTypeInfo.hpp Operators.hpp OperatorTypes.hpp BuildType.hpp
rtt/interface/*.hpp RTT::interface BC Most interfaces/base classes used by classes in the RTT namespace. ActionInterface.hpp, ActivityInterface.hpp, OperationInterface.hpp, PortInterface.hpp, RunnableInterface.hpp, BufferInterface.hpp
rtt/internal/*.hpp RTT::internal NBC Supportive classes that don't fit another category but are definately not for users to use directly. ExecutionEngine.hpp CommandProcessor.hpp DataSource*.hpp Command*.hpp Buffer*.hpp Function*.hpp *Factory*.hpp Condition*.hpp Local*.hpp EventC.hpp MethodC.hpp CommandC.hpp
rtt/scripting/*.hpp RTT::scripting NBC Users should not include these directly.
rtt/extras/*.hpp RTT::extras BC Alternative implementations of certain interfaces in the RTT namespace. May contain stuff useful for embedded or other specific use cases.
rtt/dev/*.hpp RTT::dev BC Minimal Device Interface, As-is in RTT 1.x AnalogInInterface.hpp AnalogOutInterface.hpp AxisInterface.hpp DeviceInterface.hpp DigitalInput.hpp DigitalOutput.hpp EncoderInterface.hpp PulseTrainGeneratorInterface.hpp AnalogInput.hpp AnalogOutput.hpp CalibrationInterface.hpp DigitalInInterface.hpp DigitalOutInterface.hpp DriveInterface.hpp HomingInterface.hpp SensorInterface.hpp
rtt/corba/*.hpp RTT::corba BC CORBA transport files. Users include some headers, some not. Should this also have the separation between rtt/corba and rtt/corba/internal ? I would rename the IDL modules to RTT::corbaidl in order to clear out compiler/doxygen confusion. Also note that current 1.x namespace is RTT::Corba.
rtt/property/*.hpp RTT::property BC Formerly 'rtt/marsh'. Marshalling and loading classes for properties. CPFDemarshaller.hpp CPFDTD.hpp CPFMarshaller.hpp
rtt/dlib/*.hpp RTT::dlib BC As-is static distribution library files. They are actually a form of 'extras'. Maybe they belong in there... DLibCommand.hpp
rtt/boost/*.hpp boost ? We'll try to get rid of this in 2.x
rtt/os/*.hpp RTT::OS BC As-is. (Rename to RTT::os ?) Atomic.hpp fosi_internal_interface.hpp MutexLock.hpp rt_list.hpp StartStopManager.hpp threads.hpp CAS.hpp MainThread.hpp oro_allocator.hpp rtconversions.hpp rtstreambufs.hpp Semaphore.hpp Thread.hpp Time.hpp fosi_internal.hpp Mutex.hpp OS.hpp rtctype.hpp rtstreams.hpp ThreadInterface.hpp
rtt/targets/* - BC We need this for allowing to install multiple -dev versions (-gnulinux+-xenomai for example) in the same directory. rtt-target.h <target>

Will go: 'rtt/impl' and 'rtt/boost'.

Open question to be answered: Interfaces like ActivityInterface, PortInterface, RunnableInterface etc. -> Do they go into rtt/, rtt/internal or maybe rtt/interface ?

!!! PLEASE add a LOG MESSAGE when you edit this wiki to motivate your edit !!!

WP2 Data Flow API and Implementation Improvement

Context: Because the current data flow communication primitives in RTT limit the reusability and potential implementations, Sylvan Joyeux proposed a new, but fairly compatible, design. It is intended that this new implementation can almost transparently replace the current code base. Additionally, this package extends the DataFlow transport to support out-of-band real-time communication using Xenomai IPC primitives.

Link :

Estimated work : 45 days for a demonstrable prototype.


2.1 Review and merge proposed code and improve/fix where necessary

Sylvain's code is clean and of high standards, however, it has not been unit tested yet and needs a second look.

Deliverable Title Form
2.1.1 Code reviewed and imported in RTT-2.0 branch Patch set
2.1.2 Unit tests for reading, writing, connecting and disconnecting in-process communication Patch set

2.2 Port CORBA type transport to new code base

Sylvain's code has initial CORBA support. The plan is to cooperate on the implementation and offer the same or better features as the current CORBA implementation does. Also the DataFlowInterface.idl will be cleaned up to reflect the new semantics.

Deliverable Title Form
2.2.1 CORBA enabled data flow between proxies and servers which uses the RTT type system merged on RTT-2.0 branch Patch set
2.3 Allow Real-Time data port access with CORBA Proxy

A disadvantage of the current data port is that ports connected over CORBA may cause stalls when reading or writing them. The Proxy or Server implementation should, if possible, do the communication in the background and not let the other component's task block.

Deliverable Title Form
2.3.1 Event driven network-thread allocated in Proxy code to receive and send data flow samples Patch set
2.4 Reduce footprint of data connections

The current lock-free data connections allocate memory for allowing access by 16 threads, even if only two threads connect. One solution is to let the allocated memory grow with the number of connections, such that no more memory is allocated than necessary.

Deliverable Title Form
2.4.1 Let lock-free data object and buffer memory grow proportional to connected ports Patch set
2.5 Out of band data flow review

It is often argued that CORBA is excellent for setting up and configuring services, but not for continuous data transmission. There are for example CORBA standards that only mediate setup interfaces but leave the data communication connections up to the implementation. This task looks at how ROS and other frameworks set up out-of band data flow and how such a client-server architecture can be added to RTT/CORBA.

Deliverable Title Form
2.5.1 Report on out of band implementations and similarities to RTT. Email on Orocos-dev
2.6 Create automatic marshalling of user types

Since the out-of-band communication will require objects to be transformed to a byte stream and back, a marshalling system must be in place. The idea is to let the user specify his data types as IDL structs (or equivalent) and to generate a toolkit from that definition. The toolkit will re-use the generated CORBA marshalling/demarshalling code to provide this service to the out-of-band communication channels.

Deliverable Title Form
2.6.1 Marshalling/demarshalling in toolkits Patch set
2.6.2 Tool to convert data specification into toolkit Executable
2.7 Create out-of-band data flow communication

The first communication mechanism to support is data flow. This will be demonstrated with a Xenomai RTPIPE implementation (or equivalent) which is setup between a network of components.

Deliverable Title Form
2.7.1 Real-time inter-process communication of data flow values on Xenomai Patch set
2.7.2 Unit test for setting up, connecting and validating Real-Time properties of data ports in RT IPC setting. Patch set
2.8 Update documentation and Examples

In compliance with modern programming art, the unit tests should always test and pass the implementation. Documentation and Examples are provided for the users and complement the unit tests.

Deliverable Title Form
2.8.1 Unit tests updated Patch set
2.8.2 rtt-examples, rtt-exercises updated Patch set
2.8.3 orocos-corba manual updated Patch set

2.9 Organize and Port OCL deployment, reporting and taskbrowsing

RTT 2.0 data ports will require a coordinated action from all OCL component maintainers to port and test the components to OCL 2.0 in order to use the new data ports. This work package is only concerned with the upgrading of the Deployment, Reporting and TaskBrowser components.

Deliverable Title Form
2.9.1 Deployment, Reporting and TaskBrowser updated Patch set

WP3 Method / Message / Event Unified API

Context: Commands are too complex for both users and framework/transport implementers. However, current day-to-day use confirms the usability of an asynchronous and thread-safe messaging mechanism. It was proposed to reduce the command API to a message API and unify the synchronous / asynchronous relation between methods and messages with synchronous / asynchronous events. This will lead to simpler implementations, simpler usage scenarios and reduced concepts in the RTT.

The registration and connection API of these primitives also falls under this WP.


Estimated work : 55 days for a demonstrable prototype.


3.1 Provide a real-time memory allocator for messages

In contrast to commands, each message invocation leads to a new message sent to the receiver. This requires heap management from a real-time memory allocator, such as the highly recommended TLSF (Two-Level Segregate Fit) allocator, which must be integrated in the RTT code base. If the RTOS provides, the native RTOS memory allocator is used, such as in Xenomai.

Deliverable Title Form
3.1.1 Real-time allocation integrated in RTT-2.0 Patch set

3.2 Message implementation

Unit test and implement the new Message API for use in C++ and scripts. This implies a MessageProcessor (replaces CommandProcessor), a 'messages()' interface and using it in scripting.

Deliverable Title Form
3.2.1 Message implementation for C++ Patch set
3.2.2 Message implementation for Scripting Patch set

3.3 Demote the Command implementation

Commands (as they are now) become second rang because they don't appear in the interface anymore, being replaced by messages. Users may still build Command objects at the client side both in C++ as in scripting. The need for and the plausibility of identical functionality with today's Command objects is yet to be investigated.

Deliverable Title Form
3.3.1 Client side C++ Command construction Patch set
3.3.2 Client side scripting command creation Patch set

3.4 Unify the C++ Event API with Method/Message semantics

Events today duplicate much of method/command functionality, because they also allow synchronous / asynchronous communication between components. It is the intention to replace much of the implementation with interfaces to methods and messages and let events cause Methods to be called or Messages to be sent. This change will remove the EventProcessor, which will be replaced by the MessageProcessor. This will greatly simplify the event API and semantics for new users. Another change is that allowing calling Events on the component's interface can only be done by means of registering it as a method or message.

Deliverable Title Form
3.4.1 Connection of only Method/Message objects to events Patch set
3.4.2 Adding events as methods or messages to the TaskContext interface. Patch set

3.5 Allow event delivery policies

Adding a callback to an event puts a burden on the event emitter. The owner of the event must be allowed to impose a policy on the event such that this burden can be bounded. One such policy can be that all callbacks must be executed outside the thread of the owning component. This task is to extend the RTT such that it contains such a policy.

Deliverable Title Form
3.5.1 Allow to set the event delivery policy for each component Patch set

3.6 Allow to specify requires interfaces

Today one can connect data ports automatically because both providing and requiring data is presented in the interface. This is not so for methods, messages or events. This task makes it possible to describe which of these primitives a component requires from a peer such that they can be automatically connected during application deployment. The required primitives are grouped in interfaces, such that they can be connected as a group from provider to requirer.

Deliverable Title Form
3.6.1 Mechanism to list the requires interface of a component Patch set
3.6.2 Feature to connect interfaces in deployment component. Patch set

3.7 Improve and create Method/Message CORBA API

With the experience of the RTT 1.0 IDL API, the existing API is improved to reduce the danger of memory leaks and allow easier access to Orocos components when using only the CORBA IDL. The idea is to remove the Method and Command interfaces and change the create methods in CommandInterface and MethodInterface to execute functions.

Deliverable Title Form
3.7.1 Simplify CORBA API Patch set

3.8 Port new Event mechanism to CORBA

Since the new Event mechanism will seamlessly integrate with the Method/Message API, a CORBA port, which allows remote components to subscribe to component events must be straightforward to make.

Deliverable Title Form
3.8.1 CORBA idl and implementation for using events. Patch set

3.9 Update documentation, unit tests and Examples

In compliance with modern programming art, the unit tests should always test and pass the implementation. Documentation and Examples are provided for the users and complement the unit tests.

Deliverable Title Form
3.9.1 Unit tests updated Patch set
3.9.2 rtt-examples, rtt-exercises updated Patch set
3.9.3 Orocos component builders manual updated Patch set

3.10 Organize and Port OCL deployment, taskbrowsing

The new RTT 2.0 execution API will require a coordinated action from all OCL component maintainers to port and test the components to OCL 2.0 in order to use the new primitives. This work package is only concerned with the upgrading of the Deployment, Reporting and TaskBrowser components.

Deliverable Title Form
3.10.1 Deployment, Reporting and TaskBrowser updated Patch set

WP4 Create Reference Application Architecture

In order to lower the learning curve, people are requesting often complete application examples which demonstrate well known application architectures such as kinematic robot control. This work package fleshes out that example.

Links : (various posts on Orocos mailing lists)

Estimated Work : 5 days for the application architecture with documentation


4.1 Universal Robot Controller (Using KDL, OCL, standard components)

This application has a robot component to represent the robot hardware, a controller for joint space and cartesian space and a path planner. Users can start from this reference application to control their own robotic platform. Both axes and end effector can be controlled in position and velocity mode. A state machine switches between these modes. A GUI is not included in this work package.

Deliverable Title Form
4.1.1 Robot Controller example tar ball