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

[virtuald]

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.

This only applies if your team isn't using macs, which we've found cannot use the mDNS to find the roboRIO reliably.

Thanks for posting this! We'll definitely be setting up a static IP configuration at the comp, as we're using macs.

[Mr. Lim]

Very interesting subtleties. I can see those being very annoying.

During Alpha testing I was very postivie of moving to DHCP and taking away the need to set static IPs. This was especially useful for programming laptops that were switching constantly between robot networks (static) and internet connections (DHCP).

I still am a big fan of DHCP, but recognize there are instances like this where a lack of mDNS support by some peripherals (IP-based cameras, embedded computers for co-processing, etc) could be an issue.

The pros outweigh the cons for sure, however.

I'd have to agree with jhersh in saying that the best situation is to get all devices on dynamic IPs via DHCP + mDNS, then address them only by their hostnames.

Of course not everything supports mDNS.

The RPi can probably do it with some additional software:
http://www.howtogeek.com/167190/how-...-raspberry-pi/

The newer Axis Cameras (M1011 onwards) should also support Apple Bonjour, which actually should provide mDNS services.

I haven't tried either so I'm not speaking from experience, but they are both worth a shot trying to configure.

Alternatively, I think a cool potential solution would be to have the RoboRIO detect whether a DHCP server is present on the network, and if not, act as a DHCP+DNS server. It would then need to shut down and hand off the leases to the FMS's DHCP server when connected to the field, which would probably be the hard part. Multiple DHCP servers on the same network aren't ideal.

[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!

[jhersh]

Originally Posted by Mr. Lim

Alternatively, I think a cool potential solution would be to have the RoboRIO detect whether a DHCP server is present on the network, and if not, act as one.

We considered this from very early on, but rejected it. I don't recall the reason, but we may revisit it.

[jhersh]

Originally Posted by virtuald

This only applies if your team isn't using macs, which we've found cannot use the mDNS to find the roboRIO reliably.

Thanks for posting this! We'll definitely be setting up a static IP configuration at the comp, as we're using macs.

I remember a bug report about this during beta. The team at NI that is responsible for that part of the image wasn't able to respond with a resolution due to how late it was reported. It's on our radar for next year.

Also, are you aware of this? : https://discussions.apple.com/thread/6607871

[jhersh]

Just to be sure everyone who is looking at this thread knows about the documentation for the network configuration in FRC 2015, I want to provide the link: https://wpilib.screenstepslive.com/s...rio-networking

[virtuald]

Originally Posted by jhersh

I remember a bug report about this during beta. The team at NI that is responsible for that part of the image wasn't able to respond with a resolution due to how late it was reported. It's on our radar for next year.

Also, are you aware of this? : https://discussions.apple.com/thread/6607871

I hadn't seen that, but, I'm pretty sure that isn't the problem. The issue only appears when using the DLink router. I had sent Greg Mckaskle some of my debugging notes, but I'll list them here too:

• When the roborio is connected to my home network's wireless, it resolves just fine
• When running tcpdump on the robot/laptop when connected to the dlink, mDNS packets go out to the robot, and the robot shows that it sends responses. However, the responses don't show up at the laptop
• Interestingly enough, when I try to resolve the router's mdns name (dlinkap.local), the roborio sees the response packets, but the laptop does not
• When I'm connected via ethernet to the DLink, mDNS works instantly
• I've tried changing various settings on the router with no lasting success. Every once in awhile something I change fixes it, but then after a reboot or something it will stop working

A prior thread about this is here: http://www.chiefdelphi.com/forums/sh...d.php?t=132607

Thinking about it, maybe it'll just work for us since we'll always be tethered at the comp, and mDNS worked just fine for me when I was connected via ethernet.

[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.

Aha! I want to highlight this portion of your remark, because I didn't fully understand it while at the regional. The DS and the Robo Rio both apparently are set such that if there is no DHCP server, they fall back to 'link local' (also apparently aka stateless address autoconfiguration). I'm not particularly familiar with that mode.

But if you can persuade all your other devices to do the same, and all your software can use names, you should indeed be in great shape. (A lazy 5 minute Google and read of the M1011 manual suggests possibilities, but not clear paths to doing that. The M1011 appears to let you set *two* addresses; not sure which gets the 'axis-camera.local' name. The Pi can use avahi to set a link local address. It's not clear to me if there is an easy or clean way to have the dhcp server fall back. I suspect another 20 minutes of Googling might help...)

Originally Posted by Mr. Lim

I'd have to agree with jhersh in saying that the best situation is to get all devices on dynamic IPs via DHCP + mDNS, then address them only by their hostnames.

Yeah, I agree. I think this is a good change, and hopefully once the bumps are ironed out, the teams will reap the benefits into the future.

Originally Posted by Mr. Lim

The RPi can probably do it with some additional software:
http://www.howtogeek.com/167190/how-...-raspberry-pi/

The newer Axis Cameras (M1011 onwards) should also support Apple Bonjour, which actually should provide mDNS services.

Just to confirm - they both do, and it's nice. It's particularly nice because the mDNS continues to work in both static and DHCP modes.

Cheers,

Jeremy

[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.