[ros-users] octomap_mapping depends on motion_planning_common

[Armin Hornung]

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



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