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.
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
Tasks:
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 |
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 : http://www.orocos.org/node/1073 (in case you like to scroll)
CMake manual on how to use and create Findxyz macros : http://www.vtk.org/Wiki/CMake:How_To_Find_Libraries
List of many alternative modules : http://zi.fi/cmake/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.
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 !!!
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 : http://www.orocos.org/wiki/rtt/rtt-2.0/dataflow http://www.orocos.org/wiki/rtt/rtt-2.0/dataflow
Estimated work : 45 days for a demonstrable prototype.
Tasks:
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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.
Link: http://www.orocos.org/wiki/rtt/rtt-2.0/executionflow
Estimated work : 55 days for a demonstrable prototype.
Tasks:
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 |
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
Tasks:
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 |