How do dead wheels track the robot position?

Dead wheels, also known as tracking wheels or odometry pods, track the robot's position by using small, unpowered wheels, typically omni wheels, with an encoder attached to the wheel's axle . These encoders measure the distance the robot has traveled .

Localization software uses readings from these encoders, which track "counts" or "ticks" representing a certain amount of rotation . The number of counts per revolution (CPR) determines the precision of the data .

A common setup involves two or three dead wheels, usually sprung to maintain constant contact with the floor tiles for accuracy .

Two-wheel design: Uses one parallel and one perpendicular pod to measure x and y movement, respectively. A gyroscope measures the change in heading .
Three-wheel design: Employs two parallel and one perpendicular pod to measure x and y movement. Heading is determined by the difference between the two parallel wheels, often providing more accuracy than a gyroscope due to limitations of the BNO055 IMU in the FTC control system .

Was this right?

Sources6

Dead Wheels

Game Manual 0·CC BY-NC 4.0

Warning: 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.

Term: Dead Wheel — A small unpowered wheel (usually an omni wheel) that tracks the distance the robot has traveled through the encoder attached to the wheel's axle.

Usually, there will be two or three wheels - one or two on the x and y axis each to track the front-back and left-right position relative to the starting point. Generally, odometry wheels are sprung so that the wheel is in contact with the floor tiles at all times to ensure accuracy.

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.

Open Game Manual 0

Dead Wheels > Encoders

Game Manual 0·CC BY-NC 4.0

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.

Open Game Manual 0

Dead Wheels

Game Manual 0·CC BY-NC 4.0

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.

Open Game Manual 0

Dead Wheels > Drive Encoder Localization

Game Manual 0·CC BY-NC 4.0

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

Open Game Manual 0

Dead Wheels > Two-Wheel Odometry Pods

Game Manual 0·CC BY-NC 4.0

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

Pros:

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

Quite pricey
Tuning of the heading is very important

Open Game Manual 0

Dead Wheels > Design

Game Manual 0·CC BY-NC 4.0

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:

Open Odometry by 18219

https://openodometry.weebly.com
Utilizes the REV Through-Bore Encoder
Most popular and robust publicly available design
Compact enough to fit into a goBILDA channel

Things to consider:

Utilizes Rotacaster 35mm wheels from Australia. Shipping may take a while

goREVdometry

https://discord.com/invite/Cvz3MbM9dX
Utilizes the REV Through-Bore Encoder
Compact enough to fit into a goBILDA channel

Things to consider:

Information only available through their Discord channel
Hasn't been iterated on in a while

9794 Wizards.exe Design

https://www.youtube.com/watch?list=PLICNg-rquurYgWAQGhu6iC0At75vgqFJp&v=OjNvAD350M4&feature=emb_title
Compact enough to fit into a goBILDA channel
No longer recommended as it utilizes the E8T

Open Game Manual 0