robot_client: joint_traj_streamer does not use special sequence nrs

[gavanderhoorn]

In contrast to JointTrajectoryDownloader (here), the JointTrajectoryStreamer class does not actually use the special sequence numbers START_TRAJECTORY_STREAMING and END_TRAJECTORY (here) when it starts sending trajectory points to the server.

The documentation for SpecialSeqValue does seem to imply that streaming clients are supposed to make use of the special sequence numbers whenever streaming a trajectory, and the behaviour of the downloading client makes it even more confusing as to why the streaming client doesn't do it.

We should either document this as a design choice, or fix this discrepancy as a bug.

[gavanderhoorn]

Triggered by Industrial robot client : Are start and end sequence numbers not genenrated by default ? on ROS Answers.

[gavanderhoorn]

@shaun-edwards: can you perhaps comment on why the streaming and downloading clients do this differently?

[gavanderhoorn]

Note: for now I've classified this as a bug, but we can relabel it in case it is actually a feature.

[gavanderhoorn]

@shaun-edwards: 🛎 ?

[shaun-edwards]

I'm not sure why these were specified for or why they weren't used. I guess specifying the start of a trajectory could be used to "reset" the sequence number, if the server side were tracking it?

@gavanderhoorn, does the fanuc driver use these sequence numbers?

[gavanderhoorn]

@shaun-edwards wrote:

@gavanderhoorn, does the fanuc driver use these sequence numbers?

fanuc_driver only accepts / recognises STOP_TRAJECTORY, but none of the others (on the controller side). The ROS side makes use of the regular clients, so whatever those do is the behaviour of the Fanuc driver at the moment.

I added some (speculative) explanation for why JointTrajectoryStreamer does not use those in Industrial robot client : Are start and end sequence numbers not genenrated by default ?:

The streaming driver unfortunately doesn't do this. Servers are expected to start executing a trajectory as soon as the first point (or a few, depending on server-side buffering requirements) has been received.

I wasn't involved when this part of the infrastructure was written, but I can speculate as to why this is: a streaming trajectory is potentially infinite. And as the driver should be streaming, it would be a violation of semantics to wait for a END_TRAJECTORY (note the comment on the enum value).

It would perhaps make sense for a streaming client to set the START_TRAJECTORY_STREAMING, to indicate to the server that a new motion is starting (and should fi replace the current one). But in practice most servers either assume that whatever they receive is part of a single trajectory and / or check the sequence numbers of consecutive traj pts and either error out if they are not contiguous, or assume a new trajectory has started.

[gavanderhoorn]

I think the action item here is to decide whether we feel what the current generic clients do is what should be considered 'according to spec'. If so, then the documentation (at the very least the comments on the special sequence numbers) should be updated to reflect that.