paper: MINIBOT acceleration solution

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

MINIBOT acceleration solution
by: Ether

Solution to the differential equation for the acceleration of a direct-drive (shaft-drive) MINIBOT up the pole. Rotor+shaft inertia is ignored. Friction is assumed to be speed-independent.

Friction is probably a significant factor in the MINIBOT, so this model’s accuracy will be limited by the accuracy of the friction estimate used. It will give some insight and guidance however, and may be of interest to physics and math students.

See the discussion thread for this paper for ideas on how to measure your MINIBOT’s friction. A proposed method is given for analyzing video data to extract a friction measurement.

2011-03-19c variables.txt (678 Bytes)
2011-03-19d accel_soln.pdf (13.1 KB)
2011-03-20f solution implemented in (18.5 KB)
2011-03-21 friction study data (15.3 KB)
2011-03-22 DE solution with (17.2 KB)

Great stuff! I was a bit disconcerted that it indicated that our minibot should be twice as fast as we are measuring and it instigated us to try to determine the largest factor not accounted for by your model.

I’m coming to the POV that it is probably rolling resistance.

(force friction) = (normal force) * ( the horizontal distance representing the wheel deformation) / (undeformed radius of the wheel)

We are going to try more rigid wheels with less deformation (thinner tubing)

The normal force is approximately twice the minibot weight and the deformation impacts two wheels, and the radius is very small for direct drive.

I’m curious if others with direct drive and small diameter wheels might have similar issues or have already figured out how to get results that match Ether’s fine model.

Ether, what would it take to get you to come over here and join my team? :smiley: You mathematical contributions to the Chief Delphi forums this season have been fantastic.

Regarding your model, and the (neglected) friction, I’ve learned it does play a BIG factor. Tonight I did some testing and visually saw much longer acceleration times than your model predicts. Anyhow, your previous calculations inspired me to try out a few things of my own, so last night and this morning I built up a minibot with the following specs:

~2.6-2.7 lbs
2 motors, direct drive
0.42 inch rollers
Approximately 6.5lbs normal force to the pole (magnets).
Mostly charged battery (had been charging for an hour or two) measuring 14.5 Volts when pulled off the charger.

I have friction in bushings supporting the end of the rollers, and friction of a limit switch against the pole. My best time was 1.6 seconds.

One thing I found interesting was that on a battery which measured 11.98 Volts (no load), the minibot didn’t have enough force to accelerate itself at all. On this rather dead battery, with a thumb on one roller (for as long and hard as I could without burning myself), battery voltage was dropping to 9.5ish under load. So, the lesson here is that if your minibot battery measures 12 Volts, it’s dead.

I predict the teams on Einstein will have their deployments perfected, and the winner will be the team who can get their minibot the lightest, and tuned to operate at its peak performance point.

Thanks for the kind words, but I’m an East Coast / Midwest kinda guy. Although I did take a business trip to San Diego 25 or so years ago and the weather was amazing. And the San Diego Zoo & Wild Animal Park is among the best in the country.

I’ve updated the spreadsheet to allow the user to enter a friction estimate. I’ve also derated the motor performance somewhat; the rationale for that is included in the ZIP file. Since friction does play a large role, the value you enter will have a substantial affect on the model prediction, so it’s important to try to get a reasonable estimate. I’m pondering ways to do this.

One thought is to push (with a small postal scale) or pull (with a small fish scale) the unpowered MINIBOT at a constant speed up the pole with and measure the force, then subtract the weight. This may be difficult to do accurately.

Or, make a pole with a reasonably friction-free pulley at the top. Run a lightweight but strong line (perhaps fishing line) from the MINIBOT over the pulley, and on the other end hang weights until the MINIBOT will just barely continue to climb when given a slight push. The difference in weights should be an approximation of the rolling friction. Make sure the MINIBOT motors are open-circuit (not shorted) during this test.


Thanks for the update.

I used 7400 for freewheel speed based on Richard’s dynamometer results and then I adjusted the friction number until it approximately matches the video evidence of our minibot…
it predicts 2 lbs of friction!!

I’ll try some experiments the week with a weight scale and the pole.

The other thing we might try is a time measurement of a distance measured freefall of the unbraked minibot on the pole as compare it to the speed of freefall without a pole and consider the difference to be the loss of acceleration due to friction. (I like pulling out my 400 fps camera).

I also started toying with the idea of tweaking your model to compare a rampbot to a vertical bot. I haven’t got it quite figured out yet.


Here’s another idea for measuring MINIBOT rolling friction.

Release the bot from the top of the pole and time (with a stopwatch) how fast it takes to fall a distance X. Do this several times and average the results, throwing away any outliers. Make sure the motor leads are open-circuit, not shorted.

Then use this formula to calculate the friction force:

f = w - 2*X*M/(t^2)

