Issues with our Drivetrain

Technical Java
1

Our team is having issues with the Drivetrain. We have a West Coast style drivetrain and it worked for months, we have no clue what changed. Here is some of the troubleshooting methods we have done:

  1. Verify that each motor works.
    With the robot on a stand and wheels clear, we went through each gearbox and disconnected all but one motor on each side from their speed controllers. Each motor was able to drive the gearbox by itself, it appears that all motors are running and there are no electrical disconnects.
    With Digital Multi-Meter, measured resistance across each of the 3 pairs of windings on the motors, all read ~0.3 Ohm. Motors seem to be fine.
  2. Verify that it isn’t a code issue.
    Ran robot with latest code. With current limiting on, it stutters when accelerating. With current limiting off, it also stutters but appears to be browning out (recreating the problem we are trying to solve).
    Loaded an old version of code from AZ East regional, even reverting to the joysticks! Problem persists, it doesn’t appear to be a code issue.
  3. Validation that battery to Power Distribution Panel wiring is solid.
    Noted that the positive terminal of the wiring into the PDP was (every so slightly) loose. Removed terminals from PDP and inspected for arcing, but terminals were clean.
    Suspecting possible main breaker failure, bypassed the main breaker with a new one. Tested again, problem persists, so not the main breaker.
  4. Verify that each motor works under load.
    Reran the individual motor test, but this time under load. With robot on the ground and pushing against an obstacle, the robot is able to slip the wheels on the carpet with a single motor on each side. However, one motor on each side was unable to do so. When testing the suspect motors, the robot is able to drive, but at considerably less power.
    At this point, we have identified one set of motor / speed controller on each side of the robot that is unable to supply full power. If we remove these suspect motors from power, the robot should be able to run??? Conducted another test with the suspect motors disconnected from their speed controllers but all other motors connected. The robot seemed to be running just fine! At this point, we hypothesize that the suspect motor (being in brake mode) is providing excessive resistance to the gearbox when plugged in. Unsure if it’s one bad motor on each side of the robot, or one bad speed controller. Interestingly, it’s the same motor on each side.
  5. Identify suspect speed controllers.
    Plugged into speed controllers via USB-C. Blinked each one to identify which speed controller was suspect on each side of the robot. We found speed controllers 1 and 4 were the suspect ones. This is weird, since they are apparently the lead speed controllers on each side of the robot, while 2 and 3 are following 1, 5 and 6 are following 4.
  6. Change lead speed controllers to verify that 1 and 4 are indeed bad.
    Repeated the single-motor-under-load test after adjusting the lead speed controllers to 2 and 5. Each single motor was able to slip the wheels with the robot pushing against an obstacle. It appears that the issue is gone!
  7. Change lead speed controllers back to 1 and 4 to verify.
    Repeated the single-motor-under-load test after putting the lead speed controllers back to 1 and 4. The issue is gone! This is perplexing, because all of the code is still the same, all of the wiring is the same, and all of the CAN configuration is the same.

However, the day after this the issues came back and here are some notes we took:
We added the speed controller outputs to the SmartDashboard as a graph to compare their outputs.
The left side controllers tend to have outputs that track together fairly well.
The right side followers have wildly different output voltages compared to each other and the right lead controller. The only time they tracked together was when we disconnected the lead speed controller & motor.

Here is the code:
We are currently using the branch: state_champs

Does anyone have any advice or anything we could try doing?

2

From the stuttering motion and the brownout, I’d guess that the motors are fighting each other, so something is wrong with the inversion state. SparkMaxes tend to remember settings from before. I would recommend that you call restoreFactoryDefaults() on each motor controller before applying your other settings.

1 Like
3

Thanks, we tried it but it did not work.

4

We logged what voltages they were receiving and saw this:

5

Voltages
Voltages1489Ă—746 106 KB

6

From looking at the code, I’m thinking that the graphs you’re showing are current in Amperes, not voltage. They do paint an odd picture.

I notice that you’re calling setSmartCurrentLimit(9) on the two leaders, but not the followers. Firstly, 9A seems rather low; from some quick web searches, 30A seems like a common value for teams to use. Secondly, I’m not sure what’s going to happen if the leader has a current limit but the followers don’t. I suggest you try removing or raising that current limit and applying it consistently to all motors.

Another thing you might try, just to see if it makes a difference, is to use MotorControllerGroup instead of leader/follower, as shown in DifferentialDrive (WPILib API 2022.4.1)

2 Likes
7

I recommend using the ILITE drivetrain calculator to find a good current limit for tank drive robots. For 6 NEO like OP, 30A seems like a normal estimate.

My understanding is that the followers output the same voltage as the leader, which is communicated over CAN. My understanding about current limits is that voltage may drop in order to obey the current limit set. I’m not an EE though.

OP, have you tried commenting out everything in code except the drivetrain, just to be sure nothing is interfering? That is, comment out all the non-drivetrain-related subsystems, commands, and button bindings in RobotContainer, then deploy and check the drivetrain behavior.

If you have a battery beak, look for the number labeled “Rint” – that’s your internal resistance of the battery. A higher internal resistance will die faster. If you’re using a battery from 2016 it’s probably just crap.

Also make sure you are not using a dead battery. I’ve wasted several cumulative hours on that over the years. Happens to the best of us.

Actually, re-reading:

Current limit is a sticky setting. That means, when you set it, and turn the robot off and back on, your current limit will be the same. (I should say, I’m mostly confident in this being the case, but there’s a possibility I’m wrong.) If you call setSmartCurrentLimit(9);, you are setting the spark’s current limit to 9A. If you comment it out and re-deploy, your current limit is still 9A.

If you want a functional lack of current limits, you can set it to something dumb like 1000A. But I highly recommend against this. On 6 NEOs, your max is probably 60A, but I’d try 30A or 40A first. Too low of a current limit may result in odd behaviors popping up.

If the current limit algorithm says “whoa, you’re drawing too much current, we need to drop the voltage”, and your voltage is already low (because your current limit is set so low), then it may drop the voltage to zero. In this case, brake mode may kick in, and with 6 NEOs, brake mode is gonna stop that thing on a dime.

Now, note that current limit is not the only sticky setting. Most settings are sticky. That means if you take a spark that was used on a previous robot, the settings will still be there.

In order to avoid confusion like this, I recommend calling mySpark.restoreFactoryDefaults() after initializing each spark. Then you can set all the settings for it - eg a current limit.

I also recommend not doing full brake mode. Try 1 brake mode and 2 coast per side, or 2 brake and 1 coast per side; up to the driver, but I find most like the split compared to full brake mode.

3 Likes
8

Have you tried swapping the connections between the motors and controllers on each side (swap leader motor to follower controller and follower motor to leader controller)? This will confirm that the problem is ithe controllers and not in the motors.

It is highly unlikely that you have a bad motor on each side, in the same position.

1 Like
9

Very that your CAN bus isn’t overloaded and dropping packets. I’d stay far away from 100% loaded by disabling all devices and adding the 2 motors at a time. If a motor controller has no power on it then the motor should be in coast and not make much resistance (pull the breaker; don’t instantiate the object for testing). Bad CAN bus connections can hurt, too, as can missing the termination resistor.

10

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