Orocos Real-Time Toolkit 1.10 Release Series Changes, New Features, and Fixes

Open RObot COntrol Software


Table of Contents

1. Caveats
2. Improvements
2.1. OS Abstraction
2.2. CORBA Transport
2.3. Testing
2.4. Build system / CMake
3. Orocos Component Library (OCL)
3.1. Caveats
3.2. Improvements
1. About Orocos

This document provides a quick overview of what changed between the Real-Time Toolkit 1.8 and version 1.10. This release includes all bugfixes of the 1.8 branch. If your application does not work with this release, look here for possible causes and solutions. Also feature additions and improvements are documented.

The complete changelog is available as well.

1. Caveats

  • This release is binary incompatible with RTT 1.8.x. You need to recompile all your applications in order to upgrade to this release.

  • This release can only be compiled if you have CMake version 2.6.0 or higher. If your distribution (like Debian Etch) does not support this version, look for a 'backports' version or download and install a pre-built cmake package from www.cmake.org.

  • RTT 1.8.0 introduced the SequentialActivity as the default activity for components. Because of the special semantics of this implementation, this has been reverted, and the default activity is now of type Activity, which behaves by default as an event-triggered thread (ie not periodically triggered). You can make this activity periodic by using for example

    this->getActivity()->setPeriod(0.001)

    in your component's configureHook(). In case you want the 1.8.0 behaviour back, enable ORO_ACT_DEFAULT_SEQUENTIAL in cmake. In case you want the pre-1.8.0 behaviour back (no default activity), disable ORO_ACT_DEFAULT_ACTIVITY in cmake.

    At the same time, NonPeriodicActivity has been deprecated in favour of RTT::Activity and users of PeriodicActivity should switch to RTT::Activity as well, unless they fully understand the consequences of using RTT::PeriodicActivity.

  • The Event class no longer uses its static NameServer nameserver object, even when a name is supplied. In case you require this functionality (which is unlikely), define your own NameServer<Event<T> > instance and add event objects to that instance. This feature was removed because it is a left-over of pre-TaskContext times and also causes trouble on the win32 platform.

2. Improvements

2.1. OS Abstraction

  • You can now set the default stack size of a Thread object, before it is created. This parameter is passed to the underlying OS and applied if the os supports it. See Thread::setStackSize(unsigned int). Thread is used by the new Activity class.

  • The system no longer waits for ever if it tries to stop an Activity which went into an infinite loop. Instead Activity::stop() will return false.

  • The RTT has been reported to compile with Intel compilers (on Linux) as well.

  • The RTT can be compiled without using any assembler constructs. In that case, the lock-free algorithms are replaced at compile-time with lock-based alternatives. This eases porting to other platforms or in case the user finds the assembler code suspect, or lacks it on his platform. To use this, turn the OS_NO_ASM option in in the cmake dialog.

    [Warning]Warning

    In case you enable OS_NO_ASM, you'll require Boost 1.36.0 or newer, since the lock-based alternatives are based on the since then added boost::intrusive containers.

2.2. CORBA Transport

  • A new variant of ApplicationServer::InitOrb has been added which uses the TAO Messaging service to allow to specify global time-outs for remote method calls. In case the TAO Messaging service is not available on your platform, the previous behaviour remains.

2.3. Testing

  • Initial CDash support has been added and the cmake targets were aligned in order to make automated testing work better. When tests are enabled, the 'all' target also builds the tests right away, such that a 'check' only needs to run the tests. A dependency flaw in unit test building has been fixed as well (the libraries are now built before the unit tests are built).

2.4. Build system / CMake

  • Users can set build defaults more easily using an orocos-rtt.cmake file. It allows a user to set defaults for any future build, without touching the RTT cmake files. This file is created by making a copy of orocos-rtt.default.cmake. A number of pre-defined options are listed and documented in that file.

  • The prefered way to point to non-standard include and library paths is to use the CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH variables. You can set these in the orocos-rtt.cmake file in the orocos-rtt directory (see item above), or using the -D cmake option. For backwards compatibility, the ACE_ROOT and TAO_ROOT environment variables are detected and used as well.

3. Orocos Component Library (OCL)

3.1. Caveats

  • This release is binary incompatible with OCL 1.8.x. You need to recompile all your applications in order to upgrade to this release.

3.2. Improvements

  • The DeploymentComponent now supports the pre-loading of a 'site file'. This XML file declares which components or plugins to load or configure by default. It allows for example to set the ComponentPath variable to a site-specific setting.

  • The OCL CAN classes have been cleaned up and refactored and all references to CANOpen have been removed. Also, CAN controller classes for plain Linux Socket CAN and RT-CAN (Xenomai) have been added.

    Patch contributed by S. Kauffmann.

  • Cleanups were done to the IOComponent such that it names ports correctly. Also digital in devices can be added now.

    Patch contributed by S. Kauffmann.

  • The ocl-config.h header file now contains the version number of OCL. See OCL_VERSION_MAJOR, OCL_VERSION_MINOR, OCL_VERSION_PATCH and OCL_VERSION.

  • Similar to RTT (see above), an orocos-ocl.default.cmake template was provided such that the user can create an orocos-ocl.cmake for setting defaults for each build directory, without modifying cmake files from OCL itself.

1. About Orocos

Please send your Orocos questions to orocos-users 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 RTT 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) The SourceWorks

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