open-soccer-robocup-team2026

Usar cuando un sensor ToF multizona VL53L7CX (o el VL53L5CX hermano) "no anda" o hay que leerlo/configurarlo/calibrarlo/usarlo para posicionar el robot de competencia (Teensy/Arduino, I2C) — distancias raras, loop lento por los ToF, el yaw del BNO se congela cuando los ToF rangean, zonas con status inválido, status 0 en TODAS las zonas, el boot tarda muchísimo, o hay que trilaterar / seguir pared con la matriz de distancias. Cubre resolución 4x4/8x8, modo continuo vs autónomo, frecuencia de ranging, filtrado por target_status, recorte de payload (VL53L7CX_DISABLE_*), coexistencia con el BNO055 en el bus, carga del firmware (~84 KB), calibración de xtalk/offset (cover glass), y posicionamiento por paredes. Triggers - "VL53L7CX / VL53L5CX", "ToF multizona / matriz de distancias", "4x4 / 8x8 / zonas / target_status", "el loop cae a 6 Hz por los ToF", "el yaw del BNO se congela con los ToF", "status 0 en todas las zonas", "el ToF tarda en bootear / carga firmware", "modo continuo vs autónomo", "calibrar xtalk / c

Usar cuando hay que entender, derivar, escribir o DEPURAR la cinemática de un robot omnidireccional de 3 ruedas a 120° — la matriz inversa (vx,vy,ω → 3 ruedas), las convenciones de signo/ejes, el término de giro ω·R, la saturación, o por qué el robot "da círculos en vez de trasladar", "traslada al revés", o "todo PID de rumbo amplifica el error en vez de corregirlo". Es la TEORÍA/matemática del omni-3; remite a la planta MEDIDA y al lazo para tuning. Triggers - "cinemática omni / inverse kinematics", "3 ruedas a 120°", "la matriz de las ruedas", "WHEEL_ANGLES / ángulos de rueda", "descomponer vx/vy/ω", "el robot da círculos / no traslada", "traslada para el lado equivocado", "el giro sale invertido / OMEGA_SIGN", "ω·R / término de rotación", "saturar las ruedas / clamp por rueda vs escalar", "convención +X/+Y, CW/CCW del robot", "convertir velocidad de rueda a PWM". NO es para tunear ganancias del lazo (control-pid-zona-muerta), NO es la planta medida —pisos PWM, deriva, regímenes— (dinamica-omni-3-ruedas), N

Use when calibrating or troubleshooting OpenMV cameras (H7 / H7 Plus) for the soccer robot — LAB color thresholds for orange golf ball (passive IR ball 2026) and cyan/magenta goals, exposure lock under varying field lighting, FOV and mount tuning, multi-camera consistency, frame rate vs accuracy trade-offs. Critical for Incheon where lighting differs from the IITA Salta lab.

Usar cuando el HEADING de un IMU "no anda" en firmware de robótica de competencia — clavado en 0.0, congelado, derivando, saltando, o el diag lee bien pero el firmware no — o al configurar/calibrar/recuperar/diagnosticar uno o dos BNO055 sobre I2C (Teensy/Arduino) con EMI de motores. Cubre modos (IMUPLUS vs NDOF), calibración y guardar/restaurar offsets (el chip NO tiene EEPROM), árbol de diagnóstico, recuperación de fallas y prácticas de competencia. Triggers - "heading no anda / clavado en 0.0", "el IMU se congela / freeze / yaw congelado", "el rumbo deriva / drift", "el heading salta", "el diag anda pero el firmware no", "calibrar BNO055", "guardar/restaurar calibración del IMU", "BNO055", "IMU", "Euler / quaternion", "IMUPLUS / NDOF", "CALIB_STAT / SYS_STATUS / clock stretching", "dos BNO en el mismo bus / 0x28 / 0x29", "EMI de motores / magnetómetro", "Teensy + IMU". NO es para tunear el lazo de heading-hold (control-pid-zona-muerta) ni para fusionar la pose XY (fusion-pose-odometria-landmarks).

