Why does RobotPy take longer to deploy?

Hi,

I was curious why this year’s version of RobotPy takes about a minute and a half longer to deploy to our robot? This is a relatively minor issue, but I liked when I could deploy code to the robot in about 10-15 seconds. I even deployed during a practice match once last year and I still had plenty of time to play.

The part that seems to take the longest is connecting to the Rio and finding out the versions. Is it because of the new mDNS stuff?

Again, this is a minor issue, but I was wondering what changed to make the deploy process longer?

If your computer cannot resolve the mDNS name correctly, then you would have similar issues in Java or C++, as they all use the same underlying mechanism to resolve the mDNS name.

A similar issue was reported at https://github.com/robotpy/pyfrc/issues/42, and that user was able to resolve their issue by reflashing the firmware on their OM5P-AN.

A minute and a half? Thats just obnoxious… I had 30sec deploy times and I still didn’t like it…

I followed this tutorial to flash the router. I also realized, after doing that, that theres a “download firmware” button on the program thats used to assign team numbers to routers. Can’t speak for its efficiency since I haven’t used it, though.

Before going down this route, though, answer this question- is you’re code stalling right between “Robot code deploying” (or whatever) and “WPILib version on robot is 2016.0.0”? Or is there a consistent 5-10sec delay between EVERY step. (If the former, there might also be a long delay near the end, but I’m not sure what debug lines it is between). The former is the issue that was resolved with the reflashing of the router. The latter is probably an issue with the CPU on the programming laptop.

4480, were you able to resolve your issue?

I’m sitting down with a roborio and the router finally, and I’m having a similar issue. I did reflash the router, and I can confirm that it’s definitely a DNS issue (at least, on my mac it is):

Examining the tcpdump output, it looks like this is happening:

  • t=0, query to multicast 5353
  • t=0.1 response from roborio on IPv6
  • t=0.2 cache flush AAAA from roborio?
  • OSX sends 6 ICMP6 neighbor solicitations trying to find IPv6 address of roborio, no responses
  • t=6 first ssh syn packet to roborio from computer (ipv4)

Here’s the raw tcpdump output for those interested:


OSX Computer is 10.24.23.143
Router is 10.24.23.129
RoboRIO is 10.24.23.22

01:23:50.827794 IP 10.24.23.143.55752 > 10.24.23.129.53: 65077+ SOA? local. (23)
01:23:50.830292 IP 10.24.23.129.53 > 10.24.23.143.55752: 65077 Refused 0/0/0 (23)

01:23:50.945125 IP 10.24.23.143.5353 > 224.0.0.251.5353: 0 [2q] A (QU)? roborio-2423-frc.local. AAAA (QU)? roborio-2423-frc.local. (46)
01:23:50.945654 IP6 fe80::aebc:32ff:febf:435d.5353 > ff02::fb.5353: 0 [2q] A (QU)? roborio-2423-frc.local. AAAA (QU)? roborio-2423-frc.local. (46)
01:23:50.948130 IP 10.24.23.22.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/0 (Cache flush) AAAA fe80::280:2fff:fe17:fa48, (Cache flush) A 10.24.23.22 (78)
01:23:51.120263 IP6 fe80::aebc:32ff:febf:435d > ff02::1:ff17:fa48: ICMP6, neighbor solicitation, who has fe80::280:2fff:fe17:fa48, length 32
01:23:52.121609 IP6 fe80::aebc:32ff:febf:435d > ff02::1:ff17:fa48: ICMP6, neighbor solicitation, who has fe80::280:2fff:fe17:fa48, length 32
01:23:53.122867 IP6 fe80::aebc:32ff:febf:435d > ff02::1:ff17:fa48: ICMP6, neighbor solicitation, who has fe80::280:2fff:fe17:fa48, length 32
01:23:55.124184 IP6 fe80::aebc:32ff:febf:435d > ff02::1:ff17:fa48: ICMP6, neighbor solicitation, who has fe80::280:2fff:fe17:fa48, length 32
01:23:56.125393 IP6 fe80::aebc:32ff:febf:435d > ff02::1:ff17:fa48: ICMP6, neighbor solicitation, who has fe80::280:2fff:fe17:fa48, length 32
01:23:57.146408 IP6 fe80::aebc:32ff:febf:435d > ff02::1:ff17:fa48: ICMP6, neighbor solicitation, who has fe80::280:2fff:fe17:fa48, length 32
01:23:58.158048 IP 10.24.23.143.52204 > 10.24.23.22.22: Flags [S], seq 608500754, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 2000205903 ecr 0,sackOK,eol], length 0
01:23:58.160321 IP 10.24.23.22.22 > 10.24.23.143.52204: Flags [S.], seq 2654078593, ack 608500755, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 5], length 0

Interestingly enough, I found a workaround. If I connect to roborio-2423-frc.lan, that works almost instantly. Of course, it would only work when connected to the router, and I suspect the router will be configured differently at competition…

Oddly enough, I also noticed that there seem to be 2 DHCP pools on the router, and so the robot ends up with a different broadcast IP than what my computer gets, so I cannot receive netconsole output (at least, not on OSX).

So I just have to change it to .lan instead of .local and then connect via ethernet each time? Also, that would explain why I can’t see any of my messages from the program you wanted me to run.

Even when trying to load the web interface it seems to take longer and sometimes fails to load.

No, this works via wireless too. When I said “connected” I didn’t mean “physically connected”.

Also, that would explain why I can’t see any of my messages from the program you wanted me to run.

There is an alternate way to see the Netconsole output: the driver station this year ships with a message console that should show the netconsole output. You can click the ‘gear’ icon, and then in the menu click “Console Viewer”. I’m not quite sure why it works for the DS yet.