V5 Rotation Sensor — Overview 🌀

Three Different Readings

Per the PROS V5 Rotation API, the sensor exposes three distinct readings:

Centidegrees, In Plain Numbers

The 1/100-degree resolution sounds abstract until you map it to physical motion:

• 1 cd = 0.01°. So a reading of 4500 means 45.00°.
• 36,000 cd = 360° = 1 full revolution.
• An Override arm moving from ground (0°) to high goal (~90°) traverses ~9000 cd.
• The Hero Bot arm presets in advanced-robot use 0/600/1400/2400 cd — that's 0° / 6° / 14° / 24° on a high-reduction mechanism (gear-reduced from the motor), or it could mean 6/14/24 cd of sensor reading for a direct-coupled arm with a smaller swing. Always sanity-check against the physical mechanism: 600 cd is only 6°, which is small.
• An odom tracking wheel with a 2″ diameter = π × 2 = 6.28″ circumference. So 36,000 cd of sensor rotation = 6.28″ of robot travel. That's 5,732 cd per inch — the conversion factor your odom math uses.

Position vs. Angle: When Each Is Right

• Use get_position() for tracking wheels. The wheel will spin many revolutions in a match. You need cumulative rotation, not "where is the wheel pointing right now."
• Use get_position() for arms that may exceed 360°. Even rare cases (a flipped chain bar that loops around) can confuse get_angle() by wrapping at unexpected times.
• Use get_angle() for arms with strict <360° range. If an arm physically cannot rotate past 360°, get_angle() behaves like an absolute encoder and you don't need to track wraps. But honestly, most teams just use get_position() for everything because it's simpler to reason about.
• Use get_velocity() for stall detection. Pair with a torque check on the motor: if motor current is high and Rotation Sensor velocity is near zero, the mechanism is stuck.

Physical Setup

The sensor has a 1/4″ square hole that accepts a standard VEX High Strength Shaft Insert. The shaft passes through the sensor; the sensor body bolts to the structure. As the shaft rotates, the sensor reads the angle.

• Shaft: use a 1/4″ square shaft cut to the length you need (typically 0.5–1.5″). The shaft must rotate freely inside the sensor — binding will jam your readings.
• Insert: for thinner mechanisms, use the round-shaft version of the High Strength Shaft Insert (from kit 276-1411 or similar) to adapt smaller wheels (e.g., 2″ omni for odom pods).
• Bolting: the sensor body has 4 mounting holes that match standard VEX hole spacing. Two 8-32 screws through C-channel are usually sufficient. Don't over-tighten — the plastic body will distort and bind the shaft.
• Cable strain relief: route the Smart Cable so it doesn't pull the sensor as the mechanism moves. Use cable ties to anchor the cable to a non-moving structure within 4″ of the sensor.

For Odometry Tracking Wheels

The Rotation Sensor is the canonical tracking-wheel sensor in V5RC. Per odom-pod-build, the standard configuration is:

• 2″ omni wheel (276-7254) on a 1/4″ square shaft
• Shaft passes through the Rotation Sensor
• Sensor body is rigid; wheel + shaft float against the floor via a spring/rubber-band-loaded pivot
• Pivot keeps the wheel pressed to the floor as the chassis flexes
• Two pods (parallel + perpendicular) give x/y position; pair with IMU for heading

See odom-pod-types for the swing-arm vs. fixed-mount tradeoffs and odometry for how the cumulative position counts feed into pose estimation.

For Arm/Lift Angle

Mount the Rotation Sensor on the arm's pivot axle so the shaft is the pivot. Two common configurations:

• Direct-coupled. The arm's pivot shaft passes through the Rotation Sensor. The sensor reads true arm angle 1:1. Simplest; preferred for most arms. Works as long as the sensor body can be rigidly attached to a non-rotating structure on one side of the pivot.
• Geared down (high reduction). The arm pivot drives a gear train that turns the sensor shaft at a higher RPM. This means the sensor reads more counts per degree of arm motion — finer effective resolution. Useful only if you need sub-1° precision on a small arm; for most Override applications, direct-coupled is plenty.

