Re: Network configuration?
3 views
Skip to first unread message
Georg Heppner
Mar 11, 2015, 3:55:01 PM3/11/15
to ros-sig...@googlegroups.com
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
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
On 04.03.2015 22:51, Mike Purvis wrote:
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?
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: Prof. Dr. Andreas Oberweis, Prof. Dr. Ralf Reussner, Jan Wiesenberger, Prof. Dr.-Ing. J. Marius Zöllner Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus .........................................................
Reply all
Reply to author
Forward
0 new messages