DZGarage Cockpit: una computadora de rally para un Audi clásico en seis meses

Por qué

El 17 de octubre de 2026 largamos el XII Spain Classic Raid en el auto #89, un Audi 100, con mi hermano Andrés. Compartimos el pilotaje y nos vamos turnando entre el volante y el asiento del copiloto a lo largo de los días de carrera. Cuatro días, Gijón → León → Salamanca → Ávila → Palencia, por un recorrido que la organización promete con barro, arena y piedras.

El Classic Raid es un rally de regularidad, donde hay que pasar por cada control a la hora exacta. La organización publica una velocidad media para cada tramo cronometrado (TC), esconde controles a lo largo de la ruta y penaliza cada segundo de adelanto o de atraso. Entre TC y TC están los enlaces, donde hay que llegar al siguiente control a horario sin pasar volando por los pueblos. El copiloto va calculando la distancia hecha, el tiempo transcurrido y cuánto vamos adelantados o atrasados, con el auto saltando, mientras lee un roadbook en papel y canta las curvas.

Lo habitual es usar una app en una tablet y una caja GPS comercial. Yo quería un aparato propio, que sepa cómo corremos nosotros, que muestre los números que importan en dígitos grandes, que aguante un corte de corriente y que pueda arreglar en la habitación del hotel la noche antes de una etapa. Ese aparato terminó siendo el DZGarage Cockpit, hecho en DZ Lab (donde voy dejando experimentos y prototipos) para la escudería DZ Garage.

El primer commit entró el 28 de abril de 2026. Seis meses y unos 650 commits después, la caja está montada en el tablero y congelada en el tag v0.2, lista para el sábado.

Qué construí

Son tres microcontroladores, dos receptores GPS, una pantalla táctil, una tablet y un teléfono, hablando entre sí dentro del auto.

El cockpit, la computadora de rally

El núcleo es un ESP32 con una pantalla táctil de 3,2″ y una microSD para los logs. Vive en una caja impresa en 3D para el tablero, con seis botones físicos alrededor de la pantalla:

• ±1 m y ±10 m, en dos columnas a los costados de la pantalla, uno bajo cada pulgar, para llevar el parcial a la cifra del roadbook después de una horquilla.
• MODE y RST. RST está hundido dentro de un aro protector y además hay que mantenerlo apretado, así una mano con guante que se arrastra por el panel no pone a cero el parcial con el que está navegando la tripulación.

El cockpit es el dueño del odómetro, del reloj del día y de todas las pantallas. También levanta un punto de acceso Wi-Fi que le pasa el GPS en vivo a la app de navegación de la tablet, así tablet y cockpit leen siempre la misma posición.

El neopod, el receptor GNSS cableado

Un pod en el parabrisas con otro ESP32, un receptor GNSS y una pantallita que muestra el estado, unido a la caja del tablero por un cable de 1,5 m que lleva alimentación y datos. Si el cable falla, el pod pasa solo a Bluetooth. El cockpit prefiere el cable cuando los datos están frescos y usa Bluetooth cuando no.

El collector, la segunda fuente GPS

Un tercer ESP32, sin pantalla, que se conecta por Bluetooth a un Garmin GLO y le pasa las posiciones al cockpit por cable. También lee los seis botones del panel.

Dos receptores, una decisión

Con dos fuentes GPS hay que elegir cuál usar sin que el odómetro pierda o gane metros a escondidas. Un árbitro decide qué receptor está activo. La tripulación elige el principal, el otro queda de respaldo automático, y una banda muerta con tiempos de permanencia asimétricos evita que una fuente que oscila justo en el límite se coma distancia del parcial.

Una pantalla FUENTES muestra los dos receptores lado a lado, con la distancia entre sus posiciones como número principal. Si están a más de unos pocos metros, alguno de los dos está mal. En las salidas a ruta el GLO midió velocidad y distancia más limpio, así que quedó como principal y el pod como respaldo.

Lo que hace

