Waiting for subscribers to connect to /cmd_vel

[nahakiole]

This error seems to occur when the ROS_IP isn't set. It would be an idea that the script would check at the start if it is set and if not would display an error message.

$ export ROS_MASTER_URI=http://10.0.0.1:11311/
$ rosrun teleop_twist_keyboard teleop_twist_keyboard.py
The rosdep view is empty: call ‘sudo rosdep init’ and ‘rosdep update’
Waiting for subscribers to connect to /cmd_vel
Waiting for subscribers to connect to /cmd_vel
Waiting for subscribers to connect to /cmd_vel
Waiting for subscribers to connect to /cmd_vel

After setting ROS_IP:

$ export ROS_IP=10.0.0.13
$ export ROS_MASTER_URI=http://10.0.0.1:11311/
$ rosrun teleop_twist_keyboard teleop_twist_keyboard.py
The rosdep view is empty: call ‘sudo rosdep init’ and ‘rosdep update’
Reading from the keyboard and Publishing to Twist!
.....

[trainman419]

This is probably a feature request that belongs upstream in rospy, not here.
This issue affects all nodes that use rospy, and the desired warning messages depend on whether you're using ROS over a network or locally.

If you're using ROS locally, no special setup of the ROS_MASTER_URI, ROS_HOSTNAME or ROS_IP is required, an no warning should be issued if ROS_IP and ROS_HOSTNAME are unset.

If you're using ROS over a network, ROS_MASTER_URI may be set to the default (localhost) but ROS_HOSTNAME or ROS_IP may still be required for ROS nodes on other hosts to connect to nodes on the local host.

If you're using ROS over a network and ROS_MASTER_URI is set, and the hostname of the machine is available in local DNS on your network, then no setting of ROS_HOSTNAME or ROS_IP is required. If the local hostname doesn't resolve in DNS, or if you have machine with multiple network interfaces and want to force ROS connections to come in through a specific interface, then setting ROS_HOSTNAME or ROS_IP may be required.

With all of that, I don't think there's a simple and foolproof set of rules for determining whether the ROS_IP and ROS_HOSTNAME settings are required or not.

Within teleop_twist_keyboard, I think the best we can do is to warn the users that subscribes are not connected, and then it's up to the user to determine if that is because:

• The subscriber is listening on the wrong topic.
• There is a network configuration issue that prevents the subscriber from connecting.
• The subscriber is not running.

Teaching the user how to troubleshoot these issues seems to be outside the scope of a simple teleop tool.