Q: Why is FTC so obsessed with deadwheel odometry? Top FRC teams don’t need to, why would they?
A: Well, to answer that we need to explain a few things.
Preface: What’s a deadwheel odometry?
When motion planned autos was first popularized by Gluten Free’s 3-year run of dominance in 2018, 2019, and 2020, they also popularized using these small unpowered omni-wheel pods, usually on a springed suspension, connected to quadrature encoders.
Three of them on a drivebase (or two with an IMU) is sufficient to calculate displacement on the x, y, and rotation axes, as each omni wheel will only spin when the robot is moving in the axis of measurement while remaining stationary when the robot is moving perpendicular to it.
Knowing your displacement is important for robot localization — that is, knowing where your robot is on the field.
And knowing where you are on the field fast is important when you’re moving fast in order to make sure you’re moving to the correct spot fast.
Using the quadrature interface is fast on current FTC control systems, and this sort of integrating localization benefits from higher update rates as to reduce overall drift, as error can and will still accumulates as the robot drives.
And while other localization methods do pop up now and then, none have really displaced the role that deadwheel odometry plays in FTC.
But wait, in FRC we just use drivetrain encoders for this! Why do FTC teams bother? Well, for starters…
Traction: (or rather, the lack thereof)
In FRC, you get carpet, and you also get nitrile tread that might as well be welded to it. Your wheels don’t really slip even when you gun your motors at full blast. Thus, you have generally don’t really deal with slip error.
Like, this is why top teams love nitrile so much over Colsons, even if they obliterate way faster than Colsons. Not slipping is great for making that 3-piece auto repeatable.
In FTC, you play on a foam tile field.
Your drive wheels are also limited in how grippy they can be, as if they are too grippy they fail the field destruction test and are not allowed to be used.
Foam also has inconsistent coefficients of friction (the center of the tile has more CoF than the seams), and this isn’t even getting into the various materials that can be under foam fields at different venues — most competitions are held in places like school gyms with hard floors, but occasionally you’ll have events in libraries or Championships that have carpet underneath the mats.
On top of this, practically everyone in FTC uses mecanum. And mecanum isn’t known for being the most tractile drivetrain.
To summarize “why mecanum” in one sentence: Mecanum is to FTC what swerve is to FRC, and swerve is to FTC what diffy swerve is to FRC (at least before the 4 motor limit).
We even have a similar dynamic to the issues in this thread where starter kits encourage teams to build 2 motor 2+2 tank drivetrains whereas everyone competitive uses mecanum instead. At least mecanum only needs about 10 lines of code and doesn’t need sensor feedback to drive.
Overall, this means that your drivebase will almost certainly slip if you gun it at full acceleration.
You can try to motion profile to avoid this but you’ll likely come out slower than gunning it.
Traction is the main reason why springloaded omni pods have consistently won over drivetrain encoders. They just straight up perform better because they compensate for limitations inherent to FTC.
But…couldn’t you just use AprilTags/distance sensors/etc? You can, but they’re more game specific.
Usability from game to game and speed
Deadwheel odometry is a perennially reusable solution from season to season, provided there’s no terrain.
And there usually isn’t much terrain nowadays because it hurts lower end teams. (Just ask any team that was a rookie in 2016, FTC or FRC).
Distance sensors and vision targets are much more fickle and dependent on game setup.
For example, time-of-flight sensors (e.g. the Rev one) can’t really see the polycarbonate field perimeters, so you’d need to rely on the existence of hard-plastic targets you can point at for distance.
Ultrasonic sensors don’t suffer from this as much but they’ll usually update at like 25 Hz which is just too slow for anything other than correcting drift at the end of paths.
Vision is of more interest in recent times, but it’s a really hard problem in FTC.
There’s this old 254 Championships presentation that near the beginning talks about what makes good or bad vision targets.
And the same principles still hold true for FTC too. Consider the average match looks something like this:
As you might see, it’s a bit hard to find vision targets. Maybe the preloaded cones on the field would work?
We do get those odd pictures taped to the walls that you’re supposed to use with PTC’s Vuforia, but they’re not exactly good at being vision targets and as you might predict, nobody used them.
It wasn’t until the current season at time of writing (Centerstage) that we finally got 36h11 AprilTags as fiducials instead.
AprilTags are not a cure-all though. You’re still constrained by how fast the the Control Hub can read them (about as well as Limelight 2/RPi 3), so they’re still limited to being a drift corrector when moving slow enough.
Meanwhile, deadwheel odometry is able to update at 200 Hz, gives you a global position on the field, and if done right won’t drift enough to matter by the end of your 30 second autonomous.
At best, distance sensors and AprilTags augment these existing solutions, rather than replace them.
And the performance difference between them and drivetrain encoders is significant enough in FTC that if you can use deadwheels, theres no real reason not to.
