Arrgggg Stupid Fisher Price Motors

[Adam Y.]

Does anyone have the actual information or information they used for the Fisher Price motors that were in last years kit? The information from first seems to oddly enough to go against each other from what I can gather.

[AdamT]

Well, if it helps, you don't need those spec this year because if I remember correctly, FIRST said we aren't getting them year...

[Adam Y.]

Nah Im just really curious because the maximum pushing force I'm getting for last years robot doesn't make sense.

[sanddrag]

www.team696.org/motorspecs.html

[Adam Y.]

Grrr Im confused. Can an robot move if its weight is more than maximum force available with the motors??? Maybee I didn't do the gear ratios correctly.

[evulish]

But you use more than one motor, usually...correct?

(I have no idea if that meant anything...I don't know much about motors and such :))

[f22flyboy]

Atwoods! Atwoods! yaaaay! yaaaay!


I apologize for my impulsive stupidity

[Matt Reiland]

The torque available from the wheels will fully depend on the Gear Ratio and the diameter of the wheel. So yes the robot should move even if it is very very heavy if the motors are geared down low enough

[Paul Copioli]

O.K. guys, here it is one last time. The attached spreadsheet is from the engineers at Johnson electric. Here are a few key points:

1. The 2002 FP motor is NOT the same as the previous years. It is made by Johnson Electric, while 2001 was made by Mabuchi.

2. The free speed of the Johnson electric motor is 20,326 RPM and
the Stall torque is 0.514 N-m at 12 volts. The stall amps are
109.4 and the free amps are 2.735.

3. The FP part number is 74290-9539 and is from the Harley Davidson Power Wheels vehicle. Use this number when ordering extra motors.

4. I have verified that the information given to me by Johnson Electric is correct.

Sandrag,

I looked on the web page you posted and the info is incorrect. The info on that web page shows the specs for the Mabuchi motor.

-Paul

EDIT - The file is too big and I can't upload it. Please search to find my old post. The file is attached in that post.

[Adam Y.]

Thanks:). I thought for a second I was going nuts or that our robot was actually defying the laws of physics.
But you use more than one motor, usually...correct?
Errr I thought that is if you combine two motors for each side of the drivetrain thus giving the combined power of both.
The torque available from the wheels will fully depend on the Gear Ratio and the diameter of the wheel. So yes the robot should move even if it is very very heavy if the motors are geared down low enough
I knew that but logic would dictate that the robot wouldn't move if your power at the wheels is less than the robots weight. The problem wasn't the fact that my math wasn't correct but it was that the motors wern't the right one.

[Paul Copioli]

Wysiwyg,

I just to make sure you understand the relationship between weight and the force needed to propel your robot.

F=ma right? Right. However, the largest determination in how your robot will behave is friction in your drivetrain. The actual equation I use is:
F(at wheels) = m(130lbs or 59 kg) * a + Ff(friction)

An easy way to determine Ff is to take your motors off, but leave the transmissions and pull the robot at a constant speed with a spring scale. I usually add 10% and use that.

F=Tout / Rwheel and Tout = Tmotor * GR * eff

Tout is the torque output of your drivetrain
Rwheel is your wheel radius (not diameter)
Tmotor is motor torque
GR is your gear ratio (usually > 1)
eff is your drivetrain efficiency (0.70 < eff < 0.95)

In DC motors there exists a speed-Torque relationship as follows:

Tmotor = K*Smotor + Tstall

K is the slope of the Torque - Speed curve of the motor (negative)
Smotor is the motor speed
Tstall is the stall torque of the motor
Please watch your units!!

Putting it all together:

(K*Smotor+Tstall) * GR * eff / Rwheel = M * a + Ff


'a' is the time rate of change of speed of the robot, Vout and if you take small time increments the formula for a at any instance of time 'i" is:

a_i = (Vout_i - Vout_i-1)/(t_i - t_i-1)
to shorten the notation we will use a=dVout/dt

Sout is the ROTATIONAL speed of the wheels and is related to Vout using the following equation:

Vout = Sout * Rwheel,

so the equation is a = Rwheel *dSout/dt

