WPILib Profiled PID Controller failure causing motor output to stick

We were tuning our arm joints’ Profiled PID Controllers and going between two setpoints repeatedly, and after doing this several times the robot collided with itself. I was graphing the motor outputs for the two joint motors to help tune, and this is what I saw. At the end the motor output flatlines, sticking to a constant speed for both joints. Here is a screenshot of the plot:
image
The code that caused this can be found here: GitHub - FRCTeam3255/2023_Robot_Code at 2ef0929842213d2917e368f6e6e437e6fbbdc107 (linking to the specific commit since it’s obviously under development). The only (intentional) inputs were A, B, X, and Y on the conOperator controller.

This issue is extremely concerning, and though I am fairly certain it was our fault, nothing seems like an obvious cause. Has anyone had this issue before? What steps should we take to insure this will never happen again?

So one thing I see is that your MoveArm command’s end() function calls neutralOutputs which (eventually) calls CANSparkMax.stopMotor(). That function appears to be undocumented so I’m not sure what exactly it does, but it might not zero the percent output? (at least not the value read back, but you’re saying it physically crashed as well as showing up in telemetry that way?)

1 Like

Thank you, I’ll change this to set zero percent output.

Edit: Reading the CANSparkMax implementation, it appears that stop motor does just set(0)

  @Override
  public void stopMotor() {
    throwIfClosed();
    set(0);
  }

Update: I think this happened maybe 4 or 5 more times since the original post. I can’t be entirely sure since I wasn’t graphing the motor output but the outcome was the same. The arm joints fly past the setpoints and past the soft stops. Somehow we avoided major damage every time.

We decided to switch our arm motors from NEOs to Falcons (for packaging reasons mainly) and haven’t had this issue since. This might not be entirely fair since some other code changed that could make a difference, and we also haven’t used it for nearly as long, so since the issue is so infrequent it might not have had time to happen yet.

I will update again if the issue happens again.

1 Like

We discovered an issue with our main breaker. The insulation on the wire running from the main breaker rubbed off and made contact with the bolt that secured the main breaker to the robot frame. This was likely the cause of the issue in the original post. This issue also caused the death of several Spark Maxes (including the ones that had the issue). This wiring mistake caused many other random issues.

Lessons learned:

  • Ensure that the robot frame is isolated from the battery BEFORE turning on the robot.
  • Double and triple check the core electrical components BEFORE installing them on the robot.
    • We grabbed this main breaker from a bin of old breakers because we didn’t want to prepare a new one.
    • We should have thoroughly checked that wiring on the breaker was still good.
1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.