Dead Wheels


This is a very niche aspect of design in FTC. Generally it is something done by more experienced teams who have had time to repeatedly test their designs and mechanisms with software during the off-season.

The term dead wheels, tracking wheels, odometry pods, and odometry are often conflated in the FTC community. However, there are a few key differences one must keep in mind. Odometry is an umbrella term and refers to the general use of motion sensors for localization purposes. Meanwhile, dead wheels, tracking wheels, and odometry pods are all synonymous terms. We’ll explore what they mean in a bit.

Odometry refers to the use of motion sensors for localization. Localization is a means for being able to locate the position of the bot at some point in time. Localization is crucial in path following and advanced autonomous modes as one needs to know where they are to generate the necessary movements needed to reach a desired destination. Localization software plays a major role in odometry; however, in order to produce accurate results, reliable and accurate hardware design is a necessity.

The simplest form of odometry is drive encoder localization. This is the use of encoders measuring the rotation of motors that power the drive train. One is able to read the encoder data and feed it through the kinematic equation for that specific drive train to derive the body’s velocity. Drive encoder localization is generally quite simple and easy to setup as almost all of the FTC legal motors have built-in encoders. Getting drive encoder localization setup is simply a matter of plugging in wires, no additional hardware needed.

Many teams in the community have converged on a unique solution that isn’t seen very much outside of FTC: the use of “dead wheels,” “tracking wheels,” or “odometry pods” (these terms are all synonymous). These refer to small “dead” or non-driven (not powered by a motor) wheels attached to an encoder sensor. Two or three dead wheel pods are often sprung to the ground to ensure accurate tracking. The two-wheel design utilizes one parallel and one perpendicular pod (parallel and perpendicular with respect to the drive wheel axis), measuring x and y movement respectively. Change in heading is measured via a gyroscope. The three-wheel design utilizes two parallel and one perpendicular pod, measuring x and y movement respectively. However, this design forgoes the gyroscope and instead measures heading via the difference with the two parallel wheels. This is often more accurate in the context of the FTC control system because the BNO055 IMU (used for the gyroscope in the two-wheel design) utilizes I2C which is slower than the rest of the I/O on the REV Hub and cannot be bulk read. These two issues lead to minute drift issues which can compound over time, thus leading to a more inaccurate localization system when using the two-wheel design.

However, designing consistently accurate dead wheels proves to be a difficult design challenge. It is often quite pricey. A set of three dead wheels will cost a minimum of $100 for the encoders alone, prior to any hardware.

Let’s go through the advantages and disadvantages of each system.

Drive Encoder Localization

  • Pros:

    • Cheap (the motors you’re using most likely already have encoders built in)

    • Accessible

    • Very little configuration necessary

  • Cons:

    • Drive encoder localization on mecanum drive can be quite inaccurate due to lack on traction on mecanum wheels.

    • Will drift on high acceleration on mecanum drive. Accuracy will be good enough for basic autonomous modes if acceleration is limited

Two-Wheel Odometry Pods

  • Pros:

    • Cheaper than 3-wheel design

    • Pretty good accuracy

    • No tuning of the heading necessary

  • Cons:

    • Subject to more drift than the 3-wheel design

Three-Wheel Odometry Pods

  • Pros:

    • Relatively accurate tracking. Great accuracy in a 30-second autonomous mode

  • Cons:

    • Quite pricey

    • Tuning of the heading is very important


A lot of the localization done in software relies on readings from encoders. Encoders are sensors that track “counts” or “ticks,” which are values that represent a certain amount of a rotation. Different encoders might have a different number of counts per revolution (CPR), which is also sometimes also called ticks per revolution. The greater the number of counts, the more precise the data.

Encoders are plugged into the JST-PH ports in the REV hubs. These encoders can either be built-in to the motors or external. External encoders will still need to be plugged into an encoder port but are not related to the motor in that port. Through software, we can use the motor object to determine the position of the encoder. This should be done with motors that do not use encoders. If you’re using dead wheels, you will not need the drive motor encoder ports, so those are potential ports you might want to use.

