Frequently asked questions (FAQ)

Future home of FAQ

How to build Debian packages

Rationale

You want to build debian packages once, so that you can install on multiple machines without building from source on each.

Assumptions

  1. You are building for gnulinux only.
  2. You have "svn-b", etc, alises setup (see "man svn-buildpackage").
  3. You are using Synaptic as your package manager.
  4. Example code is for Orocos v1.8, but also applies to later versions, including 2.x
  5. BASE_DIR is whatever directory you want to put everything into.

To build the Orocos RTT packages (1.x)

cd BASE_DIR
svn co ...
cd rtt
debchange -v 1.8.0-0
cd debian
./create-control.sh gnulinux    # optionally add "lxrt", "xenomai"
svn add *1.8*install
cd ..
export DEB_BUILD_OPTIONS="parallel=2"    # or 4, 8, depending on your computer
svn-br     # or svn-b

Packages are built into BASE_DIR/build-area.

To build the Orocos RTT packages (2.x)

cd BASE_DIR
git clone http://git.gitorious.org/orocos-toolchain/rtt.git
cd rtt
debchange -v 2.3.0-1
cd debian
./create-control.sh gnulinux    # optionally add "lxrt", "xenomai"
git add *2.3*install
git commit -sm"2.3 release install files"
cd ..
export DEB_BUILD_OPTIONS="parallel=2"    # or 4, 8, depending on your computer
git-buildpackage --git-upstream-branch=origin

Packages are built into BASE_DIR/build-area.

Make the packages available to your package manager

Create your own repository

cd BASE_DIR
dpkg-scanpackages build_area /dev/null | gzip -9c > Packages.gz

Now open/etc/apt/sources.list in your favorite editor, and append the following lines to the bottom (substituting the full path to your repos for /path/to/BASE_DIR/).

# Orocos packages
deb file:///path/to/BASE_DIR/ ./

Open Synaptic, reload, search for orocos and install.

KDL and OCL

Follow the same basic approach first for KDL, then for OCL

  1. build packages
  2. update the repository doing just the "dpkg-scanpackages" line again
  3. install

NB KDL and OCL will happily both build into "build_area" alongside RTT.

Test installed packages

  • 1.x: Build the quicky components. Requires OCL (install at least the

orocos-ocl-gnulinux1.8-bin and liborocos-ocl-gnulinux1.8-dev packages).

# 1.x:
svn co ...
cd quicky
mkdir build && cd build
cmake ..
make
 
# one of the following two exports, depending on your situation
export LD_LIBRARY_PATH=.
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:.
 
deployer-gnulinux -s ../quicky.xml
ls Quicky   # you should see Data_W != 0

  • 2.x: Run 'orocreate-pkg testme' and try to build the testme package.

orocreate-pkg testme
cd testme
 
#non-ROS:
make install
#ROS:
make
 
deployer-gnulinux 
> import("testme")
> displayComponentTypes()

Test CORBA deployer

These instructions test inter-process communication on the same machine. See [2] for more details on running CORBA-based deployers between computers.

In the first shell start the naming service and the deployer 

Naming_Service -m 0 -ORBDottedDecimalAddresses 1 -ORBListenEndpoints  iiop://127.0.0.1:2809 -ORBDaemon
export NameServiceIOR=corbaloc:iiop:127.0.0.1:2809/NameService
deployer-corba-gnulinux -s ../quicky.xml -- -ORBDottedDecimalAddresses 1
ls Quicky   # you should see Data_W != 0

In the second shell run the taskbrowser and see the Quicky component running in the deployer 

export NameServiceIOR=corbaloc:iiop:127.0.0.1:2809/NameService
ctaskbrowser-gnulinux Deployer -ORBDottedDecimalAddresses 1
ls Quicky   # you should see Data_W != 0

Gotchas

If the v1.8 files have already been committed to the repository, then you don't need the debchange and svn add commands when building the packages.

Make repository available to other machines

See [1] below.

References

[1] http://www.debian.org/doc/manuals/repository-howto/repository-howto#setting-up [2] http://orocos.org/wiki/rtt/frequently-asked-questions-faq/using-corba

How to re-build Debian packages

This page describes how to re-build debian packages for another Debian/Ubuntu release than they were prepared for.

Note1: This only applies if you want to use the same version as the version in the package repository. If you want a newer version, consult How to build Debian packages.

Note2: The steps below will rebuild Orocos for all targets in the repository, so lxrt, xenomai and gnulinux. If you care only for one of these targets, see also How to build Debian packages.

First, make sure you added this deb-src line to your sources.list file: 

deb-src http://www.fmtc.be/debian etch main
Next, type from your 'HOME/src' directory:

sudo apt-get update
apt-get source orocos-rtt
sudo apt-get build-dep orocos-rtt
sudo apt-get install devscripts build-essential fakeroot dpatch
cd orocos-rtt-1.6.0
dpkg-buildpackage -rfakeroot -uc -us
cd ..
for i in *.deb; do sudo dpkg -i \$i; done

You can repeat the same process for orocos-ocl.

Using CORBA

Outlines how to use CORBA to distribute applications. Differs by CORBA implementation and whether you are using DNS names or IP addresses. Examples below support the ACE/TAO and OmniORB CORBA implementations.

Sample system:

  • Deploying components in demo.xml with deployer-corba, on machine1.me.home with IP address 192.168.12.132
  • Running a GUI program demogui to connect to deployer components, on machine2.me.home with IP address 192.168.12.133
  • Use a name server without multi-casting[1], on machine1.me.home.
  • Using a bash shell.
  • Both machines are gnulinux (though this has been verified with macosx, and mixing macosx and gnulinux)

Working DNS

If you have working forward and reverse DNS entries (ie dig machine1.me.home returns 192.168.12.132, and dig -x 192.168.12.132 returns machine1.me.home)

ACE/TAO

machine1 \$ Naming_Service -m 0 -ORBListenEndpoints iiop://machine1.me.home:2809 \
-ORBDaemon &
machine1 \$ export NameServiceIOR=corbaloc:iiop:machine1.me.home:2809/NameService
machine1 \$ deployer-corba-gnulinux -s demo.xml
 
machine2 \$ export NameServiceIOR=corbaloc:iiop:machine1.me.home:2809/NameService
machine2 \$ ./demogui

OmniORB

OmniORB does not support the NameServiceIOR environment variable

machine1 \$ omniNames -start &
machine1 \$ deployer-corba-gnulinux -s demo.xml  
 
machine2 \$ ./demogui -ORBInitRef NameService=corbaloc:iiop:machine1.me.home:2809/NameService

Note that if you swap which machines run the deployer and demogui, then change the above to

machine1 \$ omniNames -start &
 
machine2 \$ deployer-corba-gnulinux -s demo.xml  -- \
-ORBInitRef NameService=corbaloc:iiop:machine1.me.home:2809/NameService
 
machine1 \$ ./demogui

Non-working DNS or you must use IP addresses

If you don't have DNS or you must use IP addresses for some reason.

ACE/TAO

machine1 \$ Naming_Service -m 0 -ORBDottedDecimalAddresses 1 \
-ORBListenEndpoints iiop://192.168.12.132:2809 -ORBDaemon &
machine1 \$ export NameServiceIOR=corbaloc:iiop:192.168.12.132:2809/NameService
machine1 \$ deployer-corba-gnulinux -s demo.xml -- -ORBDottedDecimalAddresses 1
 
machine2 \$ export NameServiceIOR=corbaloc:iiop:192.168.12.132:2809/NameService
machine2 \$ ./demogui -ORBDottedDecimalAddresses 1

For more information on the ORBListenEndPoints syntax and possibilities, see http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/TAO/docs/ORBEndpoint.html

OmniORB

machine1 \$ omniNames -start &
machine1 \$ deployer-corba-gnulinux -s demo.xml  
 
