RTT 2.0.0-beta1

This page is for helping you understand what's in RTT/OCL 2.0.0-beta1 release and what's not.

Caveats

First the bad things:
  • Do not use this release on real machines !
  • There are *no* guarantees for real-time operation yet.
  • CORBA transport does not work yet and needs to change drastically
  • The API is 'pretty' stable, but the transport rework might have influences. This release will certainly not be binary compatible with the final 2.0.0 release.
  • OCL has not completely catched up, and also needs to be restructured further into a leaner repository.
  • Do not manually upgrade your code ! Use the rtt2-converter script found on this site first.
  • RTT::Command is gone ! See Replacing Commands
  • RTT::Event is gone ! See Replacing Events
  • Reacting to Operations (former Event) is not yet possible in state machine scripts.
  • RTT::DataPort,BufferPort etc are gone ! See RTT 2.0 Data Flow Ports
  • In case you have patches on the orocos-rtt source tree, all files have moved drastically. First all went into rtt/ instead of src/. Next, all non-API files went into subdirectories.

For all upgrade-related notes, see Upgrading from RTT 1.x to 2.0

Missing things

The final release will have these, but this one has not:
  • A plugin system in RTT to load types (type kits) and plugins (like scripting, marshalling,...)
  • A tool/workflow to create type kits automatically
  • A working CORBA transport
  • RT-Logging framework
  • Service deployment in the DeploymentComponent
  • Misc fixes/minor feature additions and better documentation
  • Repackaged OCL tree. Especially, in OCL, only TaskBrowser, Reporting and DeploymentComponent are fully operational.
  • Debian packages have not been updated yet
  • A couple of unit tests still fail. You should see at the end: 

88% tests passed, 3 tests failed out of 25
 
The following tests FAILED:
          6 - mqueue-test (Failed)
         19 - types_test (Failed)
         22 - function_test (Failed)

New Features

Updated Examples and Documentation

Most documentation (manuals and online API reference) is up-to-date, but sometimes a bit rough or lacking illustrations. The rtt-exercises have been upgraded to support RTT 2.0 API.

New style Data Ports

The data flow ports have been reworked to allow far more flexible component development and system deployment. Details are at RTT 2.0 Data Flow Ports. Motivation can be found at Redesign of the data flow interface

Improved TaskBrowser

Allows you to declare new variables, shows what a component requires and provides and if these interfaces are connected.

Improved Deployment

Specify port connection properties using XML, connect provided to required services.

Improved Reporting

Data flow logs are now sample based, such that you can trace the flow and state of connections.

Method vs Operation

The RTT 1.x Method, Command and Event APIs have been removed and replaced by Method/Operation. Details are at Methods vs Operations

Real-Time Allocation

RTT includes a copy of the TLSF library for supporting places where real-time allocation is beneficial. The RT-Logger infrastructure and the Method/Operation infrastructure take advantage of this. Normal users won't use this feature directly.

A real-time MQueue transport

Data flow between processes is now possible in real-time. The real-time MQueue transport allows to transport data between processes using Posix MQueues as well as in Xenomai.

For each type to be transported using the MQueue transport, a separate transport typekit must be available (this may change in the final 2.0 release).

Simplified API

Creating a component has been greatly simplified and the amount of code to write reduced to the absolute minimum. Documentation of operations or ports is now optional. Attributes and properties can be added by using a plain C++ class variable, the need to specify templates has been removed in some places.

Services

Component interfaces are now defined as services and a component can 'provide' or 'require' a service. These tools can be used to connect methods to operations at run-time without the necessary lookup code. For example: 
 Method<bool(int,int)> setreso;
 setreso = this->getPeer("Camera")->getMethod<bool(int,int)>("setResolution");
 if ( setreso.ready() == false )
    log(Error) << "Could not find setResolution Method." <<endlog();
 else
    setreso(640,480);
becomes: 
 Method<bool(int,int)> setreso("setResolution");
 this->requires("Camera")->addMethod(mymethod);
 
 // Deployment component will setup setResolution for us...
 setreso(640,480);
»