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

Industrial robot client : Are start and end sequence numbers not genenrated by default ?

asked 2016-10-12 05:00:04 -0500

mmoerdijk gravatar image

I'm currently working on implementing an custom Industrial Robot Server that talks with the default industrial robot client using the trajectory streamer interface. I got the communication between the robot and the robot client working but I'm now stuck on the detection of the start and end of an trajectory. This page http://wiki.ros.org/Industrial/Tutori... states the following:

SEQ_NUMBER – The sequence number is the number assigned by ROS to each of the points (i.e. this is always 0 or positive). A value of -1 indicates the end of a trajectory, a value of -2 indicates a stop (in both cases the controller stops, joint data is not valid for these special types)

And from: https://github.com/ros-industrial/ind...

I get that there are a few more "special" sequence numbers:

START_TRAJECTORY_DOWNLOAD  = -1, ///< Downloading drivers only: signal start of trajectory
START_TRAJECOTRY_STREAMING = -2, ///< deprecated, please use START_TRAJECTORY_STREAMING instead
START_TRAJECTORY_STREAMING = -2, ///< Streaming drivers only: signal start of trajectory
END_TRAJECTORY  = -3, ///< Downloading drivers only: signal end of trajectory
STOP_TRAJECTORY = -4  ///< Server should stop the current motion (if any) as soon as possible

However if I use Wireshark to look at the messages that are send to the robot I can see 18 messages been send but don't see the special sequence numbers -2 (START_TRAJECOTRY_STREAMING )or -3 (END_TRAJECTORY). However if I manually stop the trajectory the -4 (STOP_TRAJECTORY) is generated.

Could someone give me a few pointer as to where the special sequence numbers are generated, and why the are not generated in my case?

I'm using ros Jade on Ubuntu 14.04 LTS with kernel 4.2.0.42 with all the latest packages installed from: http://packages.ros.org/ros/ubuntu repository.

edit retag flag offensive close merge delete

Comments

Not an answer, but you might be interested in Message Structures of the ROS-Industrial Simple Message Protocol (unfinished), which attempts to document the SM protocol in greater detail.

gvdhoorn gravatar image gvdhoorn  ( 2016-10-12 10:44:49 -0500 )edit

Thanks, didn't know that document, could have saved me some time if I had know about it before :-). Was actually thinking about writing a similar document myself. Is there by any change more documentation about adding non standard messages? I'm now looking at the motoman rep to see how they did it.

mmoerdijk gravatar image mmoerdijk  ( 2016-10-12 14:21:45 -0500 )edit

No documentation yet, but we're working on a code generator similar to gencpp to generate Simple Message structs and msgs from ROS msg idls. That would make it a lot easier.

For now, just copying and adapting one of the existing msgs is probably easiest.

gvdhoorn gravatar image gvdhoorn  ( 2016-10-12 14:31:10 -0500 )edit

See motoman#93 for an example PR that shows how to add new msgs.

gvdhoorn gravatar image gvdhoorn  ( 2016-10-12 14:31:35 -0500 )edit

And:

Thanks, didn't know that document, could have saved me some time if I had know about it before

probably. That is one of the reasons we always ask / recommend ppl to talk to us first, as we can save you a lot of time and effort (and frustration).

gvdhoorn gravatar image gvdhoorn  ( 2016-10-12 14:32:45 -0500 )edit

Yes would have been better, but I started out 3 weeks ago with ROS and did really know where to start asking :-). What would have been the right place to ask for a few pointers on implementing a "industrial robot server" it seems to me that it is a too general question for answers.ros.org .

mmoerdijk gravatar image mmoerdijk  ( 2016-10-13 00:38:31 -0500 )edit

In this particular case a msg to the ROS-Industrial mailing list would have been a good start. We should probably make that more explicit.

gvdhoorn gravatar image gvdhoorn  ( 2016-10-13 02:04:56 -0500 )edit

1 Answer

Sort by » oldest newest most voted
1

answered 2016-10-13 02:32:06 -0500

gvdhoorn gravatar image

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.

edit flag offensive delete link more

Comments

I don't know how I could miss that comment. Thank you for creating the issue and answering my question.

mmoerdijk gravatar image mmoerdijk  ( 2016-10-13 02:49:33 -0500 )edit

No problem. As I've said: we should probably make this all more explicit.

gvdhoorn gravatar image gvdhoorn  ( 2016-10-13 05:20:02 -0500 )edit

Is this problem solved? Or it has been decided to leave it like that, just checking for the sequence number of the joint trajectory?

meimar12 gravatar image meimar12  ( 2017-05-13 07:45:49 -0500 )edit

No, this behaviour has not been changed. See also the ticket referenced in my answer.

gvdhoorn gravatar image gvdhoorn  ( 2017-05-14 08:12:00 -0500 )edit

Question Tools

2 followers

Stats

Asked: 2016-10-12 05:00:04 -0500

Seen: 302 times

Last updated: Oct 13 '16