qb_device: qb_device_bringup | qb_device_control | qb_device_description | qb_device_driver | qb_device_hardware_interface | qb_device_msgs | qb_device_srvs | qb_device_utils

Package Summary

This package contains a device-independent API wrapper for qbrobotics® devices.

qb_device: qb_device_bringup | qb_device_control | qb_device_description | qb_device_driver | qb_device_hardware_interface | qb_device_msgs | qb_device_srvs | qb_device_utils

Package Summary

This package contains a device-independent API wrapper for qbrobotics® devices.

This is the only package among the ones in qb_device which can be used as a stand-alone ROS node, called Communication Handler. It wraps the qbrobotics® API, manages the shared resources and provides a multi-node from/to multi-device communication interface.

Communication Handler

The Communication Handler node manages the serial communication from the ROS ecosystem to the physical qbrobotics devices connected to it through any serial ports, and vice versa. The need of such a mediator is demanded to the possibility to connect several devices together (i.e. in a chain) and access them through a single serial port. Each ROS node representing a device has to request services to the owner of the shared resources, i.e. the Communication Handler.

Command-line tools

To start an instance of the Communication Handler node, be sure that the roscore is running and then simply execute the following command from a terminal (it does not require any configuration parameters):

rosrun qb_device_driver qb_device_communication_handler

Launch files

To integrate the Communication Handler node in your application launch file you simply need to add the node to it (it does not require any configuration parameters).

<launch>
  <node name="qb_device_communication_handler" pkg="qb_device_driver" type="qb_device_communication_handler" respawn="true" output="screen"/>
  ...
</launch>

qb_device_communication_handler

The Communication Handler provides seven services to interact with qbrobotics devices connected to the system. A part from deregister_device and register_device, for each of the others it is assumed that the requested ID has to be registered first to the Communication Handler (cf. register_device), and that a physical device configured with the same ID has to be connected through any serial port to the handler itself.

Services

/communication_handler/activate_motors (qb_device_srvs/Trigger)
  • Activates the motors of the device which ID is specified in the service request. The response success variable is set to true if motors are active.
/communication_handler/deactivate_motors (qb_device_srvs/Trigger)
  • Deactivates the motors of the device which ID is specified in the service request. The response success variable is set to true if motors are inactive.
/communication_handler/deregister_device (qb_device_srvs/Trigger)
  • Deregisters the device which ID is specified in the service request from the Communication Handler; it will not be able to request anymore services until a new registration is performed. Does nothing if the device was not already registered.
/communication_handler/get_info (qb_device_srvs/Trigger)
  • Retrieves the printable configuration setup of the device which ID is specified in the service request. On error, the response message variable is empty.
/communication_handler/get_measurements (qb_device_srvs/GetMeasurements)
  • Retrieves the motor positions and currents of the device which ID is specified in the service request. The response success variable is set to true if data retrieved (i.e. the response currents and positions variables) is meaningful.
/communication_handler/register_device (qb_device_srvs/RegisterDevice)
  • Registers the device which ID is specified in the service request to the Communication Handler (i.e. it will be able to request any of the services provided by this node); if requested, activates the device motors. A physical device configured with the same ID has to be connected through any serial port to the handler itself. The response success variable is set to true if the whole registration process ends with no failures.
/communication_handler/set_commands (qb_device_srvs/SetCommands)
  • Send the reference commands (i.e. the request commands variable) to the motors of the device which ID is specified in the service request.
/communication_handler/sync_nodes (qb_device_srvs/Trigger)
  • Checks if all the already registered devices are completely initialized and ready for the control application; a device node is considered ready if it has requested this service at least once. The response success variable is set to true if all the control nodes are ready.

Wiki: qb_device_driver (last edited 2017-03-10 14:35:05 by AlessandroTondo)