Hi everyone,
Following the suggestion from @saikishor and @christophfroehlich in the ros-controls repository (Issue #2420), I’m opening this thread to discuss the execution order of chainable controllers when a cyclic dependency is introduced.
The Problem
Currently, controller_manager uses update_list_with_controller_chain to determine the execution order. However, when a cycle is formed, the behavior becomes non-deterministic. For example:
-
Controller A (State) → Controller B (State)
-
Controller B (State) → Controller C (Command)
-
Controller C (Command) → Controller D (State/Command)
-
Controller D (State) → Back to Controller B
In this “cyclical” setup, the controller manager will still pick an execution order and run, but the order is essentially undefined. This means the state data might be “fresh” in one run and “one-cycle old” in another, leading to inconsistent control performance or hard-to-debug jitter.
The Proposal
To improve safety and determinism, we are considering adding a topological cycle detection step inside the controller manager. Instead of silently running with undefined behavior, the manager would:
-
Detect the cycle during the configuration/activation phase.
-
Reject the configuration.
-
Throw an explicit error identifying exactly which controllers form the loop.
Why we need your input
Before we implement a hard restriction that rejects cyclic graphs, we want to understand the impact on the community:
-
Are there valid use cases where you are intentionally using a cyclic dependency (perhaps relying on a one-step delay) in production?
-
Would you prefer a hard error (Failure) or a warning with a forced standard order?
-
Do you believe a cyclic chainable dependency should be strictly treated as an illegal configuration to ensure real-time determinism?
We want to make sure we don’t break specialized setups that might be using this “feature,” even if it is currently undocumented.
Let us know your thoughts!