[ros-users] Current best practice for multiple interfaces

[Bil Morris]

I am not sure why the XML RPC server does not support binding to
INADDR_ANY instead of a specific ip address.

If the server could be modified to connect to all interfaces and rebind
the sockets when the xmlrpc server receives
a SIGHUP, then I think you could take something like our upstart scripts
[1] and modify them to start ROS on boot and
and send SIGHUP to ROS whenever the WiFi interface bounces.

[1] https://github.com/TurtleBot-Mfg/ros-system-daemon-groovy

On 01/15/2013 01:25 PM, Mike Purvis wrote:
> 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
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users