Before proceeding, is there an existing issue or discussion for this?
Description
PR #36 adds active-route blockage detection to the plan executor. The current implementation uses three hard-coded constants:
BLOCKAGE_DEBOUNCE = 300 ms: how long a route must remain blocked before reporting CODE_PATH_BLOCKEDREPLAN_COOLDOWN = 2 s: minimum delay between blockage reportsOCCUPIED_THRESHOLD = 50: occupancy-grid value above which a cell is treated as blocked
These defaults work for the current demos but have not been tuned across different robots, map update rates, or deployments.
Implementation Considerations
Expose the values as ROS parameters while preserving the current defaults.
The implementation should:
- Reject negative debounce and cooldown durations
- Restrict the occupancy threshold to valid occupancy-grid values
- Document how each parameter affects replanning
- Test the default values and parameter overrides
We should also consider whether the parameters belong to the plan executor globally or need per-robot overrides.
Alternatives
Keep the values hard-coded. This is simpler, but tuning them would require rebuilding the plan executor and would make deployment-specific configuration difficult.
Additional information
This follows review feedback on #36 requesting a ticket to document and track these constants.
Before proceeding, is there an existing issue or discussion for this?
Description
PR #36 adds active-route blockage detection to the plan executor. The current implementation uses three hard-coded constants:
BLOCKAGE_DEBOUNCE = 300 ms: how long a route must remain blocked before reportingCODE_PATH_BLOCKEDREPLAN_COOLDOWN = 2 s: minimum delay between blockage reportsOCCUPIED_THRESHOLD = 50: occupancy-grid value above which a cell is treated as blockedThese defaults work for the current demos but have not been tuned across different robots, map update rates, or deployments.
Implementation Considerations
Expose the values as ROS parameters while preserving the current defaults.
The implementation should:
We should also consider whether the parameters belong to the plan executor globally or need per-robot overrides.
Alternatives
Keep the values hard-coded. This is simpler, but tuning them would require rebuilding the plan executor and would make deployment-specific configuration difficult.
Additional information
This follows review feedback on #36 requesting a ticket to document and track these constants.