I hope someone here can shed some light on issue we had recently at MARC offseason event.
I am trying to understand the data collected.
We would run for what seemed like a random time and then would be disabled. I have our first qualification match (Q3) and our second match (Q7) to compare. First match went well. Second match we disabled 57 seconds into match, were disabled for 60 seconds and then came back for 7 seconds and disabled again.
It is something to do with the radio. Trying to understand what.
The DS Radio in the console says GOOD.
The Radio Rio is bad.
So, if the radio is rebooting, why is DS Radio GOOD??
What is taking the 60 seconds? Is it the radio rebooting or is it the Rio, working through the radio to reconnect to FMS and DS that is taking 60 seconds?
We replaced raidio and everything to the Rio and still had problems in later matches.
We were running RPM to radio at first.
Switched radio and ethernet cable from Rio to VRM and VRM to radio.
Switched to a VRM, through PoE to radio
We switch DS laptops and used the USB-to-ethernet adapter from FTA.
Finally we were using a USB-to-ethernet from Rio to our PoE instead of the ethernet on the Rio.
We shook and tapped on lots of connections in pits watching for dropped comms on DriveStation.
I am wondering if the issue is the Rio2. We used it all season. We did have similar problems at Worlds. I’ll have to look at that data next.
Another question, why would RobotTeleop be toggling so much in the bad match??
In the ds logs, “DS radio” refers to the field router (at .4), and “robot radio” refers to the robot radio (.1). The line you’re pointing out in the log indicates that the ds is still connected to the field (since it’s able to ping the field router), but it lost connection with the radio (and therefore also the Rio).
Was this with the new radios or the om5p radio? 60s seems a little long for an old radio reboot (in my experience, they’re usually very close to 45s), but it does seem likely based on the symptoms.
This isn’t a symptom, it’s an artifact of how AdvantageScope displays that data. A RobotTeleop/Auto/Disabled ds log entry is recorded for each packet the DS receives back from the robot- the packet contains the mode the code is reporting. If the DS misses a status packet (fairly normal, nothing to be super concerned about in isolation) AdvantageScope displays it as false.
In the ds logs, “DS radio” refers to the field router (at .4), and “robot radio” refers to the robot radio (.1).
Thanks for hint on the IP address (.4) (.1) (.2).
We were using the old OpenMesh radio.
We tried 2 of our radios and finally borrowed one from FTA.
post wiring pics of main power and radio power
I don’t have a good picture of our wiring.
It was nice, but in trying many combinations to fix the problem we ended-up with lots of gaffers tape and zipties to secure and strain relief each iteration.
I think every FTA there was over to try to help at some point.
60s seems a little long for an old radio reboot (in my experience, they’re usually very close to 45s), but it does seem likely based on the symptoms.
In the case of Q7 match, I see some activity around 50s, but robot is not back in Teleop until 60 seconds.
This isn’t a symptom, it’s an artifact of how AdvantageScope displays that data. A RobotTeleop/Auto/Disabled ds log entry is recorded for each packet the DS receives back from the robot- the packet contains the mode the code is reporting. If the DS misses a status packet (fairly normal, nothing to be super concerned about in isolation) AdvantageScope displays it as false.
The fact that we see so many change-of-state in RobotTeleop, could this indication of dropped packets on DS side? or the robot or radio not able to send them.
I agree with Ryan. Maybe the ~45s/~60s thing is the model of radio you have, but there are other potential explanations.
As you stated, Q3 seems good. In Q7, there were two robot/radio disconnects, one @1:39:30 that lasted almost exactly a minute and one at the end of the match (1:40:37) which ends only when the logs stop, less than a minute later. The pings to the radio stop, and there is no telemetry coming from the robot at all.
So, it looks like the main issue is loss of the radio. I don’t see any smoking gun right before the connectivity is lost. “DS Radio” is the Driver Station radio, so that’s good nearly always. I don’t see any evidence that anything is going on with the RIO. Long connectivity losses are normally radio power, not radio/RIO Ethernet.
You can loose a radio because of a very brief interruption in the main power loop: battery terminals, Anderson (SB50) connectors, main breaker, connections to PDH/PD, fuse in radio power from PDH/PD, RPM/VRM, etc. In fact, in my experience, something in the main power loop is a more common cause than having an issue in the wiring that’s specific to the radio.
I see that a lot of stuff in this area was replaced, but I’d still wiggle test everything and see if you can cause the radio to reboot this way. Also, watch match videos and see if you can correlate when this happens with hits/collisions. Since you don’t mention the main power loop, I’d be especially careful to check everything there.
