[C API] simple_message communication breakdown

[kphawkins]

I believe I can duplicate this bug, I'm posting the conversation from earlier below for reference.

https://groups.google.com/forum/#!topic/swri-ros-pkg-dev/i5iBOdwMP5E

---

Hello,

I'm trying to set up a simple_message connection between my workstation and UR10 according to documentation. I compiled the server's side on the controller box and I'm trying to connect from my workstation. Unfortunately, I get this on the client's side:

[ INFO] [1391695157.810595--------------------------------------------------------621]: UDP client connected
[ERROR] [1391695157.810629757]: Failed to receive message
[ERROR] [1391695157.810663254]: Failed to receive incoming message
[ WARN] [1391695157.810695275]: Send failure, no callback support
[ INFO] [1391695157.810729612]: Connection failed, attempting reconnect

I could see the packets coming and going (see the screenshot) and I'm puzzled why simple_message reports it sees none. What does it mean when the data field is just "FF"?
I'm using the latest hydro on my PC and the latest C-API (1.8) on the controller box.

Thanks,
Nikita

---

@gavanderhoorn
Nikita,

I'm not sure what is causing your problem, but there is a wireshark dissector for simple message that may help. See http://wiki.ros.org/simple_message#Wireshark_Protocol_Dissector

I know there are others on this list that are more familiar with the C-driver. Hopefully they will respond.

---

@shaun-edwards

The screenshot shows that the datagrams contain only a single byte of
data. The dissector is not going to be much help here.

Additionally, it seems the ur driver uses port 11003, which is not in
the standard set of ports for which the dissector registers itself.
You'll have to right click on a packet on that port and select 'Decode
As', then scroll down and select 'SIMPLEMESSAGE' from the list.

I'll create an issue to add the port.
Shaun

---

@shaun-edwards
Nikita,

It sounds like a network configuration issue. Could describe your setup. What is the PC IP address, the controller address. What versions of the software are you using (source-branch or debian).

The UDP server/client initiate a handshake as part of the connection (see https://github.com/ros-industrial/industrial_core/blob/hydro-devel/simple_message/src/socket/udp_client.cpp#L109 ). This might be the communications that you are seeing.

There are some debug messages in the udp client/server that may help solve the problem. On the ROS side, you would just need to enable debug logging. On the controller side you would have to recompile and enable the logging here ( https://github.com/ros-industrial/industrial_core/blob/hydro-devel/simple_message/include/simple_message/log_wrapper.h ).

Shaun

---

@kphawkins
Have you set the desktop's IP on the tablet interface to be the default gateway? I've only ever used a direct line as the configuration. If you're running things through a router/network, you might run into issues.

This does look like a networking problem, those packets are not consistent size-wise with any of the UR simple messages, so I'd bet they're the handshake pings.

For the record, my network setup has the tablet as having:
IP: 192.168.5.100
Netmask: 255.255.255.0
Gateway: 192.168.5.101

And the desktop:
Manual Config
IP: 192.168.5.101
Netmask: 255.255.255.0
No gateway

Then, when running, I use the robot_ip 192.168.5.100 .

You might try disabling any other network adapters before trying again, there might be a routing problem.

---

Well, it's all in the same network (10.7.7.0/24), hence no routing is taking place, only switching. So, does ur_c_api_bringup work for you with a crossover cable?

@shaun, thanks. I'll try turning on debug messaging. There is nothing extraordinary in my setup. Controller has an IP .13 and the PC is running Ubuntu 13.04 and has an IP .145 (from the screenshot).

Sorry for a late reply,
Nikita

---

[kphawkins]

Revision of @ros-industrial/industrial-core to ros-industrial/industrial_core@8c5e107 seems to fix the problem. Investigating further...

[kphawkins]

I'm going to say that the best solution at the moment is to use the version of the repository mentioned above.

@shaun-edwards
This commit has broken my UDP communication: ros-industrial/industrial_core@daf3fbc
Totally reverting the receiveBytes method changes fixes the communication errors. Has this been tested for UDP?

[ERROR] [1392426506.941959806]: Failed to receive message
[ERROR] [1392426506.942124116]: Failed to receive incoming message
[ WARN] [1392426506.942245363]: Send failure, no callback support

[shaun-edwards]

I don't see anything obvious. The change was made because receiveBytes would return true having not read all of the requested bytes. This seemed to happen on wifi connections. Do you have an idea of what is happening or better yet, can you send me a test case (at the unit level).

The UDP connection was never fully added to the unit tests. It should be easy enough to add with a little refactoring of the gtest code to use a proper test fixture for the base socket connection classes (I think)

If you can get me a unit test, I will get this fixed ASAP. Thanks for tracking this down. I really appreciate it and I'm sorry my change broke your code.

[kphawkins]

For the moment, I'm going to suggest that everyone using the C API use the old commit for @ros-industrial/industrial-core: ros-industrial/industrial_core@8c5e107

I'll try to get something to you eventually. I'm questioning whether I should bother using UDP when it's giving me more problems than I'd like. The thing is, I believe it's the correct way of doing streaming communication. If my message didn't make it by the time my control loop comes around, I don't care, there's no reason sending it again.

[gavanderhoorn]

Closing this because of inactivity. C-API is also only compatible with CB2 controllers, and those are becoming rarer and rarer.

If anyone runs into this issue again, please reopen.