Falcon Flips Direction During Teleop After Repair

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

4 Likes

This is something I would share directly with Vex customer service. It would be interesting to know their answer.

1 Like

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.

2 Likes

Please contact our support (support@ctr-electronics.com). There is likely something else going on here and we can assist with troubleshooting.

It would be helpful if you could provide:

  • A self-test snapshot while the behavior is occurring
  • An export of the Talon FX configs (Tuner can do this)
  • A short video of the behavior with LEDs visible

Will do, thanks. Will be in touch shortly and share the results here.

1 Like

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.

4 Likes

Did anyone experiencing these symptoms make changes to their software recently?

2 Likes

Yes. Believe it was this. Stopped using arcade and issue went away

1 Like

We just experienced the same thing. IT was weird. After we took belts off (no load it failed) but when we put the belts on (some side load) it worked again.

I think this issue would be very hard to see in practice. For example, the driver station will not send negative 0 for a joystick axis. So the negative 0 would have to be generated by your robot code.

We often negate a joystick axis (specifically the Y axis) which caused this issue for us.

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.

Ah yes, a rare case of Falcon 500 schizophrenia

2 Likes

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.

1 Like

It’s not too easy to check whether a variable’s value is -0.0. I posed the following to my team after seeing @RCoder01’s ArcadeDrive bug:
Why would you ever write

if (x==0.0) { x=0.0; }

The answer is exactly to solve the problem caused by the ArcadeDrive bug. This code looks really weird but it is simpler than anything else I can think of to get rid of a -0.0 value.

3 Likes