Remember that Smotor is related to Sout by the relationship:

Smotor = Sout * GR

Again, putting it all together:

(K*Sout*GR+Tstall)*GR*eff/Rwheel = M*Rwheel*dSout/dt +Ff

You can solve this for Sout at any instance in time, i, and put it into a spreadsheet formula and get robot speed vs. time for various wheel and gear ratio combinations. The final spreadsheet equation using 'i' as the time right now and 'i-1' as the previous time (use a time step between 0.01 and 0.1 seconds) time step is notated as 'dt':

Sout_i = (Tstall*GR*eff*dt + M*Rwheel*Sout_i-1 - Ff*dt) / BIG Y

BIG Y = M*Rwheel - (K*GR^2*eff*dt/Rwheel)

The equation seems long, but it is pretty straightforward. If you use a spreadsheet and use initial conditions at t=0 if Sout=0, you can solve for Sout at each time increment and can figure out how long it will take you to get to max speed.

I haven't checked my notes, but this looks right. I will double check tonight.

I hope this helps.

Paul

[Dave_222]

We smoked ours to the point that it smells just to go near it at ramp riot! we let all of the magic smoke out.

[Adam Y.]

Yeah I know that I really did this quickly. All I found is that the maximum force the robot would produce if the thing was stalled which is the maximum force that youll get out of that thing ever. Which is why I started worrying when my math started getting the maximum stall force lower than our robots weight which would mean it wouldn't move right??? Thank you for the equations. I printed them out.:) Doh..... I made a booboo. Ft pounds is the wheels radius but the radius was six inches. I think I have it 334 pounds of force at the situation where the motor is stalled. Oddly enough we had problems destroying the gearbox of our motors last year. The mounts would strip clear of our robot.

[Paul Copioli]

The MAXIMUM force your robot can put out is:

Fmax = Mu * Weight

Mu is the static coefficient of friction

Weight is the weight of your robot plus any other weight transfered to your robot.

Experimenting with treads that increase your coeficient of friction is well worth the effort. Determining Mu is really easy.

Mu = tan (Theta), where Theta is the angle of a platform with respect to ground.

Take your robot from last year and lock out the wheels. Lift a platform until the robot starts to slip. Measure the angle and take the tangent .... poof! you have Mu. Since Mu DOES NOT depend on weight, you can make a simple test fixture to test out different materials.

Just as an interesting point, if you could have traction even when the platform was at 90 degrees to ground you would have an infinite Mu.

Paul

[Lloyd Burns]

To reexamine your basics from another point of view, think hovercraft: once they have a full skirt of air, any force will accelerate them, however slowly - did you ever see the flea circus film in which a flea is harnessed to a CO2 airpuck ... and the flea moves the puck, many times its mass !?!?!

[Adam Y.]

Errr Im taking physics right now and I just realized that there isn't really any force of friction in a hovercraft. Of course now your giving me interesting applications for the using this knowledge.

[Al Skierkiewicz]

Without going into any detail over the technical discussion so far, all holds if you are trying to drive up an incline at 90 degrees. So your calculations are very likely correct. When running on a level surface the power needed to move a robot is reduced with friction being the greatest force preventing movement. The friction comes together as the sum of the drive train friction, (which is minimally affected by robot weight with the use of bearings to transfer the robot weight to wheel shafts) and the wheel to surface friction which is affected by robot weight and floor matierial. All of the forces are still present but change dominance depending on the attitude of the robot. The power required for movement is that which is needed to overcome the sum of the frictions plus a little extra to get the mass in motion. Someone explained it to me as to why a 20,000 lb aircraft can get off the ground with only a 10,000 lb. thrust engine. You are not trying to drive the plane straight up, just to get up enough speed to let lift take over and you are flying.
Remember that many robots were able to design lift mechanisms a few short years ago when the competition demanded it so there must be ways of designing a mechanism to lift 130 lb.
Good Luck All
P.S. This is just an explanation from an electrical guy.

[Paul Copioli]

Al,