Use when a PID/feedback loop oscillates violently, loses to a disturbance, or the actuator can't do small corrections (deadzone, PWM floors, bang-bang, all-or-nothing motors). Symptoms - robot spins on its axis, fishtails/serpentea, correction overshoots and re-corrects opposite, raising or lowering gains both fail, "pierde la pulseada" against parasitic drift. Covers deadzone compensation, PFM/duty-cycling, PI as automatic feedforward, anti-windup, bench tuning titration.

Use when changing ANY motion control on the CENTRAL board (strafe, rotation, heading hold, PID gains, speeds) of the IITA omni-3 robots - or when the robot drifts, rotates parasitically while strafing, moves "aplastado" in diagonal, or behaves differently below/above certain speeds. Contains the measured plant model - wheel geometry, PWM floors, FLOOR_SCALE behavior, parasitic yaw, physical minimums, validated speed regimes from bench data.

Use when implementing/EXECUTING a closed-loop controller on an MCU and the question is about the REAL-TIME and NUMERICAL realization, not the gains — sample-rate choice, continuous→discrete conversion, fixed-point vs float, loop latency / sensor-to-actuator delay, jitter's effect on a loop, multi-rate loops, discrete anti-windup & derivative filtering. Triggers - "frecuencia de muestreo / sample rate", "discretizar el PID / continuo a discreto", "Tustin / Euler / backward difference", "punto fijo / fixed-point / Q15 / Q8", "el dt varía / jitter en el lazo", "latencia sensor a actuador", "lazos multi-rate / lazo rápido y lento", "PID en C para microcontrolador", "el control tiembla por timing". For automotive/aero CONTROL examples see sistemas-criticos-tolerancia-fallas. NOT for TUNING gains on the quantized actuator (control-pid-zona-muerta), NOT for the omni plant model (dinamica-omni-3-ruedas), NOT for the general timing lens (tiempo-real-determinismo).

Use when designing or reasoning about an RTOS / multitasking firmware — tasks, priorities, preemptive scheduling, schedulability (RMS/EDF), priority inversion, mutex/semaphore/queue choice, ISR-to-task handoff, stack sizing, or deciding whether a project needs an RTOS at all. Triggers - "RTOS", "FreeRTOS / Zephyr / TeensyThreads / Zircon RTOS", "tareas / tasks", "prioridades", "scheduler / planificador", "preempción", "inversión de prioridad / priority inversion", "RMS / EDF / planificabilidad", "mutex / semáforo / cola / queue", "context switch", "stack overflow de una tarea", "ISR a tarea", "¿necesito un RTOS?". Covers scheduling theory + practical RTOS patterns and classic bugs. NOT for the general real-time/timing lens (tiempo-real-determinismo), NOT for control-loop discretization (control-embebido-tiempo-real), NOT for fault tolerance/redundancy (sistemas-criticos-tolerancia-fallas).

