How do the top teams craft their drivetrains to be so quick? Ex - 971, 973, 148… I’m looking for things like target free speed, shifter vs. one speed, motor combination, ect…
I’m not sure many teams do shifting anymore. Many teams are now switching to 4 NEO drive.
You will probably find that the biggest contributor to speed of driving is not motor/ratio/wheel size/shifting config setup, but instead driver practice.
If you look at a lot of teams most don’t have that fast of a robot compared to most other teams. This usually being around 12ish-14ish ft/s adjusted (I don’t remember what that is unadjusted 14ish-16ish I think) as Nick said its mostly in driver practice. As for the question of to shift or not to shift there are many threads already created about this but my position on it as of this moment is if you plan to have pneumatics go for shifting if not don’t go for shifting. I don’t see going for shifting to be a season breaker like swerve. As for the motor combination if you have neos I would go for those unless you want the fancy talon stuff then go for mini cims, or maybe wait for the vex bldc things I seem to recall hearing stuff about that will be out maybe this winter.
Is the 4 neo drive train powerful enough to yield insane acceleration? I’ve talked with someone from 2468 and they said they use 6 neos at 16 fps at close to max weight and they are pretty much one of the fastest, most agile robots I’ve seen.
The acceleration on them is pretty decent but the trade-off is using the 2 extra PDP slots for a 6 motor drive. I would personally go for a 4 neo with shifting than 6 neo ss for most cases. though I know 2046 had 6 neo and could push almost anybody and were decently fast but I might say that was because of the slow adoption of neos.
The 3 teams you listed all built quite lightweight robots this year. This helps them accelerate faster. Building a lighter weight robot can help you stay traction limited with more aggressive gearing. However, with current limiting features on modern motor controllers this is less of a concern than it used to be.
Slow is smooth, smooth is fast.
While it may look like a robot is extremely fast, what matters most is the actual cycle speed of the robot. I’ve seen someone build a robot geared for 28 ft a second. While they were good starting the season, they were overtaken by robots that had better control of their robot.
Also, what @PatrickW said above.
When we conducted our initial testing of the NEO motors at the beginning of the year, we put them on one of our two 2018 bots without changing anything else. The robot appeared noticable faster than with the miniCIMs. At wone point we did a side by side comparison of our 2018 bots (comp and clone) and what that testing revealed was that the top speed was virtually the same, but the acceleration of the NEO motors was much better than the miniCIMs.
Since most of the gearing decisions are really a tradeoff between acceleration and top speed, the NEO motors have changed that equation a bit by offering better acceleration for the same top speed, or higher top speed for the same acceleration.
One of our offseason projects is to look at re-gearing one of our robots to compare the performance when we gear it for higher top speed. We will not start this project until the fall (after our offseason events are done), but I am excited to see what the results show.
For reference, we are a swerve team, so our drive power consists of 4 motors (one drive motor per wheel).
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.
100% agree with everything here. Many teams spend too much time optimizing mechanical aspects of a drive train as opposed to coding and electrical.
With good programming and plenty of drive practice, a 4 cim kitbot drivetrain would beat the heck out of a 4 neo wcd any day.
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.
We took this tip from team 33.
I forget, which design calculator has a sprint distance calculations?
The ilite DriveTrainSimulator spreadsheet is pretty comprehensive.
We used this one, solid results.
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.
2nd for Ilite! It is very good!
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):
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.