Paper: ILITE Drive Train Simulator, v2019

ILITE-DriveTrainSimulator - v2019.2.xlsx (1.6 MB)

Prior Versions

ILITE-DriveTrainSimulator - v2019.1.xlsx (1.7 MB)

This is an updated drive train calculator that puts emphasis on time rather than maximum speed.

Input a target motor, number of motors, gearing, and a wide range of elements about the drive train and electrical system. The output at the bottom shows estimated peak speed, estimated sprint time, minimum system voltage, and maximum voltage while the drive train is at full speed.

  • NEW Now includes the NEO motor with a stall torque of 2.585 Nm and stall current of 105A. Note that minor variations in this stall torque do not really impact the final measurements of sprint time.
  • NEW Select a deceleration model to simulate a full trapezoidal profile of a sprint, start to finish. Never forget, what speeds up must also slow down!
  • Improved voltage ramp and current limiting models
  • NEW Extra output fields within the print boundaries for those who want to calculate their own items based upon the simulator results
  • NEW Includes rudimentary traction limiting on the acceleration model
  • The distance vs time chart now also shows indicator lines for whether the drive train is traction or current limited.
  • Charts that show impacts of varying gear ratios on sprint time, battery usage, and turning efficiency
  • Want to see the effects of Voltage Ramp or Current Limiting on your final sprint time? No problem! Input those parameters into the electrical system
  • Updated acknowledgements! If you would like to learn more, it is easy to go straight to the pros!

Features for the future:

  • Updated wheel slip to account for kinetic CoF
  • Updated current modeling to account for lower current draw during wheel slip
  • Add a graph line for “time to full stop” on the existing “time to target” graphs
  • Re-orient motor cells on the prelim calcs tab to account for copy/paste into those cells directly from the motors tab

What is your NEO data based off of?

Exciting to see traction limiting included in this simulator. It was one of the few calculations I turned to other sources to perform in the past couple years.

It is based off of the Kt rating in Richard Wallace’s tests with a controller cut-off of 100A.

1 Like

Very cool!

I’m interested in comparing your drivetrain time-to-distance calculator to mine (based off Ether’s White Paper). One of the first things I see is that you only ask for the static CoF for the wheels. How do you calculate acceleration when slipping without the kinetic CoF?

I hope to do a deeper dive into your calculations in the next few days to see how they compare to Ether’s. I will probably have some more questions then. If you have any information about how you developed your simulator or have the calculations in a more readable format than excel formulas, I’d love to see them.

Great question, and the answer is simple: I don’t.

This decision was for simplicity’s sake given the limited time I could put into iterating on the spreadsheet from last year. I’ll definitely note this for next year though.

I just ran some numbers in this to compare it to my new dynamic simulator (my new one is still rough, but I promise to release it eventually). I got the same results, given the same inputs. Good job!

I have a slight difference in the handling of slipping. Although you should not design for this to happen (and should lower the current limit down to the traction limit point), you still correctly model the loss of traction (and acceleration), but the motor current stays high. If you calculate the motor current/torque from the actual tractive force (limited by traction) then your currents/voltages will be a bit more reasonable. This doesn’t change the distance, but does change the power consumption and potentially min voltage. It’s still not technically correct, since the motor speed will be higher than modeled, but it’s closer.

I did notice that my name is wrong though, you credited me as Brian Palardy. It’s actually Andrew Palardy, and Bryan Culver. Thanks for the credit though, I appreciate it.


Thanks for the feedback Andrew!

I will definitely correct the names.

Thanks! This looks very useful and is working great in Excel. Has anyone succeeded in using this in any freely available spreadsheet programs? Our school doesn’t have MS Office.

In Google sheets, the drop-downs work but it is missing most of the chart output.

In LibreOffice Calc the charts look great, but none of the dropdowns work!

Is there anything I can configure to get these to work better, or do I need to use my own Excel account when we are working with these?

There are tradeoffs between accessibility, version control, tool features, and of course expense, when creating complicated tools like this.

If you take the motor specs from the ‘Motors’ tab, and copy them to ‘DT-Prelim Calcs’ cells B6-B9, then LibreOffice should work better for you. In next year’s iteration, I’ll make this copy/paste a little easier by re-orienting those cells on that tab.

