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.
We need more information. It’s all based on the game. Different objectives and motor allotments allow/require different speeds(acceleration vs top speed). That said, 6.1 fps seems awfully slow. I’m pretty sure most teams that do 1 speed gear for something like 10 FPS.
To determine the best gear ratio (if you are using a single gearing), determine how far the average “drive” is going to be.
For instance - the average ‘drive’ in 2010 was much, much shorter than 2011.
Determine a guesstimate of distance for that year. Create a graph of distance over time, and play with your gear ratio to determine the highest ratio you can use that still gets you where you want to go in a reasonable time.
What you will very quickly discover that between 8-15 feet (perhaps the average drive of most games), you can use a very wide range of gear ratios for a very minimal change in time to reach your final point.
There really is an FRC ‘sweet’ spot around 10-12 FPS that works well in nearly every game.
Two speed shifters are a slightly different matter, and that is why teams that use them can go as fast as 14-18 FPS.
Important Questions to frame this problem:
What CoF wheels are you using?
Is 100% of your weight on those wheels?
How many motors in your drivetrain?
Do you want your robot to be able to handle extended (more than 2-3 second) pushing encounters with walls or other robots?
Those who have posted in this thread are correct in that the answer truly depends, but let me attempt to give you a more definitive answer from experience.
For the past three years, we have used a standard toughbox reduction and then chained to the wheel.
In 2011, we used a nearly 1:1 chain to the wheel because of our 4" wheels. This gave us roughly 8 FPS. Here, the robot was strong and fast. The top speed was at a level that the drivers could handle with ease, and to be fair, no one was worried about our speed as our drivers headed out to pick up tubes.
In 2012, we used a 15:22 chain to the wheel because of our 8" wheels.This give us roughly 9 GPS. Here, the robot was also fast and strong, but I cannot recall a time when our robot ever reached top speed.
I’d be lying if I said that we planned for those speeds, but they worked out really well. This year also, if the game is flat-ish, I think we’ll aim for 9.5. If the game requires getting rough with the field, then we’ll push the lower limits of 8, maybe 7.5
Assuming a high traction wheel, a little short of the weight limit, a 6wd style base, and a desire for a single speed that can primarily play offense while occasionally pushing, we’ve used 9-10 FPS for divided games (Breakaway and Rebound Rumble) and 11-12 FPS for full field games. You can’t handle an extended pushing match directly this way, and you aren’t quite as fast as you could be, but you’re plenty fast for a modestly experienced driver to handle.
What good is top speed, if the robot never achieves it?
I pose the question, because speed, traction, and acceleration are a balancing act, and too many people here throw around their theoretical peaks as facts. Thank you for being honest about your robot’s actual performance.
Almost a decade ago, I was working on a collegiate team, making robot soccer players (kaliken from 294, also). These robots were small, but pretty fast. We had geared them with a 9:1 ratio, but never came close to hitting top speed on our field. We changed to a taller ratio (14:1), which should have dropped our top speed by about 35%. Instead, our acceleration greatly improved, as did our achieved top speed. Even better, our motors drew less current and ran cooler, which helped battery life in our 30 minute all-out matches. The drivetrain has to contend with the inertia of the robot, and this is missing from most back of envelope drive calcs.
Back in FIRST, I see too many rookie teams at competition, with low gear ratios, hoping for high speeds. Their robots barely move, and scrubbing in turns causes complete standstill. Many on this forum calculate theoretical speeds, and live with what they have committed themselves to. The best course, if possible, is to do your calculations, but make sure to test several ratios above and below. Pick the one that best suits your robot, and your team’s strategy with the game.
This is exactly why you need to play with your ratios and look at the time it takes to cover distances.
A top speed of 20 feet per second sounds great, but it will obviously take far too long to get to that speed 90% of the time. You’ll be draining your battery because your motors will be working too hard. That’s why shifting is needed to realistically attain that speed.
Of course, JVN made a very good point. We need far more information to quantify this for the OP.
This is a very good point. Look at the time it takes to get from point A to point B. That time will be a combination of acceleration rate and peak speed and you want to find the combination that gets you the lowest time.
You can calculate an acceleration rate and top speed, and draw a curve for the options. Or, you can build a chassis and do some testing with combinations and accurate measures to get “real” data to make your decision. Both are good approaches.
And if you want a decently high speed (maybe 14 fps?), but still want pushing power, this: http://www.andymark.com/ToughBox-p/am-2388.htm should be something to look at.
And for that price, who wouldn’t want one?
Hmm, I don’t know the answer to that first question because honestly we don’t plan to not hit our top speed. If you truly want to optimize your DT, then I’d suggest following Tom’s methods.
Your second point also rings true in many regards, which is why my team has always favored to opt for a slower speed just so we can turn/push our way around the field. However, I think staying between the 7-10 range is probably a good sweet spot to make sure that your robot will at least be able to move.
I don’t even know what our top speed is. Its generally not that important because we don’t spend much time there. For the past two years we have run CIMple boxes with a 10 tooth output sprocket, and 32 tooth sprockets on 6" wheels. I think top speed is around 7 fps (at 4000 rpm CIM speed). I have never found myself wishing we could go faster. Most games are about getting in position to pick up or deposit the game piece. That is all about control. Getting from point A to point B usually involves getting around object C, pushing robot D, or going over obstacle E. None of those involve top speed, but all require torque/acceleration.
top speed isn’t as important as “quickness of a robot” because in most cases a FIRST robot spends most of its time moving in short bursts, not long straights where it has distance to get up to speed. from observation a robot that is “quick” can get up to speed in about 1 to 1.5 “robot lengths”
The original question was about ideal speeds. Perhaps I wasn’t as explicit in my last post as I should have been. The ideal speed depends on the strategy your team decides to pursue. A robot design that attempts to have superlative perormance in all aspects, will rarely perform in any.
Is your strategy to get to the other side of the field ASAP? If so, ideal speed is as fast as your robot can muster. As Tom mentioned, just gearing for a high speed may not be enough to hit a high speed. The fastest may be a moderate speed robot that hits its highest speed by midfield.
If your strategy involves fine control, maneuverability, or pushing, then lower speeds will be of much more benefit. For most past games, torque and it’s matching acceleration has been much more important than speed.
Shifting gearboxes can provide for both speed and acceleration, with the trade of complexity and weight. Shifting is not a realistic option if your robot uses omnidirectional drive or mechanum wheels.
As an aside, the soccer robots I mentioned earlier used omnidirectional wheels, and could pull 1G acceleration in any direction. The same theory applies to omni and mechanum, as regular wheels or tank treads.
In short, we need to see the game, and your team will have to decide which strategy they will focus on. Ideal speed is strategy-specific and robot-specific.
Once the game is released, and your strategy is decided, then it is time to build and test a simple base with your chosen drive type. It doesn’t have to be your final design, just representative enough. Load it up to 120 lbs, and break out the stop watch. Run trials with each gear ratio you can, and see what gives your robot the optimal performance for your chosen strategy.
One last point; if your robot is going to be tall, with a high center of gravity, then make sure you approximate this on your test base. Too much acceleration with a high CG can be very bad. In this case, you may be better with a hi-speed gearing and lethargic acceleration.
I’ll throw some numbers out to quantify this quickly. Hopefully, this is a real eye-opener for teams who have never done the math. This assumes a 4 cim drivetrain. This assumes you are accelerating from a stop. Someone check my math… this was thrown together quickly.
Ratio: 4.2:1
Top Speed: 18.02 fps
Time to cover 10 feet: 1.18
Ratio: 7.1: 1
Top Speed: 10.60
Time to cover 10 feet: 1.20
Ratio: 10:1
Top Speed: 7.51 fps
Time to cover 10 feet: 1.44
Ratio: 12.5:1
Top Speed: 6 fps
Time to cover 10 feet: 1.63
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.
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.
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.
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.
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.
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.