Use when the deadline IS safety — designing or reviewing fault-tolerant, fail-safe embedded control where a miss can hurt someone or destroy hardware. Covers fail-safe state design, watchdogs (windowed), redundancy & voting (TMR/dual-dual), FDIR, graceful degradation, defensive coding, and the safety standards/cultures (DO-178C aerospace, ISO 26262 automotive, MISRA C, IEC 61508). Includes deep worked case studies of the three domains the user asked about - electronic fuel injection (ECU), electronically-actuated gearbox (shift/clutch-by-wire), and aerospace flight control. Triggers - "fail-safe / estado seguro", "watchdog", "redundancia / votación / TMR", "FDIR / detección de fallas", "degradación con gracia / limp mode", "DO-178C / ISO 26262 / MISRA / ASIL / DAL / IEC 61508", "sistema crítico / safety-critical", "inyección electrónica / ECU", "caja de cambios electrónica / shift-by-wire", "control aeroespacial / fly-by-wire / FADEC". NOT for general timing (tiempo-real-determinismo), RTOS scheduling (rtos-s

Use when reasoning about REAL-TIME behavior of embedded firmware — whether a system meets deadlines deterministically, why a loop runs slow or stutters, latency/jitter/worst-case timing, blocking I/O in the control loop, superloop vs cyclic-executive vs RTOS choice. Triggers - "tiempo real / real-time", "determinismo", "el loop corre lento / a 6 Hz", "jitter", "latencia", "WCET / peor caso", "se cuelga / se congela el loop", "I/O bloqueante", "hard vs soft real time", "deadline", "cuánto tarda mi loop", "el sensor frena todo". The foundational real-time lens; grounds in this robot's real timing failures (BNO freeze, 6 Hz TOP loop). NOT for RTOS task/scheduling design itself (rtos-scheduling-embebido), NOT for control-loop math/discretization (control-embebido-tiempo-real), NOT for fault tolerance (sistemas-criticos-tolerancia-fallas), NOT for tuning a PID (control-pid-zona-muerta) or the omni plant (dinamica-omni-3-ruedas).

Use when BUILDING, wiring or tuning the estimator that fuses the IITA robot's position sensors into one pose — odometry (OTOS) + absolute landmarks (ToF trilateration, goal bearings) + heading (BNO). Triggers - "fusionar sensores de posición", "combinar ToF y OTOS", "el OTOS deriva / la odometría se va", "la pose salta / da saltos", "filtro complementario", "Kalman / EKF / filtro de partículas", "cablear pose_fusion", "el heading deriva o se congela", "tunear la fusión de pose", "qué le creo, al ToF o a la odometría". Covers the predict-from-odometry / correct-from-landmarks pattern, the pose_fusion/pose_filter modules that already exist (and aren't wired), how to MEASURE sensor noise before tuning, gating freshness/outliers, and the bench test plan. NOT for CHOOSING which technique (use localizacion-rcj-soccer), NOT for the omni motion model itself (dinamica-omni-3-ruedas), NOT for camera landmark detection (openmv-vision-tuning).

Use when deciding HOW the IITA RCJ Soccer Open robot should know where it is and which way it faces on the field — choosing/explaining a localization technique, or mapping academic terms to this robot. Triggers - "dónde está el robot", "localización", "pose", "saber la posición en la cancha", "SLAM", "visual SLAM", "odometría visual / visual odometry", "particle filter / filtro de partículas", "MCL / Monte Carlo", "localización por landmarks / balizas", "trilateración", "EKF", "Kalman", "pose estimation", "el robot no sabe dónde está". Teaches every technique with an honest feasibility verdict for OpenMV+Teensy compute, and maps each to the module that ALREADY exists in this repo. NOT for BUILDING/tuning the estimator that fuses sensors (use fusion-pose-odometria-landmarks), NOT for tuning the cameras that see the landmarks (openmv-vision-tuning), NOT for the omni motion model (dinamica-omni-3-ruedas).

Use when teaching/explaining a complex technical concept to a learner, newcomer or younger student, writing onboarding or teaching material, building intuition from scratch, motivating a team member, or awakening passion for technology/engineering. Triggers - "explicale a un principiante", "que lo entienda alguien que recién empieza", "se siente intimidado/a", "no entiende nada", onboarding, despertar vocación, motivar al equipo, enseñar con analogías. The lens: senior engineer-educator who teaches complex→simple with ONE sustained analogy and designs a winnable first victory. NOT for peer-level deliverable prose (rcj-doc-voz-estudiante), the AI-defense stance (ia-educacion-no-trampa), or system modeling (arquitectura-robotica-topdown).

Use when documentation, an argument, or a reply touches on the team's use of AI — methodology sections, USO-DE-IA, TDP/poster AI-use framing, attribution/transparency decisions, or answering anyone (judge, teacher, parent, skeptic) who calls AI use "cheating" or says "the robot isn't really theirs". Triggers - "¿no es trampa?", "usaron IA", defender el método, mostrar/declarar el uso de IA, transparencia de IA, "los chicos no aprendieron". The stance: AI use done with understanding + verification is EDUCATION, not cheating — show it and defend it, never hide or apologize. NOT for doing the AI-accelerated work (vibe-* skills) nor judging deliverables (rcj-deliverables-judge).

