Table of Contents
Paparazzi en un STM32F3
Daniel García Vaglio (B42781) Y Esteban Zamora Alvarado (B47769)
Objetivos
Daniel Garcia Vaglio:
- Implementar el mapeo de pines en el STM32f3 para el funcionamiento de Paparazzi en el microcontrolador.
- Construcción del fuselaje para adaptarse al STM32f3.
- Configurar el plan de vuelo del multicóptero.
- Configurar el GPS y magnetómetro para lograr la estabilización del mismo por medio de Paparazzi.
Esteban Zamora Alvarado:
- Configurar los acelerómetro, giroscopio y motores del multicóptero para lograr la estabilización del mismo por medio de Paparazzi.
- Crear el tutorial para la configuración de los sensores y el vuelo del multicóptero por medio de Paparazzi.
Descripción
Este proyecto consiste en implementar un sistema de estabilización avanzado en un multicóptero para esto se utilizará paparazzi. Este coptero utilizará un STM32f3, que es un controlador de bajo costo y alto desempeño.
Telemetría
Xbees
A partir del trabajo realizado en la primera parte de proyecto con respecto a la comunicación UART alámbrica, se procedió a implementar la comunicación por telemetría por medio de los modems Xbee, tal como se indica en el tutorial.
Para esto se realizó la conexión de los módulos al STM32f3 (mediante la PCB) y a la computadora mediante un adaptador USB. Una vez iniciada la sesión de Datalink en Paparazzi (transmisión y recepción de datos), en un principio no se lograba establecer la telemetría, sin embargo, se reconoció que el baud rate de los Xbees no estaba configurado al valor por defecto de Paparazzi, el cual corresponde a 57600 BPS.
Para configurar este valor, se utilizó la aplicación XCTU de Digi (fabricante) en donde se cambió el baud rate para ambos módulos al valor indicado previamente. Este software no está implementado en Linux, por lo que se puede utilizar Wine para poder ejecutarlo en Debian.
Videos de la experimentación con XBEE:
PCB
Versión simplificada
Debido al tiempo necesario para poder construir el modelo completo de la tarjeta PCB a dos capas diseñado en la primera parte del proyecto, se tomó la decisión de construir una versión simplificada de la tarjeta a una cara, la cual tiene los conectores para 4 motores (señales PWM), el módulo Xbee, el STM32f3, la interfaz UART alámbrica (utilizada en la primera parte) y el GPS.
De esta manera, se procedió a realizar el diseño por medio del entorno Kicad, tal como se describió para el modelo completo de la PCB en la primera parte del proyecto. Se realizó el diseño esquemático en el software Eeschema de Kicad y se creó el archivo netlist.
Posteriormente se llevó a cabo la asignación de los conectores adecuados en el programa Cvpcb (footprints). A continuación, se creó el diseño físico de la tarjeta PCB en el programa Pcbnew tomando las indicaciones adecuadas sobre el tamaño de los componentes, pads, conectores y pistas.
Una vez terminado el diseño en Kicad se realizó el procedimiento descrito en el tutorial del Wiki del ARCOS-lab para generar el archivo imprimible por la cortadora laser ( tutorial), utilizando el programa Inkscape. Luego de pintar la tarjeta de cobre con pintura negra (tal como lo indica el tutorial antes mencionado) y cortar la tarjeta al tamaño del diseño de la PCB, se procedió a realizar la impresión de la tarjeta por medio del software Retina Engrave, el cual utiliza la cortadora laser. A continuación se adjunta un video del proceso de impresión de las pistas en la tarjeta de cobre: video.
Posteriormente, se procedió a colocar la tarjeta en ácido para que el mismo separara correctamente las pistas de cobre, después de lo cual se limpió la pintura de la PCB utilizando un disolvente.
Una vez terminada la impresión de la tarjeta PCB, se agregaron los conectores a la misma por medio de soldadura de estaño. De esta manera, se completó la construcción de la tarjeta PCB.
Cuando estaba lista la tarjeta y mientras se conectaba el GPS se notó un error en la misma. El Rx y el Tx estaban invertidos. Se procedió a cortar las pistas existentes y a pasar jumpers para tener las pistas correctas. Este error se provocó a la hora de nombrar las terminales de los componentes, ya que el Rx del STM se conecta con el Tx del GPS y viceversa, pero el error se encontró a tiempo y no se presentaron daños en el equipo.
Videos relacionados con la tarjeta PCB:
GPS
Interfaz con Debian
La primera parte es verificar el estado del GPS, para esto se siguió como base el proyecto de programación bajo plataformas abiertas Social GPS . Se debe leer información del GPS, entonces se instala gpsd y gpsdclients pythongps para poder comunicarse con el GPS. Estos son los paquetes necesarios para leer el GPS utilizando un adaptador UART-USB como el utilizado en la primera parte de este proyecto. Una vez bien conectado, se corre gpsd para leer el archivo que genera el GPS conectado.
Sin embargo el GPS no recibía señal. Entonces para poder tomar señal se debe alejar al menos 4 metros del edificio de ingeniería Eléctrica de manera que se reduzca la interferencia.
En Paparazzi
Una vez en Paparazzi se debe configurar el boudrate del GPS. Se configura a 38400 bps. Para poder acoplarse al funcionamiento natural del GPS. Paparazzi toma por defecto 9600bps para el GPS, entonces en el archivo de configuración general se debe definir la nueva velocidad. Una vez configurada la velocidad del dispositivo, paparazzi era capaz de continuar con el plan de vuelo, ya que lo primero que hace es esperar el fix del GPS.
A continuación videos relacionados con GPS:
IMU
Acelerómetro
Para lograr obtener las lecturas correctas en el sensor de acelerómetro, en primer lugar se observó cómo se comportaban los valores ADC que enviaba el mismo por medio de I2C mediante la herramienta de tools/messages y tools/realtimeplotter en el Paparazzi Center.
De esta manera se observó que los ejes x y y estaban invertidos por lo que se procedió a cambiar estos dentro del driver del sensor ubicado en: paparazzi/sw/airborne/peripherals/lsm303dlhc.c, específicamente la función lsm303dlhc_event, la cual escribe las lecturas obtenidas a partir de los registros del sensor dentro de un vector cuyas entradas corresponden a cada uno de los ejes.
De esta manera se cambió la asignación de los ejes, después de lo cual se obtuvieron lecturas proporcionales a la posición del STM32f3 para cada uno de estos (x,y,z). Además, fue necesario cambiar algunos signos en las entradas de los ejes del vector de datos para así lograr el comportamiento adecuado del sensor.
Posteriormente, se utilizó el procedimiento indicado en ImuCalibration ( tutorial) en la wiki de Paparazzi para calibrar este sensor, el cual consiste básicamente en colocar durante un determinado tiempo la tarjeta en distintas posiciones para que estos datos tomados se pasen luego a un script de Python que devuelve los valores de sensibilidad y offset correspondientes a cada eje.
Giroscopio
El giroscopio no fue calibrado óptimamente según el método indicado en la Wiki de Paparazzi (http://wiki.paparazziuav.org/wiki/ImuCalibration/Gyroscopes). Esto debido a que se ocupa material especializado para lograr la calibración (tornamesa, encoder, entre otros), y en algunos casos los mismos desarrolladores de Paparazzi recomiendan en foros mantener los valores por defecto del fabricante.
Por otro lado, se revisaron los ejes del giroscopio, de manera que no entraran en conflicto con los valores que entrega el acelerómetro.
Aún con el giroscopio sin esta calibración mencionada anteriormente, este detecta correctamente las rotaciones que presenta el cóptero sobre sus propios ejes. Es importante indicar que Paparazzi utiliza una combinación del acelerómetro y el giroscopio para determinar el ángulo de inclinación.
Magnetómetro
El comportamiento del magnetómetro con respecto a la comunicación de datos es muy parecido al del acelerómetro en los aspectos generales, pues se encuentran en el mismo chip. Primero se calibró el magnetómetro interno, y se logró ubicar al STM32f3 correctamente respecto al campo magnético terrestre. Sin embargo esto fue hecho antes de tener listo el fuselaje pues se hizo a modo de prueba para comprobar el funcionamiento del magnetómetro y paparazzi.
Para calibrar el magnetómetro se corren los scripts que brinda paparazzi para la calibración. Lo que se hace es correr paparazzi, y recibir la informació por telemetría. Con toda la información, se crea un archivo log, el cual lee el script y se obtienen los valores sugeridos de offsets y sensibilidades. Mientras se crea el logfile, se debe tomar el cóptero y hacerlo rotar, de manera que el frente del cóptero cubra por completo una esfera.
Como se espera que las corrientes también generen distorsión en la medición entonces se debe correr otro script especial para corrientes.
Una vez comprobado el funcionamiento del chip, se procede a ensamblar el fuselaje. Sin embargo cuando esto se hizo, se perdió la calibración del magnetómetro y comienza a dar lecturas completamente aleatorias. Esto se debió a que todo el metal presente a su alrededor generó mucha distorsión del campo magnético. Además, por la configuración del cóptero ese sensor se encuentra muy cerca de la batería, cuya corriente genera campos magnéticos que perturban gravemente las lecturas del mismo.
Como resultado de la lecturas incoherentes del sensor, se procedió a conectar un chip externo. Para hacerlo se debe eliminar las lecturas que recibe paparazzi del magnetómetro interno y sustituirlas por las lecturas del magnetómetro externo (que está ubicado en un lugar más conveniente). Realizando diferentes pruebas se logró desconectar la transmisión de datos del magnetómetro interno conservando los datos enviados por el acelerómetro, lo cual es importante ya que se ocupa que estos sensores a pesar de estar en el mismo chip, uno envié lecturas (acelerómetro) y el otro no (magnetómetro).
AHRS
Cuando se realizaban las primeras pruebas de paparazzi, con los sensores, se logró calibrar la tarjeta, pero la respuesta era muy lenta. Para entender mejor el problema se utilizó la herramienta real-time-plotter, lo que hace es graficar una determinada variable a través del tiempo. Como se puede ver en los videos al final de esta sección, se comenzó a graficar cada parte del proceso para determinar dónde se encontraba el error. se analizó desde los raw values,, los scaled values hasta los valores finales después del filtrado y los arreglos por parte de la integración de todos los sensores.
Se podía apreciar un comportamiento exponencial, esto es que cuando se cambiaba la STM32f3 de posición, entre más lejano estaba el valor del sensor del real, más rápido cambiaba, pero entre más cerca, más lento cambiaba. Esto podía deberse a la mala direccción de los ejes en los sensores, pero luego de analizar cada sensor por separado, se determinó que todos los ejes estaban correctos.
Se notó cuando el STM32f3 se movía bruscamente el raw del acelerómetro se perdía, y luego de un tiempo volvía con otro valor. Entonces el comportamiento exponencial podía deberse a que el acelerómetro se desconecta, y los valores dejan de retroalimentar, por tanto a pesar que todos los sensores dicen que cambian, el acelerómetro no lo hace. Sin embargo el acelerómetro no siempre se desconectaba. Se notó que el comportamiento exponencial siempre estaba presente, pero se ralentizaba cuando el acelerómetro se desconectaba.
Luego se contempló la posibilidad de que la STM32f3 no soportara la velocidad de muestreo que se le solicitaba. Entonces se variaron las frecuencias de muestreo del acelerómetro y el giroscopio. Cuando esto se hizo, el comportamiento del cóptero mejoró notablemente. Los cambios en las lecturas eran más rápidos.
Antes el PFD era muy lento, pero ahora se acercaba a la realidad. La frecuencia se bajó de 512Hz a 20Hz. Sin embargo se comenzaron a variar las frecuencias y se notó que las señales cambiaban su comportamiento. Cuando el acelerómetro se muestreaba más rápido (que el giroscopio), se amplificaba el ruido, y las vibraciones afectaban mucho la medición del ángulo.
En el caso contrario la señal tenía un comportamiento subamortiguado, es decir un comportamiento senoidal modulado por una exponencial. y al estar cercanas, si la frecuencia era muy alta, presentaban comportamiento amortiguado (exponencial) y si las frecuencias eran bajas,las mediciones se comportanban cercanas a críticamente amortiguado.
Al finalizar el análisis se toma la decisión de permanecer con los 20Hz, y el cóptero responde correctamente a los estímulos externos cuando se hace operar en Attitude control.
A continuación videos de la experimentación con IMU:
https://www.youtube.com/watch?v=7ytlXeuS_yQ
https://www.youtube.com/watch?v=CaKPdo1k9Tw
https://www.youtube.com/watch?v=btGgqrzdHpU
https://www.youtube.com/watch?v=CoWx4HKdqwQ
Comunicación por Radio Control
El proceso de lograr la comunicación por radio control constó de dos partes principales, la configuración del perfil en el control y la correcta interpretación de la señal PPM por medio de Paparazzi para el STM32f3.
Control
En lo que respecta al control, se creó un nuevo perfil en donde a cada canal se le asignó adecuadamente la señal correspondiente a cada stick del control (4 canales correspondientes a los comandos del cóptero) y a un switch, el cual permite cambiar el modo de vuelo. Dentro de las consideraciones importantes tomadas en cuenta para el correcto funcionamiento del radio control se encuentra la calibración del valor neutral para cada stick.
PPM en Paparazzi
Para lograr hacer funcionar el reconocimiento de la señal PPM en Paparazzi con el STM32f3, fue necesario agregar y modificar unas líneas en el archivo ppm_arch.c, ubicado en la dirección: paparazzi/sw/airborne/arch/stm32/subsystems/radio_control/.
Estos cambios realizados estaban relacionados con ciertas condicionales que no tomaban en cuenta la utilización de la STM32f3. Este archivo ya modificado para el soporte de la STM32f3 se encuentra actualizado en el github del ARCOS-lab.
Por otro lado, fue fundamental crear el archivo de configuración específico para el control utilizado en el proyecto (FS-TH9x), el cual está ubicado en paparazzi/conf/radios/FSTH9x.xml. Tal como lo indica el tutorial, fue necesario hacer coincidir varios parámetros entre el control y este archivo de configuración, tales como número de canales, valores mínimos, neutrales y máximos de cada canal, tiempo mínimo de sincronización de la señal PPM, entre otros.
Se observó que si estos valores no son correctos, Paparazzi no interpreta correctamente la señal y entonces incluso en las posiciones neutrales de los sticks del control el programa interpretaba que el stick se encontraba en una posición más alta o más baja de la real, e incluso es posible que no se detecte la señal del todo.
El pin utilizado en la STM32f3 para la señal PPM (PD1) se determinó al realizar el mapeo de pines de la tarjeta en Paparazzi en la la primera parte del proyecto.
A continuaciónvideos relacionados con radio control:
https://www.youtube.com/watch?v=o_JigyDYVWE
https://www.youtube.com/watch?v=FpN9HMPmPZo
https://www.youtube.com/watch?v=_Mtwo6KzTV0
Fuselaje
Adaptación para la PCB
Armado del frame y patas
El fuselaje del cóptero fue modificado para poder utilizar un mejor sistema de patas, ya que las que tenía previamente no eran lo suficientemente robustas ni se encontraban interconectadas para tener un buen soporte . De esta manera, se adaptó una pieza de acrílico a la cual se le hicieron los huecos necesarios para poder colocarle el soporte para el nuevo sistema de patas, por lo que fue necesario quitar la pieza inferior del frame, la cual fue sustituida por la de acrílico.
Esta pieza de acrílico, al ser más grande permitió a su vez colocar sobre ella componentes como el módulo receptor de la señal del radio control y convertidores de voltaje.
Motores
PWM
En un principio, al intentar probar la respuesta de los motores en Paparazzi no se logró la activación de los mismos, por lo que fue necesario revisar el código y la configuraciones en el software para identificar el problema.
Al investigar sobre las señales PWM generadas por medio de la STM32f3, se observó que la asignación de las funciones alternativas de los pines que enviaban la señal PWM (GPIOs) era incorrecta, tal como se indica en el tutorial.
Una vez modificada esta configuración para cada uno de los canales PWM, se logró hacer funcionar por primera vez los motores por medio de un programa de prueba, el test_actuators_pwm_sin, el cual permitió confirmar que la tarjeta sí era capaz de enviar la señal para activar los motores por medio de Paparazzi, aunque en este programa no era posible cambiar el duty cicle de la señal.
Posteriormente, se utilizó el programa test_actuators_pwm, el cual se describe en el tutorial, y que permite variar el ancho en milisegundos de la señal PWM. Esto facilitó observar la variación de la potencia de los motores al modificar esta señal, lo cual fue muy útil para realizar pruebas.
Una vez funcionó el sistema de radio control, fue posible seleccionar diferentes modos de vuelo del cóptero en la ventana del GCS. Esto permitió probar el modo RC_DIRECT, el cual enviaba la señal PWM a cada motor dependiendo de las posiciones de los sticks asignados a cada comando: throttle, roll, pitch y yaw.
Se pudo observar por medio de un osciloscopio que al mover los sticks en el control, se modificaba el ancho de pulso de la señal PWM, el cual aumentaba o disminuía respectivamente según estos comandos, de la manera esperada según el movimiento que debían tener los motores para cada una de dichas órdenes. Este comportamiento se muestra en el siguiente video:
ESCs
Al realizar las primeras pruebas con los 4 motores, se observó que algunos iniciaban antes que otros al ir aumentando el throttle, por lo que luego de investigar se observó que esto ocurría cuando los rangos de throttle de los ESCs no estaban calibrados. De esta manera se llevó a cabo el procedimiento explicado en el tutorial, lo cual solucionó este problema.
Conexiones
Al hacer pruebas con motores, se observó que algunas veces los mismos presentaban un comportamiento errático, el cual les impedía realizar el arranque. Al ocurrir este problema de manera aleatoria, se determinó que posiblemente esto sucedía debido a un mal contacto en los cables de las fases que activan el movimiento del motor.
De esta manera, se cortaron los conectores de los cables y se volvieron a hacer las conexiones soldando nuevos conectores a los mismos, lo cual solucionó el problema en uno de estos motores. Se observó que un motor se daño debido a que los tornillos que sujetaban el motor a los brazos del cóptero eran muy largos, por lo que llegaron a romper el embobinado que genera el movimiento del motor.
Este motor se tuvo que sustituir por otro para así poder continuar con las pruebas de vuelo, teniendo las precauciones necesarias para manipular y conectar correctamente estos componentes.
Pruebas con hélices
Una vez se logró que funcionaran los módulos de radio control, telemetría, señales PWM, IMU y que se configuraran los archivos descritos a lo largo del tutorial y este documento, observándose un comportamiento lógico en el movimiento de los motores, se procedió a colocarle las hélices a los mismos, y así poder probar los comandos por radio control y la respuesta de estabilización básica del cóptero.
De esta manera, se observó que el valor neutral de los motores debía estar más bajo ya que al armarse los motores estos iniciaban con mucha potencia, por lo que se determinó que el valor neutral de los motores debía estar cercano a 1.15 ms, lo cual se redefinió en el archivo de airframe configuration en la sección de servos.
Luego de esto, se realizaron las pruebas de los comandos throttle, roll, pitch y yaw en el modo RC_DIRECT y se observó que el cóptero tendía a inclinarse correctamente según cada comando. Posteriormente, se cambió el modo en el GCS a ATTITUDE, el cual consiste en el primer modo de estabilización de Paparazzi, y que utiliza los valores de los ángulos de orientación en tiempo real del cóptero indicados por el IMU y el sistema AHRS para lograr conservar la orientación indicada por los comandos de radio control.
En este modo, al tener los sticks de roll, pitch y yaw en su posición neutral, lo cual indica una inclinación esperada nula, e inclinando el frame del cóptero hacia cualquier lado, se logró observar como aumentaba o disminuía la potencia de los motores, de manera que el controlador lograba recuperar la orientación inicial del cóptero.
Es importante mencionar que estas pruebas se realizaron de manera controlada mientras dos personas sostenían el fuselaje del cóptero para observar la respuesta de los motores.
Finalmente, se procedió a intentar realizar un primer vuelo de prueba a muy baja altura, sin embargo, al ir aumentando el throttle de los motores para lograr elevar el cóptero se incrementó a su vez la vibración del frame en gran medida, por lo que la STM32f3 (que contiene el acelerómetro y giroscopio del IMU) estaba siendo sometida a altos niveles de vibración y esto causó que se fuera acumulando un bias o error en la determinación de los ángulos por parte del AHRS.
Esto provocó que el controlador de vuelo detectara que el cóptero se encontraba cada vez más inclinado (aunque realmente estuviera sin inclinación) por lo que “trataba” de estabilizarse a la posición “neutral”, aumentando la potencia de ciertos motores para lograr esto.
Sin embargo, como realmente el cóptero no estaba inclinado, este aumento en la potencia de los motores más bien provocaba una desestabilización, por lo que no se logró volar el cuadracóptero bajo estas condiciones. A pesar de esto, se logró observar que este algoritmo de estabilización responde correctamente y consecuentemente con los ángulos determinados por el AHRS.
Tutorial
El tutorial tiene como fin, ayudar en el inicio de los siguientes proyectos con paparazzi, de manera que se facilite la puesta en funcionamiento de un cóptero con paparazzi y un stm32f3. En este tutorial se explica desde lo básico, como el proceso de instalación de paparazzi, hasta los últimos avances en el proyecto, como las frecuencaias AHRS y las calibraciones entre los esc y radiocontrol. El tutorial se encuentra en https://wiki.arcoslab.eie.ucr.ac.cr/doku.php/stm32f3_discovery_with_paparazzi, y a continuación el índice:
