Copyright © 2002,2003,2004,2005,2006,2007,2008,2009,2010 Peter Soetens, FMTC
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation, with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of this license can be found at http://www.fsf.org/copyleft/fdl.html.
Revision History | ||
---|---|---|
Revision 1.0.0 | 27 Oct 2006 | ps |
Simplified build system. | ||
Revision 1.0.1 | 21 Nov 2006 | ps |
Updated build/run/doc dependencies. | ||
Revision 1.1.0 | 13 Apr 2007 | ps |
Rewritten for Orocos 1.2.0. | ||
Revision 1.2.1 | 02 June 2007 | ps |
Minor clarifications. | ||
Revision 1.4.0 | 22 Nov 2007 | ps |
Changes in the library name (-target) and .pc files | ||
Revision 1.4.1 | 12 Feb 2008 | ps |
Added Debian/Ubuntu packages install instructions and updated Getting started/Makefile section. | ||
Revision 1.4.2 | 22 Apr 2008 | ps |
Improved/fixed Debian/Ubuntu package install instructions. | ||
Revision 1.6.0 | 02 Aug 2008 | kg |
Added Mac OS X install instructions. | ||
Revision 1.10.0 | 14 Sept 2009 | ps |
Added pointers to win32 install instructions | ||
Revision 1.10.1 | 14 Oct 2009 | ps |
Clarified instructions for non-standard environments, cleanups. | ||
Revision 2.0.0 | 28 Aug 2010 | ps |
Update to 2.0.0 release. | ||
Revision 2.1.0 | 11 Oct 2010 | ps |
Added UseOrocos.cmake macros. |
Abstract
This document explains how the Real-Time Toolkit of Orocos, the Open RObot COntrol Software project must be installed and configured.
Table of Contents
Big Fat Warning | |
---|---|
We're gradually moving the contents of the installation manual into the wiki. Check out the The RTT installation wiki for completeness. |
This sections explains the supported Orocos targets and the Orocos versioning scheme.
Orocos was designed with portability in mind. Currently, we support RTAI/LXRT (http://www.rtai.org), GNU/Linux userspace, Xenomai (Xenomai.org), Mac OS X (apple.com) and native Windows using Microsoft Visual Studio. So, you can first write your software as a normal Linux/Mac OS X program, using the framework for testing and debugging purposes in plain userspace (Linux/Mac OS X) and recompile later to a real-time target or MS Windows.
A particular version is represented by three numbers separated by dots.For example :
2.2.1 : Release 2, Feature update 2, bug-fix revision 1.
Before you install Orocos, verify that you have the following software installed on your platform :
Table 1. Build Requirements
Program / Library | Minimum Version | Description |
---|---|---|
CMake | 2.6.3 (all platforms) | See resources on cmake.org for pre-compiled packages in case your distribution does not support this version |
Boost C++ Library | 1.33.0 (1.40.0 recommended!) | Boost.org from version 1.33.0 on has a very efficient (time/space) lock-free smart pointer implementation which is used by Orocos. 1.36.0 has boost::intrusive which we require on Windows with MSVS. 1.40.0 has a shared_ptr implementation we require when building Service objects. |
Boost C++ Test Library | 1.33.0 (During build only) | Boost.org test library ('unit_test_framework') is required if you build the RTT from source and ENABLE_TESTS=ON (default). The RTT libraries don't depend on this library, it is only used for building our unit tests. |
Boost C++ Thread Library | 1.33.0 (Mac OS-X only) | Boost.org thread library is required on Mac OS-X. |
Boost C++ Serialization Library | 1.37.0 | Boost.org serialization library is required for the type system and the MQueue transport. |
GNU gcc / g++ Compilers | 3.4.0 (Linux/Cygwin/Mac OS X) | gcc.gnu.org Orocos builds with the GCC 4.x series as well. |
MSVS Compilers | 2005 | One can download the MS VisualStudio 2008 Express edition for free. |
Xerces C++ Parser | 2.1 (Optional) | Xerces website Versions 2.1 until 3.1 are known to work. If not found, an internal XML parser is used. |
ACE & TAO | TAO 1.3 (Optional) | ACE & TAO website When you start your components in a networked environment, TAO can be used to set up communication between components. CORBA is used as a 'background' transport and is hidden for normal users. |
Omniorb | 4 (Optional) | Omniorb website Omniorb is more robust and faster than TAO, but has less features. CORBA is used as a 'background' transport and is hidden for normal users. |
All these packages are provided by most Linux distributions. In Mac OS X, you can install them easily using fink or macports. Take also a look on the Orocos.org RTT download page for the latest information.
We documented this on the on-line wiki for the various flavours/options one has on the MS Windows platform: RTT on MS Windows
The RTT uses the CMake build system for configuring and building the library.
The tool you will need is cmake Most linux distros have a cmake package, and so do fink/macports in OS X. In Debian, you can use the official Debian version using
apt-get install cmake
If this does not work for you, you can download cmake from the CMake homepage.
Next, download the orocos-rtt-2.9.0-src.tar.bz2
package from the
Orocos webpage and extract it using :
tar -xvjf orocos-rtt-2.9.0-src.tar.bz2
This section provides quick installation instructions if you want to install the RTT on a standard GNU/Linux system. Please check out Section 3, “Detailed Configuration using 'CMake'” for installation on other OSes and/or if you want to change the default configuration settings.
mkdir orocos-rtt-2.9.0/build
cd orocos-rtt-2.9.0/build
cmake .. -DOROCOS_TARGET=<target> [-DCMAKE_PREFIX_PATH=/opt/orocos] [-DCMAKE_INSTALL_PREFIX=/usr/local] [-DLINUX_SOURCE_DIR=/usr/src/linux]
make
make install
Where
OROCOS_TARGET
:
<target> is one of 'gnulinux', 'lxrt', 'xenomai', 'macosx', 'win32'. When none is specified,
'gnulinux' is used.
CMAKE_PREFIX_PATH
: used to specify
places to look for libraries such as Boost, TAO/ACE etc.
CMAKE_INSTALL_PREFIX
: specifies where
to install the RTT.
LINUX_SOURCE_DIR
: is required for RTAI/LXRT
and older Xenomai version (<2.2.0). It points to
the source location of the RTAI/Xenomai patched Linux kernel.
Note | |
---|---|
See Section 3, “Detailed Configuration using 'CMake'” for specifying non standard include and library paths to search for dependencies. |
The make command will have created a
liborocos-rtt-<target>.so
library, and if
CORBA is enabled a liborocos-rtt-corba-<target>.so
library.
The make docapi and make docpdf dochtml (both in 'build') commands build API documentation and PDF/HTML documentation in the build/doc directory.
Orocos can optionally ( but recommended) be installed on your system with
make install
The default directory is
/usr/local
, but can be changed
with the CMAKE_INSTALL_PREFIX
option :
cmake .. -DCMAKE_INSTALL_PREFIX=/opt/orocos/
If you choose not to install Orocos, you can find the build's result
in the build/rtt
directory.
This Section provides a short overview of how to proceed next using the Orocos Real-Time Toolkit.
We're still porting the examples to the 2.x API. The most up to date examples are the RTT 2.x exercises which you can find on the Getting Started webpage.
Below, we provide two ways of building Orocos components: using CMake or a plain Makefile. Use this in combination with the code found in the Orocos Component Builder's Manual.
Example 1. A CMakeLists.txt file for an Orocos Application or Component
Note | |
---|---|
This file is automatically generated for you when you use the >orocreate-pkg program. |
You can build a component using this example CMakeLists.txt file:
cmake_minimum_required(VERSION 2.6.3) project(myrobot) find_package(Orocos-RTT) # Defines all our macros below: include(${OROCOS-RTT_USE_FILE_PATH}/UseOROCOS-RTT.cmake) # Creates libhardware.so, libvcontrol.so and libpcontrol.so # and installs in lib/orocos/myrobot/ orocos_component(hardware hardware.cpp) orocos_component(vcontrol VelocityControl.cpp) orocos_component(pcontrol PositionControl.cpp) # Each .cpp file contains one Orocos Component, using the # ORO_CREATE_COMPONENT macro. # Creates libmyrobot-support.so and installs it in # lib/ orocos_library(support support.cpp) # support.cpp is a 'helper' library you wrote. # Creates libmyrobot-types.so typekit using typegen # and installs it in lib/orocos/myrobot/types/ orocos_typegen_headers(RobotControlData.hpp RobotMeasurements.hpp) # These are headers that define the data types your # components understand # Creates libmyrobot-debug.so # and installs in lib/orocos/myrobot/plugins/ orocos_plugin(myrobot-debug debugrobot.cpp) # debugrobot.cpp must implement the RTT plugin API. # Installs header in include/orocos/myrobot orocos_install_headers( hardware.hpp ) # Just some header you like to install # Finishes up our package by generating a set of .pc files # This allows other packages to depend on this package and # automatically link with it. orocos_generate_package()
Example 2. A Makefile for an Orocos Application or Component
Note | |
---|---|
We strongly recommend using the cmake macros above. |
You can compile your program with a Makefile resembling this one :
OROPATH=/usr/local all: myprogram mycomponent.so # Build a purely RTT application for gnulinux (not recommended). # Use the 'OCL' settings below if you use the TaskBrowser or other OCL functionality. # CXXFLAGS=`PKG_CONFIG_PATH=${OROPATH}/lib/pkgconfig pkg-config orocos-rtt-gnulinux --cflags` LDFLAGS=`PKG_CONFIG_PATH=${OROPATH}/lib/pkgconfig pkg-config orocos-rtt-gnulinux --libs` myprogram: myprogram.cpp g++ myprogram.cpp ${CXXFLAGS} ${LDFLAGS} -o myprogram # Building dynamic loadable components requires the OCL to be installed as well: # CXXFLAGS=`PKG_CONFIG_PATH=${OROPATH}/lib/pkgconfig pkg-config orocos-ocl-gnulinux --cflags` LDFLAGS=`PKG_CONFIG_PATH=${OROPATH}/lib/pkgconfig pkg-config orocos-ocl-gnulinux --libs` mycomonent.so: mycomponent.cpp g++ mycomponent.cpp ${CXXFLAGS} ${LDFLAGS} -fPIC -shared -DRTT_COMPONENT -o mycomponent.so
Where your replace gnulinux with the target
for which you wish to compile. If you use parts of the OCL,
use the flags from orocos-ocl-gnulinux
.
We recommend reading the Deployment Component manual for building and loading Orocos components into an application.
These flags must be extended with compile and link options for your particular application.
Important | |
---|---|
The |
Note | |
---|---|
Make sure you have read Section 3, “Detailed Configuration using 'CMake'” for your target if you application has compilation or link errors ( for example when using LXRT ). |
In case you also want to write an executable that runs components, your main() function needs to be named ORO_main().
Some care must be taken in initialising the realtime
environment. First of all, you need to provide a function
int ORO_main(int argc, char** argv)
{...}
, defined in <rtt/os/main.h> which contains your program :
#include <rtt/os/main.h> int ORO_main(int argc, char** argv) { // Your code, do not use 'exit()', use 'return' to // allow Orocos to cleanup system resources. }
If you do not use this function, it is possible that some (OS dependent) Orocos functionality will not work.
If you have some of the Orocos dependencies installed in
non-standard locations, you have to specify
this using cmake variables before running
the cmake configuration. Specify header locations using
the CMAKE_INCLUDE_PATH
variable (e.g. using
bash and fink in Mac OS X, the boost library headers are
installed in /sw/include, so you would specify
export CMAKE_INCLUDE_PATH=/sw/include;/boost/include
For libraries in not default locations, use the
export CMAKE_LIBRARY_PATH=/sw/libs;/boost/lib
variable. When your installation directory has a standard layout, you can also use a single
export CMAKE_PREFIX_PATH=/boost
statement. For more information, see cmake useful variables link.
Important | |
---|---|
In order to avoid setting these global exports repeatedly, the RTT
build system reads a file in which you can specify your
build environment. This file is the |
The RTT can be configured depending on your target. For embedded targets, the large scripting infrastructure and use of exceptions can be left out. When CORBA is available, an additional library is built which allows components to communicate over a network.
In order to configure the RTT in detail, you need to invoke the ccmake command:
cd orocos-rtt-2.9.0/build
ccmake ..
from your build directory. It will offer a configuration screen. The keys to use are 'arrows'/'enter' to modify a setting, 'c' to run a configuration check (may be required multiple times), 'g' to generate the makefiles. If an additional configuration check is required, the 'g' key can not be used and you must press again 'c' and examine the output.
In order to enable CORBA, a valid installation of TAO or OMNIORB must be
detected on your system and you must turn the ENABLE_CORBA
option on (using ccmake).
Enabling CORBA does not modify the RTT library and
builds and installs an additional library and headers.
Alternatively, you can re-run cmake:
cmake .. -DENABLE_CORBA=ON
See Section 3.6, “Configuring for CORBA” for full configuration details when using the CORBA transport.
Move to the OROCOS_TARGET
, press enter and type
on of the following supported targets (all in lowercase):
gnulinux
macosx
xenomai
lxrt
win32
The xenomai and lxrt targets require the presence of the
LINUX_SOURCE_DIR
option since these targets
require Linux headers during the Orocos build. To use the
LibC Kernel headers in
/usr/include/linux
, specify
/usr
. Inspect the output to find any errors.
Note | |
---|---|
From Xenomai version 2.2.0 on, Xenomai configuration does no longer require the --with-linux option. |
You can set the compiler flags using the CMAKE_BUILD_TYPE
option. You may edit this field to contain:
Release
Debug
RelWithDebInfo
MinSizeRel
None
In case you choose None, you must set the CMAKE_C_FLAGS, CMAKE_CXX_FLAGS manually. Consult the CMake manuals for all details.
Orocos has been tested with RTAI 3.0, 3.1, 3.2, 3.3, 3.4, 3.5 and 3.6.
The latest version of RTAI is recommended for RTAI users.
You can obtain it from
the RTAI home page.
Read The README.* files in the
rtai
directory for detailed
build instructions, as these depend on the RTAI version.
RTAI comes with documentation for configuration and installation. During 'make menuconfig', make sure that you enable the following options (in addition to options you feel you need for your application) :
General -> 'Enable extended configuration mode'
Core System -> Native RTAI schedulers > Scheduler options -> 'Number of LXRT slots' ('1000')
Machine -> 'Enable FPU support'
Core System -> Native RTAI schedulers > IPC support -> Semaphores, Fifos, Bits (or Events) and Mailboxes
Add-ons -> 'Comedi Support over LXRT' (if you intend to use the Orocos Comedi Drivers)
Core System -> Native RTAI schedulers > 'LXRT scheduler (kernel and user-space tasks)'
After configuring you must run 'make' and 'make install' in your RTAI directory: make sudo make install
After installation, RTAI can be found in
/usr/realtime
. You'll have to specify
this directory in the RTAI_INSTALL_DIR
option
during 'ccmake'.
LXRT is a all-in-one scheduler that works for kernel and userspace. So if you use this, you can still run kernel programs but have the ability to run realtime programs in userspace. Orocos provides you the libraries to build these programs. Make sure that the following RTAI kernel modules are loaded
rtai_sem
rtai_lxrt
rtai_hal
adeos (depends on RTAI version)
For example, by executing as root: modprobe rtai_lxrt; modprobe rtai_sem.
Application which use LXRT as a target need special flags when being compiled and linked. Especially :
Compiling : -I/usr/realtime/include
This is the RTAI headers installation directory.
Linking : -L/usr/realtime/lib -llxrt
for dynamic (.so) linking OR add
/usr/realtime/liblxrt.a
for static (.a) linking.
Important | |
---|---|
You might also need to add
|
Note | |
---|---|
For older Xenomai versions, consult the Xenomai README of that version. |
Xenomai provides a real-time scheduler for Linux applications.
See the Xenomai home
page. Xenomai requires a patch one needs to apply upon
the Linux kernel, using the
scripts/prepare-kernel.sh script. See the
Xenomai installation manual. When applied, one needs to enable
the General Setup -> Interrupt Pipeline
option during Linux kernel configuration and next the
Real-Time Sub-system ->
,
Xenomai
and Nucleus
. Enable
the Native
skin, Semaphores
,
Mutexes
and Memory Heap
. Finally
enable the Posix
skin as well.
When the Linux kernel is built, do in the Xenomai directory: ./configure ; make; make install.
You'll have to specify the install directory in the
CMAKE_PATH_PREFIX
option during 'cmake'.
The RTT uses the native Xenomai API to address the real-time
scheduler. The Xenomai kernel modules can be found in
/usr/xenomai/modules
. Only the
following kernel modules need to be loaded:
xeno_hal.ko
xeno_nucleus.ko
xeno_native.ko
in that order. For example, by executing as root: insmod xeno_hal.ko; insmod xeno_nucleus.ko; insmod xeno_native.ko.
Application which use Xenomai as a target need special flags when being compiled and linked. Especially :
Compiling : -I/usr/xenomai/include
This is the Xenomai headers installation directory.
Linking : -L/usr/xenomai/lib
-lnative
for dynamic (.so) linking OR add
/usr/xenomai/libnative.a
for
static (.a) linking.
Important | |
---|---|
You might also need to add
|
In case your application benefits from remote access over a network, the RTT can be used with 'The Ace Orb' ( TAO) or OMNIORB-4. The RTT was tested with TAO 1.3.x, 1.4.x, 1.5x and 1.6.x and OMNIORB 4.1.x. There are two major TAO development lines. One line is prepared by OCI (Object Computing Inc.) and the other by the DOC group. You can find the latest OCI TAO version on OCI's TAO website. The DOC group's TAO version can be found on the Real-time CORBA with TAO (The ACE ORB) website. Debian and Ubuntu users use the latter version when they install from .deb packages.
If you need commercial support for any TAO release or seek expert advice on which TAO version or development line to use, consult the commercial support website.
Important | |
---|---|
Debian or Ubuntu users can skip this step and just do sudo aptitude install libtao-orbsvcs-dev tao-idl gperf-ace tao-naming . Orocos software will automatically detect the installed TAO software. |
Note | |
---|---|
If your distribution does not provide the TAO libraries, or you want to use the OCI version, you need to build manually. These instructions are for building on Linux. See the ACE and TAO installation manuals for building on your platform. Orocos requires the ACE, TAO and TAO-orbsvcs libraries and header files to be installed on your workstation. If you used manual installation, the ACE_ROOT and TAO_ROOT variables must be set. |
You need to make an ACE/TAO build on your workstation.
Download the package here: OCI
Download. Unpack the tar-ball, and enter
ACE_wrappers
. Then do:
export ACE_ROOT=$(pwd)
export TAO_ROOT=$(pwd)/TAO
Configure ACE for Linux by doing:
ln -s ace/config-linux.h ace/config.h
ln -s include/makeinclude/platform_linux.GNU include/makeinclude/platform_macros.GNU
Finally, type:
make
cd TAO
make
cd orbsvcs
make
This finishes your TAO build.
Orocos RTT defaults to TAO. If you want to use the
OMNIORB implementation, run from your build
directory:
cmake .. -DENABLE_CORBA=ON -DCORBA_IMPLEMENTATION=OMNIORB
To specify TAO explicitly (or change back) use:
cmake .. -DENABLE_CORBA=ON -DCORBA_IMPLEMENTATION=TAO
The RTT will first try to detect your location of ACE and
TAO using the ACE_ROOT and TAO_ROOT variables and if these
are not set, using the standard include paths. If TAO or
OMNIORB is found you can enable CORBA support
(ENABLE_CORBA
) within CMake.
Once you compile and link your application with Orocos and with the CORBA functionality enabled, you must provide the correct include and link flags in your own Makefile if TAO and ACE are not installed in the default path. Then you must add:
Compiling : -I/path/to/ACE_wrappers -I/path/to/ACE_wrappers/TAO -I/path/to/ACE_wrappers/TAO/orbsvcs
This is the ACE build directory in case you use OCI's TAO packages. This option is not needed if you used your distribution's TAO installation, in that case, TAO is in the standard include path.
Linking : -L/path/to/ACE_wrappers/lib -lTAO -lACE -lTAO_PortableServer -lTAO_CosNaming
This is again the ACE build directory in case you use OCI's TAO packages. The first option is not needed if you used your distribution's TAO installation, in that case, TAO is in the standard library path.
Important | |
---|---|
You also need to add
export LD_LIBRARY_PATH=/path/to/ACE_wrappers/lib . |
This section lists some points of attention when cross-compiling Orocos.
Run plain "cmake" or "ccmake" with the following options:
CC=cross-gcc CXX=cross-g++ LD=cross-ld cmake .. -DCROSS_COMPILE=cross-
and substitute the 'cross-' prefix with your target tripplet, for example with 'powerpc-linux-gnu-'. This works roughly when running on Linux stations, but is not the official 'CMake' approach.
For having native cross compilation support, follow the instructions on the CMake Cross Compiling page.