I'm assuming your response was regarding my calculations. My last post was only to clear up what many already know. If you design your robot to put out 100lbs of force per wheel and your coeficient of friction between your wheels and the floor is not high enough; then you will be wasting output power, becasue your wheels will spin. I also noticed my 2 posts were confusing if read one after another. The friction I was talking about in my first long post is drivetrain friction (as you mentioned, too) and the friction in my last post was friction between the carpet and wheels which provides tractive force (or the force to propel). Bottom line:

A drag racer can have all the output torque in the World, but it does no good on ice.

-Paul

[Adam Y.]

becasue your wheels will spin.
Spinning wheels=good depending on how you look at it. Last year our robot got into a pushing match with another robot but ending up winning(of course our robot still lost:rolleyes:) the pushing match because our wheels would slip while the other teams destroyed there motors because of too much traction.

[Paul Copioli]

I guess it all depends on your point of view. From where I am standing, if you design your drive train to have enough friction at 30 amps per motor (but no more), then you will not fry your motors. You should never be in a situation to have too much traction (or not enough torque).

-Paul

[Al Skierkiewicz]

Paul,
I was suppporting your claims without having gone through the math. As an electrical guy I was just trying to express my way of looking at the premise that would make sense to someone who wasn't following the math. But the friction we are talking about has another side and that being, if you were trying to drive through a different surface, mud for instance, the rolling friction is very high and therefore requires more driving force. (soft tires on carpet would be the same type of rolling friction)
However, limiting to 30 amps on the drive motor would not get you going. I was experimenting with a bare, in my hand FP motor, on a hard regulated supply capable of 25 amps continuous and kept shutting the supply down just trying to get the motor to turn. Instantaneous current is very high on this motor and when in a drive train may actually exceed 100 amps in real world starting conditions.

[Paul Copioli]

Al (and others reading this),

I agree with you 100% with regards to the starting current instantaneously going up to over 100 amps on many motors (FP and Drill included). The point I am trying to make here is to NOT DESIGN your robots pushing torque at a current draw over 30 amps per motor. If you do, and you get in a pushing match, chances are you will trip those annoying little resettable breakers. I have seen over the years (and I'm sure you have too), many teams pick a design torque at max power which is usually at 50 - 60 amps or higher (for FP, drill, and Chiphua) only to see their breakers keep tripping during long pushing matches. I am trying to save some rookies the agony of a trippy robot drive system.

-Paul

[Al Skierkiewicz]

Paul,
No arguement there. We limit our power curves in software and hardware so that we can go "turbo" when needed for a specific task without hitting breaker reset.
AL

[kmcclary]

Originally posted by Al Skierkiewicz
Paul,
No argument there. We limit our power curves in software and hardware so that we can go "turbo" when needed for a specific task without hitting breaker reset.
AL Hey Al...

What's your method of limiting the power curve in software? What's your sensing and control hardware for this (ex: current sensors of some kind feeding back to RC's digital or analog inputs)?

I'd love to see your setup. Can you describe the architecture and code?

- Keith

[Al Skierkiewicz]

Keith,
We haven't used feedback to limit control at this point. The software just scales back during normal operation and goes to full control when a button on the joystick is pressed. Our "turbo" button is just used on drive control when we want to get somewhere in a hurry. We have used this method for a few years now. When we have used the drill motors for driving with the attached transmission, we lock the speed shifter into one speed only with a couple of tywraps so it can't bump out of engagement.
The gear ratios are chosen for optimum torque at the lower speed and are obviously different for the FP motors or the drill motors.
Al
P.S. Although we have considered using our current sense to control software we think it needs a little more work so that the drivers are not confused by the action of the software. Practice, practice, practice is the key.

[kmcclary]

Originally posted by Al Skierkiewicz
Keith,
We haven't used feedback to limit control at this point. The software just scales back during normal operation and goes to full control when a button on the joystick is pressed. Our "turbo" button is just used on drive control when we want to get somewhere in a hurry. [...] The gear ratios are chosen for optimum torque at the lower speed and are obviously different for the FP motors or the drill motors.
Al So are you saying you'd do something like this:
- Set up the gear ratio of a drivetrain motor to be (for example) "60A max before tire breakaway"
- Full joystick push now outputs only a 50% duty cycle PWM signal in each direction (30A limit)
- When you hit the "turbo" button, it would then jump to 100% duty cycle in each direction.

If not, then what exactly are you doing?

Originally posted by Al Skierkiewicz P.S. Although we have considered using our current sense to control software we think it needs a little more work so that the drivers are not confused by the action of the software. Practice, practice, practice is the key. You're right... You have to have a LOT of practice time reserved if your program tries to "autopilot" things like speed ramping, or it'll be immediately compensated for by the driver who doesn't expect it.

Man oh man we had a LOT of trouble last year on my previous team with the driver "overriding" the software filtering. <chuckle> Whatever the programmer tried, the driver would adapt to it... Asking him not to do that didn't matter. He wasn't even conscious of this reaction. Deep down inside he expected a certain behavior from the robot, and by golly his unconscious body's behavior with the controls was going to make it happen that way! :)

When the driver started gripping the joysticks at their BASE with a thumb and forefinger, and started slamming them full in each direction, we gave up! We tore all the filter code out, and simply asked the driver to "PLEASE don't ask the machine to reverse too quickly or you'll blow the breakers"... :)

What the heck... Although a little jerky at times, the robot ran just fine, and admittedly the code was shorter. :)

