The Hardware Reality of Vision Systems

Lessons 3–8 treated the coprocessor as an already-working black box: PhotonVision is running, the camera is connected, the dashboard is accessible. This lesson is about building and maintaining that black box so it actually works at competition, not just in your shop.

Software configuration problems are usually fixable at the venue — you can redeploy code in the pit, update pipeline settings from a laptop, adjust standard deviations between matches. Hardware configuration problems are often not fixable without tools, spare parts, or internet access you won't have at a competition. The decisions in this lesson — which coprocessor to use, how to power it, how to mount cameras, which IP addresses to assign — need to be made and validated long before competition day.

Hardware Selection

Robot Network Architecture

Every device on the robot — roboRIO, radio, network switch, coprocessor(s) — must be connected correctly to work together. Click any component in the diagram below to understand its role, its IP address, and what happens if it's misconfigured.

Static IP Address Assignment

Every device that communicates on the robot network must have a fixed IP address. DHCP (automatic IP assignment) works in your shop but is unreliable at competition venues — the order in which devices connect to the network can cause them to receive different IPs, breaking all communication. Assign static IPs to every device before your first competition and document them.

All robot network IPs use the 10.TE.AM.x pattern, where TE.AM is your four-digit team number split across two octets. For team 2910: 10.29.10.x.

Powering the Coprocessor Safely

Coprocessors require stable 5V power at 2–4A depending on the board and USB load. There are three common approaches, each with different tradeoffs:

• VRM (Voltage Regulator Module) 5V/2A port: The simplest approach. The VRM is designed for exactly this use case — providing stable regulated 5V for coprocessors and other electronics. Maximum 2A — sufficient for a Pi 4 with two cameras, but watch the total current draw. Do not power coprocessors from VRM ports that are also powering other loads (radio, sensors).
• PDH (Power Distribution Hub) USB-C port: The REV PDH includes dedicated USB-C power ports (5V/3A). This is the cleanest solution for newer robots — no adapter needed, current-limited per port, and the PDH monitors current through its fault-detection system.
• Dedicated 5V regulator (e.g., CTRE HERO, REV MPM, or buck converter): For teams running Pi 5 or Orange Pi 5 at high load, a dedicated switching regulator can provide 5V/5A reliably. Requires more wiring but provides the most headroom.

Camera Mounting and USB Wiring

Camera mounting principles

The robot-to-camera transform (Lesson 2) is only valid as long as the camera is in the position you measured. Three mounting requirements that prevent invalidating your calibration between matches:

• Rigid mounting: The camera must not flex, vibrate, or shift when the robot collides with field elements or other robots. Bolt the camera mount through a rigid frame member or bumper bracket with locking hardware. Zip ties on flexible plastic are not acceptable for competition.
• No post-event adjustments: Once the camera is calibrated and the transform is measured, don't move it. If you need to adjust the camera angle to improve detection, do so in the shop, then recalibrate and remeasure the transform before the next competition.
• Cable strain relief: The USB cable to the camera must have strain relief at both ends. A cable that pulls on the camera connector during robot motion will eventually break the connection mid-match. Secure the cable with zip ties within 5 cm of the camera connector and at every frame crossing.

USB bandwidth constraints for multiple cameras

USB 3.0 has approximately 5 Gbps of bandwidth. A single 1280×720 camera at 60fps (MJPEG compressed) uses roughly 20–40 Mbps — well within limits. However, USB bandwidth is shared per controller: a Raspberry Pi 4 has one USB 3.0 controller shared between its two USB 3.0 ports. Two cameras at 1280×720/60fps both on USB 3.0 use about 80 Mbps total, which is comfortable. Adding a third camera on USB 3.0 may cause intermittent drops. If you need three cameras, either drop resolution/fps, or use a USB 3.0 hub with a dedicated controller, or add a second coprocessor.

First-Time Coprocessor Setup Walkthrough

Pre-Event Verification Checklist

Run this checklist at the start of every competition event — before the robot leaves the pit for its first match. Assume you cannot access the internet or reflash the SD card. Everything must be verifiable on-site in under 5 minutes.

□  Dashboard accessible at static IP (10.TE.AM.11:5800)?
      → Navigate from pit laptop. If not: check Ethernet cable, switch power,
        and verify coprocessor has booted (LED activity).

□  Live camera stream visible and updated?
      → Open dashboard. Should see camera feed updating (not frozen).
        If frozen: re-seat USB cable. If no feed: wrong camera name or driver issue.

□  Tag detections appear (green outlines) when facing a tag?
      → Hold an AprilTag from the current season at 1–2 m.
        No green outlines = wrong tag family, bad calibration, or exposure too high.

□  Calibration is loaded (RMS shown in Calibration tab)?
      → Open Calibration tab. Confirm "Calibration loaded" and RMS value.
        No calibration = all distance estimates will be wrong.

□  Pipeline set to correct tag family (TAG_36H11)?
      → Check Tag Family dropdown in pipeline settings.
        Wrong family = no detections or false positives on the competition field.

□  Robot code shows camera connected (Vision/CameraConnected = true)?
      → Enable robot in test mode. Check SmartDashboard.
        false = camera name mismatch or coprocessor not yet on network.

□  Vision/HasTargets goes true when facing a tag at 2–4 m?
      → Point robot at a field tag from typical autonomous starting range.
        false despite dashboard showing detection = camera name mismatch.

□  Field2d shows reasonable vision pose estimates?
      → Open Field widget. Navigate robot to a known position.
        Verify vision estimate is within ~20 cm of expected position.
        Large systematic offset = robot-to-camera transform or field layout issue.

□  Vision fusion counter increments during auto?
      → Run 5 seconds of autonomous facing tags.
        Check Vision/FusionCallCount (from Lesson 6). Should increment 30–60x.
        Zero = data flow between VisionSubsystem and DriveSubsystem is broken.

Making the Setup Competition-Resilient

Competition introduces failure modes that don't exist in the shop: full-field bumps from other robots, rapid temperature changes between matches, field electrical transients affecting power quality, and the tight timeline of a match queue that prevents rebooting and waiting. These practices address those specifically.

• Use a quality MicroSD card. SanDisk Endurance or similar rated cards handle the continuous write load of vision processing better than generic cards. A card that corrupts under write load loses your calibration and pipeline settings mid-event.
• Secure the coprocessor with standoffs and screws, not Velcro. Velcro fails after repeated collisions. The coprocessor should be mounted with M2.5 or M3 standoffs to a rigid panel — typically the electronics board. It must not move when the robot is bumped hard.
• Label every cable. At least two labels per cable (both ends) with the device name and purpose. In the pit queue with 8 minutes before a match, you cannot afford to trace an unmarked cable to figure out what it does.
• Bring a spare SD card with a known-good image. If the coprocessor's SD card fails during the event, having a pre-flashed spare with the current season's PhotonVision image, your static IP, pipeline configuration, and calibration means recovery is minutes, not the entire event.
• Document your coprocessor configuration in your team's pit guide. Static IP, camera names, pipeline names, calibration RMS, PhotonVision firmware version. Anyone on your pit crew should be able to verify the setup without asking the programmer who configured it.

🔌 System Check

Knowledge Check