The Zebra data just indicates the velocities measured not necessarily what they were geared for. 99th percentile of “all velocities above 2ft/s” measured at IRI fell at 12 ft/s. Based on this, I took a broad swing and said for most teams 12 ft/s is a good target default gearing (at least for this year’s 1/2 field game). We did do spot checks on individual robots if we saw something out of the ordinary (6443 hitting >19ft/s @ CC Match 28) to confirm our measurements. I think there was some discussion on there about what gearing would get you to 11/12 ft/s the fastest.
Bumping my previous question/comment since this thread is active again.
The simplest way I can explain this - if the wheels slip under max current limit, then weight is not a factor in determining current draw / current limit.
To demonstrate this, use 4 NEOs on a 140-lb (total weight) robot with a 7.5:1 ratio and a current limit of 30A per motor. I also set the CoF to 1.2 to eliminate wheel slip being the dominant factor at a lighter weight. In this scenario, the wheels do not slip, and we can see the current is limiting acceleration.
Here, the weight is changed to 70lbs total weight with all other parameters equal:
1 Like
First, thank you JesseK for putting together such an awesome simulator/spreadsheet. It clearly was a major undertaking and it’s extremely valuable!
A couple questions:
-
Am I missing something or does it not distinguish between current in the motor windings (motor current) and the current draw of the motor controller (input current)? For example, when a NEO is at stall, 80A of motor current corresponds to only 20-30A of input current. This corresponds to a duty cycle of 25-38%.
-
Where did the formula for “Estimated torque loss from rolling friction” (‘DT Prelim Calcs’!C29) come from? The result is used like a torque but appears to have units of N^(0.5)m instead of Nm.
- It doesn’t distinguish; it is expected that the current limit is a limit on the output of the controller rather than the input. Spark MAX’s case one would set the “Smart” limit, given the following:
SPARK MAX is controlling the NEO and its Smart Current Limit is configured to the desired limit for the test. It is then commanded to go full-power while letting the Smart Current Limit adjust the applied output duty cycle as necessary to keep the phase current at the limit.
- It comes from a proportional estimation of motor torque loss that scales as the drive train approaches maximum speed. At 0 speed there is no rolling friction; at maximum speed, maximum rolling friction is applied. There should be a comment on the cell. There isn’t a scientific way to measure rolling torque loss for every possible drive train setup out there given the types of bearings and wheel/carpet interface. However, this rolling friction loss roughly matches ILITE’s drivetrains from 2016-2019, as well as a few anecdotes I’ve received from teams since launching this spreadsheet. So to me it’s “good enough”.
Got that, but it looks like you are using the motor current to determine the drop in available voltage. It seems like you should be using the input current instead, right? Is that just a known limitation at the moment?
Yeah, I’d seen the comment and understood how it was being used. I was asking about the origin of the formula used to compute the value. If the value was just “0.3 Nm” and you said that seems to match experience, that’d be one thing, but you have a formula and the units of the result don’t look like they would be Nm based on the inputs to the formula, so I’m wondering what’s up with that formula.
Hope that makes sense.
For NEOs, perhaps. For other motor controllers, particularly those used by lower-resource teams, not necessarily. The spreadsheet doesn’t go to that level of granularity of incorporating duty cycle interpolation per controller (due to sheer calculation volume), and errors on the side of conservative for system voltage drop as a result. Since the system voltage drops 100% flag the 6-CIM and 8x775PRO issues seen before the BLDC days, I consider this one ‘good enough’ as well.
The units are correct; the formula seems fine to me.
The 2020 preview is available, by the way:
Ok. Thanks for clarifying. Would you consider accepting a contribution that adds the functionality I’m describing? If so, in what form would you prefer such a contribution? Collaborating on a spreadsheet can be tricky.
Aha! The formula is fixed in the 2020 preview. I was looking at v2019.2 linked at the top of this thread which used the formula:
=((1-C20)*4.448222*SUM($'Drive Train'.$G$26:$G$27)/$C$21*$C$19*E35 + $'Drive Train'.G26/120*C7*E35*C19)^0.5
which seems to have units of (Nm)^0.5.
The new formula:
=((1-C26)*4.448222*SUM($'Drive Train'.$F$25:$F$26) / (4.448222*SUM($'Drive Train'.$F$25:$F$26)))*C12
has units of Nm and seems totally reasonable. Fwiw, it looks like that new formula can be simplified to just:
=(1-C26)*C12.
1 Like
Generally, yes. However, it would be more about taking an example and incorporating it based upon a backlog of priorities. Right now the priority is documentation for 2020.
I try to balance the priorities based upon how teams use the spreadsheet and how complex or computation-intensive some of the feature requests are. The intent is to provide a simulator of drivetrain trade offs, in a form that can be opened on almost any school computer.
If we are using the velocity mode on the Talons to control our speed, would we want to set the deceleration to “reverse” in that case?
@JesseK can you add a “stalled pushing force” result somewhere? I find we have to compromise between pushing force against defense (either stalling the motors at the current limit, or slipping the wheels) and “Time to Goal” when choosing a single speed ratio for longer sprints. It would be nice to have that parameter front and center.
[edit] - also it would be nice if the “KOP Drivetrain” tab pulled the same robot and field characteristics as the main “Drivetrain” Tab, so you can compare.
2 Likes
Overall though, the sensitivity (trade-off) curves are so useful, and a huge contribution to FRC. They basically show that the gear ratio can be off by +/- ~10% from the optimal and not make much difference. They also show that 10:1 overall ratio is pretty close to optimal for a full weight robot on 6", COF 1.0 wheels, doing 15-20 ft sprints, regardless of the motor (although maybe a bit more ratio for the Falcons, since they have a higher free speed). Thank you again for this insight!
1 Like
Yes, with the caveat that since ramp rate impacts acceleration during teleop control, you’ll also want to set the ramp rate to match what you’ve set on the Talon (if you’ve set it). This is an excellent point and I’ll add a note to document it.
I’ll think this through a bit - I believe there is a “maximum tractive force” embedded in the calculations, so it should be easy to add. I didn’t add it to the tradeoffs graph directly since it makes assumptions about what the robot pushes against For example, 4 Falcons pushing 70lbs of batteries across a carpet would be very different from the same robot pushing 70lbs of a robot sideways, depending on what wheels the “defender” had.
For 1712, the most accurate modelling of our PID would be somewhere between break and reverse. I suspect this is true for most PID velocity controls.
The effect of that pushing will be different, but the force applied by the drivetrain to the carpet would be the same no? So knowing the maximum force would be good for comparing between drivetrain designs.
1 Like
I’d be more inclined to have a feature that displays how much current is drawn when the wheels break free of the carpet.
You can intuit this by playing with the current limits until they appear/disappear, but I would love for it to be more easily available.
2 Likes
So I downloaded this but I have absolutely no clue how to use it. I can see where I can input values and I can see the results but I don’t know what any of it means. Is there a tutorial on how to use this cause that would be really helpful.
1 Like
I don’t know of any tutorial for it. If you could tell us what you are trying to find with the simulator, it would be easier to help. it would take a while to explain all of the graphs and outputs.
Nothing in particular, I’m trying to figure out how it works and what all the graphs and what not mean.
I agree that this calculator would benefit from a “how-to” sheet. It took me looking at the sheet five or six times to roughly figure it out. A couple of the parameters are also slightly ambiguous IMO.
If this is included in future versions that would be awesome. @JesseK
I don’t have it open so this is from memory. But (IIRC) I start by entering the “numbers” of the gearing and drivetrain and the then look at basic characteristics before the advanced ones.