Piloto automático casero en una placa de computadora de placa única (SBC) y Arduino DUE

La idea de construir un piloto automático surgió hace aproximadamente 2 años. Quería crear un aparato totalmente autónomo capaz de llegar del punto A al punto B con la posibilidad de evitar colisiones y volar alrededor de obstáculos, capaz de superar zonas de interferencia o la ausencia de una señal de satélite. También quería tener un control conveniente y simple con el mouse, ya que se implementa en juegos (estrategias) que controlan el movimiento del avión con la ayuda de puntos. Tuve que comenzar todo desde cero, como este artículo, así que si hay errores, escríbalo en los comentarios. Comenzaré en orden.

Hardware

Inicialmente, no sabía qué hardware es mejor usar para este proyecto, pero al final llegué a la conclusión de que la mejor opción sería un montón de microcontrolador (MK) + computadora de placa única. Cuando MK resuelve el problema de la estabilización de una aeronave (LA), su movimiento en un rumbo y altitud determinados, y una computadora de una sola placa resuelve el problema de navegación y movimiento a lo largo de una ruta. Dado que el plan era evitar colisiones, la computadora tenía que ser lo suficientemente potente como para procesar la información de los sensores de detección de obstáculos, compacta y no demasiado cara en ese momento. TinkerBoard era el más adecuado para esta descripción, Raspbery era entonces 3B + y tenía características muy inferiores. Como MK, quería tener un controlador compatible con Arduino porque Arduino tenía una gran base de bocetos listos y, por lo tanto, la elección recayó en DUE 84 MHz, 32 bits ARM Cortex-M3 porqueél era el más poderoso y tenía que compensar la franqueza de mis manos)).

Inicialmente, planeé usar el MPU 9250 con un filtro Majevik como sensores de orientación, y sus resultados fueron excelentes. La principal ventaja de esta opción era que todos los cálculos, incluida la calibración de los sensores (acelerómetro, giroscopio y magnetómetro), se realizaban en el MK. Pero había un problema, el filtro compensaba poco la aceleración lineal, que se produce constantemente durante los golpes o un cambio brusco de rumbo. Esto se expresa en las lecturas de cabeceo y balanceo, en el momento de la aceleración comienzan a alejarse flotando, y pasando a través del regulador proporcionalmente diferencial (PD) y especialmente la parte diferencial, la flotación creó problemas. Por lo tanto, tuve que usar un sensor con un filtro BNO 055 ya implementado.

A diferencia del MPU 9250, el BNO tiene integrado el Cortex M0 MK integrado, que calcula inmediatamente la orientación en ángulos de Euler, la orientación absoluta en cuaternina y calcula la aceleración lineal, aunque este sensor también tiene varias desventajas. El principal problema de este sensor es la autocalibración, o mejor dicho, que no se puede apagar, es un "ajuste" de este sensor y esta calibración tiene una propiedad desagradable de desaparecer, a veces de forma absolutamente repentina incluso estando en un solo lugar sin movimiento. Esto se refleja principalmente en la guiñada que está unida al magnetómetro en este sensor y debe mostrar la dirección hacia el polo norte magnético (curso), pero a veces muestra 100 grados en estrona, y luego, después de la calibración, puede volver))). En otros asuntos, el problema del curso aún se puede resolver utilizando la sincronización con GPS. De lo contrario, el sensor funciona bien,siempre determina el cabeceo y balanceo correctamente, y las aceleraciones lineales no afectan en gran medida su trabajo, a menos, por supuesto, que la aceleración no exceda de 2G, porque Este umbral se utiliza para medir el vector de gravedad y compensar la deriva de los giroscopios.

El resto del conjunto de hierro es el siguiente: GPS Ublox Neo M8N con salida USB,
barómetro BMP 280, sonda HSCR 04 para recibir datos sobre disponibilidad en el suelo y velocidad vertical más precisa, EEPROM 24c16 para almacenar datos de calibración y configuraciones PID, módulo Neoway M509E GSM para enviar mensajes sobre las coordenadas de la aeronave en caso de accidente.

El diagrama funcional se muestra en la Figura 1:


Figura 1 - Diagrama funcional del piloto automático .

Software

Para el desarrollo de software, uso QT junto con QT Creator IDE. me es muy familiar y, gracias a la funcionalidad multiplataforma, puedo ejecutar mis programas tanto en una PC de una sola placa con Debian como en un escritorio con Windows, lo cual es muy conveniente. Para desarrollar el software del microcontrolador, se utiliza el IDE Arduino. Para mayor claridad, intentaré presentar todas las secciones de la Figura 2.


Figura 2. - Arquitectura del AP (BNO 080 agregado para el futuro).

1) Interfaz gráfica de control: es un mapa satelital con la ayuda de la cual se controla el avión. El programa de visualización de imágenes satelitales en sí no es mío, fue robado por mí aquí (su autor también trató de hacer algo similar).

