There are some things in code that you can also do to help your drivers. You can help your drivers drive straight by making sure both sides of the drivetrain are mechanically identical, closing the loop on the gyro, or by using velocity control of the drivetrain. You can also correct for momentum overshoot - fishtailing on fast-driving turns or over-turning when you are doing a turn in place. That can be done without feedback or again, with velocity control on the drive train. 254 has some interesting code that prevents overturning that essentially accumulates the turn and applies a opposite turn amount as the joystick angle is reduced or returned to zero.
Most upper tier teams this year also used vision for alignment as they drove up to retrieve a game piece or to score. This makes you look incredibly smooth.
In addition, you want to gear a gear ratio that will make your average transit time the quickest. This isn’t necessarily the fastest gear ratio, because of acceleration or deceleration. In point of fact, the average “sprint distance” for robots this year was probably in the 10 to 15 foot range. I know of very few teams that actually use shifting to ‘increase’ their quickness. More often, they use shifting just to give themselves a low pushing gear, and spend 90% of their driving time in their fast gear.
The acceleration of NEOs is changing the game entirely - it is faster than most tall robots could ever want. Suddenly traction is more important just to avoid burning out. So sprint distances, etc. are less essential to calculate and it is more about controllability. A lot of answers you’ll read in old threads are based on relatively out of date methodology that is in the middle of changing. This will take some experimentation.
I can say one thing that made the biggest difference for us was the use of a sprint distance calculator to optimize acceleration this year. We set our gear ratio blindly on that time to travel X distance number and ended up with a much “faster” robot by actually dialing our top speed way down since we were on a half field sprint at most.
Thanks for the shoutout, though I’ll mention two things:
I decided to remove the sprint distance calculator from the latest version of my spreadsheet because of programming bugs and less-than-accurate results. That’s not to say that it won’t work for you, just that I can’t 100% guarantee the values you get will be accurate. I’ve been recommending teams use ILITE’s simulator instead, which was linked above.
If you do want to use my calculator, I recommend you use the version in v3.5 instead of v2. I made a number of improvements and fixed a number of bugs between the two versions. You can download v3.5 from my github here.
Our drive train sim has worked very well for us over the last several seasons for a very specific reason: we use it to get “close enough” to the final minimum time result based upon a strategic distance we determine on Day 0. In FRC, I find that we don’t need to simulate drive train speeds/distances down to the nearest inch, or 0.1 ft/s. The drivers have much more impact on that level of precision than a gear ratio would.
We have also used the calculator twice to make performance upgrades that were based upon field conditions that were unrelated to drive train performance. In both 2018 & 2019, we needed to cut weight on our bot in week 6 or beyond. Using the calculator we made great decisions on new motor configurations in both years, leading to great on-field success.
This year we realized that muscle memory from a practice bot is sometimes incorrect when transferred to the production bot. So this year we plant to focus more on software as a means to increase overall speed of game piece manipulation.
I was working on a feed forward simulator this summer, but I didn’t get consistent results in the time I gave it. So I’ll probably switch focus to the incremental improvements listed in that thread.
There are several things to look at. Most (if not all) of this is repeat, but I’m going to try to stitch it all together.
“Speed” in terms of an FRC robot is really measured in “successful tasks per minute”, not “feet per second”. This means that in addition to the drive train, you must also work to improve your manipulators’ speed, reliability for pickup (“touch it-own it” and/or automation), margins (to reduce “line up time”), and reliability (to reduce rework time). Driver practice is also key in reducing both manipulator time and drive time!
Getting to the drive train: as has been noted, the key number here is the speed for the specific distances the robot will need to sprint. For a robot stuffing the pyramid into the vault last year, that might be less than ten feet; for gear runners the year before, it was essentially full court. When you calculate sprint time, also take into account stopping time, unless you’re going to drive your robot full speed into a wall or other structure. What affects this sprint time?
Initial maximum acceleration: this can be limited by traction considerations, robot stability (falling over on its back or face), or the available torque from the motors. Calculate all of these limits, and use the smallest.
Rate of acceleration reduction as a function of speed. That is, how much does your acceleration fall from its 0 ft/s value at 2 ft/s, 4 ft/s, and so forth?
Maximum theoretical speed: This is the speed you could reach if you had a mile of carpet. It’s the least important of these three numbers, unless one of the other two numbers is really poor, because there’s only about sixty feet of carpet, and that on a diagonal cross court run.
These are in turn affected by:
Robot weight
Robot torque and power at maximum current draw (includes motor count and efficiency and your current budget)
Effective gear ratio(s): by effective, I mean that you should include wheel diameter. An effective unite of measure for this is ft/s per 1000 rpm.
Wheel coefficient of friction (and possibly treading styles)
Robot center of gravity altitude divided by the wheelbase (If the CoG is off center front to back, you will have different effective values for acceleration and deceleration).
One of the things noted above is that switching to NEOs or 6 miniCIM or 6+ 775 pro/Redline drivetrains provide better efficiency (especially at high torque), and maximum power; this is much simpler and often lighter than shifting gearbox, meaning that in many cases it is better to throw more motors at a drive train than to shift, especially when you factor in the extra drive practice you can get from it.
The “fastest” robot I’ve been part was referred to by the announcers as a “speed demon”. It was built on a KoP chassis with 4 CIMs, 8.45 gearing, and 6" kit wheels (AM design speed of 12.7 fps), which doesn’t sound like much [it was geared slower than any recent KoP out-of-box]. However, it was about 2/3 as long and half the weight of many robots on the field, with a CoG about four inches above the carpet [arm down], and the driver had well over a hundred hours of practice. Here you can see it score a held cube then cycle three more cubes into the exchange in about sixteen seconds (time 0:22 to 0:38): https://players.brightcove.net/18122129001/Hyzdiqw1W_default/index.html?videoId=5810008652001
This is really important and a lot of teams overlook this. Sometimes to improve your robot’s speed, you actually need to work on all the aspects of the robot other than the drivetrain.
Your robot can be perfectly tuned to minimize the time it takes to cover the distance you’re travelling, but if it takes 20 seconds to pick up a game piece when it gets there you won’t see anyone calling your robot fast. Whereas a robot that takes an extra second of travel time but picks up the game piece almost instantly will certainly be a tough competitor.
I’d be curious to hear the results of other team’s experimentation with NEOs. We swapped from 4 big CIMs to 6 NEOs on our 2019 robot for IRI and were popping wheelies like nobody’s business. We ran 8" pneumatic wheels this year which probably didn’t help the situation and went to a 12.75:1 ratio on our drive train gearbox. We tried to program our way around the issue with some success. It really came down to our driver having to be more careful about throttling up and down, especially when playing defense so we didn’t end up on top of other robots.
Upon inspection this sheet looks a lot more in depth than what we used last year but overall founded on the research we did that led us down this path to begin with.
Thank you both for the number crunching and time it took for this. @AriMB@JesseK
The truly optimal driving speed for most teams is the drivetrain that the team can put together the speediest.
For lots of teams, that is the kitbot in default configuration or buying a COTS gearbox.
The time some teams spend debating gear ratio optimization could go into drive practice and that drive practice helps teams go a lot faster on the field (pieces scored per match, thus scoring more points).
In short, more drive practice will go a lot further to improve your on-field performance than gear ratio optimization for certain sprint distances.
And remember that there are multiple gear ratios for the toughbox that allow you to use different sizes of wheels and not be super slow or too fast. It’s a fantastic gearbox, but I feel like sometimes teams don’t realize they have options to buy different ratios for it.
There is a lot of hype on this thread about brushless motors. Don’t get too caught up in it. They offer a few more percent efficiency, and lighter weight, but they aren’t going to miraculously change your drivetrain performance*
Instead, choosing your drivetrain speed is always a compromise between top speed and low-speed torque. It may seem counter-intuitive, but higher gear ratios (lower “free speed”) will actually give you faster sprints over short distances because you get more torque at low speed. The problem with a high-ratio gearbox is that it runs down the side of the motor torque curve more quickly, so you run out of torque at high speed, which ultimately is why it has a lower “free speed”.
To put the concept into actual numbers we have to start talking about voltage drop, current limiting, mass of the robot, traction limiting and efficiency (friction) of the drive train. Luckily there are several simulators (not JVN calc) on CD that can take this all into account for you. Below is a plot that we made with our own simulator while designing the 2018 robot. You can see that:
the Andymark Kitbot with 6" wheels keeps up with every other option for the first ~2s (0.5m), but then starts to slow down.
the EVO Slim single speeds, which are geared a little faster, start out slower than the kitbot, but eventually overtake it after ~2m
the 2017 geartrain (which was a 2 speed ballshifter is the first to reach all distances, but only if we assume it shifts perfectly at 0.25s
Shifters help avoid the compromise. We ran shifters this year because we wanted to be traction limited at the low end (to push against defense), and also as fast as possible in longer sprints. But shifters have their own issues. They need a reliable pneumatic system, and the shift time itself can impose an acceleration and controllability penalty (our robot would sometimes kick to the side as one side shifted a fraction of a second before the other). Lots of top-level teams are choosing single speed drive shafts these days for those reasons.
*an exception is brake mode. Brushless motors have way brakier brake mode.
The hype isn’t about a generic brushless motor versus an equivalent brushed motor - it’s about the specific experiences FRC teams are having with these motors compared to CIMs.
+1^. Brendan is correct on the generalities, and Chris on the specifics. NEOs are better than CIMs for efficiency, size, and weight because they are brushless. They also perform better than CIMs in FRC drive trains because they offer more low-end torque at about the same free speed.
Yep, we switched mid build season from 3 mini-cims to 2 neos, primarily for weight reasons. And yes, the Neos offer a bit more peak power (maybe 10%, per @Richard_Wallace’s links). But on the whole, 10% isn’t going to win you more matches is all I’m saying.
(but we’ll still keep using them because, hey, 10%).
