RoboRIO / FMS / mDNS / lessons learned

[jwhite]

Hi folks,

We're having a good time in Duluth. We learned a few things about the Roborio and the new mDNS stuff the hard way. In hindsight, they're fairly obvious, but I thought I'd share our experience in the hope it saves someone else some of our puzzlement. (Nicely, the good FIRST people helped us figure it out in the practice rounds, so no Q round harmed).

We learned two things the hard way:

1. Once you get to the regional, and have the D-link configured, you are in bridge mode, and there is no DHCP server.

2. If you use static IPs, you *must* use a netmask of 255.0.0.0 or you won't work on the field.

Some subtleties of #1:
a. The mDNS stuff will keep working. But the Robo Rio and your windows laptop will use a 169.XXX address, and other devices (like our Axis camera and our Pi) will use the last leased address, in our case 10.28.23.X. So you won't be able to communicate in the Pit. Ironically, there is a dhcp server on the field, so you *will* be able to communicate on the field.
b. If you had the D-link assign a particular IP to a device, you lose that once the router is reconfigured. For example, we had the d-link give the axis a set address. The camera was still in DHCP mode, but it always got assigned .11. That meant we could keep using the basic smart dashboard widget, which only accepts a numeric IP address. Of course, that falls apart when you no longer have a DHCP server...

So the solution to #1 was to switch over to using static IPs. *It turns out that this is really easy*. Hit roborio-XXXX.local with a web browser, click on the network configuration, one easy choice, and you are done. (This presumes you're still good at doing static ips for your other devices).

The *catch* is that the default netmask the RoboRio will suggest is 255.255.0.0. That will work great in the pits, but the FMS requires a netmask of 255.0.0.0. (If you think about it, that's obvious :-/).

At any rate, I hope this helps someone else, and good luck to you all.

And a shout out to the Lake Superior staff for doing a great job of running a smooth week 1.

Cheers,

Jeremy

[jhersh]

Originally Posted by jwhite

Hi folks,

We're having a good time in Duluth. We learned a few things about the Roborio and the new mDNS stuff the hard way. In hindsight, they're fairly obvious, but I thought I'd share our experience in the hope it saves someone else some of our puzzlement. (Nicely, the good FIRST people helped us figure it out in the practice rounds, so no Q round harmed).

We learned two things the hard way:

1. Once you get to the regional, and have the D-link configured, you are in bridge mode, and there is no DHCP server.

2. If you use static IPs, you *must* use a netmask of 255.0.0.0 or you won't work on the field.

Some subtleties of #1:
a. The mDNS stuff will keep working. But the Robo Rio and your windows laptop will use a 169.XXX address, and other devices (like our Axis camera and our Pi) will use the last leased address, in our case 10.28.23.X. So you won't be able to communicate in the Pit. Ironically, there is a dhcp server on the field, so you *will* be able to communicate on the field.
b. If you had the D-link assign a particular IP to a device, you lose that once the router is reconfigured. For example, we had the d-link give the axis a set address. The camera was still in DHCP mode, but it always got assigned .11. That meant we could keep using the basic smart dashboard widget, which only accepts a numeric IP address. Of course, that falls apart when you no longer have a DHCP server...

So the solution to #1 was to switch over to using static IPs. *It turns out that this is really easy*. Hit roborio-XXXX.local with a web browser, click on the network configuration, one easy choice, and you are done. (This presumes you're still good at doing static ips for your other devices).

While what you describe can work, the simpler configuration that teams are expected to use when at an event in the pits is to set all devices to DHCP + Link Local (the default for most devices) and use mDNS to find them even when they get a 169.254 address. If there is a tool that was released that doesn't support mDNS, then you should report that as a bug on the collab.net site.

Originally Posted by jwhite

The *catch* is that the default netmask the RoboRio will suggest is 255.255.0.0. That will work great in the pits, but the FMS requires a netmask of 255.0.0.0. (If you think about it, that's obvious :-/).

I'm not sure why that would be obvious. It's not like you are allowed / able / expected to send packets among teams. 255.255.255.0 is what I would select for the "obvious" netmask.

[jwhite]

Originally Posted by jhersh

While what you describe can work, the simpler configuration that teams are expected to use when at an event in the pits is to set all devices to DHCP + Link Local (the default for most devices) and use mDNS to find them even when they get a 169.254 address. If there is a tool that was released that doesn't support mDNS, then you should report that as a bug on the collab.net site.

It's the Smart Dashboard IP camera widget. We were told it was a known problem that it only
accepts numeric ips. I didn't find a bug report for it, so I've entered it here:
https://usfirst.collab.net/sf/go/artf4028
(and boy that is not especially easy or obvious; you have to 'Plan' to add an artifact...)

Originally Posted by jhersh

I'm not sure why that would be obvious. It's not like you are allowed / able / expected to send packets among teams. 255.255.255.0 is what I would select for the "obvious" netmask.

Yeah, okay, calling it obvious is perhaps a stretch. But if you presume the FMS is running on a 10.0.0.X ip, and you have no default gateway, then a netmask 255.0.0.0 makes sense. (And yes, I agree, habit dictates 255.255.255.0).

Cheers,

Jeremy

[jhersh]

Originally Posted by jwhite

It's the Smart Dashboard IP camera widget. We were told it was a known problem that it only
accepts numeric ips. I didn't find a bug report for it, so I've entered it here:
https://usfirst.collab.net/sf/go/artf4028
(and boy that is not especially easy or obvious; you have to 'Plan' to add an artifact...)

Not sure what you mean here. Care to elaborate?

Originally Posted by jwhite

Yeah, okay, calling it obvious is perhaps a stretch. But if you presume the FMS is running on a 10.0.0.X ip, and you have no default gateway, then a netmask 255.0.0.0 makes sense. (And yes, I agree, habit dictates 255.255.255.0).

If I recall, the FMS runs at 10.100.0.x addresses. The robot never needs to send or receive packets to or from the FMS. The DS takes care of all of that communication. I don't recall what the router configuration on the field is (if it hands out a default gateway that is needed or if it broadens the subnet mask). Based on your original post I would guess it's the latter, but I can't say for sure. The DS should always be configured for DHCP so it will always do what the field requests vis-a-vis network configuration. In your proposed configuration you have to react manually to any field configuration change.

It is a work-around to an actual problem that teams obviously are dealing with. Thanks for sharing!

[jwhite]

Originally Posted by jwhite

I didn't find a bug report for it, so I've entered it here:
https://usfirst.collab.net/sf/go/artf4028
(and boy that is not especially easy or obvious; you have to 'Plan' to add an artifact...)

Originally Posted by jhersh

Not sure what you mean here. Care to elaborate?

Sure.

Disclaimer, this is all meant in a constructive way, and I know that you have little control over collab.net. Just trying to cheerfully and positively illustrate my experience.


Nit #1 - this page:
http://wpilib.screenstepslive.com/s/...-documentation
At the bottom, there is a list of what to do with an unresolved problem. That list, or elements of it, could be drawn out on the 'Troubleshooting' main page; or be somewhat more visible. I only found it because I knew you wouldn't have asked me to file a bug if I there wasn't a link, so I just kept digging until I found it. And then, really minor nit, I think the list of three action items should be bullets; my eye scans better that way. (I found the link with a ctrl-F on collab, *not* by seeing it). Super dooper teeny nit: the url could be an href...

Nit #2: this page:
https://usfirst.collab.net/sf/projects/wpilib/
Doesn't really have good guidance for someone new to all this. The welcome tells me how to clone the code, and points me back to the same documentation I just came from it I want more help. The 'getting around' and 'how to participate' sections are empty. Be nice to have more newb friendly advice. (The opening could be, if you are a developer, then...to report a bug, then ....)

Okay, now I've been a good boy, and remembered that I'm supposed to do something with Trackers. So I click on 'Trackers' (not bugs; nowhere on this page does it say what to do if I want to report a bug).

As as exercise, click on that with an icognito window to get the newb experience. Nowhere on that page is there an obvious way to enter a bug. You're in list mode. Now let's say you get lucky, and you click 'Plan' mode. Now you're invited to pick a planning folder. Or maybe 3. Who knows? You just want to enter a bug...

But let's say you try it, and you pick Java. Gee, that '+' button is greyed out, with no tooltip.

So then you make an account, repeat the exercise, and then finally you enter, not a bug, mind you, but an 'Artifact'. And then you have apparently done it.

And then you go back and write a disclaimer because you're not really grumpy :-).

Cheers,

Jeremy

[virtuald]

Originally Posted by jwhite

Sure.

Disclaimer, this is all meant in a constructive way, and I know that you have little control over collab.net. Just trying to cheerfully and positively illustrate my experience.


Nit #1 - this page:
http://wpilib.screenstepslive.com/s/...-documentation
At the bottom, there is a list of what to do with an unresolved problem. That list, or elements of it, could be drawn out on the 'Troubleshooting' main page; or be somewhat more visible. I only found it because I knew you wouldn't have asked me to file a bug if I there wasn't a link, so I just kept digging until I found it. And then, really minor nit, I think the list of three action items should be bullets; my eye scans better that way. (I found the link with a ctrl-F on collab, *not* by seeing it). Super dooper teeny nit: the url could be an href...

Nit #2: this page:
https://usfirst.collab.net/sf/projects/wpilib/
Doesn't really have good guidance for someone new to all this. The welcome tells me how to clone the code, and points me back to the same documentation I just came from it I want more help. The 'getting around' and 'how to participate' sections are empty. Be nice to have more newb friendly advice. (The opening could be, if you are a developer, then...to report a bug, then ....)

Okay, now I've been a good boy, and remembered that I'm supposed to do something with Trackers. So I click on 'Trackers' (not bugs; nowhere on this page does it say what to do if I want to report a bug).

As as exercise, click on that with an icognito window to get the newb experience. Nowhere on that page is there an obvious way to enter a bug. You're in list mode. Now let's say you get lucky, and you click 'Plan' mode. Now you're invited to pick a planning folder. Or maybe 3. Who knows? You just want to enter a bug...

But let's say you try it, and you pick Java. Gee, that '+' button is greyed out, with no tooltip.

So then you make an account, repeat the exercise, and then finally you enter, not a bug, mind you, but an 'Artifact'. And then you have apparently done it.

And then you go back and write a disclaimer because you're not really grumpy :-).

Cheers,

Jeremy

Yeah, seriously, they should use github for hosting wpilib. We'd all be happier. Collab is just terrible in so many ways -- this is why new projects rarely choose sourceforge.

[fovea1959]

I can testify that running Avahi on a rPi works just fine in the pits, on the field, and in practice.

The axis camera would still be a problem. We finally abandoned ours and went to a Lifecam on the roboRIO....

[DKolberg]

How do we get the default dashboard to use the mDNS in place of the IP addresses. After a match we could sometimes tether and after a few minutes would loose the tether and seemed to have a very dificult time to re establish communications.

[x86_4819]

Originally Posted by fovea1959

I can testify that running Avahi on a rPi works just fine in the pits, on the field, and in practice.

Aside from Avahi, how did you configure your network interface? (Static IP, DHCP, Link local, etc)

[jwhite]

Originally Posted by x86_4819

Aside from Avahi, how did you configure your network interface? (Static IP, DHCP, Link local, etc)

We initially used DHCP with our Pi and had the D-link assign it to a known address. Later, we switched that to static. Avahi worked both ways.

Cheers,

Jeremy

[Mr. Lim]

Having competed at GTRC last weekend, I noticed sometimes my students had a lot of difficulty getting a tethered connection to the robot in the pits, possibly due to some of the items raised in this thread.

It's still speculation at this point, but I think it has to do with stale DHCP leases from when the robot and DS were connected to the FMS (10.xx.yy.zz) vs falling back to link-local (169.254.xxx.xxx) in the pits.

If you are connected to the FMS and play a match, the DHCP server will give all your devices a 10.xx.yy.zz address. After leaving the field, when you power cycle the robot, or disable/enable the network connection on the DS, or wait an unspecified amount of time, those devices get a new 169.254.xxx.xxx link-local IP.

If you have one device that still has the IP from the FMS's DHCP, and another with the link-local, the two won't communicate.

The solution we stumbled up is to make sure the robot is power cycled, and the DS's network connection is disabled and re-enabled after every match (to refresh the DHCP lease).

Has anyone else run into this?

[billbo911]

Originally Posted by Mr. Lim

Having competed at GTRC last weekend, I noticed sometimes my students had a lot of difficulty getting a tethered connection to the robot in the pits, possibly due to some of the items raised in this thread.

It's still speculation at this point, but I think it has to do with stale DHCP leases from when the robot and DS were connected to the FMS (10.xx.yy.zz) vs falling back to link-local (169.254.xxx.xxx) in the pits.

If you are connected to the FMS and play a match, the DHCP server will give all your devices a 10.xx.yy.zz address. After leaving the field, when you power cycle the robot, or disable/enable the network connection on the DS, or wait an unspecified amount of time, those devices get a new 169.254.xxx.xxx link-local IP.

If you have one device that still has the IP from the FMS's DHCP, and another with the link-local, the two won't communicate.

The solution we stumbled up is to make sure the robot is power cycled, and the DS's network connection is disabled and re-enabled after every match (to refresh the DHCP lease).

Has anyone else run into this?

This actually makes a lot of sense.
I worked as a FTAA at CVR last week. We had several teams that would show up to the field with static addresses set, teams that I personally had set to DHCP on their previous match.
The reason they gave was that they could not connect in the pits or practice field unless they switched to a static address.

Cycling the status of the NIC (Disabled/Enabled) would indeed address the issue.

The other issue we saw a lot was that the Wireless had been magically re-enabled. As you should be aware, this is a BIG No-No at competition and should never happen on the DS. Just disableing the Wireless would usually force the NIC to acquire a DHCP address and all was well.

[Travis Hoffman]

Originally Posted by Mr. Lim

Having competed at GTRC last weekend, I noticed sometimes my students had a lot of difficulty getting a tethered connection to the robot in the pits, possibly due to some of the items raised in this thread.

It's still speculation at this point, but I think it has to do with stale DHCP leases from when the robot and DS were connected to the FMS (10.xx.yy.zz) vs falling back to link-local (169.254.xxx.xxx) in the pits.

If you are connected to the FMS and play a match, the DHCP server will give all your devices a 10.xx.yy.zz address. After leaving the field, when you power cycle the robot, or disable/enable the network connection on the DS, or wait an unspecified amount of time, those devices get a new 169.254.xxx.xxx link-local IP.

If you have one device that still has the IP from the FMS's DHCP, and another with the link-local, the two won't communicate.

The solution we stumbled up is to make sure the robot is power cycled, and the DS's network connection is disabled and re-enabled after every match (to refresh the DHCP lease).

Has anyone else run into this?

*Raises hand*

Nothing new to add. Our experience was as you described.

[fovea1959]

Originally Posted by x86_4819

Aside from Avahi, how did you configure your network interface? (Static IP, DHCP, Link local, etc)

We set it up DHCP. One of the Avahi daemons assigns a link local if (and only if) it sees the DHCP client does not assign an address; I don't remember the details, but could probably dig them up (as can you).

[GeeTwo]

Originally Posted by jwhite

Yeah, okay, calling it obvious is perhaps a stretch. But if you presume the FMS is running on a 10.0.0.X ip, and you have no default gateway, then a netmask 255.0.0.0 makes sense. (And yes, I agree, habit dictates 255.255.255.0).

No, if the first three octets are fixed, 255.255.255.0 makes sense. I'm not saying it's correct.