One thing I’ve noticed is that on the Movement Characteristics graph, the simulations of the current limits kicking in don’t seem to be directly impacted by a robot’s weight. While the acceleration peak(s) move along the time axis as the weight is adjusted (and the current limit indications move with them), the presence or absence of current limits do not seem to change as I adjust the robot’s weight. Obviously a lighter robot is going to demand less current from its drive motors, so there should be thresholds in which these current limits are not presence when a robot’s weight is reduced and appear as the weight is increased.

One thing I’m noticing is that all of the deceleration options kick in after the robot reaches its target. While that’s obviously easier to program, I wonder if there isn’t a way to get at least a rough prediction of when to start decelerating so that the robot will stop at the right distance. Obviously on the field this is what drivers are doing in their head, so that’s really the time-to-distance measurement we care about when deciding on a drivetrain configuration.

If you could then plot this against the various gear ratio options that would be amazing. But even just putting it in the main simulation would let the user figure out the optimal gear ratio manually.

Edit: Can you also explain how your braking and reverse acceleration models work? I’ve yet to find a good way to model motor braking using the 4 motor constants we generally use in FRC. Also it seems that the reverse mode doesn’t respect the motor current limits or bus voltage (but I could be interpreting the equations wrong).

Edit 2: It also seems like there is sometimes a problem with stopping after deceleration is finished. It looks like this could be solved by making “is finished decelerating” sticky (must stay true once it ever gets triggered).

1 Like

I’ll explain the intent of the deceleration model, with an understanding that there could be a bug or two in it.

  1. Upon hitting the target distance, the deceleration model kicks in.
    1.1 If deceleration is “coast”, a nominal friction force is applied
    1.2 If deceleration is “brake”, then a deceleration force is applied that is the “coast” friction + a torque proportional to the current running through the motor at the time
    1.3 If “reverse” is applied, then (iirc) a constant deceleration torque is applied to the motor that is not proportional to the current running through the motor at the time. In 2017, where often is was easier to to a full-reversal rather than rotate 180 into the airship, this mode is very applicable.

Again, since the deceleration graph data is “close enough” to the brilliantly-executed experiments from 234, I’d consider the simulation accuracy “good enough” for design work.

Since deceleration is still finicky and manual, and users sometimes want to assume the robot is at full speed at the target distance, perhaps it is better to give a time & distance to full stop as an output? I may also be able to add this time to the current time-to-distance vs gear ratio chart.

I used this spreadsheet last night to encourage discussion about sprint distances, and understanding acceleration vs top speed, and being able to visualize varying numbers and types of motors. I think it went reasonably well, so thanks for the great resources!

Couple of questions that came up:

  • Is total number of motors the number of motors in gearbox? Or on Robot? If we select Neo + MiniCim, and have 1 neo and 1 miniCIM on each gearbox, should we select 2 for total number of motors?

I also noticed that the Distance in the movement characteristics chart seems to overshoot, am I missing something as to why that is? The parameters that are in the spreadsheet when I download it are a sprint distance of 20 ft, but the movement characteristics have it go to 27 ft.

is wheel base length the distance between the center and corner wheels in a typical 6WD w/ a center drop?

1 Like

I love this spreadsheet and this type of modeling, but my biggest concern is that the results don’t seem to square with the practical results that we’ve seen in the field. The biggest question that teams are usually aiming to answer with a spreadsheet like this is “given a sprint distance of X, what gear ratio should I use?” Time-to-distance modelers always seem to select free speeds that are substantially higher than what teams have shown on the field to be optimized.

As an example, given a 6 NEO drivetrain with 4" wheels making the ~12ft sprint from the loading station to the rocket, the spreadsheet shows that a ~5:1 ratio is optimal for an adjusted free speed of 17.7 ft/s. However, collective CD wisdom and the new Zebra data says that the fastest cyclers were geared closer to 12 or 11 ft/s. In order to get this sheet to spit out 8:1 as a target ratio (11.9 ft/s), you feed in a sprint distance all the way down to about 3 feet.

So, where is the discrepancy? I have a few theories.

1. I’m using this tool wrong. This is the most likely answer. Someone correct me please.
2. Friction is a larger factor that anticipated. If friction is robbing us of a substantial amount of torque that isn’t being modeled for, then the model will give us data that’s off. However, some empirical testing could probably tell us if it’s off by a predictable amount, which could be included in a future version of this or other calculators.
3. Robots aren’t driving straight from the loading station to the rocket. Defense is such a factor this year that a robot’s true sprint distance isn’t 12 feet, but 3.
4. There is an error in the calculator. I don’t think this is it, but humans are fallible. I’ve seen a few sprint speed calculators, and all of them returned higher target speeds than “common knowledge” dictates.
5. “Common knowledge” is wrong. It’s possible that we’ve been taking the wrong lessons from on on-field experiences and our implicit biases are leading us astray. Humans are fallible.


