We are having major difficulties in configuring the new OpenMesh radios for use on our field for a pre-ship scrimmage this Saturday. In previous years, we were able to have teams configure DLINK, cRio/RoboRio, and any other networked robot cameras using static IPs (using the conventional 10.TE.AM.X subnet). We would configure the DLINK to disable DHCP and switch it to bridge mode using the switch on the back, and configure the radio to talk to our field access point (i.e., coniguring the SSID, the security settings, etc.). We use a simple, older version of FMS-Lite on a field laptop to run the field with good success.
The new OpenMesh / OpenWRT radio configuration through the FRC Radio Configuration utility does not appear to work for FMS-Lite field configuration directly (there is an option under “Tools” for FMS-Lite configuration). The utility appears to run correctly in that it prompts for a field SSID and WPA key. However, after configuration, there seems to be some bug which causes the radio to get into a mode where either it is unresponsive when the Web interface is invoked from a PC on the same subnet, or the web interface comes up, but gives an “incorrect password” error when “root” is entered for the password (which otherwise works fine). The only recovery from this is to reflash the radio, and reconfigure in either AP or bridge mode and not FMS-Lite mode.
Attempts to start with the bridge (competition) mode configuration using the FRC Radio config utility followed by manual tweeking through the web interface looked promising (although daunting) at first, but after attempting several variations we cannot get a configuration that works. We frequently got the bridge stuck in a state that required a firmware reflash to recover.
We have a relatively simple field AP (Netgear WNDAP360) which can do simple static VLANs and separate SSIDs. We can get bridges to associate on individual SSIDS, but we also could not get that to route (cannot ping the AP).
This shouldn’t be as hard as it is. Does anyone have a simple configuration that works? Any secret sauce for making the new radios work with FMS-Lite? What are you doing for pre-ship scrimmage FMS?
You shouldn’t need to manually change anything on the OM5P-AN after running the configuration utility.
Here’s what worked for us, using the 2015 offseason FMS (posted here).
Router - configured as per the FMS documentation
- IP address: 10.0.100.1
- Subnet mask: 255.255.255.0
- DHCP server: Configured to serve addresses starting from 10.0.100.50
- 5GHz WiFi enabled, with WPA
The one trick we found with the router is that the bridge configuration utility doesn’t support the hyphen character in SSIDs. Last year our FMS router was set up as “field-5,” so we just replaced the hyphen with an underscore.
We don’t mess around with VLANs or separate SSIDs. We use the bridge configuration utility in FMS Lite mode to configure the radios as bridges that all connect to the same SSID.
At this point, the OM5P-AN should be able to connect to the router just fine. If the wireless LED on the radio is orange, then it has connected to the router.
Also be sure that you are using the latest bridge configuration utility, found here.
Finally, if you were using VLANs before, double check your FMS networking config:
- IP Address: 10.0.100.5
- Subnet mask: 255.0.0.0
- Default gateway: 10.0.100.1
- DNS server: 10.0.100.1
Thanks, Tanis. This is very helpful.
My understanding was the FRC config tool using bridge / competition mode sets the static IP of the bridge based on the Team Number field to 10.TE.AM.1, with an SSID of “TEAM”. Are you recommending to use the config tool with a common entry for “Team” to configure the common SSID of the field AP? If this is nonnumeric, how does the tool set the radio’s IP address? Doesn’t this end up with the same static IP addresses for all of the radios? Or is there an extra step?
Do you require that teams assign static IPs to their RoboRios and any other networked devices on the robot? (i.e., IP cameras). If not, and you are not using vlans, you will not get DHCP addresses on robots on the 10.TE.AM.x subnets, right? Does this rely on mDNS to work?
We did manage to work around the LuCI web configuration / firmware stability issues by doing only a minimal mod to the 5GHz wifi web configuration to assign a common SSID and WPA key. Anything more involved seemed to make the radio lock up completely (unresponsive through the Web interface and cannot ssh into it any more).
Sorry - a little tired. Disregard the comments re team numbering and IP address conflicts from the config tool – I reread what you said and you did say to use “FMS-Lite” mode.
Our problem with that is that our radios to not configure sucessfully at all using the latest version of the config tool in FMS-Lite mode. They become unresponsive and require a reflash to recover. We do not have hyphens “-” in our SSID. Wonder if it is some other naming limitation?
We attempted to program ours using the following:
Team
SSID: FRC_FIELD
WPA Key: WeLuvRobots2016
Our original WPA Key was “WeLuvRobots!” and it complained about the bang. This new key is compliant but at the max length (15 characters). I will try some alternative SSIDs and WPA keys to see if this causing the problem.
So, changing the WPA passkey generated similar behavior. But I realize now that the bridge becoming unresponsive was actually just that we couldn’t log into it through the Web interface or through ssh to see how it was configured. What we’ve figured out is that the FMS-Lite configuration in the FRC config tool actually changes the root password of the bridge. Instead of username: root , password: root, the tool changes the root password to your WPA key.
Makes sense for security at an offseason event, I suppose, but I hadn’t seen that documented anywhere and it threw us for a loop.
It seems that the bridge is configured OK now through the FMS-Lite option in the FRC bridge configuration tool.