ARES — Amateur Rocket Embedded System
ARES es una plataforma de software y hardware para ordenadores de vuelo de cohetería experimental. Su objetivo no es simplemente registrar datos o desplegar un paracaídas; su objetivo es proporcionar una arquitectura sobre la que puedan construirse misiones completas sin reescribir el firmware en cada lanzamiento.
El sistema integra adquisición de datos, gestión de misión, comunicaciones y servicios de tierra bajo una arquitectura modular diseñada para evolucionar con el vehículo. Cambiar un sensor, añadir un nuevo enlace de radio o modificar la lógica de vuelo debería implicar cambios localizados, no una crisis existencial del firmware.
Aunque está orientado a proyectos amateur, ARES adopta principios de ingeniería habituales en sistemas aeroespaciales: separación de responsabilidades, interfaces bien definidas, componentes desacoplados y una fuerte preferencia por los estados explícitos frente a la «magia» escondida en miles de líneas de código.
En otras palabras: el cohete seguirá siendo un experimento; el software intentará comportarse como si no lo fuera.
Hardware
ARES no se ha diseñado alrededor de una placa electrónica concreta, sino alrededor de una arquitectura de hardware. La idea es desacoplar el software de los detalles físicos de la electrónica, de forma que el mismo sistema pueda ejecutarse sobre diferentes revisiones de hardware sin necesidad de modificar la lógica de misión.
Para conseguirlo, la plataforma define un conjunto de capacidades que cualquier ordenador de vuelo debe ofrecer —procesamiento, almacenamiento, navegación, comunicaciones y control de actuadores— en lugar de imponer componentes específicos. La implementación actual integra todos estos elementos en una única placa: un microcontrolador, memoria persistente, sensores de navegación, enlace de radio, conectividad WiFi y las interfaces necesarias para controlar los actuadores. Todos los periféricos se conectan mediante buses estándar como I²C, UART o GPIO, lo que permite sustituir un sensor, un módulo de radio o cualquier otro componente sin alterar el resto del sistema electrónico.
Esta filosofía de modularidad continúa en el software. El firmware encapsula todos los dispositivos físicos mediante una Hardware Abstraction Layer (HAL), que actúa como una capa intermedia entre el hardware y el resto del sistema. Gracias a esta abstracción, el motor de misión nunca accede directamente a un modelo concreto de IMU, GPS o transceptor de radio. En su lugar, trabaja con interfaces genéricas que representan conceptos funcionales como IMU, barómetro, GPS, radio o almacenamiento. De este modo, reemplazar un componente físico implica únicamente adaptar su controlador dentro de la HAL, mientras que el resto del software permanece inalterado.
La implementación actual utiliza un microcontrolador ESP32-S3 como núcleo de procesamiento. Este dispositivo proporciona capacidad suficiente para ejecutar simultáneamente el motor AMS, gestionar las comunicaciones y registrar telemetría aprovechando la planificación concurrente de FreeRTOS. Sin embargo, esta elección responde a la implementación actual y no al diseño conceptual de ARES. Aunque en la práctica el software todavía depende del ESP32-S3, la arquitectura se ha concebido para que futuras versiones puedan migrar a otra plataforma de hardware con cambios mínimos, preservando tanto la organización del software como el lenguaje de misión.
Firmware
El firmware de ARES está diseñado como una plataforma de ejecución, no como una misión codificada en C++. Su responsabilidad consiste en proporcionar los servicios necesarios para que el vehículo pueda operar de forma segura, mientras que la lógica específica de cada lanzamiento queda definida por AMS.
La arquitectura sigue una separación estricta de responsabilidades. Cada subsistema tiene una función concreta y se comunica con el resto mediante interfaces bien definidas, reduciendo el acoplamiento entre módulos y facilitando tanto las pruebas como la evolución del sistema.
Entre los servicios que proporciona el firmware se encuentran:
- Adquisición y fusión de datos procedentes de los sensores de navegación.
- Ejecución del motor AMS y evaluación de la máquina de estados.
- Registro persistente de telemetría y eventos en memoria flash.
- Comunicaciones mediante el protocolo APUS sobre enlaces de radio de bajo ancho de banda.
- Configuración y operación desde tierra mediante una API REST accesible por WiFi.
La arquitectura software está organizada en capas. En la base se encuentran los controladores de hardware y la Hardware Abstraction Layer (HAL), que aíslan al resto del sistema de los dispositivos físicos. Sobre esta capa se implementan los servicios del sistema —almacenamiento, comunicaciones y API— y, finalmente, el motor AMS, responsable de interpretar y ejecutar la misión.
AMS — Ares Mission Script
AMS es el componente que define la identidad de ARES. Mientras que la mayoría de ordenadores de vuelo implementan la lógica de misión directamente en el firmware, ARES traslada esa responsabilidad a un programa independiente que se interpreta durante la ejecución.
En otras palabras, el firmware deja de contener la misión y pasa a contener el motor que ejecuta la misión.
Esta separación permite que el mismo ordenador de vuelo ejecute perfiles completamente distintos sin necesidad de recompilar ni volver a programar el dispositivo. Cambiar un criterio de detección de lanzamiento, modificar la cadencia de telemetría o ajustar las condiciones de despliegue deja de ser una modificación del firmware y pasa a ser simplemente una nueva misión.
AMS define de forma declarativa el comportamiento del vehículo mediante una máquina de estados finita. Cada estado representa una fase operacional del vuelo, mientras que las transiciones especifican cuándo y bajo qué condiciones debe producirse el cambio de estado. Las decisiones pueden depender de medidas procedentes de los sensores, telemandos recibidos desde tierra o variables internas del sistema.
Pero una misión no describe únicamente estados y transiciones. También define la telemetría que debe transmitirse, los datos que se almacenarán localmente, las condiciones de seguridad que deben supervisarse de forma continua y las acciones que deben ejecutarse al entrar en un estado determinado, como la activación de un canal pirotécnico o la generación de un evento.
A diferencia de un lenguaje de propósito general, AMS es deliberadamente limitado. No existen bucles arbitrarios, recursión, asignación dinámica de memoria ni construcciones cuyo tiempo de ejecución sea impredecible. El lenguaje está diseñado para ser estáticamente analizable, completamente acotado y determinista. El parser impone límites estrictos sobre el tamaño de los scripts, el número de estados, transiciones, condiciones y acciones permitidas, garantizando que cualquier misión pueda validarse antes del vuelo.
El resultado es una arquitectura donde el firmware permanece prácticamente inalterado entre lanzamientos y la misión se convierte en un archivo de configuración ejecutable. Esto simplifica las pruebas, facilita la reutilización del software y reduce el riesgo de introducir errores al modificar la lógica de vuelo. O dicho de otra forma: el cohete cambia de misión; el firmware intenta no enterarse.
Ares-MC (Mission Control)
ARES Mission Control (ARES-MC) constituye el segmento de tierra de la plataforma. Es la aplicación desde la que se prepara el vehículo antes del lanzamiento, se supervisa durante el vuelo y se analizan los datos una vez finalizada la misión.
Desarrollado sobre .NET para Windows, ARES-MC integra en una única interfaz las tareas habituales de una campaña de lanzamiento: configuración del ordenador de vuelo, carga de misiones AMS, monitorización de telemetría, gestión de enlaces de comunicación y análisis post-vuelo.
ARES-MC acompaña al vehículo durante todo el ciclo de vida de una misión. Antes del lanzamiento permite configurar el ordenador de vuelo, cargar scripts AMS, editar parámetros del sistema, comprobar el estado de los sensores y verificar que todos los subsistemas se encuentran operativos. Una vez completadas las comprobaciones previas, la misión puede armarse directamente desde la aplicación.
Durante el vuelo, Mission Control actúa como centro de operaciones, recibiendo la telemetría en tiempo real y presentando una visión unificada del estado del vehículo (tú decides que datos enviar con los scripts AMS).
Una vez recuperado el vehículo, la aplicación facilita la descarga y el análisis de los registros almacenados durante el vuelo. La telemetría puede reproducirse, inspeccionarse y exportarse para reconstruir la misión, validar el comportamiento del sistema y estudiar cualquier incidencia detectada durante el lanzamiento. Porque las lecciones más valiosas casi siempre aparecen después de aterrizar.
Recursos
Enlaces
Por el momento, ARES está desarrollado para microcontroladores ESP32-S3. El firmware está escrito en C++17 y sigue prácticas habituales del desarrollo de software para sistemas críticos, inspiradas en estándares como ESA PUS, MISRA C, CERT C y las recomendaciones NASA JPL Power of 10. El objetivo no es obtener una certificación aeroespacial, sino aplicar la disciplina de ingeniería que estas normas promueven para construir un software más robusto, predecible y mantenible.
Desarrollado en C# sobre .NET para Windows, proporciona una interfaz unificada para configurar el ordenador de vuelo, supervisar la misión en tiempo real y analizar la telemetría tras la recuperación del vehículo.
No es obligatorio usar ARES-MC ya que el la comunicación con el firmware se hace vía API, así que es fácil desarrollar tu propia GUI si así lo deseas.