Robot Control
Objective: This tutorial session is devoted to understanding the ros_control framework used to implement and manage robot controllers for simulation within the gazebo.
Last updated
Objective: This tutorial session is devoted to understanding the ros_control framework used to implement and manage robot controllers for simulation within the gazebo.
Last updated
Tutorial install package:
Packagerrbot_description, rrbot_gazebo, rrbot_control
Packagemastering_ros_robot_description_pkg
Packageseven_dof_arm_gazebo_simple
Packagegazebo_control_tutorial
Packageactions_tutorial
Packageuniversal_robot
PackageUR3-IK
The ros_control framework provides the capability to implement and manage robot controllers, which that mainly consists of a feedback mechanism, most probably a PID loop, which can receive a setpoint, and control the output, typically effort, using the feedback from the actuators. The primary motivation of ros_control is the lack of realtime-safe communication layer in ROS.
The framework implements abstractions on hardware interfaces with minimal assumptions on hardware or operating system. The output is applied to the real robot or to its simulation in Gazebo by using a simple Gazebo plugin adapter.
The following figure shows the interconnection of the ROS controller, robot hardware interface, and simulator/real hardware:
More details on all the components of ros_control are shown in the next figure. They can be grouped into two main blocks:
The controllers and the control manager (the blue and yellow blocks; they will be detailed in Section Controllers):
Several controllers may be used (some are already available) and are managed by the Control Manager that is responsible of loading, unloading and switching between them.
The hardware abstraction layer (the gray and orange blocks; they will be detailed in Section Hardware Abstraction Layer).
The ROS controllers do not directly communicate with the hardware, but do it through the Hardware Abstraction Layer, enabling controllers to be hardware-agnostic. It is composed of:
the ros_control interfaces found in the figure within the Hardware Resource Interface Layer
the hardware interfaces that encapsulate the hardware drivers. They are modeled with classes that inherit from the hardware_interface::RobotHW class (this class also acts as resource manager by performing resource conflict checking for a given set of controllers, maintaining a map of hardware interfaces). In the case of simulation, the Gazebo plugin version hardware_interface::RobotHWSim is used.
The main ROS controllers are grouped according to the commands get passed to your hardware/simulator:
effort_controller: efforts commands are used to control joint positions, velocities or efforts.
joint_effort_controller
joint_position_controller
joint_velocity_controller
position_controllers: position commands are used to control joint positions.
joint_position_controller
joint_group_position_controller
velocity_controllers: velocity commands are used to control joint velocities.
joint_velocity_controller
joint_group_velocity_controller
To set an entire trajectory, the following controllers are defined:
joint_trajectory_controllers:
position_controller
velocity_controller
effort_controller
position_velocity_controller
position_velocity_acceleration_controller
Also, a controller is defined to publish joint states:
joint_state_controller
All available controllers can be found here.
The controller_manager provides the infrastructure to interact with controllers, i.e. load, unload, start and stop controllers.
This interaction can be done:
Using the command line tools:
where the available commands are load, unload, start, stop, spawn (load+start), kill (stop+unload).
Also, several controllers can be loaded and started at once with the spawner tool:
Using launch files (which is the most practical and common way):
Using rqt:
Using service calls to interact with controllers from another ROS node, e.g.:
controller_manager/load_controller has as request the name of the controller to be loaded and returns success or failure.
controller_manager/switch_controller has as request a list (which can be empty) of controller names to start, a list (which can be empty) of controller names to stop, and the switching policy.
More information can be found in the controller manager wiki page.
Controllers are usually defined with yaml files (stored in a config folder), like those shown here.
Another example is shown in the following figure, that corresponds to the rrbot_control.yaml configuration file of the rrbot_control package where the controllers for the rrbot robot are defined. In this case there is:
the joint state controller to publish the joint states of the arm (with a publishing rate set to 50 Hz),
two joint position controllers to move each of the two joints upon receiving a goal position.
We can see that all the controllers are inside the namespace rrbot. This configuration file can be loaded in a launch file, prior to the spawning of the controller:
rrbot_control.launch
If order to simulate the robot in Gazebo with those controllers, the corresponding plugin has to be added to the URDF model, as detailed in Section Preparing Gazebo for ros_control.
Important: Note that the controllers have to be spawned within the same namespace where the controls have been defined, rrbot in this case, using the ns= argument in the controller_spawner node tag. Also, the gazebo plugin will need to be within this namespace.
Advertising joint values: The joint position controllers of the rrbot robot of Section Configuring and launching controllers can be tested by advertising the desired joint values:
The connection of the controllers with the hardware interface (that encapsulates the hardware) is done through the ros_control interfaces. Some of the commonly used are:
EffortJointInterface: to send the effort command.
VelocityJointInterface: to send the velocity command.
PositionJointInterface: to send the position command.
Joint State Interfaces: to retrieve the joint states from the actuators encoder.
To control a given robot using ros_control, a class derived from the hardware_interface::RobotHW class should be implemented. This class should support one or more of the standard interfaces like e.g. the EffortJointInterface or VelocityJointInterface:
For instance, the following code shows the class implemented for a robot with two position-controlled joints. It uses the JointPositionInterface and the JointStateInterface:
In this example, the controller manager (and the controllers inside the controller manager) will get read access to the joint state of the robot (pos, vel and eff variables) through the hardware_interface::JointStateInterface and write access to the command to be sent to the robot (the cmd variable) through the hardware_interface::PositionJointInterface. Two functions should be added to this class, namely read() and write(), to fill the pos, vel and eff with the latest available values from the robot and to run the command available at cmd on the robot. These functions will then be called in the control loop before and after the computation of the control command as shown next:
More information can be found in the ros_controls git repository.
The joint_limits_interface package contains data structures for representing joint limits, methods to populate them through URDF or yaml files, and methods to enforce these limits. An example of joint limits specification in URDF and YAML formats is:
A joint limits specification in YAML format that can be loaded to the ROS parameter server looks like:
An example of how to read these values from the URDF and populate the joint_limits_interface data structures can be found in the GitHub wiki.
Transmission interfaces implement mechanical transmissions, like a mechanical reducer with a given ratio n, and therefore maps effort/flow variables to output effort/flow variables while preserving power.
Transmissions are defined in the URDF robot file as detailed in the ROS wiki urdf transmission page, e.g.:
The complete control loop when considering joint limits and the existence of transmissions is shown in the next figure:
Simulation a ros controllers in gazebo shown in the picture below
Following the example of gazebo_control_tutorial, to moves the seven_dof_arm robot along a sinusoidal trajectory by advertising the desired joint values.