Use when conceptualizing, explaining, reviewing or synthesizing a WHOLE robotic system as an integrated mechatronic system — top-down view, abstraction layers, how mechanical/electrical/power/control/vision/localization/comms fit together, what is load-bearing or critical, simplifying a complex multi-domain system. Triggers - "vista de arquitectura", "explicá el sistema completo", "top-down", "por capas", "cómo se integra todo", "qué es lo crítico", "sintetizá/simplificá el sistema", system-level review across domains. NOT for tuning one subsystem (control-pid-zona-muerta), drawing the figure (rcj-diagramas-poster), writing prose (rcj-doc-voz-estudiante), or P0/P1/P2 student feedback (rcj-soccer-coach).

Use when creating or reviewing explanatory visuals for RoboCupJunior deliverables — poster figures, system architecture diagrams, dataflow/FSM diagrams, iteration figures, photo overlays, SVG drawings for the A1 poster or TDP. Triggers - "armá/dibujá el diagrama", "la figura del póster", "explicá el sistema con un dibujo", "diagrama de bloques/flujo", "hacé el SVG", a figure that must be legible at poster distance, or any visual meant to score Photos & Graphics / Method / Data rubric points.

Use when writing or rewriting RoboCupJunior competition documentation in the team's voice — TDP sections, abstracts, system overviews, program/software documentation, video scripts, poster text, interview answers — or when synthesizing the essence of a complex robot system for judges or other teams. Triggers - "escribí/redactá la sección", "documentá este programa/código", "explicá cómo funciona el sistema", "describí la esencia", "resumí la arquitectura", text that sounds like a professor or an AI instead of a student, or any deliverable prose meant to score rubric points.

Use when evaluating, scoring, or mock-judging RoboCupJunior Soccer competition deliverables — TDP, engineering poster, technical video, team interview prep, BOM, or open-source repo — against the official 2026 rubric. Triggers - "evaluá este TDP/póster/video", "cuántos puntos nos darían", "revisalo como juez/jurado", pre-submission review, mock judging, estimating rubric points, or comparing a deliverable against Excellent descriptors. NOT for writing/preparing deliverables (rcj-judging-package) nor robot technical feedback (rcj-soccer-coach).

Use when documenting engineering work in the repo — journal entries, research backlog grooming, in-progress analysis, completed conclusions, and decision records. Enforces the YYYY-MM-DD-descripcion.md convention, attribution rules, and the discipline that the team set up but stopped using since 2026-03-20. This skill is what keeps the repo alive between sessions and turns Incheon into a documented learning experience instead of folklore.

Use when designing or executing a hardware test for any robot subsystem (mechanical part fit, PCB power-on, sensor calibration, motor/driver behavior, comm link latency, FSM integration, full match scrimmage). Defines test setup, measurable acceptance criteria, regression checks on neighbor subsystems, and journal documentation format. This is the "test plan in real hardware" that the vibe-* skills and rcj-soccer-coach reference.

Use when preparing the RoboCupJunior Soccer Open judging deliverables for Incheon 2026 (BOM, poster A1, technical video, digital portfolio, technical interview prep). Ensures every deliverable hits the 2026 rubric and stays consistent across artifacts (innovation highlighted in video must appear in poster and portfolio).

Use when working in the IITA Soccer Open repo to give technical feedback to students. Frames feedback as tema-a-analizar with risk-no-fix / risk-fix / tiempo, prioritizes P0/P1/P2, and demands a hardware-real test plan. Activates the senior-coach lens (RoboCupJunior Soccer Open + Middle Size League experience).

Use when designing or iterating mechanical parts for the robot (chassis, dribbler, kicker, sensor mounts, omni wheel hubs) using AI-accelerated CAD pipelines. Goes from sketch/intent to printable STL/STEP with verification gates (clearance, motor torque match, manufacturability, BOM check). Specialised for RoboCup-class robots with 3D-printed + manually-fabricated parts.

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.

Use when writing or modifying embedded robotics firmware for the IITA soccer robots (Teensy 4.1 + OpenMV cameras + custom Zircon PCB + BNO055 IMU + IR sensors + motors). AI-accelerated coding with hard verification gates: compiles, fits in MCU, hardware-tested, no regressions on working subsystems. Specialised for the C++/Arduino-Teensy stack and MicroPython OpenMV stack.