Chris Schindlbeck

So apparently this issue has been solved, see https://github.com/ros-planning/moveit/issues/416 https://github.com/ros-planning/moveit/pull/869 Can you confirm that this solves your problem?

I switched to moveit from source and upgraded the ROS packages via apt-get. I am a little bit confused, i still see libompl.so.1.2.1 in /opt/ros/kinetic/lib/x86_64-linux-gnu. Shouldn't that be libompl.so.1.2.3? @RhysMcK...

So today i tested my setup again as in https://github.com/ros-industrial/kuka_experimental/issues/123 where i got the same error with moveit from source and (hopefully) the new OMPL (i used the default time...

Yes. This is the issue discussed in https://github.com/ros-industrial/kuka_experimental/issues/126 and unfortunately it has not been resolved yet. I slow down the robot to mitigate this issue at least a little bit.

Reverted changes to adhere to indigo convention, changed to default KUKA colors, and added dummy inertial values

> Another alternative could be to use approximations based on primitive shapes (such as is done in the universal_robot urdfs (here)). The mass values of the UR look like accurate...

So i added a common_robotparameters.xacro in kuka_resources where we could store all "identified" robot parameters such as mass, link lengths in DH notation, cog etc I also added the cylindrical...

My ideas were: - The kuka agilus series has many common link lenghts, therefore using a single file would mitigate redundancy/error proneness - DH notation is a common convention that...

I have put all code into the kr10r1100sixx_macro.xacro. I still think it would make sense to outsource the cylinder_inertial macro but i leave this discussion to #105 Do the link...

> I'm not sure which link names you are referring to? These: ``` + + + + + + + ``` as in [here](https://github.com/ros-industrial/universal_robot/blob/ad740e0dd028cd9614b869d306dfc2da402cbc46/ur_description/urdf/ur10.urdf.xacro#L34-L39)