Let’s talk about ‘doing the math.’
It’s kind of a trite and unhelpful thing to say: go do the math. What math? How hard should I do this math? Can I believe the results of this math at all?
For general design work we love using Recalc for mechanisms and ILITE drivetrain sim for basic drivetrain considerations. These calculators can get a lot of mechanism and gearing choices within the realm of sanity with very little effort.
Other times we need to write our own calculators for weirder things. Two things we made simple calculators for were tipping; tipping the charger and tipping the robot over with an extended arm.
We are building light, so we wanted to know if a light (100lb) robot would tip the charger if one or two full-weight robots were already balanced. This would represent a ‘we’ve got 20 points, but maybe we need 30 at the last second’. Turns out that our robot is unlikely to tip the charger in these situations (even a single balanced full-weight robot that’s offset near the limit of tipping the other way would prevent us from tipping the charger towards us), so we designed the chassis to handle the 34deg breakover.
We also made an arm-chassis-combo CG calculator that predicts max driving accelerationg with the arm in different configurations and weights. These numbers are based on a loony coodinate system we chose, so don’t overthink them too much.
Tells us something kinda obvious: heavier arms and lighter chassis get tippier. Now we compare to the ILITE sim results for our chose DT (yeah, I know, the masses aren’t all exactly the same, but we’re at a crayola level of precision here).
Now we can look at the green curve of the sim results to see how our driving is impacted by different acceleration limits by using different coefficients of friction in the sim. I picked 15ft as a sprint distance we might use with an extended arm for scoring (e.g. flip out arm as soon as you enter the community zone, then drive 15ft with an extended arm to score).
friction limit - sprint time for 15ft
1.2g - 1.4s (no robot tipping limit, traction limit of our wheels)
1g - 1.4s (small acceleration limit from a full-weight robot with an insanely light arm)
0.7g - 1.4s
0.6g - 1.5s
0.5g - 1.5s (moderate robot weight with moderate arm weight)
0.4g - 1.6s
0.3g - 1.8s
0.2g - 2.2s
0.1 - 3.2s (light robot with a very heavy arm)
These are all worst-case numbers and do not necessarily limit the robot in all directions of movement with swerve.
How do we put these results in context? Welp… experience.
Our best matches in 2017 were 9 gears, or about 8 full-field cycles with a ~10s climb. Call it 120s, 8 cycles… 15s/cycle broken down to ~ 8s driving, 1-2s pickup, 4-6s scoring. 2017 was a bonkers year.
So, how much do we care about the time-cost of acceleration limiting from an extended arm?
1.2-0.7g - not even a little bit. Any design that keeps our acceleration limit at or above 0.7g is effectively the same from a driving perspective
0.6-0.4g - not really much at all. A few tenths of a second are within traffic and light defense variability.
Down to 0.3g - adding less than 1s to a cycle, which is not TOO big a deal, worth considering if we gain some significant durability or flexibility in another area of robot performance. Think carefully if this will cost us a cycle.
0.2g or worse - nope, we’ll lose more than 1s, maybe 2-3s, per cycle which will reduce our total cycle capacity by at least 1 game piece, maybe 2. This is not acceptable.
Now we have some reasonable numbers to feed back into the CG tipping calculator to see what our design allowances might look like… Effectively a 10lb manipulator on a 100lb chassis is probably around where we want our design limits to be.
I do not plan on sharing these calculators, they aren’t polished and require a lot of explanation on how to use them. Derivation of such calculators is left as an exercise for the reader.
There, that’s a decent example of how we ‘do the math’ to help guide design decisions (and how to not obsess over making the lightest arm known to FRC).
