-
Notifications
You must be signed in to change notification settings - Fork 451
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
Moving map around robot pose #26
Comments
No, this is currently not possible. With some effort some sort of moving map functionality (either growing map tiles behind the scenes or copying around maps in double buffer fashion) would be possible, but there currently are no plans to implement this from my side. |
Thank you Stefan. At the moment, I'm using a huge map and periodically clearing out the old cells far from the robot. This does have a drawback of using up a lot of RAM. A moving map may not be so practical to do in realtime -- probably the concept of submaps is better |
You could give hector_mapping2 a try. The package implements the same algorithm as hector_mapping in this repo, but it also supports tiled 2D and 3D maps. It is not very well tested, so do not expect good and stable results with the current development version. As with hector_mapping, the map origin is the initial pose of the robot when mapping was started, but the map grows as soon as a laser scan reaches the current boundaries. Not sure if the current costmap_2d package in the navigation stack can handle this - at the time I was working on hector_mapping2 I needed a patched version to allow for map size changes. |
Cool will check it out. Thanks |
how can i use this package ? |
Is it possible to move the start position of the map in realtime such that the map generated with always have its center as the robot pose? -- something like the costmap in move base. At the moment if the robot goes beyond the limits of the map size, it loses localization.
The text was updated successfully, but these errors were encountered: