We are going to give it a shot using vision processing with a Raspberry Pi 4 running Photon Vision.
I have looked at the wiring diagrams and have a few questions.
Why do we need the network switch, can we not just plug the Pi into the Radio (OM5P-AC)
Do we hard set the IP address of the Pi?
Is there a way to log into the Radio to see if it sees the Pi?
Is there a way to log into, ssh, telnet, into the RoboRio to see if it can communicate with the Pi?
I have searched the forum looking for these answers, did not see anything, but may have missed it. If this information is available somewhere else, please let me know.
Thank you,
Mark Tayler
While you do not need one, I highly reommend it. You can use the second port on the radio. However, if you do this, you will need to unplug the pi every time you want to wire to the robot in the pits.
This means you can risk not plugging it back in for a match; and you will not have access to the data in the pits either.
You could also theoretically use some of the IO to communicate directly to the Rio, but that seems like a lot of work.
For this season, you could also do wireless for the at-home challenges.
Plugging straight into the Radio works fine. The only downside is there won’t be any more available ethernet ports to plug in anything else on the robot. If you need to plug in a computer to the network (rather than WiFi), you’d have to unplug something. Usually this is more of a concern at competition where wifi connection isn’t an option, but in 2021… eeh. FWIW there is a methodology where you can bridge the USB port and ethernet ports on the RoboRIO, but I’ve not tried it much.
The PhotonVision Pi image will work with mDNS (UI served at photonvision.local:5800). However, I’m an advocate of using static IP addresses for everything. Either should work though.
The OM5P-AC is fairly locked down. You can SSH into it… maybe… but I’ve not found much useful on board… maybe someone else has?
The roboRIO can do all of the above (yay linux!), and yes, you can and should do that to help confirm the two are connected up.
That being said, the preferred methodology to debug network setup is Angry IP scanner from the development computer. The assumption is that you have a setup which allows you to talk to the roboRIO, radio, and deploy code (if not, go fix that first). Then, on top of that, use mDNS or the ip scanner to find photonVision using your development computer, and go from there.
This is a great little Switch. Its “Light Industrial”, takes anywhere from 5-30v, Uses screw terminals for power instead of barrel jack, is compact (just a bit larger footprint than the OM5P-AC), has 5 Ethernet ports giving you a net gain of 3! (4 open ports, but you already had one open port you needed to use to chain the router to the switch).
EDIT:
Also recommend these 6" Ethernet Cables for connecting the two together, and this 10 Meter Ethernet Reel for tethering computers to the robot at competition (just make sure you unwind as much as you need before plugging the computer side in because the jack spins as you unreel the cable).
Thankfully (or unfortunately depending on how you think about it) there is no story, this was something I preemptively noticed when I received it and could just imagine a robot ripping one thing out of another, so I was very sure to make sure whoever was using it knew “proper usage”.
At some point i’m hoping to find an RJ45 Slip Ring I can put inline with the output, but I haven’t found that product yet… I remember seeing RJ11 ones a long time ago, so maybe I could make that work since 1Gbe isn’t a worry here.
On your second question, my recollection is that static IP addresses solved some network connectivity problems that plagued teams in the past.
The ZebraCorns have a paper on what they did for a network switch (link below), including a recommendation for a switch and how to power it. We implemented it last year, although it never made it to the robot. The one comment I have is that the 3d-printed part which is used to hold the switch and power supply is a bit clunky and could probably stand some redesign.
Be careful about the switch you use. there are various devices out there which look like they’re exactly what you want, but are not (e.g. Intellinet 2-Port Modular Distributor (504195) ) .
Neat, glad it exists! but yeah, not sure the slip ring is worth $300 to me when we haven’t had issues yet using the one I linked above for two seasons.
First, thank you to everyone for your answers.
It never occurred to me that, yes we will need to tether the robot at competitions.
The Angry IP scanner is very helpful. We identified all of our IP addresses and were able
to use the browser to communicate to PhotonVision using either the static IP address or
photonvision.local . We will use the static IP address
A few odd things do occur though.
The IP subnet is 10.43.61.0
Radio = .1 RoboRio = .2
Raspberry Pi static IP of 10.43.61.10
Drive station uses DHCP set to 10.43.61.161
Another IP address was created for photonvision.local 10.43.61.40
Does photonvision also access DHCP to get an IP address? If so can this
be disabled?
The IP address 10.43.61.129 is live, and I cannot figure out for what.
Anyone know?
The default of PhotonVision is DHCP you can go to the settings page and configure a static address. It should look like this you can see the radio buttons in the center above hostname:
Actually, I have to recommend against plugging directly into the radio, without a switch. I can say from painful experience: this will work fine in the shop and pit, but may fail mysteriously on the competition field.
The problem appears to be that the OMP Radio is not a actually an Ethernet switch. When programmed for the FMS, only 1 of the ports works. We spent a whole day at a competition trying to make sense of this, never really figured out “why”, but using a switch just worked.
So, I definitely recommend: get a small Ethernet switch and plug the Rio and your vision computer into that, and then plug the switch into the radio.
It’s not just at competitions and you will see it in a lab/shop setting too. Though tempting to blame FMS, it’s really the radio chipset.
Your assumption that it’s not a true switch is correct and each port is effectively its own Ethernet port attached to the host.
This particular set of chips from Qualcomm have some bugs with port enumeration/handshaking/negotiation based on speed. There are several patches that were submitted to OpenWRT/Lede to resolve these issues but ultimately, they persist as evidenced by the fact that we keep seeing them.
If anyone reaaaaaaallly wants the specifics about this then I’ll go dig them out by request. There is a workaround noted in the rules and a method to avoid it. A patch isn’t coming for this to magically resolve it. It’s an esoteric bug for an older Qualcomm chipset based on PHY speed negotiation/handshaking.
This particular bug cost us more than a few matches and it was a source of much obsession for me for a while.
Would this explain why we find that a Raspberry Pi 4 has problems with the radio? We’ve found that if we connect our Pi 4 to the PoE injector connected to the left port it’s fine, but it’s not happy connected directly to the “correct” port (per the rules when not using a switch).
10-4 to this and @prensing’s post. I’d forgotten about this (I think we were still seeing issues with it all the way back in 2017???). We’d been in the mode of making sure our coprocessors were talking to the RIO prior to giving the thumbs up (by training the driveteam to look for the big “VISION OFFLINE” blinky red bad light and keep restarting the robot till said light went away).
I think it should still be sufficient to get ya started on basics at the shop, but agreed, don’t rely on the second port if you can avoid it.
The issue presents itself as a “physical layer disconnected” on that secondary port. Further, you often see it as the two ports being completely isolated from each other — this isn’t quite accurate but it’s weird that you can’t talk to one from the other when both are plugged in and everything seems normal. It’s really a problem with the physical layer within the networking chip thinking it isn’t connected when it is and the exact problem has to do with timing and specifically seems more prevalent with gigabit connections than with 10/100 but I haven’t confirmed that.
Technically, a quick unplug and replug should fix it but that’s not ideal for an FRC robot sitting on the field where students or mentors can’t easily access it.
I’ve dealt with systems where we disabled all forms of physical layer auto-negotiation for reasons such as this. Another issue I’ve seen is connectivity gets established, but at a lower speed. Sometimes, this last issue can be a feature, but not when the bandwidth and latency need to be as for the higher speed for things to work properly in the overall system.
One issue I remember was a board layout where the ground pin on a chip had too much inductance, because the design rules for power and ground got bypassed because of a bad annotation in the part’s description file. Flakey hardware bugs can be really insideous.
