ORBIT (antes AdriPilot): telemetría y mando remoto sobre openpilot

ORBIT (Open Remote Bidirectional IoV Telemetry) convierte un coche con openpilot en un nodo conectado: la telemetría sale en tiempo real, las órdenes remotas entran y el dispositivo se vincula a una cuenta con un QR. Son tres piezas: ORBITPILOT, el firmware, un fork de sunnypilot y openpilot pensado para el comma 3X; un broker MQTT con un backend en Flask sobre SQLite; y una app en Flutter.

La idea que lo ordena todo: lo que no es crítico para la seguridad sale del coche —histórico, cuentas, mapa, configuración— y el bucle de control se queda intacto. Una orden remota actúa siempre a través de los límites de actuación y seguridad del propio openpilot.

Empezó en julio de 2025 con otro nombre. AdriPilot era una app en Flutter y un servidor en Python con Flask que recogía la telemetría por MQTT y la guardaba en PostgreSQL. En septiembre ya funcionaba el cambio de carril ordenado desde el móvil, y el otoño se fue en telemetría, mapa, cámara, eventos y órdenes.

A mediados de 2026 el prototipo dejó de serlo: porté el firmware a una base reciente de sunnypilot y el proyecto pasó a llamarse ORBIT. El backend cambió PostgreSQL por SQLite para arrancar con un solo docker compose up, llegó la vinculación por QR y el firmware quedó publicado en abierto. Nació como proyecto de investigación universitaria, y hay un artículo sobre la arquitectura en preparación.

En el coche, el bus CAN alimenta a openpilot, que ejecuta el bucle de control. A su lado corre el módulo orbit/: publica la telemetría, recibe las órdenes y, opcionalmente, habla por ZeroMQ con una NVIDIA Jetson para inferencia en el borde. Fuera, Mosquitto hace de broker, el backend guarda cuentas, vinculaciones, histórico y registro de órdenes, y la app lee la telemetría en vivo.

La app nunca publica una orden: la pide al backend por REST, que la valida, la autoriza y la publica. Y el coche no se fía de nadie: lo vuelve a comprobar todo. Lo crítico vive en el coche; fuera solo queda lo que puede fallar sin poner a nadie en peligro.

La regla de partida: la autoridad solo baja. Ninguna orden remota puede dar a openpilot más control del que ya tiene con el conductor delante. Después, cuatro filtros.

• Modo. Observador (solo lectura, por defecto), copiloto (ajustes que no mueven el coche; caduca a los 15 minutos), maniobra (cambio de carril y deceleración; caduca a los 2) y banco, el control físico directo, que solo se arma tocando la pantalla del comma.
• Precondiciones. Diez comprobaciones —enganchado, rango de velocidad, conductor presente y sin intervenir, enlace fresco, reloj sincronizado…— que fallan en rojo si falta un dato, y que cada componente de openpilot repite al actuar.
• Caducidad. Las órdenes caducan (un cambio de carril, a los 3 s): si llegan tarde se rechazan y, sin renovación, el actuador vuelve a neutro solo.
• Conductor. En una maniobra, tocar volante, freno o acelerador la cancela.

La única orden que se acepta siempre, sin modo ni precondición, es disarm_all: devolverlo todo a neutro. Y el antiguo «frenado de emergencia» es hoy una deceleración asistida acotada entre −1 y −2,5 m/s², de 1,5 s como máximo. Una frenada que llega con segundos de latencia, ordenada por alguien que no ve lo que ve el coche, no evita un peligro: lo crea.

Todo viaja por un contrato MQTT versionado bajo orbit/v2/, siempre con el identificador del dispositivo en la ruta:

Los verbos viven en una única tabla del firmware de la que salen el router, las capacidades y la ayuda de la app, y un test cruzado la compara con la del backend. Y caps existe para que la app solo pinte lo que el coche declara: ningún botón que no haga nada.

Sin cobertura, la telemetría no se tira: espera en una cola SQLite de 32 MB en el coche, donde los eventos y los viajes nunca se descartan y la posición no se guarda por defecto. Lo reenviado va marcado, para no confundirlo con un coche conectado. Las órdenes, en cambio, no se encolan nunca: una maniobra diferida es un peligro.