Co-processor

[jrothr...@hdsd.org]

Hello,

WHile we have been working with the Romi much of last season, we are beginning to use our VMX-Pis again. I am wondering how to use the vmx-pi as our robot brain in the FRC  control system with a hard-wired coprocessor in AP mode (The VMX is in AP Mode).

We have a photon vision pi and a limelight.

Thank you for the incredible devices.

~Mr. R^2

[Scott Libert]

It’s hard to be definitive without more info like:

- how many subnets will exist on this network?  If multiple, how will they partitioned?

- if the coprocessor is in AP mode, but is hardwired, what is the purpose of its Access Point?

- does the coprocessor also provide a DHCP server? [Danger - multiple DHCP servers on the same subnet will cause chaos and confusion]

Absent those answers, here’s my 2c:

VMX is in AP mode so its DHCP server can allocate IP addresses to WiFi clients (eg driverstation).  But why does the coprocessor also need to be an AP?

My recommendation is disable the AP on the coprocessor.  Either give it a static IP address on the ethernet network (just as one would with a competition RoboRIO) or have it be a WiFi client of VMX’s AP.

If for some reason that’s not possible, prepare yourself for more complexity.  It’s in theory possible to have a second AP on the same subnet if and only if there is only one DHCP server, and all APs have the same password and SSID.  But this configuration is more complicated, harder to debug and seems unnecessary complex.

[jrothr...@hdsd.org]

Hello,

Thank you for your help. I apologize. My previous message described the setup inaccurately.

Here it is. 

We have two VMX-Pi robots each VMX-Pi is its own AP and unique SSID. We would like to add a coprocessor to each (one photon and one limelight).

The co-processors are not in AP mode, but are hardwired (just like with the Rio). When I plugged one in expecting the VMX-Pi's DHCP to take over, the VMX-Pi was not giving it an IP address. I used Angry ipScanner to check, and all I could find was my host computer (wirelessly connected to the VMX-Pi), at 10.67.62.5, and the VMX-Pi at both 10.67.62.2 and 172.22.11.2. This is odd as I am able to find the pi on my home router when I plug it into it. 

So, then I tried to set the static IP (with DHCP Fallback) of the co-processor to 10.67.62.9 with a gateway and DNS Server to 172.22.11.2, and it messed up the VMX-Pi somehow. I could find the VMX-Pi at first, but then I  could not. I also noticed the Titan Motor controller status light was blue. I assume once the co-processor finished booting, there was an IP conflict. 

I was using the WPILIBPi image on the co-processor because I understand how it does networking a bit better than photon or the limelight. I am going to try using photon and setting it to static to see if it works any better.

[jrothr...@hdsd.org]

Edit: The only networks are those provided by the VMX-Pi out of the box (so, two subnets 10.67.62.xx and 172.22.11.xxx correct?).

The co-processors are not in AP mode and are not running a DHCP server. Also, the two robots (and by extension the co-processors) do not talk to one another or the same host computer. I am sorry about that confusion.

[Scott Libert]

Thanks for the additional details, that helps.

>  When I plugged one in expecting the VMX-Pi's DHCP to take over, the VMX-Pi was not giving it an IP address. I used Angry ipScanner to check, and all I could find was my host computer (wirelessly connected to the VMX-Pi), at 10.67.62.5, and the VMX-Pi at both 10.67.62.2 and 172.22.11.2. This is odd as I am able to find the pi on my home router when I plug it into it. 

Yes, this is odd.  The VMX-Pi DHCP Server is configured to allocate IP addresses on its ethernet interface within the range 172.22.11.XXX  (this occurs for instance if a PC is connected to the VMX-pi ethernet port).  If the Coprocessor were (a) DHCP-enabled and (b) connected to VMX-pi's ethernet, it should have received an IP on the 172.22.11.2 subnet from VMX-pi's DHCP server.   I'm curious what the ifconfig command on the coprocessor would have revealed in this case....

My intuition is it's best to find the root cause causing DHCP address assignment to fail.  I don't have an explanation for this.

You might also consider disabling the wifi interface on the co-processor, perhaps that will remove a confounding factor?

> So, then I tried to set the static IP (with DHCP Fallback) of the co-processor to 10.67.62.9 with a gateway and DNS Server to 172.22.11.2, and it messed up the VMX-Pi somehow. I could find the VMX-Pi at first, but then I  could not. I also noticed the Titan Motor controller status light was blue. I assume once the co-processor finished booting, there was an IP conflict. 

I understand the way fallback works is it will assign the static IP address ~only if a DHCP server can't be reached~.  So I assume that in this case, the initial DHCP server communication over ethernet would have led to assignment of an ip on the 172.22.11.XXX subnet (and 10.67.62.9 would not have been used). But maybe it failed, similar to your first example.  Again, ifconfig will likely reveal more details.

If DHCP assignment failed, then the co-processor ethernet interface is statically assigned 10.67.62.9; in this case, the co-processor would attempt to send IP packets over the ethernet interface to the wifi network.  VMX-pi doesn't create any route between these subnets, so this communication should fail.

I'd recommend statically assigning the coprocessor a static ethernet ip of 172.22.11.10 (10-20 are the final octet ranges recommended by FIRST for coprocessors, 9 for IP cameras).  Disable DHCP.

Also, is it required to creating routes between the Wifi and Ethernet subnet (e.g., setting gateway)?  To keep things simple, I'd avoid this if possible.

[jrothr...@hdsd.org]

Thank you. This helps a lot.

I think you found the culprit.

"Also, is it required to creating routes between the Wifi and Ethernet subnet (e.g., setting gateway)?  To keep things simple, I'd avoid this if possible."

I think this is required as the computer and network tables are connected wirelessly. My (admittedly rudimentary) understanding is this works on a normal FRC robot because it uses a wired bridge that becomes the access point and connects all the devices together in one subnet.

However, since WiFi is disabled on the co-processor and the computer is connected wirelessly to the vmx, there is no way to get to the co-processor data. If this is true, DHCP, and for that matter, static addressing could be working and we would never know. If this is the way it is, the behavior would make sense. I have no monitor plugged into the processor, but when I get a chance, I will try it out (The limelight cannot do this, but I think Photon can). 

I see two possible fixes...

1) connect to the vmx wired (using a switch)

2) bridge the two networks in the vmx OS

There is a lot of conjecture here, but does it seem to be in the right ballpark?

[Scott Libert]

> I think this is required as the computer and network tables are connected wirelessly. My (admittedly rudimentary) understanding is this works on a normal FRC robot because it uses a wired bridge that becomes the access point and connects all the devices together in one subnet.

> However, since WiFi is disabled on the co-processor and the computer is connected wirelessly to the vmx, there is no way to get to the co-processor data. If this is true, DHCP, and for that matter, static addressing could be working and we would never know. If this is the way it is, the behavior would make sense. I have no monitor plugged into the processor, but when I get a chance, I will try it out (The limelight cannot do this, but I think Photon can). 

1) If as you say the Co-processor implements a NetworkTable "server", and the client computer truly must access this server, then a route would be needed.  I'm surprised if this were true, because the WPI robot application embeds a NetworkTables server, and because the limelight docs show example code of accessing the "limelight" table on this page, which uses the default instance (the roborio/VMX instance) of the network tables.  Based upon this, the remote wirelessly-connected PC should be able to access the "limelight" network tables data along with all the other roborio/VMX network tables data published by the roborio NetworkTables server.  All that's needed is for the co-processor to be configured with the roborio/VMX ethernet ip address, so it can connect to the NetworkTable server.  In a nutshell, I believe the co-processor implements a NetworkTables "client", not a "server".  I could be wrong on this, but I believe it's key to get this overall network architecture understood clearly.

Additionally, if a Linux computer has multiple NICs, opening up a listening socket (like a NetworkTables server does), it can accept input connections from clients on ~all network interfaces~ - so the VMX/roborio NetworkTables should be accessible from any of it's network interfaces, not just the wireless network interface.  Linux uses a "weak host model" that is described further here.  So the VMX/roborio NetworkTables server can simultaneously connect over Wifi with driver station NetworkTables client, and over ethernet with Co-processor NetworkTables client.

2) I also think it's key to understand why the co-processor didn't get an IP address from the VMX AP in your testing.  I'm concerned there's some other issue lurking, and without resolving that there will be troubles.  I think it best to resolve this first before reconfiguring the network topology.

> I see two possible fixes...

> 1) connect to the vmx wired (using a switch)

> 2) bridge the two networks in the vmx OS

> There is a lot of conjecture here, but does it seem to be in the right ballpark?

***

I recommend resolving issues 1) and 2) above before reconfiguring the network.

As you suggest it should be possible to create a bridge between VMX Wifi and Ethernet interfaces, by using Linux router software.  In my experience, if a router gets configured incorrectly, it can introduce hard-to-diagnose issues, and it would need to mesh seamlessly with the other networking configuration on the VMX; to me, it seems like a research project that could take a little while.  And until 1) and 2) are resolved, I don't think it's the "simplest thing that could possibly work".

It might also be possible to - like the FRC Wifi Router - force the robot ethernet and Wifi interfaces to be on the same subnet (although this would break the existing VMX "you can always connect via ethernet @172.22.11.2" functionality).  But I don't think this solves anything - because either way the Coprocessor (a) needs to have an IP route to the VMX/roborio and (b) needs to be configured with the ip address of the VMX/roborio.

Tricky, huh?

- scott

[jrothr...@hdsd.org]

Thank you for the reply. This info helps a lot.

Once again, I was making some assumptions...

1) I need the IP Address of Photon. 

This is only partially true. See below...

2) Since the network tables were not automatically loading, Photon was not working (this confirmed the assumption above).

So, why the assumptions above when FRC only really cares about Network Tables?

Well, The first step in using photon (and WPILibPi as well as the Limelight) is to tune it in the web interface. Since that did not work, and I did a cursory glance at the vision table which came up empty, I assumed it was not working at all.

I did find some odd ip info when using the screen and keyboard (it was using a loopback, and it seems that it is not getting a standard ip from the VMX-Pi), it seems to be working :). I created a Java program and just instantiated the library, and now (using a static ip of 172.22.11.9) the full data is showing up in Network tables. This is incredible. So, we can use a router, Rio, or possibly even a switch (not a router) to tune the pipelines, and then run our program with a direct hardwire connection between the VMX-Pi and the co-processor. I assume the Limelight will work the same.

Unfortunately, our team is exploring CPP.  Photon requires the units/time.h header file as a dependency. So, that may not work with the VMX-Pi which requires the 2020 version of the library (I think that predates the dependency). I will try the limelight in the future, but this is incredible regardless.

Thank you for your help.