ROS Control
Introduction
The ROS 2 Control package is a package designed to abstract away robot hardware and allow ROS to control many different robots in a uniform manner. It is also designed to manage the various control modes (e.g., torque, position) that may be used to control a signal robot.
The ROS control package, when used in conjunction with the Real Time Linux kernel, enables enforcing soft real-time constraints on the control loops.
Basic Architecture
Hardware Interface
- Robots often have low-level embedded systems running on microcontrollers that are responsible for:
- Converting software signals into the voltages (e.g., PWM signals) that actually control the motors.
- Converting voltages from sensors into software signals (e.g, encoders)
- Robot manufactures implement communication between the PC and these microcontrollers using a standardized class interface:
- On one end is the custom per-robot code that communicates with the hardware: this layer is different for different robot
- On the other end is the common code used by all ROS controllers: this is the same for each robot.
- Thus, the hardware interface translates standard ROS interface commands to hardware-specific commands.
- The embedded systems in hardware may provide different control modes, for example torque or position control.
- Each of these control modes can have a separate ROS hardware interface
Controllers
- Higher-level controllers can be implemented in ROS directly
- These controllers interface with the actual robot via the Hardware Interface
- Controllers can be quite simple: for example, if the embedded hardware implements position control directly, then a position controller can pass through position commands to this hardware interface
- There are also standardized controllers that implement PID control loops. For example, if the hardware interface provides a torque-based Hardware Interface, the PID control (running in ROS) can take in position commands and sensor measurements and output a torque control signal.
- Higher level controls are possible: for example, a trajectory-following controller can use lower-level controllers (such as position or velocity) to make the robot follow a trajectory.
- The ros2_controllers package contains many pre-built controllers.
- Some are somewhat higher level, such as controllers for diff-drive robots.
- By following the same interface conventions you can also write your own controller (in C++).
- Controllers are classified/grouped by their output type (and hence what Hardware Interface they need)
- Effort controllers output effort (e.g., torque) to the robot
- Can use to control torque directly
- A joint_position effort controller can take a position input, and use a PID loop to output torque
- A joint_velocity effort controller can take a position input, and use a PID loop to output torque
- Effort controllers output effort (e.g., torque) to the robot
Controller Manager
- There are many different controllers that can be used for a single robot
- The Controller Manager enables users to load, unload, start, and stop controllers
- The controller manager package provides services and a node to interact with controllers, which can be accessed via the
ros2 control
command-line tool.
Resource Manager
- ROS Control provides access to hardware resources which are managed by the Resource Manager
- The resource manager enables reading and writing to various hardware components
- The resource manager is currently implemented as part of the Controller Manager Node
Hardware Description
- The philosophy of the ros2 control package is that the URDF should be a complete description of the robot
- Therefore, much of the ROS 2 control package requires setup using extensions to existing URDF tags, under
<ros2_control>
Practical Guide to Using ROS 2 Control
The ROS 2 Control Getting Started documentation provides an overview of the package.
- The ROS 2 control package introduces terminology that for its various parts that are somewhat confusing an inconsistent due to the many layers of abstraction in this package.
- The language in this section attempts to remain consistent and keep The use of the terms internally consistent and consistent with the
ros2 control
command line interface.
- The language in this section attempts to remain consistent and keep The use of the terms internally consistent and consistent with the
- ROS 2 Hardware Resources (which represent a collection of all things needed to send and recieve low-level commands to/from a robot) are configured in the URDF file
- The
<ros2_control name
"NameOfHardwareComponent" type="system|actuator|sensor">= defines a hardware component, which consists of the following- A hardware plugin. The plugin is implemented in C++ and exported as a plugin via an
xml
file - Parameters can be passed to the hardware plugin to change it's behavior.
- A hardware plugin. The plugin is implemented in C++ and exported as a plugin via an
- Hardware Interfaces (either
command_interface
(read/write) orstate_interface
(read only)= are associated with either- A
<joint>
on the robot. This is a 1-DOF item that can be written to (e.g., given a command) and read from and must be associated with a joint in the URDF - A
<sensor>
on the robot, which can be read from - A
<gpio>
which is a generic read/write interface that need not be associated with a joint
- A
- The
- Each Hardware Component represents a set of interfaces that can be used to write to and read from the hardware.
- ROS 2 Controllers. These controllers are managed by the Controller Manager
- Controllers are what actually run control loops (with real time deadlines if using the Real Time Linux Kernel)
- Controllers take inputs in the form of ROS messages and produce outputs that are sent to the hardware via Hardware Components (as loaded by the resource manager).
- Which controllers are loaded by default are configured in
.yaml
files