Wiring

• Smart Cable: any 3-pin V5 Smart Cable. Length matters — use the shortest cable that reaches; long cables introduce noise and snag risk.
• Smart Port: any port 1–21 on the V5 Brain. The port number is what you pass to the pros::Rotation constructor. Document your port assignments in code (header file or comment block) to avoid swap mistakes.
• Don't share ports. Each sensor needs its own port. The 21 Smart Ports are a finite resource — budget them. A typical Override Hero Bot uses 4 motor ports + IMU + 2 odom rotation sensors = 7 ports, leaving 14 for additional sensors and motors.

The PROS API Surface

Code Pattern: Arm Position Controller

Same P-controller pattern as the Potentiometer version in sensors-discrete § Code Pattern: Arm Position Control, but with centidegree readings:

Code Pattern: Override Arm Presets

The advanced-robot page uses arm preset constants. Here's the Rotation Sensor version of that pattern:

Code Pattern: Odom Tracking Wheel

The Rotation Sensor reading is the input to your pose-estimation math. The conversion is wheel-circumference dependent:

Sensor Fusion: Rotation + IMU

The Rotation Sensor gives translation; the IMU gives heading. Together they give pose. Per the Sensor Onboarding Roadmap, the sensor-fusion pattern is:

1. Read parallel and perpendicular tracking wheel positions (in inches)
2. Read IMU heading (in radians)
3. Compute pose deltas using your odometry math (small-angle approximation or arc-based)
4. Update global x, y, theta

For a worked walkthrough, see odometry § Sensor Fusion. For the LemLib version of the same thing, see Section 5 below.

EZ-Template: Subsystem Pattern

EZ-Template doesn't directly consume the Rotation Sensor for chassis odometry — it uses motor encoders for distance and IMU for heading. Where the Rotation Sensor fits is in subsystem control (arm, lift, intake) running as a parallel task, just like the Potentiometer pattern in sensors-discrete § EZ-Template Integration.

LemLib: First-Class Tracking Wheel Support

LemLib is a chassis library that uses Rotation Sensor tracking wheels directly. The construction pattern wraps Rotation Sensors in lemlib::TrackingWheel objects:

The signed distance values (-2.5, 1.5) tell LemLib where each pod sits relative to the tracking center. Get these wrong and your odom will drift unpredictably. Measure them carefully on the physical robot.

Reading the Sensor in Pure Auton (No Library)

You don't need EZ-Template or LemLib to use the Rotation Sensor — PROS is enough. For odom, this is hard work but possible. For arm control, this is the most common pattern and works fine alongside any chassis library:

Use Case 1: Arm Angle for Goal Targeting

Override has 3 goal heights (low 3.25″, mid 5.8″, tall 8.7″). The Hero Bot arm needs to reach all three. A Rotation Sensor on the arm pivot lets you:

• Define preset angles for each goal height (see Section 4 code patterns)
• Drive to a preset on a button press during driver control
• Drive to a preset before scoring in autonomous, with a known timeout
• Hold position against gravity using a P-controller (or stop the motor and let mechanical advantage hold — depends on your arm geometry)

This is the same use case the Potentiometer V2 covers. Section 7 (next) compares them head-to-head.

Use Case 2: Odom Tracking Wheels for Cross-Field Navigation

Override scoring is distributed: 4 alliance goals, 4 short neutral goals across quadrants, 1 tall center goal. A typical match has the robot moving across multiple goals. Encoder-only odometry (using motor encoders) drifts after long routes; tracking wheels via Rotation Sensors are much more accurate.

• Skills runs (60 seconds): highest-value application. Encoder drift accumulates over a 60-second route; tracking wheels stay accurate.
• Match autons (15 seconds): arguably overkill — encoder odom + IMU is usually fine for 15 seconds. But tracking wheels still help if your auton routes across the field rather than staying in one zone.
• Cross-quadrant routes: if your auton flips a Toggle in one quadrant then drives to score in another, tracking wheels reduce position drift during the long traversal.

