[LeastOne]

Teams that plan in FTC field coordinates currently have to translate their waypoints into the visualizer's corner-based frame. This PR adds FTC coordinate planning and optional tile units so teams can plan Pedro paths using the same field-centered reference they use on their robots.

1. Plan with the documented FTC coordinate system

Add Pedro, FTC, and FTC Inverted options. The FTC options follow the origin, axis orientation, and positive rotation conventions in FIRST's Field Coordinate System Definition, including the inverted square-field configuration.

A centered origin makes distances and targets relative to the field center easy to express. It also simplifies symmetry-based reuse of autonomous logic: a team can define a canonical plan and use alliance/starting-side signs to reflect positions and headings instead of maintaining separate waypoint sets. The README includes a compiled, checked Java enum example. The appropriate symmetry is game-dependent; this does not automatically generate alliance-selection code or claim improved localization accuracy.

Coordinate and heading editors, playback, ruler, grid/snapping, and points-array export follow the selected frame. Switching frames preserves the physical path. Java/Kotlin robot-code exports continue to use Pedro coordinates and inches.

2. Let students reason in tiles

Whole tiles, half tiles, and tenths of a tile are easier planning units for many students than estimating inch distances. Teams can enter fractional tile coordinates and switch to inches to inspect the same path.

When Tiles is selected, changing Inches per Tile preserves the entered tile positions, including control/through points, facing-point targets, custom obstacles, and undo/redo history. For example, FTC (2, 2) stays (2, 2) when the tile size changes from 23.5 to 24; its exported Pedro-inch position changes from (117.75, 23.75) to (118.75, 22.75). With Inches selected, physical positions stay fixed. Robot dimensions and motion settings remain in inches.

3. Ground the visualization in field geometry

The image, grid, snapping, GIF background, built-in obstacle outlines, and collision checks share the editable tile calibration. The 23.5-inch default rounds the approximately 23.502083-inch assembled tile repeat measured in FIRST's official BIOBUZZ STEP assembly. The README cites the FTC manual (§9.1–9.2), field setup guide, and Onshape assembly; a measurement record identifies the inspected archive and method.

The inherited 141.5-inch boundary and 70.75-inch center remain for project compatibility, rather than claiming exact CAD perimeter dimensions. Built-in obstacles remain approximate plan-view outlines, not full 3D collision meshes. Editing their vertices detaches them from automatic template calibration.

Integration and validation

• Coordinates and Units appears above Display, expanded by default; Display starts collapsed.
• Schema 2.2.0 persists coordinates and obstacle calibration, with legacy migration and recovery.
• 198 unit tests and 16 browser tests passed; type checks, ESLint, production build, and branch CI passed for the implementation.
• The documentation's standalone Java alliance example was compiled and run; coordinate/tile tests passed again after the documentation update.
• Historical golden fixtures retain their original acceleration limits.
• Prepared directly against upstream main; fork branding, Pages deployment, service-worker changes, and unrelated asset-path changes are excluded.

Opening as a draft for maintainer feedback on FTC planning, tile units, and the calibration approach.

[vercel]

@codex is attempting to deploy a commit to the baronclaps' projects Team on Vercel.

A member of the Team first needs to authorize it.

[BeepBot99]

Thanks for the contribution, but we do not want to add this feature.

• There is no reason for teams to "plan in FTC field coordinates"; their planning happens in the visualizer, not before.
• The official coordinate system is changing in January, and the FTC SDK will add support for the legacy and unified ones, so we should not support the old system that only exists for a couple more months.
• We are currently working on Visualizer 3, a rewrite of the visualizer, so we do not want to add major new features to the current one. Visualizer 3 will use the new unified coordinate system.