Implemented a more recent function from octomap for incredible speed up #47
Conversation
There was a problem hiding this comment.
Thank you very much for the pull request, this is a great improvement. However, it disables the currently working COLOR_OCTOMAP_SERVER.
Could you please
(a) Find a way to preserve the color octomap server.
(b) Perhaps, if possible, benchmark the performance improvement?
Thank you very much!
| @@ -1,5 +1,7 @@ | |||
| octomap_mapping | |||
| =============== | |||
|
|
|||
| Forked by Yonder Dynamics to implement latest features of octomap lib that allow for a 10x speed up. | |||
There was a problem hiding this comment.
Changes to README would have to be reverted prior to this pull request being merged.
| @@ -143,6 +143,7 @@ int main(int argc, char** argv){ | |||
| } | |||
|
|
|||
| try{ | |||
| ROS_INFO("Started"); | |||
|
|
||
| /* |
There was a problem hiding this comment.
Small change in this line, but you essentially replaced all of the specialized point cloud handling in the next 100 lines with the default OctoMap point cloud insertion, and hardcoded the option "discretize"=true. This could be done as speedup, but better as an optional parameter to octomap_server, because it creates different maps in the end (less information in them).
You also only insert the "nonground" point cloud, while the commented out 100 lines insert both ground and nonground, and give the option to filter out ground points while still using them for clearing obstacles - this is a significantly different behavior and different maps will be created in the end.
I haven't measured how much this increases performance by yet but it's a massive improvement that can't be understated. I just replaced the implementation that used insertPointCloud instead of directly inserting values. Code does need to be cleaned up though.