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
- Robots often have low-level embedded systems running on microcontrollers that are responsible for actually controlling the motors.
- 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
- 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
- There are also "hardware interfaces" for gazebo, so oftentimes the simulated and real robot present the same control interface to the user
Controller Layer
- 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 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
- The ROS 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
- 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
- You can pass command-line arguments to the controller_manager_node to manage controllers
- You can also use
services
to interact with a pre-startedcontroller_manager
(e.g., if a robot launch file uses ros_control and starts its own manager)