Table of Contents
This document provides a quick overview of what changed between the Real-Time Toolkit 1.6 and version 1.8. This release includes all bugfixes of the 1.6 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.
This release is binary incompatible with RTT 1.6.x. You need to recompile all your applications in order to upgrade to this release.
The CommandProcessor did only process one command in each step() function (ie for each time the user's updateHook() was executed, the CommandProcessor only processed one command). This caused commands to be left in the queue when using NonPeriodicActivity. The CommandProcessor now processes all commands in queue during a single step() (analogous to the EventProcessor). You have to change your application logic if you relied on the old behaviour somehow.
A thread creation bug (a regression) was fixed when running in the gnulinux target and no pam limits were set.
The TaskContext has gained a new default execution model. Previously, a newly created TaskContext object could not be started and had no activity assigned. With this release, each created TaskContext gets automatically a SequentialActivity assigned, which allows it to start running and process commands and events. There is no thread created for this Activity, the commands and events are processed in the thread of the caller (thus sequentially). This activity implementation is equally thread-safe as the other RTT activities. See the Component Builder's Manual for an example.
The TaskContext has gained Event
based Data and Buffer port processing. This allows non-periodic
or sequential TaskContext objects to wake up when input on plain data ports arrives.
A new function ports()->addEventPort( &a_port, "Description")
has been added to the interface to register a port for event-based
reception. See the Component Builder's Manual for an example.
Contributed by S. Joyeux.
The TaskContext interface gained
a getActivity() function which always returns
a valid object and is equivalent to the old notation
engine()->getActivity(). Further more, the
setActivity(ActivityInterface* ) function has
been added to assign an activity to a TaskContext. The TaskContext
owns the assigned activity object and manages memory
allocation. The new usage pattern is then for example:
a_task.setActivity( new PeriodicActivity(0.01) );
ActivityInterface::trigger() and start() behaviour of non-periodic threads/activities was documented and fixed. SingleThread::start() (which is called by these) returns now also true when a loop() is still being scheduled.
The Logger class has been extended such that
it can be queried for the current 'log message' time. The OCL
ReportingComponent can use this to synchronise data logs with message
logs with the property Synchronize.
Several issues in the Event class were fixed when using heavily threaded applications. At the same time, the lock-based event implementation has been re-added and tested but can only be enabled by changing a define in signal_base.hpp.
The RTT has been adapted to work with Boost versions up to 1.37.x.
This release is binary incompatible with OCL 1.6.x. You need to recompile all your applications in order to upgrade to this release.
The interface of the DeploymentComponent changed slightly.
kickOut(void) has been renamed to kickOutAll(void)
and two new functions kickOut(std::string file_name),
kickOutComponent(std::string comp_name) which unload a series
of components described in a file or a single component by name respectively.
This was done for equivalence with the kickStart* methods.
The Property file format of the Reporting Component has changed. The component is now configured from a single property file, which must be read using 'LoadProperties' (XML) or 'marshalling().loadProperties(file)' (scripting). See the OCL Reporting Component Manual for all details.
The DeploymentComponent has better support for unloading/reloading components using XML files and error handling during the configuration steps. Loading additional components in a configured and running system is now possible.
Contributed by D. Faconti
The DeploymentComponent gained the ability to use
LoadProperties (in addition to the
UpdateProperties and
PropertyFile elements) in the XML
configuration file. This allows to load new properties into
any existing component.
Finally, a Properties element has
been added in case you want to set (default) properties in
the deployment XML file. This makes the use of an external
property file optional.
It is now possible to specify which component is Master when specifying a Slave activity in the deployment XML file. Also, each slave becomes automatically a peer of its master.
The Deployment component now looks for a 'site local' XML file in the current directory. This allows to pre-set the component path and load local libraries or site specific components.
The Deployment component's file format got the 'AutoSave' property for each loaded component. When set to 1, it causes the properties of the component to be saved to disk, using the same file name as used in LoadProperties, PropertyFile or UpdateProperties. If no file is given, a warning is issued and nothing is saved.
The Deployment component now also detects .dylib libraries on Mac
Contributed by S. Roderick.
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) FMTC
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.