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

Revision history [back]

click to hide/show revision 1
initial version

What are the options to adapt the trajectory

1)

When you send a MoveGroup request to plan and execute, the path will be checked against every geometry update in the scene. If you additionally set replan == true (and the associate parameters) in your request, the planner will be invoked again in this case to generate a new collision-free trajectory and execute the new one.

Many people do not see this functionality because it will not work if you execute a previously generated/planned trajectory through the ExecuteTrajectory action, e.g., plan first, and then pass the trajectory to execution. That's weird, but in this case the engine should not be allowed to replan on it's own and execute a different trajectory. If you would like to see trajectory execution abort in this case, please write a pull-request. :)

During execution, the remaining path, which is actually collision-checked, is estimated based on passed time since triggering the trajectory controller. That's a caveat of the concrete implementation when execution time is not sufficiently deterministic, e.g., when working with compliant controllers or time scaling.

Additionally, the planner is not informed of the aborted trajectory, so the new trajectory might take a very different path when a minor adaptation would have been sufficient. That's also something that could be improved via the GenericTrajectory field that was added long after.

2)

moveit_servo (is be a very different interface with overlapping use-cases) will automatically slow-down and stop in front of dynamic obstacles, but does not replan - a higher-level interface would have to be added.

3)

In MoveIt2 there is ongoing work on a hybrid planner framework to implement such a schema, but this is still in development/redesign phases and I haven't seen it run on a real system.

4)

For anything more sophisticated than the logic above you will need to implement a custom MoveGroupCapability (or run your own node instead of move_group, if you prefer that). The approach could be quite similar to 1), but you could adapt it properly for your use-case.