Ideal robot speed

[Levansic]

Tom,

What size wheels are your numbers from, and what speed are you using for the CIMs?

My calcs, using the free speed of CIMs, suggest that you are using 3.3" wheels, which doesn't feel right. I have never seen anything close to the published free speed of the CIM motors, when attached to unloaded gearboxes. Too much friction.

[Tristan Lall]

Originally Posted by Tom Line

The difference between an 18 fps drivetrain (no shifting) and a 6 fps drivetrain over 10 feet is about .4 seconds. Shifting introduces another variable, but you can see where I'm going with this. Erring for a higher gear ratio will rarely leave you disappointed. Due to acceleration timing, a top speed of 10.6 fps is only .02 seconds slower than an 18 fps over 10 feet without shifting.

In fact, over 10 feet a robot geared for 18 fps will only hit about 15 fps.

This segways into a very interesting argument about when you should design for shifters.

There's another question implicit here: are teams interested in long-distance sprints? Ever since we went to the rectangular field (the short 48 ft field in 2000, and the long 54 ft field in 2003), most games have had common, reasonable strategies that involve a sprint of 30 ft or more, with modest arc and elevation changes. (2001, 2007, 2010 and 2012 are the biggest exceptions.)

2008 is the canonical example, since cycle time was the only critical factor for the lap-bots. 2011 was another game where cycle time was critical, and speed in the open was available.

Another valuable aspect of speed in the open is building momentum for defence. Sometimes a pushing match isn't necessary—hitting the opponent out of position at the right moment is frequently a good strategy. It's a minimal demand on your gameplay time, with a large effect on the opposition. (2003 was the canonical example of this, but it was handy in all of the games that didn't have safe zones for scoring robots, 2004 in particular.)

Also, position denial is an effective form of defence. In 2010, being a fraction of a second faster than your opponent side-to-side between the goals would have been enough to stop them from kicking a ball past you (even given drivers' reaction times).

More generally, FRC robots have a hard time pushing while twisting—so get parallel to your opponent, and hold them against the wall by keeping pace with them. That requires you to be as fast as the expected opponent, but not much else. For that reason, it's a good, simple way for the robots lacking manipulators to operate effectively—and might be a good reason for them to err a little higher on the speed spectrum. In this case, the fact that the acceleration from rest is so closely matched actually favours the defender, because he can easily keep alongside a robot geared lower, while still being able to execute the same maneoeuvre against faster opponents.

[Tristan Lall]

One more detail: when making comparisons, we need to distinguish between the theoretical top speed (i.e. proportional to motor free speed), and the actual top speed when the motor is operating at a particular load condition.

The voltage will vary depending on state of charge and current demanded (i.e. load), and speed varies with voltage.

Oftentimes, we'll talk about the theoretical free speed of the drivetrain at 12 V (because it's straightforward to calculate), but for actual modelling of the gameplay, it's worth considering the real speed of the robot under game conditions.

[Lil' Lavery]

In my entire time in FRC, I can only recall of two matches where I had the thought "boy, I wish we had a higher top speed." Once was in 2009, when the robot we were supposed to be harassing and scoring out was outrunning us the entire match and we couldn't do anything about it*. The other was in 2010 when there was a defensive robot who could get across the field faster than we could, which made it very difficult to score on them. Usually my regrets over design choices stem from somewhere else, even within the drivetrain.

*Worth noting that robot eventually ended up on Einstein.

[Tom Line]

Originally Posted by Levansic

Tom,

What size wheels are your numbers from, and what speed are you using for the CIMs?

My calcs, using the free speed of CIMs, suggest that you are using 3.3" wheels, which doesn't feel right. I have never seen anything close to the published free speed of the CIM motors, when attached to unloaded gearboxes. Too much friction.

4 inch wheels. Stage 1 reduction 12:50, stage 2 reduction 10:XXXX, where XXXX is varied to obtain the final max FPS.

You cannot use the free-speed of the cims. My calculations include drivetrain efficiency and a speed-loss constant that is empirically determined. Grab JVN's design calculators. I've been puttering around combining the old motor-specs excel sheet with JVN's calculator so that acceleration, distance and time can be easily calculated for drive trains, arms, etc.

[Ether]

Here's an analytical solution to a DE approximation of the accelerating vehicle time-to-distance problem.

Has something like this already been posted to CD somewhere? If not, I'd appreciate if someone would vet it. Then I'll clean it up and post it.

[Levansic]

It's been a while since I've had to use diff. eqs., but your solution looks correct to me.

The only thing I caught that may lead to confusion here is the missing note that S in eq. 9 is in units of radians per second, not rpm, as most published specs for motors list. If it were changed to rpm, then The second parenthetical term would be (pi*d) instead of (d/2).

[=Martin=Taylor=]

Originally Posted by ferrari77

Assuming the the field is divided into two like Rebound Rumble what would be an ideal speed for a robot?

Right now we are looking at 6.1 ft/s according to JVN's design calculator but this could be 8.13 ft/s if a 32 instead of 24 tooth pulley is used on the gearbox

We are only going to have one speed but could potentially have a software limited slow speed for precise movements and aligning.

Where can I download the JVN calculator?

I searched all of JVN's paper uploads and I don't see it. It didn't "disappear" did it?

[Ether]

Originally Posted by =Martin=Taylor=

Where can I download the JVN calculator?

I searched all of JVN's paper uploads and I don't see it. It didn't "disappear" did it?

JVN's Mechanical Design Calculator

http://www.chiefdelphi.com/media/papers/2059 (2008-2011 versions)

http://www.chiefdelphi.com/media/papers/1469 (2004 version)

[billbo911]

Originally Posted by Ether

JVN's Mechanical Design Calculator

http://www.chiefdelphi.com/media/papers/2059 (2008-2011 versions)

http://www.chiefdelphi.com/media/papers/1469 (2004 version)

I've found that having both the 2004 version and a current version really help in demonstrating the results of different design choices. Or to say it another way, it really helps when making a design choice.

The 2004 version is not quite as clean, but that drawback actually allows you to see "behind the curtain", so to speak, in how the resultant data is generated.

[Ether]

Originally Posted by Levansic

It's been a while since I've had to use diff. eqs., but your solution looks correct to me.

Thanks for giving it a look.

The only thing I caught that may lead to confusion here is the missing note that S in eq. 9 is in units of radians per second, not rpm, as most published specs for motors list.

Actually, the missing note was that all units are assumed to be SI :-)

For those allergic to SI, attached is an example of a choice of a consistent non-metric system of units for this problem.