-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Check for free space directly from laser scan #517
Comments
Can you explain the motivation? |
@SteveMacenski I've updated the issue description with some motivation. |
I think this should be a server or plugin interface where one implementation of it could be looking at a laserscan. Some robots don't have lasers or lasers appropriate for that application due to resolution, size, or placement. Checking the costmap lets you fuse in other sensors (multiple lidars, radar, sonar, depth, etc) which should be generally used. If you're trying to make some type of collision zone type of implementation, I'd make sure its configurable for multiple robot setups but generally still advise to use the costmap unless you're wanting to query this at 100Hz or something |
Also, for a low-level safety check, I'd expect you'd want it isolated in a separate process from the potentially complex world model. Can you explain how this relates to self-localization? |
I'd like to close this issue. I think we no longer need this now that we can run costmaps in the odom frame. |
In the world model, enable a service for checking for free space directly from laser scans instead of going through a costmap (or another world representation) with the region specified relative to the robot.
There are two cases where measuring the distance to an object would be beneficial:
See #516 for more background info.
The text was updated successfully, but these errors were encountered: