# Drive Train Calcs - Not trusting my results

I want to be able to believe the numbers I get when I do drive train calculations. But I think I’m doing something wrong.

Let’s say I’m using 6” wheels and I want to optimize a robot’s gear ratio to travel 15 ft distances as quickly as possible.

What I try:
Plug the numbers into a spreadsheet (JesseK, JVN, etc) and figure out what ratio minimizes the travel time. I also plug them into a spreadsheet that I made that basically traces JVN’s first drive train spreadsheet (my sheet attached below).

What I get:
I find that a ratio of about 7:1, providing a theoretical top speed of about 20 ft/s, gets me there in 1.26 seconds from a stop. This is in a range of gear ratios that get me the approximate shortest sprint time. I plug those numbers into JesseK’s spreadsheet and get a similar time. According to the spreadsheet I made (mostly copying JVN’s original spreadsheet), the robot gets up to around 17 ft/s by the time it crosses the 15 foot line. And according to the numbers in my spreadsheet, it’s traction limited, because the gearbox can provide more force than my maximum tractive force in the first few instants of acceleration.

Those results seem wrong. What gives? I assume that a 20 ft/s drive with a CoF=1.1 is not traction limited, so what did I do wrong? Based on what I just calculated, my design decision would be to completely throw out those numbers and design something that’s perhaps 12-13 ft/s, because based on experience that seems like a nice speed that’s not too fast or too slow. I’d like to figure out what’s going on with my numbers so I don’t have to ignore the math.

Turning
I understand that in the end, the need to turn will constrain me into choosing a slower gear ratio than what I’d choose if I’m only considering sprint time over a certain distance. That means I can forget these problems to some extent. But I still want to understand what’s going on. If I’m designing for a strafe wheel (we may consider this depending on the game), I don’t care about the same sort of turning math anymore. Then I’ll be back to a case when I just want to know what ratio is the fastest over a certain distance. I want to know how the slower acceleration balances out with a faster top speed over a certain distance, and how hard we can push the motors without frying them or tripping breakers.

Speaking of tripping breakers,

Current Constraints?
I am basically ignoring the 40 amp limit, because the motor is going to spike initially anyway and the breakers can handle temporary overages. How should I decide exactly how much I dare to push those current limits? According to my spreadsheet, I’m pulling more than 40 amps for the first 0.70 seconds if I floor it from a stop, including a span of 0.29 seconds over 80 amps. That’s fine, right? The snap action breakers can handle (if I’m looking at the right spec sheet) a 200% overload for approx. 1.5-3.9 seconds, or 300% overload for 0.5-1.1 seconds. How much do I push that? Are there any good rules of thumb for figuring out how much you can push an RS-550 or FP motor?

**Inefficiencies **

Right now I have a 0.85 gearbox efficiency and a 0.93 carpet to wheel efficiency built into the spreadsheet. What other terms eat up power and slow down the robot? I lifted that 0.93 directly from JVN’s spreadsheet, and I have no idea if it’s anywhere close to a realistic number.

Thanks in advance for any guidance you may decide to offer.

When gearing for 15 ft specifically, the “Time to Travel 15ft, vs. Gearing” curve is mostly flat from a ~5.5:1 ratio all the way to a ~9:1 ratio (assuming a 148-lb robot). Then consider that a robot on the field won’t go in a straight line too many times during a match, particularly in elimination matches where there will be plenty of defense to get around.

The same negligibility applies when doing comparative ‘drag race’ graphs. A robot geared 5.5:1 won’t gain any worthwhile distance on a 9:1-geared robot over 15 feet.

One of the big things missing from most of those drive train calculators is electrical resistance. I’m pretty sure most of them assume a constant voltage power supply with superconducting wires. In reality, your battery and your wires have non-zero resistance which limits the maximum current available to your motor to something less than stall current. Sometimes significantly if you’re doing a bad enough job of wiring. See this thread for the glorious details and possibly a better drivetrain model:
paper: Battery Voltage in Robot Drivetrain Simulation and Modeling

Getting a precise measurement for a specified system is all well and good, yet when considering the end results of controllable decisions, the resistance of the battery & wiring doesn’t necessarily effect two outcomes of the same FRC robot differently. Thus can we assume that, given gearing choice A and gearing choice B, the wiring/battery resistance is the same and doesn’t need to be modeled?

Though taking the battery resistance into account would provide better results on modeling systems like rotary arms as they relate to desired performance metrics (current spikes & time of rotation). Thanks for pointing it out Kevin, I hadn’t noticed that spreadsheet.

The voltage drop across a wire (which we can assume is the same resistance, the resistance is a constant) is dependent on current. A different gear ratio would pull a different current over time as it accelerates. So modeling that is good.

