You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the ExecuteTaskSolutionCapability converts the solution message into a series of ExecutableTrajectory objects, it does not have a way to set the names of the controllers that should be used to execute each trajectory segment. This results in the TrajectoryExecutionManager having to figure out on its own what controller to use for each set of joints, which (as described in the linked issue) doesn't always work correctly if there are multiple controllers to choose from.
One solution is to add new fields to the MTC Solution or SubTrajectory messages to define what controllers should be used for each segment. I think this is an important supporting piece to this suggestion by @v4hn about adding additional properties to MTC Stages to set the controller to use during execution. This would be an API change, though, so I wanted to get feedback from others about the best path forward.
The text was updated successfully, but these errors were encountered:
This is similar to this MoveIt2 issue I posted: moveit/moveit2#1182
When the ExecuteTaskSolutionCapability converts the solution message into a series of
ExecutableTrajectory
objects, it does not have a way to set the names of the controllers that should be used to execute each trajectory segment. This results in the TrajectoryExecutionManager having to figure out on its own what controller to use for each set of joints, which (as described in the linked issue) doesn't always work correctly if there are multiple controllers to choose from.One solution is to add new fields to the MTC Solution or SubTrajectory messages to define what controllers should be used for each segment. I think this is an important supporting piece to this suggestion by @v4hn about adding additional properties to MTC Stages to set the controller to use during execution. This would be an API change, though, so I wanted to get feedback from others about the best path forward.
The text was updated successfully, but these errors were encountered: