⚠️ Hardware First

Check Your Robot Before You Code

Half of all "my code is broken" problems are actually hardware problems. This guide teaches you to verify the robot before opening VS Code — saving hours of debugging code that was never the issue.

1
Why First
2
Physical
3
Ports
4
Spin Test
5
Pre-Flight
// Section 01
Hardware First, Code Second
The most common beginner mistake in VRC programming is not a coding mistake at all — it is trying to debug code when the problem is the robot.
⚠️
The rule: never open VS Code until you have verified the robot hardware is correct. A motor on the wrong port looks exactly like a code error. A reversed motor looks exactly like a wrong sign in your chassis config. A dead battery looks exactly like a PID tuning problem.

Real Examples of Hardware Problems Disguised as Code Problems

Looks like
Wrong chassis port number in code
Robot turns when it should go straight. Student changes port numbers for 30 minutes.
Actually
Motor physically plugged into wrong smart port on the Brain.
Looks like
Negative port sign wrong in chassis config
One side of the drive spins backward. Student inverts signs in code.
Actually
Motor cartridge inserted backward, or motor mounted inverted on the robot.
Looks like
PID constants are way off
Robot stops short every time, inconsistently. Student retunes kP for an hour.
Actually
Battery at 40% — low voltage causes inconsistent motor speed that looks like a tuning problem.
Looks like
IMU heading drift in code
Robot turns to the wrong angle every time. Student digs into EZ Template config.
Actually
IMU mounted at a tilt — even 5 degrees off from flat causes heading errors.

Your First Diagnostic Tool: the Brain Screen

Before writing a single line of code, power on the V5 Brain and navigate to the Device Info screen. This screen shows every motor and sensor the Brain can detect — and their status. If a device is missing from this screen, it is a hardware problem. Fix it before touching VS Code.

V5 BRAIN — DEVICE INFO
P1V5 Motor✓ Connected
P2V5 Motor✓ Connected
P7V5 Inertial✓ Connected
P4V5 Motor✗ Not found
Port 4 not detected — check cable seating before coding
💡
How to get to Device Info: from the Brain home screen, press the V5 logo or navigate to Settings → Device Info. Every connected smart device appears here with its port number and type. Anything missing is a hardware issue — cable not fully seated, damaged port, or wrong port number.
// Section 02
Physical Inspection
Walk through the robot with your hands, not your eyes. Things that look fine from a distance often have a loose screw, a pinched wire, or a disconnected cable that will cause a failure mid-run.

Click each item to expand the inspection detail. Work through these in order — structure first, then power, then sensors.

⚙️
Drive motors secured — no loose motor screws
Check

Grip each drive motor and try to wiggle it. It should not move relative to the chassis. Check the two mounting screws on each motor — they work loose over time from vibration.

  • Use a flat-head screwdriver to tighten any loose motor mounting screws
  • Check the motor shaft collar — if the shaft slides in and out, the collar set screw is loose
  • On a 4-motor or 6-motor drive, check every motor — not just the ones you can see easily
Why it mattersA loose drive motor shifts position during a match, changing the effective wheel track width. This causes odometry drift that looks like a calibration problem but is actually a mechanical one.
🔌
All smart cables fully seated at both ends
Check

Each smart cable has a small locking tab. Press it in and pull to confirm it is actually latched — do not just tug. Follow every cable from the motor to the Brain port.

  • A cable that looks seated but is not latched will disconnect under vibration
  • Check for cables routed over sharp edges or moving parts — they will eventually abrade and fail
  • Zip-tie or velcro cables away from wheels, axles, and any rotating mechanism
  • After seating each cable, verify the device still appears on the Brain's Device Info screen
Why it mattersA partially connected smart cable can cause intermittent connection loss during a match. The motor goes dead mid-autonomous and the robot thinks it completed the motion — causing every subsequent movement to be in the wrong position.
🔋
No pinched or kinked wires near moving parts
Check

Manually move every mechanism through its full range of motion — arm up and down, claw open and closed, drive wheels forward and back. Watch cables as mechanisms move.

  • Any cable that gets pulled tight at any point in the range of motion will eventually fail
  • Add slack loops in cables that cross pivot points (arms, claw joints)
  • Cables crossing moving joints should have a service loop — extra cable coiled near the joint
Why it mattersA pinched cable causes intermittent connection errors that only appear during specific robot positions — exactly the positions you need during a match. These are the hardest failures to diagnose remotely.
🔋
Battery seated fully and latch clicked
Check

Press the battery firmly into its mount and confirm the latch is engaged. The Brain should show a solid battery icon — not a flashing one.

  • Check the battery percentage before every coding session — aim for above 70%
  • A battery below 50% causes inconsistent motor performance that mimics PID tuning problems
  • If the Brain shows the battery icon flashing, the battery connection is intermittent — reseat it
Why it mattersV5 motor speed is voltage-dependent. A fresh battery drives at a different speed than a depleted one. If you tune PID with a fresh battery then run matches on a tired one, your autonomous will fail. Always tune and test with the same battery charge state.
📏
IMU mounted flat — parallel to the floor
Check

Place the robot on a flat surface. Look at the IMU from the side — its top face should be level with the floor, not angled. Even a 5-degree tilt causes heading errors.

  • The IMU measures rotation around its vertical axis — if that axis is tilted, it measures a combination of axes instead
  • The IMU can be mounted anywhere on the robot, but must be flat and away from large motors (electromagnetic interference)
  • Mount with both screws — a one-screw mount vibrates and shifts over time
  • After remounting, always re-run chassis.initialize() to recalibrate
Why it mattersA tilted IMU is one of the most common causes of "my turns are always off by the same amount." It is a hardware problem that no amount of PID tuning will fix.
⚙️
Drive axles spin freely with no binding
Check

Lift each side of the robot and spin the drive wheels by hand. They should spin freely with minimal resistance. If a wheel is stiff or catches, find the mechanical source before coding.

  • Shaft collars too tight against a c-channel hole cause axle binding
  • A bent axle will feel bumpy when spinning — replace it
  • Bearings not seated flush in their holes add drag — press them in fully
  • Wheel screws over-tightened into a drive insert can bind the wheel to the shaft unintentionally
Why it mattersMechanical friction reduces the effective speed range of your motors. Your drive may feel sluggish at low power and your PID settle will be inconsistent. Remove all mechanical resistance before tuning.
Your robot's autonomous always veers left, even though the code looks correct. What should you check first?
⬛ Increase the kP constant on the right side
⬛ Re-download the EZ Template library
⬛ Physical inspection — check motor seating, cable connections, and axle drag on both sides
⬛ Change the chassis drive type in code
// Section 03
Port Mapping & Device Verification
Document every port assignment before writing code. This log becomes notebook evidence and the reference your whole team uses when wiring changes.
💡
Fill this in from the Brain — not from memory. Go to the Brain's Device Info screen, read each port and device type, and record them here. Your code port numbers must match this table exactly.

How to Read the Brain Device Info Screen

1

Power on the Brain and navigate to Device Info

From the Brain home screen: tap the V5 logo → Settings → Device Info. Every detected smart device appears with its port number and device type.

2

Record every port in the table below

For each device shown, enter the port number, device name, and what mechanism it controls. The "Code Port" column is what you will use in your ez::Drive chassis declaration — include the negative sign if the motor needs to be reversed.

3

Flag anything missing

If a device you expect to see is not on the screen, do not move on. That is a hardware problem to fix before writing code. Check the cable seating at both ends.

Port Assignment Log

This table saves automatically. Use it as your reference when configuring ez::Drive and declaring motors in globals.hpp.

Port Assignment Log
Brain Port Device Type Mechanism / Label Code Port Direction

Translating the Log to Code

Once your port log is complete, your ez::Drive declaration in main.cpp uses those exact numbers. Negative means reversed:

ez::Drive chassis( {1, -2, 3}, // left drive ports — negative = reversed {-4, 5, -6}, // right drive ports 7, // IMU port 3.25, // wheel diameter (inches) 200 // cartridge RPM: 100=red, 200=green, 600=blue );
📝
Notebook entry tip: take a photo of the Brain's Device Info screen and include your port log as a table in your engineering notebook. This documents the build-and-code connection that judges want to see — evidence that programming happened in parallel with hardware setup.
Your code has ez::Drive chassis({1, 2, 3}, {4, 5, 6}, 7, 3.25, 200) but motor 3 is actually plugged into port 8 on the Brain. What happens?
⬛ Nothing — EZ Template auto-detects the correct port
⬛ Port 3 shows no motor — the left drive will behave as if one motor is missing
⬛ The code will not compile
⬛ The motor on port 8 will run at double speed
// Section 04
Motor Direction & Spin Test
Verify every motor spins the correct direction before you upload any code. The Brain's built-in motor test lets you do this without writing a single line.
🎯
The rule: lift the robot off the floor before the first driver control test. A robot that drives in the wrong direction — or has one side reversed — will launch into a wall at full speed. Lift first, verify, then put it down.

Using the Brain's Motor Test (No Code Required)

1

Navigate to the motor test on the Brain

From the Brain home screen: tap the V5 logo → Devices → select any Motor. You will see a control panel with a voltage slider. This lets you spin that specific motor directly from the Brain.

2

Spin each drive motor individually at low voltage

Set voltage to about 30 (roughly 25% speed). Spin each drive motor one at a time. Watch which direction the wheel turns. You are looking for: left motors all spinning in the same direction, right motors all spinning in the same direction, and left/right sides mirrored so the robot drives straight when both sides run positive.

3

Record which motors need to be reversed in code

If a left-side motor spins the wrong way relative to its neighbors, it needs a negative port number in your chassis config. Record these findings in your port log before writing any code.

What Correct and Incorrect Looks Like

✓ Correct — tank drive
All left motors spin the same direction.
All right motors spin the same direction.
Left and right sides are mirrored.
When running positive power on both sides, the robot drives forward when placed on the ground.
✗ Needs fixing
One motor on the left side spins opposite to the others. Fix: add a negative sign to that motor's port number in your ez::Drive chassis config. Do not re-wire the physical motor.
ℹ️
Fix direction in code, not hardware. When a motor spins the wrong direction, the correct fix is to negate the port number in code (e.g., change 3 to -3). Do not flip the physical cable or re-wire the motor — that creates confusion for anyone who works on the robot later.

The Lift Test — First Driver Control Run

After uploading code for the first time, follow this sequence before putting the robot on the floor:

1

Lift the robot completely off the floor

Hold it securely or place it on blocks. All four wheels should be off the ground with clearance to spin freely.

2

Enable driver control and push both sticks forward

All drive wheels should spin forward. If any wheel spins backward, that motor's port needs to be negated. If the robot spins in place, the left and right sides are reversed — swap the port arrays in your chassis config.

3

Test turning in the air

Turn left and right. Left turn: right wheels forward, left wheels backward. Right turn: left wheels forward, right wheels backward. Confirm this is what you see.

4

Only then put it on the floor

Once all directions are verified in the air, carefully place the robot down and test driving slowly. The first floor test should be at reduced speed — set chassis.set_max_speed(60) in initialize until you are confident everything is correct.

You upload code and enable driver control. The robot spins in circles instead of driving straight. What is the most likely cause?
⬛ The kP value is too high
⬛ The left and right port arrays are swapped in the chassis config, or one side has all motors reversed
⬛ The IMU needs recalibration
⬛ The battery is too low
♨️
Motor thermal limits — know these before long practice runs. Every V5 Smart Motor is current-limited to 2.5A by VEXos. At stall (motor commanded but blocked), all 2.5A converts to heat with zero mechanical output. Within 30–60 seconds of continuous stall, the motor triggers internal thermal protection and stops responding. For Skills runs and extended practice, watch the Brain’s device screen — motors with yellow or red temperature indicators need a 1–2 minute cool-down before running again. Add stall detection code to intake and arm motors to prevent this automatically. See the Stall Detection guide for implementation details.
// Section 05
Pre-Programming Checklist
Complete this before every new coding session. Your progress saves automatically. All boxes should be checked before you open VS Code.
0 of 16 checked
0%
Physical verification
Power and sensors
Port mapping and device verification
Ready to open VS Code
⚙ STEM Highlight Engineering: Systematic Verification & Root Cause Analysis
The pre-programming check is a structured verification protocol — the engineering equivalent of a preflight checklist. In aviation, checklists eliminate the largest category of human errors: forgetting steps. The key insight is that systematic verification (checking every port, every motor direction) is faster than symptom-driven debugging (spending 30 minutes wondering why the robot spins when it should go straight). A hardware error looks identical to a software error until you verify the hardware — this is the principle behind separating concerns in engineering diagnosis.
🎤 Interview line: “We run a systematic hardware verification protocol before every coding session. This is based on the engineering principle that hardware errors and software errors produce identical symptoms — you cannot diagnose code if you haven’t verified the hardware first. Our checklist eliminates entire categories of false debugging paths.”
🔬 Check for Understanding
Your robot turns right when commanded to go straight. You suspect a code sign error. Before changing code, the first action should be:
Flip the sign on the right drive motors in robot-config.cpp
Verify in the Brain Device Info screen that all drive motors are connected, on the correct ports, and spinning the correct direction when commanded manually
Re-upload the code to see if it was a one-time error
Check the IMU heading to see if it is drifting
Related Guides
🌍 V5 GPS Sensor → ⚡ Wiring & ESD → ⚡ Battery Management →
← ALL GUIDES