f is friction force in Newtons

w is MINIBOT weight in Newtons

M is the mass of the MINIBOT in kilograms

t is the average time in seconds

X is the distance it fell in meters

For beginning physics students:

The above formula comes directly from F=M*a, assuming constant applied force:

F = M*a

(w-f) = M*a

a = (w-f)/M

v = integral(a*dt) = a*t = (w-f)/M*t  (assuming V = 0 at start)

x = integral(v*dt) = integral(a*t*dt) = (1/2)*a*t^2 (assuming x=0 at start)

x= (1/2)*(w-f)/M]*t^2

solve for f to get the formula


Our letters crossed in the mail. I was writing up my post when you were posting yours I guess. I’m going to leave it because it’s slightly different from what you suggested.


Did you use .09 or .094 for the stall torque?

If you use .094 then a straight line from 7400 free rpm to .094 Nm stall will give a max power of 18.2 watts. I think that’s a bit optimistic.

If you use .09 then it’s 17.4 watts, which matches the upper curve in Richard’s data.

Since it appears there may be some significant variation in the motors, I selected freeSpeed and stallTorque values for the spreadsheet which give 16.8 watts, to make the numbers a bit more conservative. But of course YMMV.

“Make sure the motor leads are open-circuit, not shorted.”

If you do… make sure you have created a method of slowing down your minibot before it crashes to pieces on the tower platform…:yikes:

“Did you use .09 or .094 for the stall torque?”

I used .09.

I usually don’t trust the stopwatch for such a short race- too easy to have hidden bias.

A basic 30 fps video camera is easy to get stop and start points estimated to within 30-60 ms based on multiple playbacks and just counting time by single stepping through frames.
And the data is all recorded so someone else can check the calculation.

YMMV… If we can get within 15-25%, I would be VERY happy.

Thanks, Ether, for providing this… The students will have fun with this one.
We are working in New Hampshire…

I noticed you are retired and in “US”, which FRC teams did you use to work with?

The longer I thought about this, the more I liked it :slight_smile:

I put together a proposed method for analyzing this kind of video data to gain a more accurate characterization of the friction. Right now the acceleration model supports only constant (velocity-independent) friction. But what if the friction is a strong function of velocity?

The proposed analysis shows how to take the distance vs time data from the video and extract from it a 2nd-order polynomial function of friction vs velocity.

If anyone actually runs a video test and analyzes the data, would you share the results with me? If the friction varies strongly with velocity I may be able to modify the acceleration model to reflect that.

If you have data but don’t wish to do the analysis, I’d be glad to do it for you and sent you the results.


If only these equations didn’t require some backwards-thinking Lambert-W function to solve them for [t]. Ether, would it be possible to use your equation-solving software to do so? Wolfram-Alpha keeps putting the Lambert-W function in the results and I can’t find a generic approximation that doesn’t spiral out of control. nsolve should work in Mathematica, but on WolframAlpha it’s just like solve.

Minor ramblings…

Last night I found the Newtonian approximation (uses Newton’s method) for solving the Lambert-W. [result] = W(z) is the notation, and z is given via solving x(t) for t. Turns out, for a small enough z (|z| < 0.01 in most cases) Newton’s method converges to the correct answer (with w0=0) in 1 iteration. The answer is … get this … z. Since our z is exp(-B^2*x/D), and B^2/D is LARGE, making the *denominator of z HUGE, the Lambert evaluation = exp(-B^2x/D). It typically mucks up when there’s too much weight, way more motors than needed, or ridiculously improperly geared (making z > 0.01).

Maybe I’ll update my tools post-season. Really the only thing that’s useful from it is to see the time to goal as a function of Gearing, so a very close gearing estimation can be made for exactly how a team wants to play the game. It may be useful to generate a set of bounds for software since PWM output correlates directly to the power of a motor. In the direct-drive minibot’s case, t is a function of 2 major variables – diameter and weight (assuming constant friction that decreases available torque) – so finding the optimal diameter for a weight would be easy if it were set up.

Oh, and to relate the equations to drive train (no minibot), replace “weight” with "weightsin(theta)" where theta is the angle of the ramp to climb in radians. Theta = 0 for a flat surface. This explains a minor flaw in the direct t=aI rotary equations I was using that prevents me from even attempting to do ramp calculations.

Still working on a way to at least characterize friction. The chart shows a theoretical climb of 1.6 seconds for our minibot, yet the reality is about 2.6. Really it’s a question of whether friction robs the robot of acceleration torque, maximum speed, or both (and if both, what proportions?).


The desired engineering result for LogoMotion is to find the shaftDiameter which minimizes the time required to reach a specified height x. This can be done by using numerical methods on the solution x=f(time,shaftDiameter) presented in the paper. In the example spreadsheet, Excel’s “Solver” does this quite easily with just a few iterations. A macro could be written to do the iterations, but it’s almost as easy to adjust the shaftDiameter manually to converge on a close-enough solution.

