| name | vibe-pcb-design |
| description | Use when designing custom PCBs for the robot (sensor breakouts, motor driver expansions, MCU base boards, IR sensor arrays) using AI-accelerated KiCad pipelines. From schematic intent to gerber-ready board with verification gates (DRC clean, footprint match, BOM sanity, JLCPCB-compatible). The robot already uses a custom "Zircon" board — this skill applies for new boards or revisions. |
Vibe PCB Design — Pipeline IA → Placa Fabricable
Status: outline only — content pending iteration.
When to use
- Diseñar una placa nueva (sensor breakout, expansión, daughter board).
- Revisar la placa Zircon (Rev v15 actual) para una revisión vXX.
- Auditoría de schematics existentes en
hardware/electronics/.
- Diseñar un PCB de IR sensor array para detección de pelota / línea.
When NOT to use
- Cambios al firmware sin tocar hardware — usar
vibe-robotics-coding.
- Cambios mecánicos puros — usar
vibe-mechanical-design.
- Decisiones de sourcing puras (sin diseño nuevo).
Pipeline esperado (planned content)
[TODO: desarrollar con la placa Zircon como referencia base]
- Intent capture — qué hace la placa:
- Qué se conecta (lista de I/O, alimentación).
- Restricciones de tamaño (¿cabe en el chasis?).
- Costo target (Argentina / JLCPCB).
- Component selection — IA propone components con sourcing:
- Mouser / DigiKey (para componentes que se piden internacionales).
- JLCPCB Parts Library (para assembly automático).
- Sourceables en Argentina (cuando aplica).
- Schematic generation — KiCad schematic estructurado:
- Jerárquico si tiene sentido (módulos: power, sensors, comm, MCU).
- Net naming consistente.
- Bypass caps en cada IC.
- PCB layout — IA orienta routing, IA verifica DRC.
- Verification gates antes de fabricar:
- DRC clean (sin errores de design rule).
- Footprint match contra datasheets reales (no contra LCSC genéricos).
- BOM sanity check (componentes sourceables, costo razonable, alternativas).
- Compatibilidad con casa de fabricación (JLCPCB / PCBWay / local).
- Test points presentes para debugging.
- Power rail decoupling correcto.
- Conectores con polarización (no se pueden enchufar al revés).
- Output — schematics + Gerbers + BOM + pick&place en
hardware/electronics/board-name-revXX/.
Verification gates (no negociable)
- DRC clean antes de exportar gerbers.
- Cada IC con su decoupling cap (regla del pulgar: 100nF cerca de cada VCC pin).
- Cada conector con label de pinout (en silkscreen).
- BOM con part numbers reales y links.
- Para revisiones de Zircon: regression test contra firmware existente (
zirconLib).
- Test point en cada power rail crítico (3.3V, 5V, motor V+).
Context: placa Zircon
[TODO: capturar info concreta de Zircon Rev v15 desde hardware/electronics/Zircon.pdf]
Lo que ya sabemos:
- MCU: Teensy 4.1 (montado, no integrado).
- Drivers de motor: U5, U7, U17 (3 drivers H-bridge para 3 motores omni).
- Pinout maestro: documentado en
software/libraries/zirconLib/zirconLib.cpp y journal/2026-03-20-diferencias-pines-motores-arquero-delantero.md.
- Diferencia entre robots: mismo PCB pero ROBOT1 (arquero) y ROBOT2 (delantero) usan pines lógicos diferentes — definido vía
#define ROBOT1 / #define ROBOT2.
Si se hace una revisión Zircon:
- Considerar uniformar pinout entre arquero y delantero (eliminar las divergencias documentadas el 2026-03-20).
- Considerar agregar lo que falta en Rev v15 (¿ESP32 onboard? ¿conector dedicado para módulo árbitro RCJ?).
JLCPCB compatibility checklist
References
hardware/electronics/Zircon.pdf — schematic actual Rev v15.software/libraries/zirconLib/zirconLib.cpp — firmware library que asume el pinout.journal/2026-03-20-diferencias-pines-motores-arquero-delantero.md — divergencias entre robots.AI-INSTRUCTIONS.md sección 7.
