# Port Questions and (Initial) Feedback from Controller via Simple Message - ROS-I

Hello ROS-Community!

I would still like to use my computer (Matlab, Simulink, C++) like a "controller" and therefor write a little driver. It is not yet necessary to run it on the real B&R Controller or to have some robot included yet. This is a goal for me to reach, at least for some better understanding. And I think I am pretty close to the solution.

So what I do on the ROS-Side: I roslaunch industrial_robot_client robot_interface_streaming.launch and it connects to my "controller". No further Error or Warnings, etc. My Controller runs at the moment Hercules as a server that listens to Port 11000. Afterwards I run my modified test_move.py. The changes are only because of the joint names, but more information can be found in one of my questions I got solved here earlier. If I rosrun anypkg test_move it works and finishes but I get an error message on the tab where I roslaunched before from the action node:

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


We had this once earlier, if you follow to the mode of test_move, but now I am on to write my small "conroller"-specific driver. How do I need to build up an initial feedback for my laptop of a fake feedback and on which ports do I need to send them?

Edit: If I wait long enough after the roslaunch I get this error message, which I may should look to work out first:

[ERROR] [1416915304.267290322]: Failed to connect to server, rc: -1. Error: 'Connection timed out' (errno: 110)


I also get it if I do roslaunch and afterwards rosrun: I get the first error message first and some time later the next. Hercules thereby states that the Connection is established? Maybe some problems with the ports?

As I found out over WireShark there are two ports in use when launching the robot_interface_streaming.launch.

• 11000
• 11002

Why and how to use those, like what should be used to receive or send on which node?

edit retag close merge delete

Sort by » oldest newest most voted

First: there aren't necessarily really any ports that you need to use. simple_message was meant to be usable on top of different transports / protocols, so it doesn't really make sense to specify a TCP port that should always be used.

However, if you want to re-use the nodes that the industrial_robot_client package provides, then you are expected to be using certain TCP ports in your controller-specific driver (in the general case).

You can find which ports are used for what in the simple_message api docs, which are accessible through the ROS wiki page for simple_message.

A quote from the linked API doc page:

Enumeration of standard socket ports (supported by all platforms). These are defined for convenience. Other ports may be used. Additional ports for application specific needs may also be defined.

enum StandardSocketPort { MOTION = 11000, SYSTEM = 11001, STATE = 11002, IO = 11003 }

As for the rest of your question: all you need to do is write a (server) program that starts transmitting JOINT_FEEDBACK or JOINT_POSITION packets as soon as something connects to it. That program is typically called the state relay or joint state reporter, and the default port is 11002. On 11000, the generic clients expect a server program that accepts JOINT_TRAJ_PT packets (or one of its variants).

The robot_interface_streaming.launch that you mention starts a robot_state node, and a motion_streaming_interface node. The former tries to connect to port 11002, the latter to 11000. As your Hercules (server?) only listens on 11000, the state relay will not be able to connect, and will time-out, after some time. Hence the Failed to connect to server .. error message you are seeing.

The other error (Joint trajectory action rejected: ..) simply states that the joint_trajectory_action node (again from the industrial_robot_client package) has not yet received any state information from the robot controller. Without knowing the state of the robot (manipulator), it cannot control it in any meaningful way, so it refuses to propagate any commands. It should be obvious that ultimately this is caused by the fact that you don't have any state relay, so there is no state reporting anywhere in your system.

more