Trajectory control

[akihikoy]

Although I have made almost the same issue report in ros_kortex, I write it here again since it is an important fundamental issue of both ros_kortex and pure kortex.

The issue is about the trajectory control.

There are following APIs:

• PlayCartesianTrajectory (example use: https://github.com/Kinovarobotics/kortex/blob/master/api_python/examples/102-BaseGen3_ctrl/01-move_angular_and_cartesian.py )
• PlayJointTrajectory

However both are not a trajectory control, but a point-to-point control.
In other words, they are not a way to generate a motion from multiple via-points.

In ROS, sometimes SimpleActionServer of actionlib is used to provide a trajectory control, which can be accessed through the /follow_joint_trajectory topic. It is commonly used, for example, in Universal Robots UR and Yaskawa Motoman.
In these robots, /follow_joint_trajectory provides a trajectory control that can traverse multiple via-points. Each via-point consists of time-from-start, joint angles, and joint angular velocities.

Note that executing PlayJointTrajectory and PlayCartesianTrajectory multiple times does not offer the same functionality, since the motion stops after each execution of PlayJointTrajectory and PlayCartesianTrajectory; i.e. the joint angular velocities at each via-point are zero.

Thus,

1. The APIs like PlayCartesianTrajectory and PlayJointTrajectory are confusing naming. They should be MoveToCartesianPose or something like that.
2. How can we generate a motion from multiple via-points? I could not find such an API in kortex. Is that not implemented yet?

[alexvannobel]

Hi @akihikoy ,

Thanks a lot for the feedback.
You are right : for now, the PlayJointTrajectory and PlayCartesianTrajectory calls act as "reach joint angles" and "reach cartesian pose" calls. They were named as such because
a) The arm computes, then plays the trajectory needed to get from point A to point B.
b) In the future, this computation may possibly include dodging obstacles or complex constraints. In this respect, the word trajectory is more appropriate.
We understand, however, that this naming is confusing for the end-user and we will consider challenging the naming of the "trajectory-related" RPC's and messages.

The support for multiple via-points trajectories will be available in the next release, as will be the support for MoveIt! follow_joint_trajectory interface in ros_kortex.

Cheers,
Alex

[alexvannobel]

Hi @akihikoy ,

We did not change the PlayCartesianTrajectory and PlayJointTrajectory naming in this release, but we will work on a deprecation mechanism to eventually change the naming of those functions.

The Base service now supports the PlayPreComputedJointTrajectory function. I invite you to look at the ROS FollowJointTrajectory server in ros_kortex to see how it is used. We don't currently have an example on how to use the function from normal C++ or Python code, but it will be added soon.

I will close this issue, but feel free to open a new one if there is anything with the functionality.

Best,
Alex

[alexvannobel]

It is documented (in the matlab_kortex repository) what the arm expects as a PreComputedJointTrajectory. You can see the hard limits and conditions here.