At the Midwest Regional last week, we experienced a failure in a Talon SRX. I’m going to document what happened, so that maybe we can figure out what happened and prevent future failures.
It started unfortunately during our 1st quarterfinal match. We went to start our climb and noted immediately that the drum wasn’t spinning. We immediately stopped applying power hoping to prevent further damage. We quickly went back to the pit and first checked the CIM motor. We disconnected the CIM from the Talon SRX and connected a drill drive (a modified drill to apply voltage) to the CIM. The motor spun, eliminating the motor as the point of failure. Next, we reconnected the Talon SRX, enabled the robot, and applied power with the Talon. The Talon’s lights remained flashing orange, indicating it wasn’t trying to allow voltage. A check of the roboRIO web dashboard revealed that the roboRIO didn’t see the Talon in question. The final check was when I poked the Talon and realized that it was burning hot. We were able to quickly replaced the Talon and climb in our final two QF matches.
The post-finals check revealed a possible point of failure. Earlier in the morning, a plastic Versa Planetary encoder stage in the climber had shattered. The stage had simply been removed and the climber returned to normal function. During the process of removing the stage, the actual CTRE encoder had been left attached to the Talon SRX’s data port. The encoder shows visible damage to the circuit board and possible signs of arcing.
A second possibility was identified by the drive team who had been removing the robot from the field. The climber has a ratchet attached, and the drive team removes the robot from the field by releasing the ratchet and gently letting the robot descend to the floor. This means that after every match, the CIM motor was being back driven.
Finally, when we returned home, the Talon SRX was connected to our test board. Immediately when turned on, the PDP started to alternate flashing yellow and red. There was also a clicking noise present. The Talon was disconnected, the flashing stopped, and the clicking ended.
The question we are left with is did the Talon SRX fail because of the damaged encoder, back driving, or another reason?
I think it is unlikely to have been caused by the motor backdriving. That does not usually cause a speed controller failure - otherwise it would be a lot more dangerous to push a robot around the field…
Have you taken apart the Talon to see if there’s any visible damage? Since it doesn’t sound like something you would ever want to use on a robot again, it can’t hurt for troubleshooting.
If you heard a clicking sound with the Talon connected and it stopped when it was disconnected, that is probably a breaker repeatedly tripping. The PDP User Guide doesn’t list flashing yellow and green as an option for the LEDs. Maybe it could be a sticky fault clearing and returning, but that doesn’t sound likely.
You should definitely email prosupport at vexpro.com with the details of the failure and pictures if you have. They always like to see how and why their products fail so they can design them better in the future. They can probably give you a better answer than anyone else on this forum (excluding people on CD who work for Vex). They may even ask you to ship it to them (or bring it to them in person at CMP if you’re going) so they can take a look in person.
EDIT: I said contact Vex but I forgot that Talons are actually made by CTRE (which is weird because I had to go to CTRE’s website to find the PDP User Guide). Their support email is support at ctr-electronics.com
Backdriving the CIM as the robot is lowered can’t generate any more energy than the weight of the robot times the height of the lift, plus perhaps a few more wraps of rope. In any case, it’s nowhere near enough energy to get the motor controller “burning hot”.
The hot controller and clicking PDP both point to a short in the power side of the motor controller. This short causing the arcing in the encoder seems at least as likely as the arcing having caused the short, though I wouldn’t be a bit surprised if both were caused by something else.
CTRE would probably love to hear about this. They are always looking for new failure modes to make stuff more reliable. I recommend shooting them an email.
We just had a SRX that was behaving poorly. It would continually drift when used for position control. CTRE had us try multiple things to resolve it. When we finally swapped it out for another one, it worked perfectly. CTRE immediately issued an RMA so they could run an analysis on it because they had never seen that behavior before. They are shipping us a replacement as well.
Honestly, I wish all vendors gave the same level of support.
One more for contacting CTRE. We recently were testing our arm that grabs gears (which the claw is ran by a Talon) and it ran, then all of a sudden stopped working, lost power to the Talon and we never worked again. We contacted CTRE and they sent us a new Talon to replace the broken one, and had us send the Talon that was broken. No difficulty at all with support. I got back from robotics (11 PM) and sent them an email to follow up, and they sent back within 10 minutes.
