rostopic list works but rostopic echo does not

edit

Adding the ros server to the /etc/hosts file on the client worked for me.

Check your settings in both terminal. We had same problem and problem was in :

We had in 1st terminal ROS_MASTER_URI=http://192.168.1.10:11311 - in this terminal runs roscore and in 2nd terminal ROS_MASTER_URI=http://localhost:11311 - in this terminal runs urg_node

In matlab we receive using rostopic list all nodes but if we use rostopic echo /scan, we are not able to receive data.

there is our solution: best way how eliminate similiar mistakes is add few lines to .bashrc file

export ROS_MASTER_URI=http://192.168.1.10:11311
export ROS_HOSTNAME=192.168.1.10
export ROS_IP=              (empty data)

and it works!

and if you want use matlab

192.168.1.11 - our PC with matlab 192.168.1.10 RPI with ROS and sensors

setenv('ROS_MASTER_URI','http://192.168.1.10:11311')
setenv('ROS_IP','192.168.1.11')
setenv('ROS_HOSTNAME','192.168.1.11')

I undergo the same problem. You also should set $ROS_IP on mobile robot. It works.

In my case it was a matter of my client not being able to resolve the IP address of my server. I was able to verify this by subscribing to a topic and then checking the info about that topic:

$rostopic info /gazebo/model_states

Type: gazebo_msgs/ModelStates

Publishers: 
 * /gazebo (http://my-workstation:42193/)

Subscribers: 
 * /rostopic_117_1574085827847 (http://132.11.11.111:40064/)

I had passed 132.11.11.111 to my client as ROS_MASTER_URI but my server publishes as 'my-workstation' and not 132.11.11.111. It's clear then that the Ros Master was unable to connect the topic listener and publisher to listen and publish to the same port because it cant resolve what 'my-workstation' is referring to.

So my solution was to add

132.11.11.111 my-workstation

to the end of etc/hosts on my client and now it works

even after the correct settings of ROS_MASTER_URI and ROS_IP to the base workstation you would some times not receive the data and rostopic list works but not rostopic echo

in order to work on this issue you'll have to add an exception in your firewall settings for the robot's IP connection or disable the firewall using the command : sudo ufw disable

it should definitely work !

I just had this issue when I moved my computers onto a new network, where they got assigned new nonstatic IPs by DHCP. The fix which worked for me was:

set ROS_HOSTNAME on robot PC to its own ip,

set ROS_HOSTNAME on base PC to its own ip

set ROS_IP on robot PC to base IP

set ROS_MASTER_URI to base IP:11311 both machines.

$ROS_IP and $ROS_HOSTNAME basically tell the nodes running on a computer on which address they are reachable from the outside. You need to set only one of those. Whatever works better in your network. (To be absolutely sure and if you can use static IPs, i prefer using IP addresses)

So make sure, that you can ping in both directions and set $ROS_IP on the server and the workstation each to their externally reachable addresses.

jbohren already mentioned what constellation can lead to the observed behaviour. rostopic list is completely independent from the setting of $ROS_IP. It only needs an correctly set $ROS_MASTER_URI. :)

By default:

Step 1: On the robot:

1) run Roscore

2) export ROS_IP: IP address of Robot

Step 2: On your server monitor PC:

1) export ROS_IP: IP address of your PC

2) export ROS_MASTER_URI: http:// IP_address of Robot :11311

If it doesnt work, disable firewalls both the robot and the server PC.

I had this problem the other day, but in my case it was due to a network configuration issue. The entry in /etc/hosts in the client machine mapped the master machine IP to the hostname robot-base, but its hostname was internally set to robot-lab. And this was the hostname shown in rostopic info calls, for example:

$ rostopic info /odom
Type: nav_msgs/Odometry

Publishers: 
* /ekf_localization (http://robot-lab:40969/)

So when I tried to subscribe to a remote topic, ROS would lookup the name robot-lab, which wasn't present in the hosts list.

Bottom line, don't try to be smart about it, always name your machines in /etc/host exactly what they call themselves.