ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
I think you've run into something where the download and streaming drivers differ in their implementation. The JointTrajectoryDownloader::send_to_robot(..)
method in the IRC does set the first and last points to these special sequence numbers (here), making it explicit for the server when the client starts and completes uploading a new trajectory.
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.
This is certainly too implicit right now, and I've created an issue to track this: ros-industrial/industrial_core#152.