Which ROS 2 controllers and interfaces are actually active?
Use ros2 control list_controllers to read controller names, types and lifecycle states from the intended controller manager. Check hardware components and claimed interfaces separately. These listing commands do not request motion or change controller state, but they also do not stop an already running system.
Updated · RLSOK
Start with the read-only commandsChoose the intended controller manager
Use an existing ROS 2 environment with ros2controlcli installed and its workspace sourced. The examples follow the linked Jazzy sources; installed package versions can expose different options. RLSOK is not needed for these inspection steps.
Replace /controller_manager with your actual node, for example /robot_a/controller_manager. Use the ROS domain and namespace intended by your existing environment. Do not change discovery settings or launch hardware just to make an inspection command return data.
Read the controller state
The basic listing reports each loaded controller's name, plugin type and state. The claimed-interfaces option adds the interface names associated with each controller. A controller listed as active is a lifecycle observation, not proof that it is the approved controller for your release.
If the command cannot contact the manager, record that failure as unknown state. Check the node name and your existing ROS environment. An empty successful response means that manager reported no loaded controllers; it does not describe every manager or driver in the system.
ros2 control list_controllers -h ros2 control list_controllers -c /controller_manager ros2 control list_controllers -c /controller_manager --claimed-interfaces
Read hardware state and interface claims separately
ros2 control list_hardware_components -c /controller_manager ros2 control list_hardware_interfaces -c /controller_manager
| Observation | Useful interpretation | Still unknown |
|---|---|---|
| Controller is active | The queried manager reports that controller lifecycle state. | Approval, artifact identity and physical motion. |
| Hardware component state | The lifecycle state reported for that component. | The state of other components or external drivers. |
| Interface is claimed | The reported interface claim can be checked against the controller listing. | Whether this is the binding you intended to approve. |
Why one active label is insufficient
Upstream issue #3444 records a Jazzy user's observation that manually deactivating a hardware component left controllers active and interfaces claimed. It is a specific report about lifecycle behavior, not evidence that every installed version behaves identically. RLSOK does not claim to fix that upstream issue.
Read the controller and hardware observations together. Do not infer hardware state from controller state alone, or treat a lifecycle transition as release approval. The linked report is the reason this guide keeps those observations separate.
Keep a useful inspection record
- Record the ROS distribution, ros2_control package version, controller manager name and observation time.
- Preserve the returned controller names, types, states and interface claims beside your expected configuration.
- Treat the three command results as separate snapshots; they are not one atomic capture and the system can change between them.
- Treat unavailable or stale observations as unknown. Do not fill missing state from an old YAML file or a previous successful command.
Compare an observation against an approval
If your next question is whether a selected active controller still matches an approved configuration, the separate RLSOK comparison guide describes a structured export and a baseline-versus-changed evaluation. Terminal listings from this page are not inputs to that procedure; follow its export format and prerequisites.
That comparison uses the v1.5.0-shadow.8 evaluation prerelease and documented source mappings in an isolated environment. Its reported mock checks do not establish physical-robot compatibility or actual customer use.
Sources and verification scope
Source code and guides describe implementation and setup. Release notes identify reported checks and their limits. Publication alone does not establish customer use or physical-robot validation.
Continue with the relevant guide
Try the local example without an application. For setup or integration help, you can also contact us.