A proposed method for characterizing friction is presented here. If anyone runs the test and finds that friction vs velocity is strongly nonlinear, then it would be worthwhile to explore finding solutions to the resulting nonlinear DE.


We set up a camera today. The yard stick was not in perfect position so I had to estimate some of the distances,
The times were 29 frames/sec on an MPEG4 camera.
(Dartfish software licensed to us free last year would have estimated all the measurements automatically-I miss it.)

time (sec) Distance(m)
0 0
0.034483 0.00635
0.068966 0.01524
0.103448 0.03175
0.137931 0.0508
0.172414 0.0762
0.206897 0.1016
0.241379 0.13208
0.275862 0.1651
0.310345 0.2032
0.344828 0.24765
0.37931 0.29845
0.413793 0.3556
0.448276 0.4191
0.482759 0.4826
0.517241 0.5588
0.551724 0.635
0.586207 0.7112

2.3 lb direct drive minibot

Your tool estimates about 6-10 Newtons of force without much velocity sensitivity if I plugged it in properly.

We may decide to try lo lower the normal force and measure again.

Thanks for posting this. Very interesting!

See attached screenshot. The friction has a lot of “noise” (to be expected) but it appears to be independent of velocity. So I fit a least-squares line instead of a quadratic. I’d say the friction is darn close to 6 Newtons.

Arghh. Won’t let me attach screenshot. I’m going to upload it with the paper attachments.

OK, here’s a link to the screenshot:

Thanks Again!

We’ve been doing more testing to analyze the model accuracy.
I think the largest remaining error is the phenomena of sliding friction that occurs when the power is first applied.
The model suggest that the robot should move its first half inch within 0.05 seconds of applying the power.
We see it taking about .3 seconds based on video analysis.

It’s approximately 0.2-0.3 seconds whether we turn the motors on after the mininbot is attached to the pole or if we start the motors up prior to attaching to the pole.

After accounting for the time of this initial sliding friction, the model you produced accurately predicts the measured time of our minibot!
I’d be curious if anyone else would be willing to share their results.

I would think a ramp bot could be better able to minimize this initial sliding friction and also immediately start doing “work” (some of which that will be turned into vertical momentum) as soon as it turns on. The pole bot has to wait until it reaches the pole to have any of its work being used for creating vertical momentum, Thus, I’m a firm believer that theoretically, a ramp bot can obtain a better time than a pole bot.

Good catch. I was thinking about that just the other day. The model assumes there is enough friction between the “wheel” (drive shaft) and the pole so that the wheel never slips. But if your shaft diameter is small enough and your normal force isn’t high enough, the stall torque of the Tetrix can “burn rubber” (like a dragster). The model does not account for this. I could add another user input: coefficient of friction, and include that to model wheel slip. But not only would that number be fuzzy (so many factors can cause it to vary), it would also make the system nonlinear and not solvable analytically. Numerical methods would have to be used. Of course, once you say goodbye to the analytical solution and start using numerical methods, you can introduce all sorts of clever nonlinear refinements. Maybe a fun project for the off season.


It is important to have the wheel slip modeled if you want to get the optimum wheel radius and normal force. I have done the modeling a couple of times… once for my own excel dynamic model and I also posted the numerical solver as a modified version of Team 1640 Drivetrain model on my blog here for others to use.
This has the spec motor curves built in but by playing with the parameters, you can easily make it look like the dyno model.

I measured the coefficient of drag as .22 for our minibot model using a high speed camera and a drop test. The coefficient of drag is defined as Drag_force/Normal_force. This model used Tetrix kit bearings. Typically the friction force is 6 to 7 newtons for our 2.5lb minibot. We always measure it with a newton scale prior to each run.

A excellent approximation to the climb time can be made by using your variable definitions.

The steady state climb speed v_ss = D/B (should be the same as peak_pwr/W)
System time constant tau = 1/B
Dist = pole height.
time_to_climb = Dist/v_ss + tau

This falls out of the exponential solution when the time > 5 tau which is typically the case for the minibot. To include the effects of drag… simply replace W with W + Drag.

Glad to see you are spending some time to document the physics for others. I have been a little lax this year on my posts.

We finished our last regional and did not implement our secret weapon:
(although we did tell the Boston Regional judges about it)
Rubber on rubber (1.2 CoF sliding friction) for the first 3 inches of vertical climb before switching to rubber to steel (0.3-0.6 CoF sliding friction).
We projected that would save us 0.2 to 0.3 seconds and still keep normal force low.

The rubber on rubber is minibot to hostbot ramp that runs vertically parallel to the tower pole and then switches onto the pole before the minibot crosses the 18" line.