Python code to handle simple message protocol.

ROS-Industrial
1

I’m writing a controller software in python for my robot and I would like it to interface with industrial_robot_client and simple message. I understand I can use scapy to craft network packets but I’m a little lost on how I should do this? Has anyone done something like this or knows ways I can encode and decode the simple message protocol in python, with scapy for example?

I’m trying to define a custom protocol in scapy but am a little lost.

class simpleMessage_feedback(Packet):
name = "joint feedback"
fields_desc = [ByteEnumField("message_ID", 10),
               ByteEnumField("comm_type",1),
               ByteEnumField("reply",0 ),
               ]
2

I’m not sure any more what the state of it is, nor whether it will work for what you are trying to do, but I wrote gavanderhoorn/simple_message_py a few years back.

Might be something you could use.

3

Thanks, that looks like something that could really help. I use that and try to hack together some sort of server implementation.

4

There is no assumption in the bare protocol classes about it being a server or a client. Only the top-level (Twisted-based in this case) program that provides the data (coming from a socket, but that is not a requirement) would make that distinction.

The example is a client, but only because the endpoint created is one.

5

I see. I’ve started trying to get everything working but it seems the construct library has had some significant changes so there’s some work in there. Mind if I open some issues on GitHub or ask some questions?

6

Would be great to have a server variant of this for both integration testing the simple_message_client in industrial_core and to have at least one readable (ie not obfuscated by robot manufacturer languages) reference server implementation if someone ends up implementing yet another driver

7

Indeed it would. I tried to look at the UR driver since it’s the only one in python but I’m not good enough to get much out of it. :slight_smile:

Anyways I forked the original repo and am slowly working to get it updated and working again. https://github.com/Roiki-design/simple_message_py

8

A little update, I have a working server that sends simple messages for functionality testing and the server now connects to the industrial client.

Now I’m running into 2 different errors:

[ERROR] [1563359872.487050741]: Joint trajectory action rejected: waiting for (initial) feedback from controller

[ERROR] [1563359872.886763861]: Message callback for message type: 15, not executed

I’m guessing the first is ROS waiting for initial status information from the controller? but what kind?
For the second I have no idea.

9

You need to periodically send position (joints) and status messages from the server to the client before it allows sending trajectories

10

For some reason I didn’t receive any email notifications about this thread. Sorry about that.

The old version of construct is actually still available. It’s just called construct v2. I use it all the time.

I don’t believe you needed to really update anything.

Looking at your fork I’m also not entirely sure why you delete everything and then re-add it. The commit history is rather confusing.

You’re free to ask, always. I can’t guarantee I can help though.

ur_driver is not simple_message based. So that wouldn’t help you.

As @simonschmeisser already commented: the client is waiting for joint state messages, as it cannot otherwise determine what the state of your robot/controller is.

The easiest is to periodically send JOINT_POSITION to the client. If you need/would like multi-group support, you’d have to use JOINT_FEEDBACK (but note that multi-group support never made it into the v1 industrial_robot_client).

For some more background information on Simple Message, see ros-industrial/rep#20.

11

By the time I found that out I already had done most of the work anyway, might as well do it. And I’m pretty much learning as I go so my workflow is pretty messy. Sorry about that. :stuck_out_tongue_closed_eyes:

I get that and i’ m now doing that on port 11002. Or should I use JOINT_POSITION instead? And I’ve tried sending ROBOT_STATUS messages to the client on port 11000 but that does nothing. Looking at wireshark the client doesn’t send any requests until I shut it down. Then it sends a single JOINT_TRAJECTORY_POINT type message.

Also I’m using the packages available from melodic repos if that means anything.

12

For everything to work as a regular server implementation:

  • periodically send JOINT_POSITION and ROBOT_STATUS messages to the state client
  • accept JOINT_TRAJ_PTs from the motion client
13

I see. I got it mostly working now, messages are sent and decoded correctly. But how do I make a callback for the joint_trajectory_point message? I attached a callback with the registerCallback function and gave a function as callback that sends a reply message using sendMsg but the _dispatchMsg function gets cauhght in the exception? Is this how you’re supposed to do it?

EDIT:

Disregard that, I figured it out and now everything works. It sends callbacks and outputs joint values to an array. ROS complains about execution timeout but that can be disabled.
Now I need to just figure out the motor control bits.