El reto de la autonomía submarina no está en la propulsión ni en el sellado: está en la arquitectura de control. El Ai Apaec no navega por radio control — procesa sus propios datos de sensores, ejecuta su propio plan de misión y corrige su propia trayectoria en tiempo real. Este artículo documenta la electrónica de control AUV completa: selección de hardware, arquitectura de conectividad y la modificación del firmware ArduSub que hace posible que el vehículo funcione como un torpedo autónomo.
Si llegaste aquí directo, el contexto físico está en los artículos sobre la estructura central del AUV, el cono posterior y el sellado hermético del módulo de energía. Todo el proyecto está documentado en: [ver el proyecto completo].
Componentes de la electrónica de control AUV
La pila de control del Ai Apaec sigue una arquitectura de dos capas: un computador de misión de alto nivel (Raspberry Pi) que toma decisiones y un controlador de vuelo de bajo nivel (Pixhawk) que ejecuta los comandos sobre los actuadores. Este esquema es estándar en vehículos autónomos profesionales y tiene una ventaja clara para un proyecto DIY: si el piloto automático falla, el computador de misión sigue vivo, y viceversa.
Raspberry Pi — computador de misión
La Raspberry Pi actúa como el cerebro de alto nivel del vehículo. Ejecuta los algoritmos de navegación, gestiona la comunicación con la estación base en superficie via MAVLink, y en el futuro procesará los datos de cámara o sonar si se integran. La elección de RPi sobre alternativas como un Arduino Mega o una placa STM32 custom se justifica en tres puntos: corre Linux (lo que significa SSH, Python, ROS y depuración remota sin hardware especial), tiene suficiente potencia de cómputo para tareas de percepción futuras, y la comunidad de soporte es enorme. Usamos la Raspberry Pi 5, que dobla el rendimiento de la RPi 4 con una mejora térmica relevante para un cilindro estanco con ventilación limitada.
Pixhawk — piloto automático
El Pixhawk es el controlador de vuelo de código abierto que gestiona las operaciones de bajo nivel: estabilización, control de actitud y la interfaz directa con los ESC y servomotores. Recibe comandos de la Raspberry Pi por UART y los traduce en señales PWM precisas para cada actuador. La decisión de usar Pixhawk en lugar de una solución más simple como un Arduino con librería RC tiene una razón de peso: el Pixhawk integra acelerómetro, giroscopio y magnetómetro con redundancia de hardware, y el ecosistema ArduSub ya tiene implementado el modelo de física submarina (flotabilidad, arrastre, control de profundidad). No tiene sentido reinventar ese stack desde cero cuando existe y funciona.
ESC bidireccionales 35A/6S — tres unidades
Los ESC bidireccionales son el puente entre el Pixhawk y los motores. La palabra clave aquí es bidireccional: los propulsores submarinos necesitan girar en ambas direcciones para generar empuje reverso, y un ESC estándar de dron no permite eso sin modificación de firmware. Los ESC bidireccionales lo hacen nativamente, lo que simplifica la configuración y elimina un posible punto de fallo. La especificación 35A/6S da margen holgado para los motores de propulsión del Ai Apaec sin operar cerca del límite térmico.
Sensor de profundidad MS5837
El MS5837 es un sensor de presión diseñado específicamente para entornos submarinos, con un rango de hasta 30 bar (300 metros de profundidad) y resolución de 0.2 mbar. Su ventaja frente a sensores de presión genéricos más baratos es la compensación de temperatura integrada: bajo el agua, los gradientes térmicos entre la superficie y las capas más profundas causan deriva significativa en sensores no compensados, lo que se traduce directamente en error de profundidad. El MS5837 compensa eso internamente y entrega datos fiables al Pixhawk via I2C, permitiendo al controlador de profundidad mantener la cota deseada con precisión.
Servomotor impermeable D30
Como se documentó en el ensamblaje del cono posterior, el Ai Apaec controla su cabeceo y alabeo mediante superficies hidrodinámicas accionadas por servomotores. El Servomotor D30 fue elegido por su diseño impermeable y alto torque. La impermeabilidad no es un lujo: el sellado del tubo de transmisión de la aleta no es perfecto, y la humedad que se acumula en el cono a lo largo de misiones repetidas termina corroendo los servomotores estándar y haciéndolos fallar. El D30 está diseñado para aguantar esa exposición.
Módulo GPS UBX NEO-M9N
El GPS es un componente con una función muy específica y acotada en este AUV: proporciona posición geográfica precisa solo cuando el vehículo está en superficie. No penetra el agua, y no se espera que lo haga. Su valor está en tres momentos de la misión: registro del punto de inicio, marcado de posición durante maniobras en superficie, y localización para recuperación al finalizar una inmersión. El UBX NEO-M9N maneja cuatro constelaciones GNSS simultáneas (GPS, GLONASS, Galileo, BeiDou), lo que da un fix más rápido y más robusto que los módulos M8N anteriores, especialmente en zonas con cielo parcialmente obstruido.
Arquitectura de conectividad de la electrónica del AUV
El siguiente esquema muestra el flujo de energía y datos dentro del cilindro de electrónica y sus conexiones con los actuadores y sensores externos.
Fuente de energía y distribución
La energía proviene del cilindro de baterías (líneas rojas en el esquema). La línea principal pasa primero por un medidor de voltaje que envía el estado de carga a la Raspberry Pi para monitoreo en tiempo real. Desde ahí se ramifica en tres destinos: dos UBEC que regulan el voltaje (uno a 5-6V para la Raspberry Pi, otro a 7-8V para los servomotores), y los tres ESC que reciben la tensión de batería directa para alimentar los propulsores. Los UBEC son necesarios porque la Raspberry Pi es sensible a fluctuaciones de voltaje: cuando los propulsores demandan pico de corriente, la tensión de batería cae momentáneamente, y sin regulación eso puede causar resets del computador de misión en el peor momento.
Comunicación Raspberry Pi – Pixhawk
La Raspberry Pi y el Pixhawk se comunican por UART usando el protocolo MAVLink. Este canal transmite en ambas direcciones: la RPi envía comandos de misión de alto nivel (waypoints, cambios de modo, comandos de actuador) y el Pixhawk devuelve telemetría en tiempo real (actitud, profundidad, estado de los propulsores, alertas). El Pixhawk a su vez genera las señales PWM hacia los tres ESC y los dos servomotores basándose en esos comandos y en los datos de sus sensores internos.
Sensores externos
El sensor de profundidad MS5837 se conecta al Pixhawk por I2C, que es el bus nativo del sensor y permite que el firmware ArduSub lo integre directamente en el controlador de profundidad sin necesidad de código adicional en la Raspberry Pi. La antena GPS UBX NEO-M9N se conecta también al Pixhawk, que gestiona la adquisición de fix y expone los datos de posición al resto del sistema via MAVLink.
Montaje en el cilindro de electrónica
Todos los componentes se montan dentro del cilindro estanco de electrónica, que los aísla del entorno submarino. La versión actual es un montaje provisional para pruebas funcionales — la disposición final está pendiente de optimización para reducir la longitud del cableado interno y mejorar la distribución térmica. El criterio de montaje provisional es simple: accesibilidad para depuración, no compacidad.
Programación y calibración del sistema de control
Tener el hardware correcto es la mitad del trabajo. La otra mitad es hacer que el firmware entienda que está controlando un torpedo y no un dron de cuatro hélices. Esta sección documenta los pasos de configuración y, en particular, la modificación del código fuente de ArduSub que fue necesaria para que el Ai Apaec funcione correctamente.
Firmware ArduSub personalizado: el SUB_FRAME_CUSTOM
Cargamos el firmware ArduPilot (variante ArduSub) en el Pixhawk usando QGroundControl. ArduSub incluye varios frames de vehículo predefinidos (BlueROV2, SimpleROV, etc.), pero ninguno se ajusta a la configuración del Ai Apaec: dos propulsores horizontales para avance y guiñada, un propulsor vertical para cabeceo por empuje directo, y dos elevons (superficies de control combinadas aleta/timón) que gestionan el cabeceo y alabeo aerodinámico.
La solución fue definir un SUB_FRAME_CUSTOM directamente en el código fuente. En ArduSub, la definición de un frame es una matriz de contribución: cada fila corresponde a un actuador y cada columna a un grado de libertad (surge, sway, heave, roll, pitch, yaw). Un valor positivo en la celda indica que ese actuador contribuye positivamente a ese DOF cuando recibe comando positivo. Modificar esta matriz correctamente es lo que hace que el vehículo reaccione como debe al joystick.
SUB_FRAME_CUSTOM para el Ai Apaec en el código fuente de ArduSub.El primer problema que encontramos al probar en modo Stabilize fue un acoplamiento cruzado entre ejes: un comando de alabeo producía movimiento de cabeceo y viceversa. Este es un síntoma clásico de mezcla incorrecta en los elevones. Los elevons son superficies que combinan la función de alerón y elevador: para cabeceo, ambas se deflectan en el mismo sentido; para alabeo, se deflectan en sentidos opuestos. Si la suma y la diferencia están invertidas en la matriz, los ejes se cruzan.
La corrección se hizo en dos frentes: ajustar los signos en la definición de mezcla de los elevons dentro del SUB_FRAME_CUSTOM, y calibrar el parámetro AHRS_ORIENTATION para que el Pixhawk interpretara correctamente su orientación física dentro del cilindro (estaba montado en una posición no estándar). Tras esos ajustes, logramos control manual completo en los seis grados de libertad: avance, guiñada, cabeceo, alabeo, y los dos propulsores respondiendo coherentemente al joystick.
El estado actual es funcional en Stabilize, con una respuesta algo lenta que se corregirá en la próxima fase de afinación de PIDs. El firmware modificado está disponible en el repositorio fork de ArduPilot, branch version_0.2.
Sistema operativo en la Raspberry Pi
La Raspberry Pi 5 corre Raspberry Pi OS en su versión lite (sin escritorio), lo que reduce el consumo de memoria y los procesos en segundo plano que podrían interferir con los scripts de tiempo real. Se configuraron los servicios UART para la comunicación serial con el Pixhawk y el stack MAVLink para el enlace con la estación base. La elección de OS lite sobre Ubuntu Server fue práctica: mejor soporte de hardware nativo de RPi y menos configuración de drivers.
Comunicación con la estación base
El enlace de telemetría actual funciona via MAVLink sobre WiFi cuando el AUV está en superficie, lo que permite monitorear estado de batería, actitud, profundidad y enviar comandos de control desde QGroundControl en un laptop. Este esquema es suficiente para las pruebas de desarrollo — mientras el vehículo pueda subir a superficie periódicamente, la comunicación se mantiene. Para misiones autónomas prolongadas bajo el agua sin retorno a superficie, se necesitaría equipamiento acústico submarino, que queda fuera del alcance de esta fase del proyecto.
Preguntas frecuentes sobre la electrónica de control de AUVs
¿Qué firmware se usa para controlar un AUV DIY?
El firmware más usado en AUVs DIY es ArduSub, que es la variante submarina de ArduPilot. Corre sobre Pixhawk y tiene implementado el modelo de física submarina, modos de vuelo específicos para ROVs y AUVs (Stabilize, Depth Hold, Auto), y soporte nativo para sensores como el MS5837. Para vehículos con configuraciones no estándar —como el Ai Apaec con elevons— es necesario definir un frame personalizado modificando el código fuente y recompilar el firmware.
¿Por qué usar Raspberry Pi junto con Pixhawk en un AUV?
La combinación Raspberry Pi + Pixhawk implementa una arquitectura de control de dos capas que separa responsabilidades. El Pixhawk gestiona el control de bajo nivel en tiempo real (estabilización, señales PWM a actuadores) con latencias de milisegundos. La Raspberry Pi gestiona las tareas de alto nivel que no son críticas en tiempo (navegación, procesamiento de datos, comunicación con estación base) con la flexibilidad de Linux. Usar solo Pixhawk limita la inteligencia del vehículo; usar solo Raspberry Pi sin un controlador dedicado hace el control en tiempo real frágil y propenso a interrupciones del sistema operativo.
¿Qué sensor de profundidad se recomienda para un AUV DIY?
Para la mayoría de proyectos AUV DIY, el sensor de profundidad recomendado es el MS5837, disponible en versiones de 2 bar (20m) y 30 bar (300m). Su ventaja principal frente a sensores de presión genéricos es la compensación de temperatura interna, que elimina la deriva por gradientes térmicos. Se comunica por I2C, tiene soporte nativo en ArduSub, y su footprint pequeño facilita la integración en cilindros estancos compactos. Para profundidades de hasta 30 metros, la versión de 2 bar tiene mejor resolución.
Conclusiones y próximos pasos
La arquitectura de control del Ai Apaec está operativa: Raspberry Pi y Pixhawk comunicados, actuadores respondiendo correctamente, firmware personalizado con el SUB_FRAME_CUSTOM validado en modo Stabilize. La parte técnicamente más compleja de esta fase —la definición correcta de la mezcla de elevons y la calibración de orientación del IMU— ya está resuelta.
Los próximos pasos en orden de prioridad son: afinación de los controladores PID en agua (la respuesta actual en Stabilize es correcta pero lenta), desarrollo del modo de vuelo personalizado que gestione la relación entre velocidad de avance y ángulo de cabeceo para el control de profundidad hidráulico, y el ensamblaje y sellado definitivo del cilindro de electrónica. Ese proceso de sellado está documentado en detalle en el artículo de sellado hermético del módulo de energía.