The original JVN calc had several battery voltage steps, which gets ‘close enough’. The point is that a battery will drop down to at least 8v or lower during launch, the time it stays low is determined by the gearing and current draw. Essentially, torque = acceleration, a faster gear ratio gets you less total motor torque to the wheels, so you will stay at high torque output longer. Torque is proportional to current, also.

It would be hard to use the battery simulation with mechanisms because the current draw is (comparatively) so low that drivetrain motions would screw up your nice voltage simulation. It could be done, but this would be more an RT software kind of challenge (battery voltage compensation for control loops) then a simulation one. Just assuming you are running under a lower voltage and being pleasantly surprised when the voltage is higher is usually good for mechanisms.

I never even thought of the battery voltage drop. I’ll have to find that math. I’ll add voltage to the spreadsheet. I might have to come back and ask for help on how to estimate that voltage drop, though. It seems like that should help me get a more realistic estimate of how fast the gearing can be while still being traction limited.

Related to post 2, I did notice how flat that curve is for 10-15 ft sprint times. I don’t really understand why anybody would want to be on the fast side of that sweet spot. What is a good reason for gearing it to 17 ft/s when 12 ft/s gets you there just as quickly?

That being said, it is often prudent to do your analysis for a mechanism at a lower than 12V Voltage to see how it may operate. This is especially true for end-game mechanisms as the batteries are often getting tired towards the end of matches.

Battery voltage drop shouldn’t be too difficult. I imagine you take your current you’re running at and multiply it by your battery’s internal resistance, and you end up with the drop in voltage. Say, for example, if you’re pulling 150 Amps and your battery’s internal resistance is 20 mOhms, you’ll have a voltage drop of 3 Volts, so instead of supplying 13V (which seems to be the typical charge at the start of a match), you’re really supplying only 10V.

Don’t “quote” me on that, but I think that’s how the math would work out. Anyone with more authority on the subject care to tear my analysis apart?

btw, my assumption for current is way high, but you get the idea. It comes out to a nice round number

Your current assumption is actually too low. A stalled CIM will draw 100A+ at 12V, assuming no resistance. So a four CIM drivetrain will be trying to suck down 400A or so if you floor it from a dead stop. The only reason it won’t be able to is all the added resistance from the battery, wires, PDB, speed controller, etc.

Well, there you have it. I remember seeing our Battery drop to at least 8.5 Volts, but we had some bad batteries (internal resistance was 35 mOhms), so I guess we were drawing ~240A.

In all of the data logs I took on our 2012 practice robot, a straight-line accel always dropped the battery to 8v on launch. The time under voltage was highly dependent on the gearing and battery state of charge, but the low-voltage peak was always around 8v or lower.

At T0 where v=0, current in a 4-CIM drivetrain would be around 500a or so.

It would be if there were 12 volts at the motors. But not with 8 volts.

The 8 CIM thread got me interested in this again. I had added battery voltage to my calculator earlier in the year without getting it to produce sane results, but today I gave it another run:

Embarrassingly, somehow I missed Andrew’s white paper link in Post #3 when this thread was new. Now that I’ve read that, it’s very helpful to see what he did, and I think I am attempting to do something similar with this spreadsheet, albeit without having voltage data to give me a reality check. Logging some voltages is something I’d really like to do with one of our robots this fall. Knowing that 33’s voltage was consistently dipping below 8 V or so is a really handy thing to know.

I’ll add a quick link to Al’s post from another thread in which he explains how to calculate resistance losses.

As before, my spreadsheet is based on copying the process from the modeling tab in JVN’s 2004 spreadsheet.

I still don’t really trust what the spreadsheet tells me without doing some quantitative tests on actual robots. But the results seem more reasonable than before.

From playing around with this spreadsheet, here are some of the things it tells me based on some of the various inputs I’ve tried:

• 6 CIM drive can do sprints around 10% faster than 4 CIM drive, assuming both drives have gear ratios optimized for sprint speed
• 6 CIM drive can be traction limited at about 3 ft/s faster gearing than an equivalent 4 CIM drive
• If 4 CIM drive drops voltage to 7.8 V, a 6 CIM drive drops it to 6.8 V and an 8 CIM drive drops it to 5.8 V.
• A trio of similar 18 ft/s drives with 4, 6, and 8 CIM’s would initially pull 344, 441, and 514 Amps (it would be academically interesting to see how long one could drive an 8 CIM drive hard without tripping the 120A breaker, wouldn’t it?)
• Adding an extra foot of 12 AWG wire (0.5 ft black + 0.5 ft red) causes a loss of about 1% of a robot’s pushing force.
• Given the same gearing, 2 CIM drives take a significant hit (10-20%) to their spring speeds and a huge hit (30-40%) to their pushing force. No wonder it’s so easy to push 2 CIM robots around.

