Frontier detection RFC

[ojura]

Rendered

[ojura]

More specifically about the plugins idea: ROS offers pluginlib for dynamically loading plugins into ROS nodes. Rviz uses this (the Submaps plugin, for example).

If cartographer_ros offered a plugin API where we could execute the plugin code in OnLocalSlamResult, this would be sufficient for having a standalone implementation of frontier detection.

[sebastianklose]

Thanks @ojura for your RFC. The results look very interesting.

Without having looked at your code in detail, I would vote against adding a plugin architecture to cartographer_ros for this purpose. I would be fine with the idea of opening up the MapBuilderBridge to become an interface that can be implemented differently for the frontier detection.
WDYT?

[ojura]

Can you please elaborate more? You think this could be merged upstream?

The code for frontier detection is more or less fully contained in cartographer_ros/frontier_detection.cc / .h, and is called from OnLocalSlamResult. The code for frontier detection does require Cartographer(_ros) headers and access to Cartographer internals (specifically, the submap occupancy grid values, and their optimized poses). Adding the needed wiring to MapBuilderBridge sounds like a good idea in any case, but does not resolve the issue of this code being highly dependent on cartographer_ros (since it needs to run inside the cartographer_node executable if we want speedy access to submap grids). If it is not merged upstream, I see no other option than living in a fork of cartographer_ros like at the present, or as a standalone plugin making use of a plugin API.

I have a couple of other ideas for specializing robotics algorithms for Cartographer (for example, submap-level path planning), so that's why I'm rooting for a plugin API where we could write plugins which make use of Cartographer internals, but can live as standalone Catkin packages.