industrial robot simulator, client: implementing simple message simulator from documenation

[frederic...@nist.gov]

I wrote a robot simulator that provides the simple message interface, following the web documentation only (from scratch, no borrowed code). I used this documentation:

http://wiki.ros.org/simple_message

and this tutorial:

http://wiki.ros.org/Industrial/Tutorials/create_joint_position_streaming_interface_using_tcp_socket_libraries

I've verified that I can connect to the joint message command TCP port 11000, and the joint state sender TCP port 11002, using a simple client counterpart that I wrote. Telnet connects too, and just shows the expected binary output.

I want to run the industrial robot client as a check, but it fails. e.g.,

me> roslaunch industrial_robot_client robot_interface_streaming.launch robot_ip:=localhost
...
[ERROR] [1414597010.104699711]: Failed to connect to server, rc: -1. Error: 'Network is unreachable' (errno: 101)
[ERROR] [1414597010.145136831]: Failed to connect to server, rc: -1. Error: 'Network is unreachable' (errno: 101)
[ERROR] [1414597010.145231091]: Failed to receive message length
[ERROR] [1414597010.145280560]: Failed to receive incoming message
...

I launched the industrial robot simulator Python program to see if the client could see that, and got the same errors (I commented out the running of the client node in the simulator launch file).

I want to check with the group: Should I be able to do this:

roslaunch industrial_robot_simulator robot_interface_simulator.launch
roslaunch industrial_robot_client robot_interface_streaming.launch robot_ip:=localhost

and connect with no errors?

[G.A. vd. Hoorn - 3ME]

Yes and no. Your roslaunch lines look fine, but I'm pretty sure you need
to provide it with an IP, not a hostname.


Gijs

[frederic...@nist.gov]

Better -- using the IP address instead of the hostname, I now get "connection refused" errors, both from the client and telnet.

Does the Python simulator use the well-known simple message ports 11000 and 11002 by default?

[G.A. vd. Hoorn - 3ME]

On 29/10/14 16:59, frederic...@nist.gov wrote:
> Better -- using the IP address instead of the hostname, I now get
> "connection refused" errors, both from the client and telnet.
>
> Does the Python simulator use the well-known simple message ports 11000 and
> 11002 by default?

No. It only provides a ROS API level simulation. simple_message is not used.

[Proctor, Frederick M]

I took a look at the Python code and indeed, I should have known that it implements a simulation of the ROS topics, not simple message.

But thanks -- success, now that I know that the "industrial_robot_simulator" is not a simple message simulator, and the "industrial_robot_client" takes IP addresses. I'm moving now, with some other errors that I can track down. I'll add a "gethostbyname" call in simple message's tcp_client.cpp so that either style works.

--Fred

>> me> robot_interface_streaming.launch

>> robot_ip:=localhost
>> ...
>> [ERROR] [1414597010.104699711]: Failed to connect to server, rc: -1.
>> Error: 'Network is unreachable' (errno: 101) [ERROR]
>> [1414597010.145136831]: Failed to connect to server, rc: -1.
>> Error: 'Network is unreachable' (errno: 101) [ERROR]
>> [1414597010.145231091]: Failed to receive message length [ERROR]
>> [1414597010.145280560]: Failed to receive incoming message ...
>>
>> I launched the industrial robot simulator Python program to see if
>> the client could see that, and got the same errors (I commented out
>> the running of the client node in the simulator launch file).
>>
>> I want to check with the group: Should I be able to do this:
>>
>> roslaunch industrial_robot_simulator robot_interface_simulator.launch
>> roslaunch industrial_robot_client robot_interface_streaming.launch
>> robot_ip:=localhost
>>
>> and connect with no errors?
>>
>>
>

--
You received this message because you are subscribed to a topic in the Google Groups "swri-ros-pkg-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/swri-ros-pkg-dev/P8sbqIGKG84/unsubscribe.
To unsubscribe from this group and all its topics, send an email to swri-ros-pkg-d...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[G.A. vd. Hoorn - 3ME]

On 29/10/14 17:12, Proctor, Frederick M wrote:
> I took a look at the Python code and indeed, I should have known that it implements a simulation of the ROS topics, not simple message.

Yes, I was unsure of whether I should've linked you to the relevant
Python sources, but figured you'd be able to find those yourself.

> But thanks -- success, now that I know that the "industrial_robot_simulator" is not a simple message simulator, and the "industrial_robot_client" takes IP addresses. I'm moving now, with some other errors that I can track down. I'll add a "gethostbyname" call in simple message's tcp_client.cpp so that either style works.

