Taming a rogue drivetrain (TalonSRX, CANbus)

Hi CD,

We are in the middle of teasing out a fascinating bug in our drive system.

At Utah, our driver reported the robot “continuing to move” - or the drive “sticking”. It was minor enough that we couldn’t tease it out in the pits.

In the lab, we’ve successfully replicated it on the practice bot.

If our students hit the limits of the joysticks in quick succession - so either double tap forwards, or backwards, or forwards then backwards - then the drive “sticks” at 100% going in the second direction.

*EDIT: Inputting an additional throttle command stops the motor. This I assume is how we overcame issues at Utah.
As you might expect, it’s a terrifying failure mode. E-stops don’t remove momentum from the robot… so we’ve replicated on a crate, and again with a different motor.

Our hardware:
-Logitech controller
-Dell Latitude programming laptop
-RoboRIO, fresh, this year’s firmware
-TalonSRX, firmware 3.8 / new Lifeboat, (current limits 0 & 120max/25continuous)
-Seven Talons & four VictorSPX on the CANbus, along with the standard VRM, PCM, etc.
-3 mini-CIM drivetrain

We have
-Changed the joysticks (twice)
-Changed the motor
-Reset the TalonSRX to factory defaults
-Re-installed the 3.8 firmware

What am I forgetting?

What do we need to plot on SmartDashboard to be able to tease out what is happening here? I’m thinking we need the joystick throttle input, commanded motor power, and actual current consumption (from the PDP) displayed next to each other while we attempt to replicate it?

Our code is here:

We use a stripped-down version of Cheesy Drive / arcade drive.

Any help is deeply appreciated
-one very confused Mechanical mentor

Try removing your current limits and instead trying more sensitive limits from your driver

we had some interesting drive behavior consistent with your symptoms when trying current limiting/ramp rate, but found them inconsistent and hard to reproduce controllably. Found solution by zeroing out settings one by one.

Are you aware of this issue? https://github.com/CrossTheRoadElec/Phoenix-Documentation#motor-output-direction-is-incorrect-or-accelerates-when-current-limit-is-enabled

I really don’t want to do this, our drivetrain sizing was done with the expectation we could lay down a current limit to protect ourselves from brownout stall conditions. Will try if Joe’s solution doesn’t work.

No, I wasn’t! Sounds like our symptom. We’ll add that line tonight.

Was calling _tal.configPeakCurrentDuration(kPeakTimeMs, 10) always in the manual? The manual is dated 1/13, but I don’t remember seeing that line when we were configuring our current limits for the first time in late January. Omar only added it to the Java example in GitHub around 2/18-2/20, which was around when the Phoenix release came out.

…What is that “10” in the command, then? My understanding of the command in January was that the “10” was the current duration…

The timeout duration.

You need to be careful with those timeouts cascading if you’re using an Iterative robot. Too many of them failing will put you outside the 20ms default timing window.

If you give it a ‘0’ in the final argument, the code will try to set the value and return immediately independent of success. If you give it a non-zero timeout value then the command blocks and returns an error code after the specified timeout.