If one chooses to design dead wheels, there are only two recommended encoders that one should use for FTC: REV Through-Bore Encoders and U.S. Digital S4T Encoders.

REV Through-Bore

Often short-handed to “REVcoders” or “revcoders,” the REV Through-Bore encoders has quickly become the de facto option the FTC community. The REV encoders have gained such a reputation due to its relative affordability, much improved reliability, and ease of use. The through-bore design proves to be a significant improvement over previous optical disc encoder designs. Optical disc encoders are very fragile, prone to scratching, and are much less tolerant to design flaws.

A REV Through-Bore Encoder

REV Through-Bore Encoder


  • Through-bore design is very robust and easy to design with

  • Relatively cheap

  • High CPR

  • Easy wiring


  • Quite large relative to other encoders. May be challenging to create a compact design

  • Many Through-Bores seem to experience slight, uneven resistance when rotating. REV says this is normal and will subside as the encoder wears in

    • To forcefully wear in a REV Through-Bore encoder a 1/2” hex shaft can be spun on a drill through the encoder for a couple of minutes

  • Odd mounting points


The Through-Bore encoders have a very high CPR (8k). The REV Hub transmits velocity in a 16-bit signed integer. This means it can only communicate a maximum value of 2^15 (which is 32768). Thus, it only takes 4 rotations a second (32k / 8k = 4) for the velocity value on the REV Hub to experience an integer overflow. This is primarily a concern when dealing with motion profiling. The popular, existing tools (Road Runner and FTCLib) have mechanisms for dealing with this issue so this is not a concern and should not sway your design decision. Just keep this detail in mind once you start programming.

U.S. Digital S4T

The S4T miniature shaft encoder is another viable option used in dead wheel designs. These encoders are very small and may significantly reduce the footprint of your dead wheel design. Gearing these encoders is ideal to prevent shock loads.

An US Digital S4T encoder

S4T Encoder


  • Very compact


  • More expensive (nearly double the price)

  • Less durable

    • Very thin wires. Prone to breaking easily if not secured properly

  • Ideally requires external gearing

SRX Mag Encoder

The SRX Mag Encoder from Cross The Road Electronics is a magnetic encoder. It is not used by many FTC teams due to its slightly higher complexity to use and lack of FTC-centric documentation. It is more popular in FRC.

A CTRE SRX Mag encoder

CTRE SRX Mag Encoder


  • Very compact

  • Relatively cheap


  • Requires assembly

  • Not much information exists for use in FTC

U.S. Digital E8T (deprecated)

Once the de facto option for most FTC teams, the E8T optical encoders are no longer recommended as the REV Through-Bores are a superior option at an equivalent price. The open-hole optical disc design of these encoders face a number of frustrating design flaws that made them very fragile and prone to breaking. The only advantage that they have relative to the REV Through-Bores is their smaller footprint.

An US Digital E8T encoder

E8T Encoder


There are few open source dead wheel designs. Dead wheels are often designed around a team’s own drive train and FTC teams seldom publicly release their own robot CADs.

Here are a few publicly available dead wheel designs:

Spring Tensioning

It is highly recommended that your dead wheel design includes some form of spring tensioning that pushes the wheel into the ground. This ensures that the wheel is always in contact with ground and has adequate traction. Sufficient force is required to ensure constant traction to prevent the wheels from slipping. Keep in mind that too much force may lift a light drive train off the ground and disrupt driving.

The most popular method of spring tensioning is to pivot your pod around a point and provide a rotational force via a spring or rubber band.

A demonstration of pivoting spring tensioning

FTC 14320’s spring tensioning

A much more niche option is to vertically spring odometry pods. The idea is that springing around a pivot will cause the dead wheels to move in the axis parallel to the ground if the height of the dead wheels relative to the ground changes. Vertically sprung odometry pods will not experience such an issue. However, this is not really an issue that most teams will experience. Vertically springing is much harder to design well and is not recommended for the relatively minor improvement in accuracy it yields.

An example of vertical spring tensioning

FTC 18172’s vertical springing