ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 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.