0
$\begingroup$

Rosanswers logo

I'm running the ROS core on a mobile robot and am using ssh to monitor it from a workstation. On the workstation I have ROS_MASTER_URI and ROS_IP configured per the wiki's instructions to point at the robot's IP address. "rostopic list" works correctly and shows me the correct list of topics. Unfortunately, "rostopic echo" is silent, and "rxgraph" also implies the workstation is not connected to the host.

The question: under what circumstances could rostopic list work and rostopic echo not work?

(I'm familiar with the relevant sections of the wiki (http://www.ros.org/wiki/ROS/NetworkSetup, for example), but they're not answering this question for me.)

Thank you.


Originally posted by Tom Sgouros on ROS Answers with karma: 81 on 2012-11-13

Post score: 5


Original comments

Comment by Tom Sgouros on 2012-11-13:
Just to elaborate, I can edit /etc/hosts on both machines to make this work, but the network setup page implies I should be able to do this by setting ROS_IP, which does not seem to work. I don't have su privilege on all the machines I want to use.

Comment by Mattster on 2021-07-15:
Suffering the same problem in 2021, but I do have su access so I edited /etc/hosts and its started working. None of the rest of the ROS_ID= stuff worked. Why does this make it work?

$\endgroup$

8 Answers 8

0
$\begingroup$

Rosanswers logo

$ROS_IP on your workstation should be your workstation's IP address, not the robot's.

rostopic list is just talking to the master, whereas rostopic echo needs to be able to communicate with the publishers.


Originally posted by jbohren with karma: 5809 on 2012-11-13

This answer was ACCEPTED on the original site

Post score: 8


Original comments

Comment by BaBui on 2022-06-15:
Thank you so much. It worked. I forgot to set ROS_IP on master, and slave robot

$\endgroup$
0
$\begingroup$

Rosanswers logo

$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. :)


Originally posted by Ben_S with karma: 2510 on 2012-11-13

This answer was NOT ACCEPTED on the original site

Post score: 1

$\endgroup$
0
$\begingroup$

Rosanswers logo

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


Originally posted by Younghyo with karma: 15 on 2014-04-15

This answer was NOT ACCEPTED on the original site

Post score: 1

$\endgroup$
0
$\begingroup$

Rosanswers logo

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.


Originally posted by charles.fox with karma: 120 on 2015-05-09

This answer was NOT ACCEPTED on the original site

Post score: 1


Original comments

Comment by lhnguyen on 2017-06-13:
Thanks for your answer! I got headache with other solutions but this does help me!

Comment by Harestew on 2020-05-02:
This worked for me, either! For my case ROS_MASETER_URI setting for base machine itself was not necessary. Also ufw disable(turn off firewall) and etc/hosts file did not affect my result.

$\endgroup$
0
$\begingroup$

Rosanswers logo

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


Originally posted by Thomas10111 with karma: 81 on 2015-07-14

This answer was NOT ACCEPTED on the original site

Post score: 7

$\endgroup$
0
$\begingroup$

Rosanswers logo

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')

Originally posted by Wiew with karma: 53 on 2017-03-31

This answer was NOT ACCEPTED on the original site

Post score: 5

$\endgroup$
0
$\begingroup$

Rosanswers logo

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 !


Originally posted by sai krishna with karma: 111 on 2019-07-16

This answer was NOT ACCEPTED on the original site

Post score: 1


Original comments

Comment by MarkAi9 on 2021-05-11:
"sudo ufw disable" solved my case

$\endgroup$
0
$\begingroup$

Rosanswers logo

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


Originally posted by benwex93 with karma: 51 on 2019-11-18

This answer was NOT ACCEPTED on the original site

Post score: 1

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.