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

Orocos RTT is now built with the 'CMake' tool, instead of the automake tool previously. See the installation manual for the new build instructions. The installed libraries and header files names and locations have not changed. However, the pkgconf directory has disappeared and is replaced with the rtt/rtt-config.h file, which contains the same defined macros.

The new build system may on your system detect installed libraries differently than in version 1.0. If you encounter problems, notify the orocos-dev mailinglist and a hotfix will be prepared.

See also Change Orocos directory structure and [Project]Build shared libraries .

Support for real-time PowerPC (40x and 60x were tested) has been added. The functionality has been tested with a Linux 2.4 PPC kernel (patched for Xenomai), with gcc 3.3.6 and glibc 2.2.5 but should work with other kernels and compilers as well.

See also Rethink the os/oro_*.h assembly functions .

The necessary files have been added to run Orocos RTT on eCos. However, you need to create a specially crafted C++ GNU toolchain, see libstdc++ for eCos, because the free eCos version does not supply a Standard C++ toolchain. See also [Project] eCos Port .

An rtos_task_yield() function is now required in the FOSI layer, which maps to the yield function of your OS. If your OS does not support a 'thread yield', you may implement this as an empty function.

Two functions, int rtos_task_check_scheduler(int* scheduler) and int rtos_task_check_priority(int* scheduler, int* priority), have been added to the internal FOSI layer. Each OS must implement these functions and check the arguments for validity.

See also RTT does not provide means to check scheduler/priority combos .

The SingleThread and the NonPeriodicActivity threading classes had undefined semantics for start() and stop() with respect to loop() in case start() was called multiple times in a row. With the old behaviour, start() invocations had an accumulative effect, causing loop() to be executed as much as start() was called, even after stop() was called. The new behaviour only allows start() to succeed if loop() is not executing. stop() will only return when loop() finishes.

See also loopActivity .

See the above remark about the changed behaviour of NonPeriodicActivity.

The TaskContext startup(), update(), shutdown() user functions are in the process of being renamed. They are still valid, but deprecated and new applications should no longer use these names. The new names are startHook(), updateHook() and stopHook(). The new naming is less confusing in combination with the new configuration state of the TaskContext (see below). Existing RTT 1.0.x applications using the old naming remain working.

See also TaskContext offers no configuration function .

The programs.MyProgram and states.MyStateMachine prefixes, required to access loaded programs and statemachines has been dropped. One can now address a TaskContext program or state machine by just writing MyProgram or MyStateMachine in a script. The parser will not allow name clashes between script names and TaskContext objects. The parser has been modified to allow the old syntax and warn the user of the change.

See also [Project]Refactor TaskObject vs TaskContext .

Program and state machine scripts are no longer loaded as TaskContext C++ objects but as TaskObject C++ objects. In practice, this has no effect on existing applications, unless the user uses getPeer() in order to access loaded scripts (instead of the recommended states(), programs() or execution()). In that case, the user needs to call getObject() instead of getPeer() or revert to the recommended functions.

See also [Project]Refactor TaskObject vs TaskContext .

Toolkit plugins which use the RTT::TemplateTypeInfo class to add user data types to the Real-Time Toolkit must provide operator>> as well for their type when 'use_ostream' is enabled. In other words, if you defined operator<< for your toolkit type, you now also need to define operator>>.

See also Toolkit Plugins should provide read()/operator>> as well .

When a PropertyBag object is stored in an XML struct element, it previously had the type="type_less" attribute. XML files written by RTT 1.2.0 will use the type="PropertyBag" attribute (conforming scripting naming). If an old-style file is found, it is automatically converted.

When a std::vector<double> property is stored in an XML struct element, it previously had the type type="std::vector&lt;double&gt;" attribute. XML files written by RTT 1.2.0 will use the type="array" attribute (conforming scripting naming). Also, the 'Size' element is no longer required and may be omitted. The elements of the array struct also no longer require a name, and the name is ignored. The ordering in the file counts as index number. If an old-style file is found, it is automatically converted.

See also [Project]XML format: change of type="xyz" fields .

The ControlTask class and related classes have been extended to map to the TaskContext and TaskObject interface.

When the RTT is built as a shared library (default), dependent libraries, such as the OCL, KDL or your own library which includes RTT headers, must also be a shared library. If you do not obey this rule, crashes or compilation errors may occur. It is not yet clear if this is a bug in the GNU linker or expected behaviour.

See also Mixing liborocos-rtt.a and .so causes crash upon exit .

From release 1.2.0 on, Orocos RTT is built by default as a shared library. This significantly improves link times and application development times. It also allows dynamic component deployment in the Orocos Component Library.

The TaskContext class has been extended to support a configuration state. A component now has a configure() and cleanup() method to configure the component or free all resources. If a component is not configured, it will refuse to start running. The associated user functions (configureHook() and cleanupHook()) allow the user to control the transitions.

See also TaskContext offers no configuration function .

The PeriodicActivity and NonPeriodicActivity classes have received additional constructors which allow to set the scheduler type to ORO_SCHED_RT (default) or ORO_SCHED_OTHER. This allows easier creation of not real-time threads in the Orocos RTT.

See also Priority and scheduler of activities .

The PeriodicActivity class could no longer be started if its thread was stopped for some reason. If the thread is not running, it tries to start it again.

See also PeriodicActivity does not start PeriodicThread if necessary. .

From release 1.2.0 on, Orocos RTT has better build and run-time support for Corba (using ACE/TAO). Remote modification of component parameters has been improved and is taken advantage of by the Corba based KTaskbrowser 1.2.