Network configuration?

[Mike Purvis]

Another area that I'm always interested to discuss with other robot manufacturers is how they set up the network and wifi on their robots. Does the robot try to join a network, or create an AP? Some kind of fall-back behaviour?

If your robot has an ethernet port on it, is that for plugging into the wall to "get it online", or is it a service port with a static IP for rescue purposes? Do you have both, or maybe an onboard network switch?

When users configure their robot's wireless, are they editing a conf file somewhere? Running the wicd-curses TUI? Interacting with a connmanctl prompt?

[Ką Mykolas]

Personally was looking forward to Wi-Fi direct technology [1] [2]

Sadly, neither kernel shipped with ROS-Groovy, neither most of the hardware I own supports it yet. 

[1] http://www.wi-fi.org/discover-wi-fi/wi-fi-direct
[2] http://en.wikipedia.org/wiki/Wi-Fi_Direct

[Mike Purvis]

Georg,

This is helpful, thanks for writing it up— we have come to a similar place at Clearpath. Jackal's PC includes two network interfaces, and by default they are configured as a WAN/DHCP port and static IP port, respectively, for much the reasons you outline. And agreed that demo/show robots tend to get configured as an AP, whether by strapping on a discrete router or using hostapd with a built-in device.

As you've identified, the gold standard would definitely be a config that allows the robot to ship to the user as an AP, with a web-accessible panel which allows the user to switch it over to their network, similar to a router. It may be that Wifi-Direct or some kind of bluetooth phone-pairing scheme could have a role to play here, but it should be possible all with standard 802.11b/g/n.

I believe the most likely path to this solution is via Intel's IoT-focused connman network manager. To that end, I've been maintaining a PPA for it, with up-to-date packages for Ubuntu Trusty. We've been using this for in-house experiments, and anyone else is obviously welcome to try it out as well, but I'd be really excited if someone could work on taking the next step and building out some of the other pieces— probably some kind of a user-space process which would communicate with connman using its d-bus API. It could even be a shim which would bridge the d-bus API into ROS and then allow it to be controlled from an rqt widget, though that starts to put more demands on the user doing the configuring vs simply "connect to AP and access this webpage."

Mike

On 11 March 2015 at 15:52, Georg Heppner <g.he...@gmx.de> wrote:

Hey Mike,

so we (FZI) are not really an OEM but we work closely with industry partners to provide them with state of the art robotics.  Therefore our requirements of  the "shipped" components are probably somewhat different (we only ship prototypes) but maybe my answers interest you to as we often come across the same issues.

The answers to your question if of course : It depends :)
I think you can distinguish if the "robot" you ship is an application (just use it) or a research vessel (do awesome things with it an connect other things to it).

Applications:
In our case these are either demonstrators for some kind of expo or prototypes meant to be used in production lines. In both cases there is the need to give the user control of the robot. So these setups usually feature a router that provides a WLAN AP. This is often the best solution because it is self sutained, you do not need to interfere with any custom network (and most of the time are not allowed to). The AP will provide IPs via dhcp and provide dns resolution while the actual robot pc and other components are residing on fixed ips (but are also connected via the router or additional switches). The user can also connect via cable by plugging it into the router. As user interface we are relying more and more on Websites. These also work very well with ROS.

However, while we implement things or update the system we usually want to have an internet connection. For this we usually use hardware with dual Ethernet ports. The one is configured to the "internal" AP network while the other one is set to be a dhcp client. So when we have the robot in our lab we can connect that port and gain instant network access. You have to be carefull however if this is a permanent option as we often encountered routing or name resolution problems. This is also a problem especially for ROS as the name resolution usually fails horribly. This is due to our company network. Each device will get a dns name which follows a naming schema. If the robot pc has a different host name internally things start to break. Especially when you have set the MASTER_URI to an IP rather than the host name (but that is what you would expect :) ).
So we usually end up configuring things for the "internal" network and change the MASTER_URI manually when we need to access is via company network.

