ROS realted issue


We had bought our LEO rover and had it up and running for about two months and we’re very happy with it. However, several weeks ago WiFi module short-circuited (not sure why; module fault or something) and it threw our LEO rover into unoperational status.

At first, it seemed that the RPi4 board was OK and that Husarion Core2 board was also defective (if would raise no Husarion Core2 error if Leo-bringup was launched from RPi, and no firmware update could be done). However, after some extensive testing, it seemed alright (all the right voltages were at all the right places - as far as we can tell). Then we tried uploading a simple code using MS Visual Studio (from Windows running laptop) and it seemed to work: all the basic functionality was there again (motor control -but not rover motors, ADC, LED blinking, etc). After that, we were able to upload new firmware to it from the RPi4 (and USB cable) as described in the tutorials. Also, we downloaded and installed newest OS version on the SD card.

The reason I’m writing is that we are currently stuck trying to run roscore or leo_bringup (via roslaunch) and we get the error: “RLException: ERROR: unable to contact ROS master at [http://husarion>11311]”. We are connecting to the RPi4 + Husarion Core 2 directly via cable (HDMI for monitor and keyboard) since we have ordered new a WIFI module (the same one) and are waiting for it to arrive. We have also tried using different WiFi USB modules (TP-Link TL-WN722N) but it does not seem to have any effect.

Thus, I would have two questions:
1.) for the ROS related program operation is it essential to have a WiFi module connected and that it be the original model?

2.) are we doing something wrong from the ROS side? or direct connection is not a way to go? How to test if everything is OK while we wait for the WiFI module to arrive?

And yes, just to mention when we turn on the robot (without an external monitor and the keyboard) with connected motors the LED indicator just keeps flashing as the system is not fully operational. Also, we have the following ROS environmental variables defined:
ROS_IP= (as the one defined by ip address command)
ROS_MASTER_URI=http://husarion:11311 (however ping husarion does not return any results)

Any help or pointers would be welcomed and appreciated.
If any additional information is needed, I would be glad to provide it.


Hi Josip,

first of all, I would suggest you flash the LeoOS image to the SD card (Do a backup first if you have any files you would like to keep) as the documentation was updated and no longer references the old image releases and I have better overall knowledge of the new system.

As for your questions:
1.) It is not essential to have a WiFi module connected for the ROS programs to work. However, some of the configuration needs to be changed.

2.) You had a good idea with the variables, but you need to understand some things first:

  • husarion hostname (change to master.localnet in LeoOS) is defined in /etc/hosts file and is translated to address which is the address assigned to the interface createad by the external WiFi module. This makes the address not resolvable if you don’t have the module connected.
  • ROS_MASTER_URI needs to be resolvable and should point either to the address where the roscore is started or to the Rpi, in which case roslaunch will start a new instance of roscore if it is not already running. To point to the Rpi, you can use the loopback device by specyfing http://localhost:11311 (or
  • If you specify ROS_HOSTNAME, it needs to be resolvable by the Rpi, as well as any other computer that wants to communicate with the ROS network. The latter was provided by the DNS server running with the Access Point.
  • The same applies to ROS_IP, except you don’t need a DNS server, so it is a better option in your case.
  • If you have specified both ROS_IP and ROS_HOSTNAME, only the ROS_HOSTNAME variable will be used. To use the ROS_IP variable, make sure the ROS_HOSTNAME is not exported.

Assuming you have connected the Rpi to your network and the interface has the address, you can try the following configuration:

export ROS_IP=
export ROS_MASTER_URI="http://localhost:11311"

You can apply the configuration to the /etc/ros/setup.bash file to make the configuration global and restart the leo service:

sudo systemctl restart leo

Hi Blazej_Sowa,

Thank you for the fast and informative reply.
First to address you question about the LeoOS version used: yes we are using the newest (2 weeks old) LeoOS image, so we should be up to date in that department.

As for your answers:

1.) thank you for the info. Is there any tutorial available on using a different WiFi module with Leo? Or could you please give us some pointers (is it LeoOS specific or more general)? As I said, we did order the replacement one, but till it gets here or possibly for future changes it would be nice to know how to use different WiFi modules.

2.) I have followed your suggestions (temporarily changing ROS_IP and ROS_MASTER_URI in the /etc/ros/setup.bash - till the WiFi module arrives) and everything (camera, LEO UI, motors) seem to work well now. Did have some issues with one of the motors (which kept turning after the velocity command was set to 0) but resolved it by moving power lines from encoder wires :slight_smile: (as suggested in the assembly docs).

So it seems we have resoled the original issue - thank you very much.


I’m afraid there isn’t one at the moment. Such tutorial is on my ToDo list but with a low priority, so I wouldn’t expect it in the near future.

I can’t promise it will work but have a look at the /etc/netplan/00-wlan-persistent-names.yaml file. This file tells netplan to assign the interface names based on the kernel drivers used.
If you succeed to modify the configuration so that your WiFi module’s name becomes wlan_ext and restart the rover, it might work right away. If not, you might also need to modify the hostapd configuration (/etc/hostapd/hostapd.conf file).

For more info about netplan, you can visit this and this.

And here are some commands useful for debugging hostapd:

# Restart the hostapd service
sudo systemctl restart hostapd
# Check the status of the hostapd service
systemctl status hostapd
# Check the logs of hostapd service
journalctl -b -u hostapd

Thank you for the reply. I will have a go with changes to files you suggested (and more) once I’m back from vacation (2-3 weeks time). I will then post any feedback so you know for the future reference.