[joint_trajectory_controller] Implement partial joint list handling

[bmagyar]

The joint_trajectory_controller currently only accepts a joint trajectory goal if all joints have a defined goal. This is an unnecessary constraint which was already lifted in ROS Kinetic.

[v-lopez]

@ddengster I was going to start working on this, but @bmagyar mentioned that you may have something for this? Is it something you'd accept contributions to? If not I'll get on another issue

[ddengster]

@ddengster I was going to start working on this, but @bmagyar mentioned that you may have something for this? Is it something you'd accept contributions to? If not I'll get on another issue

thanks for the initiative! I don't have any plans for this, but you may want to wait for the joint sorting PR #53 to get in first.

[v-lopez]

I will wait, thanks @ddengster.
I'm taking the time to think about how it can be done. Could any of you give me your opinion on the outline of the changes to be made below?

A partial joint trajectory implies that the "missing" joints hold their state until the end of the trajectory. (at the moment we're not bridging an existing trajectory into the new one).

I see two options:

1. We don't modify the `Trajectory``class and modify the partial message and fill the missing joints with the current state.

2. We modify the Trajectory class so it can accept partial joints. I started with this idea in mind and is detailed at the end, but probably complicates it too much.

I don't want any changes to be restrictive in the future when we provide a current trajectory with the goal.

When we implement current_trajectory bridging, what would be the approach? Combine both trajectories outside the Trajectory class and provide the resulting msg to Trajectory?

I would like to know the scope of the Trajectory class.

Right now it bridges between current state and starting trajectory, so it's not too far fetched that it would do the bridging between two trajectories, or fill a partial trajectory.

Annex Trajectory class modifications for option 2

Trajectory class keeps the current state of the joints in state_before_traj_msg_, but we will need to map from partial to global joints. We may need to pass the full joint_names in the constructor, and compute and store the remapping inside the Trajectory class. (we may move @ddengster code inside the

The sample() method provides a JointTrajectoryPoint with all the joints.

• For the mentioned joints, the behavior should be the same as it is now.

• For the "missing" joints, it should return the current state position. What about velocities and accelerations? Only if the partial trajectory has them?

[ddengster]

As I understand it, the Trajectory class handles sampling and translates messages into something the controller can sample from. Edit: Translating messages might be something it should handle?

I'd favor a method where you do all resorting/remapping/partial handling/merging of the received message before sampling Trajectory instead of maintaining a mapping in Trajectory and invoking it everytime you want to sample the trajectory, hence increasing complexity. So i'm all for number 1. I'm also not aware of any use of the original message so we can forget about it after its use.

Regarding velocities and accelerations, PR #62 attempts to port over the code of quintic_spline segment.cpp which also covers velocities and accelerations. How they use it in partial joint handling is still something I havent found out yet.