FRC 95 The Grasshoppers 2020 Build Thread

There is a 2020 version of the ILITE DTS, with improvements


For those who use the ilite simulator, can you explain sprint?

I want to know the best gear ratio to go a certain distance. Let’s say 10 feet. On the spreadsheet, if I put in 10 feet as the sprint, the results say the total distance ends up being 20. So can I assume the sprint distance is really just the acceleration distance?

Next, if I change my gear ratios, then my final distance measurement changes too. Does this mean I need to play with sprint distance number to get the correct final distance number if I want to compare times over that specific distance?

1 Like

This video is great:


The best explanation of “sprint” in the video @Ty_Tremblay linked starts at 23:19.


Is there a way to specify a shift point within the calculator?

For auto-shifting? Unfortunately, not yet. There have been multiple requests for it though, so I can look into that for next year.


Thanks. The info from your guys’ awesome simulator is still really useful. I think we’ll be a little faster than it predicts when we optimize our shifting point.

With low gear around 7 ft/s we will often shift at 4-6ft/s to keep the drive motors in a high-power-output state, rather than let the robot (slowly) get to 7ft/s.

1 Like

You can actually calculate the optimal shift point, i.e. the speed at which the force applied by the motor in high gear becomes larger than the force in low gear.

The force applied by the motor with gear reduction G at a speed \omega can be expressed by \tau_s G \left( 1- \frac{\omega G}{\omega_f} \right). So we can solve for the shift point, \omega = \omega_s by equating the forces from both gear ratios:

\tau_s G_1 \left( 1- \frac{\omega_s G_1}{\omega_f} \right) = \tau_s G_2 \left( 1- \frac{\omega_s G_2}{\omega_f} \right)

G_1 - \frac{\omega_s G_1^2}{\omega_f} = G_2 - \frac{\omega_s G_2^2}{\omega_f}

\frac{\omega_s}{\omega_f} \left(G_2^2 - G_1^2 \right) = G_2 - G_1

\omega_s = \omega_f \frac{G_2 - G_1}{G_2^2 - G_1^2} = \frac{\omega_f}{G_1+G_2}



A few questions -
Are Gs 9.17 or 1/9.17? i.e. the reduction or ratio?
How does this equation account for the different motor torques at different RPMs?

G would be 9.17 (i.e. the ratio)

The equation for motor torque at various rotational speeds is given by \tau_m = \tau_s \left( 1 - \frac{\omega_m}{\omega_f} \right), where \tau_s is the stall torque, \omega_f is the free speed, and \omega_m is the motor’s current rotational speed. We can replace \omega_m for the wheel speed, \omega multiplied by the gear ratio, and multiple \tau_m by the gear ratio to get the torque at the wheel, \tau. So putting that all together we get \tau(\omega) = \tau_s G \left( 1 - \frac{\omega G}{\omega_f} \right), which gives the torque provided by the motor at the wheel for any possible wheel speed.

1 Like

A helpful old thread: FRC 2012 "Best Designs" Log


Explored this thread tonight, surely could help younger teams in need of inspiration.

1 Like

Finally, a meaty update.

We got out 2012 turreted shooter working again to get a little testing in. Firstly - needs way more flywheel mass. Secondly - old and corroded brushed motors get really pissy. Was a good, quick, learning experience, but we quickly moved on.

We got into prototyping for real. We laser-cut our mk2 prototype shooter out of PETG. A nice little-known plastic with many of the properties of polycarbonate, except that it’s less expensive and laser-cuttable. It’s a great prototyping material for us.

Roughly 2in compression, 6x2 colson wheel, 25° of engagement, and 1x minicim running open-loop at ~12V. Tons of range, and shot variation was about 1 ball diameter at ~25ft range. Quite pleased for our first try.

It’s designed to do a target zone shot, so about 70 deg, and we had to tip it waaaay down to test at full power. Our first shot almost took out a light fixture…

The CAD model uses a laser-joint featurescript to make tabbed joints, which fit together really well if you massage the material thickness to make up for the laser kerf. We then pilot-drilled some spots to cinch everything together with wood screws. Worked like a charm.

Some pollen seems to have materialized out of nowhere! Very weird for this time of year in NH…

We are also wrapping up ‘gimpy bot’ which is our 2018 chassis stripped way down to just a programmers playground. This will be our test bed for control loop development, additional/advanced prototyping, and other such activities.

Our prototyping carnage thus far. The intake funnel is… not as effective as we’d have hoped. Lots of work to do there. The power cells will squeeze through very small gaps if they are over-constrained. I hope we can make good progress on that this weekend. The wooden mk1 shooter went together quickly, and exploded even more quickly.


Two inches of compression is more than we were thinking of using, have you had any issues with the ball’s aerodynamics being messed up? Are you planning on increasing/decreasing that at all? Also something to note that you might have thought of already is that the power cells take a really long time to decompress, which might mess with you if you don’t expect it.

Good thoughts.

In doing shooting challenges for quite some time in FRC I’ve learned that foam balls need a lot more squish than one might initially suspect in order to develop a consistent shot. The power cells will vary in diameter, I’d guess around +/- 1/4in, maybe more. If you only compress 1/2in then your compression variation ball-to-ball is 50%-150%, which will be a mess in terms of accuracy. If you squish 2in then the variation is more like 88-112%. Not nearly so bad.

These sorts of balls go through two ‘phases’ of compression. First, the air inside actually compresses like a spring. This only matters for really fast compression cycles. Second, air actually escapes the ball and the foam structure collapses a little. This only happens for slower compression cycles. What we’ve learned over the years is that you don’t want to squish the heck out of the balls in your feeder/conveyor because that will force air out and result in that ‘slow recovery’ you see when squishing it by hand. HOWEVER, in a shooter, the squish is so fast that little air escapes, so the ball rebounds quickly upon exiting the shooter because the compressed air inside of it returns it to shape. Compare slapping a power cell to slowly squishing it to see this effect first-hand.

To avoid these issues -

  1. Feed into the shooter consistently
  2. Compress the power cell as little as possible in the feeder/indexer

Gotcha, we’ll keep that in mind as we’re designing, thanks!

1 Like

Shooter repetition testing.


skip to 41:00

1 Like

Do you have a link to this feature script? This sounds incredibly useful for a lot of different applications, in FRC and out.

1 Like