# paper: Drivetrain Acceleration Model

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

Drivetrain Acceleration Model
by: Ether

_

updated C code which includes motor voltage drops due to circuit resistance

Derivation of Voltage Drop Model

PDF Drivetrain Acceleration
[/b]
_

Drivetrain acceleration model with loss of traction (wheel slip), motor voltage drop due circuit resistance, accel based on reduced-voltage motor curves, and torque-dependent, speed-dependent, and constant friction losses.

Full C source code.

2nd-order numerical integration using Heunās Method.

CSV output file can be directly imported into Excel for graphing acceleration, speed, distance, motor amps, and motor voltage vs time.

drivetrain accel h6 RevB.pdf (20 KB)
drivetrain accel h7.zip (5.43 KB)
drivetrain accel h7.xls (141 KB)
20130924_2231.zip (6.65 KB)
drivetrain accel RevC.pdf (22.4 KB)
voltage drop model rev E.pdf (46 KB)
drivetrainModel_20131218.zip (63.5 KB)

Very cool. Now if only we could convince you to use variable names longer than 2 characters

Am I correct in assuming that Tm = Ts*(1-V/Vfree); on line 55 could also be used to figure out approximate current draw? Or am I over simplifying this?

1 Like

Yes. Kt, the motor torque constant, is Newton_meters per amp. So you can calculate the motor amps A=Tm/Kt*. For a CIM, Ktā0.018 Nm/A. You could modify the C code to output amps so it could be plotted.

However, the model does not account for voltage drops due to heavy currents through the wires, the wire connection points, the batteryā s internal resistance, changes in motor resistance due to temperature, etc so the accuracy of Tm (and the current) will be affected. Also, Kt is not strictly constant - it varies somewhat with motor temperature.

Very cool. Now if only we could convince you to use variable names longer than 2 characters

Iāve been programming since 1969 and Iāve never liked long variable names. To me it makes the code much less readable. I like the code to look like the way I would write the equations. I know opinions differ on this matter.

• when not slipping. when slipping, youād have to use the kinetic friction force and back-calculate the motor torque.

So, close enough for determining if itās bad or not but not close enough to be an āaccurate modelā.

Twas just a joke, I know the equations look like this but Iāve always found annotating them with english names helped me understand what was going on. Course, that was the second thing I did with this (first was read what heun integration was). Thanks for sharing this.

This is cool. I wouldnāt have looked up Heunās method if I hadnāt seen this thing. I also wouldnāt have looked up rolling resistance. This white paper has given me some homework. Hopefully I can include those two things into the calculator Iāve been playing with. Thanks very much for posting goodies like this.

*I posted an update/correction to the C code:

• fixed an error in the English-to-SI conversion constants

• modified the accel function to better reflect the relationship between friction and rolling resistance

• added total drive motor amps to output

Canāt look at this in-depth right nowā¦ but thank you very much for another great resource! This looks quite usefulā¦ particularly if k1, k2, and k3 are given real, semi-accurate values (not just assumptions)!

Dangit man, I just finished converting to coffeescript and started putting a front end on it! Mind posting your diffs?

http://bl.ocks.org/schreiaj/raw/6604718/7bbf83cd0195ef2dc3b0244c446a78a8c98eda1b/ Itās still missing the axis so itās kinda useless to get numbers out of but Iāll post the updated version tonight once I get the axis un-inverted.

Current coffeescript port available at https://gist.github.com/schreiaj/6604718/7bbf83cd0195ef2dc3b0244c446a78a8c98eda1b/

Thereās a CSdiff report in the posted ZIP file that contains the revised C code

Thanks, Iāll get those integrated sometime in the near future.

Iāve got visitors coming over in 15 minutes.

Later this evening Iāll strip out all the non-functional changes and give you a report of the minimum changes needed.

Itās not a lot, once I get rid of the non-functional changes.

Thanks for doing this. Iām hoping your user-friendly interface will generate more interest and technical discussion, and maybe even inspire teams to conduct tests and make their data available.

Hereās the updated version (havenāt put your code changes in yet) but I did make it a little easier to read.

http://bl.ocks.org/schreiaj/raw/6604718/81de5905aa072e9666bee0c0e8f06fc207f7a970/

Thanks for putting this together.

I put together this āDrag Estimatorā for my HS supermileage team years ago. It is based off of the Empirical rolling resistance and wind resistance test given in the Bosch automotive handbook.

For rolling resistance, this gives a constant coefficient and a v^2 coefficient.

Iām glad you brought this up.

I structured the code to make it very simple to change the rolling resistance model if you want to. It takes only 2 keystrokes to change the rolling resistance model from
L = Kro+KrvV; (line #68 in the 9/19/2013_1112a code)
to
L = Kro+Krv
V*V;

In fact, you could make the rolling resistance any function of V, or even use a look-up table if you have experimental data.

However, I think the V*V term only comes into play due to air resistance at speeds much higher than FRC robot speeds. It would be enlightening to see some actual data of rolling resistance vs speed for a typical FRC robot (with drivetrain mechanically disengaged from wheels) on FRC carpet surface.

Umā¦ ā^ā is xor in C.

Someone slipped into excel mode in the middle of a line of C.

Actually**ā¦**
Octave, Maxima, SciLab, AWK, and RLaB

Which is still less weird than the weird case of coffeescript that I found while porting this by accidentā¦

Turns out āvariable *ā compiles to āvariable * variableā as opposed to throwing a compile error.

Thereās a small error in the build 9/19/2013_1112a code.

At line 75, āA4/10" should be "An/10ā.