# Terreneitor 2026: cómo reparte un coche robot el control y la visión Terreneitor es un coche educativo de 2026 con Raspberry Pi y Arduino. Su documentación permite estudiar el control del motor y distintas rutas de navegación. - URL canónica: https://robotica.es/ia/terreneitor-2026-coche-robot-control-navegacion/ - Versión Markdown: https://robotica.es/ia/terreneitor-2026-coche-robot-control-navegacion.md - Publicado: 2026-10-08 - Última actualización editorial: 2026-10-08 - Autoría: Redacción Robotica.es - Categoría: IA en robótica - Etiquetas: Neutrinos Electrónicos, Terreneitor 2026, educación, programación, robótica educativa - Idioma: es-ES Las fotografías de **Terreneitor 2026** muestran un coche educativo que ha cambiado de estructura y de disposición de componentes durante su desarrollo. Neutrinos Electrónicos publica esos montajes junto a programas para Raspberry Pi y Arduino. La división entre ambas placas permite seguir cómo una decisión de navegación termina convertida en movimiento. El proyecto se prepara para WRO Future Engineers y conserva archivos de bases, soportes, un engranaje y una rueda. Su nombre procede del recuerdo de un coche de juguete compartido por el equipo; el robot documentado es una construcción para estudiar conducción autónoma, con electrónica y piezas adaptadas a ese trabajo. ## Dos placas con tareas distintas Raspberry Pi 4 se ocupa de la percepción y de la lógica de la carrera. Arduino UNO controla el motor, la dirección y parte de las lecturas que necesita comunicar al ordenador principal. El puente BTS7960 alimenta el motor de tracción, mientras un servo orienta las ruedas delanteras. Esta organización ofrece un problema educativo concreto: la Pi debe expresar lo que quiere hacer y el controlador debe ejecutar órdenes coherentes con el montaje. Una imagen o una distancia no mueve el coche por sí sola; antes hay que convertirla en una velocidad y una posición de dirección. La memoria describe una cámara, un TF-Luna sobre un soporte orientable, medición trasera de distancia y orientación inercial. Las fotografías y los archivos mecánicos ayudan a localizar componentes, pero las versiones publicadas no utilizan todos esos elementos de la misma forma. ## Las constantes también describen una versión El sistema principal reúne ajustes de velocidad, visión, competición y geometría en un archivo de configuración. Así puede cambiarse una referencia sin buscarla entre distintas funciones. También separa módulos para comunicación, captura de imagen y estados del recorrido. Al leerlo aparecen diferencias respecto al resumen general: cambian el ángulo central declarado, el tipo de entrada de cámara y algunos pines. Esas diferencias importan porque un valor correcto para una revisión puede resultar incorrecto para otra. La documentación sirve para estudiar la arquitectura; no debe tratarse como una receta única de cableado que mezcle todas sus ramas. Las máscaras de color y el tamaño mínimo de detección permiten observar otra relación útil. El coche no interpreta una señal únicamente por su nombre: necesita que la cámara entregue una región suficiente y que los umbrales se ajusten a la escena que está viendo. ## Una alternativa reactiva para comparar El [programa alternativo publicado](https://raw.githubusercontent.com/flvr-soda/WRO2026-neutrinos-electronicos/main/code/safety_sys/main.py) utiliza medición ultrasónica, un soporte de exploración y órdenes serie hacia Arduino. Incluye la búsqueda del sentido de giro, maniobras temporizadas, conteo de esquinas y una detección de colores con OpenCV. Por tanto, no coincide exactamente con la descripción de una alternativa basada en un LiDAR fijo que aparece en la memoria. Es una rama de pruebas con otros supuestos. Presentar las dos como si fueran un mismo sistema terminado ocultaría precisamente lo que se puede aprender al compararlas. Los giros temporizados dependen de la velocidad real y del agarre. Del mismo modo, disponer de estados dedicados al aparcamiento no equivale a acreditar un estacionamiento fiable con cualquier disposición de señales. El proyecto necesita ajustes sobre su pista y su construcción. Terreneitor resulta interesante para quien quiera estudiar un robot móvil con separación entre decisiones y actuadores. Sus distintas rutas de software hacen visibles los costes de mantener esa separación: acordar mensajes, conservar una configuración consistente y comprobar qué sensores está usando realmente cada programa. ## Fuentes - [Neutrinos Electrónicos: Terreneitor, arquitectura y fotografías [en]](https://raw.githubusercontent.com/flvr-soda/WRO2026-neutrinos-electronicos/main/README.md) - [Terreneitor: parámetros del sistema principal](https://raw.githubusercontent.com/flvr-soda/WRO2026-neutrinos-electronicos/main/code/main_sys/src/config.py) - [Terreneitor: programa alternativo de navegación ultrasónica](https://raw.githubusercontent.com/flvr-soda/WRO2026-neutrinos-electronicos/main/code/safety_sys/main.py) - [Terreneitor: firmware de control de movimiento](https://raw.githubusercontent.com/flvr-soda/WRO2026-neutrinos-electronicos/main/code/firmware_terreneitor.ino) *Imagen: Fotografía de Neutrinos Electrónicos de Terreneitor completo de perfil, con cuatro ruedas, placas, cableado y soporte de sensores. [Archivo original](https://raw.githubusercontent.com/flvr-soda/WRO2026-neutrinos-electronicos/main/photos/vehicle/derecha_v3.jpeg).*