ZebraSwitch - Reliable Robot Ethernet that won't break your BOM

We’ve spent a long time searching for a reliable gigabit Ethernet solution to use on our robots that is affordable and works well for us. This paper will describe our “recipe” for creating such a switch.

Paper is up here: https://team900.org/blog/ZebraSwitch/

Direct link: https://drive.google.com/file/d/1831LYvreDi92YI8yGHP0Xr4zeUm9So4q/view


⁹ Vaping is bad, don’t do it, not even especially with electronic components.


Seriously, thanks for sharing! Another trick we’ve used to keep barrel jack connectors in without 3-d printed parts or glue is to use right angle barrel connectors; you can keep these in with a zip tie or inside wall of the robot.



Also a good trick.

Do you guys mind explaining some of the personal pitfalls you experienced for not following this rule:

  1. If you plan on having ethernet onboard your robot, DO NOT use both ports on the
    OpenMesh Radio. Yes, this means plugging your RoboRIO into a switch.

  2. The reason for this is complicated but it comes down to a firmware issue on the
    OpenMesh Radios used in FRC and the physical ports ending up isolated from each
    other on boot of the radio.

See the editor’s note that was added. The physical ports end up isolated from each other on boot up of the radio sometimes - the OpenMesh radio no longer acts as a switch when it happens.

This problem used to be isolated to the AC radios but I’ve seen it on the ANs and at this point (though recreation on the ANs has been difficult), for The Zebracorns, we require Ethernet communication between our Jetson and the RoboRIO and that’s the end of the story.


Interesting! Thanks for the paper guys, we’ll definitely be looking at this for the upcoming competition, probably experienced some of this behavior with our limelights.

1 Like

Huh. Totally would explain some very random issues we had in 2017 that would only get resolved by “reboot the robot, magically works now”.


Can confirm this bit us hard in 2017 at an out-of-district event where I spent a long time chasing it down with some of our students before realizing what the issue was… and it’s not consistent so it only happens every so often. It was not the only problem we had mind you…

The 2017 season is when the rule was updated (Team Update 2 or 3 maybe?) in a very unceremonious update that almost no one knew about and even this past year, I had to inform some CSAs that “yeah dude, it’s cool to run the RoboRIO to the switch”.

Again though, follow the guide. This might be needed for some teams but I think for a vast majority, they might be better continuing to run the RoboRIO directly off of the OpenMesh. It’s very team dependent.


We broke marshall! 900’s using Onshape! The old CAD collaboration tools are dead, long live the CAD collaboration tools!

also cool whitepaper.


We’ve been using OnShape since 2015 my dear padawan… though FIRST NC might have called it Onshore (or we might have, I’m not sure - stupid autocorrect):


Nice work Marshall and the team, thanks for sharing!

I had to inform some CSAs that “yeah dude, it’s cool to run the RoboRIO to the switch”


1 Like

Love the paper! I have an alternative mounting solution that uses the smaller (non-gigabit) version of that network switch. It stacks the radio on top of the network switch and also provides mounting for the VRM and PoE injector. I uploaded it to thingiverse: https://www.thingiverse.com/thing:4060871

We’ve never used a gigabit switch simply because we don’t need the extra throughput for these applications.


Do you mind if I pull your switch mount into ‘MKCad - Electronics’?

Go for it. I totally think it’s ripe for someone to come along and make a better one that latches and doesn’t involve double sided tape but I’m lazy.

Look what Uncle Jeff sent me for Christmas! An unmanaged Ethernet switch, to play with.

Cool. Word of warning, I don’t know about the particular switch you pictured but it looks like it has a metal housing. Some of the switches we looked at that had metal housings were case grounded. That’s not a problem normally but on an FRC robot that can make mounting it a concern as we can’t have chassis grounding. Might not be an issue but something to be aware of.

I think you refer to r49 (page80). Very good to know, and non-trivial for a lot of reasons.
Is this a good thread to ask questions about the setup for the switch? I didn’t see any step by step info in the white paper. I read quite a bit about securing the power source.

It should be an easy thing to check with a multimeter or crack it open and take a look at it though it’s likely going to be through one of the mounting holes if it is grounded to the case.

I’m not sure what you mean by setup but ask away. It’s an unmanaged switch so you just plug it in and watch your packets go from one port to another.

What software do I have to use with the om5p w/ FRC firmware?
Or in other words, will only the driver’s station and (in our case) robot Java talk to the om5p?

I performed a test using ssh between two pi.
I am able to reach the far port with a om5p flashed with openWRT, but I cannot with a om5p flashed with FRC firmware.
I don’t see any ports on the radio configured for ssh, and seeing how one cannot modify the firmware, I think I can go no further until I have a DS and a Roborio to work with.
Merry Christmas!!

You can’t use ssh (or any protocol) over port 22, only certain ports are allowed for team use. You can use SSH, HTTP, Telnet, etc. as you please within a range of a few allocated ports:

The following ports are opened for communication between your Robot and Driver Station. All other ports are blocked. All ports are bidirectional unless otherwise stated.

  • UDP/TCP 1180 - 1190: Camera Data
  • TCP 1735: SmartDashboard
  • UDP 1130: DS-to-Robot control data
  • UDP 1140: Robot-to-DS status data
  • HTTP 80: Camera/web interface
  • HTTP 443: Camera/web interface (secure)
  • UDP/TCP 554: Real-Time Streaming Protocol for h.264 camera streaming
  • UDP/TCP 5800-5810: Team Use

Teams are permitted to utilize ports 5800-5810 for their own purposes, or any other open ports (other than 1130 and 1140) if not already allocated.

edit to add: not directly related to your question, but while we are on the topic of FRC radio firmware behavior, it’s also worth noting that there is a bandwidth limit of 4 Mbit/s across all ports that will be enforced by the FMS during competition and will be enforced by the radio using team-use firmware if that box is checked in the Radio Configuration Utility

Source: 2019 FMS Whitepaper

1 Like