[ros-users] Current best practice for multiple interfaces

[Mike Purvis]

Greeting gurus of ROS—

We're facing an ongoing conundrum with network configuration on our mobile
platforms, and I'm hoping for some suggestions on what approach to take.

*Background*

The state of affairs on Turtlebot is simple: roscore comes up when wlan0
comes up. This works well for Turtlebot, but it makes several assumptions
which don't typically apply to our Husky and Kingfisher products (and
others):

- That the robot will always be connected to wifi.
- That the robot will always be connected to the same wifi AP.
- That the robot does not need to react to events like going out of
wireless range (for example, by backtracking to pick it up again).
- That the robot's PC has sufficient HMI for a user to configure wifi
settings as necessary.
- That the robot does not need ROS to always be running.

*The Problem*

One specific example of an issue we are encountering is that we have status
indicator lights for "ROS system up", "Wifi up", signal strength, etc., but
these are driven by a microcontroller interfaced over rosserial. So in
order for the status to be propagated over that bridge, ROS (or something
of it) must be running even when the wifi is down.

*So Far*

So—what about just launching ROS against localhost? Or setting a static IP
on eth0 (the "service port"), and launching against that?

This is what we have begun doing, but it means that additional layers are
required in order to use utilities like rxplot and rviz from a machine
connected over wifi. Options we have experimented with so far:

- the two-master approach, with various flavours of master-sync and foreign
relay scripts (unreliable, seemed to have bandwidth issues)
- configuring a static route on the connecting PC (finnicky to set up,
won't work for phones/tablets where such configuration is unavailable)
- setting up a VPN on the robot, which the remote user joins in order to
interact with the system (complicated, seems over the top)

Here's the setup script for our Kingfisher software, which establishes the
distinct upstart jobs for the "core" and "interface" masters:
https://github.com/clearpathrobotics/kingfisher/blob/master/kingfisher_bringup/upstart/install.bash

Is the Gateway Model a good fit for what we're trying to do? If so, should
it be to facilitate dual-masters on the robot, or to flip topics and
services directly to a mirrored master on the user PC? Does that mean the
rocon hub should go on the user PC? What if there are multiple users
wanting to visualize from the robot at the same time?

Thanks for any thoughts or guidance,

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/ros-users/attachments/20130115/ad59aac5/attachment-0003.html>