Getting a hold on task contexts

There are two ways to get a TaskContext instance that represents a task context: using its name or using its type. Both ways are accessed using the TaskContext.get call.

Note: the task type can be used only for oroGen-generated tasks. If oroGen is not used, only the name can be used

As an example, with the following oroGen deployments:

deployment "lowlevel" do
  task('can', "can::Task").
  task("hbridge", "hbridge::Task")
  add_default_logger
end

The following code snippet will get a handle on the hbridge task in the two different ways:

Orocos.run 'lowlevel' do
  hbridge = TaskContext.get 'hbridge'
  hbridge = TaskContext.get :provides => 'hbridge::Task'
end

Note that the type given to the provides option may be a superclass of the actual returned task. This access method is meant to make startup scripts more generic. For instance, if we assume that there is a generic base::IMU IMU driver model that is subclassed by imu::XsensTask and dfkiimu::Task, then a startup script that does

imu = TaskContext.get :provides => 'base::IMU'

Will get an IMU task regardless of its name and exact type.

If no task is found or if an ambiguity exists (i.e. if there is more than one component matching), the method raises Orocos::NotFound.

Manipulating and monitoring the component’s state

The component’s state machine can be manipulated using the standard RTT calls. You need to know the following calls:

• configure: move the component from the PreOperational to the Stopped state. In oroGen, only components whose definition include the needs_configuration statement need that step.
• start: actually starts the component
• stop: stops the component if it is running

All these methods are synchronous (i.e. the component is actually started once the start method returns) and raise StateTransitionFailed if the transition could not happen.

When the component is in a fatal error state, one can use the reset_error call to get back to the stopped state (where either start or configure can be called again).

At runtime, the ready?, running?, error? and fatal? allow to inspect the component’s state. Even though it is possible to access the state directly, avoid to do so unless you really need it. The reason is that, if oroGen’s extended state support is used in a component, then the above predicates will continue to work while checking for, say, FATAL_ERROR won’t.