KUdos Electronics Bringup

Project Overview

This documents the bringup process for the KUdos custom electronics stack: taking the designed PCBs, firmware, and software from development to working competition robots.

Bringup involves assembly, initial power-on testing, firmware flashing, integration with robot mechanisms, and debugging the inevitable issues that arise when theory meets reality.

Role: Electronics integration lead

---

Why We Built This

The VEX V5 brain only supports two types of external connections:

• 3-wire ports: Simple analog/digital I/O
• Smart Ports: Proprietary protocol for VEX sensors

We wanted to use two things that don't work with either:

1. goBILDA Pinpoint Odometry Computer: Uses I2C communication - not supported by V5
2. Limelight Vision Camera: Provides data over NetworkTables/REST API - no way to interface with V5

The solution was a Raspberry Pi coprocessor that could speak I2C to the Pinpoint, HTTP to the Limelight, and RS485 to the VEX brain.

---

First Hardware Setup

Before designing a custom PCB, we prototyped with off-the-shelf components:

• Raspberry Pi Zero 2W: Main coprocessor
• Waveshare RS485 HAT: Amazon module for serial communication to V5 brain
• Pinpoint via headers: Connected directly to Pi's I2C pins using jumper wires

This setup worked but had significant limitations that drove the final design.

---

Challenges Encountered

Backwards Encoder Connector

Problem: The Pinpoint odometry sensor wasn't responding at all during initial testing.

Cause: The connector we made for the encoder pods was wired backwards - power was going to the signal pins and signal to the power pins.

Solution: Rewired the connector with correct pinout. This was a simple fix once identified, but caused hours of debugging.

Python Middleware Lag

Problem: No matter how much we tuned our PID controllers, the robot movements were sluggish and oscillating. The robot couldn't track paths accurately.

Cause: The original firmware was a Python script acting as middleware between the Pinpoint and VEX brain. Python's garbage collection and interpreter overhead added 50-100ms of latency to every sensor reading.

Solution: Rewrote the entire firmware in C++. The improvement was dramatic - sensor data came through in real-time and PID tuning finally worked as expected.

Before (Python): ~80ms round-trip latency
After (C++):     ~5ms round-trip latency

Unreliable Header Connections

Problem: The system would randomly disconnect or glitch during matches, especially after the robot took hits.

Cause: Using GPIO headers with jumper wires was inherently unreliable. Headers can wiggle loose, pins can bend, and connections degrade over time. Competition robots take a beating.

Solution: The custom RPi HAT design replaced all header connections with proper locking connectors. Even if we couldn't test the final HAT due to ordering delays, this was the primary motivation for designing it.

RS485 Direction Timing

Problem: Occasional message corruption when switching between TX and RX modes on the Waveshare HAT.

Cause: The GPIO direction pin wasn't being switched at the right time relative to UART transmission.

Solution: Used tcdrain() to wait for the UART buffer to fully flush before switching to RX mode.

---

Lessons Learned

1. Don't use Python for real-time control: The latency from Python's interpreter made PID tuning impossible. For anything time-sensitive, use C/C++.
2. Headers aren't competition-ready: What works on a bench falls apart when the robot gets hit. Locking connectors are worth the extra design effort.
3. Triple-check your pinouts: A backwards connector can waste hours of debugging. Label everything.
4. Sometimes you compete with the prototype: Ordering delays happen. Make sure your fallback setup is reliable enough to actually use.

---

Evolution to Final Design

Every problem from bringup drove a design decision in the custom RPi HAT:

Bringup Problem	HAT Solution
Headers wiggle loose during matches	Locking JST/Molex connectors
Waveshare HAT blocked I2C headers	Dedicated I2C ports on board edge
Encoder connector wired backwards	Keyed connectors with clear pinout labels
Multiple loose components	Single integrated board

Due to ordering issues, the final HAT wasn't tested before Worlds - we competed with the Waveshare HAT setup. But the HAT design addressed every reliability issue we encountered.

---

Timeline

Date	Milestone
Oct 2025	First bringup with Waveshare HAT and Python
Nov 2025	Identified Python latency issue
Jan 2026	Custom RPi HAT design completed
Jan 2026	C++ firmware rewrite (after HAT design)
Apr 2026	World Championship (competed with Waveshare setup)