Skip to content

Latest commit

 

History

History
119 lines (86 loc) · 6.42 KB

tutorials.wiki

File metadata and controls

119 lines (86 loc) · 6.42 KB

    2. note =
    3. note.0 = qb SoftHand Installation
    4. note.1 = qbmove Installation
    5. title = Basics
    6. description = Basic knowledge of the qbrobotics control Nodes
    7. next =
    8. next.0.link = Details
    9. next.1.link = Communication Handler
    10. level = BeginnerCategory
    11. keywords = qbrobotics SoftHand qbmove control
<>

As shown in the following picture there are two distinct configurations to control several qbrobotics® devices connected to the system: 

 * The first (and recommended) groups all the Hardware Interfaces together (thanks to the [[combined_robot_hw]]) and exploits them as a unique robot system. We have called it ''"synchronous"'' just to point out that every sequence of reads and writes is always done in the same predefined order.
 * The second mode threats every device as an independent Hardware Interface with its dedicated ROS Node which executes the control loop independently w.r.t. the rest of the system, i.e. ''"asynchronously"''.

Mixed configurations can be also achieved through a proper setup. In such a case we can think of synchronous sub-systems which execute asynchronously w.r.t. each other.

Note that in a single-device system the synchronous mode is a nonsense.

In both cases there is always one central Node which manages the shared resources for the serial communication (e.g. one or many USB ports) and which provides several ROS services to whom wants to interact with the connected devices. This Node is called Communication Handler and it is usually started in a separate terminal.

    1. TutorialCategory
    2. note =
    3. note.0 = Basics
    4. title = Details
    5. description = Details on the qbrobotics control Nodes
    6. next =
    7. next.0.link = Communication Handler
    8. next.1.link =
    9. level = IntermediateCategory
    10. keywords = qbrobotics SoftHand qbmove control
<>

To understand what is hiding under the hood, have a look at the C++ classes overview which sums up all the main concepts of our ROS packages:

    1. TutorialCategory
    2. note =
    3. note.0 = Basics
    4. title = Communication Handler
    5. description = Details on the Communication Handler Node
    6. next =
    7. next.0.link = Control
    8. next.1.link =
    9. level = BeginnerCategory
    10. keywords = qbrobotics SoftHand qbmove control
<>

The Communication Handler Node has no parameters to be set, therefore it is always launched like this:

On start, it scans the serial communication resources connected to you system and shows a list of the devices it has found. By default it never scans again for new devices, apart from asking it explicitly during the initialization of a control Node.

This is a simple example when starting the Communication Handler with two qbrobotics® devices connected on two distinct USB ports:

When the Communication Handler is on, it provides all the Services required to interact with the connected devices: e.g. get info or measurements, activate or deactivate motors, set commands, and even more... A detailed description of the services can be found in the qb_device_driver package wiki.

    1. TutorialCategory
    2. note =
    3. note.0 = Communication Handler
    4. title = Control
    5. description = Details on the control Node
    6. next =
    7. next.0.link =
    8. next.1.link =
    9. level = BeginnerCategory
    10. keywords = qbrobotics SoftHand qbmove control
<>

As shown in Details the control Node exploits the ros_control Controller Manager which loads and runs the device controllers. Each controller provides an Action Server that, together with the Hardware Interface structure, allows the user to send commands to the relative device and get its measurements.

From an API point of view, it is implemented an Action Client which matches the relative trajectory controller and provides a method to send Goals, i.e. command references, directly to the given device. Additionally the Action Client is subscribed to a Topic (`*_controller/command`) that can be used to send reference commands from outside the code, e.g. asynchronously from the command line, or from a higher level control Node, e.g. as a result of a planning algorithm.

Regardless the control mode chosen for the given application, and apart form a customization of the API, the following launch file templates can be used respectively to control several devices or a single one:

    1. TutorialCategory