Best practices transversales para robótica de competición — workflow profesional, testing sistemático, calibración, debugging, control de versiones, documentación, mecánica, y disciplinas operativas que diferencian a equipos ganadores. Usar SIEMPRE que se trabaje en metodología de desarrollo de robots de competición, organización del workflow del taller, debugging sistemático de robots, control de versiones de programas Pybricks, documentación de calibraciones, gestión de baterías, troubleshooting, o se mencione 'best practices', 'workflow', 'testing', 'mechanical design', 'team strategy', 'qué hacer cuando no funciona'. Aplica a cualquier categoría de robótica (WRO, RCJ, FLL, sumo, line follower).
Las skills técnicas son el 50% de un equipo ganador. El otro 50% son las disciplinas operativas: cómo el equipo trabaja, prueba, documenta, y se prepara para la competición. Esta skill cubre las prácticas que diferencian a equipos top de los amateurs.
Trampa común: pasar a la siguiente mission antes de tener la actual estable. Resultado: 5 missions a medias, ninguna confiable.
Cuando alguien dice "funciona", preguntar:
Una mission solo se declara "lista" cuando funciona 8/10 veces o más en condiciones realistas de competición.
Cada equipo debe llevar un logbook (digital o papel) donde se registra cada test:
| Fecha | Programa | Versión | Bater % | Resultado | Notas |
|---|---|---|---|---|---|
| 2026-04-07 14:30 | mission_north | v3 | 95% | OK | |
| 2026-04-07 14:32 | mission_north | v3 | 95% | OK | |
| 2026-04-07 14:33 | mission_north | v3 | 92% | FAIL | Se desvió 5 cm en el último giro |
| 2026-04-07 14:36 | mission_north | v3 | 90% | OK |
Al revisar el logbook se ven patrones que en el momento no se notan: "fallaba siempre cuando la batería bajaba de 92%" o "fallaba siempre la última corrida del día = los motores recalientan".
Antes de declarar un programa estable, probarlo bajo distintas condiciones:
| Condición | Test |
|---|---|
| Batería 100% | 5 corridas |
| Batería 70% | 5 corridas |
| Mat con polvo | 5 corridas |
| Diferentes ángulos de luz | 5 corridas |
| Después de 1 hora corriendo | 5 corridas |
| Mat de práctica vs mat oficial (si lo hay) | 5 corridas cada uno |
Si pasa las 6 condiciones con 8/10 = el programa está listo para competición.
wheel_diameter empíricamente con straight(1000) y cinta métrica.axle_track empíricamente con turn(360) y comparación con gyro.WHITE y BLACK del ColorSensor sobre el mat actual.Si falla cualquiera de los pasos 4-5, NO empezar a programar/competir hasta resolverlo.
# CALIBRACIONES — Robot v3.2 — 2026-04-07
# wheel_diameter calibrado con: straight(1000) → 998 mm reales (3 corridas, batería 8.0V)
# axle_track calibrado con: turn(360) → gyro reportó -0.5° (2 corridas, batería 8.0V)
# Sensores de color calibrados sobre mat WRO 2026 oficial
WHEEL_DIAMETER = 56.1
AXLE_TRACK = 113
WHITE_LEFT = 92
BLACK_LEFT = 8
WHITE_RIGHT = 90
BLACK_RIGHT = 10
Cuando algo falla, no parar al primer "ah, era esto". Preguntar 5 veces "¿por qué?":
"El robot no completó la mission."
¿Por qué? "Porque se desvió 5 cm a la izquierda."
¿Por qué? "Porque el motor izquierdo giró menos."
¿Por qué? "Porque las ruedas patinaron en el arranque."
¿Por qué? "Porque la aceleración era muy alta."
¿Por qué? "Porque copiamos el código de otra mission sin ajustar settings."
Causa raíz encontrada: settings hardcoded en cada mission en lugar de un set único calibrado.
print() no se ve en standalone. Usar:
hub.display.text(str(int(value))) # mostrar números
hub.display.icon(STAR) # marcadores visuales de estado
hub.light.on(Color.GREEN / RED / YELLOW) # códigos de color rápidos
hub.speaker.beep(frequency, duration) # alertas sonoras
Si un programa falla, cortarlo a la mitad, probar la primera mitad, después la segunda mitad. Identificar en qué mitad está el bug. Repetir bisectando hasta aislar la línea problemática.
mission_north_v1.py — primera versión funcionalmission_north_v2.py — agregado check de pelotamission_north_v3.py — calibrado para mat oficialNUNCA borrar versiones viejas que funcionaron. La v2 puede ser más estable que la v3 cuando estás bajo presión en competición.
Cada cambio importante se commitea con un mensaje descriptivo. Para el taller IITA, el repo es IITA-Proyectos/iita-vibe-robotics-martes-SL con la convención de carpetas establecida en el README.
El día anterior a la competición:
El centro de gravedad bajo da estabilidad. Robots altos se vuelcan en aceleración, frenado, o giros rápidos.
Los attachments deben encajar y quitarse en <5 segundos sin destornillador. Pins LEGO con tope mecánico funcionan perfectamente.
El robot va a chocar con cosas. La base estructural debe aguantar 100 caídas sin deformarse. Reforzar los puntos de fijación de los motores y del hub con beams cruzados.
Si el robot tiene partes que se mueven libremente (un brazo que cuelga), va a comportarse distinto cada vez. Todo movimiento debe estar controlado o fijado.
Antes de competición, golpear el robot deliberadamente desde varios ángulos. Si algo se rompe ahora, mejor que en la cancha.
24 horas antes:
En la cancha: