The Pin

A pin is a small two-color object that sits inside a goal. There are 63 pins in total, in four color combinations. Pins are the primary scoring object — visible red and blue pins each count for 5 points, and yellow pins are worth either 0 or +10 depending on the Toggle in their quadrant.

From a manipulation standpoint, all pins share the same geometry. The color combination doesn't change how you grip them — just which pin you'd want to grip in any moment. Specific pin dimensions, mass, and exact shape are not in the reveal video transcript and will be confirmed in the manual.

The Cup

A cup is hollow and hourglass-shaped — narrow in the middle, flared at both ends. One side is opaque, the other is transparent. Cups stack on top of pins on goals. Adding a cup to a goal increases that goal's pin capacity (more cups = more pins can be stacked there).

The opaque/transparent rule is the one that drives mechanism design:

• Pin in transparent side of cup → pin's color is visible → pin scores
• Pin in opaque side of cup → pin's color is hidden → pin does not score

This means: if your robot places a cup with the opaque side toward the pin, you've just scored 0 points instead of 5. Cup orientation control is mandatory, not optional. See Section 4 (Cup Orientation) for how to solve this.

It also means a defensive play exists: if you can't prevent an opponent from placing a pin, you might be able to top it with a cup's opaque side to block the pin from scoring. Whether this is legal depends on the manual's descoring rules.

The 1+1 Possession Limit

The reveal video states explicitly: at any given time, each robot is only allowed to possess one cup and one pin. This is the central design constraint of Override and shapes every mechanism choice.

What this means in practice:

• No magazine accumulators. A common pattern from past games — pick up many objects, drive once, score them all — is illegal here. You can hold one of each, period.
• Sequence matters. If you pick up a cup first and then can't reach a pin, you have to stack the cup on a pin that's already been placed (yours or someone else's).
• Pin must come first in the stack. A stack is "pin in goal + cup on top." Order is enforced by the geometry.
• Most efficient cycle holds both before the trip. Architecture B (dual-grip) is the only way to score a complete pin+cup stack with one field traversal.

The Goal

9 goals total in 3 sizes. 5 are neutral (either alliance can score in them) and 4 are alliance-specific (2 red, 2 blue). Every goal has an AprilTag for vision sensor identification.

• No stacking limit. The reveal video says "there is no limit to the number of scoring elements that are allowed to be placed on a goal." You can keep stacking pin/cup pairs arbitrarily high.
• Goal heights vary. 3 sizes confirmed; specific heights pending the manual. Your manipulator's reach must accommodate the tallest goal you plan to score on.
• AprilTag mounting. Confirmed on all 9 goals regardless of alliance. See AprilTags Deep Dive for ID mapping (TBD post-manual).

Architecture A — Sequential Single-Grip

One universal manipulator. Picks up either object. Two trips per scored stack: trip one for the pin, trip two for the cup.

What it looks like

A single gripper at the end of an arm or lift. The gripper has to be designed to hold both a pin and a cup — usually with a compliant inner surface (foam, rubber, or articulating fingers) that conforms to whatever shape it's clamping. Common implementations: a wide V-jaw with rubber pads, a passive scoop with a one-way trap, or a paired-finger gripper with adjustable spacing.

Cycle sequence

1. Drive to pin source (loader, field tile, or driver station)
2. Grip pin
3. Drive to goal
4. Place pin
5. Drive to cup source
6. Grip cup — orient if needed (see Section 4)
7. Drive back to same goal
8. Stack cup on pin

When to pick this

• Rookie team or first-year V5 build — build skill is the limiter, simplicity wins
• Your robot's strategy emphasizes other systems (drivetrain, defense, endgame) and the manipulator is "just good enough"
• You want to ship a working V1 fast and iterate to dual-grip in Phase B
• You're short on motor ports for the rest of the robot

Spartan's V1 Hero Bot will likely use Architecture A. The team's "roller-changing arm" concept fits this pattern — one mechanism that handles both objects sequentially. Phase B teams can graduate to B or C.

Architecture B — Dual-Grip

Two specialized grippers, each on its own actuator. Pick up one of each, traverse once, place both.

What it looks like

The robot has two distinct grippers. The pin gripper is small, narrow, optimized for the pin's geometry. The cup gripper is wider, often with a contoured inner surface that captures the cup's hourglass shape. The two grippers are typically stacked vertically or side-by-side on the same lift assembly — they share the lift but each has its own grip actuator.

Cycle sequence

1. Drive past pin source — pin gripper engages
2. Drive past cup source — cup gripper engages
3. Drive to goal
4. Place pin first
5. Stack cup — rotate first if orientation is wrong

When to pick this

• Experienced team that has built multi-mechanism robots before
• Cycle time matters most for your strategy (high-volume scoring)
• You have motor ports to spare (typically 2 grip motors + 1 lift = 3 mechanism ports)
• Drivers can handle a more complex robot with more state to track

Architecture C — Hybrid Intake-and-Grip

A passive ground intake (rollers, compliant scoop, or chute) captures whichever object the robot drives over. An active grip extracts the captured object from the intake and places it on the goal. Object type is identified by an optical or distance sensor.

What it looks like

The bottom of the robot has an angled scoop or roller intake near the chassis floor. The robot drives over a pin or cup; the intake captures it and feeds it into a holding zone on the chassis. Above the holding zone, an arm with a single grip extracts and places. A sensor on the holding zone identifies whether it's a pin or cup, and the robot programs accordingly.

Cycle sequence

1. Drive over pin source — intake captures pin
2. Identify (sensor confirms it's a pin)
3. Drive over cup source — intake captures cup
4. Identify (sensor confirms it's a cup)
5. Drive to goal
6. Extract pin from holding zone, place on goal
7. Extract cup, orient, stack on pin

When to pick this

• You want fast field-pickup without precise alignment (common in chaotic match flow)
• You have programming bandwidth for sensor logic and state management
• You don't have the build skill for two precision grippers (Arch B) but want better cycle time than Arch A
• You want a competitive Phase B robot that simplifies pickup at the cost of some placement complexity

Decision Matrix

For Spartan's 6-team program with mixed experience levels, the recommendation depends on team-by-team skill: rookies to Architecture A, experienced returners to B or C. Cross-team consistency is less important here than for the drivetrain — teams can have different manipulator architectures without breaking shared learning.

Why Cup Orientation Matters

The reveal video is explicit: "placing a pin into the opaque side of a cup prevents that color from being scored." This means a cup placed wrong-way-up on a pin is the same as not placing a cup at all (from a scoring standpoint). Worse, if you do this on every cup placement, you score zero points from your cup work for the entire match.

Your manipulator must do one of three things to handle this:

1. Always pick up cups in a known orientation — if cups always come out of the loader transparent-side-up, then your gripper just maintains that orientation through placement. Easiest solution.
2. Detect orientation, rotate if wrong — sensor identifies opaque vs transparent side, gripper rotates the cup before placement if it's wrong. Most robust but most complex.
3. Always rotate to a known state — gripper always rotates the cup 0 degrees or 180 degrees before placement to match a fixed reference. Simpler than detection but assumes you know the starting orientation.

Which option you pick depends on how cups are presented to your robot. We don't yet know the loader mechanics from the manual — if loaders deliver cups in a known orientation, Option 1 works. If cups can come from the field in any orientation (e.g., descored from another team's goal), Option 2 is necessary.

Detecting Cup Orientation

Two viable sensor approaches:

• Optical sensor (V5 Optical 276-7405). Mount facing the cup's grip area. Detects color/brightness difference between opaque and transparent sides. The transparent side will read as "ambient" (whatever is behind the cup); the opaque side will read as the cup's solid color. Tunable threshold determines orientation. See Optical Sensor Deep Dive.
• Distance sensor. Mount facing the cup's grip area. The transparent side passes some IR light through; the opaque side reflects more. Distance reading differs between the two sides. Less reliable than optical for this specific case.

Optical is the standard answer here. It's purpose-built for color/material discrimination and the opaque/transparent distinction is exactly the kind of contrast it was designed for.

Rotating the Cup

If your sensor detects the cup is wrong-way-up, your gripper needs to flip it. Three implementation patterns:

Defensive Cup Placement (If Legal)

The flip side of the orientation rule is that you can deliberately place a cup wrong-way-up over an opponent's pin to deny them the points. Whether this is legal depends on the manual's descoring and interaction rules.

If legal, this becomes a significant defensive play. Your robot would need a mode where it deliberately places cups in their opaque-up orientation. The implementation is the same hardware as orientation correction — just used inverted. Wait for the manual before designing strategy around this.

AprilTag Identification on Goals

The reveal video confirms: "all of [the goals] are equipped with AprilTags for vision sensor identification, regardless of starting alliance." This is significant for an autonomous and skills program. The AI Vision Sensor (276-8659) reads up to 38 distinct AprilTag IDs (numbered 0-37) within a ~73° field of view.

Specific tag IDs and goal-to-ID mapping are not yet published — expected in the manual or via VEX's game-specific update. Once known, your manipulator's autonomous code can navigate to a specific goal by ID, identify it visually, and align before scoring.

For now, design the manipulator's programming to support AprilTag-based alignment without committing to specific IDs. See AprilTags Deep Dive for the integration patterns.

Optical Sensor for Cup Orientation

As discussed in Section 4, the V5 Optical Sensor (276-7405) is the right tool for opaque/transparent discrimination. Mount it inside the cup gripper, facing the inner surface of the captured cup.

Tuning:

• Brightness threshold — transparent side reads through to ambient/whatever is behind; opaque side reflects bright cup color. Set threshold based on your specific cup color and ambient lighting.
• Calibration ritual — before each match, run a calibration that captures the "clearly opaque" reading and the "clearly transparent" reading. The midpoint is your threshold.
• Multi-sample averaging — take 5–10 readings and average. Single readings can flicker due to ambient light changes; averaged readings are stable.

Distance Sensor for Goal Alignment

For close-range goal alignment (the last 6″-12″ before placement), a distance sensor often beats vision. Mount one facing forward on the manipulator. Drive to within sensor range of the goal, then close the loop on distance:

• Coarse approach: AprilTag-based heading and approximate distance via vision.
• Fine approach: distance sensor confirms exact distance from manipulator face to goal rim.
• Place: motor commands placement only when distance is in a tight tolerance (e.g., 2″ ± 0.5″).

This is the standard sensor stack for VEX manipulators that need both global navigation and local precision.

Color Sensor for Pin Identification

If your manipulator picks up pins one at a time and you want to identify which pin you're holding (for strategic decisions: e.g., is this a red/blue dual or a yellow/yellow?), a color sensor on the gripper interior reads the pin's color combination.

This is optional. Many teams skip it and let the driver visually verify before pickup. Depends on your cycle time and driver workload tolerance.

Sensor Stack Summary

For a competitive Override manipulator, the typical sensor configuration is:

The temptation with manipulators is to build the whole thing at once. Don't. Override's manipulator has at least three independent design problems (pin grip, cup grip, orientation control) and stacking them all at once means you can't debug any of them. Build in stages, test at each stage.

Match-Day Tuning Sequence

1. Calibrate optical sensor against ambient lighting at the venue. Field lighting differs from your build space.
2. Verify AprilTag detection at the actual goal positions. Some venues have lighting that makes tag detection unreliable.
3. Test grip force with a fresh battery. Battery sag during practice can hide grip force issues that emerge mid-match.
4. Time a full cycle in match conditions. Cycle time longer than 8 seconds means you score 8–10 stacks per match instead of 12–15. Look for what's slow.
5. Practice cup orientation correction as a separate skill. Have a teammate hand you cups in random orientations; verify your robot always places transparent-side-up.

STEM Highlight — Engineering Tradeoffs

Interview Talking Points

Check for Understanding

What to Put in Your Engineering Notebook

• The architecture decision matrix. Show the comparison from Section 3. Write down the team values you weighted. Show why the chosen architecture won.
• Cup orientation sensor calibration data. Optical sensor readings for opaque side vs transparent side, your threshold, how it differed across lighting conditions. Numbers and graphs are notebook gold.
• Cycle time evolution. Track cycle time as you iterate. The graph that shows 14 sec → 11 sec → 8 sec across iterations is exactly what judges want to see.
• Failure log. Every time the manipulator failed during testing, note what happened, what you changed, and whether it worked. This is the "iteration" story judges look for.
• The 1+1 possession limit constraint. Document how you ensure the robot doesn't accidentally exceed the limit. This shows judges you read the rules carefully.

Related Guides