Those are all pretty interesting to me if they’re true.

Acceleration Spreadsheet Nemo V2.xlsx (118 KB)

Acceleration Spreadsheet Nemo V2.xlsx (118 KB)

It is highly dependent on several factors. Let’s say I assume the following:
CoF = 1.2
Drive efficiency = 0.80
Carpet-wheel efficiency = 0.93
Enough resistance to cause voltage to drop to 7.8 V / 6.7 V for 4/6 CIM drive
Charged battery voltage = 12.8 V

4 CIM is traction limited at about 11 ft/s
6 CIM is traction limited at about 14 ft/s

Change any of the conditions I listed, and you get an appreciable change. I encourage you to download the spreadsheet and start messing with the numbers along the left side.

In practice, we had to gear our drive closer to 9 ft/sec to get the tires to spin from a stop using 4 CIM’s, Versawheels, and 1 stage Vex gearboxes plus a chain stage (we have since gone to ballshifters). I can play with numbers to make the spreadsheet report that 9 ft/s result, but I don’t know which of the factors listed above is off by the most. That’s why I’d like to put together some testing in the fall.

4 CIM traction limit at 17.8 fps
6 CIM traction limit at 26.5 fps

Are you sure you’re not looking at the average speed over distance fields from your spreadsheet? Those actually come close to matching your claims.

For reference, from my own spreadsheet I get:
4 CIM traction limit at 16.4 fps actual speed
6 CIM traction limit at 25 fps actual speed

Comparing both of your spreadsheets, I see that your first one gives different results than the second. This appears to be due to the fact that you use voltage as a variable in determining the gearbox output torque.

However, I have observed robots which experience voltage drops when initially engaging in a pushing match then quickly recover. This would mean that the second spreadsheet would be misleading for determining traction limits because this only considers sprints, assuming that the traction limit occurs during the initial drop while disregarding the recovery of battery voltage during a pushing match.

For example, a robot may drop to 8V when initially engaging in a pushing match, then within half a second rise back up to 11V and remain there for the duration of the pushing match. Therefore, the traction limit should be evaluated at 11V and not 8V.

Seems like hard experimentation should be explored before blindly trusting any of these models.

I certainly wouldn’t argue with your last statement.

The older first spreadsheet doesn’t take voltage drop into account, so the second one should be a better predictive tool. IF there isn’t anything drastically wrong with it.

For a robot’s voltage to increase from 8 V to 11 V, the wheels have to start turning. That can happen if the tires spin or if the other robot decides to go backwards. In a situation in which both robots are stalled at a dead stop while trying to push each other, I care about being traction limited at 8 V. If it’s an option to back up and ram the other robot to develop a bit of wheel speed, or if the other robot might let up for a second to let me gain an inch, then I agree that being traction limited at 11 V could be just fine in those cases.

Did some testing last night. We have a drivetrain which is geared to 8.8 fps in low gear and 22.6 fps in high gear with 4 CIMs. We are using KOP wheels (Andymark says .95-1.0 CoF) and the robot weighs about 145 pounds with battery, bumpers and all. We are aware this gearing is not absolutely ideal, but using 6 in. wheels and looking at COTS options meant we were going for whatever retrofits best to 6 in. wheels out of designs made for 4 in. wheels.

We set the robot up against the wall and drove into it to test our traction limits. Our robot is traction limited in low gear. Didn’t watch the voltage drop in this case since I fully expected it to be traction limited.

The high gear when starting statically was not traction limited. The voltage reading on the driver station dropped just below 8 Volts and then hovered between 7.5 and 8.5 Volts while the robot’s wheels failed to turn.

We then tested dynamically going into the wall such that the wheels would be spinning when we hit the wall in high gear. The observed effect is that we were traction limited in this case. The wheels spun while the robot pushed against the wall not moving. The observed voltage readings were an initial drop below 8 Volts, then a quick recovery to between 9.5 and 11.5 Volts. If you have suggestions for other things to test with this set up I would be glad to give stuff a try.

One thing I have done is use Weighted Objective Tables to evaluate the trade-off between “Time to Distance” and motor/circuit breaker abuse. Basically it’s an objective way of determining which gear ratios are reasonable for a given strategy. If your strategy requires driving long distances across the field often, go with time to travel 25 feet. If the game dictates that the longest distance a team will reasonably be able to travel often in a sprint is 10 feet, use that. Then consider current draw under certain conditions and how long it may take your breakers to trip in the worst case scenario. Weight them accordingly. It’s a good way to objectify this inevitable trade-off in gearing decisions, especially since all of these things are quantifiable with decent models. This can also be used to objectify motor allocation and shifting in addition to gearing choices.