Closed pabloinigoblasco closed 10 months ago
"The goal of a localization system is keep a continous track of the position of the robot (not just finding some initial position - amcl is itself able to converge by its own even without any initial position)"
Initializing AMCL with uniformly distributed particles is an option as you suggested. But in order to converge, the robot has to be manually moved around. With this package setting the initial pose, you can start autonomous navigation immediately.
The reason this package isn't a great replacement for AMCL for all cases is that this localization is expected to fail if there are repeating patterns in the global map.
But if there aren't repeating patterns in your specific map, it might be a good replacement for AMCL.
As stated before, we believe setting the initial position is the best use for this package in a general scenario. And that is what we meant by Nav2 integration.
But feel free to use this package in anyway that is appropriate for your use case.
Hello ashinwinkNV, thanks for your answer.
"The goal of a localization system is keep a continous track of the position of the robot (not just finding some initial position - amcl is itself able to converge by its own even without any initial position)"
Initializing AMCL with uniformly distributed particles is an option as you suggested. But in order to converge, the robot has to be manually moved around. With this package setting the initial pose, you can start autonomous navigation immediately.
Potentially, you could use trigger the amcl update to make it converge even without motion.
The reason this package isn't a great replacement for AMCL for all cases is that this localization is expected to fail if there are repeating patterns in the global map.
I wonder if this is based on this documentation. This appears to be a particle localization filter. Shouldn't it be capable of handling multi-hypothesis scenarios?
But if there aren't repeating patterns in your specific map, it might be a good replacement for AMCL.
I believe the whole point of implementing a localization algorithm on a graphics card is to offload the intensive computation of mathematical operations from the CPU, which may be resource-limited in embedded systems. That only makes sense if you need to make this computation continously in real time, not just once. Transferring a particle filter algorithm that can be parallelized to a GPU seems like a great strategy. Therefore, in my opinion, this should be considered an alternative to AMCL regardless of its precision or any other consideration.
It's true that we observed a shaky effect in pose estimation, which is quite bothersome. We're still determining whether this is a limitation of the mathematical algorithm or a result of incorrect parameterization (we used the default settings).
As stated before, we believe setting the initial position is the best use for this package in a general scenario. And that is what we meant by Nav2 integration.
But feel free to use this package in anyway that is appropriate for your use case.
I do not get the point of using the algorithm in the gpu for a single one-shot computation.
Thanks. Regards.
Hi @pabloinigoblasco
Is the commits you made suitable to replace AMCL for Nav2 usage? I am looking for alternative to replacing the default nav2 amcl.
Best, Samuel
The current implementation of isaac_ros_map_localization does not publish the output transform into tf following the REP 105.
"The goal of a localization system is keep a continous track of the position of the robot (not just finding some initial position - amcl is itself able to converge by its own even without any initial position)" (answering https://github.com/NVIDIA-ISAAC-ROS/isaac_ros_map_localization/pull/22#issuecomment-1791695390)
The previous implementation publishes the robot position in the /localization_result topic (using the global /map reference frame) but nothing is published in /tf according (to REP 105)
To support nav2 it is required to publish the /map -> /odom transform via a tf2 broadcaster. From my point of view, without these proposed changes we could not claim that this package is integrated with nav2.