the Robot Construction Kit

Starting the system up

Setting up CORBA

The CORBA communication layer is set up through the Orocos.initialize call. The general header for an orocos.rb script is therefore:

require 'orocos'

It will connect to the default CORBA name service (in general, localhost), and will raise if the name service can’t be found. This default name service will always be used to register all orocos components started by the ruby instance.

If you want to use another name service, for instance because you have a system spread on multiple machines and you want to manipulate modules on the various machines, you can change the default CORBA name service or use multiple name services at the same time.

#changing the default CORBA name service

require 'orocos'
Orocos::CORBA.name_service.ip = "host_name"

Finally, the CORBA.call_timeout and CORBA.connect_timeout specify timeouts at the CORBA level. See the {rdoc_class: {base_url: /api/tools/orocos.rb, name: “Orocos::CORBA”}} documentation for more information.

Starting processes (oroGen-based modules only)

Important: the following functionality is only available for deployments that have been generated by oroGen.

Orocos.rb has the ability to start deployments that are generated by oroGen projects. The general syntax for that is: 'deployment1', 'deployment2' do

where deployment1 and deployment2 are the names of the deployments. In addition, oroGen creates deployments for each task context you create, which can be used with: 'my_proj::Task' => 'task_name' do
end waits for all the processes to be up and running, and will raise an exception if one fails to start, i.e. crashes or fails to start within a specified timeout (20s by default). This timeout can be changed with the :wait option: 'deployment1', 'deployment2', :wait => 10 do
end can also redirect the process outputs to files, and run them in valgrind. See the {rdoc_class: {base_url: /api/tools/orocos.rb, name: Orocos, base_module: ‘’, text: “documentation of the Orocos module”}} for more information.


Three nameservices are currently available: CORBA, Avahi and Local. All three can be used in parallel or standalone with any number of instances. To access n name services with priority order Orocos::NameService can be used bundling the added name services.

By default there is one Orocos::NameService instance accessible via Orocos.name_service. And one instance of Orocos::CORBA::NamerService accessible via Orocos::CORBA.name_service. The latter one is the default CORBA name service and by default also added to Orocos.name_service.

Note The default CORBA name service is used to register all Orocos components started by the ruby instance.

Important: Even if the default CORBA name service was removed from the Orocos::name_service instance it will still be used to register Orocos components started by the ruby instance.


The CORBA name service is usually used to register all running orocos components of one or multiple machines.

#changing the default CORBA name service

Orocos.name_service.ip = "host_name"

#adding a second CORBA name service

ns = "host_name2"
# adds the new corba name service to 
# the global Orocos::NameService instance
Orocos.name_service << ns 

Note Changing the default CORBA name service after Orocos was initialized might have some side effects onto the accessibility of started orocos components.


The Avahi nameservice allows distributed name resolution, i.e. it does not require a centralized server. For the name resolution via Avahi to work, deployments have to be started with a service discovery domain set:

#starting components with Avahi support 'deployment', 'cmdline_args' => { 'sd-domain' => '_robot._tcp' } do |p|

This option is available to deployments as soon as the tools/service_discovery package has been installed. Corresponding to the sd-domain the nameservice has to be enabled with a searchdomain.

# adding an Avahi name service 

ns = "_robot._tcp"
# adds the new corba name service to 
# the global Orocos::NameService instance
Orocos.name_service << ns 

Note: in order to resolve the task context of the currently started deployment allow the servicediscovery about one second after deployment start. Use the :wait option as illustrated in the next section.


The Local name service is used by log replay to register tasks which are replayed from a log file. It is automatically created and added to the Orocos.name_service instance if a log file is loaded.