Skip to content

Remove start clear#4418

Merged
SteveMacenski merged 1 commit intomainfrom
4271_2
Jun 11, 2024
Merged

Remove start clear#4418
SteveMacenski merged 1 commit intomainfrom
4271_2

Conversation

@SteveMacenski
Copy link
Member

@SteveMacenski SteveMacenski commented Jun 11, 2024

We found that clearing the start made other orientations in the same pose also be "free" even though those might be in critical collision at other orientations. We know the start is "free" because it has to be definitionally since the robot is there.

This removes the clearing to fix that issue. Conveniently, we have defensive programming elsewhere that this makes it the only required change. Within the planner plugins themselves we already interpret 1 iteration as being start occupied and thus no valid potential path solution could be found, so we keep that contextual failure mode if there's no way out from the start.

Addresses #4271

@tonynajjar
Copy link
Contributor

Regression test?

@SteveMacenski SteveMacenski merged commit 9cc607c into main Jun 11, 2024
@SteveMacenski SteveMacenski deleted the 4271_2 branch June 11, 2024 23:43
Marc-Morcos pushed a commit to Marc-Morcos/navigation2 that referenced this pull request Jul 4, 2024
Marc-Morcos pushed a commit to Marc-Morcos/navigation2 that referenced this pull request Jul 4, 2024
Manos-G pushed a commit to Manos-G/navigation2 that referenced this pull request Aug 1, 2024
stevedanomodolor pushed a commit to stevedanomodolor/navigation2 that referenced this pull request Apr 29, 2025
@tonynajjar
Copy link
Contributor

@SteveMacenski would it make sense to bring back the starting pose collision check now that this is removed?

@SteveMacenski
Copy link
Member Author

SteveMacenski commented May 12, 2025

Intuitively, if the robot is at its start pose, doesn't that mean its not in collision by definition that it is currently occupying that space? If its critically in collision (not just against an obstacle but transported into another obstacle) that it is really not able to plan then my comment in the description of this revert PR still makes sense to me. It wouldn't be able to expand at all since any motion model from that pose would still also be in collision and we catch that right now interpreted as a StartOccupied. If its barely in collision, then it could expand outward - which I think is what you would probably want?

I would think this is good behavior you want so that your robot can recover itself from bad situations where it ends up potentially up against or very close to other obstacles for whatever reason.

If not, then I could support adding it back in as a parameterized feature (default off, since I think most people would want that default off to have the easiest recovery path possible).

@tonynajjar
Copy link
Contributor

tonynajjar commented May 14, 2025

I would think this is good behavior you want so that your robot can recover itself from bad situations where it ends up potentially up against or very close to other obstacles for whatever reason

I can see this point. My concern is that in such scenarios, by pure visual interpolation, I don't trust that that it can go from pose 1 (fully horizontal inside the lethal zone) to pose 2 without colliding with the lethal space at the border of the pose 1.

image

@SteveMacenski
Copy link
Member Author

SteveMacenski commented May 14, 2025

OK - I'd be OK with throwing that exception on the initial pose check if you wanted to make it a parameter about whether to do it or not 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants