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