ntnu-arl / gbplanner_ros

Graph-based Exploration Planner for Subterranean Environments
BSD 3-Clause "New" or "Revised" License
648 stars 147 forks source link

Integration with other SLAM Algorithms #14

Closed derektan95 closed 2 years ago

derektan95 commented 2 years ago

Hi @MihirDharmadhikari,

I wonder if this graph-based planner can work with other types of SLAM algorithms such as RTABMap? It has the flexibility to allow us to map the scene with RGBD input, while localizing using 3D LiDAR input. It has the ability to output octomaps incrementally that is local to the robot's SLAM pose, similar to submaps in VoxGraph. This seems to be compatible with this package as reference to the GBPlanner1's README.md.

However, please be aware that the planner requires several dependencies; for example:

Mapping framework: either Voxblox or Octomap
Planner-Control interface package: pci_mav
MAV simulation: RotorS, LiDAR simulator

By extension, how about RTABMap's potential integration with COHORT? Would be amazing to see how we can integrate this exploratory planner to existing ROS frameworks that is used by many others. (I am currently using RTABMap for localization, and move_base to send navigation goals)

Regards, Derek

MihirDharmadhikari commented 2 years ago

Hello @derektan95 ,

Currently GBPlanner2 works independent of the localization method. So RTABMap can be used for localization. However, for volumetric mappingGBPlanner2 only supports Voxblox due to the optimizations done in the planner for the same. As long as the correct transform from the sensor frame to the world frame exists in the tf tree, the Voxblox server will build the correct volumetric map irrespective of the localization method used. As you correctly pointed out, GBPlanner1 supports both Octomap and Voxblox, but GBPlanner2 only supports Voxblox.

In future we do plan to integrate GBPlanner with the existing ROS frameworks like the ROS Navigation Stack to address a broader user community.

Similar to GBPlanner, COHORT also works independent of the robot's onboard localization solution hence RTABMap can be used onboard the robots for localization.

I hope this helps.

Best, Mihir

derektan95 commented 2 years ago

Hi @MihirDharmadhikari,

Great to hear from you. Just a follow-up question:

Is it efficient to run both VoxGraph and Rtabmap at the same time? For RTABMap, I have configured it to run Iterative Closest Point on consecutive 3d lidar scans to derive accurate SLAM pose (i.e. sensor frame -> world frame). Similarly, it seems to me that VoxGraph operates by converting pointcloud input into Sign Distance Function submaps, which are geometrically aligned to each other to derive the robot's SLAM pose.

_Based on your suggestion, I could use RTABMap to derive the sensor -> world frame, while generating the voxblox volumetric map using the Voxblox server (I assume voxblox params are loaded into the gbplanner node in this launch file)._ But won't running core gbplanner launch file (which pressumably runs VoxGraph) perform redundant work that RTABMap is already doing? In other words, won't it be wasted effort to generate SDF submaps and perform geometric alignment to derive the robot's SLAM pose when RTABMap is already doing it? Are there parameters to set such that VoxGraph will not perform unnecessary steps when accurate sensor -> world frame transforms are already derived from other SLAM algorithms (like RTABMap)?

  <node pkg="gbplanner" type="gbplanner_node" name="gbplanner_node" output="screen" launch-prefix="$(arg launch_prefix)">
    <remap from="odometry" to="$(arg odometry_topic)" />
    <remap from="/pointcloud" to="/input_pointcloud" />
    <rosparam command="load" file="$(arg gbplanner_config_file)" />
    <rosparam command="load" file="$(arg map_config_file)" />  <!-- $(find gbplanner)/config/$(arg robot_name)/voxblox_sim_config.yaml -->
  </node>

Hope you could give me some pointers on how I can modify the launch file to integrate RTABMap with GBPlanner2 efficiently.

Thanks as always, Derek

MihirDharmadhikari commented 2 years ago

Hi Derek,

GBPlanner does not use VoxGraph. It uses Voxblox, which is used only for volumetric mapping and takes the sensor -> world transform provided externally. Hence, it will not do the redundant calculation of deriving this transform. The launchs file provided in the demos only launch Voxblox server, VoxGraph is not used anywhere.

Hope this helps.

Best, Mihir

derektan95 commented 2 years ago

Hi @MihirDharmadhikari,

Thanks for the prompt response. I am getting a much better understanding of this repository now. I understand now that GBPlanner2 only uses VoxBlox for volumetric mapping at the sensor -> world tf provided by any external source.

Am I then right to say that VoxGraph is used only in COHORT? I am getting this impression because this COHORT explanation video specified the use of VoxGraph as a centralized mapping framework to align and fuse VoxBlox submaps from each robot. This merged map is used to identify and assign exploration volumes for robots to explore in. Your paper suggest likewise.

Thanks as always, Derek

MihirDharmadhikari commented 2 years ago

Hi Derek,

Yes, Voxgraph is only used by COHORT to align and merge the submaps from all the robots on a centralized ground station. Whereas GBPlanner onboard each robot only uses Voxblox as the volumetric mapping framework.

Best, Mihir

derektan95 commented 2 years ago

Hi @MihirDharmadhikari,

That's great. I have a much better understanding of this project now, after having read the VoxBlox and VoxGraph papers too. Looking forward to trying out COHORT when it's out. Good luck with your academic endeavours!

Regards, Derek