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

Open RObot COntrol Software


Table of Contents

1. Caveats
2. Improvements
2.1. Scripting
2.2. OS Abstraction
2.3. RTT classes
2.4. Corba Support
3. Orocos Component Library
3.1. Caveats
3.2. Improvements
1. About Orocos

This document provides a quick overview of what changed between the Real-Time Toolkit 1.4 and version 1.6. This release includes all bugfixes of the 1.4 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.4.x. You need to recompile all your applications in order to upgrade to this release.

  • The AnalogInInterface, AnalogOutInterface AnalogInput and AnalogOutput classes have a slightly changed interface. This makes them incompatible with RTT 1.4 and older. The template parameter has been dropped and the default 'raw' value is now int. In this way, two's complement and unsigned A/D converters are supported upto 31 bits. This change did also change the Comedi API in OCL, see below.

    See also AnalogIn/OutInterface is an atrocity. .

2. Improvements

2.1. Scripting

  • Scripting now supports automatic type converions. This means you can provide an integer argument where a double is expected and vice verse. The 'C++ style cast' is supported as well. One can write for example

    var int i = int(3.456); // i == 3

    Conversions that reduce precision will print a Logger warning during parsing, unless this explicit cast is used.

    See also [Scripting]No conversions available from int -> double ->... .

  • Scripting now also supports the C 'float' type. You can now write

    var float f = 10.0f;

  • Event based transitions in statemachines are now always asynchronous and can be received during the entry and run programs. State machines can react immediately in the same state to events emited in the entry program. Events emited in the run program can only be processed in the next execution step of the state machine.

  • Event transitions in statemachines can now be written more naturally. The if and select statements are optional when a transition program is given. For example:

      transition some_event(a) { do foo(a); }
      transition some_event(a) if (a < 10.0) then { do foo(a); }
    	    

    See also Unable have event transition with no select statements .

  • The transition syntax has been unified. One can write both condition and event transitions in transitions blocks or with the keyword transition. For example:

      transition if (a < 10.0) { do foo(a); }
      transitions {
          some_event(a) if (a < 10.0) then { do foo(a); }
          // ... repeat
      }

  • Both condition and event transitions can be specified at the top level of a state machine. These 'global' transitions apply to any state of that state machine and are evaluated after the transitions of the current state.

  • There was a bug in the parser such that calling a method on an unknown object resulted in calling the method on the current object. This had very confusing consequences, such as when using:

      do scripting.loadProgram("the_program.ops");
      do the_program.start();

    Which would load fine, but start() would return in error. The correct behaviour is to signal an error during loading that 'the_program' is not yet known (It only becomes known after loadProgram is executed).

2.2. OS Abstraction

  • The RTT has been adapted for the Preempt-RT Linux kernel patch, using the monotonic real-time clock infrastructure for real-time periodic execution. See Periodicity of thread not guaranteed under (preempt-rt) gnulinux .

  • An initial Max OS-X port has been done (RTT and OCL), and stable enough for broader testing. The Orocos target name for Mac OS-X is 'macosx'. See Mac OS X port .

  • The main() function has been removed from the Orocos library and is now a macro that expands in user code. This greatly improves debugging, as some (most) debuggers don't look in libraries for the main() function. Also, this makes it easier to define your own ORO_main function.

2.3. RTT classes

  • The DataPort and BufferPort classes and base classes have been refactored for lower code size and faster execution. This change is backwards compatible, except for the (internal) createConnection(PortInterface*) function, which has disappeared. Use connectTo(PortInterface*) instead.

    See also .

  • It is now possible to load new Properties from XML files into a TaskContext. This is done using the loadProperties() function, available in the C++ MarshallingAccess interface and also in the scripting interface. This allows to load new parameters into a component, even after it was compiled. You can use this to provide extra parameters to (multiple) scripts for example.

    See also [Project] Allow to load extra properties from file in a TaskContext .

  • The TaskContext interface classes (commands, methods, events, properties,...) now all have a remove...() function to selectively remove elements from the interface again.

    See also Method-Command repositories do not have removeX .

  • The Logger class has been restored to correctly log the [Location] tag after recursing into functions.

    See also Logger In() instances do not nest correctly .

2.4. Corba Support

  • CORBA DataPorts have been thoroughly tested and fixed. They now respect connection direction and can also be connected using only the IDL interface. Also, the ports disconnect automatically when a remote connection no longer exists, making it free again to setup a new connection.

    See also Corba Data/Buffer ports do not respect connection direction .

    See also Can not connect ports using only IDL interface .

  • Completely transparant Method and Command invocation in C++ on remote CORBA TaskContexts has been added (this was already available in the scripting interface). This feature however increases code size, even if CORBA is not used. A CMake variable ORO_REMOTING has been defined which allows to turn this feature off. It is enabled by default if you build the RTT with the CORBA protocol library.

    See also getMethod<...>("name") does not work for remote/CORBA components .

3. Orocos Component Library

3.1. Caveats

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

  • The Comedi API in OCL has changed to the API of the new RTT base classes. Also, Comedi classes moved from the RTT to the OCL namespace.

    See also AnalogIn/OutInterface is an atrocity. .

  • The ComediPulseTrainGenerator and ComediEncoder classes (previously only compatible with a patched version of Comedi) have been rewritten such that they now use the ComediLib 0.8 API. This also caused a change in the ComediPulseTrainGenerator constructor: the subdevice specifies the counter to be used (starting from '2') and the channel parameter has been dropped.

    See also Comedi layer is lagging behind comedi releases .

  • The Axis and related classes from the OCL hardware package have been moved to the OCL namespace.

    See also hardware/axes/dev classes should not be RTT namespace. .

3.2. Improvements

  • Most components in the OCL are now at run-time loadable by the DeploymentComponent (deployer application).

  • Orocos better intercepts lost connections to remote TaskContexts. The Orocos Component Library's deployer and taskbrowser use this infrastructure to detect and cope with lost connections.

    See also CORBA Connections may cause TRANSIENT exception when server exited .

  • The OCL CORBA deployer can now create CORBA servers and CORBA proxies for any component type. When a local component is created, one can set the boolean Server property to 1, in which case it is exported as a ControlTask CORBA server using the naming service. If the naming service is not available, set the boolean property UseNamingService to 0. In that case, an IOR file is generated. The server() method of the deployer adds the same functionality in the scripting interface.

    CORBA proxies can be created in three ways: by using the naming service, by using an IOR file or by specifying the IOR literally. This is done by specifying the 'type' field of the component as "CORBA", "IORFile" or "IOR" and providing the registered name, IOR file location or IOR respectively in the 'name' field.

    See also [Project] deployer can not connect to CORBA components .

  • The AutoConnect feature of the deployer now also works across distributed components, provided that both components have the AutoConnect option set in the XML configuration and that one is known as a peer to the other.

  • An Include feature has been added to the deployer's XML file syntax. This directive allows to include another XML file in place such that you can better manage multiple XML files or share XML files between users.

  • The deployer logs improved diagnostics in stopComponents, startComponents,... family of functions.

  • The deployer does 'spell' checking for unknown or misspelled XML 'name' attributes, which goes further than the standard XML syntax checking.

  • The DeploymentComponent can be configured itself by using its name in the XML configuration file. In this way, you can add an activity or load a script into this component.

  • The taskbrowser can be compiled with the -DNO_GPL flag such that it does not contain any GPL'ed code. This flag removes the dependency on the GPL readline library. TAB-completion and history are not available in that case.

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) FMTC

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