The task context provides and requires services. It uses an ExecutionEngine to perform its functions. Essential interfaces are operations, data flow ports and properties. These interfaces have been defined using the oroGen specification. In order to modify the interfaces you should (re)use oroGen and rely on the associated workflow. More...
#include <Task.hpp>
Public Member Functions | |
| Task (std::string const &name="imu_imar::Task", TaskCore::TaskState initial_state=Stopped) | |
| Task (std::string const &name, RTT::ExecutionEngine *engine, TaskCore::TaskState initial_state=Stopped) | |
| ~Task () | |
| bool | configureHook () |
| The following lines are template definitions for the various state machine. More... | |
| bool | startHook () |
| void | updateHook () |
| void | errorHook () |
| void | stopHook () |
| void | cleanupHook () |
Protected Attributes | |
| int | timeout_counter |
| imu_imar::iVRU_BB | imu_imar_driver |
| base::samples::IMUSensors | sensors |
| base::samples::RigidBodyState | reading |
| aggregator::TimestampEstimator * | timestamp_estimator |
Friends | |
| class | TaskBase |
Detailed Description
The task context provides and requires services. It uses an ExecutionEngine to perform its functions. Essential interfaces are operations, data flow ports and properties. These interfaces have been defined using the oroGen specification. In order to modify the interfaces you should (re)use oroGen and rely on the associated workflow.
The name of a TaskContext is primarily defined via:
deployment 'deployment_name'
task('custom_task_name','imu_imar::Task')
end
It can be dynamically adapted when the deployment is called with a prefix argument.
Constructor & Destructor Documentation
| Task::Task | ( | std::string const & | name = "imu_imar::Task", |
| TaskCore::TaskState | initial_state = Stopped |
||
| ) |
TaskContext constructor for Task
- Parameters
-
name Name of the task. This name needs to be unique to make it identifiable via nameservices. initial_state The initial TaskState of the TaskContext. Default is Stopped state.
| Task::Task | ( | std::string const & | name, |
| RTT::ExecutionEngine * | engine, | ||
| TaskCore::TaskState | initial_state = Stopped |
||
| ) |
TaskContext constructor for Task
- Parameters
-
name Name of the task. This name needs to be unique to make it identifiable for nameservices. engine The RTT Execution engine to be used for this task, which serialises the execution of all commands, programs, state machines and incoming events for a task. initial_state The initial TaskState of the TaskContext. Default is Stopped state.
| Task::~Task | ( | ) |
Default deconstructor of Task
Member Function Documentation
| void Task::cleanupHook | ( | ) |
This hook is called by Orocos when the state machine transitions from Stopped to PreOperational, requiring the call to configureHook() before calling start() again.
| bool Task::configureHook | ( | ) |
The following lines are template definitions for the various state machine.
This hook is called by Orocos when the state machine transitions from PreOperational to Stopped. If it returns false, then the component will stay in PreOperational. Otherwise, it goes into Stopped.
It is meaningful only if the #needs_configuration has been specified in the task context definition with (for example):
task_context "TaskName" do needs_configuration ... end
TO-DO: configure the IMU parameter values using the debug_port
For the time being, it uses the default values: 57600 Baud-rate, 100 Hz and 50 bytes package size containing acc, gyros and roll, pitch and yaw
Open the communication port which is the port to acquire the inertial values
| void Task::errorHook | ( | ) |
This hook is called by Orocos when the component is in the RunTimeError state, at each activity step. See the discussion in updateHook() about triggering options.
Call recover() to go back in the Runtime state.
| bool Task::startHook | ( | ) |
This hook is called by Orocos when the state machine transitions from Stopped to Running. If it returns false, then the component will stay in Stopped. Otherwise, it goes into Running and updateHook() will be called.
Synchronize driver with the stream comming from the device
Store the read values in the Circular Buffer
Synchronize with the starting byte
| void Task::stopHook | ( | ) |
This hook is called by Orocos when the state machine transitions from Running to Stopped after stop() has been called.
| void Task::updateHook | ( | ) |
This hook is called by Orocos when the component is in the Running state, at each activity step. Here, the activity gives the "ticks" when the hook should be called.
The error(), exception() and fatal() calls, when called in this hook, allow to get into the associated RunTimeError, Exception and FatalError states.
In the first case, updateHook() is still called, and recover() allows you to go back into the Running state. In the second case, the errorHook() will be called instead of updateHook(). In Exception, the component is stopped and recover() needs to be called before starting it again. Finally, FatalError cannot be recovered.
The driver in synchronized, starting to read values
Time of receiving
Store the read values in the Circular Buffer
Check the status of the Driver Circular Buffer
Read a byte in the stream
Store the read values in the Circular Buffer
Compute the checksum
Read the IMU inertial Values
If checksum is correct
Write the values in the data object
Write in the Ports
Friends And Related Function Documentation
|
friend |
Member Data Documentation
|
protected |
|
protected |
|
protected |
|
protected |
|
protected |
The documentation for this class was generated from the following files:
