Understand ROCKO's Software Architecture
Nodes and Controllers
Please refer to the ‘Recommended Reading’ section for further clarification and notes on implementation!
ROCKO, as a system developed in ROS, achieves functionality through software entities called nodes. These are the fundamental entities that make ROS2 work.
Nodes function as discrete entities containing unique logic. They send and receive information with other nodes through topics. Topics are named interfaces for messages; configuring one node to publish to a particular topic, and another node to subscribe to it, will allow them to communicate. The web of nodes communicating through topics is called the graph.
ROCKO relies heavily on controllers, a type of node unique to the ros2_control framework. Controllers are used to achieve control systems applications, meaning they perform tasks related to the motion and dynamics of the physical robot system. They allow us to implement ROCKO’s core functionality independent of a specific piece of hardware or hardware library.
Controllers and nodes, while similar, differ in a few very important ways integral to understanding ROCKO’s software environment.
Receiving information | Node | Receives messages with a subscription to a topic. |
Controller | Receives instructions through a controller manager. | |
Sending information | Node | Sends messages through a publisher to a topic. |
Controller | Sends data through a controller manager. | |
Communicating with hardware | Node | Can be accomplished directly through importing a hardware library. |
Controller | A hardware interface monitors hardware data, and sends that data to the controller manager. |
As you can see, although nodes and controllers are fundamentally similar in concept (and are implemented similarly by ROS2’s developers!) they exist in different contexts.
At first, it may seem like ros2_control is adding additional complexity to an otherwise straightforward system! However, it actually makes our lives much simpler than they may otherwise be. It provides us control logic, makes that logic portable between hardware contexts (so ROCKO may be upgraded), and allows all of the sensor and hardware data to operate with the control logic in real-time.
ROCKO’s Nodes and Controllers
AddFeedforwardController
The AddFeedforwardController does what it says on the tin: it takes an externally specified feedforward via a topic and adds it to the incoming control value, often the output of a PID controller. This controller proves helpful when a system requires a variable feedforward component that may need to be calculated outside of the typical control chain. In ROCKO’s case, we use it to add extra velocity to the motor outputs based on the user’s input from a joystick, which allows ROCKO to drive around.
ROS Parameter | description |
|---|---|
| A list of the input/output interface(s) of the controller. The name should correspond to the next item in the chain, likely a piece of hardware, ending with its controlling interface. |
| The name of the topic the controller will subscribe to for receiving updated feedforward values. The type of this topic must be Float64. |
PIDController
This is a brief overview of how PID controllers work; please refer to the ‘Recommended Reading’ section for further details!
ROCKO uses 2 PID controllers to maintain balance and drive around. We utilize the built-in ros2_control PIDController class, whose docs can be found here. PID controllers are a common feedback-driven controller used in robotics that take in a current reading and a desired setpoint. Based on the difference between the current reading and the desired setpoint, as well as the tuned coefficients of the controller, the PID controller will output a value that will attempt to drive the current reading towards the desired setpoint.
The first PID controller on ROCKO is the pitch controller. The job of this controller is to maintain ROCKO’s balance. It takes in a desired pitch (often 0 for ROCKO to maintain vertical balance) and the current pitch reading, which comes from the IMU sensor. It outputs a value in rad/sec that gets sent to the AddFeedforwardController for the left and right wheels, which then gets sent to the motors that drive ROCKO.
The second PID controller on ROCKO is the velocity controller. Its job is to keep ROCKO from drifting back and forth while maintaining balance. It takes in a desired velocity (0 for ROCKO to balance in place, a non-zero number for ROCKO to drive in a direction) and the current average velocity of ROCKO, which comes from the encoders on ROCKO’s motors. It outputs a pitch that then gets used by the pitch controller as its desired setpoint.
Diffdrive Controller
The diffdrive controller is a little atypical, as it is the node that commands the ROS2 control chain, but it still contains some control logic. It uses topics to take in a desired robot body vector, which is the overall linear and angular direction of ROCKO, and outputs left and right velocities that will achieve that overall vector. These left and right velocities are then sent to the velocity PID, which uses them as the desired setpoint for the controller. It also sends these velocities to the AddFeedforwardControllers to allow ROCKO to drive around.
While ROCKO uses a joystick by default to supply the desired robot body vector, you can replace the joystick with any controller that can output a robot body vector. This means that you can use a trajectory-following algorithm, path-finding software, or anything else you can come up with to control ROCKO!
Name | Description | Publisher or Subscriber? |
|---|---|---|
| The desired robot body vector for ROCKO to follow | Subscriber |
| The desired velocity for the velocity PID controller | Publisher |
| The feedforward value to add to the left motor | Publisher |
| The feedforward value to add to the right motor | Publisher |
Recommended Reading
Official Documentation
3rd Party Resources
ros2_control_explained by masum919
ROS Overview by Articulated Robotics
PID Controller Explained • PID Explained by PID Explained