np.

Supporting hostnames via gethostbyname() would indeed be nice.


> --Fred


Gijs

[frederic...@nist.gov]

I added a call to 'gethostbyname' in tcp_client.cpp, and the required header in tcp_socket.h. Works fine, I can use either dot-notation IP addresses or hostnames. The patch is below.

diff --git a/simple_message/include/simple_message/socket/tcp_socket.h b/simple_message/include/simple_message/socket/tcp_socket.h
index 43245b2..08374bf 100644
--- a/simple_message/include/simple_message/socket/tcp_socket.h
+++ b/simple_message/include/simple_message/socket/tcp_socket.h
@@ -42,6 +42,7 @@
 
 #ifdef LINUXSOCKETS
 #include "sys/socket.h"
+#include "netdb.h"        /* gethostbyname */
 #include "arpa/inet.h"
 #include "string.h"
 #include "unistd.h"
diff --git a/simple_message/src/socket/tcp_client.cpp b/simple_message/src/socket/tcp_client.cpp
index 60ff396..7eaf8bd 100644
--- a/simple_message/src/socket/tcp_client.cpp
+++ b/simple_message/src/socket/tcp_client.cpp
@@ -57,6 +57,8 @@ bool TcpClient::init(char *buff, int port_num)
   int rc;
   bool rtn;
   int disableNodeDelay = 1;
+  struct hostent *ent;
+  struct in_addr *in_a;
 
   rc = SOCKET(AF_INET, SOCK_STREAM, 0);
   if (this->SOCKET_FAIL != rc)
@@ -70,10 +72,16 @@ bool TcpClient::init(char *buff, int port_num)
       LOG_WARN("Failed to set no socket delay, sending data can be delayed by up to 250ms");
     }
 
+
     // Initialize address data structure
     memset(&this->sockaddr_, 0, sizeof(this->sockaddr_));
     this->sockaddr_.sin_family = AF_INET;
-    this->sockaddr_.sin_addr.s_addr = INET_ADDR(buff);
+    if (NULL != (ent = gethostbyname(buff))) {
+      in_a = (struct in_addr *) ent->h_addr_list[0];
+      this->sockaddr_.sin_addr.s_addr = in_a->s_addr;
+    } else {
+      this->sockaddr_.sin_addr.s_addr = INET_ADDR(buff);
+    }
     this->sockaddr_.sin_port = HTONS(port_num);
 
     rtn = true;

[G.A. vd. Hoorn - 3ME]

On 29-10-2014 18:08, frederic...@nist.gov wrote:
> I added a call to 'gethostbyname' in tcp_client.cpp, and the required
> header in tcp_socket.h. Works fine, I can use either dot-notation IP
> addresses or hostnames. The patch is below.

[..]

If you could open a pull request against industrial_core on github, that
would be grand.


Otherwise I'm sure someone can apply it for you.


Gijs

[Proctor, Frederick M]

I don't have the privileges to create a branch on GitHub / industrial core. Normally what I do in other repos is create a branch, e.g., "frederickproctor", push that up to the GitHub repository origin, then issue pull requests on that branch.

I don't see any people-named branches on industrial-core, just hydro/indigo-devel branches. How do you all do branch management?

--Fred

-----Original Message-----
From: swri-ros...@googlegroups.com [mailto:swri-ros...@googlegroups.com] On Behalf Of G.A. vd. Hoorn - 3ME
Sent: Wednesday, October 29, 2014 1:14 PM
To: swri-ros...@googlegroups.com
Subject: Re: [ROS-Industrial] Re: industrial robot simulator, client: implementing simple message simulator from documenation

[frederic...@nist.gov]

It works OK now, no connect errors. There is one conflict in the documentation for the joint state interface.

It says it should be 10 here: http://wiki.ros.org/Industrial/Tutorials/create_joint_position_streaming_interface_using_tcp_socket_libraries :

2.1.2 Joint Feedback (Joint States)
...
Server streams: LENGTH(bytes), 10, 1(COMM_TYPE – TOPIC), 0 (REPLY_TYPE – N/A), UNUSED, JOINT_DATA[10] (in rads (floats))

But it says 11 here: http://wiki.ros.org/simple_message

Joint Trajectory Point Message

The point data serves as a waypoint along a trajectory and is meant to mirror the trajectory_msgs/JointTrajectoryPoint message. This point differs from the ROS trajectory point in the following ways:

