Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

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.