machine2 \$ ./demogui -ORBInitRef NameService=corbaloc:iiop:192.168.12.132:2809/NameService

And the reverse

machine1 \$ omniNames -start &
 
machine2 \$ deployer-corba-gnulinux -s demo.xml  -- \
-ORBInitRef NameService=corbaloc:iiop:192.168.12.132:2809/NameService
 
machine1 \$ ./demogui

Localhost

Certain distro's and certain CORBA versions will exhibit problems even with localhost only scenarios (demonstrated with OmniORB under Ubuntu Jackaloupe). If you can not connect to the name service running on the same machine, substitue the primary network interface's IP address for localhost in any NameService value.

For example, instead of 

machine1 \$ omniNames -start &
 
machine2 \$ deployer-corba-gnulinux -s demo.xml

or even

machine1 \$ omniNames -start &
 
machine2 \$ deployer-corba-gnulinux -s demo.xml  -- \
-ORBInitRef NameService=corbaloc:iiop:localhost:2809/NameService

use

machine1 \$ omniNames -start &
 
machine2 \$ deployer-corba-gnulinux -s demo.xml  -- \
-ORBInitRef NameService=corbaloc:iiop:192.168.12.132:2809/NameService

NB as of RTT v1.8.2 and OmniORB v4.1.0, programs like demogui (which use RTT::ControlTaskProxy::InitOrb() to initialize CORBA) do not support -ORBDottedDecimalAddresses (in case you try to use it).

Multi-homed machines

Computers that have multiple network interfaces present additional problems. The following is for omniORB (verified with a mix of v4.1.3 on Mac OS X, andv v4.1.1 on Ubuntu Hardy), for a system running a name server, a deployer, and a GUI. The example system has a 192.168.1.0 wired subnet and a 10.0.10.0 wireless subnet, and you have a mobile vehicle that has to communicate over the wireless subnet but it also has a wired interface.

The problem may appear as one of

  • The vehicle can not contact the name server when the wired interface is disconnected but it is up (NB on rare occasions, we've seen this even with the wired interface disconnected and down!)
  • Your GUI can connect to the deployer, but then locks up or throws a CORBA exception when trying to connect to certain remote Orocos items (we had this happen specifically for methods with parameters).

The solution is to forcibly specify the endPoint parameter to the name server. In the omniorb.cfg file on the computer running the name server, add (for the example networks above) 

endPoint = giop:tcp:10.0.10.14:
where 10.0.10.14 is the IP adrs of that computer. This forces the name server to publish end points on the wireless network first. Despite this, it will still publish the wired interface but it will come after the wireless. Specifying the endPoint parameter on the command line (instead of the config file) will not work, as then the name sever publishes the wired network first, and then the wireless network second.

If the above still does not work, then set the endPoint parameter in all computer's config files (note that the end point is the IP adrs of each computer, so it will be (say) 10.0.10.14 for the computer running the name server and the deployer, and (say) 10.0.10.21 for the computer running the GUI). This will force everyone onto the wireless network, instead of relying on what the name server is publishing.

To debug this problem see the debugging section below, but after starting the name server you will see it output its published endpoints (right after the configuration dump). Also, if you get the lockup then adding the debug settings will cause the GUI or deployer to output each message and what direction/IP it is going on. If they have strayed on to the wired network it will be visibly obvious.

NB we found that the clientTransportRule and serverTransportRule parameters had no affect on this problem.

NB the above solution works now matter which computer the name server is running on (ie with the deployer, or with the GUI).

Debugging

Add the following to the omniorb.cfg file 

dumpConfiguration = 1
traceLevel = 25
and get ready for lots of output.

See also

[1] http://people.mech.kuleuven.be/~orocos/pub/stable/documentation/rtt/current/doc-xml/orocos-components-manual.html#id479277

ACE/TAO http://www.cs.wustl.edu/~schmidt/TAO.html

OmniORB http://omniorb.sourceforge.net/