Re: [ros-users] octomap_mapping depends on motion_planning_c…

I see. I was using your svn trunk directly (Repository Root:
http://alufr-ros-pkg.googlecode.com/svn). 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.

Thanks for pointing out the appropriates source code repo for
electric. I will use that instead when I get back to it.

Carlos

2011/9/9 Armin Hornung <HornungA@informatik.uni-freiburg.de>:
> Hello Carlos,
>
>> There seems to be a broken dependence from octomap_mapping's
>> octomap_server to motion_planning_common's
>> mapping_msgs::CollisionObject. Surprisingly, the octomap_server from
>> binary depends instead of arm_navigation_msgs (e.g. #include
>> <arm_navigation_msgs/CollisionObject.h>), whereas the octomap_server
>> from source depends on motion_planning_common's mapping_msgs
>>
> Which ROS distribution are you using? From the problem you ran into I
> assume you're building octomap_mapping trunk against electric.
>
> There are two binary versions of the octomap_mapping stack, one for
> diamondback and one for electric. Those are built from two different
> source versions. The change you observed concerning CollisionObject is
> the reason why there are different branches required. Check the
> "releases" page of the stack for details:
> http://www.ros.org/wiki/octomap_mapping/Releases
>
> trunk of octomap_mapping currently builds with diamondback, while the
> "octomap_mapping-unstable" branch builds with ROS unstable and electric.
>
> To save you all the hassle - just rely on the released binary packages
> if you're using Ubuntu ;)
>
> Best,
> Armin
>
> --
> Armin Hornung
> Humanoid Robots Lab, Albert-Ludwigs-Universität Freiburg
> Contact: http://www.informatik.uni-freiburg.de/~hornunga
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>