paper: Battery Voltage in Robot Drivetrain Simulation and Modeling

Thread created automatically to discuss a document in CD-Media.

Battery Voltage in Robot Drivetrain Simulation and Modeling
by: apalrd

An example of improper gear ratio selection, and a possible solution to model robot battery voltage to improve simulation accuracy. Also includes my thoughts on drivetrain gear ratio selection.

In this paper, I describe four things:
-The problem faced when choosing the wrong ratio
-Data collected to verify and solve the problem
-Simulation of battery voltage to back up the data
-My thoughts on drivetrain gear ratio selection

I have also attached my modified spreadsheet which models battery voltage. I hope it is useful to you. Credit for the spreadsheet goes to John V-Neun for his excellent 2004 spreadsheet. I just added a little bit.

RobotSimulation-BatteryVoltageModel.xls (2.58 MB)
RobotSimulation-BatteryVoltageModeling_RevB.pdf (72.5 KB)

A few weeks ago, JVN told me I should write a paper on this. So, after promising it to the CD community, I finished collecting all of the log files and assembling the paper. I hope you all like it. Consider it my Christmas present to Chief Delphi forums.

As always, I’m open to questions and comments, and always looking for ways to improve my design methods.

1 Like

Aaaand I shouldn’t post things at 11:30 PM.
The first graph labels are wrong. The orange graph is 2.56:1, the blue graph is 4:1. I’ll update the PDF.


Thanks for putting this together, I was just thinking about this problem, and this is going to be very helpful. This is a very nice Christmas present indeed.


Nice paper! If you look at the battery voltage graph and compare to acceleration you will get an idea on what might be taking place. As the load changes, the current drawn by the motors change, and so to the voltage drop across the internal resistance of the battery. Of course, teams should also be aware that using other motors in the robot (at the same time as driving), also modifies the voltage drops and available current. The length and wire size also have a great effect on the current available to the motors. Longer and smaller diameter wire, adds significant resistance to the individual motors. At 100 amps, #10 wire will drop 0.1 volt per foot. So if the motor is wired with two feet of wire, the drop will be 0.4 volts since you must take into account both the red and black paths. If a team uses #12 for the motor path, double that loss.


Merry Christmas.

I was wondering if your model takes into account gathering a game piece? In a robotic arm application, the manipulator could take a trapezoidal profile to accelerate, cruise at steady speed, and then decelerate to zero speed. This is important because the robot manipulator does not desire to ram into it’s final position and
damage the manipulator. This velocity profile would seem to match a FRC robot obtaining a game piece. Would this change your model characterisitics significantly and hence your ratio match?

BTW, thanks for “thinking out of the box” for your analysis. Off to breakfast.


Thanks so much for posting this technique. I’ve been working a lot this semester on getting a better understanding of drivetrain design. This has definitely furthered my knowledge and I intend to apply this as a part of my ‘lessons learned’.

Again, thanks for sharing!


I eventually measured (sorta) the resistance of a battery using the Battery Beak. It told me the exact battery I measured (plus it’s half of the cable and connector) had an internal resistance of 0.021 ohms. I had already picked 0.03 because that number matched the actual data fairly well. I think the extra 0.009 ohms accounts for some of the voltage drop in electrical components, as we would see ~0.004 ohms from the #10 wire alone (by Al’s numbers). The simulation uses 12v as the base battery voltage, a good moderately charged battery is usually higher also.

Al, at 400a, what are the losses of a #6 vs #4 battery cable? We always keep the length short (never adding length to the 12" COTS cable and using a ~6" wire between Main Breaker and PD), and wondered if switching to #4 on one or both ends would help.

What other ways have people optimization power flow? I remember reading something about Jim Zondag figuring out a way to optimally charge the minibot batteries before matches in 2011 anything like that for standard FRC battery?

What about resistance added by Anderson connectors going to the motors or other quick disconnects?

Any specific type of 10 AWG wire better than others in terms of power loss?

Do these actually make a noticeable difference in performance?

Yes. Solid silver :slight_smile:

We never did a ton of analysis of charging FRC batteries, but we did some for the minibot batteries.

Since the use time was so short, we were trying to push the charge (and surface charge) as high as possible, as quickly before a match as possible (to reduce fade of the surface charge). We ended up with a cycle using 2x RC car battery chargers. One was 115vAC powered, with our battery cart, and would charge it ‘normally’. We would then put the charged battery into the minibot (where it was secured with zip ties), and leave a lone zip tie sticking out and the minibot power switch off to indicate that the battery was disconnected. Before a match, we had another 12vDC powered battery charger (running off a robot battery) which would very rapidly (40s or so) top off the battery at a very high charge current (10a or so), then we would zip tie the battery connection and go onto the field.

We tested the charge profile using a battery discharger (functionality included in one of the RC car battery chargers), to verify the length/current of the top-off charge. It was a fairly time consuming process. Eric Yahrmatter did most of it. We did all of this development mid-comp season, we didn’t use a special charge process at the first two or three competitions, but we did have many batteries and chargers in parallel then.

A cycle like that wouldn’t work nearly as well for normal FRC robots.

Did you run any minibot pole-climbing tests to compare climb times using a given battery fresh off the charger vs the same battery 10 minutes after coming off the charger?