The Override field layout (per the v0.1 manual) is 12′ × 12′ with goals near corners and along the perimeter midpoints. Cross-field travel can exceed 8 feet in a single auton segment — the kind of distance where encoder drift becomes noticeable.

Use Case 3: Cup-Flip Mechanism State (More Niche)

Cups have one transparent side and one opaque side. Per SC3, a pin in the transparent side scores; a pin in the opaque side does not. Some teams will build a cup-flip mechanism — a small rotating cradle that flips the cup before placement to ensure transparent-side-up.

• A Rotation Sensor on the flip mechanism's pivot tells your code "the cup is flipped" or "the cup is in original orientation"
• Or a simpler approach: limit switches at the two end positions (see sensors-discrete § Switches) — cheaper, fewer Smart ports used
• The Rotation Sensor wins if you want the flip to stop at any angle (e.g., for an in-progress cup orientation correction); the limit switch wins if you only need two states

For detecting cup orientation before flipping (i.e., reading the cup itself), use the Optical Sensor — see sensors-optical § Override Use Cases.

What the Rotation Sensor Doesn't Help With

• Pin color identification. Use the Optical Sensor (RGB hue detection) instead.
• Toggle state. The four field Toggles change yellow-pin scoring per quadrant. Per the v0.1 manual, Toggles are field elements with their own state — not something the Rotation Sensor reads. See override-toggle-strategy for how Toggles affect scoring.
• Endgame collapse confirmation. Use a limit switch at the collapsed-arm position — cheaper, simpler, more reliable than reading angle for a binary "am I ≤18″?" check.
• Distance to a goal. Use the Distance Sensor or AI Vision Sensor with AprilTags.

Side-by-Side Specs

The Decision, Plainly

For Override 2026-27, What We Recommend

Spartan's V1 Hero Bot baseline (per the kickoff brief) calls for IMU + Potentiometer for arm angle. After looking at this in detail, that recommendation holds:

• The Override arm range is small. Ground to high goal is roughly 0°–90° on the arm pivot (or much less if geared down). Both sensors handle this; the Pot V2's 333° range is plenty.
• 1° precision is enough. Goal heights are physical targets; the arm can be off by a few degrees and still place a pin/cup correctly. Sub-degree precision doesn't buy you anything for this game.
• The Pot V2 is half the cost. Across 6 teams (39 students), that adds up. $90 saved per robot is real budget money.
• Smart port budget matters for Override. A typical Hero Bot uses 4 motor ports + IMU + potentially 2 odom Rotation Sensors + AI Vision Sensor + Distance Sensor + Optical Sensor = 10+ Smart ports. Putting the arm sensor on an ADI port leaves Smart ports free for vision and distance sensors that have no ADI alternative.

Where you should switch to a Rotation Sensor: if you decide to build odom tracking wheels for skills runs (recommended for Period 4 vet teams chasing high skills scores), use Rotation Sensors for those. Don't mix — if you're investing in Rotation Sensors anyway, it can be cleaner to put one on the arm too. But for V1, Pot V2 is the right call.

What About a Motor Encoder for Arm Angle?

The Smart Motor has a built-in encoder. Why not use that?

• Backlash and slop. Gearboxes have play. The motor encoder reads the motor shaft, not the arm pivot — so you're reading "where I commanded the arm" plus backlash, not "where the arm actually is." For coarse positioning this is fine; for precise angle control it accumulates error.
• No absolute reference on power-up. Like the Rotation Sensor, the motor encoder is relative; you need to zero it. Both sensors require a known reference position at startup.
• For Override arm presets, motor encoder is sufficient. If you want zero extra hardware, you can run the arm purely off motor encoder readings. The advanced-robot.html worked example actually uses this approach. The Pot V2 (or Rotation Sensor) becomes a sanity check or upgrade path.

Cross-References

• sensors-discrete § Potentiometer V2 — full deep dive on the alternative
• advanced-robot § Arm Control — the canonical Override Hero Bot arm preset code
• odom-pod-build — building tracking wheels around the Rotation Sensor
• sensors-roadmap § Priority Stack — how this fits in the larger sensor onboarding plan