Edit: Maybe this post should be a comparison between the data coming out of the Zebra thread, and the data coming out of this spreadsheet. Generally speaking the advice from the Zebra thread says that you should gear below 12, pretty much always. Sprint distance calculators tend to recommend 16 ft/s and up from my experience. What’s the disconnect between those two?

Were they geared closer to that, or were they spending more time at those speeds?

EDIT I need to go read the Zebra thread in more depth but can’t do it right now; my instinct is this isn’t directly supported but I owe you a stronger analysis to raise the level of discourse in this thread.


Ooh, good catch. I’ll do some digging there as well.

Edit: for anyone playing the home game, here is the link to the drivetrain speed conversation.

1 Like

We use the calculator internally and arrived at a free speed around 12-13FPS for 6 miniCIMs on a loading station to rocket sprint. I’ll see if I can replicate our input values and post them.

You’re on the right track in how you’re using the tool; I don’t think you’re using it incorrectly. Keep in mind that the tool presents more information than just a “minimum time to target” graph.
Evidence of the conventional FRC wisdom is available in the other factors that the graph presents, such as the voltage response and the velocity profiles for both acceleration / deceleration.

For example, the under-torqued flag isn’t red in this case because the distance to accelerate is actually just under the threshold of the target distance - robot length. Looking at other factors, the tool also shows a velocity profile which looks more like a wave rather than a typical trapezoid.

Here is ILITE’s 2019 Drive Train design. As @Knufire mentioned, we started with a 6 flipped MiniCIM setup. Over the course of the season we switched to NEOs, and (for now) expect to continue in that direction for 2020. In Detroit, we were able to hit 15 game pieces with this setup. It was also somewhat able to slip through defense.

1 Like

@ahartnet Sorry I missed your questions! Here are the responses:

Is total number of motors the number of motors in gearbox? Or on Robot? If we select Neo + MiniCim, and have 1 neo and 1 miniCIM on each gearbox, should we select 2 for total number of motors?
That number represents the total number of motors across all gearboxes. For the combo “motors” you would enter 2. For a 6-NEO drive (with 3 per gearbox), you would enter 6.

I also noticed that the Distance in the movement characteristics chart seems to overshoot, am I missing something as to why that is? The parameters that are in the spreadsheet when I download it are a sprint distance of 20 ft, but the movement characteristics have it go to 27 ft.
The distance chart includes overshoot due to deceleration. The “time to target” and “sprint distance” all assume the robot is at max speed at the target distance. I added an extra deceleration curve to determine what it would take to stop a robot, and how much further the robot would travel under different deceleration models.

Since simulation of multiple trapezoids for a target distance is pretty difficult (most notable, determining appropriate distance at max speed in order to stop at just the right distance) I opted to keep this as an add-on for the main graph rather than (poorly) attempt to simulate profiles across multiple gear ratios. I’ll take a look at this again for 2020, but no promises.

is wheel base length the distance between the center and corner wheels in a typical 6WD w/ a center drop?
The wheelbase is the front-rear distance between the 4 wheels that touch the ground at any given time. If it is a 8WD where all wheels touch the floor at all times, then the appropriate thing to enter would be the wheel base relative to the outer-most wheel. Yet for 6WD drop-center, it is the distance from the middle wheel to an outer wheel.

Additional Notes for 2020:

  • Add deceleration battery usage to total battery usage
  • Make max-speed threshold more conservative
  • Add a tab which captures the KOP graphs for reference
1 Like

I’m trying to figure out if we have ours straight too. 1293 went Mini CIMs, geared 7.31:1 in our 3CIM4U (into an otherwise-stock wide AM14U4). We ballparked a 15-foot sprint for the cargo ship, but it felt like 7.31 gearing yielded either the right answer or something in the ballpark at 10, 20, and 25 feet too.

We were frequently outrunning defenders, most of them presumably on stock 4-CIM-10.71-geared AM14U4 setups, though 6894 did have our number in the THOR West semis. So I’m pretty darn happy with what we had, but I know there’s always a next level.