[ros-users] octomap_mapping depends on motion_planning_common

Armin Hornung HornungA at informatik.uni-freiburg.de
Mon Oct 10 09:58:31 UTC 2011

On 2011-10-07 23:02, Carlos J. wrote:
> I see. I was using your svn trunk directly (Repository Root:
> http://alufr-ros-pkg.googlecode.com/svn).
I just moved the diamondback-compatible version of the octomap_mapping 
stack into its own branch. The electric version is now maintained in 
trunk to avoid future confusion ;)

> I wanted to add Nearest
> Neighbor functionality to the octomap implementation of octrees by
> following what is done in the PCL Octree. I never completed the task
> due change in priorities and purposes.
If you get back to it and eventually have patches to contribute: That 
will be a very welcome addition to OctoMap and could be quite useful for 
many users! For easiest integration later I would suggest working 
directly on the OctoMap trunk (from sourceforge) instead of the released 
version included in the ROS stack.

Best regards,

Armin Hornung
Humanoid Robots Lab, Albert-Ludwigs-Universität Freiburg
Contact: http://www.informatik.uni-freiburg.de/~hornunga

More information about the ros-users mailing list