roslaunch is not executed on startup because network adapter doesn't delay start

[VinniF]

Hi,

I created a launch file that runs my ROS nodes automatically, including the Master.

Firstly I added the service with robot_upstart, including my master-ip and the wlan0 interface
Then I used daemon-reload and started the service. That was always working fine. However, on reboot it would never work.

service name-of-service status helped me finding the issue: The error displayed was
root: bebop: No IP address on wlan0, cannot roslaunch.

After more debugging, there were two things I needed to do before it worked correctly:
Firstly, I needed to alter the automatically created service file in /lib/systemd/system/name-of-service.service. I added following lines:
After=network.target
Wants=network.target
After=network-online.target
Wants=network-online.target

After adding these lines and reloading the daemon, the error persisted. As I found out, there was no service activated that delays my service. So I enabled both of these services with
sudo systemctl enable NetworkManager-wait-online.service
sudo systemctl enable systemd-networkd-wait-online.service

After reloading the deamon again, finally my service is delayed until I have a wifi connection and the lauch file is executed correctly.

Make sure every time you edit and reinstall the service, to edit the automatically created service file.

There's not much that can be done about the disabled network waiting service, but please automatically add the four lines to the service file.

[iamtesch]

Thanks -- this was required for us, too!

[kaorusha]

Hi, adding those four lines worked at first but not after adding another user service. So eventually I changed the service file as below:

[Unit]
Description="myservice"
After=network.target
Wants=network.target
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/sbin/myservice-start
Restart=on-failure # add this

[Install]
WantedBy=multi-user.target

It will restart until wlan0 get data.

[BRNKR]

Hi, adding those four lines worked at first but not after adding another user service. So eventually I changed the service file as below:

[Unit]
Description="myservice"
After=network.target
Wants=network.target
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/sbin/myservice-start
Restart=on-failure # add this

[Install]
WantedBy=multi-user.target

It will restart until wlan0 get data.

this has to be mentioned somewhere or included into robot upstart

[mikepurvis]

I don't know that there's strictly a right or wrong way for this to go. Historically (for Clearpath), we never wanted to block starting ROS on having wifi connectivity because a) we wanted users to be able to teleop their robots right out of the crate on initial delivery, without having to have the wifi set up first, and b) we wanted the robots to be able to react to wifi-loss as just another environmental event to potentially respond to (eg, by flashing a light, returning to a known waypoint, whatever).

But part of that is obviously our field robotics focus, and there is a complexity cost paid for it, particularly once you get into the realm of clock syncs occurring after network connectivity is achieved (and therefore after ROS has already started).

That said, I can certainly imagine other types of scenarios such as controlled lab environments would rather just bypass all this and assume that every device is online all the time, and that being online is a prerequisite for any other kind of operation.

[BRNKR]

I don't know that there's strictly a right or wrong way for this to go. Historically (for Clearpath), we never wanted to block starting ROS on having wifi connectivity because a) we wanted users to be able to teleop their robots right out of the crate on initial delivery, without having to have the wifi set up first, and b) we wanted the robots to be able to react to wifi-loss as just another environmental event to potentially respond to (eg, by flashing a light, returning to a known waypoint, whatever).

But part of that is obviously our field robotics focus, and there is a complexity cost paid for it, particularly once you get into the realm of clock syncs occurring after network connectivity is achieved (and therefore after ROS has already started).

That said, I can certainly imagine other types of scenarios such as controlled lab environments would rather just bypass all this and assume that every device is online all the time, and that being online is a prerequisite for any other kind of operation.

for me it looks like the launch file is executed before the ubuntu network stack is available at all. not specific for wifi. but could be a specific problem for me, because i source a bash file which checks the current IP, which is not available at launch.