- Keith

[Al Skierkiewicz]

Keith,
I am not sure exactly what the numbers were. (I'll leave that up to the software guys.) I think it was closer to 70%/100% though. The turbo mode was only intended to be used in low current manuvers like open field running, diving for the goals from dead start etc. I will try to have our driver explain it better.
Al

[kmcclary]

OK...

BTW: Am I correct in my description of your approach, or are you doing it a completely different way? (Set up the drivetrain to be TOO strong, cut the "full scale" PWM level back to compensate until "turbo" button hit, and no feedback sensing whatsoever from the motors?)

- Keith

[patrickrd]

Originally posted by Paul Copioli
Mu DOES NOT depend on weight

That's not entirely accurate, but usually a good simplification to make ;)

If your wheels are spiked or is made of material that digs into the carpet at all, instead of rubbing against it, the F=mu*N approximation becomes less and less accurate. In reality, as you increase N, mu becomes less and less to some asymptote. According to my experiments anyway :)

[Paul Copioli]

Patrick,

Your experiments must have some other variables coming into play. Mu is a constant of proportionality as defined by experiments. Its purpose is to show the relationship between "relatively flat" objects sliding against one another. When you have spikes or other geometry such that you have many such defineable surfaces in many orientations, Mu no longer holds true. I agree with you that Mu has its limitations, but Mu does not change with respect to weight.

-Paul

[Matt Attallah]

[puts on flame suit]

But, rember, that the carpet isn't considered a "Solid"

start the flaming! :D

[Paul Copioli]

Close Enouuuuuuugh!!

(Reference Labatt's Blue T.V. comercial)

[AllenH]

Hi all. Driver from Wildstang Here.

So there's a topic about the "turbo" control on our robots. It's nothing complicated, like a tranny or anything. It's all based on software.

How I operate it: I press the top button the joysticks to activate it. In doing so, on last years robot, it does two things: One, the "Turbo" button increase our power to the motor (Full value on the speed controller and pwm output), from 50% to 100%. Another nice feature it enabled was the DISABLING of the 4wheel quad turn. Instead of turning the front wheels about 45 degrees of the center plane, and rear, -45 degrees, it actually kept the rears straight and only the fronts turned.

We had to do this because the control of our robot was so sensitive to high speed manipulation, the slightest jerk would mess up our shot at a "one hit wonder" to the first goal.

However, once we obtained one or two goals, it was only good to use turbo when crabing and going straight. If I needed to turn slightly, it was better to take advantage of the slow, but more powerful quad turn.

I hope that settle some things!!


Allen
Wildstand driver/electrical student leader
111

[Al Skierkiewicz]

Keith,
I asked our mech engineer to give an answer on design criteria vs motor specs. Our driver gave a good description of operation above.