-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
[AMCL] reduce the amount of memory used #4426
[AMCL] reduce the amount of memory used #4426
Conversation
8a9516d
to
1d798cb
Compare
|
@facontidavide, your PR has failed to build. Please check CI outputs and resolve issues. |
bc58877
to
2c548d7
Compare
UPDATE: sorry I don't understand why this PR include files outside nav2_amcl. I will clean it up Also, I removed the limitation in terms of maximu size of the map, so ignore the 3.2 km remark from @doisyg |
@facontidavide, your PR has failed to build. Please check CI outputs and resolve issues. |
Signed-off-by: Davide Faconti <[email protected]>
2c548d7
to
728abf3
Compare
@facontidavide, your PR has failed to build. Please check CI outputs and resolve issues. |
Signed-off-by: Davide Faconti <[email protected]>
@facontidavide, your PR has failed to build. Please check CI outputs and resolve issues. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Otherwise LGTM. AMCL changes usually scare me since its been untouched for so long, but this is minor and I don't foresee any issues.
double->float
there's a reason MPPI/Smac both use floats for everything, I found massive improvements in performance on it alone, but I haven't had the cycles to try to apply that to the full stack to see how much more it could be reduced (though, those are 2 of the heaviest operations outside of the costmap).
Party on! What's next for memory consumption? 😎
|
Signed-off-by: Davide Faconti <[email protected]>
Still a draft, should I merge this in? |
if it is good for you, it is good for me. I will prepare tomorrow a PR for the documentation https://docs.nav2.org/configuration/packages/configuring-amcl.html?highlight=amcl |
😄 sparse costmaps ??? Not yet... not yet... |
Please do update the configuration guide docs for this param. You can also announce it in the Iron->Jazzy migration guide file since Nav2 hasn't forked for Jazzy yet (still working on it..)
Well before you go nutty there, lets discuss that. I have a broader plan for costmaps in the medium term future 😉 |
Keep me in the loop! I am sure I can take some work out of your plate 😉 |
* iprove memory used by AMCL and add parameter "freespace_downsampling" Signed-off-by: Davide Faconti <[email protected]> * fix message and linting Signed-off-by: Davide Faconti <[email protected]> * add class member Signed-off-by: Davide Faconti <[email protected]> --------- Signed-off-by: Davide Faconti <[email protected]>
[AMCL] reduce the amount of memory used, backport of upstream (ros-navigation#4426)
* iprove memory used by AMCL and add parameter "freespace_downsampling" Signed-off-by: Davide Faconti <[email protected]> * fix message and linting Signed-off-by: Davide Faconti <[email protected]> * add class member Signed-off-by: Davide Faconti <[email protected]> --------- Signed-off-by: Davide Faconti <[email protected]>
* iprove memory used by AMCL and add parameter "freespace_downsampling" Signed-off-by: Davide Faconti <[email protected]> * fix message and linting Signed-off-by: Davide Faconti <[email protected]> * add class member Signed-off-by: Davide Faconti <[email protected]> --------- Signed-off-by: Davide Faconti <[email protected]>
This changes likelihood storage from double to float, inspired by ros-navigation/navigation2#4426 . As a side-finding, this fixes a bug in the `make_likelihood_field()` function which causes memory footprint to go through the roof for large maps. Basically, because we applied the `max_obstacle_distance` threshold **before** calculating the distance map, for distances larger than `max_obstacle_distance` the priority queue in `nearest_obstacle_distance_map()` was processing the map in a random fashion instead of the "advancing wavefront" that the algorithm is meant to do. This caused the priority queue length to be almost as large as the map itself. This change does not affect either the accuracy or the average CPU usage. --------- Signed-off-by: Gerardo Puga <[email protected]>
Basic Info
Description of contribution in a few bullet points
This is a memory optimization that should not affect realtime perfomance, but will reduce considerably the amount of memory used by AMCL.
In our large map (200 Mb) this is the memory usage before the change:
And after the changes:
The main changes are:
map_cell_t
: reduction from 12 bytes to 5 bytesfree_space_indices
using 1/4th of the points (equally spaced)Description of documentation updates required from your changes
Describe the new parameter "freespace_downsampling"
Future work that may be required in bullet points
To be discussed
For Maintainers: