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

edit

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.