Orocos RTT 1.0 Release Series Changes, New Features, and Fixes

Open RObot COntrol Software


This document provides a quick overview of what changed between Orocos RTT versions 0.24 and 1.0. Hence, this release includes all bugfixes of the 0.24 branch. If your application does not work, look here for possible causes and solutions. Also feature additions and improvements are documented.

1. Caveats

1.1. Overall Changes

1.2. OS Changes

  • The ORO_OS namespace has been renamed to RTT::OS. See [Project] new Orocos namespace for all details. The headers are installed in 'rtt/os'.

  • The RTT::OS::PeriodicThread setToStop() function now executes finalize() as well and no longer uses Events nor the Completion Processor. See OS::PeriodicThread depends on RTT::Event, CompletionProcessor for all details.

  • The RTT::OS::ThreadInterface functions makeHardRealTime(), makeSoftRealTime() and isHardRealTime() have been replaced with bool ThreadInterface::setScheduler(int) and int ThreadInterface::getScheduler() const. By default, all threads (except the main thread) are created as 'hard realtime' (if available). Use setScheduler to change the default with an OS defined parameter. The rationale of this decision has been discussed on Remove ZTT and friends. This also lead to a renaming of the equivalent functions in the fosi_internal.h file.

1.3. CoreLib Changes

  • The Event object has changed 'constructor' semantics. An Event requires a "name" upon construction in order to be usable. Nameless events are 'empty' and require initialisation. See [API] Change event 'add' methods for all details.

  • The Activity classes can no longer react to Events. Use an EventProcessor or the ExecutionEngine to react to events. See [Project] Removing Events out of activities for all details.

  • The NonPreemptibleActivity, PreemptibleActivity, NonRealTimeActivity classes and their Thread classes no longer exist. Use (or subclass) the PeriodicActivity instead and add a priority level in the constructor. See Remove ZTT and friends for all details.

  • The property reading and writing functions of the PropertyLoader have changed semantics. It is now possible to specify if all properties, some properties or one property must be written to or read from a file. The global 'find' function has been renamed to 'findProperty'. See reading properties does not fail for all details.

1.4. Scripting Changes

  • The emit statement for emitting events has been replaced by the do statement in both program scripts and state machine scripts. See Using events in TaskBrowser for all details.

  • The task.varname prefix, required in programs and statemachines in order to access TaskContext variables has been dropped. One can now address a TaskContext variable by just writing varname in a script. The parser will not allow name clashes between program script variables and TaskContext variables in which the scripts are loaded. See Using properties from a state machine for all details.

1.5. Component TaskContext Changes

1.6. Corba IDL Changes

These changes only apply if you directly used the IDL interface of Orocos.

  • The RTT::Corba::ControlTask class and related classes have been revised to map better to the TaskContext interface. MethodFactory has been renamed to RTT::Corba::MethodInterface, CommandFactory has been renamed to RTT::Corba::CommandInterface. The RTT::Corba::TaskObject has been added and getting a command or method from the interface is now similar to plain C++ usage.

  • All created objects now have a destroy_X IDL method which you must call to free the serverside object.

2. Improvements

2.1. Orocos C++ Interface

  • The classes and functions required to setup or access a component have been greatly simplified and are more uniform in naming. For example, adding a command is done by writing commands()->addCommand(...), properties by properties()->addProperty(...) etc and such for each primitive. Retrieving a 'pointer' to a primitive from another TaskContext is then done by peer->getCommand("name"), peer->getProperty("name") etc. See The Component Builder's Manual for all details.

  • All Orocos primitives are to be used as 'objects' and not as 'pointers'. For example, one does no longer write

    Property<int>* myProp = peer->properties()->getProperty<int>("Prop");
    assert( myProp != 0 );

    but instead:

    Property<int> myProp = peer->properties()->getProperty<int>("Prop");
    assert( myProp.ready() );

    The ready() method checks if "Prop" could be found and had the correct value. This aproach must be taken for every Orocos primitive: Commands, Events, etc. See The Component Builder's Manual for all details.

  • The Command's evaluate() function has been renamed to done(). See [API] Commands: evaluate() deprecated, use done() for all details.

2.2. Component XML Configuration

  • Orocos no longer has a hard dependency on Xerces, nor on 'cpf.dtd' for XML parsing. If Xerces is not detected on your system, an internal (TinyXML) implementation is used. Furthermore, the 'cpf.dtd' file is no longer required to parse Orocos XML files. Orocos has this file built-in and uses it to validate your document when the XML parser supports it (i.e. Xerces). See XML Parsing: DTD's and Parsers. for all details.

  • The readProperties and writeProperties functions have become more strict. All properties must be read or written or they will refuse to change any values. To have more flexible behaviour, alternative functions have been added to fill the gap. See reading properties does not fail for all details.

2.3. TaskBrowser Component

  • One can emit events from the TaskBrowser by calling the event by name and providing the arguments. See Using events in TaskBrowser for all details.

  • An TaskBrowser 'Component' has been created which is more powerful than the classical RTT::TaskBrowser. It dynamically connects to Data Flow Ports and allows better testing of unconnected components.

A. About Orocos

Please send general, non technical, Orocos questions to orocos at lists.mech.kuleuven.be .

These pages are maintained by the Orocos team.

For questions related to the use of the Orocos Software, please consult these web pages and the Orocos manuals. If that fails, the orocos-dev at lists.mech.kuleuven.be mailing list might help. Please send comments on these web pages and the development of Orocos to our developer mailing list at orocos-dev at lists.mech.kuleuven.be . All of our lists have public archives ( dev public archive ) .

Copyright (C) FMTC

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.