Part of #570.
Summary
Someone sets a gain, a frame name or use_sim_time from the command line during a test and never reverts it. A launch file overrides a value that a later config file was supposed to own. The node reads the parameter once, keeps running, and logs nothing. The robot behaves slightly differently and everything reports healthy.
ros2 param get shows the current value, but nothing shows that it is not the value the node started with, or not the value it was supposed to have. To find it by hand you already need to suspect the right parameter.
Proposed solution
Read node parameters and report a value that no longer matches its reference, with two ways to define that reference:
- self-capture: remember the value the parameter had when the node armed, and report later changes. This needs no configuration and covers the "someone changed it during the run" case.
- a pinned expected value in config. This covers the case self-capture cannot see by construction, a value that was already wrong on the first tick.
Three things it has to be careful about.
Reading parameters is a service call into another node. Every detector so far reads the local graph cache and is free to be exhaustive every tick. This one is not, so it needs a budget on calls per tick, and it must not run on the gateway executor, or one node that stops answering stalls the gateway itself.
A changed value is not automatically a broken robot. The fault should say what moved and leave the judgement to whoever reads it, so WARN rather than ERROR.
A node that is missing from one sweep must not immediately lose its captured baseline. Otherwise a discovery gap turns into a fresh capture and a real drift disappears behind it.
Also in scope
Nested per-detector configuration has no end-to-end proof in this package today. Every test calls configure() with hand-built JSON, so nothing covers the path from YAML through the gateway into a detector. This detector's pinned-value rule is the natural place to prove it.
Part of #570.
Summary
Someone sets a gain, a frame name or
use_sim_timefrom the command line during a test and never reverts it. A launch file overrides a value that a later config file was supposed to own. The node reads the parameter once, keeps running, and logs nothing. The robot behaves slightly differently and everything reports healthy.ros2 param getshows the current value, but nothing shows that it is not the value the node started with, or not the value it was supposed to have. To find it by hand you already need to suspect the right parameter.Proposed solution
Read node parameters and report a value that no longer matches its reference, with two ways to define that reference:
Three things it has to be careful about.
Reading parameters is a service call into another node. Every detector so far reads the local graph cache and is free to be exhaustive every tick. This one is not, so it needs a budget on calls per tick, and it must not run on the gateway executor, or one node that stops answering stalls the gateway itself.
A changed value is not automatically a broken robot. The fault should say what moved and leave the judgement to whoever reads it, so WARN rather than ERROR.
A node that is missing from one sweep must not immediately lose its captured baseline. Otherwise a discovery gap turns into a fresh capture and a real drift disappears behind it.
Also in scope
Nested per-detector configuration has no end-to-end proof in this package today. Every test calls
configure()with hand-built JSON, so nothing covers the path from YAML through the gateway into a detector. This detector's pinned-value rule is the natural place to prove it.