[Documentation] [TitleIndex] [WordIndex

API review

Proposer: E. Gil Jones

Present at review:

A bit of system design exposition

To give a bit of context on what's up with the planning scene stuff here's a system diagram specifically of how the planning scene system functions. The goal of this meeting is not system design, but I still thought it would be useful in reviewing the messages.

planning scene design

The EnvironmentServer node is at the center of every thing. It serves two primary roles - the first is to monitor the current state of the system (current robot state, collision map, collision objects) to provide a unified view of the state of the world as it affects arm navigation, and the other is to provide a unified view of the current or altered state of the world to all the arm navigation components - nodes like planners, trajectory filters, constraint-aware kinematics.

One primary use case for the system is for requests to MoveArm to actually move from the current position to another desired position. The other primary use case is for nodes other than move_<group_name> to make requests to arm navigation components. In particular, these other nodes may want to consider states other than the current state - for instance, whether a plan can be found to put a cup down in a particular location after the robot has actually picked up the cup. In either case the function of the planning scene system is identical. The calling node makes a GetPlanningScene.srv request to the EnvironmentServer - the request contains a planning_scene_diff, which contains all the changes from the current state of the system the calling node would like to make. For the move_<group_name> case this is likely to only be changes in link padding, allowed contacts, or ordered_collision_operations. For the latter use case this could also be changing collision objects or providing a new current robot state.

In either case, once the EnvironmentServer receives the call it first applies the diff to the current planning scene state to get a resolved planning scene. It then calls the SetPlanningScene.action for each of the arm navigation components that have previously registered that they are alive and would like planning scenes. The mechanism that is used for this registration is that each of the components contains a CollisionModelsInterface class that first advertises an action in the local namespace and then call a registration service in the EnvironmentServer on start-up. The EnvironmentServer looks up the calling node's name in the service request and in the registration callback creates an action client back to the CollisionModelsInterface. It then stores these actions in a map and will iterate through the map when a new call to the GetPlanningScene service occurs. The action in CollisionModelsInterface sets the internal collision model using the resolved planning scene and optionally calls a callback within the owner code that can take appropriate action when there's a new planning scene. The idea is that all arm navigation components get a unified view of the world such that planning, filtering, and kinematics all occur in a unified view of the world which may or may not be the current state of the world. Calls can then be made to plan, filter, find kinematics without requiring changing the world model. There's an implied resource given that only one planning scene can be shared among the arm navigation components at any given time.

Once all the components have done what they need to do for the new planning scene all the actions return and the EnvironmentServer returns the resolved planning scene in the response to GetPlanningScene. The calling node can then set its own CollisionModels class with the scene and make calls that directly manipulate the CollisionModels. Calling nodes can then safely also make calls to kinematics, planners, and trajectory filters repeatedly and efficiently.

What to review

All messages in arm navigation from unstable are fair game for review, though most have been previously reviewed. There are a whole bunch of message packages in arm_navigation (in rough dependency order):

One thing to note is that all fields have been removed from messages since review - references to LinkPadding, OrderedCollisionOperations, and AllowedContactSpecification are gone from some messages. The reason is that these are part of the planning scene.

New messages that are especially important to review

Messages that I propose to delete before release (no longer used, supplanted by PlanningScene, available from C++ API in a more complete manner)

Question / concerns / comments

Meeting agenda

To be filled out by proposer based on comments gathered during API review period

Conclusion

Stack status change mark change manifest)



2019-07-13 12:28