🔌 Integration · Onshape + EZ Template · Intermediate

CAD to Code: The Engineering Thread

CAD decisions have direct consequences in EZ Template. Every number in your chassis constructor came from somewhere — and that somewhere is your Onshape assembly. This guide maps every connection explicitly.

From example to team implementation

Study → Predict → Adapt → Test → Explain → Credit. Copying examples is a useful way to learn. Understand the important behavior, choose and adapt configuration and controls for your robot, predict the results, then test and improve your implementation on the actual robot. Credit outside code where it appears.

Libraries provide reusable capabilities; you do not need to rewrite their internals. Your team chooses and configures them, writes team-specific behavior, tests it, and explains and credits their use. Official VEX-provided starting code needs no credit under GRSF policy; community examples are outside sources.

See the student-centered policy and Code Summary/Credit Summary guidance. Students explain their own implementation and learning.

Why this matters: Most students treat CAD and programming as separate workstreams. They're not. If your Onshape model has motor port 3 on the left front, your robot-config.cpp must have that. If your wheel diameter in CAD is 4.125", your chassis constructor must say 4.125". Every mismatch between CAD and code is a bug before you even write any auton.

🔌 The Connection Map — CAD → EZ Template

📐 Onshape Assembly → ⚡ EZ Template Constructor

📐 Onshape: Motor Position

Motor labeled "L-Front" at Brain port 1 in assembly annotations

→

⚡ robot-config.cpp: Left motors array

{-1, -2} // negative = reversed
Check motor direction in CAD

📐 Onshape: Wheel Part Properties

Right-click wheel → Properties → "Diameter: 4.125 in" (from VEX parts library)

→

⚡ main.cpp: wheel_diameter

4.125 // NOT 4.0
Always read from CAD, not memory

📐 Onshape: Drivetrain Width

Measure tool: center of left wheel to center of right wheel = 12.5 in

→

⚡ chassis.drive_width_set()

chassis.drive_width_set(12.5);
Used for odometry calculations

📐 Onshape: Tracking Wheel Offset

Mate connector position: tracking wheel center is 4.0 in right of robot centerline

→

⚡ tracking_wheel constructor

ez::tracking_wheel left_tracker
(port, 2.75, 4.0); // 4.0 = offset

📐 Onshape: Motor Cartridge Color

V5 Motor part → configuration: Blue (600 RPM) selected in configurator

→

⚡ main.cpp: MOTOR_GEAR

pros::E_MOTOR_GEAR_BLUE
// Blue=600, Green=200, Red=100

🔧 Robot Config Generator

Enter your measurements from Onshape. Generate a configuration example, review and adapt it, then test and explain the result. Keep the source comments when copying.

Left motor ports (comma-sep, - = reversed)

Right motor ports

IMU port

Wheel diameter (from Onshape)

Track width inches (Onshape measure)

Tracking wheel offset (if using odom)

📏 How to Read Measurements from Onshape

Wheel diameter: Right-click the wheel part in the Feature Tree → Properties. Check the diameter from the VEX parts library — 4" omni wheels are 4.125".
Track width: Tools menu → Measure. Click center of left wheel, then center of right wheel. Read the distance. Use this exact number.
Tracking wheel offset: In the Assembly, right-click the tracking wheel's mate connector → Edit. The X or Y offset from the robot's origin mate is your distance to center.
Motor ports: Add a text annotation to your assembly labeling each motor with its Brain port number. Update it whenever wiring changes.

The port map habit: Create a simple table in your engineering notebook: Motor → Location → Port → Direction. Update it every time wiring changes. When a motor fails and needs replacing at a tournament, you don't want to guess which port it was on.

📖

DOCUMENTATION: BOTH TOOLS

Onshape measurement tools and EZ Template drive constructor reference

⚡ EZ Installation → 📦 VEX Parts Library → 📏 Tracking Wheel Offset →

⚙ STEM Highlight Engineering: Systems Integration — CAD as a Design Specification

The translation from CAD model to working code is a systems integration problem. In professional engineering, a CAD model specifies exact constraints — gear ratios, pivot radii, link lengths — and the software team uses those measurements as inputs. When a robot’s drivetrain CAD specifies a 4:1 gear ratio, the code’s RPM calculations must use that exact ratio. Discrepancies between the mechanical design and software parameters are one of the most common causes of auton drift.

🎤 Interview line: “Our CAD model drives our code configuration. When we update gear ratios in Onshape, we update our EZ Template wheel settings to match. This systems integration approach eliminates a category of bugs where mechanical and software assumptions diverge. Our drivetrain documentation shows the CAD specs side-by-side with the code constants.”

Your Onshape model shows a 3.25-inch wheel diameter, but your EZ Template chassis is configured with 4.0 inches. What is the most likely symptom?

⬛ The robot drives faster than expected because the code thinks wheels are larger

⬛ Autonomous movements will consistently overshoot — the robot drives farther than commanded because the code calculates travel based on the wrong wheel size

⬛ The robot steers to the left because one side is configured differently

📝

Notebook entry tip: Build & Program — Orange slide — Write a CAD-to-code handoff entry: include your Onshape wheel diameter measurement, gear ratio from the CAD assembly, and the corresponding EZ Template config values. Side-by-side documentation of CAD specs and code constants shows judges that your software was derived from your design — not invented separately.