Collision avoidance for attached object fails

[jrgnicho]

I've been working on a pick and place demo in which the robot picks up a box and moves it to another location while avoiding obstacles from the urdf and sensor data (octomap). I attempted to attached by publishing to the available move_group topics 'attached_collision_object' and 'planning_scene' but the box always passes through the obstacles as if it wasn't there. It seems that there are several other developers who have encountered this problem as well (see link: https://groups.google.com/forum/#!topic/moveit-users/34cvq4mtCoE )

[sachinchitta]

Is this with groovy or hydro?

[jrgnicho]

I have observed this same issue in both groovy and hydro. On Feb 22, 2014 11:18 PM, "Sachin Chitta" notifications@github.com wrote:

Is this with groovy or hydro?

Reply to this email directly or view it on GitHubhttps://github.com/ros-planning/moveit_ros/issues/411#issuecomment-35824259 .

[sachinchitta]

Could you also mention how you are calling move group - is this through move_group_interface (C++ or python), separately through the action interface or using the planning service?

[jrgnicho]

At first I tried with the move method of the move group interface, eventually I tried with the GetMotionPlan service but the results were the same. On Feb 23, 2014 9:47 PM, "Sachin Chitta" notifications@github.com wrote:

Could you also mention how you are calling move group - is this through move_group_interface (C++ or python), separately through the action interface or using the planning service?

Reply to this email directly or view it on GitHubhttps://github.com/ros-planning/moveit_ros/issues/411#issuecomment-35855726 .

[jrgnicho]

I forgot to mention that all of code for this application was in c++ On Feb 23, 2014 9:50 PM, jrgnicho@gmail.com wrote:

At first I tried with the move method of the move group interface, eventually I tried with the GetMotionPlan service but the results were the same. On Feb 23, 2014 9:47 PM, "Sachin Chitta" notifications@github.com wrote:

Could you also mention how you are calling move group - is this through move_group_interface (C++ or python), separately through the action interface or using the planning service?

Reply to this email directly or view it on GitHubhttps://github.com/ros-planning/moveit_ros/issues/411#issuecomment-35855726 .

[sachinchitta]

426 should fix one issue mentioned here: i.e. when move() is called from move_group_interface.

The other issue here : when the planning service is called, attached objects are ignored. I think this is actually correct behavior - the plan_kinematic_path service was designed to allow future planning, i.e. planning from a state that's not the current state. It will use a user-specified start state to populate the start for planning. If there are no attached objects in the user-specified start state, they will not be accounted for in the plan. However, there is a simple way to get around this:

If you are not filling in the start state, set start_state.is_diff = true. This should get the planner to not delete the attached objects. Note this only works for the plan only api. The plan and execute api calls (e.g. move()) will require the fix above.

@isucan - could please comment on this too.

[jrgnicho]

I'll test this fix on my pick and place application. In regards to your comment on the use of the planning service, I do specify a start state with an attached collision object in the service request. However, I've only tried the planning service approach in groovy for which there isn't a 'is_diff' field in the RobotStateMsg.

[sachinchitta]

If you specify the full start state (with attached collision object), you should leave is_diff as false. Otherwise, set is_diff to true.

[isucan]

@sachinchitta I think your explanation covers everything, and your suggested fix would work just fine. Please let me know if you still run into problems.