I don’t remember doing any, although I wasn’t working on that project directly. We did a lot of minibot pole tests, and our lead minibot mentor worked on it during the day a lot (he’s good at highly iterative machining projects like that).

I worked pretty closely on this. Yes and no, we iterated the minibot to the point of ridiculousness. Minibots were certainly both run on high and low batteries throughout the course of testing but we were never specifically interested in the difference between the times of minibots other then to tell which was fastest and why. As such we don’t have any of the kind of data that you’re looking for. We knew that a fresh battery couldn’t possibly be less charged then one that had been off the charger for a while so we always made sure that we used a battery straight off the charger. Does 10 minutes of sitting actually reduce the battery voltage any significant amount? Maybe not, but we were squeezing every bit of power out of those motors to make it up the pole in under a second so we did it anyway.

Hope that kind of answers your question.
Regards, Bryan

*Thanks for the detailed explanation Bryan

Assuming that you are talking 12" on both sides of the Anderson connector, the resistance of #6 would be roughly 0.002 ohms. Moving to #4 would cut that in half. So all things being equal, moving to #4, 400 amps would give you another 0.4 volt available at the PD terminals. We choose to trade off the free weight of 12" of battery cable for the slightly higher loss. Then try to keep all wiring short to minimize losses and balance the loads.
I can’t tell you how many teams over the years have come to me trying to make their autonomous run straight. By far most of these teams had several more feet in the wiring feeding one side of the robot then the other side. To all teams, your robot design should try to keep the PD centered in the robot base so that wire runs to drive hardware is short and similar lengths. All other loads are secondary to the drive. The cRio doesn’t care where it is located, neither does the DSC, compressor or other loads. When a team asks if I can determine a problem with their drive, one of the questions will be “how fast did you design your robot to move and does it move as fast you expected?” When the answer is “no, it doesn’t go as fast as we expected” then I look for where the PD is mounted and the length of the wiring to the speed controllers and motors. While mounting to make things pretty is great, it is not always the best choice for electrical losses.

First of all, what a great resource for the CD community! I’m very thankful for the thoughtful research that went into to this paper, and that you released this for everyone to benefit from.

I have a few (scratch that, lots of) questions about your methods and findings.

First, given a desired sprint distance (ie, a distance which high gear is optimized for), how does this translate into an actual distance that we can plug into your calculator? Usually, we want a robot to be stopped, or close to stopped at the end of our sprint distance. If we want to go from stopped to, let’s say 15 feet, you don’t realistically accelerate for all of that distance, so it would be inappropriate to design for the highest speed possible at 15 ft, or lowest time to 15 feet. On the other hand, an FRC robot does not need equal times to accelerate and decelerate (like a spaceship would), so it would be wrong to design around a time to 7.5ft or max speed at 7.5ft. Would you just go with a “medium-ish” guess of acceleration for 12 feet and deceleration for 3 feet? Is there some more analytic way to determine the “max speed distance” given the desired sprint distance?

Second, which do you more design around, time to distance, or time to speed? You mentioned that you wanted time to speed as well as time to distance, so you didn’t end up with a ratio that accelerated too slowly. Does this mean that first find the best gear ratio for time to (sprint) distance, and then check the time to speed to see if it looks OK? Or do you work to optimize time to speed as well as time to distance?

My third question has to do with your battery voltage calculation method. Could you solve for battery voltage with a differential equation, given motor speed and load? Or is your iterative method of calculation a better simulation of the real world? Ie, does current drawn in one microsecond determine battery voltage in the next microsecond (which determines current drawn, and around the cycle goes), or is this just a situation where a calculus approach is just overkill?

First, the design distance (‘Ref Distance’ on the calculator) is used as the time it takes to accelerate to that distance from stopped. I don’t include decel time, just accel time. You would still be moving when you reached that distance. I did not write the majority of the calculator, it’s JVN’s.

Second, Time to Distance. Time to Speed is used to validate acceleration targets, to make sure shorter-distance movements might possibly be acceptable.

Third, this method was the easiest method to implement. It has some noise, especially at the start, so I filter the voltage. It seemed to work well enough.

The reason I calculate it iteratively is because voltage is needed to calculate torque in the mechanical portion of the calculator. So, I calculate voltage from the last iteration current, for use to calculate this iteration’s torque. The voltage change per iteration is so small that I don’t really need immediate accuracy.

Thanks for sharing Andrew. It’s something I’ve never considered in my spreadsheets since it was an unknown assumption. I took my lunch hour and did algebra to come up with a solution for x(t) because the “Battery Voltage Gain Filter” strikes me as wonkish (though that filter is an interesting way to fix the problem). The result was based on some constants that are pre-computed via the motor & robot properties, yet the point is that (luckily) a solution exists for the non-linear differential equation:

Results on Wolfram|Alpha

It’s not exactly pretty, and solving that solution for t (so time can be a function of gear ratio) is causing WolframAlpha to blow up… so more work will have to be done. Yet it does allow for more straightforward calculations of pretty much everything (including voltage) without the need for circularly-dependent equations that need several hundred lines at high resolution to get accurate.

Pretty equations for constants A, B, C, D & E to come tonight or early tomorrow.