How you plan your autonomous route matters as much as how you code it. Match autonomous and Skills autonomous are fundamentally different games with different objectives, time limits, and risk profiles — and they require completely different planning approaches.
VRC Push Back is played on a 12′×12′ field. Matches consist of a 15-second autonomous period followed by a 1:45 driver-controlled period. The alliance that scores more points in the autonomous period is awarded 10 bonus points added to the final score. Each alliance also has the opportunity to earn an Autonomous Win Point by completing assigned tasks.
In a Skills match, teams can use any legal starting position for the red alliance and must remain in the red alliance station. There are more ways to score in Skills matches, and the way you earn control zone bonuses is different from head-to-head matches.
Each team gets up to three driving skills matches and three autonomous coding skills matches. This means each event gives you three attempts to set your best skills score — plan accordingly.
Every season publishes specific tasks that must be completed to earn the Autonomous Win Point. Read the current game manual carefully — the AWP tasks change every year. Before planning any scoring route, confirm:
Your baseline autonomous must always complete the AWP condition at 95%+ reliability. Everything else is bonus.
In match autonomous, you are not allowed to touch foam tiles, scoring objects, or field elements that begin the match on the other side of the autonomous line. This means your route is constrained to your alliance’s half of the field. Map every scoring element on your side and calculate their point values.
Think of your match autonomous in three tiers, from safest to most aggressive:
Before every match, confirm with your partner:
| Action | Points | Est. Time | Pts/sec | Priority |
|---|---|---|---|---|
| Score near element (close to goal) | 3 | 1.5s | 2.0 | High |
| Score far element (travel required) | 3 | 4.0s | 0.75 | Low |
| End-game action (climb/park) | Variable | 3–8s | Depends | High if worth >15 pts |
| Control zone bonus | Bonus | — | Free if on route | Always include |
| Element far off optimal route | Any | +6s detour | Very low | Usually skip |
With three runs per event, you can be strategic about which routes you attempt:
Use a top-down field diagram. VEX publishes the official field layout in the game manual appendix. Print it at a scale where you can draw on it, or recreate it on graph paper with your team. Mark all game elements, goals, and zone boundaries.
The starting position is not “near the left tile” — it is a specific corner, a specific orientation. Mark it as a point with an arrow showing heading. The robot’s starting position should be repeatable to within 1 centimeter and 1 degree across every practice run — use physical reference marks on your practice field (tape on the tiles).
Draw the robot’s center path from start to first element, to goal, to next element, etc. Label each waypoint with:
Before writing a single line of code, push the robot along the planned route by hand in the pit. Does the path physically work? Does the robot fit through that gap? Does the arm clear the goal structure? Does the approach angle to the element make sense mechanically? Physical walkthrough catches about half of all route problems before they become code problems.
Add up estimated times for every movement and action. Compare to your available window (15 seconds for match, 60 seconds for skills). If you are over budget, identify which elements to cut — lower pts/sec actions first. If significantly under budget, add one more element.
After finalizing a route, create a “route card” — a single index card or laminated sheet that the drive team keeps at the field:
PATH.JERRYIO works best for teams with odometry (position tracking) — it outputs X/Y coordinates that assume the robot knows its position on the field. For EZ Template teams without odometry, its primary value is as a planning visualization tool rather than a code generator:
pid_drive_set() and pid_turn_set() values in your EZ Template codeTeams running LemLib (an advanced PROS library with odometry) can use PATH.JERRYIO’s full code generation. LemLib is an open-source C++ library that introduces common path-following algorithms like Pure Pursuit and Boomerang. PATH.JERRYIO can generate path files for the robot, which will be used by the robot to travel the designed paths in the autonomous period with path-following algorithms.
This is beyond the scope of most middle school teams using EZ Template, but it is the direction the most competitive high school teams move toward as they advance.
VRC foam tiles vary between fields. Older tiles are more compressed, producing less friction. Brand-new tiles have slightly different texture. Your robot’s drive PID was tuned on your gym’s tiles — at competition, those same values may produce a different distance. Mitigation: test on your competition field’s tiles during the practice window before the event. If driving long or short, adjust the target distance in code before the first match.
Where two tiles meet, there is a small seam that can deflect the drive slightly. Competition fields are assembled by volunteers and the seams are not always perfectly aligned. A route that crosses many tile seams accumulates small heading errors. Mitigation: use the IMU for heading correction (EZ Template does this automatically). Run your autonomous on the event field during practice time and verify the ending position.
If your robot starts 0.5 inches further left than intended, a movement that was supposed to end at a goal may miss it by 0.5–1 inch at the end of a 36-inch drive. For tight scoring sequences, this matters. Mitigation: use a physical reference — robot back corner against the tile edge, robot side against the perimeter wall. Develop a consistent pre-match placement ritual and practice it.
Game elements are placed manually before each match. The game manual specifies their starting positions, but human placement has tolerance. An element that should be at a specific coordinate may be 0.25–0.5 inches off. Mitigation: design your intake approach with a wider collection window. Drive slightly past the element’s expected position if your intake can catch it on the way. Never build a route that requires hitting a precise element location with no margin.
Drive PID performance changes with battery voltage. A 12.0V battery produces different motor output than a 12.5V battery at the same power command. Early in the day with a fresh battery, your robot may drive slightly faster and overshoot. Late in the day or after many runs, a lower battery may cause undershoot. Mitigation: fully charge batteries before every skills run. Run autonomous only on batteries at 12.4V or above. Consider adding a battery voltage check at the start of autonomous and adjusting drive speed accordingly.
The IMU must calibrate while the robot is completely stationary. If the robot is placed on the field and then bumped or moved after calibration, heading will be off. Competition venues also sometimes have vibration from other matches running nearby. Mitigation: calibrate the IMU as the last step before the match starts. In EZ Template, chassis.initialize() calls IMU calibration automatically in the initialize() function. Verify the IMU shows calibrated on the Brain screen before stepping back from the robot.