El firmware tiene unas 23.000 líneas de C++ solo en el cockpit. Todo lo que aparece en pantalla está en castellano (el idioma de la tripulación) a través de una tabla de i18n.

El odómetro calcula la distancia por haversine, con un umbral de baja velocidad, un saneador de GPS que descarta saltos y fixes congelados, y un factor de calibración R para que mida igual que el de la organización. Una calculadora en el propio aparato saca R a partir de dos referencias oficiales separadas por al menos 10 km, con una pantalla de confirmación que muestra viejo → nuevo antes de aplicarlo.

Cada día la organización entrega un carnet de control con una hora de salida y una cascada de offsets hasta cada control. Escribís la hora de salida una vez (con atajos de "próximo minuto en punto" y "próximo :30") y la hora ideal de cada TC sale sola. Cualquier cambio que recalcule el día pide confirmación, y el diálogo dice qué se va a mover ("recalcula TODOS los TC de hoy").

En los enlaces, la pantalla ENLACE muestra el próximo control y su hora, los kilómetros que faltan, la Vm necesaria y el margen en verde, ámbar o rojo, con un colchón de llegada anticipada de entre 5 y 15 minutos ya incluido. En los últimos 30 segundos antes de un control, una cuenta regresiva a pantalla completa se queda con todo.

TC por tablas

Algunos tramos cronometrados llegan como una tabla en papel con tiempos de paso cada 100 m, que te dan unos 10 segundos antes de la salida. La tabla está armada con un puñado de segmentos a velocidad constante, así que una hoja entera se reduce a unas pocas cadencias ("13 s cada 100 m desde 0,0, 10 desde 0,3…"). El copiloto teclea esos pocos números y la pantalla de carrera muestra una cifra enorme de adelanto o atraso, el próximo cambio de velocidad y un aviso CAMBIO 100 m antes.

El resto

• HITOS para los tramos que se cronometran en postes al costado de la ruta, y +MIN para los anuncios de "sumen N minutos" y las neutralizaciones, otra vez con un diálogo que lista cada hora que se mueve.
• Zonas de gracia del reglamento: ningún control secreto puede estar a menos de 500 m de una salida o una llegada, ni a menos de 250 m de un cambio de velocidad. La pantalla muestra esa ventana, que es donde se recupera con calma.
• Registro de viñetas. Manteniendo apretada 2 s la esquina de la pantalla de carrera se guarda el número de viñeta del roadbook con el parcial, la hora y la posición de ese momento, para revisar después o para encontrar el camino de vuelta.
• QR de rescate. La última posición conocida como un QR de Google Maps, por si tenemos que decirle a alguien dónde estamos.

La configuración va por web, en 192.168.4.1. El cockpit sirve una web pensada para el teléfono desde su propio punto de acceso: ajustes, el planificador de la etapa del día en una línea de tiempo, los planes de TC, la lista de viñetas, diagnósticos y los logs de la SD. Se entra con un QR que aparece en la pantalla. Nada viene de afuera del auto, que es lo que pide el reglamento.

Los logs de sesión van a la SD: un CSV por arranque, a 10 Hz en movimiento, una fila de keepalive cada dos minutos cuando estamos parados, más una fila de evento por cada corrección de la tripulación. Las filas se sincronizan cada pocos segundos, así que si el auto se reinicia no se pierde casi nada. Cada noche el navegador arma un GPX y un CSV combinado del día directamente desde la tarjeta.

El firmware también está preparado para vivir en un auto. Cada placa tiene watchdogs de loop y guarda el motivo del último reset. Si hay una caída de tensión en medio de un TC o de un enlace, retoma sin perder kilómetros. Un túnel no reinicia la pantalla ni cierra un teclado abierto. Hay un salvapantallas que atenúa y se desplaza cuando estamos parados, y la versión del firmware sale de git describe y queda estampada en el banner de arranque y en la cabecera de cada log.

La parte física

