Battery Progressively Dropping

Throughout our matches last week we found issues with the voltage output of our battery. After looking at the logs for the matches we found that the battery itself wasn’t the problem, but our robot was simply not asking for the power it needed and by the end of the match our robot could barely function or was extremely laggy. We tried changing batteries with other teams and we found that our roborio was plugged into the wrong spot, but the problem still seemed to persist. Anybody have any ideas or similar experiences on what could be happening?


We had a very similar problem in our week 2 event at semass. In order to fix this problem, we used software current limiting by using .configPeakCurrentLimit(int); , .configContinuousCurrentLimit(int); and .enableCurrentLimit(boolean);. This will only work if you are using the talonsrxs and falcons.

1 Like

Can you give us an example of what values for the limits you guys used?

What do you mean by these things?

What symptoms made you think it was a voltage issue with your battery, and what in the logs made you think it wasn’t your battery?

What do you mean by this?

Where was it plugged in, and did you actually correct the situation (how)?

1 Like

We found in the logs of the matches that the actual voltage of the battery wasn’t dropping, but there was a drastic decrease in power supplied to the motors by the end so we thought it was something with the PID. I don’t remember exactly how it was configured, but I’ll talk to our tech guy who had it set up tomorrow and get back to you.

If you are using PIDs, did you clear the I accumulator between driving? Maybe the I term is integrating when you don’t expect, dropping the control output.

1 Like

5980’s programmer here. So as @Joebot was saying, I would get back to you guys.

As far as I know, no PID was used at all throughout the entire robot. The drivetrain is controlled via direct (but deadbanded and clipped) percentages from the driver’s controller sticks, all subsystems are controlled using one-time commands bound to button holds, and the only thing that could have possibly used memory was our color sensor (which we disabled but the issue kept happening).

It seemed that, near the end of the match, the RoboRIO slowed it’s sending of CAN data, which was shown by the logs for the matches we had issues with. We had no clue what was causing it until one of the techs helping us randomly noticed that the RoboRIO was plugged into the VRM instead of directly into the PDP, which may have been causing a lack of amperage to the RIO near the end of the match after everything began to warm up.

So, after we swapped the RIO’s power source to what it was supposed to be, the problem seemed to stop. I hope this extra information helps.

1 Like

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