CEFIRO DRON
Enlace a la documentación completa del proyecto
El principal objetivo de este proyecto es el desarrollo de un dron cuadricóptero, basado en Arduino con la posibilidad de hacer fotografía aérea, y que permita colocar diferentes tamaños de cargas, hasta un máximo de medio kilo. Además, se ha de poder utilizar en un gran rango de tareas.
El software utilizado es de tipo abierto para tener flexibilidad y costes bajos. Al igual que el hadware.
En este trabajo se ha estudiado: el nivel de la técnica de los UAV´s (drones) y sus clasificaciones; el diferente hardware libre que existe actualmente, y que se podría utilizar para volar de manera efectiva y segura, así como los distintos softwares de tipo abierto y las funciones que realizan. Basándose en este estudio y en los objetivos, se ha realizado el dimensionamiento general del dron. Justificando debidamente la selección de los componentes elegidos.
Se ha utilizado el programa eCalc para realizar los cálculos necesarios para el dimensionamiento de la propulsión del motor, la batería y las hélices.
La estructura mecánica es de tipo H, y en un principio se iba a desarrollar 3D con el programa SolidWorks. Pero finalmente por reducir costes y asegurar una rigidez y resistencia altas, se ha optado por recurrir al mercado asiático y adquirir un frame (cuerpo del dron) ya impreso.
Finalmente, se ha realizado un test de los componentes que asegurará la estabilidad del equipo. Y también, se han realizado pruebas de los controladores de Ardupilot ajustando los valores de control con un procedimiento empírico hasta conseguir el funcionamiento deseado.
A lo largo de esta memoria se recogerá todo el proceso, las dificultades e imprevistos que han ido surgiendo, soluciones implementadas y el resultado.
En este capítulo se estudia el hardware que existe actualmente en el mercado, y muestra las placas más conocidas de los UAV y finalmente, los softwares de tipo abierto más potentes que existen.
- Arduino Nano o Mini. Son varias las desventajas que se encuentran en el montaje de un UAV con Arduino, entre las que se pueden destacar la gestión de interrupciones.
Para explicar las interrupciones de Arduino se propone un ejemplo muy simplificado: Diseñamos un sistema que tiene que atender una serie de actuadores (por ejemplo, un botón), tendremos que andar sondeándolos periódicamente para ver si se pulsó el botón. ¿Pero qué ocurre si se pulsa un botón mientras el programa anda ocupado en otra tarea y justo en ese momento no se está sondeando la entrada del actuador? En este caso el sistema no será capaz de detectar la pulsación. La solución en este caso es el uso de interrupciones. Cuando se dispara una interrupción, el procesador detiene la ejecución del programa que está corriendo, almacena el estado de los registros (incluido el contador de programa), y ejecuta un subprograma, llamado rutina de servicio de interrupción, que atiende la interrupción (en este caso la gestión de la pulsación del botón). Una vez finalizada la rutina, el microprocesador restaura los registros y continúa la ejecución del programa principal por el mismo lugar en el que fue interrumpido.
Esta gestión de interrupciones haría inmanejable un equipo caro, que se encuentra levitando a varios metros del suelo, lo que supondría ante cualquier imprevisto un accidente fatal.
Otra de las desventajas de Arduino, se pone de manifiesto cuando se tiene que ampliar la versión estándar de la placa del microcontrolador por medio de interfaces adicionales y de funciones de entrada y salida. Si bien el hardware estandarizado permite ampliarse por medio de lo que se conoce como shields, la adquisición de estos módulos adicionales, incrementa rápidamente los costes del proyecto, así como el peso del UAV, lo que tampoco interesa para un equipo que hay que levantar del suelo con cuatro rotores.
| Figura 3 – Arduino Nano |
- PixHawk es un proyecto independiente y de hardware abierto que intenta dar soluciones hardware para autopiloto de vehículos de alta calidad a las comunidades académicas, de hobby e industriales a un bajo costo y una alta disponibilidad, según se dice en su página oficial. Pixhawk se ha convertido en los últimos tiempos en la plataforma preferida para desarrolladores, por las grandes posibilidades que ofrece. Ha superado a su antecesora, APM. En su interior lleva también el software de Ardupilot.
Cuenta con un procesador de 32 bits STM32F427 Cortex M4, y otro coprocesador de 32 bit STM32F103 con 256 Kb de RAM y 2 Mb Flash. Dispone de una IMU completa formada por giroscopio, acelerómetro, barómetro y magnetómetro, algunos de ellos por duplicado. Incorpora también 5 puertos UART, 2 puertos CAN, 1 puerto SPI y un puerto I2C. Además, dispone de numerosas entradas para los distintos tipos de receptores de radio, entre otros.
Tras analizar las opciones que nos ofrece cada plataforma se ha optado por utilizar para este proyecto la placa PixHawk de Ardupilot, por su versatilidad a la hora de ser programada y configurada para diferentes tipos de proyectos con UAVs. Dado que se quiere personalizar la aeronave con una configuración específica, esta placa nos ofrece una amplia gama de formas de comunicación y de control.
Se ha descartado la opción de APM ya que Pixhawk es su “sucesora”. También se han descartado las controladoras NAZA por su alto precio y por su imposibilidad de ser programada.
Al tratarse de un placa descendiente de Arduino, tan solo que con mejores características hardware, posee muchos puertos y protocolos en común entre los que podemos destacar:
- IMU
Es una unidad de medición inercial o IMU (del inglés inertial measurement unit). Es un dispositivo electrónico que mide e informa acerca de la velocidad, orientación y fuerzas gravitacionales de un aparato, usando una combinación de acelerómetros y giróscopos.
- UART
UART, son las siglas en inglés de Universal Asynchronous Receiver-Transmitter, en español: Transmisor-Receptor Asíncrono Universal, es el dispositivo que controla los puertos y dispositivos serie. Se encuentra integrado en la placa base o en la tarjeta adaptadora del dispositivo.
- I2C
Circuito inter-integrado (I²C, del inglés Inter-Integrated Circuit) es un bus serie de datos con un protocolo síncrono. I2C usa solo 2 cables, uno para el reloj (SCL) y otro para el dato (SDA). Esto significa que el maestro y el esclavo envían datos por el mismo cable, el cual es controlado por el maestro, que crea la señal de reloj. I2C no utiliza selección de esclavo, sino direccionamiento.
- SPI
El Bus SPI (del inglés Serial Peripheral Interface) es un estándar de comunicaciones, usado principalmente para la transferencia de información entre circuitos integrados en equipos electrónicos. Es otro protocolo serie muy simple. Un maestro envía la señal de reloj, y tras cada pulso de reloj envía un bit al esclavo y recibe un bit de éste. Los nombres de las señales son por tanto SCK para el reloj, MOSI para el Maestro Out Esclavo In, y MISO para Maestro In Esclavo Out. Para controlar más de un esclavo es preciso utilizar SS (selección de esclavo).
Cómo si de una placa Arduino se tratara, y como el propio software hace referencia, Ardupilot (firmware) que se ejecuta en nuestra placa de vuelo. Es el encargado de gestionar toda la información que recibe del exterior (sensores físicos y radio) y actuar en consecuencia sobre los actuadores de la aeronave.
Actualmente se puede descargar desde su repositorio de GitHub desde el cuál podemos descargar su código e incluso contribuir a su mejora.
La idea inicial era aportar código original a este proyecto, haciendo utilidad de un sonar para detectar el cambio de alturas que puedan propiciar montículos, u obstáculos en el aterrizaje, proporcionado en la asignatura de Diseño de Sistemas Empotrados. Pero por incompatibilidad de dicho sonar, y por el retraso en la llegada de los componentes, no se pudo implementar.
Pero este proyecto no muere aquí, se realizará un pedido de sonares analógicos, y no solo se instalarán en la zona inferior del dron, para facilitar su aterrizaje, e irlo acomodando al gusto del piloto a través del software, sino que también se implementarán sonares analógicos para la detección de objetos, tanto frontal, como lateral, como posterior, con el objetivo de crear un UAV que sea complicado chocarle.
Dejando a un lado las ideas originales frustradas, y ante la falta de tiempo para la entrega del proyecto, se optó por coger el código del repositorio de GitHub, revisarlo, y posteriormente testearlo en nuestra aeronave por si fuesen necesarios ajustes en el código para optimizar el vuelo.
Para cargar el código en nuestra placa, en lugar de abrir la aplicación de Arduino, teníamos que abrir la aplicación de Mission planner, conectarnos a nuestra placa por el puerto serie correspondiente, y posteriormente cargar el código obtenido de GitHub, la librería que se ha decidido cargar es Copter.h y un conjunto de modos de vuelos ya predefinidos. Todo este código se adjunta en el Anexo.
| Figura 31 – Carga de Código al Arducopter a través del puerto serie usando MissionPlanner |
4. DIFICULTADES Y SOLUCIONES ADOPTADAS
A lo largo de este proyecto se han ido sucediendo distintas dificultades e imprevistos, tanto a nivel hardware como a nivel software. En algunas ocasionas, estos imprevistos han sido resueltos, pero en otras ha sido muy complicado cumplir los plazos junto con el éxito del proyecto de manera conjunta. Estos son los principales problemas que han ido surgiendo en su transcurso:
- Elección de componentes. A la hora de elegir el proyecto, se partía con la certeza de que no iba a ser un proyecto barato, debido a la envergadura y complejidad de este. Se intentaron reducir los costes del mismo, en todo momento, buscando ofertas de segunda mano, y de grandes mayoristas.
Estas ofertas no se sucedían, y el tiempo se iba sucediendo. La solución final, fue rebajar el coste, reduciendo la calidad o la categoría de algunos componentes, y realizar la compra.
- Tiempos de entrega. Pese a realizar la compra de componentes con un margen considerable de tiempo, el material provenía de China, y ningún componente cumplió con los plazos de entrega prometidos. Lo que nos retrasó el ensamble del UAV 2 semanas. Los vendedores se excusaron con que: el 11 del 11, y fechas próximas al Blackfriday, suponen una carga muy elevada de trabajo para las compañías de transporte, y se retrasan los envíos.
- Componentes erróneos. Una vez habían llegado todos los componentes, se procedió al ensamblado del drone, y empezaron a sucederse más problemas. El receptor solicitado al vendedor, no había sido enviado, y su lugar, se había enviado otro tipo de receptor que era inviable instalar en nuestra configuración, debido al protocolo de comunicación que habíamos establecido en nuestra configuración.
La solución adoptada fue recurrir al mercado de segunda mano, y adquirir uno. El cuál también sufrió unos días de retraso en el envío.
- Otros problemas menores en este caso, porque tuvieron una solución más rápida, fue la escasez, o nulidad de conectores que enviaron los proveedores. Concretamente a la hora de alimentar el power module con los cables salientes de la PDB, es necesario un conector xt60, que el proveedor no incluyó. Como se comentaba anteriormente, se optó por doblar el cable sobre si mismo para aumentar su perímetro, pre estañearlo, e introducirlo en el conector xt60 hembra del power module.
Lo mismo sucedió con la alimentación de la placa controladora del Gimbal, se daba por hecho que se incluiría un conector para alimentarla, pero no. Se optó por solucionarlo con cables de un pack de Arduino, con terminales en formato pin macho y pin hembra, se llevó el pin positivo de alimentación del gimbal, al pin positivo de la lipo, e igualmente con el negativo.
- Otro problema grave que ya se ha mencionado con anterioridad en esta memoria, fue la incompatibilidad del sonar de Arduino que incluía el pack que nos prestó el profesor de la asignatura de Diseño de Sistemas Empotrados.
En un principio se contaba con él como componente estrella para dificultar la realización de este proyecto, pero hasta que no recibimos todos los componentes, y se realizó el ensamblado de los mismos, no se pudo verificar su incompatibilidad.
Como se comentaba con anterioridad, la idea inicial era aportar código original a este proyecto, haciendo utilidad de un sonar para detectar el cambio de alturas que puedan propiciar montículos, u obstáculos en el aterrizaje, proporcionado en la asignatura de Diseño de Sistemas Empotrados. Pero este proyecto no muere aquí, se realizará un pedido de sonares analógicos, y no solo se instalarán en la zona inferior del dron, para facilitar su aterrizaje, e irlo acomodando al gusto del piloto a través del software, sino que también se implementarán sonares analógicos para la detección de objetos, tanto frontal, como lateral, como posterior, con el objetivo de crear un UAV que sea complicado chocarle
- El problema determinante para que el UAV no acabara volando fue la lipo. Se desconoce el momento preciso en el cuál la batería llegó al fin de su vida. Hay varias hipótesis:
- Que llegara ya estropeada desde China.
- Que durante la configuración del UAV esta bajara su voltaje por debajo del límite y alguna de las celdas sufriera un punto de no retorno.
- Una de las hipótesis más factibles, es que debido a la compra de un cargador de lipos, muy económico, este dañara la batería al no hacer una carga debidamente balanceada, como necesitan este tipo de lipos.
