Just wanted to share a recent experience we had with one of our falcon’s that other teams may or may not be having, but thought it would be good to share:
Like many of you, we’ve been opening up our motors, adding shims if needed, and properly Loctiting all of the screws. We performed this operation on all of our drive base motors, and for some reason ended up repurposing one of those motors in our climber gearbox.
From the first day we tested our climber, we had an extremely bizarre issue of the falcon reversing itself. Not after a reboot, not after a brownout, but literally after sitting enabled for a few seconds, sometimes a minute, just flip itself the other way.
After removing the chain from the gearboxes and running them to rule out any mechanical problems, it turns out the motor was fighting itself and flipping direction on occasion. I have no idea what could have caused this (maybe it had two personalities), but my best guess is that somehow, the electronics were damaged during a repair that caused this. When the motor was in coast mode or powered off, no mechanical issues were present.
A replaced motor was installed earlier today and our first successful traversal took place
PSA: Just be careful when fixing your falcons and don’t damage the electronics
Had this EXACT same issue. I still don’t know what caused it. I pulled that falcon when we did the loctite repairs and now everything is working fine. BUT I haven’t been able to test it as we are short a few screws and shims still (vex has sent them but waiting on shipping) and I used that one for parts thinking it was defective. As soon as we get the new shims (and the bot is in working order) I’ll do some digging. Let me know if you get any answers in your testing.
I am not sure if I may be having the same issue but, our robot is mecanum drive and everything seems to working fine other than the motors on the right side, which are inverted in code, they move the wrong direction then halfway through joystick movement they go the other direction. I was not sure if my issue was code or the Falcons themselves.
Edit: While in that period of being halfway through they completely stop and then flip direction.
One thing to double-emphasize on this thread - while the symptoms described here are similar, there is as-of-yet no proof the root causes are the same.
Please continue to debug and drive to root cause, reaching out to CTRE support as needed. If you have time, post back here describing the root cause, and the process you used to discover it, so others may learn.
I had sent a support email to CTRE. My issue has to do with the fact that we removed load from motors that were operating under a closed loop velocity control. Thus the P gain would immediately cause it to overshoot velocity and it would reverse. May not be your problem but that was the same symptom.
Hi. Guy who reported the ArcadeDrive bug here. The bug only produces unexpected outputs when using exactly -0.0 as the forward speed and some nonzero turning speed. As soon as the forward speed changes to anything else, the inputs should fix themselves. A simple fix for until the next release of wpilib (which will likely include a fix for this bug) is to just check for a forward speed of -0.0 and replace it with 0.0 before calling the arcadeDrive method.
I would be surprised if the observed issue in question revolves around such specific circumstances.