At an absolute loss for why this would be occuring and could use some help.
We have 4 orange pis on our robot. They all interface to a 5 port TPlink switch (TL SF 1005D). We like these switches because they’re fairly small and made of plastic. Were tight to the weight budget.
We’e found a lot of dropped pings and high latency to reach each orangepi on the network. The roborio is always available to pings. But often the orange pis aren’t. If i simply plug 1 orange pi in, and leave the other 3 off the switch (but still powered by the robot) i have no problem consistently pinning each one. The problem seems to be when all 4 orange pis are turned on.
The switch is on a 5V 2A regulator. We also confirmed this was the case with a multimeter. It was a digital multimeter but I’m fairly confident this is the case. My initial fear was the switch entering some sort of brown out. The orange pis are also on a regulator.
Checking syslog on the orange pi. I don’t see any complaints about browing out or any sort of power issues.
Watching the network with wireshark, i don’t think our vision network is overworking the switch. So I’m at a loss there.
Anyone expierence anything like this or have any ideas? I’m at a loss for why it would be behaving this way.
Check the MAC addresses of each Orange Pi; we’ve run into an issue where they were all identical after cloning one SD card to others. This resulted in the exact same failure mode as you: the system worked with one Orange Pi networked, but we dropped tons of packets when a second was connected.
oh my gosh. I think that might be exactly what is going on, I can’t confirm right now but we made one image and cloned it several times. I’ll be over the moon if that’s the problem! I’ll have to wait until tonight to connect and check but I wouldn’t be shocked
From my understanding, even though MAC addresses are unique to each network card on each Orange Pi, udev rules can sometimes get copied when imaging which ends up setting them all to the same ID.
The udev file will be cloned to the new machine and thus it will override the real MAC and make the file system just read those MAC associated here instead of the real MAC.
To fix this, I believe you need to run these commands:
nmcli con show to find the UUID of your network profile sudo nmcli con modify <uuid> ethernet.cloned-mac-address 00:12:34:56:78:9a
(take this with a grain of salt, it’s been a while since I’ve done this)
Just set different addresses for each device; we just incremented the final value by 1 for each additional coprocessor.