UP | HOME

ROS Control

Introduction

The ROS 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, velocity) that may be used to control a signal robot.

Documentation

  • The ROS control package is documented here and on the Github Wiki.
  • Sometimes the documentation links directly to source code

Basic Architecture

Hardware Interface

  1. Robots often have low-level embedded systems running on microcontrollers that are responsible for actually controlling the motors.
  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 is different per each 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 velocity control.
    • Each of these control modes can have a separate ROS hardware interface
  4. There are also "hardware interfaces" for gazebo, so oftentimes the simulated and real robot present the same control interface to the user

Controller Layer

  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 simply 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 ROS 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
  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
    • You can pass command-line arguments to the controller_manager_node to manage controllers
    • You can also use services to interact with a pre-started controller_manager (e.g., if a robot launch file uses ros_control and starts its own manager)

Author: Matthew Elwin.