rock-core / tools-orocosrb

Rock's low-level component control library in Ruby
0 stars 13 forks source link

Orocos.rb: deploying and supervising Orocos/RTT modules

Orocos.rb is a Ruby library which allows to access, read out and control Orocos RTT (http://www.orocos.org) components. It uses the CORBA transport of Orocos for that, so you need to have the CORBA library installed, as well as the rtt-corba library.

Most intersting features of Orocos.rb, like reading/writing ports and properties, starting out processes, ... Require the module to be generated by orogen. This is because of the type handling library that orogen is built on, and could probably be changed in the future. The rest of the documentation will assume that the modules you are working on have been orogen-generated.

All script snippets in this documentation are Ruby scripts, and assume that you have first done:

  require 'orocos'
  include Orocos

Installation

This package is part of the rubim.orocos package set of RubyInMotion. See http://sites.google.com/site/rubyinmotion for installation instructions.

Starting processes

As always with orogen, the dependency tracking is done using pkg-config. So make sure that the PKG_CONFIG_PATH environment variable is set properly: it should include the lib/pkgconfig subdirectory of where you installed the orogen module.

Then, start your modules with

  p1, p2 = Orocos::Process.spawn 'canbus', 'hokuyo'

where canbus and hokuyo are the names of the processes as deployed by orogen, i.e. the name given to #deployment in the orogen specification:

  deployment 'canbus' do
    # Spawn task contexts
  end

Alternatively, you can use the block form. In this form, when the do ... end block is exited, then the processes are properly shut down.

  Orocos::Process.spawn 'canbus', 'hokuyo' do |p1, p2|
    # Use the process objects.
  end

In both cases, +p1+ and +p2+ refer to Orocos::Process instances that respectively represent the +canbus+ and +hokuyo+ processes.

See the documentation of Orocos::Process for more details.

== Getting a grasp on existing task contexts

You can grab an object represeting the remote RTT component with:

  c = TaskContext.new IOR
  # or 
  d = Orocos.name_service.get TaskName

where TaskName is the name given to the task during deployment and IOR the Interoperable Object Reference (IOR). You can list all existing tasks using the orocos_state script included in orocos.rb.

Alternatively, one can get a task based on the interfaces it implements. In orogen, this is marked by the class hierarchy (i.e. either directly the task's class name or one of its parent class names).

For instance, with the orogen specification looking like:

  name "controldev"
  task_context "Device" do
    ... generic interface definition ...
  end
  task_context "Joystick" do
    subclasses "Device"
    ... specific joystick parts ...
  end
  task_context "Joypad" do
    subclasses "Device"
    ... specific joypad parts ...
  end
  task_context "Remote" do
    subclasses "Device"
    ... specific remote parts ...
  end

During deployment, you would choose the "right" one for your system. For instance, a local computer would use controldev::Joystick, the robot would require a remote control and therefore use controldev::Remote and so on.

Though, the script will be independent from that choice because you can use

  c = Orocos.name_service.get_provides("controldev::Device")

Orocos.name_service.get_provides returns a Orocos::TaskContext instance. See the documentation of that class for more details.

Changing and reading a task context's state

Manipulating a task context

You can change the task's properties with:

  # This property is a "simple" type (i.e. not a struct)
  c.device_name = "/dev/ttyUSB0"

  # This one is a struct, so get the component's default value and change it 
  value = c.parameters
  value.maxSpeed = 20
  value. = 200
  c.propertyName = value

The properties are represented by Orocos::Attribute objects. In the same way, ports can be accessed through Orocos::InputPort and Orocos::OutputPort objects:

  output_port = c.currentReadings
  input_port  = c.speed

Reading/writing these ports is done with:

  port_reader = c.currentReadings.reader
  port_reader.read # => returns the current reading instance

  port_writer = c.speed.writer
  port_writer.write(10) # => returns the current reading instance

If the port's type is a structure, then you can either do:

  sample = port_writer.new_sample # or c.speed.new_sample
  sample.value = 100
  port_writer.write(sample)

or represent the structure through a hash:

  port_writer.write(:value => 100)

Orocos::InputPort#writer and Orocos::OutputPort#reader return respectively Orocos::InputWriter and Orocos::OutputReader objects. These objects are connected to the remote ports using the standard RTT data flow mechanism, so it is possible to specify a connection policy:

  port_reader = c.currentReadings.reader(:type => :buffer, :size => 10, :pull => true)
  port_writer = c.speed.writer(:type => :buffer, :size => 10, :pull => true)

See Orocos::Port#validate_policy for an in-depth explanation of possible values.

Finally, the task's methods can be used in this way:

  m = c.rtt_method('watch')
  ret = m.call(arg1, arg2)

and commands are used:

  m = c.rtt_command('watch')
  handle = m.call(arg1, arg2)
  # Check if the command is finished

Both calls store the arguments on the remote component, so if the same method is to be called repeatedly, use #recall:

  m = c.rtt_method('watch')
  ret = m.call(arg1, arg2)
  ret2 = m.recall

Orocos::TaskContext#rtt_method returns an Orocos::RTTMethod object while Orocos::TaskContext#rtt_command returns an Orocos::Command one.

Connecting task contexts together

It is possible to connect ports using orocos.rb. Simply do:

  # Get the InputPort and OutputPort instances# Get the InputPort and OutputPort
  instances# Get the InputPort and OutputPort instances
  input_port  = c.input
  output_port = c.output
  output_port.connect_to(input_port, policy)

+policy+ is the connection. It is a hash whose arguments are the policy parameters. See Orocos::Port#validate_policy for an in-depth explanation of possible values.