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.
    [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.
    OS::PeriodicThread depends on RTT::Event, CompletionProcessor
    for all details.

  • The RTT::OS::ThreadInterface functions
    makeSoftRealTime() and
    isHardRealTime() have been replaced
    with bool
    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

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.
    [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.
    [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'.
    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.
    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.
    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,
    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
    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.
    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.
    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

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.
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
( dev public
) .

Copyright (C) FMTC

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