Summary
State‑interface–based controllers (e.g., pendulum tests) show nondeterministic initialization behaviour across hardware and CI environments. This forces relatively long RM initialization timeouts (currently ~1.5–2.0 s) and make pendulum tests (pasive hardware) more fragile than command‑interface–based ones (active hardware), which consistently initialise in <0.2 s.
This issue proposes discussing an architectural mechanism to stabilise state interfaces during startup, potentially enabling deterministic initialization and lower RM timeouts.
Problem Description
Command interfaces initialise deterministically because they do not depend on external state propagation.
State interfaces, however, depend on:
- Gazebo physics startup
- plugin initialization
- first state publication
This introduces nondeterminism that varies with CPU load, distro, and simulation timing.
The pendulum test (introduced in PR #765) is the clearest example: it is the only test that cannot reliably initialise under 0.2 s —not even under 1 second. See ISSUE #801 and PRs #809 and #831 for more context.
Even with improved test logic (e.g., checking the first stable value instead of the first sample), the underlying nondeterminism remains.
Proposed Direction: Startup Alignment Controller
A potential architectural solution is introducing a small controller that activates only during startup:
- Activates before the real controller
- Sends a known command (e.g., hold or move to URDF initial position)
- Waits until the state stabilizes around the expected value
- Deactivates itself
- Hands control to the real controller
This would act as a “phantom hand” that ensures deterministic initial conditions for passive joints without modifying the real hardware interface.
Such a mechanism could:
- Eliminate dependence on the first nondeterministic state sample
- Reduce variability across machines and CI
- Allow significantly lower RM initialization timeouts
- Improve reliability of state‑interface tests
Related Improvements (Context Only)
These are not part of the proposal but are closely related:
Stable‑value checker:
A test‑side improvement that waits for the first stable state value instead of the first sample.
This improves correctness but does not solve nondeterministic startup.
RM timeout reduction:
If startup becomes deterministic, RM timeout could potentially be lowered from ~1.5–2.0 s to something closer to command‑interface behavior.
This would be a follow‑up discussion.
Request for Feedback
Before exploring prototypes, I’d like to ask:
- Is a startup/alignment controller conceptually aligned with ros_controls’s architecture?
- Would this be acceptable as an optional mechanism for simulation and CI?
- Are there existing patterns or constraints that should be considered?
I’m happy to refine the idea based on feedback or explore alternative approaches if this direction is not appropriate.
Summary
State‑interface–based controllers (e.g., pendulum tests) show nondeterministic initialization behaviour across hardware and CI environments. This forces relatively long RM initialization timeouts (currently ~1.5–2.0 s) and make pendulum tests (pasive hardware) more fragile than command‑interface–based ones (active hardware), which consistently initialise in <0.2 s.
This issue proposes discussing an architectural mechanism to stabilise state interfaces during startup, potentially enabling deterministic initialization and lower RM timeouts.
Problem Description
Command interfaces initialise deterministically because they do not depend on external state propagation.
State interfaces, however, depend on:
This introduces nondeterminism that varies with CPU load, distro, and simulation timing.
The pendulum test (introduced in PR #765) is the clearest example: it is the only test that cannot reliably initialise under 0.2 s —not even under 1 second. See ISSUE #801 and PRs #809 and #831 for more context.
Even with improved test logic (e.g., checking the first stable value instead of the first sample), the underlying nondeterminism remains.
Proposed Direction: Startup Alignment Controller
A potential architectural solution is introducing a small controller that activates only during startup:
This would act as a “phantom hand” that ensures deterministic initial conditions for passive joints without modifying the real hardware interface.
Such a mechanism could:
Related Improvements (Context Only)
These are not part of the proposal but are closely related:
Stable‑value checker:
A test‑side improvement that waits for the first stable state value instead of the first sample.
This improves correctness but does not solve nondeterministic startup.
RM timeout reduction:
If startup becomes deterministic, RM timeout could potentially be lowered from ~1.5–2.0 s to something closer to command‑interface behavior.
This would be a follow‑up discussion.
Request for Feedback
Before exploring prototypes, I’d like to ask:
I’m happy to refine the idea based on feedback or explore alternative approaches if this direction is not appropriate.