ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

How to locally allow object/gripper collision in electric ?

asked 2012-01-25 01:22:56 -0500

TomTUM gravatar image

updated 2014-01-28 17:11:11 -0500

ngrennan gravatar image

A) I ran into some trouble when trying to check robot states for validity in a collision aware grasping scenario.

It seems like one can publish a collision_object on the /collision_object topic and the planning scene will show this object and additionally cut the shape out from the collision_map. (This however does not always seem to work, it could however be that rviz is the problem when it comes to displaying the changed state.)

But now, when i run a state validity check similar to what is in the pr2_arm_navigation_tutorials, this seems to give the collision_map a reset and the cubes created by the object are back in the collision map.

Adding the object in the planning_scene_diff request as collision_object doesn't seem to help either: I still get collisions in the area of the object with collision_map and not the object, so the object seems not to be cut out. (If i would get collisions with the object and not the map, i could then additionally disable collisions with it via a CollisionOperation).

What am I overlooking?

B) On a related topic: how can i get the collision free ik to work with the desired state?

It seems like the query via planning_scene_diff alters the environment state used by the collision free ik service (*), is it also possible to use the service with different environent states concurrently?

It seems like the paradigm of checking state validity locally does not yet affect the coll. free ik service yet, is this functionality planned to be or already available like checking state validity?

(*) i can for example allow the gripper to collide with the collision_map globally.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2012-01-25 04:26:29 -0500

egiljones gravatar image

Hi Tom,

The system is pretty complicated, and these are good questions. To give you a bit clearer idea what's going on, I'll first refer you this document. When you publish a collision object on the /collision_object topic, it enters into the main planning scene - the one held by the environment server. This can be considered the current state of the world. It does not, however, automatically get pushed to the arm_navigation components - so collision aware IK will not know about the object if you start making calls to it directly. The planning scene only gets pushed to the various components (via the SyncPlanningScene action) when someone calls the SetPlanningSceneDiff service in the environment server. Note that this is NOT the service called in the get_state_validity.cpp function, though they have the same fields. Thus to get a collision object to the different components via the method of publishing a collision_object you then need to call the SetPlanningSceneDiff action afterwards with empty arguments - this will send the current planning scene held by the environment server to the different components.

The system now also provides an alternate way to populate arm navigation components with a collision object - instead of publishing the object on the collision_object topic, you can include it in the planning_scene_diff field in the service request. What this does is say to the environment server "take the current scene, apply the diff that I'm providing, and sync all arm navigation components to the diffed scene". Until the next time you call SetPlanningSceneDiff, all arm navigation components will contain the diffed scene, even if the current scene held by the environment server changes (a new collision map, published objects). There is only one scene held in the arm navigation components at a time, so if you are calling SetPlanningSceneDiff from multiple nodes with different scenes you may not get the scene that you are expecting.

The service called in get_state_validity is a little bit different. It tells the environment server "take the current scene, apply whatever diff I'm handing you, and return the result". This call doesn't affect the arm navigation components in any way. You then take this result and use it populate your own internal CollisionModel class, which provides a whole bunch of functions for collision checking and validity queries. In Electric for stuff like collision-aware IK and planning you need to use the SetPlanningSceneDiff method, but there's a lot you can do internally with CollisionModels.

Nodes will filter the collision_map for objects at the time their planning scene is set - if everyone agrees on what objects are in the world, then I think you'll start getting consistent behavior in that respect.

edit flag offensive delete link more


I indeed just mixed up the 2 services set_planning_scene_diff and get_planning_scene, seems to work just fine now.
TomTUM gravatar image TomTUM  ( 2012-01-25 23:44:54 -0500 )edit

Question Tools

1 follower


Asked: 2012-01-25 01:22:56 -0500

Seen: 393 times

Last updated: Jan 25 '12