We had several robot resets in Pittsburgh that were very similar to what 341 experienced.
We have no RS-775's on our robot (thankfully). 4-CIM drivetrain, 2 RS-540's in the roller claw, 1 RS-550 for the arm.
The FTA reported the same low voltage reading to us at one point that was reported to 341.
Our first reset was after a hard impact with a tower. Most others occurred during normal operations, with no contact or other anomalous activity occurring at the time of reset. There were a few impacts later on in the competition that did not interrupt robot function at all.
We use C++. Others report using Java.
cRIO is isolated from the frame.
It appears that reports of this occurrence are getting more and more widespread, and the robots experiencing them more and more diverse in design and function. What are the common hardware and software ties that bind these robots and reboots together?
If any other teams have experienced similar issues, please share them.
Quote:
Originally Posted by Jared341
We had this issue crop up consistently throughout the Florida Regional starting on Friday afternoon and continuing into the playoffs. At some point in the match, the cRIO would reboot and we would lose comms for at least 45 seconds. The FTA was able to tell that our battery voltage was dropping to <7.5 volts or so just prior us rebooting.
We practiced with our robot (very aggressively - moreso than in a real match) for a week+ prior to ship and then completed practice day with no power issues cropping up whatsoever. The robot has 6 drive motors (4 CIMs, 2 RS-775s), a compressor, a FP motor running an arm, and a RS-775 running a roller claw. That is a lot, but none of the motors even get warm during a 2 minute match, so I am disposed to believe that the problem is electrical rather than mechanical in nature (or perhaps a hybrid of the two). Each time when we died on the field, we were not in a pushing match or anything - we were simply maneuvering around the field at a moderate speed, sometimes while manipulating a tube.
We pulled our electronics off the bot prior to crating, and will be able to try and reproduce/diagnose the problem in our shop over the next few weeks.
What I absolutely dread, however, is the possibility of not being able to reproduce/diagnose the issue at home, and then going into our next event with zero confidence that we're not going to have the same problem crop up again...
We are running Java v28 with no vision processing, but a lot of SmartDashboard I/O. I will use NetConsole in the coming weeks to make sure it isn't a code issue.
Any other suggestions on what to look for/try?
EDIT: Things we have checked already:
-Replaced 120A main breaker (immediately prior to cRIO reboots happening, the robot popped its main breaker during a match. The breaker itself looked suspect so we swapped out. After the switch, no breaker tripping, but cRIO brownouts started to happen.)
-BaneBots RS-775 motors with case shorts were identified and removed, but the issue still happened.
-Replaced our compressor.
-Re-did wiring for main breaker, PD board, cRIO power.
|