teleop_twist_keyboard.py reports “Waiting for subscriber to connect to /cmd_vel” when its ROS master does not show a compatible subscriber. In the captured configuration, loopback addressing isolates ROS nodes on each computer, while the diagnostic output also suggests that the teleoperation process and the reported subscribers may be using different environments or masters.
Interpret the /cmd_vel Evidence
| Evidence | Engineering implication |
|---|---|
rostopic list includes /cmd_vel
|
The queried ROS master has registered the topic. |
rostopic info /cmd_vel shows no publishers |
The teleoperation publisher was not registered with the master queried by that command. |
Subscribers are /rosbot_ekf and /serial_bridge
|
Subscribers exist on the queried master. |
Both subscriber URIs use 127.0.0.1
|
Those advertised endpoints are reachable only from the same host. |
If the teleoperation command and rostopic info ran in the same active ROS environment, the publisher should appear in the topic information while it is running. Its absence is therefore a diagnostic sign to compare the environments used by the two terminals.
Remove Loopback-Only ROS Configuration
The supplied .env sets both ROS_IP and ROS_MASTER_URI to 127.0.0.1. That configuration supports communication only within one host; it cannot advertise robot nodes to another device. The displayed ROS_MASTER_URI= http://127.0.0.1:11311 also contains whitespace after the equals sign, so verify how the file loader parses it.
# On the robot
ROS_IP=ROBOT_IP
ROS_MASTER_URI=http://ROBOT_IP:11311
# On the laptop or other ROS 1 device
ROS_IP=LAPTOP_IP
ROS_MASTER_URI=http://ROBOT_IP:11311Replace the placeholders with addresses reachable through the selected LAN or VPN. Do not use 127.0.0.1 for a node that must communicate with another computer.
Apply and Verify One Consistent Environment
- Remove the loopback values from the active configuration and eliminate the whitespace after
ROS_MASTER_URI=. - Confirm that every terminal sources the intended ROS Noetic setup and the same
~/ros1_ws/devel/setup.shworkspace. The supplied.bashrcsources the Noetic setup twice; retain one consistent setup path. - Restart the affected ROS processes so they register again with the selected master and advertise reachable addresses.
- While the teleoperation command is running, execute
rostopic info /cmd_vel. Verify that it now lists a publisher and that subscriber URIs no longer advertise127.0.0.1for cross-device communication. - Run
rostopic listfrom the other device and confirm that it sees the same topic set as the robot-side master.
Separate VPN State from ROS State
Stopping the Husarnet daemon does not remove exported ROS variables or re-register nodes with different addresses. The observed fault can therefore remain after husarnet daemon stop. First correct the ROS master and advertised node addresses; then validate whether the chosen LAN or VPN path can reach those addresses.
The available manufacturer response states that ROS 1 on ROSbot is no longer supported. Treat this Noetic configuration as a legacy deployment and use the manufacturer’s current robot-network documentation when planning a supported architecture.
FAQ
Why does teleop_twist_keyboard wait for a /cmd_vel subscriber?
The teleoperation process does not see a subscriber through its active ROS master. Compare its environment with the terminal where rostopic info /cmd_vel reports /rosbot_ekf and /serial_bridge.
Can ROS Noetic communicate between devices with ROS_IP=127.0.0.1?
No. 127.0.0.1 is loopback-only; configure each host to advertise its reachable robot, laptop, LAN, or VPN address.
Why did stopping Husarnet not clear the /cmd_vel problem?
Stopping the daemon does not change the exported ROS_IP or ROS_MASTER_URI values and does not re-register existing nodes. Correct the environment, restart the ROS processes, and verify publisher and subscriber URIs with rostopic info /cmd_vel.