Multiple Pi's?

So does anyone know the rules about having multiple Pi’s running on the bot? Would a simple LAN splitter like this work for putting two inputs into the radio?
https://www.amazon.com/gp/product/B074N2J159/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1

Just thinking about if it’s possible at all has anyone investigated or tried for their team?

That splitter, you can only have one pi active at a time, so what’s the point, just unplug the one you are not using.

You want multiple Ethernet ports running at the same time, you need an Ethernet switch. We have had good luck with the Netgear 5 port, all metal frame.

We did not have good luck with the one Andymark sells in a plastic enclosure.

12v input, wire to VRM or a 2nd VRM if needed.

I’m pretty sure you are allowed to use multiple Pis. However, the LAN splitter that you linked to will not work. You need to use an Ethernet Switch. Out of curiosity, what is the second Pi for?

You can have as many co-processors as your heart desires.

You can legally use those splitters BUT they won’t do what you think they’ll do.

Ethernet (TCP/IP) is a digital protocol that needs switching, routing, etc.

Instead of one of those, you would want to use a switch similar to this fine example in FIRST Choice: http://firstchoicebyandymark.com/fc18-035

We ran two TX1s at one point last year. It worked well but we ultimately had to remove the second one to focus on some core problems we had.

From Amazon’s notes for that product (which were apparently poorly translated from Chinese):

> Condition of usages: shut down one computer while you are using another one, which can not use at the same time.

Agreed with this. We used this switch on our 2016 robot to make tethering easier (since the OpenMesh radio has only the two ports, testing auto using the pi when the radio was configured for competition required either swapping the radio out or having a switch).

One note: if you go with the switch approach, be sure that your roborio connects directly to the radio, and the pis connect to the switch and the switch to the other radio port. Don’t connect your rio to the switch!

If you lose the switch for some reason (barrel connector :frowning: ) you don’t want to lose the roborio connection!!!

Depending on which radio you are using this is risky and runs contrary to a team update.

I’ll try to find which switch we used this past year and link back later, but it plagued us all Stl regional. It took us awhile to identify it as the root cause which is always frustrating.

The only reference I found was in Team Update 17, which mentions that some teams had issues when using the 802.3af port. However, it also calls out the problems of having a switch between the roborio and the radio. Ultimately we’re left with a choice between two risks: the possibility of losing connection to the coprocessor, or the possibility of losing connection to the coprocessor and the roboRio.

Now…if we had a radio with 3 or 4 ports, or someone made a rugged switch that had a barrel connector AND supported 12v POE (input), then I could stop worrying!

I guess? I see your point but I’m not convinced it is a proper risk analysis of the situation. You’re boiling it down to a simple failure mode and ignoring the nature of these radios as well as a teams reliance on a coprocessor. As a team that experienced the issue and as a mentor with a pretty decent understanding of the underlying firmware on these radios and a background in this stuff then my take is to either not use the OM5P-AC radio or use a switch - which is a much more stable and known quantity.

Also, as a current beta testing team - there has been a firmware update to the radio to address this issue and it might be resolved now… maybe. I’ve had two radios running for desk testing and I haven’t been able to recreate the issue with the new firmware but I still don’t trust them.

Anyway - I think you were trying to make a point about risks but it’s a point predicated on assumptions - as most risk evaluations are.

Marshall - this is slightly off topic, but radio related.

We know that the radio operates from 12V power. Based upon a discussion with Open-Mesh, a couple of years back, the radio is able to operate at slightly lower Voltages. As I recall, the primary factor was the transmit power level. Do you know if anything is being done to tune the transmit power level for these devices?

Thanks!

Still suggest the metal cased Netgear over this. We used the plastic cased one from FirstChoice last year only to fail in our third event.

BenBernard based on last years data, it was far more likely for the radio to not maintain comms between it’s two ports, than a switch and it’s 5 ports. Hense the reason for the updates to begin with. We spent our whole week 1 event at Southfield with multiple FTA’s and only were able to to get communication with our vision processing when we ran it how it wasn’t meant to be… So the choice is do you trust your comms to an proven industry standard network switch with no user changeable firmware, or hardware that has a firmware that is to be understood, configured, locked down, updated at an event, with limited access to real world competition testing.

marshall has his money on the right bet… :slight_smile:

Nothing that I’ve been asked to test. Can you point to some kind of document for this? I haven’t seen anything that suggests these radios drop transmit power at 12v…

Oddly enough, we ran that same Netgear switch as well. Didn’t see any issues with the plastic one on the practice bot though.

Ageed–but the tradeoffs will be different for different teams. Our pi was only used in autonomous, and then only for our side-gear auto. Thus for us the impact of losing the pi would have been pretty low–and it never actually happened to us. On the other hand, we had terrible experiences with the barrel connectors, even when they were taped in, so I really didn’t want to run our roboRio connection to the radio via the switch and end up depending on another barrel connector.

If we were more dependant on our pi, I think I’d have made the same choice as Marshall. Given that the OP was looking for ways to add more pis, my guess is that Marshall’s advice would be more appropriate for him.

Marshall - Took me a while to locate the email. I asked Open-Mesh about operating Voltage limits. Open-Mesh specifies 12 to 24 Volts. The VRM provides between 11.93 and 12.49 Volts. At issue is 11.93 vs 12 Volts and any Voltage drop in between. Open Mesh indicated to me that they thought the radio may not operate at 11.8 Volts; however, they also indicated that at reduced transmit power levels, the radio might operate at even lower Voltages. I was never able to get an answer if FIRST exercised any options in this area. At issue is possible incompatibility between the VRM and the radio depending upon manufacturing tolerances.