UP | HOME

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

  1. 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)
  2. 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.
  3. 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

  1. Higher-level controllers can be implemented in ROS directly
  2. 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.
  3. The ros2_controllers package contains many pre-built controllers.
    • Some are somewhat higher level, such as controllers for diff-drive robots.
  4. By following the same interface conventions you can also write your own controller (in C++).
  5. 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

Controller Manager

  1. There are many different controllers that can be used for a single robot
  2. The Controller Manager enables users to load, unload, start, and stop controllers
  3. 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

  1. ROS Control provides access to hardware resources which are managed by the Resource Manager
  2. The resource manager enables reading and writing to various hardware components
  3. The resource manager is currently implemented as part of the Controller Manager Node

Hardware Description

  1. The philosophy of the ros2 control package is that the URDF should be a complete description of the robot
  2. 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.

  1. 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.
  2. 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.
    • Hardware Interfaces (either command_interface (read/write) or state_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
  3. Each Hardware Component represents a set of interfaces that can be used to write to and read from the hardware.
  4. 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

Author: Matthew Elwin.