In ros2_control’s Jazzy documentation, a controller update error and a hardware read or write error have different effects. A controller’s update() error deactivates that controller or its controller chain, after which Controller Manager attempts to start available fallback controllers. A hardware error stops the controllers using that hardware’s command or state interfaces.
The difference follows the dependency graph. Replacing a controller needs usable interfaces beneath it; restarting hardware needs those interfaces to be configured and exported again. A fallback-controller name addresses the first layer, while the resources it needs determine whether activation is possible.
The Jazzy Controller Manager documentation describes both error paths and the fallback_controllers parameter. This article follows those sections as checked on October 16, 2026; no controller, hardware component or recovery sequence was run.
The return value’s origin determines the affected scope
Controller Manager’s control loop reads state from hardware, updates controllers and writes commands to hardware. The same return_type::ERROR label can therefore originate at different points in the loop.
| Error origin | Documented response in Jazzy | Dependency to examine |
|---|---|---|
A controller’s update() |
Deactivate that controller or its entire chain, then try available fallback controllers | Controllers and interfaces required by the replacement strategy |
Hardware read() or write() |
Stop all controllers using that hardware’s command and state interfaces | Every controller consuming or commanding those hardware resources |
For the controller path, the chain is significant. A controller can produce a reference used by another controller instead of directly commanding hardware. An error in such a chain affects more than an isolated plugin name, because the connected control computation is being deactivated.
For the hardware path, the documented scope includes state-interface users as well as command-interface users. Looking only for the controller that writes an actuator command misses consumers of the failed hardware’s state. The relevant set comes from interface dependencies, not from which application last sent a goal.
The fallback behavior is explicitly attached to controller update errors in these sections. The hardware-error paragraph describes stopping dependent controllers; it does not describe the hardware error as an interchangeable trigger for the same replacement-controller route.
A fallback strategy can require more than one controller
The parameter is named <controller_name>.fallback_controllers. It lists controllers to activate when the associated controller fails during its update cycle. The documentation recommends including every controller needed for that strategy, including chainable controllers that export interfaces used by the main fallback controllers.
This explains why naming the top-level replacement may be incomplete. If that replacement writes through an interface exported by a second controller, the second controller is part of the working strategy. The dependency remains even if the two controllers have separate plugin instances and configuration sections.
The parameter describes a collection of controllers needed for fallback. Its documentation does not specify that a list should be interpreted as successive independent alternatives in priority order. Designing the list around interface dependencies gives each entry a concrete purpose.
An illustrative chain makes the interface requirement visible
Consider a hypothetical configuration with a primary chain A → B and a fallback chain C → D. These letters are invented controller names. In this example, A supplies references to B, and B uses the hardware’s command and state interfaces. C would supply references through D instead, while D connects the replacement strategy to the hardware.
| Hypothetical component | Role in the example | What it needs |
|---|---|---|
| A | Primary high-level controller | Interfaces exported by B |
| B | Primary hardware-facing controller | Hardware command and state interfaces |
| C | Main fallback controller | Interfaces exported by D |
| D | Chainable part of the fallback | The hardware interfaces used by the fallback strategy |
If A returns an update error and its primary chain is deactivated, listing only C leaves a dependency unexplained: C needs D’s exported interfaces. Including D identifies that dependency as part of the intended fallback strategy. At activation time, the required interfaces still have to be available.
Now change the failure in the example. If the hardware supplying the required state or command interfaces has returned an error, the resource problem sits underneath both chains. C and D still depend on those resources. Exchanging A and B for C and D does not recreate the hardware interfaces that the replacement needs.
The useful distinction is between an error in the primary control computation and an unavailable resource shared by both strategies. The first can leave a usable interface path for fallback. The second makes restoration of that path part of recovery.
Hardware restart rebuilds the resource side of the chain
The Operations section states that restarted hardware must go through its lifecycle again to reconfigure and export its interfaces. Restarting the process or device is therefore one event; restoring the interfaces consumed by controllers is another part of the sequence.
This gives controller reactivation a concrete prerequisite. The replacement controller needs its required interfaces, whether they come directly from hardware or through a chainable controller. If a hardware restart has changed their availability, that must be resolved on the hardware side before a controller can use them.
The same documentation separately describes restarting controllers through the controller-switching service or CLI by placing the relevant controllers in both stop and start lists. It also notes that some controllers, such as broadcasters, may not need a routine restart. That operational choice is distinct from a hardware error’s documented impact on all users of its command and state interfaces.
The ros2_control hardware-interface guide explains how Resource Manager, lifecycle and interface claims connect hardware to controllers. Fallback adds another route through that same resource structure, rather than bypassing it.
Read a fallback configuration as a dependency graph
A useful interpretation starts at the returned error and follows the affected interfaces. For a controller update error, identify the deactivated controller or chain and the complete replacement chain. For a hardware read or write error, identify all users of that hardware’s state and command interfaces and the lifecycle work needed to expose those resources again.
This keeps the fallback list meaningful: each named controller supplies a control function or an interface needed by another member. When activation cannot proceed, the next technical question is which required interface is unavailable and which component provides it. The answer points to the layer that needs attention—controller configuration, chain dependency or restarted hardware.