All V5 Motors Cutting out mid-match

Hey guys!
I had this issue at a recent tournament last weekend. Our cap flipper is the kind where the whole claw rotates 180 degrees at the press of a button.
It was going pretty good until I tried to flip one cap and the second the claw turned about 45 degrees, it cut out. Not just the claw motor, but all the motors on the robot. The only way our bot started moving again was when our teammate or an opposing bot nudged ours. Once that happened, the claw would continue its flip and all the motors would be fine again.
We temporarily avoided this problem once it was observed by restraining ourselves to flip caps in intervals of a couple second.
The trends for when this happened would be

-After rapidly flipping multiple caps in a short amount of time
-The claw would turn to the point where the side of the cap hit the ground. Its at that point where the motors cut out.

Would anyone have a clue why this happens? I thought it was burning out but that doesn’t explain why all the chassis and lift motors burn out, and on top of that, the motor was a healthy temperature.
Have any of your guys had this problem? And if so, how did you resolve this?
Thank you in advance!

Hmmmmm… maybe you tripped a breaker. Is your firmware up to date? It could also be that your battery connection was loose, and the vibrations just shook it loose. I could see that happening with Cortex, but V5 seems a lot more secure.

I had that happen yesterday - we debugged it to a smart cable that got nicked, suspect it is shorted. Symptom all motor ports went out, but radio still worked, and Brain appeared to function correctly. Nothing on event log…

When I tested the brain at home it was fine. Similarly, the second brain we thought was dead is back. Of course I knocked out of commission again by connecting one motor at a time until we had the failure happen again.

@jpearman should something have been recorded in the log? any way for VEXos to detect global shutdown of motors?

A power short on a single smart port should not cause a global shutdown of all motors, each port has its own dedicated eFuse that will detect over current and disable just that single port. Disrupted port communication should be detected and recorded in the log, latest vexos will also show full screen alert if a port becomes disconnected when user code is running. If controller comms is lost, all motors will be stopped but should be re-enabled when controller communication is re-established.

1 Like

Then what would cause every motor port to cease functioning? I tested each port with the devices motor control. Not a single port worked during the outage and this was on two V5 Brains.

I’ll go back and see if I can reproduce it in a more controlled environment (not the kids robot…)

in your code if its not a separate function, if your claw isn’t able to reach 180 degrees of 0 degrees then the code will never finish there for stopping the other coding from ever happening, (this is only true if you have to set to go to 180 or 0 at the push of a button)

Post code? You are likely using a motor command that is waiting for completion, so when it does not complete the code sits there waiting for the move to finish.

To test: drive forward while operating your flipper. Try to change direction while it’s flipping. If you can’t, a blocking motor command is the problem.

Was not able to reproduce on test bench.

I have had an issue where during normal run-time of a user program, the V5 randomly switches to the default “drive” program. Could this be your issue?

In our case, I had our teams configure the motors to be on the same ports as default Drive program - you know for that day they totally mess up their code, which they will :slight_smile:

Since they have not provided me with their code, I can not say for sure it is not related to something they did there.