Suggestion: Allow either cartesian interpolation or joint space interpolation between waypoints

[awesome-manuel]

A major limitation in current (vendor specific) interfaces is that you can either define a trajectory with cartesian interpolation or joint space interpolation. If you want to switch between both, you have to stop and send another trajectory.

Since joint space interpolation often allows for much faster movements, it is beneficial to have both in the same trajectory to increase overall speed.

Often a motion needs precise control at the start and at the end, but a fast transition in between. This can only be achieved when we allow both motion types in the same trajectory.

[stefanscherzinger]

That's an interesting point indeed.

While I see some challenges for a mixed trajectory definition with ROS messages, I do see a practical workaround using both interpolation types: The paradigm of ROS-control targets fast, real-time controller switches. Users could chain both Cartesian and joint-based trajectories with minimal delay. A high-level node on the ROS side would have to handle controller switches upon some pre-defined events, though.

[awesome-manuel]

Actually I think both things are independent:

• Trajectories can have Waypoints in joint space or cartesian space no matter what interpolation is used
• Interpolation can be done in joint space or cartesian space no matter how the waypoints are specified

[gavanderhoorn]

@awesome-manuel wrote:

Actually I think both things are independent:

• Trajectories can have Waypoints in joint space or cartesian space no matter what interpolation is used
• Interpolation can be done in joint space or cartesian space no matter how the waypoints are specified

while this is true, there seems to be a mismatch with your earlier statement:

Since joint space interpolation often allows for much faster movements, it is beneficial to have both in the same trajectory to increase overall speed.

If the idea is to allow specifying trajectory points as joint poses and Cartesian poses, this would not lead to any performance improvements, unless execution of such trajectories also supports this mix.

---

If you look at industrial robots, you typically have to chose between either a "joint move" or a "linear move". Both typically support specifying destinations in either joint coordinates or Cartesian coordinates.

If they have support for something which could be called a trajectory (in the sense the concept is a first class citizen and is treated as an entity or unit of work on its own, instead of considering only individual points in a list), there typically isn't support for mixing different execution types in a single instruction. KUKA and Fanuc both support Spline moves fi, but you cannot easily switch to other interpolation styles, or at least not without an impact on motion execution.

[awesome-manuel]

I know that most (if not all) robots don't support mixing joint interpolation and cartesian interpolation, but in my opinion it's a major drawback. In the end a robot will execute a path in joint space anyway, so a workaround could be to interpolate using fine steps (e.g. 1mm?) and then execute in joint space.

But from what I understand the discussion here is more about how to specify the expected trajectory and not so much the interface to a real robot.

Conclusion: I think it could be beneficial for users if

• every waypoint has both a cartesian pose and a joint space configuration (both not necessarily complete)
• a parameter (0.0 ... 1.0) to shift the weight between pose and joints
• a parameter to specify if the way from this to the next waypoint should be interpolated in cartesian or in joint space

If a robot does not support such trajectories an intermediate layer has to make "the best out of it" in order to follow this trajectory.