Research:
In our case these are more or less autonomous robots, like humanoids, walking robots, snake robots and things like that. They are set up simmilar to the applications in the way that they usually have an internal network and an external network. The internal one connects all the components like laserscanners etc. and usually uses fixed ips. Sometimes there is an DHCP but it will keep a mac address list to provide the same ips again. There is mostly no need for an actuall router, so a switch will usually do the work quite well at this front. The second interface is configured as the DHCP variant as mentioned above. Also they usually have a WLAN stick or simmilar to connect to external routers. This can either be the company network or just local networks when we are in the field. These WLAN interfaces are configured as dhcp (or sometimes static) clients. Having the Robots as Clients rather than APs greatly reduces the WLANs that are around and therefore the overall reliability. Also the robots often share a network so they can talk to another. Unfortunately our company network has a quite strict firewall which is another thing your ROS configuration can easily break on. We often had the case that everything looked good but didn`t work because we could send data to the Robot but not back. So at least services and actions do not work anymore.


In both cases I experimented with fallback behaviours but they never seemed to work well and lead to more trouble than they were worth. I think it would be awesome to provide a fallback IP like the Fritz Box does for example. Its a totally different IP the Box is always answering on so you can get to the configuration interface and change things back. However I dont know how to achieve such a behaviour. Therefore we usually have an emergency display+keyboard combination nearby to actually change things back by hand. I recently tried a cheap and lightweight monitor (without any casing) that can be build into the robot and even provides touch (via USB) and was very pleasantly surprised by its performance. So far I just use it as monitor but the plan is to put simple QT GUIs in the Autostart and provide a simplistic touch configuration interface with that.

In case the network needs to be changed this is either done directly at the routers web interface or by configuring it manually in the /etc/interfaces. All of the network managers have the problem that you can not (easily) use them via a ssh connection. Maybe that is a problem only I have because I am not familiar with their config files, but many of my colleagues also use the interfaces file for that reason. You can also put presets in there so you just have to write something like "ifconfig eth1 myFavouriteConfiguration" or similar. But most of the time we have all the options in the interface file and just comment in what we need.
If the system is intended for (end user) customers however, we try not no let them change any network configurations at all.

Another thing that is quite handy is to put every configuration into some form of script. So for example if you need to set a different MASTER_URI or maybe even a custom port for the master we do this little shell scripts. So you have something like ROS_SETUP_WLAN.sh or ROS_SETUP_COMPANY.sh. Also we often use a single start script for the robot behaviour. This will call the required environment setup script before launching the application. If you want to be really flexible, you can also let it call symbolic links and change these whenever the network configuration is changed.

I guess with the Robots that you are selling I would expect that they act as client to my already existing robot network so they should also be clients, providing both cable and wireless connection. However, I would need to configure this first. If you want to be really cool you could provide both options to toggle. Have them delivered as AP because everybody can simply connect its laptop to it and then configure the client configuration (most of the time you will need at least a wifi pw). The most consumer friendly way to do this would be a web interface like with popular routers have it but as you are providing Robots mostly used by researches (I guess) anything that can be configured within a terminal is appreciated.

Hope this wall of text helps  :)

Best Regards
Georg

--
You received this message because you are subscribed to the Google Groups "ROS Vendors Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-vendo...@googlegroups.com.
To post to this group, send email to ros-sig...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-vendors/fe8dee03-2dea-4a00-a234-2e133da20f51%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
.........................................................
M.Sc. Georg Heppner
Wissenschaftlicher Mitarbeiter Interaktive Diagnose- und Servicesysteme (IDS)

FZI Forschungszentrum Informatik
Haid-und-Neu-Str. 10–14
76131 Karlsruhe, Germany
Tel.: +49 721 9654-248
Fax: +49 721 9654-249
hep...@fzi.de
www.fzi.de

.........................................................
FZI Forschungszentrum Informatik am Karlsruher Institut für Technologie
Stiftung des bürgerlichen Rechts
Stiftung Az: 14-0563.1 Regierungspräsidium Karlsruhe
Vorstand: Dipl. Wi.-Ing. Michael Flor, Prof. Dr. Andreas Oberweis,
Prof. Dr. Ralf Reussner, Prof. Dr. J. Marius Zöllner
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
.........................................................