Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Utilize footprint cost to check for collision avoidance #37

Open
2 tasks
padhupradheep opened this issue Jul 24, 2024 · 2 comments · May be fixed by #38
Open
2 tasks

Utilize footprint cost to check for collision avoidance #37

padhupradheep opened this issue Jul 24, 2024 · 2 comments · May be fixed by #38
Assignees
Labels
bug Something isn't working

Comments

@padhupradheep
Copy link
Member

padhupradheep commented Jul 24, 2024

Right now, the planner is not able to handle:

  • collision during in-place rotation for unsymmetrical platforms
  • collision in narrow aisles

In these cases, the planner could either through a invalid control exception which eventually leads to recovery behaviors or just wait for the global planner to replan.

@padhupradheep padhupradheep added the bug Something isn't working label Jul 24, 2024
@padhupradheep
Copy link
Member Author

On researching further, the local planner utilizes a lookahead point within the robot's footprint. This effectively won't help in any sort of collision detection for suddenly occurring obstacles. The collision check that is being performed right now is based on the projected robot pose, which in transformed to the respective map pixel and checked if there is a collision. This approach however does not consider the footprint of the robot, leading to collision for unsymmetrical platform.

Although on a real robot there is a safety scanner, it is essential for the local planner to plan an efficient path leading to efficient navigation.

@padhupradheep padhupradheep self-assigned this Jul 29, 2024
@padhupradheep padhupradheep linked a pull request Jul 29, 2024 that will close this issue
@padhupradheep
Copy link
Member Author

As part of #38, dynamic lookahead distance also needs to be documented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant