Generalize across rosdistros

[mikepurvis]

This seems like it's only very lightly specialized for hydro. Would we consider a generic ros-system-daemon package which uses a debconf setting for the path to the workspace/setup.bash file?

Debconf would be an obvious choice as well for the question of which network interface to use (eth0/wlan0/other).

Finally, for headless robot computers, it would be great to weaken the coupling to NetworkManager. For example, supporting events from connman, wicd, etc.

[stonier]

A generic ros-system-daemon package which uses a debconf setting for the path to the workspace/setup.bash file

Debconf could work. I also think an update-alternative solution would be fine as well. The latter would let you write specific implementation packages for different robots, or even variants of that robot while at the same time giving users a mechanism to point to their own workspaces. Are there any disadvantages to update-alternatives?

Debconf would be an obvious choice as well for the question of which network interface to use (eth0/wlan0/other).

This seems to be one where user input definitely would be beneficial.

Finally, for headless robot computers, it would be great to weaken the coupling to NetworkManager.

:+1:

[mikepurvis]

I don't have a clear understanding of update-alternatives— it's a scheme for maintaining symlinks, is that correct? So you'd have a symlink somewhere (/etc/ros/setup.bash?) which is set by a package install script to point to /opt/ros/newest/setup.bash, but there's a structured way to point it to a setup in your homedir or elsewhere if you want that?

Certainly just editing a text file is easiest for users, but being able to override it with a subsequent implementation package would be attractive.

Regarding the network interface business, I think a better default might be to set ROS_HOSTNAME to $(hostname). This should/will always resolve locally, it will resolve correctly on any network with a proper DNS service, and can be corrected on a case-by-case basis by editing /etc/hosts or adding a HOSTALIASES env. This completely decouples the ros daemon from whether a particular network interface is connected or not, and probably allows the ROS service to start earlier in the overall system bringup.

[stonier]

update-alternatives

I believe you'd have something like that /etc/ros/setup.bash which would point to your official /opt/ros/hydro/setup.bash or /opt/ros/indigo/setup.bash. Installing an implementation (in this case a distro) would automatically switch to the new implementation. e.g. if you had hydro, and installed the core indigo packages it would switch. Probably you can do debconf style and ask them if they want to switch in the install process.

This also means you have the flexibility to install a deb workspace for a particular robot - and provide an alternative for that, e.g. /opt/yujin/turtlebot/setup.bash. The last piece of flexibility is to allow the user to provide an alternative too. I believe you could do something like:

# Adding a new alternative
sudo update-alternatives --install /etc/ros/setup.bash /home/snorri/turtlebot/devel/setup.bash ros 1

# Start the interactive setter and choose the new alternative as default for "ros"
sudo update-alternatives --config ros

I haven't actually done the above, so we should test first :neckbeard:. It does feel more in line with usual user workflows though...I run update-alternatives quite frequently. dpkg almost never.

Interfaces

Aye, we also already converged to always setting our ROS_HOSTNAME on the robots to the local hostname. i.e.

export ROS_MASTER_URI=http://localhost::11311
export ROS_HOSTNAME=${HOSTNAME}

and in /etc/hosts you already have your hostname configured to loopback (e.g. hostname here is bob):

127.0.1.1       bob

Our DNS servers elsewhere get setup to find 'bob'. This has the advantage of letting the robot run on any network and also be agnostic about problems with its own wireless interfaces (driver problem or someone pulls the usb wireless dongle) and it will keep on chugging.

The assumption here of course is the DNS Servers. Usually users don't have access or don't know how to do DNS serving, so it's a pretty high constraint. As you say though, researchers can quickly hack /etc/hosts and windows has it's own equivalent of this too. Not a perfect situation for all use cases, but it covers more bases with the least hassles I think.

[mikepurvis]

Re: interfaces, wouldn't that be:

export ROS_MASTER_URI=http://${HOSTNAME}:11311
export ROS_HOSTNAME=${HOSTNAME}

This way, you can get a remote connection to the bot on your workstation with just:

export ROS_IP=[IP of my wlan0]
export ROS_MASTER_URI=http://robot_hostname:11311

And if your DNS infrastructure can't resolve robot_hostname to the robot's wired or wireless interface, you fix it via /etc/hosts or HOSTALIASES.

[stonier]

@mikepurvis are you still using ros-system-daemon to auto-start your robots?

If not, I'd like to get on the same page with other companies with regards to this so we can contribute to something that doesn't ordinarily get much love.

[mikepurvis]

We never switched over— we're still using robot_upstart across the board, except on Turtlebot and PR2 which have their own legacy systems.

The version of this you and I were hacking on last year is here, but I never really pursued it (getting it on launchpad, imported to packages.ros.org, etc). This was for a variety of reasons, including confusion over what was going to happen with Ubuntu and systemd, and uncertainty that the amount of disruption at CPR would be worth whatever advantages were brought by the new scheme.

[stonier]

Ok. We never got around to implementing autostart properly (i.e. beyond using rc.local) till now. Having upstart disappearing in the near future throws a spanner in the works. I'll do some digging and see where that takes us, but since we have a clean slate with the gophers I should push somewhere viable long term.

[stonier]

Thanks for the update.

[mikepurvis]

The robot_upstart overhaul which occurred at the beginning of this year made the backend a pluggable affair. Right now there's only upstart supported, but a ticket exists (https://github.com/clearpathrobotics/robot_upstart/issues/20) to add systemd support, which will cover... well, a lot of things, but importantly Ubuntu 16.04 + ROS Kinetic.

It should be quick to do; just haven't gotten to it.

[stonier]

Oh, that's a nice move and certainly seems a good place to start. I'll check it out - thanks.