Puede controlar la aeronave utilizando puntos (marcadores) o botones WADS. Para controlar los puntos, es necesario establecer la ruta de vuelo con marcadores verdes, se colocan con el mouse (RMB) y hacer clic en cargar ruta, o usar el marcador de movimiento instantáneo (rojo) (LMB) y luego el avión desde la posición actual volará a este punto, para su operación es necesario establecer casilla de verificación en la casilla de verificación "Manual" de clics accidentales.

Todos los parámetros de marcador se ingresan en los campos apropiados en el formulario, puede eliminar los marcadores haciendo doble clic en el botón central del mouse, mientras que aún permanecerán en la memoria del avión, debe usar el botón Eliminar ruta para eliminarlos de la memoria. Al llegar al punto, como en las estrategias de la aeronave, girará a su alrededor. Control de botones WADS controla directamente los volantes usando controladores PD. Cuando se presiona cada botón, se ingresa un valor a la entrada del controlador, por ejemplo, cuando se presiona S, el tono 30 y cuando se suelta es 0. Cuando se presiona W -30, etc. WADS se activa mediante casillas de verificación: "manual", "botones". Este modo ayuda a verificar la funcionalidad de todos los timones antes de comenzar. La interfaz gráfica se ejecuta en la computadora portátil, los comandos de control desde la interfaz gráfica que usa el socket TCP se transfieren al kernel. La interfaz de control gráfico se muestra en la Figura 3:


Figura 3 - Interfaz gráfica de gestión.

2) El núcleo del piloto automático es esa parte del software que se calcula en una computadora de placa única TinkerBoard. El núcleo es responsable de la navegación y el movimiento a lo largo de la ruta. Para hacer esto, se conecta un sensor GPS a la computadora. Al usarlo, puede obtener la posición actual de la aeronave (latitud y longitud) y comparar esta posición con lo que está en la ruta de vuelo. Como resultado de esta operación, se obtiene el acimut al objetivo, que se envía al microcontrolador junto con el resto de los parámetros de vuelo. En el futuro, el kernel puede equiparse con su sensor IMU para implementar el ANN. Por ejemplo, puede usar BNO 080 para integrar, acelerar y obtener velocidad, y al integrar la velocidad, obtener la distancia. La distancia recibida del ANN deberá traducirse al sistema de coordenadas GPS (latitud y longitud) para su uso en el cálculo del acimut.

Tal ANN puede usarse junto con un sensor GPS en caso de pérdida temporal de comunicación con el satélite para que la aeronave no pierda un "giro" a un punto. En el momento de la operación desde el GPS, el ANN se ajustará constantemente por sus lecturas y completará los espacios entre los períodos de actualización del sensor GPS. Del mismo modo, el algoritmo de visión artificial o SLAM debe ajustarse cambiando la altura del punto y creando sesgos del acimut calculado. Una vez que se completa el cálculo de la ruta, el núcleo envía datos UART: acimut, altitud, ángulo de ataque, tipo de punto y también si es necesaria la rotación alrededor de este punto.

3) El microcontrolador ejecuta los comandos principales, la tarea principal del MK es seguir el curso dado a una altura determinada. Para esto, el MKU está equipado con un sensor IMU BNO 055, un barómetro bmp 280 y un sonar. Para el movimiento a lo largo del curso, se utiliza el acimut obtenido del núcleo, se compara con la velocidad actual y el desajuste resultante se transmite a los controladores PD para guiñar y rodar. El control de tono se lleva a cabo mediante 2 controladores PD: el primero determina la falta de coincidencia de las alturas actual y predeterminada, que se alimenta a la entrada del segundo controlador, mientras que la salida del controlador de altura está limitada por el ángulo de ataque actual para controlar su conjunto. Si en la interfaz gráfica se selecciona el tipo de punto para despegar o aterrizar, se utiliza un sonar para determinar la altura. Su testimonio se combina con los datos del barómetro,para determinar con mayor precisión la distancia al suelo y la velocidad vertical. Además de las funciones básicas, MK también recopila telemetría sobre el funcionamiento de los sensores IMU, la dirección y altitud actuales, los transfiere al núcleo, donde estos datos se complementan con datos del GPS e ingresan a la interfaz gráfica.

Conclusión

Por el momento, el piloto automático todavía está en la etapa de prueba de vuelo y no está completamente configurado. Sin embargo, pasé solo dos inicios y aún no he recogido los coeficientes para los reguladores.

En general, los reguladores de DP me parecen inestables y quiero reemplazarlos por algo más confiable, especialmente porque ya están desactualizados. También es necesario reemplazar los cálculos con ángulos de Euler con cálculos en cuaterniones, porque estos últimos se comportan de manera más estable cuando giran la aeronave en ángulos superiores a 120 grados y vuelan durante el viento.

Una toma más detallada de la aviónica

Enlace al código fuente del veneno (con bibliotecas) Github aquí solo la fuente pero más reciente