Todas las cajas son OpenSCAD paramétrico, impresas en una Prusa Core One: la caja del tablero (ahora "panorámica", 175 × 87 mm, después de una v0.4 cuadrada que parecía una caja de proyecto de electrónica cualquiera), una visera separada contra los reflejos, el neopod, los prensaestopas y el soporte.

El soporte es un panel perforado IKEA SKÅDIS cortado a 460 × 360 mm, apoyado sobre el tablero del lado del copiloto, con brazos impresos, un apoyo, una bisagra y bases para la caja del cockpit y para una tablet en vertical. Entró en el auto el 14 de octubre y aguanta. La alimentación sale del 12 V del auto, bajado a 5 V por USB, sin batería ni telemetría.

El cableado también se genera. Un script de Python dibuja el arnés, los patrones de agujeros y la planta en SVG, y arma una guía de montaje en HTML, así los dibujos no se pueden desfasar de los números del CAD. Hay assert() en los modelos que rompen el build si la tuerca de un botón choca con la PCB de la pantalla o con una pared.

Todo lo que se ve acá son renders. Las fotos de las cajas de verdad van en el próximo post.

Cómo lo construí

El firmware está hecho con PlatformIO, con todas las versiones fijadas. Hay suites de tests unitarios nativos que corren en la Mac y cubren el odómetro, el filtro GPS, el árbitro de fuentes, el plan del día, las tablas, el log de SD, la persistencia de ajustes y la tabla de textos.

Para no depender solo de salir a la ruta hay un simulador de escritorio que mete rutas sintéticas (curvas de herradura, pendientes, túneles, árboles tapando el cielo) por el código real del filtro y del odómetro, para ver dónde una etapa de montaña pierde metros. Un segundo harness conecta el pod de verdad por BLE al mismo motor, sin cockpit de por medio.

También hice prácticas por rutas reales, bajando los logs por Wi-Fi para reproducirlos offline. Con esos datos elegí el receptor principal, el modelo dinámico del GNSS y el procedimiento de calibración.

Las piezas se diseñan en OpenSCAD y se laminan con PrusaSlicer, detrás de un make print que se niega a mandar piezas inestables. Los prototipos son de PLA, con insertos de latón termofijados.

El proyecto se organizó con documentos en Markdown: uno de diseño por cada funcionalidad (reglas de UX, modo tablas, plan del día, ajustes), uno de estado general, un registro de tareas y un checklist del rally con fechas que cada commit va tachando. El feature freeze fue el 13 de octubre.

Para la tripulación hay instructivos en Markdown en castellano, que un script de Python con Chrome headless convierte en PDFs del tamaño del teléfono y en texto listo para WhatsApp: cómo preparar una etapa, prácticas de la tripulación, un protocolo de fotos, el plan de etapas, hoteles, un checklist para salir de casa y una página de "si algo falla" para la guantera.

Claude Code como coingeniero

La mayoría de las sesiones fueron trabajo en pareja con Claude Code: revisar el firmware buscando modos de falla en los que yo no había pensado (encontró que la tablet no estaba recibiendo ningún frame, tres semanas antes del rally), escribir tests nativos, iterar el CAD a partir de fotos de las placas reales y mantener la documentación sincronizada con el código. Cuando mis fotos o lo que medía con el calibre no coincidían con el plan, cambiábamos el plan. Y cada decisión quedaba escrita en un documento, así la sesión siguiente podía arrancar desde cero sin que yo le explicara nada.

Dónde está ahora

Las tres placas están flasheadas desde una release con tag. La caja está en el auto, las dos fuentes GPS anduvieron en rutas reales y la tablet toma la posición del cockpit. Falta la carrera. El sábado a la mañana en Gijón vamos a saber si los números de la pantalla valen más que un cronómetro y un lápiz.

Esa parte la escribo después de Palencia, en un segundo post: cómo anduvo el aparato en carrera, qué falló, qué cambiaríamos, y fotos de verdad del auto, de las cajas montadas y de la pantalla en plena etapa.