Closed doisyg closed 9 months ago
No, it cannot be backported as it breaks ABI/API stability policies.
Oh, thanks @SteveMacenski for your fast reply.
Do you think it's possible (for example, for me) to backport this functionality into a similar package that would not be part of the Nav2 stack but would work independently? To avoid this stability policies issue.
Do you think it's possible (for example, for me) to backport this functionality into a similar package that would not be part of the Nav2 stack but would work independently? To avoid this stability policies issue.
Nothing prevents you from forking Nav2 and backporting the feature in your fork
First of all, thanks a lot to @AlexeyMerzlyakov and @SteveMacenski for the collision monitor. I am finding myself in a new company and having yet again to implement something similar to the collision monitor. Just started experimenting with it. It is great to be able to find this brick part of nav2.
A bit of context about my use case: a robot with a full certified low-level functional safety where we are using nav2 on top and with the collision monitor configured with slightly more conservative zones in order to never trigger the low level safety.
Feature description
A stop zone with optional allowed degree of freedoms in order to avoid having a robot stuck. For instance:
For a circular robot
When obstacle in the zone, forbid linear speeds, but allow rotations / angular z speeds
For a rectangular bi-directional robot
When obstacle in the zone, forbid angular speeds, forbid linear speed in one direction but allow in the inverted direction (i.e. when an obstacle is in front of the robot, allow to go backward)
Implementation considerations
TBD if this feature is seen as useful. I will happily propose an implementation and a PR.