• The joint velocity in an industrial robot standard way (as a single value).
• The duration is somewhat different than the ROS timestamp. The timestamp specifies when the move should start, where as the duration is how long the move should take. A big assumption is that a sequence of points is continuously executed. This is generally true of a ROS trajectory but not required.

Member	Type	Value	Size
Message Type:	StandardMsgType::JOINT_TRAJ_PT	11	4 bytes

Are these different things? Or is 11 wrong? I used 11, and got an error from the industrial_robot_client, so 10 looks like the winner from a code point of view.

[G.A. vd. Hoorn - 3ME]

On 29-10-2014 18:23, Proctor, Frederick M wrote:
> I don't have the privileges to create a branch on GitHub / industrial core. Normally what I do in other repos is create a branch, e.g., "frederickproctor", push that up to the GitHub repository origin, then issue pull requests on that branch.
>
> I don't see any people-named branches on industrial-core, just hydro/indigo-devel branches. How do you all do branch management?

I try to avoid people-named branches, as they don't really have any
meaning in the context of change management / tracking. A branch named
'joe' does not convey any information as to what is going on in that
branch, while something like 'issue123_fixing_frob_mistake' does.

Typical workflow for me:

- fork the origin repo, clone to workstation
- create local feature branch
- work, fix, etc
- commit to local feature branch
- push branch to remote (personal clone)
- use GH iface to create PR (personal clone -> origin repo)

As soon as the maintainers of origin merge the PR, I remove my feature
branch.

Even if I have commit privileges, I tend to follow the above workflow:
it makes for easier PR reviews, and makes it clear who did what.


> --Fred


Gijs

[Proctor, Frederick M]

I understand, I haven't done the "fork" feature on GitHub. This makes sense to me. I'll go ahead and do that.

[G.A. vd. Hoorn - 3ME]

On 29-10-2014 18:38, frederic...@nist.gov wrote:
> It works OK now, no connect errors. There is one conflict in the
> documentation for the joint state interface.
>
> It says it should be 10 here:
> http://wiki.ros.org/Industrial/Tutorials/create_joint_position_streaming_interface_using_tcp_socket_libraries
>
> 2.1.2 Joint Feedback (Joint States)

[..]

> But it says 11 here: http://wiki.ros.org/simple_message
>
> Joint Trajectory Point Message

[..]

> Are these different things? Or is 11 wrong? I used 11, and got an error
> from the industrial_robot_client, so 10 looks like the winner from a
> code point of view.

Yes, these are different things. Msg id 10 is a JOINT_POSITION, id 11 is
a JOINT_TRAJ_PT.

Joint state relays used to all sent JOINT_POSITIONTs back to the ROS
side to transmit joint states. More recently some relays have started
using JOINT_FEEDBACK (15), as this allows for including velocities,
accelerations and efforts.

Joint Trajectory Points are actually -- as the name implies -- points in
a trajectory, so desired, not actual state. Joint trajectory relays send
those from the PC to the driver on the controller. As with joint state
relays, newer implementations of trajectory relays have started using an
extended version of JointTrajPt (which already is an improvement over
JOINT_POSITION, which was the very first msg used for trajectory
points), JointTrajPtFull (14).

As for a reference for those msg ids, see [1].


Gijs


[1]
https://github.com/gavanderhoorn/rep-ros-i/blob/rep-xxxx_assigned_msg_ids/rep-ixxxx.rst#standard-messages

[G.A. vd. Hoorn - 3ME]

On 29-10-2014 19:58, G.A. vd. Hoorn - 3ME wrote:
[..]

> Joint state relays used to all sent JOINT_POSITIONTs back to the ROS
> side to transmit joint states. More recently some relays have started
> using JOINT_FEEDBACK (15), as this allows for including velocities,
> accelerations and efforts.

Actually not efforts. Just position, velocity & acceleration. See also [1].


Gijs

[1]
https://github.com/ros-industrial/industrial_core/blob/hydro-devel/simple_message/include/simple_message/joint_feedback.h#L70-L76

[Proctor, Frederick M]

I forked 'industrial_core', created a 'gethostbyname' branch, added support for passing host names in addition to IP addresses, commited and pushed the branch up to my fork on GitHub, and submitted a pull request. If you Elders agree, please merge this in.

--Fred

[G.A. vd. Hoorn - 3ME]

On 30/10/14 14:42, Proctor, Frederick M wrote:
> I forked 'industrial_core', created a 'gethostbyname' branch, added support for passing host names in addition to IP addresses, commited and pushed the branch up to my fork on GitHub, and submitted a pull request. If you Elders agree, please merge this in.

It's not just up to me, but thanks for the contribution :).


Gijs