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

What is the intended workflow for using the PlanningSceneValidityServer?

asked 2012-06-11 06:27:52 -0500

Adolfo Rodriguez T gravatar image

updated 2014-01-28 17:12:38 -0500

ngrennan gravatar image

If I understand correctly, the PlanningSceneValidityServer provides a ROS service interface for performing state and trajectory validity checks (similar to how things were done back in diamondback).

I've been testing the fuerte implementation, and it seems to use whatever planning scene has been previously set (if any), by an external entity not part of the PlanningSceneValidityServer.

What was the original use case that inspired this node?. Before digging into the implementation, I was looking for something that would allow queries for the current robot state (and internally manage planning scene updates); this with the objective of simplifying these very common validity queries, because:

  • The amount of boiler plate code to do the same thing has grown since electric.

  • I'd rather not get/set the same planning scene multiple times from many (possibly remote) nodes, if they will all operate on the same scene.

TIA

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
2

answered 2012-06-11 06:57:16 -0500

egiljones gravatar image

The planning_scene_validity_server was put in place for users who still required a service call API for validity checks that were going to take a while - like checking the validity of a trajectory. Allowing these calls in the environment_server made it worse at maintaining the state of the system as the validity checks require locking underlying data structures. If you want to do validity checks from python using the validity server is your only real option. By design it only allows for validity checking of the last scene that was syncned and not necessarily the latest scene in the environment server.

For getting the robot state, you can still make service calls to the environment_server.

For validity checks if you are writing in C++ I would suggest fetching the planning scene from the environment server and making the checks using the C++ API for CollisionModels - this will be vastly more efficient than making repeated calls to the validity server.

In terms of system design, you should only need to setting the planning scene if you expect there to be new objects in scene (a collision map, published objects). If all you expect to happen is an updated robot state you can get that from the environment server and include it as part of the request you are making to an arm_navigation component like a planner or IK.

We realize that the system has gotten more complicated in some ways, but we believe the benefit in terms of efficiency, logging, and offline playback operation outweigh the complications.

edit flag offensive delete link more

Comments

good explanation. according to my test, to get the validity of a specified state, making a call to the service provided by planning_scene_validity_server costs about 0.4ms, while using the C++ API for CollisionModels onlys needs about 0.2ms

yangyangcv gravatar image yangyangcv  ( 2012-12-18 12:04:32 -0500 )edit

Question Tools

Stats

Asked: 2012-06-11 06:27:52 -0500

Seen: 177 times

Last updated: Jun 11 '12