conguración del hardware y - archivo digital upmoa.upm.es/52981/1/tfg_hector_palop_bouza.pdf ·...

UNIVERSIDAD POLITÉCNICA DE MADRID

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA YDISEÑO INDUSTRIAL

Configuración del hardware ysoftware de un monocóptero coaxial

AutorHéctor PALOP BAUZÁ

TutorMiguel HERNANDO

GUTIÉRREZ

CotutorAlberto BRUNETE

GONZÁLEZ

Julio 2018

CONFIGURACIÓN DE UN MONOCÓPTERO COAXIAL

You should take the approach

that you're wrong. Your goal is

to be less wrong.

Elon Musk

Héctor Palop Bauzá I

II Escuela Técnica Superior de Ingeniería y Diseño Industrial (UPM)

Agradecimientos

No podría pasar ésta oportunidad sin agradecer, en primer lugar, a mis padres por sucariño y la libertad que me han dado todos éstos años. Otros los habrá, pero no mejores.

Hay personas de las que sé que me voy a acordar toda mi vida, y mis amigos deBibliofest no son ninguna excepción de ello, aunque acabemos cada uno en un lado distintodel planeta. Obviamente siento un cariño enorme por todos ellos, pero quiero agradecerespecialmente a Andrés, sin quien éste documento no tendría ni remotamente el aspectoque tiene ahora.

Mil y una gracias también para Belén, por animarme armada con innita pacienciatodos los días desde que la conozco.

Otros a los que no me podría faltar agradecer son mi tutor, Miguel Hernando, y todosmis amigos de la A-109, con los que he vivido ésta Odisea desde primero de carrera,muchas gracias a todos.

III

IV Escuela Técnica Superior de Ingeniería y Diseño Industrial (UPM)

Índice general

Agradecimientos III

Resumen IX

Abstract XI

Glosario XIV

1. Introducción 1

1.1. Estado del Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1. Marco histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.2. Terminología apropiada . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.3. Clasicación de los UAVs militares . . . . . . . . . . . . . . . . . . 4

1.1.4. Proyectos de UAV coaxial . . . . . . . . . . . . . . . . . . . . . . . 4

1.1.4.1. MAV (o su apodo, Woodchipper), por Schlauncha . . . . . 4

1.1.4.2. Coaxial Dualcopter, por Taek Sung Oh . . . . . . . . . . . 7

1.1.4.3. Sprite, por Ascent AeroSystems . . . . . . . . . . . . . . . 9

1.2. Objetivos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3. Herramientas y programas utilizados . . . . . . . . . . . . . . . . . . . . . 10

1.4. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2. Modelo Coaxial 15

2.1. Introducción a los UAV recreacionales . . . . . . . . . . . . . . . . . . . . 15

2.2. Singlecopter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3. Coaxcopter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4. Monocóptero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

V

ÍNDICE GENERAL

3. Conguración electrónica 27

3.1. Esquema general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2. Batería . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3. Placa controladora APM 2.8 . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4. Power Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.5. Módulos de telemetría . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.6. Variadores de los motores (ESC ) . . . . . . . . . . . . . . . . . . . . . . . 33

3.7. Motores y servomotores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.8. Emisora y receptor radio-control . . . . . . . . . . . . . . . . . . . . . . . . 36

4. Firmware de Ardupilot 39

4.1. Introducción a Ardupilot . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2. Estructura general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3. Interpretación de las lecturas . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.4. Gestión de las entradas y salidas externas . . . . . . . . . . . . . . . . . . 49

4.5. Orden de ejecución y planicación de tareas . . . . . . . . . . . . . . . . . 50

4.6. Gestión de memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.7. Sistema de estimación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.8. Control de actitud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.9. Comunicación MavLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.10. Código crítico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.11. Implementación del rmware . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.11.1. Descarga del rmware . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.11.2. Método Make . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.11.3. Método Waf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5. Estación de tierra Mission Planner 75

5.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.2. Flight Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.3. Initial Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.4. Cong/Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

VI Escuela Técnica Superior de Ingeniería y Diseño Industrial (UPM)


6. Calibración de los componentes de vuelo 85

6.1. Acelerómetro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.2. Emisora Radio Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.3. Brújula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.4. Variadores ESC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

7. Resolución de problemas 93

7.1. Pre-armado de motores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

7.2. Corrección de la lectura del acelerómetro . . . . . . . . . . . . . . . . . . . 94

7.3. Firmware de los ESCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

7.4. Firmware de la telemetría . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

7.5. Ajuste de los PIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

7.6. Registros de vuelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

7.6.1. Utilidad de los registros de vuelo . . . . . . . . . . . . . . . . . . . 102

7.6.2. Dataash Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

7.6.3. Telemetry Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

8. Resultados y Conclusiones 107

8.1. Pruebas realizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

8.1.1. Entorno de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

8.1.2. Resultados de las pruebas . . . . . . . . . . . . . . . . . . . . . . . 111

8.1.2.1. Ensayo en cadena abierta . . . . . . . . . . . . . . . . . . 111

8.1.2.2. Ensayos con realimentación . . . . . . . . . . . . . . . . . 111

8.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

8.3. Líneas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Bibliografía 121

Anexos 125

Índice de Figuras 159

Índice de Tablas 161

Héctor Palop Bauzá VII

ÍNDICE GENERAL

VIII Escuela Técnica Superior de Ingeniería y Diseño Industrial (UPM)

Resumen

El presente Trabajo de Fin de Grado tiene como objetivo fundamental la incorporacióny conguración de tanto los componentes electrónicos como del software existente en unmonocóptero coaxial radio-control.

El diseño mecánico de éste vehículo dispone por un lado un sistema de dos rotoressuperpuestos que le proporcionan la sustentación vertical a la vez que sirve para contra-rrestar el momento generado por una de las hélices con la otra hélice, y viceversa. Por otrolado, el movimiento en el plano horizontal se controla a través de la acción de dos servo-motores que desplazan el centro de gravedad del vehículo dotándole de estos dos gradosde libertad. Estas características dotan al vehículo de un movimiento omnidireccional yestabilidad natural en la guiñada que no poseen la mayoría de otros vehículos aéreos deala rotatoria más convencionales.

El trabajo recoge la selección e incorporación de los componentes electrónicos que po-sibilitan el vuelo del aparato con vistas a la implementación del rmware facilitado deArduCopter. Dicho rmware ha sido desarrollado por el equipo de programadores pro-fesionales y acionados de Ardupilot, resultando en un software enormemente eciente ypolivalente que se ha incorporado y congurado en éste proyecto adaptado a la morfologíadel monocóptero coaxial, lo cual posibilita también la comunicación y monitorización delvehículo en vuelo desde una estación de tierra.

Junto con éstos objetivos, éste trabajo también engloba la resolución de un conjunto deproblemas de hardware y de software que se han encontrado en varios de los componentesque se han empleado en el proyecto.

IX

ÍNDICE GENERAL

X Escuela Técnica Superior de Ingeniería y Diseño Industrial (UPM)

Abstract

This thesis aspires to bring a hardware and software solution for a helicopter-based`coaxcopter' model. This type of vehicle gains its aerial lift from the use of a pair of coaxialpropellers and moves along the horizontal plane with the displacement of its gravitycenter. The electronics used on board are selected to succesfully support the open-sourceArducopter rmware. The use of this implementation carries on a series of problems andmisconducts in the hardware and software of the UAS that are also adressed in thisproject.

XI

ÍNDICE GENERAL

XII Escuela Técnica Superior de Ingeniería y Diseño Industrial (UPM)

Glosario

AHRS Attitude and Heading Reference System

API Application Programming Interface

CAN Controller Area Network

DIY Do It Yourself

EEPROM Electrically Erasable Programmable Read-Only Memory

EFK Extended Kalman Filter

ESC Electronic Speed Controller

FET Field Eect Transistor

FIFO First-in First-out

GDOP Dilution Of Precision

GND Ground (Toma de tierra)

GPS Global Positioning System

HAL Hardware Abstraction Layer

HUD Head-Up Display

I2C Inter-Integrated Circuit

IDE Integrated Development Environment

IMU Inertial Mesurement Unit

MISO Master Input Slave Output

MOSI Master Output Slave Input

LED Light-Emitting Diode

LiPo Lithium Polymer

OSD On Screen Display

ORB Object Request Broker

PID Proportional-Integral-Derivative controller

XIII

ÍNDICE GENERAL

POSIX Portable Operating System Interface for Unix

PWM Pulse Width Modulation

RX Receiver

SCL, SCLK Serial Clock

SDA Serial Data

SPI Serial Peripherial Interface

TX Transmitter

UART Universal Asynchronous Receiver-Transmitter

UAV Unmanned Aerial Vehicle

UAS Unmanned Aircraft System

USB Universal Serial Bus

XIV Escuela Técnica Superior de Ingeniería y Diseño Industrial (UPM)

Capítulo 1

Introducción

1.1. Estado del Arte

A lo largo de ésta primera sección haremos un repaso del estado actual de la ramade la robótica referente a los UAVs (vehículos aéreos no tripulados), empezando por elaspecto histórico de los mismos, y abordando seguidamente los modelos más relevantessimilares al modelo de monocóptero coaxial que en el que hemos basado éste proyecto.

1.1.1. Marco histórico

Si bien en la actualidad, se tiene razonablemente consolidado el concepto de vehículoaéreo no tripulado (UAV ), es necesario entender que nace de una rama tecnológica muyespecíca que no ha encontrado su lugar en la industria (tanto por la falta de mediospara desarrollarla como porque no se buscaba la utilidad que proporciona) hasta haceunos pocos años, lo que impide determinar de forma rigurosa el marco histórico de losUAVs. Así pues, si queremos referirnos al primer UAV creado por el ser humano, ¾haremosmención a los globos aerostáticos no tripulados que bombardearon Venecia en 1849[1]? ¾Opodemos considerar como un diseño válido anterior los Aerial Targets, ingeniados comoaviones kamikazes no tripulados poco antes de los años 20[2]? Y si admitimos éste segundoejemplo, ¾por qué dejamos fuera todos los diseños anteriores de misiles que claramentetambién vuelan sin tripulación? Y si los misiles también son válidos, entonces podríamosdescender en el tiempo encadenando ejemplos, validando cualquier tipo de proyectil hastala prehistoria. Se podría debatir que la diferencia entre un UAV y un misil guiado es queuno es capaz de volver a su destino después de cumplir su misión mientras que el otrono, pero de la misma forma hay un sinfín de ejemplos que nos hacen caer en la mismaindeterminación, ya que junto a la condición de vehículo no tripulado hay también unamultitud de características según las cuales podemos categorizar uno u otro ejemplo comoel primer UAV que tenía X cualidad. Estas características propias pueden ser la posesiónde un sistema de control de actitud (lo cual es fundamental en los UAVs modernos), o siutiliza tecnología electrónica, o si posee una fuente propia de energía, o si emplea motoressean eléctricos o de combustión interna, o los grados libertad con los que se desplaza.Dónde ponemos el límite de lo que fue UAV y lo que no es algo que no está impuesto porel propio concepto de UAV.

1

CAPÍTULO 1. INTRODUCCIÓN

Lo que sí podemos hacer de forma rigurosa es citar algunos de los ejemplos históri-cos que sí que han marcado la evolución de ésta tecnología, sin los cuales el conceptode UAV no tendría el valor que posee actualmente. Según algunas fuentes[3], el primerartilugio mecánico documentado que se puede entender como UAV toma el diseño de unave mecánica (Figura 1.1) que se le atribuye a Archytas de Tarantas. Este invento fuesupuestamente desarrollado en el año 425 BC, pero no se tienen constancias de que losdiseños se llevasen a la práctica y que un modelo físico fuese capaz de tomar el vuelo deforma controlada. Sólo sería en el siglo XV cuando Leonardo da Vinci elaboró el primerdiseño de artilugio volador helicoidal (Figura 1.2) que se puede recrear de forma funcionalen la actualidad. Su mecanismo sólo dota al vehículo de un grado de libertad vertical,pero se le considera el primer antecesor espiritual del helicóptero.

Figura 1.1: Ave mecánica.[4] Figura 1.2: Mecanismo helicoidal.[4]

Ya entrados en el siglo XX podemos empezar a hacer referencia a unos ejemplos quecomparten mucho más con el UAV moderno, ya que encuentran una utilidad muy deseableen el sector militar, el cual vivió un boom tecnológico durante la Primera y Segunda GuerraMundial, impulsando el primer diseño del llamado Kettering Bug (Figura 1.3), que es unmodelo basado en un aeroplano desarrollado por el ejército de los EEUU en 1918, y quese utilizó como lanza-misiles móvil (y ciego) durante toda la Primera Guerra Mundial.El salto tecnológico en éste sector a lo largo de los últimos 100 años se debe tanto ala necesidad de innovación provocada por las guerras que han marcado el siglo comoa la aparición de muchas tecnologías modernas ocurrida sobre todo durante la segundamitad del siglo, como la electrónica, los materiales compuestos y el desarrollo de nuevastecnologías de comunicación entre dispositivos.

Figura 1.3: Kettering Bug.[4] Figura 1.4: MQ-8 Fire Scout.[5]

La invención del helicóptero en el año 1936 supone el último gran paso en el trasfondohistórico de nuestro proyecto ya que en él se fundamenta la mecánica detrás del modelocoaxial que hemos utilizado en éste trabajo. Desde entonces tanto los modelos físicos comosu implementación autónoma como UAVs han evolucionado en los sosticados vehículosque se utilizan hoy en día en el ámbito militar, y cuyo ejemplo más representativo actual-mente son los modelos Fire Scout (Figura 1.4).

2 Escuela Técnica Superior de Ingeniería y Diseño Industrial (UPM)


1.1.2. Terminología apropiada

Hoy en día se utiliza una gran cantidad de terminología para hacer referencia a losvehículos aéreos no tripulados, lo cual puede llevar en muchas ocasiones a confusión. Enlos siguientes epígrafes ofreceremos algo de claridad a todo esto para entender lo que seoculta detrás de las diferentes nomenclaturas de ésta tecnología.

El término más común utilizado por los medios para describir una aeronave no tripu-lada es dron. Desafortunadamente, el término dron acarrea un estigma heredado de sucontrovertida aplicación militar en el campo de batalla. Un término más preferible y cien-tícamente descriptivo empleado más por los proponentes de la industria es el acrónimoUAV que se corresponde a Unmanned Aerial Vehicle. Los términos dron y UAV se consi-deran semánticamente iguales, a pesar de que la opinión popular suele interpretar que losUAVs son aeronaves pilotadas remotamente por un piloto mientras que los drones tienenuna ruta pre-programada. A falta de referencias ociales, éste punto de diferenciaciónsigue quedando sujeto a debate.

Debido a la evolución de ésta tecnología con el paso del tiempo, ha nacido la necesidadde utilizar más términos para referirse al conjunto de elementos que interactúan para queel vehículo no tripulado vuele, a parte del propio vehículo. De esto sale que otro de lostérminos que se suele emplear para referirse a éstos robots móviles es UAS (UnmannedAerial Systems), en los cuales la distinción sí que queda clara frente a los drones o UAV, yaque la denición de UAS encapsula tanto el propio vehículo no triulado como la estacióncontroladora en tierra, como el sistema de comunicación que los conecta.

El cualquier caso, la OACI (Organización Internacional de Aviación Civil) ha propues-to una denición formal para tratar de poner n al debate anteriormente citado[6].

• Se llama UAV (Unmanned Aerial Vehicle) a cualquier tipo de vehículo aéreo notripulada, independiemenente del sistema de control.

• Se llama RPA (Remotely Piloted Aircraft) a las aeronaves no tripuladas que secontrolan por control remoto.

Aclarada ésta distinción, es importante notar que no hay ningún término ocial parareferirse a los vehículos que sólo operan de forma autónoma sin tener detrás un controlremoto. Además, la Real Academia Española no recoge ninguna acepción para lo quepopularmente se reere como un dron, a pesar de toda su exposición en todo tipo de mediode comunicación público en España. La palabra correcta para referirnos a los vehículosaéreos no tripulados es por lo tanto el anglicismo UAV.

Por otro lado, el término coaxcóptero tampoco tiene reconocimiento ocial pero tal ycomo veremos más adelante en el trabajo, lo usaremos para referirnos a todo UAV quecuente únicamente con dos rotores coaxiales, independientemente de su mecanismo dedesplazamiento en el plano XY.

Héctor Palop Bauzá 3


1.1.3. Clasicación de los UAVs militares

A pesar de todos los esfuerzos que se han hecho por recopilar todos los distintos tiposde vehículos aéreos, a día de hoy no existe un reconocimiento universal de los diferentestipos de morfologías. Pueden encontrarse referencias propias de cada país para expresarlos distintos tipos de UAVs de uso militar ya que cada uno es el responsable de la creaciónde sus propios modelos y utiliza su propio sistema de referencia. Aclarado esto, podemosllegar a decir que la clasicación que más se acerca a ésta referencia universal es la queofrece la OTAN y que se visualiza en las siguientes imágenes[7]. Es importante recordarque éstas tablas se han creado únicamente en vista de las aplicaciones militares de losUAVs. Las morfologías referentes a los modelos recreacionales se pueden encontrar másadelante en éste trabajo.

Figura 1.5: Clasicación reducida de UAVssegún la OTAN.[7]



Figura 1.6: Clasicación extendida de UAVssegún la OTAN.[7]



1.1.4. Proyectos de UAV coaxial

A continuación pasaremos a analizar algunos de los ejemplos que realmente muestranel estado del arte actual en cuanto al modelo de UAV elegido para el proyecto. Lascaracterísticas físicas del modelo facilitan el uso de vehículos aéreos coaxiales en interiores(por ejemplo pueden pasar a través del arco de una puerta) pero no por ello se limitan aello. Donde se aprovecha realmente el potencial de los UAVs es en los exteriores ya quetal y como veremos en otra sección, el uso de la posición GPS puede ayudar a corregir laestimación de otras variables que juegan un papel en el control autónomo del vehículo.

1.1.4.1. MAV (o su apodo, Woodchipper), por Schlauncha

Este primer modelo representa una buena referencia de los modelos coaxiales desarro-llados con pocos recursos ya que sus características se corresponden a lo que hoy en día seentiende cuando se habla de un coaxcóptero. Se trata de un diseño completamente casero,fabricado con madera y materiales reciclados, ganándose el apodo de Flying Woodchipper(Astilla Voladora), lo cual no ha evitado que se convierta en una referencia a seguir delos coaxcópteros DIY en el año 2013.

Figura 1.7: Coaxcóptero MAV.[8] Figura 1.8: Coaxcóptero invertido.

El coaxcóptero de Shlauncha posee una estructura invertida(Figura 1.8), poniendotodos los elementos pesados en la parte superior del vehículo, y las hélices coaxialesorientadas hacia abajo. Este tipo de diseño resulta conveniente porque ayuda mucho ala estabilidad natural del vehículo. El movimiento en el plano XY se controla con el usode alerones, lo cual resulta un sistema mucho más popular que el desplazamiento de losejes del cuerpo del vehículo en los diseños de coaxcópteros. El rmware utilizado en elvehículo es precisamente el código desarrollado por Ardupilot. Desafortunadamente, elmodelo quedó destruido en un accidente aéreo con un aeroplano radio control en el mismoaño de su construcción, honrando a su apodo Woodchipper.



1.1.4.2. Coaxial Dualcopter, por Taek Sung Oh

A pesar de que su nombre puede evocar otro concepto distinto, éste coaxcóptero chinoconstruido en 2016 utiliza un sistema de hélices coaxiales y de movimiento de ejes muysimilar al que emplea nuestro proyecto de monocóptero. La diferencia radica en que mani-pula únicamente la orientación de los rotores sin inclinar también parte del cuerpo (dondese encuentra el centro de gravedad) del coaxcóptero.

Figura 1.9: Coaxial Dualcopter volando.[9] Figura 1.10: Aspecto interior.[9]

Está elaborado desde cero empleando un hardware y un software completamente pro-pios sobre un Arduino UNO. El rmware utilizado está programado de forma indepen-diente en el entorno de Arduino y no tiene ninguna relación con Ardupilot o con MissionPlanner.Tanto el código utilizado como el circuito esquemático empleado son púbicos yestán disponibles en el blog del creador del proyecto.

Figura 1.11: Circuito esquemático del Coaxial Dualcopter [9]



1.1.4.3. Sprite, por Ascent AeroSystems

Sprite es un coaxcóptero modular nanciado a través de Kickstarter, y resulta unejemplo muy relevante ya que consiste en el primer coaxcóptero comercial, introduido en2015. Es un modelo portátil y modular con el chasis impreso en 3D y que anuncia serresistente al agua.

Emplea una hélice principal replegable que consigue el movimiento ascendente mientrasque la segunda es una pala también replegable que actúa como contrapeso para generar unmomento contrario al que provoca la primera pero no contribuye al movimiento ascendentede la misma forma que la que lo hace la primera. Su rmware se basa en el proporcionadopor Ardupilot de forma similar a nuestro proyecto, lo que lo hace compartible con lasestaciones de tierra más comunes para congurar su comportamiento, analizar su estadoy establecer rutas de vuelo.

Figura 1.12: Sprite.[10]

El movimiento en los ejes de pitch y roll lo consigue mediante la inclinación de los ejesde los rotores, de forma similar al sistema empleado por nuestro proyecto. Además tambiénposee el centro de gravedad muy por debajo de la posición de las hélices y consigue unvuelo aparentemente muy estable con un diseño muy robusto. La principal aplicación parala que se ha diseñado es la videocaptura de imagen para actividades de montaña.

Actualmente la compañía Ascent Aerosystems ya cuenta con un segundo modelo lla-mado Sprite2 con mejores prestaciones, diseñado con un chasis de policarbonato. Estesegundo diseño pesa un total de 420 g con un tiempo de vuelo de aproximadamente 22minutos, y su estructura modular permite colocarle una extensión con dos grados de li-bertad para dotarle de una cámara GoPro montada que le permite hacer seguimientos depersonas y objetos



1.2. Objetivos del proyecto

El objetivo principal del proyecto consiste en la incorporación y conguración de tan-to los componentes electrónicos como del software existente en un monocóptero coaxialautónomo para lograr que el vehículo se comporte de forma autónoma y sea capaz decomunicarse con una estación de tierra. Ésta meta se ha abordado primero con la se-lección de los componentes electrónicos adecuados, y segundo con la implementación yconguración del rmware facilitado por Ardupilot.

Mientras que la morfología del vehículo es un caso muy concreto y único, la infraes-tructura de hardware y de software que hay detrás se ha diseñado con la intención de serlo más polivalente posible. Este documento busca facilitar precisamente la comprehensiónde esta infraestructura, junto con la resolución de los problemas que aparecen a raíz de lamisma y haciendo un claro hincapié en su aplicación en el monocóptero coaxial utilizadoen este trabajo.

Con todo ésto en mente se ha desarrollado la siguiente Estructura de Descomposicióndel Proyecto:

Figura 1.13: Estructura de Descomposición del Proyecto.



1.3. Herramientas y programas utilizados

Durante la elaboración de éste trabajo se han empleado un conjunto de herramientasque han servido para dar forma a éste proyecto, siendo la mayor parte de éstas herra-mientas software.

El principal software empleado en éste proyecto consiste en rmware open source desa-rrollado por Ardupilot, concretamente el programa Arducopter, el cual ha asentado la basedel software en la realización de éste proyecto. Este rmware ha sido desarrollado de for-ma iterativa y coordinada desde el año 2009, y constituye en software open source másempleado actualmente para aplicaciones de vuelo debido a su alta compatibilidad con elhardware, su polivalencia para distintos tipos de vehículos, su gran eciencia computacio-nal, y su facilidad de conguración.

Junto con el rmware de Ardupilot, también se ha empleado el otro extremo en todosistema de aeronaves no tripuladas (UAS ), que es el software de la estación de tierra. Laestación de tierra empleada es Mission Planner, la cual ha sido también desarrollada porArdupilot lo que facilita enormemente la compatibilidad con el rmware y ofrece un granabanico de opciones de conguración para el mismo.

A pesar de que el rmware es de origen externo, la IDE de Arduino es la que se hautilizado realizar la implantación del rmware, junto con las herramientas software `Waf 'y Make' para conseguir la build del programa. El software de control de versiones queutiliza Ardupilot para gestionar el rmware es git, teniendo almacenado el código fuenteen su repositorio de GitHub.

Además del entorno de Arduino, también se han utilizado momentáneamente otrasIDE s con la intención de compilar el rmware, concretamente la IDE PlatformIO, quees un entorno propio del editor de código fuente Atom. Sin embargo éste entorno fuedescartado en fases siguientes del proyecto debido a la complejidad de compilación delcódigo.

Para la construcción del chásis y el sistema mecánico que alberga el hardware y softwareutilizados en éste proyecto, se ha empleado una tecnología de impresión 3D con dosimpresoras: la Makerbot Replicator 2X y la Witbox Printer.

De forma general, se ha utilizado parte del equipamiento proporcionado por el De-partamento de Electrónica, Automática e Informática Industrial de la Escuela TécnicaSuperior de Ingeniería y Diseño Industrial, principalmente la jaula en la que se mantieneaislado el monocóptero por razones de seguridad, además de ordenadores, un cargadorpara baterías LiPo y herramientas varias como alicates de pinza y de corte, cables, yconectores.

De forma más transversal, se ha empleado una placa Arduino UNO junto con herra-mientas de soldadura para realizar el asheado de los variadores (ESCs). Para ésta mismafunción se han empleado los programas AVR Burn Tool BL Heli Tool que permitían cargarun rmware a los ESCs desde el Arduino UNO.

El resto de los materiales utilizados como la batería, los modulos de telemetría, o losmotores forman parte del mismo monocóptero y se pueden encontrar más adelante en lasección correspondiente.



1.4. Estructura del documento

A continuación se presenta un desglose que describe los contenidos de los diferentesapartados que se pueden encontrar en éste documento con el objetivo de facilitar la lecturadel mismo:

• CAPÍTULO 1. En éste primer capítulo se pretende introducir al lector al temaprincipal del proyecto. En él se describe la situación histórica y actual de los vehículosaéreos no tripulados, seguido de una enumeración de los objetivos y los materialesutilizados en el proyecto.

• CAPÍTULO 2. Aquí se explican las características físicas propias del monocópterocoaxial dentro de los vehículos aéreos no tripulados, comparándolo en especial consus dos principales competidores coaxiales: el coaxcóptero y el singlecopter.

• CAPÍTULO 3. En éste capítulo se listan y se describen los diferentes componenteselectrónicos que se han elegido para el proyecto, y se representa la forma de conexiónentre ellos.

• CAPÍTULO 4. A lo largo de todo éste capítulo se desarrolla una explicacióndel contenido del rmware empleado seguido de una descripción del proceso deimplementación del mismo rmware.

• CAPÍTULO 5. De forma análoga al capítulo anterior, aquí se detalla una expli-cación más breve acerca de las funcionalidades más importantes de la estación detierra Mission Planner.

• CAPÍTULO 6. En éste capítulo se elabora una descripción de los diferentes pro-cesos de calibración de los componentes electrónicos empleados en el proyecto.

• CAPÍTULO 7. Aquí se listan los diferentes problemas de hardware y software quese han ido encontrando durante la realización del proyecto. En general, se han estruc-turado enunciando un problema y una hipótesis propuesta seguidos de la soluciónque los ha solventado.

• CAPÍTULO 8. En éste último capítulo se realiza un análisis de los resultadosobtenidos durante los ensayos realizados, y se presentan las conclusiones alcanzadas.


Capítulo 2

Modelo Coaxial

2.1. Introducción a los UAV recreacionales

Existe una multitud de modelos físicos que se asemejan al que hemos utilizado en éstetrabajo, y debido a la falta de tradición histórica en la historia de los UAV s, no existeun archivo ocial donde aparezcan recogidas las diferentes morfologías posibles de éstetipo de pseudo-helicópteros. Incluso dentro de los modelos que se recogen bajo un mismonombre pueden presentar diferencias constructivas muy grandes como el posicionamientode las hélices respecto al resto del sistema. Los nombres que se les da a éstos modelossuelen hacer referencia al nombre y al número de los componentes que utiliza (por ejemplo,utilizar una o dos hélices) más que la forma de la propia estructura.

Figura 2.1: Tipos de UAV recreacionales.

A pesar de ésta falta de regularización en el área de los vehículos aéreos no tripulados,sí que se suele hacer una distinción entre dos grandes categorías de aerodinos: los de alaja y los de ala rotatoria[11].

13

CAPÍTULO 2. MODELO COAXIAL

Los aerodinos de ala ja hacen referencia a los vehículos con forma de aeroplano,estando dotado de alas con un perl aerodinámico capaz de generar una diferencia depresiones entre su cara superior llamada extradós, y su cara inferior llamada intradós,que le permiten desplazarse por el aire gracias a una fuerza ascendente de sustentación.

Figura 2.2: Morfologías de UAV de ala rotatoria.[12]

La imagen de la gura 2.2 hace referencia a los tipos de UAV s de ala rotatoria másfrecuentes que se pueden encontrar en aplicaciones de aeromodelismo. En aplicacionesde transporte de personas y mercancía, la aeronave más común es sin lugar a duda elhelicóptero, seguido por sus derivados: el autogiro, el girodino y el convertiplano. Sinembargo, éste proyecto se centra en aplicaciones de aeromodelismo recreacional y vamosa limitar la clasicación a los modelos que aparecen en la imagen.

Como se puede apreciar, existe una variedad de conguraciones posibles de rotores, y sesuele hacer referencia a los distintos modelos según el número de hélices. Los dos modelosde UAV de ala rotatoria más comunes que se pueden encontrar en aeromodelismo sonel cuadracóptero y el helicóptero, mientras que los correspondientes al modelo coaxial seencuentran en una clara minoría. Dentro de éstos modelos coaxiales tampoco podemosencontrar ninguna referencia ocial, pero tampoco resulta coherente hacerla ya que todoslos modelos que entran dentro de la categoría coaxial pueden presentar un gran númerode diferencias constructivas sin llegar a salirse de éste modelo.

Sin embargo, sí que podemos destacar dos modelos que, aunque no están sujetos aunas características estrictas, sí que reúnen ciertas particularidades que caben dentro delconsenso general de la comunidad de Internet, que son el singlecopter y el coaxcopter.Éste reconocimiento les ha llevado a gurar en entre los distintos frames que soporta elcódigo de Ardupilot, lo que realimenta la popularidad de éstos modelos y los convierte enel objeto directo de nuestro estudio.



Estos modelos presentan unas ventajas comparativas respecto a su competencia prin-cipal, el cuadracóptero, como la reducción del tamaño de fuselaje, ya que se elimina lanecesidad de aumentar la supercie para distribuir la mayor cantidad posible de motores.De esta forma llegan a ocupar aproximadamente un 60% del tamaño que ocuparía uncuadracóptero de peso similar. Estas ventajas también se transeren al sucesor espiritualde éstos modelos, el helicóptero, ya que habitualmente la cola de éstos resulta aparatosay resta maniobrabilidad al vehículo. Además los modelos coaxiales resultan más ecien-tes que los helicópteros tradicionales ya que dedican la potencia de sus dos rotores a lasustentación aérea en lugar y no pierde energía en tener que alimentar a un rotor antipar.

La morfología del monocóptero que hemos desarrollado se encuentra en un punto in-termedio entre éstos modelos singlecopter y coaxcopter. A diferencia de nuestro modelo demonocóptero, estas dos morfologías utilizan el uso de alerones para modicar su direcciónen el aire, pero su estudio resulta conveniente pues son el punto de referencia del quepartiremos para adaptarlo a nuestro modelo en el aspecto del software. Tanto los single-copter como los coaxcopter se desplazan verticalmente gracias al uso de su(s) hélice(s),lo que genera el movimiento de throttle. Por otro lado, los movimientos de roll, pitch yyaw los realizan modicando el ángulo de unos alerones que inciden sobre el ujo de airedescendiente creado por las hélices[13].

Otra de las desventajas que presentan los helicópteros convencionales frente a losmodelos coaxiales (o multirrotor) consiste en la asimetría que poseen en el rotor principalpara lograr la sustentación aérea. El ujo de aire presente a través del disco del rotores regular durante el vuelo estacionario pero al avanzar, las aspas que se encuentran ensentido de avance se mueven a mayor velocidad respecto al aire ya que a la velocidad degiro de la aspa se le suma también la componente de traslación del helicóptero. De formaanáloga, se puede entender que las aspas que se mueven en sentido contrario al avanceestán desplazándose a una menor velocidad respecto al sistema de referencia externo. Estefenómeno es lo que se conoce como dimetría de sustentación provocada por el rotor. Éstefenómeno aparece en los modelos coaxiales ya que las hélices invertidas compensan éstasdiferencias de velocidades una a una, anulando así éste efecto[14].

En general, los coaxcopter se consideran más estables que los singlecopter, ya que po-seen un control intrínseco del movimiento de guiñada, tal como veremos más adelante.Además, el coaxcopter sólo depende de dos grados de libertad para controlar su movi-miento en el plano XY, mientras que el singlecopter necesita 4 debido a su necesidad decompensar el movimiento yaw. Con todo, no hay que olvidar que éstos últimos puedenacabar siendo completamente estables si cuentan con el sistema de control adecuado.

Otro de los factores que se tienen que considerar durante la concepción del modelo esdónde se sitúa el centro de gravedad (principalmente dictado por la posición de la batería)respecto de las hélices. Generalmente, un centro de gravedad situado por encima de lashélices proporcionará una mejor estabilidad al sistema. Aunque en el diseño de nuestromonocóptero, éste aspecto no se tuvo en cuenta, ésta pérdida de estabilidad natural podríacompensarse con un buen sistema de control.

A continuación pasaremos a explicar el funcionamiento de los modelos singlecopter ycoaxcopter debido a que presentan fuertes similitudes y tienen más reconocimiento que elmodelo del monocóptero que utilizamos en éste proyecto.



2.2. Singlecopter

La característica principal de los singlecopter radica en que poseen un único motor decorriente continua que hace girar una sola hélice. De acuerdo a la tercera ley de Newton,ésto provoca un momento angular constante en el vehículo que tiene que ser contrarres-tado. Mientras que un helicóptero tradicional compensa éste movimiento rotatorio conla ayuda de una hélice de cola, el modelo del singlecopter emplea para esto un juego dealerones controlados con 4 grados de libertad que se encargan de redirigir el ujo de aireque genera su única hélice, compensando el inevitable movimiento intrínseco de guiñadadel vehículo.

Figura 2.3: Dibujo de un singlecopter.

Tal y como se puede visualizar en la Figura 2.3 , los singlecopter cuentan con 4 aletaslaterales estáticas que resultan fundamentales en el modelo ya que proporcionan unaresistencia contra el movimiento de guiñada natural del vehículo. A pesar de esto, unaresistencia al movimiento de por sí no puede contrarrestarlo por completo para evitarque el vehículo pivote constantemente. La corrección de éste movimiento natural la da ladisposición de los alerones inferiores controlados por servomotores, junto a los movimientosde cabeceo y alabeo (roll y pitch).

Por lo tanto, la velocidad de la hélice será la responsable del ascenso vertical (throttle),mientras que los servomotores que modican los movimientos angulares de los aleronesson los que se accionan para realizar las maniobras de roll, pitch y yaw propias de todovehículo aéreo, además de la corrección de guiñada constante de la que hemos habladoanteriormente. También cabe decir que aunque en la imagen se han representado lashélices en la parte superior, el concepto de singlecopter tal cual se conoce sólo implica laconguración mecánica de alerones y hélice que se ha comentado anteriormente.



2.3. Coaxcopter

El coaxcopter (o coaxcóptero) se distingue en que emplea dos hélices cuyas aletasestán invertidas entre ambas, de forma que giran en sentido contrario generando las dosun mismo ujo de aire (Figura 2.4). El movimiento invertido entre las dos hélices provocaque el momento angular causado por una de las hélices sea cancelado por el de la otrade forma natural. Ya que no necesita compensar el movimiento de guiñada, no poseealetas laterales y sólo necesita dos alerones independientes para desplazarse en el planobidimensional XY.

Figura 2.4: Dibujo de un coaxcóptero.

La ascensión vertical se controla alterando una misma velocidad en las dos hélices. Va-riar la velocidad relativa entre ambas supone dotar al vehículo de un movimiento angularcontrolado lo que supone el movimiento de yaw. Finalmente, las maniobras pitch y roll secontrolan mediante los dos grados de libertad que permiten los servomotores que manejanlos alerones dos a dos. Igual que el singlecopter (Figura 2.3), el centro de gravedad notiene por qué estar situado por debajo de las hélices, por lo que el vehículo representadoen la Figura 2.5 podría cuadrar igualmente en la denición de coaxcóptero.

Figura 2.5: Dibujo de un coaxcóptero con hélice invertida.



2.4. Monocóptero

El modelo de monocóptero que se ha empleado en éste trabajo se puede entender comouna variante de coaxcóptero, ya que reúne las características principales que permitenreconocerlo como tal: posee el sistema de hélices superpuestas al tiempo que controla sumovimiento en el plano XY mediante la acción de dos servomotores.

Figura 2.6: Monocóptero (alzado). Figura 2.7: Monocóptero (perl).

De la misma manera en el coaxcóptero visto anteriormente (Figura 2.4), las hélicesdel monocóptero tienen las aletas invertidas y giran en sentido contrario, con lo queconsiguen generar momentos angulares invertidos que se cancelan entre ellos, al tiempoque provocan un mismo ujo de aire descendente. Este mecanismo resulta muy ventajosorespecto a los singlecopter y los helicópteros tradicionales, ya que elimina la necesidad deañadir grados de libertad adicionales para lograr un movimiento vertical limpio, con uncoste de entre el 10% y el 20% de eciencia respecto al uso con una sola hélice, lo cualsupone un precio considerablemente bajo teniendo en cuenta no sólo supone un aumentoen la complejidad del control de actitud al añadir más grados de libertad al sistema, sinoque también estamos añadiendo motores adicionales, con un peso adicional que afectaráal rendimiento total de la capacidad de vuelo del monocóptero. El peso del vehículo es unfactor que no conviene despreciar a la ligera ya que ha supuesto la razón de numerososintentos de rediseño durante la fase de la concepción mecánica del vehículo. Por la mismarazón se ha decidido cambiar la batería por una con casi la mitad de la capacidad de laanterior, tal como explicaremos más adelante, lo cual consolida la idea de tener en cuentacómo puede afectar cualquier cambio estructural que hagamos al peso del vehículo.

La fundamental diferencia con el coaxcópterpo y con la mayoría de modelos de pseudo-helicópteros que circulan por internet, es el sistema de desplazamiento del centro de gra-vedad para modicar su trayectoria en el aire. El método más convencional para lograrésto consiste en el movimiento de alerones para redireccionar el ujo de aire emitido porlas hélices. Además la gran mayoría de coaxcópteros que sí que modican su centro degravedad lo hacen manipulando la orientación de sus ejes respecto al resto del cuerpo,mientras que nuestro monocóptero también reorienta parte de su propio cuerpo respectoal resto del mismo.



Este desplazamiento del centro de gravedad supone una la aparición de un ángulo deinclinación producido entre el sistema de referencia de las hélices y lo que llamaremos elcuerpo del monocóptero, que se compone del compartimento que contiene la electrónicadel vehículo y más notablemente la batería, que supone el elemento más denso del vehículo.

Figura 2.8: Movimiento de roll del monocóptero

Figura 2.9: Movimiento de pitch del monocóptero

Debido a que como se ha mencionado, la mayor parte del peso se concentra en elcuerpo del monocóptero, el centro de gravedad del mismo se sitúa relativamente bajo enel diseño. Esto provoca que lo que realmente se está inclinando con los movimientos depitch y yaw no sea tanto el cuerpo del monocóptero como las hélices del mismo respectoa la supercie terrestre. Al modicar la orientación de las hélices se consigue redirigirel ujo de aire lo que permite que el monocóptero se desplace lateralmente, efectuandoasí las maniobras de pitch (Figura 2.9) y roll (Figura 2.8) accionando sus respectivosservomotores.

Matemáticamente, se puede analizar la potencia proporcionada por los rotores que sederiva de la siguiente expresión (Ecuación 2.1), donde la Q representa el momento torsordel rotor y Ω es la velocidad angular del rotor[15].

P = ΩQ (2.1) P = PU + PL (2.2)

La potencia total suministrada por el rotor se descompone en la que proporciona elrotor superior (PU) y el rotor inferior (PL). Idealmente la potencia proporcionada porambos es la misma. Sin embargo, sólo podemos asumir con rigor que la potencia total seobtiene con la suma de la correspondiente a cada rotor (Ecuación 2.2).



Esta potencia luego se debe reducir en base a la presión estandarizada a nivel del mary a la velocidad angular nominal (Ecuación 2.3), donde se utiliza la densidad de corrección(ρ/ρ0) y la corrección de la velocidad angular (Ω/Ωdeseado) en rotaciones por minuto.

Pred =P

ρρ0

( ΩΩdeseado

)3 (2.3)

Finalmente, el coeciente de potencia CP se calcula (Ecuación 2.4) empleando la den-sidad del aire ρ, la supercie circular del rotor A, la velocidad angular del rotor Ω y elradio del rotor R.

CP =P

ρAΩ3R3(2.4)

El coeciente de potencia total CP depende tanto del par motor superior como inferior,es decir CP ≡ CQ=f(QU , QL). Esta dependencia funcional es igualmente válida para elcaso de la potencia del rotor P. El par motor sí que alcanza normalmente el equilibrio(QU=QL) durante el vuelo, vericado en condiciones experimentales [15].

Por otro lado, la gura de mérito (FM) es una unidad cuanticable usada para caracte-rizar el rendimiento de un dispositivo o sistema, en relación a su competencia alternativa.Según Leishman y Syal [16] la gura de mérito para sistemas de rotores es dada por laecuación 2.5, donde kappaint es el coeciente de correción por interferencia coaxial.

FM =κintPidealPreal

(2.5)

De forma experimental, se determina que el factor de interferencia mínimo para rotorescoaxiales es kappaint = 1.2657, y de ello se obtiene que la gura de mérito resultante esde 0.61 para el caso de vehículos coaxiales, lo cual los sitúa ligeramente por encima quelos sistemas de ala ja[15].


Capítulo 3

Conguración electrónica

3.1. Esquema general

A continuación se muestra un esquema que representa la relación entre los distintoscomponentes electrónicos que hemos explicado anteriormente, y también se detalla el tipode señal que están transmitiendo. Como ya se ha comentado, la mayoría de los sensoresque juegan un papel en el control de actitud del vehículo son internos a la placa por loque no aparecen en el esquema siguiente. El módulo GPS, sin embargo, sí que se conectade forma externa pero puesto que su función radica en el control de velocidad y posicióna gran escala (lo cual queda fuera de los límites del trabajo), no se ha incluido junto alresto de componentes como se puede ver en la Figura 3.1.

Figura 3.1: Esquema de la electrónica utilizada.

21

CAPÍTULO 3. CONFIGURACIÓN ELECTRÓNICA

En las siguientes secciones de éste capítulo pasaremos a listar y explicar los diferentescomponentes que aparecen en la Figura 3.1, y que componen la conguración electrónicade nuestro proyecto.

3.2. Batería

La batería se emplea como fuente de energía para la etapa de potencia (Power Module)la cual se encargará de distribuir ésta alimentación al resto de componentes electrónicosdel monocóptero. Para ello se ha optado por el uso de baterías de polímero de litio(LiPo) de 11.1V que son las que se utilizan normalmente para éste tipo de aplicaciónen aeromodelismo. La tasa de descarga (35C) se ha elegido de acuerdo a las controladorasde los motores (ESC ) que vamos a emplear.

La primera batería que se utilizó en el desarrollo del trabajo fue una de marca Floureoncon un peso de 423.5 g y una capacidad de 5500 mAh. Después de algunos intentos devuelo se evidenció que los motores no tenían la suciente fuerza como para levantar todoel peso, y dado que la batería es el elemento más denso del monocóptero, se decidió reducirpeso adquiriendo una nueva batería (Zippy) más pequeña y ligera, aunque ello supongauna pérdida de capacidad. A continuación se puede ver una tabla comparativa con lasespecicaciones de las dos baterías.

Tabla 3.1: Tabla comparativa de las baterías Floureon y Zippy.

Marca/Modelo Floureon ZippyTensión 11.1 V 11.1 V

Capacidad 5500 mAh 2200 mAhCélulas 3S 3S

Tasa de descarga 35C 35CConector de carga JST-XH DST

Conector de descarga JST-XH XT60Dimensiones 155×48×25 mm 114×34×24 mm

Peso 423.5 g 181 g

De la comparación que se puede ver en la tabla 3.1, se puede notar que la disminuciónde capacidad y peso es muy proporcional: reduciendo un 60% la capacidad (de 5500 mAha 2200 mAh), conseguimos reducir un 57.2% el peso (de 423.5 g a 181 g). Además de unadisminución en el peso, la nueva batería también tiene un tamaño menor a la en sus 3dimensiones a la anterior, lo cual asegura que la batería quepa en el lugar que ocupaba laanterior.

La constante de descarga que aparece en la Tabla 3.1 resulta suciente para entregar almenos 34 A, que es lo que se corresponde en los requisitos de alimentación de los motores.Dada la capacidad de la segunda batería presente en la Tabla 3.1 y su tasa de descarga,podemos llegar a deducir el tiempo de vuelo máximo de la batería que obtendríamosempleando la batería Zippy a máxima potencia. según muestra la Ecuación 3.1.



Capacidad =tiempo de vuelo

minutos hora· Intensidad nominal

T iempo de vuelo =60 min/h · 2200 mAh

12 min · 21 A= 6 min

(3.1)

3.3. Placa controladora APM 2.8

La controladora de vuelo es el componente principal que dene el comportamientodel vehículo ya que se encarga de gestionar la información de todos los sensores, de laemisora y de la comunicación por telemetría para controlar el movimiento del monocópteroa través de las salidas de los motores. También supone un almacén de memoria dondese almacena el rmware del vehículo, junto con un conjunto de parámetros y registrosaccesibles por el usuario a través de la estación de tierra. Existe una pequeña variedad deplacas controladoras de vuelo que se emplea para éste tipo de aplicaciones, pero la que seha elegido por razones de eciencia y de coste ha sido la placa APM 2.8.

La controladora APM 2.8 se basa en las placas de tipo Arduino (concretamente en elmodelo Arduino UNO) y comparte con ellas la compatibilidad con el software de Arduino,lo cual permite la ejecución del rmware open source de Ardupilot, que es el que vamos autilizar debido a su gran eciencia. Más concretamente, el rmware que vamos a utilizares la versión 3.2.1 puesto que es la versión de Ardupilot más reciente compatible con lasplacas APM. Las especicaciones de hardware de la placa son las que se pueden encontrara continuación.

Figura 3.2: Entradas y salidas de la APM 2.8 [17]



Las características del hardware que posee la APM 2.8 son:

• Procesador ATMEGA2560• Giróscopo de tres ejes• Barómetro• Chip Dataash de 4 MegaBytes• Brújula interna

Las diferentes entradas y salidas de la APM 2.8 son:

• 8 pines digitales de entrada• 8 pines digitales de salida• 9 pines analógicos de entrada• 1 puerto I2C• 1 puerto para la alimentación con etapa de potencia• 1 puerto de telemetría• 1 puerto USB• 1 puerto para la comunicación del GPS• 2 puertos UART (la telemetría utiliza un UART)

A pesar de las características que ofrece la APM 2.8, presenta una serie de inconve-nientes que no se encuentran en su mayor rival en el momento en el que se realizó éstetrabajo: la placa Pixhawk. La principal ventaja de la Pixhawk sobre la APM es la capaci-dad de multithreading gracias a su procesador ARM Cortex M4 32-bit, lo cual le permitecargar las versiones superiores a la 3.2.1 de Ardupilot (que emplean multithreading), locual le abre muchas puertas en cuanto a la conguración del software que la APM tienecerradas. Esto implica que muchas de las funcionalidades modernas y útiles que se hanimplementado en los últimos años en el rmware no están disponibles para los usuariosde la APM. Además, el procesamiento de la Pixhawk es más rápido, sus sensores son másprecisos su almacenamiento de registros se hace en una tarjeta microSD externa, y poseemás puertos en general que la APM. Aclarado esto, cabe decir que la razón por la quese ha optado y se ha seguido con una controladora APM es porque su coste es 4 vecesinferior al de una Pixhawk, lo cual constituye una ventaja muy considerable de la APMsobre una Pixhawk, a pesar de que el uso de ésta última habría solucionado de entradamuchos de los problemas encontrados durante la elaboración de éste trabajo.

3.4. Power Module

La mayoría de controladoras de vuelo utilizan una etapa de potencia (Power Modu-le) que actúa como un conector dedicado que hace de mediador entre los conectores dela batería y el resto de componentes. Esto permite proporcionar un nivel de tensión de5.37 V y un ujo de corriente de 2.25 A estables, lo cual reduce fuertemente el riesgode sobretensiones en la placa. Además, permite al rmware de Ardupilot compensar ade-cuadamente las interferencias magnéticas que afectan a la brújula. La etapa de potenciaacepta una tensión máxima de la batería de 18 V y una corriente máxima de 90 A. Ellayout del conector que va a la placa es el que aparece en la siguiente Figura 3.3.



Figura 3.3: Conector del Power Module 3DR a la APM.

3.5. Módulos de telemetría

Los módulos de telemetría son el hardware que se utiliza para establecer una comuni-cación radio entre la placa controladora (APM) y la estación en tierra. Poseen su propiormware en open source, el cual se ha tenido que modicar como ya veremos próxima-mente. Los módulos que se han adquirido para éste trabajo son de la marca 3DR Radio,cuentan con un rango de aproximadamente un kilómetro y medio, y tienen una frecuenciade transmisión de 915 MHz. La conexión a la placa se efectúa con el conector que vieneincluido con los módulos de telemetría de forma que cable a cable queda como en la Figura3.4

Figura 3.4: Conexión de la telemetría con la placa.



3.6. Variadores de los motores (ESC )

Los variadores ESC (Electronic Speed Controllers) son el componente responsable delcontrol de que los motores giren a la velocidad requerida por Ardupilot, administrando lapotencia con la que se los alimenta de forma independiente al control de las señales. Suaspecto se puede visualizar en la Figura 3.5. Estos componentes interpretan las señales decontrol en forma de PWM (Pulse Width Modulation), empleando un rango de frecuenciasentre los 50 Hz y los 100 Hz, los cuales envía la placa para determinar la velocidad degiro de los rotores.

Otra característica de los variadores es que son capaces de invertir el sentido del motorsi es necesario, que además permite realizar un frenado dinámico, usando al motor comogenerador para disminuir la velocidad del mismo. Son un componente intermediario querecibe la alimentación de la batería (que pasa a través de la etapa de potencia) y las señalesde control que envía la placa controladora, y envía las señales de salida correspondientesa los motores de las hélices.

Figura 3.5: Conexiones de los ESCs.[18]

Los ESC siguen la señal de referencia que reciben de la placa para proporcionar unatasa rápida de conmutación de transistores de tipo FET, para regular el ciclo de trabajoque reciben los motores. Los ESC cuentan con su propio rmware que puede llegar adar problemas (tal como veremos en otro apartado) pero el software es independientedel que envía las órdenes desde la placa. En éste trabajo, los ESC empleados son unosTURNINGY PLUSH 25 A. Mientras que tal y como lo indica su nombre, tienen unaintensidad nominal de 25 A, mientras que su intensidad máxima llega hasta los 35 A.

Respecto a las conexiones, las cuales se entienden fácilmente visualizando la gura3.5, los cables gordos van directos a la salida del Power Module, la cual proporciona laalimentación procedente de la batería, mientras que la señal de control se conecta comoun PWM más al canal correspondiente de los pines de salida digital en la placa APM.



3.7. Motores y servomotores

En toda aplicación de aeromodelismo, los rotores que se suelen encontrar empleanmotores eléctricos de corriente continua sin escobillas (Brushless DC Motors). La ventajade utilizar este tipo de motor radica en su alta relación de potencia frente a su peso, lasaltas velocidades (con bajo par) que pueden alcanzar y la posibilidad de regularlos conun control electrónico, lo cual los hace idóneos para éste tipo de aplicación.

Figura 3.6: Motor sin escobillas.[19] Figura 3.7: Motores utilizados (BL-CR28M).

En éste tipo de motores, la corriente electrica pasa a través de los bobinados (Figu-ra 3.6) que están distribuidos para generar un campo magnético. Éste campo magnéticoprovoca que el imán que se encuentra dentro de los bobinados rote entre los bobinados,ya que es repelido y atraído por los subsecuentes bobinados que se van excitando secuen-cialmente. Para mantener ésta rotación, es necesario revertir constantemente la corriente,de forma que las polaridades de los bobinados se permuten continuamente. [20]

Los motores que hemos utilizado (Figura 3.7) son modelo BL-Brushless CR28M, tie-nen una potencia máxima de 375 W, una intensidad nominal de 21 A, una intensidadmáxima de 34 A y un valor de 1050 kilo-voltios. A estos motores se les colocan una hélicesde 10×4`7 pulgadas. Contando con los valores de carga de las hélices (10×4 - 10×5),podemos identicar el empuje máximo que proporcionan los motores, situándolo en 1320g. La conexión de éstos motores viene en forma de 3 cables con corriente trifásica quese conectan directamente a la salida de los ESC correspondientes. Los variadores son losencargados de convertir la alimentación de acuerdo a la señal de control enviada por laplaca controladora para que los motores se exciten a través de la corriente trifásica paragirar a una determinada velocidad.

Por otro lado, los servomotores empleados son el resultado de un pequeño motor decorriente continua con la posición controlada por un potenciómetro, cuya salida mecánicase adecua con la correspondiente reductora. Los servos se alimentan a 5 V con pines deseñal y tierra desde la propia placa (no directamente desde la batería), y se controlan conuna señal PWM que indica con una modulación de frecuencias la posición a la que sedeben colocar. Los servos utilizados en éste trabajo son:

• Standard HD-3001 HB, con un par máximo de 3,5 kg·cm a 4,8 V.• Analog Servo HD-1501MG, con un par máximo de 3,5 kg·cm a 4,8 V.



3.8. Emisora y receptor radio-control

La emisora de radio es la herramienta de mando que utiliza el usuario para mandarlelas órdenes de vuelo a la placa a través de modulación de ondas de radio que se envíanal receptor, el cual las convierte en señales PWM que se transmiten a la placa en formade señales de entrada. Éstas señales son procesadas por la placa y constituyen las señalesde referencia que tendrá en cuenta el control de actitud del sistema para determinar lassalidas adecuadas.

La emisora utilizada en éste trabajo es una Turningy TGY-i6. Cuenta con 4 canalesprincipales (roll, pitch, yaw, throttle) controlados por los sticks de la emisora y 2 canalessuplementarios que se pueden emplear para una variedad de funciones opcionales (cambiarel modo de vuelo, activar el failsafe, control de la cámara montada, etc). La distribuciónde las salidas que aparecen en los canales mencionados en función de las entradas quese desee es modicable reprogramando el layout de la emisora, para lo cual es posibledisponer de varias distribuciones guardadas al mismo tiempo (aunque claramente sólouna puede estar activa simultáneamente).

Además de la selección de canales a los que afecta cada stick de la emisora, también sepuede invertir la señal que se envía, congurar la linealidad de la respuesta de los sticks, eincluso asociar varios canales a un mismo stick si se desea. A pesar de todas las funcionesque ofrece la programación de la emisora, en el desarrollo de éste trabajo lo correcto esestablecer la conguración estándar de roll, pitch, yaw y throttle tal y como se explicarámás adelante.

Figura 3.8: Emisora utilizada. Figura 3.9: Receptor utilizado.


Capítulo 4

Firmware de Ardupilot

4.1. Introducción a Ardupilot

Ardupilot es el sistema de pilotaje autónomo open source más usado actualmente enun gran rango de aplicaciones de aeromodelismo, incluyendo muchos de los tipos citadosen el segundo capítulo del trabajo. Incluye tanto el desarrollo del software correspondienteal rmware de vehículos como el de las estaciones de tierra más usadas actualmente. Laversatilidad de Ardupilot no sólo se limita a los tipos de modelos de vehículos aéreos, sinotambién al gran número de placas distintas con las que es compatible el rmware. Ademásde su versatilidad, el software ofrecido por Ardupilot ha demostrado ser enormementeable, eciente, completo y abierto, tanto en términos de open source como en la formade organización con la que se ha desarrollado.

Desde su origen en 2009 hasta el día de hoy, ha sido y sigue siendo el software más abley polivalente que se puede encontrar en Internet, lo cual lo convierte en una herramientaidónea para nuestro proyecto. Aunque el rmware apropiado para nuestro modelo devehículo ha quedado estancado en la versión 3.2.1 debido a las limitaciones del hardware dela placa APM, el código de Ardupilot no deja de actualizarse día a día, siendo desarrolladoy mejorado tanto por grupos de voluntarios como por profesionales y socios que se agrupanen la llamada Comunidad de Ardupilot. Las contribuciones al código se realizan a travésde la plataforma de control de versiones Github.

• Plane• Copter• Rover• Antenna Tracker• Mission Planner• APM Planner• APM Planner 2.0• MAVProxy

• APM Planner• DroneKit• MinimumOSD• Tower• QGroundControl• PX4• MAVLink• UAVCAN

Nótese que aunque el proyecto con el que vamos a trabajar es Copter, hay una consi-derable parte del código que es común para todos los proyectos de vehículos, tal y comoveremos en los siguientes epígrafes.

29

CAPÍTULO 4. FIRMWARE DE ARDUPILOT

4.2. Estructura general

El rmware Arducopter que usaremos como base para programar nuestro monocópterotiene disponible su código fuente en su repositorio de git y lo componen más de 700 000líneas de código. Con el n de facilitar su comprensión, a lo largo de éste capítulo se vaa desarrollar un resumen explicativo acerca del funcionamiento de dicho rmware. Esteresumen lo descompondremos en la siguiente serie de bloques lógicos de código que iremosabordando uno a uno y que se encuentran consolidados en la estructura general del código(Figura 4.1).

• Interpretación de las lecturas• Gestión de las entradas y salidas externas• Orden de ejecución y planicación de tareas• Gestión de memoria• Sistema de estimación• Control de actitud• Comunicación MAVLink

Figura 4.1: Estructura general del rmware de Ardupilot.



Esta estructura básica (Figura 4.1) se puede descomponer en 5 partes principales, queno son las que se corresponden a la división lógica del rmware que vamos a realizar,aunque sí que ayuda al entendimiento del funcionamiento global del código.:

1. El código del vehículo. Son los cheros de más alto nivel que denen el compor-tamiento del rmware. Presenta 4 modelos de vehículos: Plane, Copter, APMrover2y AntennaTracker. Nosotros nos centraremos en el modelo Copter, que es en el quebasaremos el rmware del monocóptero. Aún con esto, hay una abundante cantidadde elementos en común entre los diferentes tipos de vehículos.

2. Las librerías compartidas. Se comparten entre los distintos modelos menciona-dos anteriormente. Entre ellas, se incluyen los drivers de los sensores, la estimaciónde altura y posición (con un ltro extendido de Kalman) y el código de control deactitud (PIDs).

3. La capa de abstracción de hardware (`AP_HAL'). Es el intermediario al queel rmware llama cada vez que quiere acceder directamente al hardware. Además, esla responsable de la portabilidad del rmware a las distintas placas que lo soporta,y por ello tiene subdirectorios especícos para cada tipo de placa.

4. Los directorios de herramientas. Son directorios de apoyo de actividades varias.Por ejemplo `Replay ' gestiona el guardado del monitorizado de la sesión.

5. El código externo de apoyo. Su nalidad es dar soporte a algunas característicasadicionales o a la placa. Los elementos externos que constituyen ésta parte son:

• PX4NuttX. El núcleo del sistema operativo en tiempo real para placas Pix-hawk• PX4Firmware. El middleware y drivers usados en placas Pixhawk.• UAVCAN. La implementación del protocolo CANBUS utilizado en el rm-ware de Ardupilot.• MAVLink. El generador de código y responsable del protocolo de comunica-

ción Mavlink.

Dentro del rmware Ardupilot distinguimos una serie de tipos de vehículo. Aunquela mayor parte del código es genérica y aplicable a todos los tipos de vehículo, cada tipotiene asociada una considerable porción del código que cubrirá las funciones propias dedicho vehículo:

• APM Plane. Para drones con forma de avión de ala ja.

• APM Copter. Agrupa los distintos modelos de helicópteros, multicópteros y mo-nocópteros y puesto que es el que se ha empleado en éste trabajo, es el que vamosa desarrollar próximamente.

• APM Rover. Para vehículos terrestres y embarcaciones.

• APM Sub. Para ROVs sumergibles y submarinos.



Como resulta lógico, a lo largo de éste capítulo vamos a ignorar el código propio delos otros vehículos, ya que cada una de éstas divisiones funciona de forma independientea las demás y por tanto no tendrá ningún efecto sobre nuestro proyecto.

Figura 4.2: Estructura propia del modelo Copter de Ardupilot.[21]

La Figura 4.2 representa una visualización especíca del modelo Copter dentro delcódigo de Ardupilot. El bloque que se encuentra en la parte superior izquierda del esquemaalberga el contenido de los drivers de los sensores, y se ejecuta en segundo plano. Dentro,se reciben los datos de los sensores y se transforman a unidades estándar, que luegoson almacenadas en búers propios de la capa superior (front-end) de los drivers.La laderecha de bloques del programa muestra la secuencia de ejecución del hilo principaldel programa. Este thread se ejecuta periódicamente a 400 Hz en nuestro caso (paracualquier frame contenido en el modelo Copter), y comienza accediendo a los últimosdatos disponibles en la capa superior de los drivers. De esa forma, por ejemplo paraestimar la actitud, el AHRS (sistema de referencia de actitud y rumbo) y el EKF (ltrode Kalman), accederán a los últimos datos leídos por el acelerómetro, giróscopo y brújuladesde la capa superior de los drivers.



Dentro del propio modelo Copter, encontramos otra distinción tipológica en cuanto alframe con el que se identica a nuestro vehículo. Dependiendo del frame seleccionado, elcódigo tomará uno u otro rumbo a la hora de efectuar el control de actitud en base a lasentradas de los sensores y de la emisora para asemejar el comportamiento a la morfologíafísica del vehículo.

A continuación, vamos a hacer un listado de las librerías más importantes del códigode Ardupilot. Todas éstas librerías son de carácter general, es decir compartidas entre los4 modelos de vehículo de Ardupilot. Las que aparecen listada no constituyen la totalidadde las librerías del código sino sólamente las más relevantes para el entendimiento de todoel código. La lista completa contiene más de un centenar de familias de librerías que porrazones de simplicidad y brevedad no se incluyen a continuación.

Librerías principales:

• ÀP_AHRS'. Estimación de la altura con ltro de Kalman.• ÀP_Common'. Contiene ìncludes ' vitales para el funcionamiento de todo sketch

y librería.• ÀP_Math'. Funciones matemáticas útiles en el cálculo vectorial.• ÀC_PID'. Controlador PID del sistema.• ÀP_InertialNav'. Interpreta la inercia de navegación a través de los sensores.• ÀC_AttitudeControl'. Funciones de control PID en altura y posición.• ÀP_WPNav'. Navegación punto a punto.• ÀP_Motors'. Combinación de los motores según el modelo de vehículo.• `RC_Channel'. Convierte la entrada PWM a grados o velocidad motores.• ÀP_HAL', ÀP_HAL_AVR', ÀP_HAL_PX4'. Implementan la HAL a las

placas.

Librerías de sensores:

• ÀP_InertialSensor'. Lee las entradas del giróscopo y el aceletrómetro, efectúala calibración y adecua las unidades medidas (deg/s, m/s) al código principal.• ÀP_Range_Finder'. Interfaz de los sensores infrarrojos y de ultrasonidos.• ÀC_Baro'. Interfaz del barómetro.• ÀP_GPS'. Interfaz del GPS.• ÀC_Compass'. Interfaz de la brújula de 3 ejes de referencia.• ÀP_OpticalFlow'. Interfaz del ujo óptico sensorial.

Otras librerías:

• ÀP_Mount, AP_Camera, AP_Relay.' Control del soporte y del obturadorde la cámara montada.• ÀP_Mission'. Recibe y almacena las órdenes de vuelo en la EEPROM.• ÀC_Buer'. Búer FIFO que usa ÀP_InertialNav'.• ÀP_Scheduler'. Interfaz del GPS.• ÀC_Compass'. Planica tareas y tiempos dentro del thread principal.



4.3. Interpretación de las lecturas

El código de ArduPilot se ha escrito de forma polivalente en cuanto al hardware queadmite. Por ello tiene asociados una serie de drivers destinados a la compatibilidad dediversos protocolos de comunicación destinados a la transmisión de información de laplaca con las entradas y salidas del sistema. Los protocolos compatibles con Ardupilotson I2C, SPI, UART y CANBUS. En los siguientes apartados procederemos a exponerbrevemente las características de cada uno de éstos protocolos[22].

1. I2C. Es un protocolo serie de comunicación por un sistema de dos líneas llamadasSCL (Serial Clock) y SDA (Serial Data). Todos los dispositivos en el bus están co-nectados con éstas dos líneas y toda la comunicación ocurre cuando uno de los dosdispositivos (designado como maestro) inicia la comunicación. El resto de dispositi-vos (designados como esclavos) tienen una labor puramente reactiva y sólo envíano reciben información cuando el maestro manda la orden[23].

Figura 4.3: Protocolo I2C.[24]

2. SPI. Es un protocolo de comunicación síncrona compuesto por 4 líneas: SCLK(señal de reloj ), MOSI (Master-Out-Slave-In), MISO (Master-In-Slave-OUT ) y unpin de selección por cada esclavo. Además de ser más rápido que el I2C, permiteuna comunicación full-duplex pero sólo es válido para distancias cortas[23].

Figura 4.4: Protocolo SPI.[25]



3. El UART (Universal Asynchronous receiver-transmitter) es un protocolo de comu-nicación serie asíncrono a través de dos líneas en el cual el formato de los datos y lavelocidad de transmisión son congurables. Puede cubrir distancias grandes y conuna velocidad relativamente grande[23].

Figura 4.5: Protocolo UART.

Éste protocolo es especialmente importante en el rmware puesto que es el respon-sable de la comunicación con:

• El enlace USB con Mission Planner.• El enlace por telemetría MAVLink con Mission Planner.• El primer y (opcional) segundo GPS conectado.• La telemetría alternativa con la radio.

4. El CAN bus es un tipo de bus muy robusto, del cual deriva UAVCAN, el cual esun protocolo diseñado para establecer una comunicación segura en aplicaciones enel sector aeroespacial y de robótica. Es un sistema de comunicación con múltiplesmaestros, en el cual cualquier nodo puede establecer la transmisión de datos. Lacomunicación se hace a través de dos líneas llamadas Can HI (nivel alto) y Can LO(nivel bajo)[23].

Figura 4.6: Protocolo CANBUS.[26]

En Ardupilot, se acondiciona el entorno necesario para emplear éste último tipo de busde dos formas que explicaremos brevemente a continuación: proporcionando los driversHAL necesarios para dar soporte al hardware y empleando el protocolo UAVCAN que esel responsable de manejar las tareas de alto nivel.

El software básico responsable de la compatibilidad de Ardupilot con el bus CAN selocaliza en la librería `AP_HAL' y se puede decir que consiste de 2 clases:



1. 1- La clase `CAN'. Es la responsable de la representación de una interfaz físicaen la placa. Ésta clase se encarga también de la apertura, la conguración y laejecución de la interfaz, y constituye un punto de conexión esencial entre el softwarey el hardware.

2. La clase `CANManager'. Agrupa todas las interfaces físicas. En ella se distingueuna enumeración de las interfaces además de proveer un acceso a ellas y supone unpunto de acceso para acceder a la clase `CAN'.

Por otro lado, ÀP_UAVCAN' es la librería que da soporte al protocolo UAVCAN,y contiene la interacción con `Libuavcan'. También proporciona un punto de acceso aotras librerías de interés de Ardupilot. Es el responsable de enviar y recibir los mensajesa través del bus CAN con el protocolo UAVCAN, y de traducirlos a formas aceptablespor otras librerías. La idea consiste en que las librerías que pueden consumir o transmitirdatos envíen la información a ÀP_UAVCAN' de su forma preferente. Además, tambiénproporciona un ciclo de actualizaciones de `Libuavcan'.

En el aspecto sensorial, el rmware sigue una estructura FrontEnd/BackEnd que con-siste en la separación formal entre la capa externa de presentación (llamada front end) yla capa interna de acceso de datos (llamada back end). En el `setup()' del programa, lacapa front end es la responsable de la creación de una o múltiples capas back end en basea la detección automática del tipo de sensor que se está usando. De ésta forma, el códigodel vehículo nunca se comunica directamente con los drivers del sensor, sino que lo hacesiempre a través del front end, el cual llama a los distintos back ends que constituyen losdrivers de los sensores.

4.4. Gestión de las entradas y salidas externas

Cuando hablamos de entradas externas, nos referimos a la información que no vienede los sensores de la placa, sino a la que enviamos desde la emisora radio. Las entradasde la emisora juegan claramente un papel esencial en el código de Ardupilot, no sólo porel rol que desempeñan en el manejo del vehículo sino porque también permiten efectuarcambios de forma remota del modo de vuelo activo en el vehículo, así como el controlde módulos auxiliares como la posición de la cámara montada (si la tiene). La señal querecibe nuestra placa desde el receptor radio viene en forma de PWM (en otras placas elprotocolo de comunicación es distinto), y el objeto responsable de la comprehensión enbajo nivel de éstos valores para transmitirlo al resto del código es `RCInput', contenidoen la librería ÀP_HAL'.

Las salidas externas son las que usa Ardupilot para controlar los servos y motores. Elnúmero de salidas disponibles es una característica propia en cada placa. En el caso de laAPM, el número de salidas posibles es 8. Sin embargo, nuestro modelo coaxial únicamenterequiere 4 salidas de motores y servos para funcionar. Las salidas a éstos servos y motorestambién se transmite en forma de PWM. En los servos, los PWM suelen tener un valordel orden de 50 Hz mientras que en los ESC tienen un valor alrededor de los 400 Hz. Deforma análoga a `RCInput', el objeto `RCOutput' perteneciente a la librería ÀP_HAL'es el responsable de la transmisión en bajo nivel de las señales PWM a los motores delvehículo.



Aunque hemos hablado de cómo los objetos `RCInput' y `RC Output' gestionan lasentradas y salidas a bajo nivel, el alto nivel lo maneja otro objeto llamado `RC_Channel',el cual dispone parámetros congurables por el usuario para modicar los valores demínimo máximo y trim (ajuste) de cada canal. También proporciona los medios paracongurar un canal auxiliar, además de la posibilidad de escalar los valores de entradas ysalidas, entre otras características. Observando el código de la librería `RC_Channel', nospodemos encontrar con que muchas de las variables atribuidas a parámetros modicablesdesde Mission Planner se aplican tanto a las operaciones de entrada como de salida. Porejemplo, `rc1.radio_trim' se aplica la calibración al canal 1 tanto en la entrada como enla salida, donde especica el punto medio de navegación al servo conectado al canal 1. Esdecir, se establece una asociación entre los números de los canales de entrada y los de loscanales de salida, a pesar de que por separado cumplen funciones diferentes.

Desgraciadamente, esto impide un uso exible si lo que se quiere es controlar por se-parado lo que ocurre en la entrada y la salida de un mismo canal, puesto que no sonindependientes entre ellas. En nuestro caso particular no nos interesa modicar las aso-ciaciones de entradas y salidas que hay en cada canal así que esto no nos supone unimpedimento.

4.5. Orden de ejecución y planicación de tareas

La siguiente imagen muestra un esquema explicativo de la arquitectura del código deArduPilot. A primera vista puede parecer que ArduPilot usa un único thread, a travésde las funciones `setup()' y `loop()' típicas de Arduino, pero en realidad el código poseemás de un nivel, puesto que la mayoría de placas soportan multi-threading. Sin embargo,nuestra placa (APM) no pertenece a este grupo. Por ello, en lugar de emplear varios I,utiliza un temporizador simple con un sistema de callbacks.

Los callbacks son bloques de código ejecutable que esperan a ser llamados o ejecutadospor otro bloque de código. Una función callback es esencialmente un patrón (en el sentidode que es una solución establecida a un problema común), y por tanto el uso de una funcióncallback también se conoce como un patrón callback. El funcionamiento de los callbacksse basa en la transmisión de funciones y variables que se usan en otras funciones. Cuandopasamos una función callback como argumento a otra función, sólo estamos pasando ladenición de la función, no estamos ejecutando como tal la función. Y puesto que lafunción contenida cuenta con la función callback en sus parámetros como una función yadenida, es capaz de ejecutar el callback cuando lo necesite.

Los callbacks constituyen un mecanismo de implementación asíncrono de programa-ción. Esto implica que se evita que el procesador se quede ocioso esperando a que se lepase una orden. En lugar de ello, se obliga al procesador a mantenerse ocupado con unaserie productiva de tareas, y cuando la orden nalmente llega, el procesador es llamadopara acatar la actividad que viene asociada con la orden. En suma constituye un sistemaefectivo para sacar el máximo partido al procesador[27]. Dentro del código de Ardupilot,los callbacks se emplean siguiendo un sistema especíco. En todo momento, se ejecutaun temporizador de 1 kHz en `AP_HAL'. Con él, se puede llamar a cualquier funciónen el código a 1 kHz, de forma que se puede formar un registro de funciones que se vanllamando secuencialmente.



Los callbacks se introducen en éste registro usando:

ha l . s chedu le r−>reg i s t e r_t imer_proce s s ( )

Si quisiésemos ejecutar un trozo de código con una frecuencia mayor que 1 kHz,se haceque mantenga la variable `last_called' de forma que vuelva a ello inmediatamente si noha ejecutado la función. Para conocer el tiempo desde la última llamada, utilizamos unade las siguientes funciones:

ha l . s chedu le r−>m i l l i s ( )ha l . s chedu le r−>micros ( )

Si se estuviese trabajando con varios threads (se recuerda que la placa APM empleaen su lugar temporizadores con callbacks) sería necesario asegurarse de que los datoscompartidos entre ellos están sincronizados, para evitar la corrupción de datos. Para ellose emplean principalmente semáforos (Semaphores), que proveen un mecanismo simplepara lograr un tráco correcto de datos entre threads.

Sin embargo, como hemos dicho, la placa APM no utiliza un sistema de threads ypor ello requiere un sistema de planicación de tareas, que se contiene en la libreríaÀP_Scheduler'. Dicha librería sirve para proveer un mecanismo sencillo de control sobrelos tiempos de ejecución de cada tarea, dividiendo los tiempos programados para cadaoperación dentro del thread principal. Éstas referencias de tiempos aparecen en una tablade tareas, que puede tener un aspecto como el ejemplo siguiente:

s t a t i c const AP_Scheduler : : Task schedu ler_tasks [ ] PROGMEM = ins_update , 1 , 1000 , one_hz_print , 50 , 1000 , f ive_second_cal l , 250 , 1800 ,

;

El primer número que aparece en cada tarea es la frecuencia de la llamada, siendola unidad de tiempo la que se ha especicado en ìns.init()'. En el ejemplo anterior, sien ìns.init()' se ha jado un `RATE_50HZ', cada paso de tiempo será de 20 ms, porlo que la llamada a ìns_update()' se realizará cada 20 ms, la llamada a `hz_print' serealizará cada 1 segundo (cada 50 veces que pasen 20 ms) y `ve_second_call' se llamarálógicamente cada 5 segundos (cada 250 veces).

El segundo número que aparece indica el tiempo máximo de ejecución de cada tareaprogramada. Gracias a ello se puede evitar hacer las llamadas a las funciones si se sabeque no hay tiempo suciente para ejecutarlas en el peor de los casos. La cifra indicadirectamente el tiempo en microsegundos para cada tarea.

También es necesario aclarar que la función `loop()' permanece en espera (bloqueada)siempre que está esperando la siguiente lectura de IMU (Unidad de Medición Inercial), yseguidamente a recibirlas procede a ejecutar el grupo de tareas asociadas a ésa lectura. Deésta forma, la recepción de la lectura de la IMU constituye el metrónomo que marca el pasoen la planicación de tareas del código. Las tareas ubicadas en el listado de planicaciónde tareas nunca deben llamar a funciones de espera o de sleep ya que alterarían el ritmode ejecución mencionado antes, además de haber previsto el tiempo máximo de ejecuciónen el peor de los casos.



Para resolver los casos en los que una o más ordenes programadas quieran ejecutarseal mismo tiempo, se dispone de tres sistemas de control[28].

• Los semáforos. Son variables que se modican de acuerdo a las condiciones pre-denidas en el programa cuando hay un problema de concurrencia de procesos.• Las estructuras lock-free. Son partes del algoritmo que permiten a procesos ac-

ceder a un mismo recurso sin generar algún bloqueo, y resultan más ecientes quelos semáforos.• El ORB (Object Request Broker). No lo vamos a comentar debido a que es un

mecanismo exclusivo para la placa PX4.

4.6. Gestión de memoria

La placa APM 2.8 posee 4 kilobytes de memoria programable no volátil EEPROM.Ésta memoria es usada para almacenar parámetros de usuario, puntos de referencia y pun-tos de reunión, entre otros. Ardupilot gestiona el acceso a éste almacenamiento mediante4 tipos de mecanismos:

• El objeto ÀP_HAL::Storage.' Es accedido desde la librería `hal.storage'.• La librería `StoreManager'. Proporciona un mayor nivel de abstracción a la

anterior librería citada.• La librería `DataFlash'. Almacena un registro de datos de a bordo.• Funciones que establecen una interfaz Posix. Es decir, una interfaz portátil

de Linux habilitada en cheros tradicionales.

El resto de las librerías y funciones referentes a la gestión de memoria permanen-te se construyen a partir de éstos mecanismos. Por ejemplo, la librería ÀP_Param' seconstruye sobre el objeto ÀP_HAL::Storage' mencionado anteriormente. A continuaciónanalizaremos las funciones de los 4 mecanismos citados más detalladamente.

1. ÀP_HAL::Storage.'

ÀP_HAL::Storage' es un objeto que está presente en todas las plataformas enlas que se instale el rmware de Ardupilot, no sólo en APM. Aunque otras placasconstan de un espacio de memoria mayor (la Pixhawk cuenta con 16 kilobytes dememoria EEPROM ), la APM cuenta con 4096 bytes, pero todas ellas cuentan conla interfaz ÀP_HAL::Storage API' para gestionarlo mediante 3 funciones:

• ìnit()' que inicia el subsistema de almacenamiento.• `read_block()'. que lee un bloque de bytes.• `write_block()'. que escribe un bloque de bytes.

La simpleza de la interfaz facilita la labor de la gestión de memoria mediante el uso dela interfaz API en lugar de la librería. El tamaño de la memoria disponible con la in-terfaz está determinado de forma estática dentro de ÀP_HAL/AP_HAL_Boards.h'.



2. La librería `StoreManager'.

Aunque la API descrita en el apartado anterior facilita mucho el almacenamien-to del rmware en una placa, no es lo más conveniente para manejar el espaciodisponible. Para ésta labor usamos el `StoreManager', que provee otra interfaz APIque abstrae la información almacenada en bloques semi-continuos de datos que tie-nen un objetivo asignado. Es decir, lo que estamos haciendo es tomar como puntode partida el espacio disponible en secciones que proporcionan parámetros, puntosgeométricos de límites, puntos de referencia y puntos de reunión en vuelo.

En el código de `StoreManager.cpp' se pueden observar unas tablas en la partesuperior. En ésta tabla es donde aparece la distribución de áreas. En ella se puede verla estructura de varios de los bloques de datos no contiguos localizados en un mismobloque lógico, lo cual reeja la mecánica impulsada por el gestor `StorageManager'.La idea detrás del uso de éste sistema es intentar evitar que los usuarios tengan querecongurar su placa para adaptarla a su versión de Ardupilot, lo cual acaba siendoun tema bastante recurrente en el desarrollo del rmware. Además, la interfaz del`StoreManager' también provee algunas funciones útiles de lectura y escritura devariables.

3. La librería `DataFlash'.

Además del almacenamiento del rmware y de parámetros de vuelo, otro tipo dealmacenamiento que el sistema necesita es el dedicado a los registros de a bordo,lo cual es gestionado por la librería `Dataash'. Ésta librería puede parecer extrañapor distintas razones.

Su nombre proviene de su diseño inicial pensado especícamente para el chip `Data-Flash' de la APM 1. Originalmente, consistía en un driver que con el tiempo acabótransformándose en el sistema de registros que es ahora. Por lo tanto, se puede es-perar que la estructura interna de ésta librería reeje su historia de maneras no muyconvenientes.

La interfaz API de `DataFlash' se ha diseñado para funcionar como un modelode infraestructura de registros. Esto permite autodenir estructuras de datos paramensajes de registro individuales. Por ejemplo, el mensaje GPS perteneciente alregistro de datos del sensor GPS. Esto permite guardar y gestionar de forma e-ciente los registros de datos en su almacenamiento de memoria permanente a la vezque provee una interfaz API para otras librerías que pueden requerir sacar los datosregistrados cuando el usuario desee descargar éstos registros después de realizar unvuelo.

De una forma similar a la librería `StorageManager', si accedemos a `DataFlash.cpp'y nos centramos en la parte superior, podemos observar una pequeña tabla ahí si-tuada que dene los mensajes de registro que se van a escribir cuando el vehículoesté en vuelo.



Sin embargo, la APM pone un ligero problema con esto ya que a diferencia delresto de placas modernas, sólo posee 4 megabytes de almacenamiento en el chip`DataFlash' accesible por una interfaz SPI. La interfaz está orientada a un diseñopor páginas de forma que sólo se pueden rellenar 512 bytes por cada página, y des-pués es necesario informar al chip para que copie la página rellenada en la memoriapermanente mientras se continúa la labor de escritura de la siguiente página. Los4 megabytes que posee la APM 2.8 no suponen mucha capacidad de memoria enrelación a la cantidad de datos que suele registrar el sisema automáticamente, lo quenos obliga a trabajar con un mecanismo llamado wrapping (que consiste en llamara otras subrutinas) cuando se llena cada página.

Toda ésta complejidad se esconde detrás de una interfaz API que muestra un núme-ro de registro, el cual es simplemente un pequeño conjunto de bytes que se escribendurante el vuelo con Ardupilot. La implementación de `Dataash' para placas APMemplea un marcador de bytes en el frente de cada página que indica el número deregistro que está siendo escrito en un momento dado. Los números de registro secorresponden con los que luego aparecen descargados cuando el usuario recuperasus registros.

4. Posix IO.

Posix es una familia de implementaciones estandarizadas que mantienen compa-tibilidad entre diferentes sistemas operativos. Siguiendo éstos criterios, Posix denelas interfaces de programación de aplicaciones (API ) junto con consolas de coman-dos e interfaces de utilidades, que hacen compatible a variantes de Unix con otrossistemas operativos. Algunas de las placas que soportan Ardupilot (de entre las cua-les no se encuentra la APM) se basan en un sistema operativo que posee una interfazAPI parecida a Posix. Por ejemplo, el sistema operativo NuttX que emplea la Pix-hawk tiene una considerable capa Posix. Por ésta razón se pueden delegar algunasde las funciones a éste mecanismo (sólo funciones no imprescindibles ya que éstasdeben ser compatibles con todas las placas).

Para usar Posix IO se debe comprobar primero si la placa posee soporte Posix IOobservando la macro `HAVE_OS_POSIX_IO' contenida en `AP_HAL_Boards.h'.Después, para conocer dónde se puede almacenar la información dentro del chero,es necesario añadir una macro especíca en `AP_HAL_Boards.h' que proporcionala dirección donde los datos se van a colocar.

Una vez se han satisfacen las anteriores condiciones, se pueden emplear las funcioneshabituales Posix IO como `read', `write', `close', etc. Sin embargo se deben tomarciertas precauciones al manejar funciones Posix, como tener cuidado de llamarlassólo desde el temporizador IO, y nunca desde la API directamente accesible desdela librería.

En una Pixhawk, una operación de IO puede durar tiempos de hasta un segundo,lo cual es tiempo suciente para afectar enormemente a la respuesta en vuelo delvehículo en vuelo. Con esto se intenta subrayar la importancia de extremar el cuidadosi se intenta modica ésta sección de la gestión de memoria.



4.7. Sistema de estimación

El sistema de estimación que Ardupilot es el responsable de obtener los valores másrigurosos posibles de las variables que representan la información de la lectura de la actituddel vehículo, y resulta crucial para el procesamiento correcto de los valores de entrada conlos que más adelante juega el control de estimación del rmware.

Este sistema realiza el cálculo de posición, velocidad y orientación en base a las lecturasde los sensores (giróscopo, acelerómetro, brújula, GPS y barómetro) y se fundamenta enel uso de un algoritmo que emplea un Filtro de Kalman Extendido (EKF ). Éste ltro, quetambién puede ser llamado Filtro Kalman-Schmidt, consiste en la versión para sistemasno lineales del ltro de Kalman, el cual tiene como objetivo predecir linealmente unaestimación del sistema a partir de la actual media y covarianza del sistema.

El funcionamiento del EFK se puede resumir argumentando que es un ltro de Kal-man tradicional aplicado a un sistema de error lineal aproximado aplicable al sistema.Debido a que el EFK se obtiene empleando una aproximación de un sistema no lineal, noproporciona garantías de optimización desde el punto de vista matemático del error, peropara muchos sistemas (notablemente para sistemas de navegación y GPS), el EFK hademostrado ser un método de gran utilidad en la obtención de estimaciones del estado deun sistema. En los epígrafes siguientes explicaremos brevemente la matemática detrás delltro de Kalman tradicional, lo que nos ayudará a comprender su equivalente extendidopara sistemas dinámicos[29].

El ltro de Kalman tradicional consiste de dos pasos: una predicción seguida de unaactualización de los valores de entrada. La expresión (4.4) expresa la predicción que estimael ltro, siendo µn el valor de la media, Kn la covarianza, y en la estimación del error(x− µn)[30].

µn = E[f(µn−1, un, bn, n)]

Kn = E[enenT ]

(4.1)

El segundo paso del algoritmo siendo la actualización de los valores de entrada sederiva como el error cuadrático medio de la estimación. Queda como se muestra en lasecuaciones (4.2).

µn = µn +Wnνn

νn = yn − ynyn = E[g(µn, vn)]

(4.2)

Con esto en mente, ya podemos lanzarnos a la aplicación del EFK en el rmware deArdupilot. El algoritmo que implementa el EFK se encuentra en la librería `AP_NavEFK'y estima un total de 22 estados a partir de las ecuaciones contenidas en la librería.

A continuación, vamos a realizar unas breves aclaraciones previas antes de abordaruna descripción simplicada sin lenguaje matemático que ilustra el funcionamiento delalgoritmo.



Empezaremos identicando los distintos estados que resultan de la estimación con elEKF :

• Altura (en cuaternios).• Velocidad (Norte, Este, Abajo).• Posición (Norte, Este, Abajo).• Sesgo de medición del giróscopo (ejes X, Y, Z).• Factores de escala del giróscopo (ejes X, Y, Z).• Sesgo de medición de la aceleración vertical (eje Z).• Campo magnético presente (ejes X, Y, Z).• Velocidad del viento (Norte, Este).

Por otro lado, denimos la Unidad de Medición Inercial (IMU ) como el conjunto desensores y drivers responsables de la medición de la velocidad, orientación y aceleracionesen nuestro vehículo. Con esto aclarado, el hilo descriptivo del algoritmo es el siguiente:

1. Se calcula la posición angular a partir de los valores angulares proporcionados porla IMU.

2. Se convierten las aceleraciones recibidas por la IMU empleando la posición angulardel cuerpo (X,Y,Z) en medidas con ejes terrestres (Norte, Este y Abajo) y se aplicala corrección por la gravedad.

3. Se integran las aceleraciones en el cálculo para hallar la velocidad del vehículo.

4. Se halla la posición actual del vehículo a partir de la velocidad del mismo.

5. Se estima el ruido intrínseco del acelerómetro y del giróscopo y se emplean paraestimar el crecimiento del error en la determinación de los ángulos, velocidades y laposición que realizamos en los pasos anteriores. Si no se realizan correcciones em-pleando otros sistemas de medida, como el GPS, éste error de estimación no cesaráde crecer. Los errores estimados se agrupan en una matriz larga llamada la Matrizde Covarianza de Estados (State Covariance Matrix ).

6. En cuanto se recibe la lectura del GPS, el ltro compara la diferencia entre la posi-ción estimada en el punto 4 y la posición medida por el GPS y a éste valor le llamala innovación.

7. Se combinan la innovación, la matriz de covarianza de estados y el error de la me-dición del GPS para calcular la corrección de cada uno de los estados del ltro. Aéste proceso le llamamos corrección de estados.

8. Con cada medida nueva que tomamos, la cantidad de incertidumbre en cada estadoque se actualiza se reduce. El ltro calcula ésta reducción de incertidumbre realizadagracias a la corrección de estado y después actualiza la matriz de covarianza deestados. Finalmente, regresa al paso 1 y vuelve a empezar el proceso.



En adelante, nos referiremos a los pasos contenidos entre los puntos 1 y 4 como elproceso de predicción de estado. Tal y como hemos aclarado antes, los estados son variablesque queremos estimar, como el roll, pitch y yaw, la altura, la velocidad del viento, etc.A parte de la posición, la velocidad y la orientación, el ltro también tiene en cuenta laestimación de otros estados que están sujetos a cambios de forma lenta, entre los cuales seincluyen el sesgo de medición de los distintos sensores, la velocidad del viento y el campomagnético terrestre. Los estados citados no se modican directamente por la predicciónde estado, pero pueden ser afectados por otras mediciones tal como describiremos másadelante.

Aclararemos que si poseyésemos una estimación inicial perfecta, unas lecturas de laIMU perfectas y un error nulo en los cálculos de estimaciones, podríamos prescindir delos siguientes pasos y repetir los pasos de 1 a 4 durante todo el vuelo sin realizar ningúnotro cálculo. Sin embargo, se dan errores en los valores iniciales, en las lecturas de la IMUy en el redondeo de los cálculos por lo que en realidad sólo podríamos volar durante unossegundos antes de que los errores acumulados de velocidad y posición ganen demasiadarelevancia.

Los pasos contenidos de 1 a 5 se repiten siempre que se recibe una nueva entradade proporcionada por la IMU hasta que una nueva medida proveniente de otro sensoresté disponible. El algoritmo del EKF provee una forma de combinar los datos obtenidospor la IMU, el GPS, la brújula, el barómetro y otros sensores para calcular de la formamás precisa y dedigna posible la velocidad, posición y la orientación del vehículo. Lossiguientes puntos describen cómo una medición de la posición horizontal del GPS afectaal procesamiento del resto de lecturas. Esto también es aplicable a los usos con otros tiposde medida, como la altura barométrica.

Donde el ltro de Kalman brilla más es precisamente en el reconocimiento de la co-rrelación entre diferentes errores y diferentes estados para corregir otros estados ademásdel que se está leyendo y empleando actualmente. De esta forma se consigue que medidascomo la del GPS sean capaces de corregir errores en la posición velocidad y orientación.El grado de corrección que se aplica en éste último paso es moderado en relación al valordel error acumulado en las medidas. Esto implica que en el caso de que el ltro opine quesi su velocidad calculada es menos able que la medida del GPS, se ponderará con másacentuación la medida del GPS. La abilidad con la que se considera al GPS se puederegular manualmente modicando el parámetro `EFK_POSNE_NOISE'.

El proceso que hemos descrito hasta ahora expresa el funcionamiento básico del EFKimplementado en las primeras versiones de ArduCopter. Desde entonces, el modelo haevolucionado en lo que ahora se llama EKF2, que presenta una considerable cantidad deventajas. Para empezar, permite el procesamiento con múltiples IMU compensación deerrores mediante lecturas simultáneas de distintas IMU. Puede estimar errores de oseten el giróscopo en un arranque en movimiento, además de admitir una mayor toleranciaa la corrección de distintos tipos de errores, consiguiendo una salida ligeramente másable, todo ello requiriendo una ligeramente menor cantidad de recursos hardware paraprocesarse.

A continuación, procederemos a explicar los diferentes mecanismos con los cuales con-sigue lograr las diferentes ventajas que acabamos de mencionar aquí.



• En lugar de intentar realizar la estimación del cuaternio directamente, se estima unvector de error rotacional y se aplica la corrección al cuaternio desde las ecuacionesde navegación inercia. Cuanto mayores sean los erores angulares, más ecaz resultaéste mecanismo ya que evita errores asociados con la linealización de cuaternios concorrecciones angulares considerables. El fundamento teórico de éste mecanismo sepuede encontrar en el libro [31].

• Éste EKF se ejecuta en un marco temporal retrasado, de forma que permite combi-nar las medidas, el ltro de estados y la matriz de covarianzas de un mismo instante.El método que empleaba el anterior EKF empleaba medidas retrasadas para com-binarlas con estados retrasados pero la matriz de covarianzas sí que era actual, locual reduce la precisión del sistema. En el EFK2, los estados retrasados del ltro sepredicen para emplearlos en el marco temporal actual, donde se usa un ltro com-plementario que retira el retraso temporal además de los cambios repentinos queocurren cuando se combinan medidas. La base teórica que hace éste sistema posiblese puede encontrar en la publicación [32]. A nivel computacional, esto resulta muchomás eciente que predecir los estados usando datos de la IMU almacenados en cadaiteración. El mecanismo que usaba el anterior EKF suavizaba las correcciones deestado incrementalmente lo cual, a la larga, reduce la estabilidad del ltro.• Las operaciones matemáticas en el código son más ecientes, lo que logra una mayor

velocidad en el cómputo del ltro.

• Se ha incluido una versión simplicada para regular el mecanismo de correccióndel ángulo yaw de la brújula que se ejecuta en tierra o cuando hay demasiadainterferencia magnética que impide el uso del otro sistema (más preciso) que empleauna combinación de 3 ejes para determinar 6 estados con el magnetómetro.

Finalmente, es necesario mencionar la existencia de parámetros responsables del ajustedel EFK. Los parámetros tienen valores por defecto calibrados para proporcionar un buencompromiso entre precisión y robustez de los sensores.

4.8. Control de actitud

El control de actitud se reere a la regulación automática de la orientación de un objetorespecto a un marco de referencia inercial (en nuestro caso, el horizonte). Para controlarla actitud de un vehículo se emplean los datos recibidos por los sensores en un lazo derealimentación de información que regula la salida que se obtienen en los actuadores. Paraello, ArduCopter emplea un sistema de reguladores PID que explicaremos en los siguientesepígrafes.

Los ángulos motores se introducen para empezar en un conversor que traduce el errorangular (diferencia entre el ángulo deseado y el ángulo actual) en el valor de rotacióndeseado. Aunque en el esquema (Figura 4.7) éste conversor aparece como un regulador detipo P, lo cierto es que se trata de otro tipo de control, llamado Square Root Controller ,que se utiliza también como sistema de compensación para sistemas dinámicos[33]. El valorsaliente de ésta conversión se introduce en el controlador PID que convierte el error derotación en las órdenes de alto nivel para los motores.



Figura 4.7: Lazo de realimentación simplicado.[34]

La transformación que sucede dentro del Square Root Controller se corresponde a unaconversión lineal a partir de la raíz cuadrada de las medidas que entran como ángulosmotores. Ésta conversión se puede ver en la gráca que aparece en la Figura 4.8. Elfundamento teórico detrás del conversor establece que al ser la solución trivial la únicaposible en un sistema en cadena cerrada y restringido a una región Ω, se puede concluirque el origen del espacio de estados es globalmente asintóticamente estable. De esta formase prueba matemáticamente la garantía de estabilidad para la regulación automática enel punto de equilibrio del sistema[33].

Partiendo de que la función de Lyapunov V(q, q) que representa el análisis de laestabilidad de la ecuación del sistema en base a los vectores de desplazamiento angular qy la ganancia proporcional del equivalente regulador P Kp es:

V (q, q) =1

2qTM(q)q + 2

∣∣∣∣∣∣∣∣∣

√√q2

1 + 1− 1√√q2

2 + 1− 1√√q2n + 1− 1

∣∣∣∣∣∣∣∣∣T

Kp

∣∣∣∣∣∣∣∣∣

√√q2

1 + 1− 1√√q2

2 + 1− 1√√q2n + 1− 1

∣∣∣∣∣∣∣∣∣(4.3)

Y la región Ω que se dene como:

Ω =

∣∣∣∣qq∣∣∣∣ ∈ IR2n : V (q, q) = 0

Ω = q ∈ IRn : V (q, q) = 0

(4.4)

Siendo q cada vector (uno para cada dimensión) de deplazamiento angular y V(q, q)la función de Lyapunov, entendemos que puesto que V (q, q) 6 0, entonces V ( ˜q(t), ˙q(t)) 60 es descendiente, y V (q, q) 6 0 es continua dentro de la región Ω. Esto implica queV ( ˜q(t), ˙q(t)) 6 0 tiene un límite α ∈ IR+ siendo t → ∞. Por lo tanto, V (q, q) = 0.Y ya que Ω es un espacio invariante, la única solución invariante es la trivial: q = 0 yq = 0, dando pié al razonamiento de que el origen del espacio de estados es globalmenteasintóticamente estable.

Dada su alta robustez comparándolo con reguladores tradicionales (en concreto P yPD), resulta muy atrativo para aplicaciones de control punto a punto como para la quelo hemos empleado en nuestra situación [33].



En suma, la principal ventaja de emplear éste tipo de control radica en que se garantizala estabilidad global asintótica (siempre que las medidas caigan dentro de unos límitespredenidos) y la respuesta nunca tiene oscilaciones(ya que es lineal).

Figura 4.8: Linealización con Square Root Controller.[34]

Es conveniente aclarar que modelo de PID ilustrado anteriormente (Figura 4.7) es unarepresentación muy simplicada del camino que sigue cada uno de los ángulos motores ensu control retroalimentado. Para considerar un modelo más veraz y riguroso, es necesariocontemplar una visión más amplia y detallada del sistema de control (Figura 4.9). En éstaversión expandida, se pueden apreciar las siguientes características.

• El lazo de control se repite de forma aparentemente independiente para cada unode los 3 ángulos de la actitud del vehículo: roll, pitch y yaw. Sin embargo, no es deltodo independiente ya que como veremos en el siguiente punto el ángulo yaw vieneafectado también por la salida del roll y el pitch.

• La linealización de las medidas de los ángulos de pitch y roll se efectúa tal cual seha descrito previamente, pero en el movimiento yaw, se incorpora también el valorestabilizado de roll y pitch ya que tienen efecto sobre el ángulo yaw.

• A la salida de los PIDs de cada ángulo, se incluye un limitador independiente paracada motor de forma que la salida del PID nunca sobrepase los valores impuestospor el usuario, lo cual supone una medida de seguridad para no forzar los motoresaún en el caso de que falle el lazo de control y la salida resulte ser inestable.

• A la salida de cada limitador, se aplica un parche de estabilidad, el cual como seexplicará más adelante prioriza un eje de control sobre otro cuando una entrada decontrol se encuentra fuera de los límites físicos del modelo del vehículo.

• Finalmente se recuerda que los ESC que controlan las hélices están dotados de supropio rmware que también controla y modica la señal eléctrica nal que les llegaa las hélices. Sin embargo éste rmware es independiente de ArduCopter y no sepuede tener en consideración en el estudio del código del vehículo.



Figura 4.9: Lazo de control completo del rmware.[35]



A nivel de código, podemos visualizar el diagrama que veremos a continuación querepresenta el camino seguido por el código del rmware cada vez que se recibe una entradadel piloto que se desea convertir en salida PWM, pasando por todo el lazo de controlgestionado por los PIDs.

Figura 4.10: Esquema del código del control de actitud.

El ciclo que aparece en el esquema anterior se ejecuta a una frecuencia de 100 Hz,ya que ésta es la tasa de refresco de la APM. A continuación vamos a explicar con másdetalle los pasos seguidos por el código durante todo éste ciclo.

1. La clase de alto nivel de modo de vuelo `mode.cpp' llama a la función `upda-te_ight_mode()'. Ésta función comprueba el modo de vuelo actual del vehículocontenido en la variable `control_mode' y llama a la función apropiada `<modo-devuelo>_run()', siendo <mododevuelo>reemplazado por `stabilize_run' para elmodo stabilize, o `rtl_run' para el modo RTL, etc. Ésta función (`<mododevue-lo>_run()') se puede encontrar en el archivo llamado `control_<mododevuelo>.cpp'según el modo de vuelo correspondiente, es decir `control_stabilize.cpp' o `con-trol_rtl.cpp', etc.

2. La función `<mododevuelo>_run()' convierte las entradas introducidas por el usua-rio (encontradas en `g.rc_1.control_in', `g.rc_2.control_in') en la correspondientemagnitud apropiada para el modo de vuelo seleccionado , ya sea ángulo de incli-nación, o tasa de rotación o tasa de ascenso, etc. Por ejemplo, el modo `AltHold'convierte las entradas de roll y pitch introducidas por el usuario en ángulos de in-clinación (en grados) y la entrada de yaw se convierte en tasa de ascenso (en cm/s).



3. La última tarea que realiza la función `<mododevuelo>_run()' es pasar éstas magni-tudes deseadas (ángulos de rotación o tasa ascendente, etc) a las librerías de controlde actitud o control de posición contenidas ambas en el directorio ÀC_AttitudeControl'.

4. Ésta librería (ÀC_AttitudeControl') proporciona 5 formas posibles para controlarla actitud del vehículo. Sin embargo en la práctica sólo se usan 3 de éstas formas,que vamos a describir a continuación:

• La función àngle_ef_roll_pitch_rate_ef_yaw()' acepta un ángulo de roll ypitch y una tasa ascendente para el yaw, todos ellos en su forma adimensional,llamada earth frame.• La función àngle_ef_roll_pitch_yaw()' también recibe los parámetros en for-

mato earth frame sin embargo considera el yaw un ángulo más en lugar de unatasa, con lo cual su salida también toma un valor angular estático.• La función `rate_bf_roll_pitch_yaw()' acepta los parámetros de roll, pitch

y yaw en formato body frame lo cual los convierte directamente en tasas dedesplazamiento angular en grados por segundo.

El uso de éstas funciones se puede entender mejor con el ejemplo vamos a proponer.La Tabla 4.1 que aparece a continuación representa el caso hipotético en el que seprueba a introducir una misma combinación de datos de entrada para los parámetros(roll, pitch y yaw) y se estudia la salida que obtendría cada una de las funcionesque acabamos de explicar.

Tabla 4.1: Ejemplos de aplicación de las funciones de ÀC_AttitudeControl'

Ángulo Entrante o Saliente Función 14 Función 24 Función 34Roll In -1000 -1000 -1000Roll OUT -10o -10o -10o por segundoPitch IN -1500 .1500 -1500Pitch OUT -15o -15o -15o por segundoYaw IN 500 500 500Yaw OUT 5o por segundo 5o 5o por segundo

Observando la tabla podemos entender de una forma aplicada los conceptos de earthframe y body frame en los parámetros de las funciones, así como su traducción en loque luego son desplazamientos angulares y tasas de desplazamientos angulares quemás tarde implementarán otras funciones.

5. Después de la llamada de cualquiera de éstas funciones, se llama a la funciónÀC_AttitudeControl::rate_controller_run()', la cual convierte la salida de los mé-todos que acabamos de listar en entradas de roll, pitch y yaw para que sean leíblespor la librería ÀP_Motors' mediante los métodos `set_roll', `set_pitch', `set_yaw'y `set_throttle'.

6. La posición tridimensional del vehículo se controla mediante la librería ÀC_ Pos-Control'. En el caso normal, sólo se usa para manejar métodos de eje Z simples (comopuede ser el control de actitud), ya que los modos de vuelo más complicados desdeel punto de vista del estudio tridimensional (como el modo Loiter) hacen uso de



otra librería llamada ÀC_WPNav'. En cualquier caso, los métodos más habitualescontenidos en la librería ÀC_PosControl' son los siguientes:

• El método `set_alt_target_from_climb_rate()' acepta como parámetro deentrada una tasa ascendente en cm/s y lo convierte en un valor de alturaabsoluta (no confundir con un valor absoluto de altura).• El método `set_pos_target()' acepta un vector tridimensional de posición y lo

interpreta como la desviación entre el origen y el objetivo.

Cada vez que se llama a algún método en ÀC_PosControl', el código del modo devuelo llama también a ÀC_PosControl::update_z_controller()'. Éste método eje-cuta el bucle de control PID para la variable de posición en el eje Z, y envía una señaldébil de nivel de throttle a la librería ÀP_Motors'. De manera análoga, siempre quese llame a métodos de los ejes X e Y, se llama a ÀC_PosControl::update_xy_controller()'.

7. El mezclado de los movimientos de los motores se efectúa en la librería ÀP_Motors'.En ella se contiene el código responsable de la conversión de los valores de roll, pitchy yaw recibidos desde ÀC_AttitudeControl' y ÀC_PosControl' en los valores desalida que recibirán los motores, es decir los PWM. Por lo tanto, las librerías de másalto nivel harán uso de las siguientes funciones:

• Las funciones `set_roll()', `set_pitch()' y `set_yaw()' aceptan un rango de va-lores entre -4500 y 4500 para las variables de roll, pitch y yaw. Éstos valores sonparámetros adimensionales que realmente no se corresponden ni a los ángulosni a las tasas deseadas, sino que son referentes a los límites totales que se lepuede exigir a cada actuador. Por ejemplo, si ejecutamos `set_roll(-4500)', loque estamos ordenando es que se realice la maniobra roll en sentido antihorariode la manera más rápida posible.

• La función `set_throttle()' acepta como parámetro de entrada un valor dethrottle comprendido entre 0 y 1000, donde 0 implica tener los motores paradosy 1000 supone tenerlos a máxima potencia. De manera análoga a los anteriores,éste parámetro también representa una variable adimensional.

8. Tal y como se ha especicado en otra sección, existen distintas clases para cadatipo de frame adaptado en el vehículo como por ejemplo cuadracóptero, Y6, he-licóptero tradicional, etc. En cada uno de ellos se encuentra una función llamadaòutput_armed' que es la responsable de la implementación de la conversión de losvalores que hemos obtenido en el apartado anterior de roll, pitch, yaw y throttleen salidas PWM que se envía a los motores. Ésta conversión a menudo incluye laimplementación de un parche de estabilidad. Como ya hemos mencionado anterior-mente, el parche se encarga de priorizar el control de un eje sobre el de otro cuandolas órdenes de la emisora sobrepasan los límites físicos impuestos por el tipo deframe. Por ejemplo, en un cuadracóptero no es posible activar simultáneamente unthrottle y un roll a máxima potencia, ya que para realizar la maniobra roll, unosmotores deben girar a menos velocidad que otros. En la parte inferior de la funciónòutput_armed' se puede observar una llamada al método `hal.rcout->write()', elcual es el responsable de pasar los valores de PWM deseado a la capa de abstracciónÀP_HAL'.



9. Finalmente, las librerías `AP_HAL', que corresponden a la capa de abstracción dehardware son las que proporcionan una interfaz robusta con el harware de todaslas placas compatibles con Ardupilot, y suponen la barrera nal entre las señalesenviadas por todo el sistema de control de actitud y los motores. En particular, des-tacamos la función `hal.rc_out_write()' ya que es la responsable de que los valoresPWM recibidos por la clase `AP_Motors' se transmitan de la forma apropiada enforma de trenes de pulsos modulados en los pines de salidas de la placa.

4.9. Comunicación MavLink

MAVLink (Micro Aerial Vehicle Link) es el protocolo de comunicación que emplean laplaca para enviar mensajes y comunicarse con la estación de tierra que emplea el códigode Ardupilot. Entre otras cosas, se encarga de gestionar la transmisión de puntos de ruta,la información de la telemetría, los cambios del modo de vuelo, etc. En los apartadossiguientes explicaremos la forma en la que se comunica Mission Planner con la APM yvice-versa. Los mensajes MavLink (llamados msg) son básicamente cadenas de bytesque han sido codicados por la estación de vuelo (Mission Planner) y que se envían yasea por USB o por telemetría. Nótese que no es posible enviar datos por éstas dos vías almismo tiempo, aunque de estar ambas conectadas, siempre se le dará prioridad al USBfrente a la telemetría. La codicación que hace Mission Planner no se hace tanto poraplicaciones de seguridad sino por encapsular la información en una estructura de datosque se puede enviar a través del canal en forma de mensajes. Cada uno de éstos mensajesMAVLink tiene una longitud de 17 bytes, compuestos por 6 bytes de cabecera, 9 bytes decapacidad y 2 bytes de suma de vericación (checksum), siendo su estructura:

• Cabecera. (6 bytes)

1. Mensaje de cabecera, siempre 0xFE.2. Longitud del mensaje.3. Número de secuencia, decrementa cíclicamente entre 255 y 0.4. Identicador del sistema, indica qué sistema envía el mensaje.5. Identicador del componente, indica qué componente del sistema está enviando

el mensaje.6. Identicador del tipo de mensaje, por ejemplo un 0 implica un heartbeat.7. Comunicación MAVLink

• Capacidad. (tamaño variable, entre 0 y 9 bytes) Contiene los datos de interés queestán siendo transmitidos.• Suma de vericación. (2 bytes) Se emplea para la detección de errores.

Cuando un mensaje es recibido, el software verica que el mensaje es válido compro-bando el valor de la suma de vericación, y si éste valor está corrompido, si descarte elmensaje. Por ésta misma razón, la tasa de frecuencia de admisión de la telemetría se jaen 57 600 en lugar de 115 200 como se usa para el enlace por USB. Cuanto menor sea latasa, menos errores registrará, aunque la comunicación se hace más lenta. En teoría, latasa 57 600 se ha calculado para distancias de algo más de un kilómetro y medio con loque debería ser suciente para la mayoría de aplicaciones de vuelo.



Ahora bien, vamos a jarnos en los parámetros que nos interesan en cada paquete:

• El identicador de sistema (System ID). Se reere a la fuente emisora (comopuede ser Mission Planner) que envía el mensaje, ya sea por telemetría o por USB.El software hace comprobaciones regularmente para vericar que es el mensaje loestá leyendo el destinatario correcto.• El identicador de componente (Component ID). Hace referencia al subsiste-

ma dentro del propio sistema principal. Nótese que en la versión actual de Ardupilotno se distinguen subsistemas por lo que no se hace uso de éste identicador.• El identicador del tipo de mensaje (Message ID). Expresa la naturaleza

del mensaje.• La carga del mensaje (payload). Es lo que contiene el mensaje real.

Los paquetes de datos transmitidos por MavLink tienen siempre el mismo número debytes, aunque nos interesa realmente es el contenido de la capacidad del mensaje, juntocon el identicador del tipo de mensaje, para saber qué está transmitiendo. A continuaciónexplicaremos los pasos que sigue el software para interpretar cada mensaje MavLink :

Se llama al método `handlemessage(msg)', el cual lee el identicador de sistema delmensaje para vericar si el sistema receptor es el correcto. Nótese que todo sistema que secomunique usando MavLink tendrá obligatoriamente un identicador de sistema. Por ellocualquier mensaje enviado por la APM contará con el mismo identicador de mensaje.

1. Se llama al método `handlemessage(msg)', el cual lee el identicador de sistema delmensaje para vericar si el sistema receptor es el correcto. Nótese que todo siste-ma que se comunique usando MAVLink tendrá obligatoriamente un identicadorde sistema. Por ello cualquier mensaje enviado por la APM contará con el mismoidenticador de mensaje.

2. Se extraen los datos de la capacidad del mensaje y se resitúan en un paquete. Los pa-quetes son estructuras de información basadas en un tipo especíco de información.Llegados a éste punto dejaremos de utilizar el término mensaje ya que representaun formato que el software ya no volverá a usar en el resto del proceso. El contenidode éstos nuevos paquetes es fundamentalmente la información bruta que contenía lacapacidad del mensaje.

3. Los paquetes se amoldan a una estructura de datos apropiada. El tipo de estruc-tura dependerá del tipo de la información que transmite. Por ejemplo, hay muchasestructuras de datos recopiladas según la actitud, GPS, canales RC, etc. Esto sir-ve para agrupar mensajes de función similar para lograr una estructura modulary comprensible. Éstas estructuras son completamente idénticas sean cuales sean elemisor y el receptor.

4. Una vez tenemos los datos agrupados en una estructura apropiada, se vuelve acomprobar el anterior identicador de mensaje y si es correcto se procesa el contenidodel paquete almacenándolo en la memoria EEPROM, concluyendo la interpretacióndel mensaje.



Finalmente, todos los identicadores de mensaje tienen la sintaxis `MAVLINK_MSG_ID_<nombre>'. Conocer los tipos de identicadores nos puede llevar a entender correcta-mente la naturaleza de los mensajes que se envían por MAVLink, por lo que vamos aproceder a listar a continuación los tipos de identicadores de mensaje más importantesque se pueden encontrar los mensajes transmitido por MAVLink en el Anexo 1.

4.10. Código crítico

Ahora que tenemos una comprensión general del rmware de Ardupilot, podemosentender lo que tenemos que modicar para adaptar el software a nuestro modelo demonocóptero.

En la librería llamada `APMcong.h', podemos encontrar primero la siguiente adver-tencia:

// I f you used to d e f i n e your CONFIG_APM_HARDWARE s e t t i n g here ,i t i s no l onge r

// va l i d ! You should switch to us ing a HAL_BOARD f l a g in yourl o c a l c on f i g .mk.

Esto no debería sorprendernos ya que en la sección de la implantación del rmwarese explica cómo tenemos que modicar el archivo `APMcong.h' para que se adapte alhardware de la APM. Lo que nos interesa es lo que aparece justo después:

#de f i n e FRAME_CONFIG QUAD_FRAME/∗ opt ions :∗ QUAD_FRAME∗ TRI_FRAME∗ HEXA_FRAME∗ Y6_FRAME∗ OCTA_FRAME∗ OCTA_QUAD_FRAME∗ HELI_FRAME∗ SINGLE_FRAME∗ COAX_FRAME∗/

Aquí se nos muestra la conguración de los distintos tipos de frames al que pode-mos adaptar el código de ArduCopter. En un sentido físico, el frame se reere al modelotangible del vehículo, entrando cada uno en una categoría distinta (helicóptero, aero-plano, cuadracóptero, etc). Cada uno de estos modelos tiene un equivalente software quepermite adaptar correctamente el rmware a la distribución de motores, llamada normal-mentemotor mixing. Como ya hemos visto anteriormente, la morfología estandarizadaque más se acerca a nuestro modelo de monocóptero es el modelo coaxial, ya que aunqueel coaxcóptero emplea alerones en lugar de desplazar su centro de gravedad, la correspon-dencia entre los grados de libertad y su movimiento en 3 dimensiones es la misma, tantoen el número de motores como en el movimiento que provoca cada uno.



Los coaxcópteros realmente poseen una combinación de 4 alerones pero en este modelose controlan 2 a 2 con un solo par de grados de libertad. Por tanto, el tipo de frame quedeberemos seleccionar es el `COAX_FRAME', que es el que se ha implementado pensadopara coaxcópteros con alerones.

El frame que se seleccionemos jugará un papel esencial ya que será el responsable dedecidir qué secciones del código se acceden de acuerdo a la distribución de los motorespropia del frame. En versiones superiores (3.5 y en adelante), la variable frame se convierteen un parámetro de los que se pueden modicar en cualquier momento desde la propiaestación de tierra. Todos los tipos distintos de frames son compatibles con la APM, aunquelos más ecientes resultan ser los correspondientes a cuadracópteros y helicópteros dentrodel modelo Copter.

En cualquier caso, los cambios provocados por el frame se reejan en la librería`AP_Motors', donde se encuentran las funciones que manejan la tasa de refresco a laque se da la actualización de las señales de los motores, o que establecen los valores mí-nimos de salida, o que facilitan una máscara de bits para diferenciar servos de motores, onalmente, las funciones que envían las órdenes de salida a los motores, diferenciando siestán desarmados o armados. Ésta última función es de un interés fundamental ya que esla responsable de enviar las salidas de los motores siguiendo el modelo coaxial.

// Hé l i c e supe r i o rmotor_out [AP_MOTORS_MOT_3] = _rev_yaw∗_rc_yaw .pwm_out +_rc_thrott le . radio_out ;

// Hé l i c e i n f e r i o rmotor_out [AP_MOTORS_MOT_4] = −_rev_yaw∗_rc_yaw .pwm_out +_rc_thrott le . radio_out ;

// Servomotor f r o n t a l_servo1 . servo_out = _rev_rol l∗_rc_rol l . servo_out ;

// Servomotor derecho_servo2 . servo_out = _rev_pitch∗_rc_pitch . servo_out ;

// Rec i b i r po s i c i one s_servo1 . calc_pwm ( ) ;_servo2 . calc_pwm ( ) ;

En éste trozo de código se obtiene la salida de los motores como la suma de las entradasde la radio junto con la corrección aplicada en el yaw por el sistema de control de actitud.La salida de los servos se corresponde simplemente con la corrección del control de actitud,de roll y pitch respectivamente para cada servo. Otra información importante referentea la disribución de los motores se puede congurar en la clase `AP_MotorsMatrix.cpp',en la cual se puede congurar lo que se conoce como motor mixing, que hace referencia aqué motor gestiona qué movimiento.



4.11. Implementación del rmware

4.11.1. Descarga del rmware

El rmware de Ardupilot es un proyecto de código abierto que se gestiona con laherramienta de control de versiones Git y se puede encontrar en los repositorios conacceso libre de Github. Por tanto, desde cualquier navegador web se puede acceder parahacer un clon en los archivos locales y así obtener una copia de la versión que se desee delcódigo. Cabe decir que en el repositorio se encuentra tanto el código correspondiente almodelo Copter, como el de Plane, Rover, Sub y Antenna Tracker. Sin embargo nosotrosnos centraremos en el primero puesto que es el modelo que nos interesa.

Para descargar el código fuente primero será necesario instalar el cliente de Git enel ordenador local, y clonar el archivo maestro que se encuentra en el repositorio deGithub. Seguidamente es necesario realizar la build del programa utilizando ya dos posiblesmétodos, el primero utilizando make y el segundo empleando la herramienta Waf. Parala lograr la carga del rmware en nuestro hardware (APM 2.8) se ha seguido el primermétodo pero procederemos a explicar los dos ya que los desarrolladores de Ardupilot hananunciado la inminente transición a Waf para gestionar el rmware.

4.11.2. Método Make

Lo primero que habrá que abordar es la descarga de los archivos del código fuenteen su versión 3.2.1 puesto que es la última versión con el modelo Copter que soportanuestra APM 2.8. Nada más realizar el clone del repositorio de Github se puede observarque los archivos descargados consisten en un conjunto de archivos `.cpp' y librerías `.h'que constituyen el código fuente del programa. Para poder crear la build preparada paranuestra placa, es necesario realizar unas cuantas conguraciones previas en la consola degit, situándonos en el archivo con el código fuente descargado:

g i t c on f i g −−g l oba l core . a u t o c r l f fa l seg i t submodule update −− i n i t −−r e c u r s i v eg i t checkout ArduCopter−3.2.1

Es posible que el comando `git submodule update init' falle y no se puede ejecutarporque los submódulos están registrados con la dirección en `ssh' en lugar de la `https',lo cual da problemas en el acceso al repositorio de Git. La solución a éste problema vieneintroduciendo:

g i t submodule f o r each −−r e c u r s i v e ' g i t submodule syncg i t submodule update −−r e c u r s i v eg i t submodule update −− i n i t −−r e c u r s i v e .

Ésta sincronización provoca que se use la dirección http para buscar el repositorio,de forma que no haya conictos en el acceso, y ésta vez sí que nos permite introducir elcomando si nos dio problemas anteriormente. Por otro lado, se ha utilizado una versiónmodicada de Arduino adaptada para poder entender y compilar ciertas librerías delcódigo que se puede encontrar en [36].



Además será necesario instalar la herramienta PX4toolchain que se puede encontraren [37]. Con esta herramienta nos interesa abrir shell propia de ésta herramienta, llama-da PX4Console, navegar hasta el directorio donde se encuentra nuestro código fuente yejecutar el siguiente comando de forma que nos permita congurar los parámetros con loscuales crearemos la build del programa:

make con f i gu r e

Después de hacer esto, nos encontramos con que se ha creado un archivo `cong.mk' enel cual tendremos que especicar la ruta del directorio en el que tenemos nuestra versiónmodicada de Arduino que nos hemos descargado previamente. Esto quedará de la forma:

ARDUINO = C:/ arduino −1.0.3−windows

Una vez tenemos esto ya estamos listos para ejecutar la orden desde la Shell dePX4Console:

make apm2

Esta operación traduce los archivos a los correspondientes `.pde' y .h propios de unproyecto en Arduino, lo cual nos permite visualizar el proyecto usando la IDE de Arduino.

Además de la conversión de los archivos, éste método genera un archivo binario quecontiene el rmware en forma de `.elf' . La interfaz de vuelo Mission Planner no es capazde leer éste tipo de archivo para subirlo a la placa así que será necesario convertirlo a otroarchivo binario `.hex', lo cual se puede lograr mediante el siguiente comando:

avr32−objcopy −O ihex myf i l e . e l f my f i l e . hex

Este archivo sí que es cargable en la placa desde la interfaz de Mission Planner, locual nos otorga una primera versión del código compilable que responde en nuestra placa.

Dentro de la interfaz de Mission Planner es posible acceder a un conjunto de paráme-tros referentes a una gran variedad de opciones de conguración del vehículo. Todos éstosparámetros se pueden modicar desde la pestaña de conguración de Mission Plannersin necesidad de alterar el código del programa. Entre las distintas opciones que ofrece,muestra la posibilidad de cambiar el FRAME que tiene asignado. Éste parámetro es degran importancia puesto que es el que va a dictar la asociación de las salidas de acuerdoal modelo de vehículo elegido. Según la guía de Ardupilot[38] , el valor que se le debe daral parámetro para que mimetice el modelo coaxial, es 9. Sin embargo, pronto compro-bamos que después de ejecutar la orden de escribir (guardar) los parámetros cambiadosen la placa, no se encuentra ningún cambio respecto al modelo que tuviésemos cargadopreviamente (que probablemente sería el modelo de helicóptero, que es el que aparece pordefecto cargando el rmware Copter).

Esto se debe a que sólo desde la versión de Copter 3.5 (que no es compatible conla APM), se encuentran todos los modelos de vehículo fusionados en el mismo rmware,y por tanto permite la selección del modelo en el estado post-complación. En nuestrocaso, como trabajamos con la versión 3.2.1 de ArduCopter, no podemos modicar ésteparámetro después de compilar el programa así que hay que hacerlo desde el código yluego subirlo modicado a la placa. Situándonos en el rmware en Arduino, abrimos lalibrería `APM_Cong.h' y lo primero con lo que nos encontramos es el mensaje de alertaque hemos comentado en la sección anterior 4.10.



Ignoramos éste mensaje puesto que en el momento de hacer la build del programaya modicamos el archive cong.mk para compatibilizar el rmware con la APM. Se-guidamente nos encontramos con la posibilidad de denir el modelo con el que se estácompilando el programa. El rmware está diseñado de forma que la asociación de lassalidas se hace de acuerdo al modelo que esté seleccionado en ÀPM_Cong.h'. Basta condejar escrito lo siguiente para que el resto del programa sepa qué asociación de motoresseguir y ejecutar los bloques de código acorde a ello:

#define FRAME_CONFIG QUAD_FRAME

Cuando le damos a compilar el programa nos encontramos para empezar con un men-saje de error que nos informa de que no se reconocen las librerías (ninguna de las libreríascomunes para todos los modelos de Ardupilot). La solución a éste problema es sencilla-mente cerrar y volver a abrir Arduino. Resulta que la primera vez que especicamos laruta del sketch, la IDE no identica correctamente la ruta de las librerías, pero para lapróxima vez que lo abramos estando ya especicado el problema queda resuelto.

Después de hacer esto sí que se logra la compilación del programa. Sin embargo, loque no se consigue es subir el programa a la placa. Justo antes de anunciar el fallo en lacarga, nos salta un warning con el siguiente mensaje:

avrdude . conf : programmer type must be wr i t t en as ' id_type '

El mensaje hace referencia a un archivo que se encuentra en los archivos de la ver-sión modicada de Arduino, que tiene algunos errores que tienen que ser corregidos. Enconcreto, el archivo defectuoso se encuentra en la ruta:

/ usr / share / arduino /hardware/ t o o l s /avrdude . conf

Esconder (renombrar) el archivo tal como se sugiere en foros referentes al problemano lo soluciona ya que es un archivo necesario para la operación de carga en la placa,así que será necesario arreglar lo que hay defectuoso dentro del archivo. Una vez tenemosel archivo abierto, todo lo que tenemos que hacer es colocar comillas en el identicadordel programador señalado, pero cuando volvemos a intentar cargar el programa, nos en-contramos con que nos vuelve a saltar el mismo mensaje de error con referencia a otralínea con otro programador dentro del mismo archivo àvrdude.conf'. Resulta que hayuna hilera de aproximadamente un centenar de líneas con los programadores mal escritosdentro del archivo a los que deberemos añadir las comillas para que los reconozca la IDE.Una vez solucionamos el tema de los programadores, el compilador nos informa de quehay una errata más contenida en àvrdude.conf' la cual se identica y se corrige para quequede de la siguiente forma:

desc = "Direc t AVR p a r a l l e l Access cab l e " ;

Una vez tenemos esto cambiado nos encontramos con que la carga del programa ahorasí se efectúa con éxito en la placa. Y con esto concluye el proceso de cómo cargar elrmware en la placa con el frame coaxial que hará que nuestros motores se muevan deforma acorde a la tipología del monocóptero.



4.11.3. Método Waf

Antes de comenzar con la explicación de cómo proceder para elaborar la build delprograma con Waf, es necesario precisar que el método no es compatible con la placaAPM, que es la que estamos usando en éste proyecto. Esto se debe a que el método sóloes válido para versiones superiores a la 3.5 de Ardupilot. Esto puede llevar a la pregunta depor qué se está va a detallar un método que no es válido para el hardware de éste proyecto.La respuesta a ello es que si bien en éste proyecto se ha conseguido acceder, modicar ycompilar una versión del rmware de Ardupilot en una placa APM, la realidad es que sehan encontrado serios impedimentos impuestos por el hardware de la placa para lograruna ejecución fácil y completa del código.

Si se desea continuar con éste proyecto en líneas futuras es muy probable que loconveniente sea dejar de depender de las limitaciones de la APM y pasar a usar otrasplacas con más capacidades como puede ser la Pixhawk. En las versiones más modernasdel rmware disponible para éstas placas, el método de compilación pasa a ser el que seva a explicar a continuación.

Como se ha expuesto en éste apartado, el código de Ardupilot está actualmente enplena transición para mover su modo de construir la build a una herramienta llamadaWaf [39]. Este programa es un build system que según su propio manual corresponde ala descripción: Es un trozo de software que ayuda a automatizar los procesos en unproyecto de software, enfocándose en particular al procesamiento del código fuente. Laintención detrás del uso de éste sistema es mermar el efecto de la evolución constantede los lenguajes de programación y de las soluciones que resultan de ellos, mediante lapredilección de un software en el build system generalista frente a uno especializado queamenaza con quedarse rápidamente obsoleto. Los objetivos que Waf alega lograr son:

• La ejecución no redundante de procesos cuando no ha habido cambios.• La puesta en marcha de compiladores y scripts como procesos iguales cuando lo son.• La ejecución de procesos en paralelos por motivos de eciencia.• Facilitar la ejecución de testeo de software agilizando la tarea.• Proveer ayuda y herramientas útiles para los compiladores más usados.

Además,Waf es un sistema basado únicamente en Python, sin dependencia de softwareo librerías externas, sin denir un nuevo lenguaje y sin requerir un generador de códigopara crear las builds (`Makeles '). El programa se puede descargar desde su página webo se puede clonar desde su repositorio en Github. El script se ejecuta con un intérpretede Python (con versión superior a 2.5). Al ejecutarlo, se descomprime una librería en unchero oculto en el directorio del archivo. Esta carpeta debe tener permisos de escriturapara que el archivo Waf pueda descomprimir su librería. Puesto que el archivo Waf esun script de Python, se puede ejecutar simplemente llamándolo con `python':

$ python waf

Una vez tenemosWaf instalado, tenemos que preparar la generación de la build para laplaca que deseamos, mediante el comando `congure board' La lista de placas disponiblespara esta orden es la siguiente:



. / waf c on f i gu r e −−board bebop −−s t a t i c

. / waf c on f i gu r e −−board edge

. / waf c on f i gu r e −−board min i lu r e

. / waf c on f i gu r e −−board navio2

. / waf c on f i gu r e −−board px4−v1



. / waf c on f i gu r e −−board fmuv3


. / waf c on f i gu r e −−board fmuv4

. / waf c on f i gu r e −−board skyviper−v2450

. / waf c on f i gu r e −−board s i t l

. / waf c on f i gu r e −−board s i t l −−debug

Nótese que la APM no se encuentra entre las placas disponibles para la conguraciónde la build. Esto se debe a que tal y como hemos dispuesto antes, la placa no es compatiblecon el protocolo de compilación con Waf. Además, el comando `congure' dispone de unaopción `debug' que coloca banderas para facilitar la operación de debugging.

Es posible limpiar (borrar) los objetos creados generados por la build con los siguientescomandos. El primero mantiene la información almacenada en el `congure' mientras queel segundo la elimina junto con el resto de datos de la build.

. . / waf c l ean

. / waf d i s t c l e a n

Una vez se tiene construida la build con la conguración deseada,Waf soporta tambiénla carga en la placa. El método de carga es ligeramente distinto según la placa que se quierautilizar. Para las placas Pixhawk el comando a utilizar es el siguiente:

. / waf −−t a r g e t s bin/ arducopter −−upload

Para placas basadas en un sistema operativo Linux es necesario especicar la placa,así como su dirección IP en la etapa de la conguración:

/waf c on f i gu r e −−board <placa> −−rsync−dest root@<IP>

Después de establecer la conguración se ejecuta el comando de carga que se ha es-pecicado para la Pixhawk y así se consigue subir el programa en una placa con sistemaLINUX. En ésta explicación se han contenido los comandos más útiles en la compilacióny carga del programa, pero hay muchos más que pueden resultar útiles si se desea utili-zar Waf con nes menos limitados. La lista de comandos y opciones construidos en Wafpuede consultarse en el comando de ayuda de Waf, así como algunos consejos prácticosañadidos por Ardupilot :

/waf −−help


Capítulo 5

Estación de tierra Mission Planner

5.1. Introducción

Mission Planner es la interfaz más usada en aplicaciones de aeromodelismo que sirvede lo que se conoce como estación de tierra. Las estaciones de tierra sirven como puntode enlace entre el usuario y el vehículo para realizar toda operación previa al vuelo delvehículo y para su monitorización durante el mismo. Está desarrollada por Ardupilotpara sus modelos de Plane, Rover y Copter y es completamente open source para elsistema operativo Windows. Mission Planner se puede utilizar como una herramienta deconguración de diversos parámetros o como un sistema de control suplementario paravehículos autónomos.

Figura 5.1: Comunicación con el vehículo.

Entre las distintas funcionalidades de Mission Planner, se encuentran:

• La carga facilitada del rmware correspondiente según el modelo en la placa. (Des-afortunadamente, no se incluye el modelo coaxial, lo cual invalida ésta opción paranuestro caso con el monocóptero).• La conguración y ajuste de los parámetros del vehículo.• El registro de datos de vuelo que permite el análisis y depuración de los mismos,

incluyendo tanto los registros `dataash' como los registros de telemetría.• Un simulador de vuelo que recrea los modelos de vehículos más comunes (entre los

cuales el nuestro no se encuentra)• La monitorización en directo del estado del vehículo por enlace de telemetría.• Canal 6: Opcional, cámara montada

61

CAPÍTULO 5. ESTACIÓN DE TIERRA MISSION PLANNER

La conexión de Mission Planner con la placa controladora a bordo puede hacerse bienpor enlace USB (tasa de tansmisión baud rate igual a 115200), bien por telemetría (tasa detransmisión igual a 57600). En cualquier caso, dicha comunicación se establece utilizandoel protocolo I, el cual aparece explicado en la correspondiente sección del I de Ardupilot.En caso de que falle la conexión, también es conveniente comprobar que el puerto estácorrectamente seleccionado en I, y si estamos usando el enlace por telemetría alimentandola placa con un ordenador, es importante deshabilitar el puerto correspondiente en eladministrador de dispositivos de I, o en caso contrario la comunicación fallará anunciandoque no se detectan los latidos (heartbeats) que inician la comunicación.

Los siguientes apartados van a cubrir las explicaciones de las pestañas más importantesde la interfaz de Mission Planner, que son `Flight Data', `Initial Setup' y `Cong/tuning '.Aunque no son las únicas pestañas del programa son las que vamos a desarrollar ya queel resto no ha tenido ningún impacto en la elaboración de éste trabajo.

5.2. Flight Data

La pestaña `Flight Data' de Mission Planner muestra información relativa al estadoactual del vehículo, y es visible en todo momento durante el vuelo del mismo. Contienemucha información útil que nos informa de las lecturas de todos los sensores, incluyendoel GPS si lo tenemos habilitado. Presenta un HUD, que es el que se puede ver explicadoen la siguiente imagen, un conjunto de subpestañas que explicaremos más adelante y unmapa que funciona con Google Earth que muestra la ruta establecida para una misión denuestro vehículo.

Figura 5.2: HUD de la pestaña `Flight Data'[40].



Debajo del HUD podemos encontrar una serie de sub-pestañas que seleccionamos paravisualizar lo que aparece debajo. En la parte inferior de la ventana con el mapa podemosver dos opciones, una llamada 'Auto Pan' que permite que la cámara del mapa sigaautomáticamente la trayectoria del vehículo, y otra que no tiene que ver con el mapa ensí, la opción llamada `Tuning '. Ésta opción resulta de gran interés puesto que permitevisualizar cualquiera de las variables que puede enviar la telemetría en forma gráca. Estoresulta muy conveniente cuando queremos analizar la evolución de una variable especícaen un vuelo. Con esto en mente vamos a explicar brevemente las opciones que nos dan enlas pestañas inferiores:

• Quick. Proporciona una vista rápida y fácil de la altitud, velocidad en tierra, ve-locidad en tierra, distancia hasta el siguiente punto de ruta, ángulo de guiñada,velocidad vertical y la distancia hasta el punto de partida.• Acciones. Permite mandar al vehículo una serie de órdenes como cambiar el modo

de vuelo o cambiar los puntos de ruta.• Pre-ight. Permite acceder una serie de parámetros relativos a las vericaciones

que hace se hace antes de levantar el vuelo.• Indicadores. Muestra de forma ordenada manómetros referentes a la altura, orien-

tación y velocidades del vehículo.• Estado. Muestra la totalidad de las variables observables del vehículo a través del

enlace por telemetría.• Servo. Permite modicar los PWM asociados a servos auxiliares del vehículo.• Logs de Telemetría. Permite acceder a los registros de telemetría que se graban

automáticamente al realizar un vuelo.• DataFlash Logs. Da acceso a los registros que se almacenan en el chip Dataash,

que no como explicamos en otra sección no está disponible en nuestra placa.• Scripts. permite subir un script para que se ejecute en Mission Planner.• Messages. Muestra los últimos mensajes que se han enviado o recibido con la placa

a través de MAVLink.• Payload Control. Sirve para reajustar la inclinación del vehículo durante el vuelo

en el caso que transporte una carga.

Cabe destacar que de todas las opciones que hemos listado, las que resultan de másutilidad son la pestaña de Estado, que aporta una información muy completa sobre todolo que está cambiando en el vehículo, y los Logs de telemetría, que ayudan a visualizar laevolución de todas éstas variables.

5.3. Initial Setup

Esta pestaña de Mission Planner cuenta con varias secciones referentes a las laboresprevias a la realización del primer vuelo con un vehículo. Aunque algunas de ellas sepueden suplir por otros medios, éstas secciones resultan fundamentales y el vehículo nopodrá levantar el vuelo sin pasar por ellas. Aunque algunas de ellas no están disponiblessi no está conectada la placa a Mission Planner. Las opciones que se ofrecen cuando sítenemos conectada la placa son:



• Install rmware. Ofrece la posibilidad de cargar el rmware de los modelos devehículos más comunes de Ardupilot. Como se ha comentado antes, el modelo coaxiales un frame muy especíco del modelo Copter por lo que no podremos cargar nues-tro rmware utilizando ésta opción.

• Wizard. Es una opción poco recomendable ya que lleva al usuario por todo el pro-ceso de instalación de rmware y calibrado de sensores sin permitir elegir métodosalternativos como la carga de un rmware propio. Por éstos motivos, no resulta útilemplear ésta función.

• Mandatory Hardware. Abre un desplegable de opciones de calibración y ajus-te necesarios para que el vehículo sea capaz de volar. Lo componen las siguientesfunciones:

• Frame type (Ignoramos ésta opción puesto que sólo es válida para versionessuperiores de Ardupilot).• Compass : Calibración de la brújula.• Accel Calibration: Calibración del acelerómetro del vehículo.• Radio Calibration: Calibración de la recepción de las entradas de la emisora

radio-control• Flight Modes : Conguración de los modos de vuelo asociados.• Fail-Safe: Mecanismo que decide qué hacer si se pierde la conexión de MissionPlanner con el vehículo.

Los procesos de calibración de sensores se explicarán con más detalle en otra sec-ción del trabajo ya que resultan imprescindibles para que el vehículo levante el vuelo.

• Optional Hardware. Otro desplegable de opciones de hardware que pueden resul-tar convenientes, pero no son de una importancia fundamental. Entre ellas destaca-mos dos de ellas que resultan útiles en otras partes del trabajo: la opción Sik Radioque permite visualizar los parámetros actuales de la telemetría y la opción MotorOutputs que muestra unas barras que representan las salidas de PWM deseadas enfunción de las entradas que se introduzcan de la emisora.

5.4. Cong/Tuning

En el menú de la pestaña `Cong/Tuning ' encontramos una serie de opciones de con-guración relativas al comportamiento en vuelo del vehículo, y lo que es más importante,nos da acceso a la lista completa de parámetros que nos permite modicar cualquierparámetro congurable desde Mission Planner.

La mayoría de estos parámetros ya cuentan con un valor por defecto deseable al cargarel rmware, pero muchos de ellos requieren ser ajustados para que el vehículo funcionecorrectamente. Entre los parámetros congurables se destacan las constantes de los PIDsdel vehículo (en el modelo Copter hay un PID para cada ángulo roll, pitch y yaw) paralos que se ofrecen varias formas de ajuste. Cabe decir que Mission Planner cuenta con unmodo de ajuste automático de los PIDs que explicaremos más adelante.



• Flight Modes.

Permite asociar los modos de vuelo a los canales auxialiares a elección del usuariopara el modelo Copter. Aunque existen un total de 20 modos de vuelo, solamenteunos pocos de ellos se utilizan de forma normal, y son los que vamos a explicar acontinuación. Los modos de vuelo se asocian a una frecuencia, la cual correspondeal canal que se le asocie visible en la pantalla de calibración de las entradas de laemisora.

• Stabilize: Es el modo de vuelo más básico y menos restrictivo. Solamente operaun control realimentado en el roll y el pitch, dejando el resto de grados delibertad en cadena abierta.• AltHold : Similar a Stabilize pero mantiene la altitud del vehículo.• Loiter : Similar a AltHold pero también mantiene la posición gracias a las coor-

denadas GPS.• RTL: Ordena al vehículo retornar al origen (punto de despegue).• AUTO : Ordena al vehículo seguir los puntos de ruta establecidos en la misión.• Autotune: Entra en modo de calibración de PIDs automática.• Brake: Provoca que el vehículo se detenga de inmediato.

Los modos de vuelos que requieren conocer la posición del vehículo necesitan teneracceso a un GPS que, en el momento de la elaboración de éste trabajo, no estádisponible. De tenerse es conveniente comprobar que se enciende en la placa el LEDcorrespondiente a la indicación de que está activado el `GPS lock '.

• GeoFence.

Esta opción habilita un volumen cilíndrico centrado en el punto de despegue queimpone unos límites circulables para el vehículo. Este sistema evita que el vehículoacabe volando demasiado lejos del punto de partida haciendo que se pare en loslímites estipulados, los cuales se pueden congurar desde ésta sección en MissionPlanner. También permite la opción de deshabilitarlo si no interesa usarse, o deter-minar la acción que se realiza cuando se sobrepasan los límites del cilindro.

• Basic Tuning.

En ésta opción se facilita un ajuste muy básico y limitado de los reguladores PID.En él se proporcionan 3 barras de ajuste:

1. La primera ofrece un control proporcional (tipo P) del tanto el roll como elpitch del vehículo (éstos dos grados tendrán un ajuste muy parecido)

2. La segunda regula el throttle necesario para mantener la altura estática en elaire.

3. La tercera ajusta sensibilidad de la ascensión del vehículo, también llamadatasa de ascensión.

• Extended Tuning.

Aquí se permite realizar un ajuste mucho más completo de las variables de losreguladores PID (Figura 5.3). Nos da acceso a las 3 constantes de cada uno de losreguladores, lo cual proporciona muchas más opciones para realizar el ajuste.



Además, permite la calibración de otras las características presente en otros modosde vuelo como la corrección de la posición en Loiter o la velocidad de crucero al esta-blecer una ruta. Entre las opciones que posee cabe destacar la opción de seleccionarel modo de vuelo Autotune que permite depurar las variables de los reguladores PIDuna vez el modelo ya es mínimamente estable en el modo de vuelo AltHold.

Figura 5.3: Reguladores PID en 'Extended Tuning '.

• Listas de parámetros.

Las siguientes 3 opciones encontradas, que se reeren a Standard Params, Full Pa-rameter List y Full Parameter Tree agrupan diferentes visualizaciones del mismoconjunto de parámetros a los que se le puede dar un valor desde Mission Planner através del protocolo MAVLink para controlar el comportamiento del vehículo. Éstosparámetros se almacenan en la memoria permanente del vehículo. El acceso a éstosparámetros es de esencial importancia ya que reduciéndolo a un bajo nivel, es todolo que hace Mission Planner, aunque posee interfaces muy grácas, en el fondo loque realiza son cambios en la conguración de éstos parámetros que luego se puedenver claramente listados en ésta sección.

Además, el programa también permite guardar una conguración especíca de losparámetros en un archivo externo. Esto se convierte en una característica muy va-liosa en el momento que queremos hacer un reseteado completo de los parámetros(devuelve todos los parámetros a sus valores predeterminados), lo cual ocurre siem-pre que hemos modicado un valor que no debíamos. Todos los parámetros tienenal lado pequeña descripción que informa de los valores habituales que suelen tener.Cuando modicamos manualmente uno de los parámetros aparecerá subrayado encolor verde, pero no se harán efectivos los cambios en la placa hasta que no hagamosclick en `Write Params '. Esta función no tiene ningún mensaje de conrmación porlo que después de modicar los parámetros resulta conveniente desconectar y volvera conectar la placa para cerciorarse de que se han efectuado los cambios.



Finalmente, es conveniente aclarar que la lista de parámetros se genera automática-mente a partir del código fuente del vehículo, lo cual hace que cada rmware poseauna colección propia parámetros congurables. La lista de parámetros es considera-blemente extensa por lo que gura en los anexos de este documento.


Capítulo 6

Calibración de los componentes devuelo

6.1. Acelerómetro

La calibración del aceletrómetro es un proceso obligatorio para que el rmware permitael armado de los motores del vehículo. Es decir, si no se efectúa, el rmware instalado nopermitirá que el vehículo alce el vuelo lógicamente por cuestiones de seguridad. Consisteen registrar una serie de orientaciones del vehículo según va indicando en software deMission Planner para guardar referencias que luego utiliza el sistema de control de actituddel rmware para decidir las señales de salida apropiadas en los motores. El proceso esrelativamente rápido y sencillo y consiste en seguir los siguientes pasos:

1. Conectar la placa controladora a Mission Planner.2. Bajo la pestaña `INITIAL SETUP ', seleccionar `Accel Calibration' dentro del des-

plegable `Mandatory hardware'.3. Hacer click en el primero de los dos botones que tienen escrito `Calibrate Accel ', ya

que es el que ofrece la calibración en torno a 3 ejes.4. Mission Planner requerirá que se posicione el vehículo en una serie de posiciones

guardando en cada una la lectura de la orientación del vehículo. Como algunas deéstas posiciones tiene un nombre que puede inducir a error, se facilita a continuaciónuna imagen que ayuda a entender éstas posiciones para el caso de un tricóptero, delas cuales podemos deducir las posiciones en las que se debe situar el monocóptero.

Figura 6.1: Posiciones de calibración.[41]

5. Una vez hemos registrado todas las orientaciones, seleccionamos `Click When Done'y se nos mostrará un mensaje informándonos de que la calibración ha sido exitosa.

69

CAPÍTULO 6. CALIBRACIÓN DE LOS COMPONENTES DE VUELO

Nótese que es posible fallar el proceso de calibración si Mission Planner detecta quela orientación registrada en alguna de las posiciones no resulta coherente con el resto. Esimportante tener en cuenta que la calibración del acelerómetro se efectúa para especicarlas referencias en base a las que se hará la lectura de la orientación, y no sirve pararedenir completamente los ejes de referencia de la orientación del vehículo si por ejemplose desea posicionar la placa de lado en lugar de estar plana boca arriba, como se sueleencontrar en la mayoría de multicópteros. Éste último proceso de redenición de ejestambién se ha realizado en éste trabajo, pero aparece explicado más adelante, en susección correspondiente.

6.2. Emisora Radio Control

Los transmisores RC son los dispositivos que emplea el usuario para controlar el movi-miento del vehículo y su orientación. El modo Copter, que es en el que centramos nuestrotrabajo, establece éste control en torno a las variables roll, pitch, yaw y throttle. Cadauno de éstos movimientos están mapeados en los canales correspondientes del transmisory comunican las señales que nalmente recibe el software. La conguración estándar esla que se ha utilizado en el desarrollo del trabajo, y es la que se puede visualizar en laFigura 6.2.

Figura 6.2: Conguración estándar de la emisora[42].

Siguiendo ésta distribución, el orden de conexión de los canales de acuerdo a cómo lostiene asignados el código de Copter es el siguiente:

Canal 1: RollCanal 2: PitchCanal 3: ThrottleCanal 4: YawCanal 5: Opcional, modos de vueloCanal 6: Opcional, cámara montada



Antes de lanzarse a realizar la calibración de la radio, es necesario comprobar que lasseñales salientes de la emisora se corresponden con la que aparece en el esquema que seha proporcionado, lo cual puede implicar la reprogramación del layout de la emisora RC.Una vez se ha comprobado que la emisora RC está correctamente programada, deberemostomar ciertas precauciones antes de calibrar la emisora.

Se recomienda tener la batería desconectada (alimentando la placa únicamente porUSB) y retirar si es posible las hélices de los motores. Además, será necesario centrar losajustes (trim) de la emisora. Si no están centrados, la calibración se efectuará en torno alajuste actual lo cual es poco recomendable. Aclarado ésto, el proceso de calibración de laemisora es el siguiente:

1. Conectar la placa a Mission Planner por USB.

2. Bajo la pestaña `INITIAL SETUP ', seleccionar `Radio Calibration' dentro del des-plegable `Mandatory hardware'. Hacer click en `OK '.

3. Desplazar los sticks de la emisora hasta todos sus límites de carrera. Se deberíapoder observar cómo se establecen unos límites rojos sobre las barras de calibraciónen Mission Planner. Nótese que con la emisora utilizada, el límite inferior del roll nose mantiene jo cuando mantenemos el stick correspondiente al mínimo, lo cual sedebe a un defecto de la propia emisora y sólo podemos tener cuidado de no mantenerel roll al mínimo cuando volemos el vehículo.

4. El proceso anterior se repite para todos los otros modos de vuelo para los cuales sedesee calibrar la emisora.

5. Tras asegurarnos de que todos los límites están correctamente establecidos, seleccio-namos `Click when Done' y se nos mostrarán los valores numéricos en una ventanaa modo de resumen de la calibración. Los valores normales de límites inferior ysuperior son respectivamente 1100 y 1900.

6.3. Brújula

La brújula del sistema debe su funcionamiento a un magnetómetro interno en la APMque indica la posición del norte respecto a la orientación actual del vehículo. Igual que elresto de sensores, requiere una labor de calibración, aunque la primera vez que se conecta,la interfaz de Mission Planner ya realiza automáticamente una labor de precalibración,dando unos valores de partida que no se alejan demasiado de los valores de referenciaóptimos.

Se recuerda también que aunque la placa APM cuenta con una brújula interna propiaque es la que se ha utilizado en el desarrollo de éste trabajo, se suele aconsejar utilizaruna brújula externa, sobretodo si se posiciona la placa cerca de las baterías donde es muysusceptible a interferencia magnéticas.

Aclarado ésto, existen dos métodos de calibración referentes a la brújula, el primero esel método estándar llamado Oboard Calibration (también llamado Live Calibration),el cual se efectúa desde la estación de tierra.



El segundo se llama Onboard Calibration, se realiza sobre la propia controladora devuelo y resulta más efectivo que el Oboard Calibration. Sin embargo, éste último métodosolamente es válido para versiones de ArduCopter 3.4 y superiores. Puesto que la versiónde nuestro rmware es la 3.2.1, nos varemos obligados a seguir el segundo método. Lospasos que se siguen para realizar la calibración Oboard Calibration son los siguientes:

1. Conectar la placa a Mission Planner por USB.2. Bajo la pestaña `INITIAL SETUP ', seleccionar `Compass Calibration' dentro del

desplegable `Mandatory hardware'.3. Se abrirá una ventana similar a la siguiente imagen que muestra 2 sistemas de ejes

cartesianos, cada uno de ellos representando los sistemas de referencia propios de lalectura del acelerómetro.

Figura 6.3: Posiciones de calibración.

Haciendo rotar al vehículo físicamente, vemos que se dibuja un rastro de puntos querepresentan el recorrido angular que ha seguido el vehículo. El objetivo que proponeésta calibración es llegar a pisar todos los puntos blancos distribuidos en el primersistema coordenado, con el rastro coloreado que vamos dejando. Aunque ésta labores factible realizarla al tacto, en seguida nos damos cuenta que hacer seguir elrastro coloreado por la ruta que deseamos no es tan intuitivo como puede pareceren un principio. La forma más ecaz de realizar esto es posicionando el vehículolentamente en todas las posiciones que se piden en la calibración del acelerómetroque se puede ver en la Figura 6.1.

4. Si seleccionamos la opción `Use Auto Accept ', el proceso de calibración se completaráde forma automática en cuanto se hayan registrado todas las posiciones necesarias.En caso contrario, habrá que terminarlo manualmente cuando consideremos que yahemos pisado todos los puntos blancos.

5. De una u otra forma, una vez quedan registrados los datos, aparecerá una ventanainformando que se han guardado los nuevos osets, los cuales aparecerán en verdeen la ventana principal.



En la versión de Copter 3.2.1, se considera que los osets (òset_x', òset_y', ò-set_z') tienen un valor aceptable cuando el módulo del vector de osets es inferior a600.

6.4. Variadores ESC

Los controladores electrónicos de velocidad (ESC ) son el componente electrónico pro-gramable capaz de hacer girar el motor bajo las instrucciones suministradas por el rm-ware. La mayoría de ESCs requieren una calibración para conocer los valores de PWMmínimo y máximo que puede enviar la controladora de vuelo, el cual es el tema queabordaremos en ésta sección.

Existen 3 procedimientos para calibrara los ESCs : el método All at once, el métodomanual y el método semi automático. Estos dos últimos no se suelen recomendar ya queimplican calibrar los ESCs uno a uno en lugar de todos a la vez. Aunque vamos a explicarlos tres métodos, el primero es el que se ha acabado usando por razones de comodidad yconveniencia. En todos los métodos de calibración y testeo listados se recomienda retirarlas hélices de los motores.

Antes de abordar los métodos de calibración, es conveniente entender que la calibraciónAll at once es un método que sencillamente permite que la placa comunique el throttleenviado por la emisora directamente a los ESCs, sin alterar la señal de acuerdo al controlde actitud. Si se alimenta a la APM durante éste proceso, conseguimos enviarle una mismaseñal a todos los ESC s al mismo tiempo. Mantener el throttle al máximo en el momentodel arranque supone la forma habitual de iniciar los ESCs en `modo programador' quepermite establecer los límites que denirán los valores mínimos y máximos posibles enbase a las señales recibidas por la emisora.

Método All at once.

1. Desconectar tanto el USB como la batería.2. Encender la emisora radio con el throttle puesto al máximo.3. Conectar la batería. Al cabo de unos segundos deberían escucharse 2 pitidos

claros emitidos por los ESCs.4. En cuanto la APM termine de iniciarse, se iluminarán alternativamente un

LED rojo y otro azul.5. Desconectar y reconectar la batería. A cabo de unos instantes se debería escu-

char un tono musical seguido de 2 pitidos claros.6. Después de los últimos dos pitidos, reducir el throttle al mínimo posible. Esperar

a oir los pitidos de conrmación.7. Subir levemente el throttle.8. Desconectar y reconectar la batería.9. Después de 4 segundos con throttle bajo, todos los motores debería girar es-

tando los ESCs calibrados.



Modo Semiautomático.

1. Conectar la placa aMission Planner y darle al parámetro 'ESC_CALIBRATION'un valor de 3.

2. Desconectar la batería y el cable USB de la placa.3. Reconectar la batería. Esperar a oír un tono de alarma. ESCs.4. Pulsar el botón de seguridad hasta que se ilumine un LED rojo jo.5. Esperar a escuchar un tono musical, seguido de dos pitidos claros, seguidos de

una serie de pitidos (el número de pitidos se corresponderá con el número deceldas que tenga la batería), y nalmente un pitido largo nal que indica quese han registrado los puntos extremos y el ESC ha quedado calibrado.

6. Desconectar la batería y repetir el proceso para el resto de ESCs.

Método Manual.

1. Conectar uno de los 3 cables del ESC seleccionado en el canal del receptorcorrepondiente a la recepción del throttle de la emisora radio.

2. Encender la emisora con el throttle al máximo.3. Conectar la batería. Esperar a oír los 2 pitidos.4. En cuanto se escuchen los pitidos, bajar el throttle al mínimo posible.5. Esperar a escuchar una serie de pitidos (el número de pitidos se corresponderá

con el número de celdas que tenga la batería), seguidos de un pitido nalque indica que se han registrado los puntos extremos y el ESC ha quedadocalibrado.

6. Desconectar la batería y repetir el proceso para todos los ESCs.7. Si parece que un ESC no ha sido calibrado correctamente, es posible que la

señal del canal de transmisión del throttle necesite ser invertida.

Una vez tenemos hecha la calibración, es conveniente realizar una labor de testeo paracomprobar que han sido calibrados correctamente. Esta labor se efectúa conectando elvehículo en modo el modo de vuelo estabilizar (`Stabilize Mode'), y después de armar losmotores, proporcionarle un ligero throttle al vehículo. Si los motores giran a la mismavelocidad ante una misma entrada, podemos concluir la etapa de calibración.

En caso de que no roten a la misma velocidad, es posible que los ESCs no esténapropiadamente calibrados, para lo cual la solución puede consistir en repetir el procesosiguiendo un método distinto. El método manual suele ser el más consistente de los 3 quese han descrito ya que es completamente independiente de la placa que es el elementoque puede resultar más problemático. Sin embargo, también puede ser un problema delrmware de los ESCs. El reajuste de dicho rmware queda explicado en otra sección deltrabajo. Finalmente, cabe decir que no todos los ESCs son compatibles con todas lasplacas, si todo falla es posible que el problema se reduzca a un conicto de compatibilidadde hardware.


Capítulo 7

Resolución de problemas

7.1. Pre-armado de motores

Problema: No es posible mover los motores con el rmware instalado. Se recibe unmensaje en la pantalla de información de vuelo de Mission Planner `Prearm: check mageld'.

Hipótesis: El rmware de Ardupilot no está permitiendo que se armen los motores.

El rmware de Copter cuenta con proceso de vericación que comprueba si todo estáen orden para dar el permiso de armar los motores por razones de seguridad, lo cualpuede servir para evitar fallos en las calibraciones en la conguración o en las lecturas delos sensores en medio del vuelo. Cuando Mission Planner nos aleta de que no es posiblearmar los motores, presentará un mensaje en la pantalla de vuelo, el cual en nuestro casoes `Prearm: check mag eld'.

Esta alerta aparece cuando el campo magnético que se detecta en la placa es un 35%superior o inferior al valor esperado. En términos numéricos, el valor de campo magnéticoque se espera recibir está en torno a 530, por lo que tanto si recibimos lecturas superiores a874 o inferiores a 185, nos saldrá ésta alerta. Dependiendo del lugar del planeta donde nossituemos éste campo magnético puede variar un poco, pero con éstos límites impuestos elproblema suele estar en la brújula.

La solución que se propone para éste problema suele consistir en recalibrar la brújulapuesto que es el elemento que está dando una mala lectura, sin embargo en nuestrocaso ésta alerta no viene como resultado de una mala lectura, sino que es un problemaintrínseco de la placa. Resulta que a diferencia de la mayoría de placas, la APM 2.8utiliza una brújula interna, lo cual puede dar problemas como el que se ha expuesto,sobre todo cuando situamos la placa cerca de un elemento que emita un campo magnéticoconsiderablemente fuerte como la batería.

A parte del uso de una brújula externa a la placa, la solución para los usuarios de unaAPM 2.8 consiste en desactivar la comprobación de seguridad de la brújula. Esto se hacedesde la pestaña de `CONFIG/TUNING ', en la ventana de `Standard Params ', dondepodemos hacer click en el desplegable, seleccionar `Skip Compass ` y presionar en `WriteParams ' para guardar el cambio efectuado.

75

CAPÍTULO 7. RESOLUCIÓN DE PROBLEMAS

Deshabilitar éstas opciones está desaconsejado pero no supone una gran pérdida cuan-do sabemos lo que estamos desactivando. La lectura de la brújula tiene un papel clave enla corrección de la dirección de la trayectoria del vehículo pero no inuye directamente enel sistema de control de actitud que es responsable de que el vehículo sea estable. Ignorarun fallo similar en el acelerómetro sí que podría tener consecuencias mucho más gravessabiendo que es el elemento principal que proporciona la información que se realimenta enel sistema de control de actitud. En cualquier caso, el uso de ésta opción no tiene ningúnefecto negativo a largo plazo pero conviene tenerla en cuenta si en un futuro se decideemplear una brújula externa y enmendar ésta opción.

7.2. Corrección de la lectura del acelerómetro

Problema: La lectura de la orientación del vehículo no resulta coherente con la posi-ción actual del vehículo.

Hipótesis: El problema no es un fallo de calibración puesto que la diferencia entrelos valores actuales y los valores leídos son demasiado grandes para ser solamente erroresde oset. De hecho, ni siquiera es posible terminar el proceso de calibración con éstoserrores. El problema radica en que los ejes de referencia que se están empleando paraubicar las lecturas del acelerómetro no son los correctos para nuestro modelo (la placacon el acelerómetro se sitúa posiciona de lado pegada al compartimento de la batería).

Situando el monocóptero en posición level, es decir de pie sobre el suelo de cara al norte,podemos leer las siguientes interpretaciones de las lecturas del acelerómetro, a través deMission Planner :

ROLL: -3.7PITCH: -90YAW: 0

La lectura del roll parece estar asociada a la guiñada (yaw) puesto que el valor semodica dependiendo de la orientación del monocóptero en el plano XY. De ser estocierto, el valor correcto de éste ángulo debería ser 0 puesto que el monocóptero estabaposicionado de cara al norte durante la lectura de éstos valores. En cualquier caso, éstadiferencia es lo sucientemente pequeña como para considerarlo un mero desvío que sepuede corregir sencillamente registrando un valor de oset a través de la calibración delacelerómetro.

Uno de los parámetros que Mission Planner permite modicar y enviar al rmware dela placa es `AHRS_ORIENTATION'. Éste parámetro es el responsable de transformar lalectura de la orientación respecto a sistema de referencia global al sistema de referencialocal de la placa. Esta opción rota tanto la referencia de la unidad de medición inercialcomo la brújula asociada del vehículo, para adaptarlo a las posiciones en las cuales los deroll, pitch o yaw dieren 45 o 90 grados del sistema de referencia deseado.El parámetro`AHRS_ORIENTATION' puede tomar hasta 42 valores distintos, empezando por 0 sino queremos hacer ningún cambio al sistema de referencia. Cada uno de éstos valoresaplica una combinación de correcciones de 45, 90, 135, 225, 270 o 315 grados a los ángulosmedidos.



Por técnica de ensayo y error somos capaces de descubrir que el valor adecuado de ésteparámetro para nosotros es el número 25, el cual aparentemente sólo aplica una correcciónde 270 grados en el ángulo pitch leído.

Una vez grabamos éste valor de 25 en el parámetro `AHRS_ORIENTATION', selec-cionamos la opción de escribir los parámetros cambiados en la placa, reiniciamos la placay volvemos a pasar por los procesos de calibración de la brújula y del acelerómetro, ycomprobamos que ahora la lectura de la orientación sí es la correcta.

7.3. Firmware de los ESCs

Problema: Desde el primer momento, los motores de las hélices (Brushless DC) noreaccionan de la misma forma a las órdenes de la emisora. Subiendo progresivamente elthrottle, una de las hélices comienza a rotar antes que la otra. Además (probablemente)las dos hélices no alcanzan la misma velocidad máxima con una misma entrada de throttlemáximo desde la emisora.

Hipótesis:

1. Uno de los motores está defectuoso. Los motores tienen las mismas característicasde par y de velocidad en vacío, pero ya se ha tenido que reemplazar previamenteel eje de uno de los motores debido a que el anterior lo había dejado ligeramentecurvado y afectaba de una manera notable a la rotación de la hélice superior.

2. El problema reside en que los ESCs, a pesar de tener el mismo hardware no tienenel mismo rmware instalado y responden de forma diferente ante una misma ordende la emisora.

Ya que la primera hipótesis requiere un reemplazo completo de un motor que conllevaun coste temporal y monetario, se ha decidido averiguar primero si el elemento defectuosoen el movimiento de las hélices son efectivamente los ESCs. Se ha procedido a permutarla conexión de los motores con los ESCs y se ha comprobado que al conectar cada ESC alotro motor se consigue trasladar el movimiento defectuoso de las hélices de un motor aotro. Con esto se comprueba que efectivamente, los ESCs son responsables del movimien-to asíncrono de las hélices. Nos enfrentamos entonces ante un problema en el rmwarecargado en los ESCs y para poder corregirlo antes hay que entender bien lo que son losESCs.

Los ESC (Electronic Stability Control) son unos dispositivos electrónicos que sirvenpara conectar motores de corriente continua con el cable de señal en la placa, de formaque en lugar de controlar la posición como lo haría un servo, se controla la velocidad yel par de los motores, al mismo tiempo que cuidan la alimentación de los motores porseparado, haciendo pasar la alimentación proporcionada por la batería por una etapa depotencia que adecúa la corriente que luego reciben los motores.

La gran mayoría de los ESCs son programables (los nuestros lo son) y están cargadoscon un rmware especíco de cada marca, que es el responsable de adecuar la potenciasuministrada a los motores según las ordenes que reciban desde la emisora.



Los rmwares de ESC más comunes en aplicaciones de aeromodelismo son BLheli ySimonK. Contrastando información y opiniones en foros se ha llegado a la conclusión que,aunque los dos son muy parecidos y muy ecientes, el software proporcionado por BLhelies ligeramente más estable y en general es el más usado por los aeromodelistas que quierenactualizar el rmware de sus ESCs a la versión más moderna. Por ello, el rmware que seha elegido para cargar (o recargar) en nuestros dos ESCs, es el proporcionado por BLheli.A ésta operación se la denomina ashing del controlador.

El rmware de BLheli no es difícil de encontrar subido en un repositorio de Internet yaque es código libre para que lo utilice quien lo necesite. Lo complicado se hace reprogramarlos ESCs con éste nuevo rmware que está en nuestro ordenador usando un dispositivoque no admite puertos USB o Bluetooth o ninguna otra forma de comunicación directacon el ordenador. De lo que sí que están dotados éstos dispositivos es de un puerto serieal cual podemos conectar 3 pines (TX, RX, GND) alimentándolo desde la batería paralograr una comunicación serie con otro dispositivo que sí que admita una comunicaciónpor USB con el ordenador. El dispositivo que se ha elegido para ésta tarea es un ArduinoUNO ya que cuenta con las herramientas necesarias para servir de intermediario paratraspasar el rmware desde el ordenador hasta los ESCs.

El software capaz de enviar el rmware a los ESCs a través del puerto serie que hemosutilizado es un programa llamado AvrBurnTool. Le indicamos el tipo de placa y el puertoque estamos utilizando y no encontramos ningún inconveniente para cargarlo en nuestroArduino UNO (Figura 7.1).

Figura 7.1: Carga del programa de AvrBurnTool en Arduino en 'Extended Tuning '.

Después es necesario conectar los pines del puerto serie del Arduino a los correspon-dientes que hay en nuestros ESCs. En las imágenes siguientes se puede ver los puntosexactos en los que se conecta el puerto serie. Al hacer esto es importante tener en cuentaque para conectar los pines a la placa es necesario soldar los pines en las pistas indicadas.Las pistas tienen un diámetro muy reducido y están muy cercanas a otros componentes enla placa. Por ello es necesario extremar la precaución al soldar, y utilizar un equipamientode soldadura apropiado para ésta tarea.



Figura 7.2: Conexión al Arduino. Figura 7.3: Conexión al ESC.

Una vez que tenemos las conexiones físicas entre el Arduino y el ESC listas, podemosashear el archivo binario que contiene el rmware del ESC. Para ésta operación usaremosun programa llamado OllyW's BLHeliTool, que ha sido diseñado espeícamente para elashing de rmware BLHeli en una amplia variedad de ESCs. Se modican los parámetrosde modo por defecto con múltiples ESC, de ESC que queremos reprogramar y el modode asheo. Seguidamente alimentamos directamente con la batería el ESC conectado alArduino y ejecutamos el asheo.

Figura 7.4: Pantalla de carga exitosa con OllyW's BLHeliTool.

Una vez realizado esto, se desueldan todos los pines que haya soldados al ESC y serepite el proceso con el otro ESC para garantizar que ambos terminan actualizados ycargados con el mismo rmware. Después de esto ya hemos terminado con el ashing delos ESC.

Una vez vueltos a montar, se vuelven a controlar y se comprueba que efectivamenteahora las hélices empiezan a moverse al mismo tiempo al subir el throttle desde la emisora,con lo que queda resuelto el problema y validada la hipótesis de que el elemento defectuosoen el movimiento de las hélices era únicamente el rmware de los ESCs.



7.4. Firmware de la telemetría

Problema: No somos capaces de conectar la placa a la estación de tierra (MissionPlanner) a través del enlace radio usando la telemetría.

Hipótesis: Se ha comprobado que el hardware de la telemetría sí que es compatiblecon la placa APM y con la estación de tierra. Lo que está fallando entonces tiene que serel software, es decir, el rmware propio de la telemetría.

La ventana correspondiente a la telemetría en Mission Planner está en la opción 3DRRadio del desplegable Òptional Hardware', bajo la pestaña ÌNITIAL SETUP '. Estaventana ofrece información de interés que se puede modicar, como la tasa de transmisióno el protocolo de comunicación utilizado en la comunicación, pero lo que nos interesa esla versión del rmware que aparece en la siguiente imagen.

Figura 7.5: Versiones del rmware de los módulos de telemetría.

Como se puede observar en la Figura 7.5, resulta evidente que el módulo de la te-lemetría de aire posee una versión del rmware anterior (1.8) a la del módulo de tierra(1.9). Debido a esto, la comunicación entre ambos dispositivos falla siempre que se inten-ta establecer. Ya que el proceso de ashear el módulo de aire resulta complicado ya queno cuenta con un canal de comunicación facilitado para ésta tarea, lo que haremos serádegradar la versión del rmware de la telemetría de tierra (local) a la versión 1.8 que esla que posee la telemetría de aire.

Ya que la telemetría de tierra cuenta con un puerto USB, podemos cargarle el rmwaredirectamente desde un ordenador sin la ayuda de un intermediario (tal y como veremosmás adelante con el rmware de los ESCs). El programa responsable de la carga de rm-ware de 3DR es uno llamado 3DRRadioCong. En él se muestran una serie de menúsdesplegables que permiten congurar el tipo de rmware que queremos subir al módulode telemetría. Éstos campos se rellenan automáticamente con los datos actuales presio-nando en `Load Settings '. Una vez hemos dispuesto los cambios con la versión deseada,seleccionamos Ùpload Firmware (Local)' y dejamos que cargue los datos al módulo detierra.

Una vez terminado éste proceso ya podemos comunicar con éxito la placa con laestación de tierra a través del enlace radio por telemetría. Nótese que la comunicacióntambién fallará si se desea comunicar la placa con Mission Planner a través del enlace detelemetría mientras alimenta la placa por USB con un ordenador, si no se ha deshabilitadoel dispositivo en el administrador de dispositivos. Además, es importante tener en cuentaque la tasa de transmisión propia de la telemetría es 57600 mientras que la de enlace USBes 115200. Este parámetro deberá seleccionarse en el desplegable de la esquina superiorderecha en Mission Planner, junto con el puerto seleccionado antes de conectar la placa.



7.5. Ajuste de los PIDs

Problema: El sistema de control requiere un ajuste y el ajuste automático que ofreceArdupilot (llamado Autotune) no es una opción viable ya que requiere una estabilidadmínima de vuelo en campo abierto.

Hipótesis: Podemos realizar el ajuste PID de forma manual siguiendo procedimientosrecomendados por usuarios de Ardupilot.

Tal y como hemos explicado anteriormente en el capítulo referente al uso de la estaciónde tierra Mission Planner, disponemos de una interfaz de alto nivel en Mission Plannerque nos permite observar y modicar las constantes de los reguladores presentes en elrmware del vehículo.

Dicha interfaz (Figura 5.3) dispone por un lado reguladores proporcionales 1 referentesa la interpretación de las entradas recibidas por la emisora, y por otro lado los reguladoresPID referentes al rate del roll, pitch, y yaw. Además esta interfaz permite otras opcionesde conguración pero por el momento sólo jaremos nuestra atención en el Rate Roll yRate Pitch, que son los que nos interesan para lograr un comportamiento estable en elmodo de vuelo Stabilize.

Aunque con ésto ya disponemos de las herramientas para realizar el ajuste, todavíarequerimos una metodología apropiada con la cual enfrentarnos al ajuste manual de PIDs.Aunque en Internet se pueden encontrar varios métodos sugeridos, todos parecen seguirun proceso similar basado en el ensayo y error.

Antes de comenzar el método de ajuste es conveniente tomar ciertas precauciones comocerciorarse de tener completamente cargada la batería y de tener todos los componenteselectrónicos integrados en el vehículo debidamente calibrados. Este proceso supone unode los últimos pasos a los que se somete al sistema electromecánico del vehículo previosa poder volarlo de forma autónoma por lo que es imprescindible que todo esté en ordenantes de abordar el ajuste.

El método de ajuste manual recomendado en este trabajo, referente al ajuste de losreguladores emparejados del roll y el pitch, se compone de los pasos siguientes [43].

Paso 1: Ajustar el rate_P

1. Poner a cero el valor de la acción integral I.2. Poner las acciones proporcional P y derivativa D a unos valores mínimos (por ejem-

plo P = 0.025 y D = 0.01)3. Atribuir el valor de P a uno de los potenciómetros de la emisora a través de uno de

los canales auxiliares que dispone.4. Establecer como intervalo de acción de P un valor inferior de 0.05 y un valor superior

de 3.00.5. Modicar en vuelo el parámetro P en vista al comportamiento en tiempo real del

vehículo.6. Cuando el valor de P resulta aceptable, se puede consultar en Mission Planner

haciendo click en `Refresh Parameters ' para registrar el valor actual.1Son llamados Stab Roll, Stab Pitch y Stab Yaw



Paso 2: Ajustar el rate_D

1. De forma análoga al rate_P, asociar el valor de rate_D al un potenciómetro de laemisora mediante un canal auxiliar.

2. Establecer un intervalo entre 0 y 0.025 para la rate_D3. Cuando se obtenga una rate_D que haga oscilar rápidamente al vehículo, nos que-

damos con ese valor ya que es el máximo rate_D adecuado para nuestro sistema.4. Observar y registrar el valor máximo obtenido de rate_D.

Paso 3: Reajustar el rate_P

1. Conservando el valor máximo de rate_D obtenido, modicar el valor de rate_Pmanualmente hasta un 130% de su valor actual.

2. Registrar los valores de rate_P y rate_D obtenidos hasta el momento.

Paso 4: Ajustar el rate_I

1. Asociar el valir de rate_I al potenciómetro auxiliar de la emisora.2. Modicar durante el vuelo el parámetro rate_I observando su comportamiento hasta

que se note un aumento signicativo en la establidad del vehículo.3. Registrar los valores nales de rate_P, rate_D y rate_I.

Aunque éste sería el procedimiento correcto para realizar un ajuste manual adecuadopara el vehículo, en nuestro caso hemos simplicado el sistema a un ajuste de la constanteproporcional a través del potenciómetro de la emisora manteniendo la acción derivativa aun valor jo de 0.0125. Este valor se ha escogido en base a que se encuentra en el puntomedio del intervalo aconsejado. Otros métodos de ajuste manual recomiendan modicarel valor de rate_P en base a un rate_D ya pre-jado por lo que esta forma de ajusteaunque es menos elaborada también puede resultar conveniente. A la hora de modicarlos valores, lo que tenemos que observar es lo siguiente:

Demasiado valor proporcional provoca que el vehículo oscile con más rapidez yagresividad. Si es demasiado bajo, reacciona lento a las entradas, dando la impresiónde que hay un delay (un retraso) en su movimiento.Un valor demasiado alto de rate_D hará vibrar demasiado al vehículo, y un valormuy bajo tendrá un efecto similar al de un rate_P muy bajo.Finalmente, la acción integral sólo tiene un efecto a largo plazo por lo que no esobservable en los entornos que se han utilizado en este proyecto.

Dado que durante las pruebas realizadas que veremos más adelante, los ensayos sehan llevado a cabo en entornos controlados en lugar de vuelos en campo abierto, en estetrabajo el ajuste que se ha llevado a cabo ha terminado siendo un regulador PD en elcual se ha ido modicando rate_P (a través del potenciómetro auxiliar de la emisora)manteniendo rate_D ja, tal y como acabamos de explicar.



7.6. Registros de vuelo

7.6.1. Utilidad de los registros de vuelo

Los registros de vuelo corresponden a las evoluciones de un conjunto de valores deciertas variables seleccionadas de antemano. Son de gran utilidad cuando se quiere depuraralgún aspecto paramétrico del software y se quiere averiguar qué falla. Especícamente,en el desarrollo de éste trabajo hemos hecho uso de ellos para el renado de los PIDs.Existen 2 formas de registrar los datos de vuelo con Ardupilot : con los Dataash logs ycon los Telemetry logs. Ambos métodos pueden parecer similares, aunque no funcionande la misma forma. El uso de éstos registros se centra en resolver:

Fallos mecánicos.

Los fallos mecánicos más comunes suelen involucrar un al funcionamiento por partede los motores o de sus ESCs. Éstos se maniestan en forma de una brusca divergen-cia en la evolución de los valores deseados de roll y pitch frente a los valores reales deroll y pitch. Ésta discrepancia se hace especialmente visible en los dataash logsqueveremos más adelante, y se encuentra observando la diferencia entre el recorridocoherente del movimiento deseado frente a una perturbación brusca producida en elmovimiento real del vehículo.

Vibraciones indeseadas.

Las vibraciones elevadas pueden perturbar la lectura la actitud y altura del vehículorecibida por el acelerómetro, lo cual puede causar que el vehículo acabe derivandoen el aire. Las vibraciones se pueden captar observando la evolución de la lecturatridimensional del acelerómetro. Lo normal es que éstos valores cambien momentá-neamente mientras el vehículo se está moviendo, pero pueden suponer un problemasi también cambian cuando el vehículo no está efectuando ninguna maniobra du-rante su vuelo.

Interferencias en la brújula.

Tanto la batería como los motores, o los ESCs pueden suponer una fuente conside-rable de interferencia magnética que puede afectar a la lectura de la brújula. Estopuede provocar un efecto negativo popularmente llamado toilet bowling que puedeacabar con el vehículo tomando una dirección errónea. La interferencia magnética sepuede observar mediante el seguimiento de la variable `mag_eld' en los registros.Nótese que la interferencia magnética suele ser más fuerte siempre en el periodo delarranque del vehículo, cuando afortunadamente tiene el mínimo impacto sobre elmovimiento del vehículo. Una interferencia magnética en aplicaciones de vuelo esdañina no cuando está presente sino cuando su valor no es constante, y se consideraaceptable cuando sus picos de oscilación no superen el 30% del valor medio. El ruidoestático producido por las interferencias magnéticas no resulta perjudicial ya queacaba siendo ltrado por el sistema de estimación del software (ltro de Kalman).



Fallos en el GPS.

A veces, es posible que perciban errores de posición GPS muy repentinos que puedenprovocar que el vehículo adopte la idea de que no está situado donde debería estar,lo cual le puede llevar a cambiar el rumbo de forma agresiva hacia una posiciónerrónea. Éste comportamiento erróneo se puede visualizar tanto en los Dataashlogs como en los Telemetry logs, y se suelen dar cuando desciende el número de saté-lites disponible, lo que provoca un aumento en la dilución de la precisión geométrica(GDOP).

Problemas de potencia.

Aunque gracias al uso de la etapa de potencia que nosotros empleamos (3dr po-wer module) se consigue reducir mucho el riesgo de sobretensiones inesperadas, suocurrencia sigue siendo posible. Se pueden reconocer en los registros cuando un va-lor medido (como puede ser la lectura del barómetro) termina de forma repentinamientras el vehículo sigue en vuelo. Las variaciones de 0.10 V o 0.15 V se considerannormales, pero picos superiores pueden ser una indicación de que otros dispositivospueden estar compartiendo la alimentación de la APM lo cual puede llevar fácil-mente a la aparición de éstas sobretensiones.

Ajuste del control PID.

Una herramienta muy útil en la labor de ajuste del lazo de control del vehículoconsiste en el uso de la visualización gráca de la salida de los motores gracias a losregistros de Dataash logs y Telemetry logs. Además de la salida de roll, pitch, yaw ythrottle, también permiten la posibilidad de observar las constantes del PID, lo quepuede ayudar en el ajuste del mismo, y con ésa misma intención se han empleado.

7.6.2. Dataash Logs

Almacenan los datos en el chip de memoria BeagleBoard dataash, el cual en circuns-tancias normales se puede descargar en el disco duro del ordenador a través de MissionPlanner y exportar en otros formatos para ser leído más tarde a través de una interfazde Mission Planner o a través de otros programas como Matlab. En el modelo especícoCopter, éstos registros se crean automáticamente nada más se arman los motores. Losparámetros que acaban registrados en los Dataash logs son los que aparecen bajo lapestaña `CONFIG/TUNING ', en la sección `Advanced Parameters'.

La recuperación de éstos registros viene muy facilitada en la placa Pixhawk puesto quese almacena en la memoria SD de la placa que se puede retirar y leer luego directamentedesde el ordenador. Sin embargo en el caso de la APM, la memoria no es extraíble porlo que hay que hacer uso de la interfaz de Mission Planner para descargar los archivos.Desgraciadamente, el acceso a la memoria EEPROM para escribir y para leer registrosde vuelo tipo Dataash logs no está disponible en algunas placas APM. El procedimientoque se emplea para descargar éstos registros (se recuerda que normalmente se generan deforma automática) en las placas que lo permiten es mediante la sub-pestaña Dataashlogs, dentro de la pestaña principal `FLIGHT DATA'.



En la placa que hemos utilizado (APM 2.8), el intento de acceso a éstos registrosresulta en el siguiente mensaje de error y provoca que Mission Planner deje de funcionarcorrectamente hasta que se cierre y se vuelva a abrir.

Figura 7.6: Mensaje de error en los Dataash Logs.

Este error (Figura 7.6) se debe a un tema de incompatibilidad del hardware de la APMcon el sistema de registros Dataash logs y resulta funcionar correctamente en algunasAPM pero en muchas otras (entre las que se encuentra nuestra placa) no hay mucho que sepueda hacer para resolver éste error. Se ha probado a resetear el contenido de la memoriaEEPROM modicando todos sus parámetros a sus valores por defecto, pero eso tampocoha ayudado con el acceso a éstos registros. Con la placa que estamos empleando no quedaotro camino que descartar ésta herramienta.

7.6.3. Telemetry Logs

Los registros de telemetría se guardan por Mission Planner cada vez que conectamosel vehículo por enlace de telemetría y armamos los motores del vehículo. Se almacenandirectamente desde Mission Planner en el directorio facilitado en la sección `Planner ',ubicada bajo la pestaña `CONFIG/TUNING '. Cuando se crea un registro de telemetríacon la extensión `.tlog', también se genera otro archivo con nombre similar y extensión`.rlog'. Este último archivo contiene los metadatos del archivo `.tlog' y puede ser ignorado.

Los registros de telemetría se acceden desde la sub-pestaña `Telemetry log ' desde`FLIGHT DATA'. El botón `Play ' nos permite visualizar en la pantalla de google earth lareproducción del vuelo guardado, mientras que el botón `Log>KML' nos permite accedera la evolución de los parámetros que queramos estudiar durante el vuelo guardado.El prin-cipal uso de los registros de telemetría es la reproducción de misiones de vuelo revisandotoda la información (entre las cuales se encuentra la posición GPS del vehículo) que seha ido recibiendo por telemetría a lo largo del vuelo.



Toda ésta información se almacena de forma automática, lo que facilita la detección deerrores si algo falla durante un vuelo. Mientras un registro se está reproduciendo, ademásde la evolución de la posición del vehículo, podemos observar la evolución de todas lasvariables observables, y se puede incluso hacer grácas en 3D con los datos obtenidosdurante un vuelo. Las variables de las que se desea hacer un seguimiento se seleccionan dela misma forma que para los registros Dataash logs, en la sección `Advanced Parameters '.

A diferencia de los Dataash logs, el hardware de la APM no encuentra ningún pro-blema con la lectura y escritura de los registros de telemetría. Por ésta razón, éstos sonlos registros que se emplearán para la visualización de los resultados.


Capítulo 8

Resultados y Conclusiones

Llegados a éste punto ya tenemos todo el sistema hardware montado , conectado,calibrado y funcionalmente disponible además de la placa cargada con su rmware co-rrespondiente, lo cual signica que ya tenemos todo en orden para realizar la serie depruebas de funcionamiento del monocóptero que culminan el desarrollo de éste proyecto.Es conveniente aclarar que no se han realizado pruebas de vuelo en campo abierto, co-mo puede caber esperar de un proyecto de aeromodelismo. Debido a la falta de garantíade un sistema de control bien ajustado que puede arriesgar gravemente la integridad delvehículo, dichas pruebas se han llevado a cabo en un entorno controlado que restringe losgrados de libertad que tiene el monocóptero, tal como explicaremos próximamente, y quefacilita el ajuste del sistema de control del mismo.

8.1. Pruebas realizadas

El objetivo de dichas pruebas es permitir el movimiento del vehículo de forma contro-lada en condiciones de seguridad para poder realizar el ajuste PID en base al comporta-miento que muestra el vehículo. Tal como veremos más adelante, el monocóptero no esestable naturalmente (es decir, en cadena abierta) por lo que éste proceso resulta crucialpara lograr el comportamiento en vuelo deseado.

Es importante aclarar que debido a la extensión de este trabajo, no se ha llegado aelaborar un modelado matemático del comportamiento del vehículo para poder ajustarsus reguladores PID, por lo que solamente se ha seguido un método de ensayo y error delcual se han obtenido los resultados que se ilustrarán más adelante. Dicho ésto, el modeladomatemático que permita un ajuste del sistema de control más elaborado y able quedafuera de los objetivos del proyecto por lo que se deja pendiente de desarrollo en líneasfuturas si se desea continuar fuera del marco de este proyecto.

También conviene recordar que el sistema de control de actitud se basa en un conjuntode 3 reguladores PID sólo para estabilizar el vehículo en vuelo (uno para cada roll, pitchy yaw) y otros 3 reguladores (algo más sencillos) para moderar la respuesta frente a lasórdenes de la emisora. Debido a las dimensiones del proyecto, las pruebas y los resultadosmostrados se reeren únicamente al comportamiento de los movimientos roll y pitch decara a lograr la estabilidad del vehículo inmóvil en el aire (en modo de vuelo Stabilize).

87

CAPÍTULO 8. RESULTADOS Y CONCLUSIONES

8.1.1. Entorno de pruebas

El uso de un entorno de pruebas controlado nace de la necesidad de realizar pruebas demovimiento de los motores sin arriesgar la integridad física del vehículo. Con ésta nalidadse han dispuesto 2 entornos de pruebas, el primero utilizando un sistema de barras y elsegundo un sistema de cuerdas.

1. Entorno basado en barras.

El entorno basado en barras (Figura 8.1) consiste en la disposición de dos barrasparalelas con un carril longitudinal que permiten que el vehículo adaptado con uneje se desplace a lo largo de un eje horizontal (movimiento roll) pero impidiendolos desplazamienos laterales (pitch) o verticales (throttle). El movimiento de gui-ñada (Yaw) queda también restringido gracias a la presencia de unos retenes en losextremos sujetos al raíl. El eje del vehículo sujeto a los raíles atraviesa al propiovehículo aproximadamente por su centro de gravedad, lo que en teoría permite queel esfuerzo de un sólo motor sea capaz de hacer rotar al vehículo entero.

Figura 8.1: Entorno de pruebas basado en barras.

La principal desventaja de usar éste sistema es que al no permitir el movimiento en eleje vertical, se le está negando al vehículo de la estabilidad natural que proporcionael throttle del vehículo. Aún con esto, el sistema de barras permite sólamente larotación en el eje de alabeo, lo que restringe el movimiento de vehículo a un sólogrado de libertad 1. Gracias a ésto podemos ajustar únicamente el control en el ejedel roll sin tener que preocuparnos del cómo afectan los otros grados de libertad alque queremos controlar.

1En realidad, además del movimiento en roll también se permite un desplazamiento longitudinal, que

resulta de una combinación del angulo de roll con el vertical del vehículo.



2. Sistema basado en cuerdas.

Este segundo entorno (Figura 8.2) se dispone colgando el monocóptero de formasimétrica de dos cuerdas de forma análoga al sistema con barras. Las cuerdas cuentanen reposo con cierta holgura de forma que en éste entorno sí que se permite elmovimiento rotatorio en pitch además del roll. Las cuerdas están dispuestas de formaque su holgura no es lo sucientemente grande como para permitir signicativamenteel movimiento de guiñada, por lo que podemos simplicar el sistema argumentandoque sólamente permite abiertamente los movimientos en roll y pitch y de forma unpoco más limitada el movimiento en el eje vertical (throttle).

Figura 8.2: Entorno de pruebas basado en cuerdas.

La ventaja que supone emplear este sistema frente al entorno con barras consisteen que, además de resultar un entorno más dedigno al caso real (vuelo en campoabierto), permitir el movimiento de throttle proporciona al vehículo una estabilidadnatural con la que es conveniente contar, ya que también se encuentra en el casoreal. Sin embargo, al ganar grados de libertad también complicamos la labor delajuste del sistema de control. Además, la holgura de las cuerdas aumenta el volumenocupable por el vehículo durante las pruebas, lo que puede ser perjudicial si sedispone de un espacio reducido para llevarlas a cabo. Por lo tanto, éste sistema esmás recomendable cuando se evidencia que el entorno con barras resulta demasiadorestrictivo, y no permite perfeccionar el ajuste con los grados de libertad que sedesean.



8.1.2. Resultados de las pruebas

Las siguientes pruebas se han realizado para probar el comportamiento del monocóp-tero en los entornos anteriormente descritos. En ellas se ha experimentado con distintosvalores en los reguladores PID con el objetivo de dar con unos valores que permitan uncomportamiento estable en el roll y en el pitch para el modo de vuelo Stabilize. Debi-do a la simetría del diseño mecánico, se ha decidido emparejar los reguladores de roll ypitch, por lo que ambos emplearán los mismos valores en sus reguladores. Por tanto, cuan-do hablemos de las constantes del regulador en los siguientes epígrafes, nos referiremosprecisamente a las constantes que regulan la estabilidad tanto en el roll como en el pitch.

Los siguientes ensayos se han realizado empleando únicamente una entrada de la emi-sora: una subida progresiva del throttle de forma lineal. Por tanto podríamos entender elmodelo resultante como una respuesta frente a una entrada en pendiente ascendente.

8.1.2.1. Ensayo en cadena abierta

En este primer ensayo (Figura 8.3) no se ha empleado realimentación en el monocóp-tero, es decir se ha dejado la constante P del regulador a cero. Con esto se pretenderponer a prueba la estabilidad natural del vehículo sin el sistema de control detrás. Comola intención detrás del ensayo es probar el vehículo en el escenario más realista posible,se ha realizado en el entorno de cuerdas preparado.

Figura 8.3: Ensayo en cadena abierta.

• Por un lado, el roll del vehículo evoluciona tomando valores más y más negativoscon el paso del tiempo sin oscilar, lo que indica que el monocóptero se va inclinandoprogresivamente sin ninguna corrección.

• Por otro lado, el análisis del pitch sí que observamos una oscilación, la cual proba-blemente se deba a un efecto de rebote entre las cuerdas, que acaba estabilizándosecuando alcanza un equilibrio de tensiones entre ellas. A pesar de esto, de cara alcomportamiento observado en el roll podemos asumir que de haber estado en campoabierto, el pitch habría seguido una desviación similar a la del roll.

Con esto comprobamos que tal y como habíamos supuesto, el monocóptero no ofreceuna estabilidad natural en el roll y en el pitch en cadena abierta.



8.1.2.2. Ensayos con realimentación

Los siguientes ensayos se han realizado empleando un regulador PID que regula elcomportamiento en los ejes pitch y roll. Los valores que se han tomado como punto departida se corresponden a los típicos que se proponen para aplicaciones de tipo helicóptero.Mientras que se ha dejado la constante I a cero, la constante D toma un valor de 0.0125que no hemos modicado en los siguientes ensayos. El único parámetro que hemos idomodicando es la constante proporcional ya que es la más relevante en todo ajuste PID.

1. Ensayo con P = 0.05

En este ensayo se le ha dado a la P un valor signicativamente bajo con la intenciónde ir probando valores alejándonos progresivamente del ensayo en cadena abierta.Como se puede ver (Figura 8.4), el roll sigue teniendo un comportamiento erráticohacia los valores negativos lo que implica que la corrección proporcional es demasiadobaja.

Figura 8.4: Ensayo con P = 0.05.


Subiendo el valor proporcional hasta un tanto de 0.2 (Figura 8.5), observamos que elcomportamiento adquiere un carácter sustancialmente más oscilatorio lo que denotaun valor de P en el regulador demasiado alto. Nótese que el pico inicial alcanzavalores de sobreoscilación de casi 50 frente a los 30 con el ensayo con P = 0.05.

Figura 8.5: Ensayo en entorno de barras con P = 0.05.




Aquí (Figura 8.6) se observa una mejoría en cuanto a la reducción de oscilacionesen el régimen permanente del roll, aunque el pico de sobreoscilación mantiene unvalor alto. Sin embargo, puesto que nos interesa más éste tipo de comportamientofrente a uno errático por una falta de acción proporcional, nos mantendremos eneste orden de valores en el siguiente ensayo.



En este último ensayo (Figura 8.7) parece que hemos dado con un valor bastantecorrecto de constante proporcional, ya que hemos conseguido mantener la estabili-dad en el régimen permanente reduciendo la amplitud del pico de sobreoscilación aun valor de 30. Viendo lo convenientes que son estos últimos resultados decidimosquedarnos con estos valores.


Con esto concluye el apartado de pruebas y resultados de este trabajo. Los valoresnales del regulador PD elegido para los ejes de roll y pitch son P = 0.225 y D = 0.0125.Cabe decir que los resultados mostrados en los anteriores epígrafes han sido seleccionadosde un conjunto de ensayos más amplio e iterativo de lo que se acaba de mostrar. Losensayos mostrados son de facto los más representativos y los más idóneos elegidos deentre una multitud de ensayos realizados para cada diferente valor de P.



8.2. Conclusiones

A lo largo de este Trabajo de Fin de Grado se ha expuesto el proceso detrás de laselección y conguración de todos los componentes (tanto hardware como software queconvierten la estructura mecánica de un monocóptero en el robot reactivo y comunicadoque ha acabado siendo al terminar el proyecto.

El modelo físico de monocóptero coaxial para el que se ha realizado este trabajo noes un modelo común entre los proyectos habituales de aeromodelismo. A pesar de esto, seha conseguido adaptar el software polivalente de Ardupilot con éxito permitiendo así elacceso a todas las facilidades de uso que proporciona.

• Por un lado, el rmware resulta muy conveniente tanto por su carácter polivalentecomo por lo completo y eciente que es en sus funciones (que incluye sistemas deestimación de medidas, de control de actitud, de gestión de recursos, de interpreta-ción de lecturas y de comunicación con la estación de tierra).

• Por otro lado, la estación de tierra Mission Planner ha facilitado enormemente lalabor de calibración de los componentes de vuelo, así como la conguración de losparámetros que adaptan el entorno software al modelo mecánico de monocópterocoaxial con el que hemos trabajado.

Aunque en este proyecto se han alcanzado los objetivos propuestos empleando la placaAPM 2.8, queda claro que se habrían ahorrado varias de las complicaciones encontradashabiendo utilizado una placa Pixhawk, ya que cuenta con un hardware superior y permiteejecutar las versiones más modernas de ArduCopter que no están disponibles para unaAPM, lo cual la priva de las funciones más recientes que se encuentran habitualmente. Apesar de estas complicaciones, podemos armar que hemos adaptado y congurado conéxito el modelo de monocóptero coaxial empleando la placa APM junto al hardware quehemos seleccionado especícamente para este proyecto.

En cuanto a los resultados obtenidos de los ensayos, podemos decir que hemos obtenidoun modelo de control de actitud sucientemente satisfactorio en los entornos de pruebasque se han utilizado. En el ensayo nal (Figura 8.7) se ha dado con un modelo quepresenta unas leves sobreoscilaciones iniciales y que consigue estabilizarse notablemente enel régimen permanente. Sin embargo conviene recordar que éstas pruebas se han realizadoen los entornos de pruebas preparados y no ofrecen garantías de resultados probados encampo abierto.

En suma, el presente Trabajo de Fin de Grado ha servido para proponer y probaruna solución hardware y software que permite el funcionamiento de un caso concretode robot aéreo que se sale de las categorías de modelos convencionales en aplicacionesde aeromodelismo. Aunque esta solución se ha elaborado especícamente para el modelode monocóptero coaxial, las metodologías y las herramientas que nos han llevado a ellapueden ser igualmente válidas si se desean llevar a un proyecto similar pero con unamorfología diferente, ya que muchos de las complicaciones encontradas y resueltas noeran intrínsecas al modelo del vehículo. Por tanto persevera la idea de que las solucionesencontradas en este Trabajo de Fin de Grado sean extrapolables a otros proyectos.



8.3. Líneas futuras

Tal y como se acaba de exponer, este Trabajo de Fin de Grado pretende esclarecerla búsqueda, el uso y la conguración de la capa software y hardware aplicado a un tipode robot muy poco convencional. A pesar de todo el esfuerzo y tiempo invertido en ello,aún no se puede garantizar la estabilidad de vuelo en campo abierto. Además la congu-ración establecida en el software debería ser suciente para ofrecer un comportamientocompletamente autónomo (si se llega a garantizar la estabilidad en vuelo), permitiéndoleviajar de un punto A a un punto B sin emplear un control remoto, sin embargo estacaracterística no se puede garantizar sin realizar los ensayos oportunos.

De esto queda claro que el aspecto expandible en líneas futuras que más apremia envista al estado nal de éste proyecto es el perfeccionamiento del ajuste del sistema decontrol. Idealmente, lo más apropiado sería extraer un modelo matemático en base alcomportamiento medible para poder acabar con un sistema de control robusto que puedagarantizar la estabilidad del monocóptero en campo abierto.

Una vez resuelto éste aspecto se puede estudiar la posibilidad de realizar ensayos encampo abierto para poner a prueba el manejo radio-control y la autonomía del vehículoestableciendo rutas de vuelo punto a punto a través de la estación de tierra.


Bibliografía

[1] Findingdulcinea, On this day: Austria drops balloon bombs on venice, 2018.

[2] V. M. Giordano Bruno Antoniazzi Ronconi, Thaís Jessinski Batista, The utilizationof unmanned aerial vehicles (uav) for military action in foreign airspace, vol. 2,pp. 137180, 2014.

[3] J. F. Keane and S. S. Carr, A brief history of early unmanned aircraft, in JohnsHopkins APL Technical Digest, pp. 559570, 2013.

[4] S. POP, A. LUCHIAN, R.-G. ZMADU, and E. OLEA, The evolution of unmannedaerial vehicles, vol. 15, pp. 125132, 12 2017.

[5] N. S. S. Command, Navsup weapon systems support, 2016.

[6] A. Barrientos, J. Cerro, P. Gutiérrez, R. San Martin, A. Martínez, and C. Rossi,Vehículos aéreos no tripulados para uso civil. tecnología y aplicaciones, 06 2018.

[7] D. Azimov and J. Allen, Analytical model and control solutions for unmanned aerialvehicle maneuvers in a vertical plane, in 2017 International Conference on Unman-ned Aircraft Systems (ICUAS), pp. 15791587, June 2017.

[8] Schlauncha, Coaxi-copter, 2012.

[9] T. S. Oh, Coaxial dualcopter source code, 2016.

[10] A. AeroSystems, Sprite kickstarter, 2015.

[11] NASA, Presentation "principles of ight: Axes/control surfaces", Spring 2009.

[12] S. P. . D. LLC, Lecture "drones for your business", Spring 2018.

[13] C. P. Coleman, A survey of theoretical and experimental coaxial rotor aerodynamicresearch, 04 1997.

[14] A. J. Ruddell, Advancing blade concept (abc) development, vol. 22, pp. 1323, 011977.

[15] R. Feil, M. Rinker, and M. Hajek, Flight testing of a coaxial ultralight rotorcraft,05 2017.

[16] Figure of merit denition for coaxial rotors, Journal of the American HelicopterSociety, vol. 53, no. 3, 2008.

[17] Ardupilot, Apm 2.5 and 2.6 overview, 2016.

95

BIBLIOGRAFÍA

[18] F. MAX, Variador electrónico(esc): Qué es y cómo funciona., 2016.

[19] T. RC, Brushed vs brushless motors, 2018.

[20] M. Przybylski and B. Slusarek, Design and analysis of brushless dc motor withmagnetic powder core and nd-fe-b bonded magnets, 06 2018.

[21] Ardupilot, Ardupilot code overview (copter), 2016.

[22] R. Perlman, Interconnections : bridges, routers, switches and internetworking pro-tocols / r. perlman., 06 2018.

[23] D. Paret and C. Fenger, The I2C Bus: From Theory to Practice. New York, NY,USA: John Wiley & Sons, Inc., 1997.

[24] Dignal, El bus i2c, 2015.

[25] TOTALPHASE, Spi background, 2018.

[26] C. ELECTRONICS, Can bus explained - a simple intro (2018), 2018.

[27] J. McClurg, H. Hojjat, N. Foster, and P. erný, Event-driven network programming,SIGPLAN Not., vol. 51, pp. 369385, June 2016.

[28] E. W. Dijkstra, The origin of concurrent programming, ch. Cooperating SequentialProcesses, pp. 65138, New York, NY, USA: Springer-Verlag New York, Inc., 2002.

[29] M. Isabel Ribeiro and I. Ribeiro, Kalman and extended kalman lters: Concept,derivation and properties, 04 2004.

[30] S. J. Julier and J. K. Uhlmann, Unscented ltering and nonlinear estimation, Pro-ceedings of the IEEE, vol. 92, pp. 401422, Mar 2004.

[31] M. E. Pittelkau, Rotation vector in attitude estimation, p. 855, 11 2003.

[32] A. Khosravian, J. Trumpf, R. Mahony, and T. Hamel, Recursive attitude estimationin the presence of multi-rate and multi-delay vector measurements, in 2015 AmericanControl Conference (ACC), pp. 31993205, July 2015.

[33] F. Reyes, J. Cid, M. A. Limon, and M. Cervantes, Square root - type control forrobot manipulators, International Journal of Advanced Robotic Systems, vol. 10,p. 39, Jan 2013.

[34] Ardupilot, Ardupilot copter attitude control, 2016.

[35] leonardthall, Arducopter 2.9 pid loops for stabilize, acro and alt_hold, 2013.

[36] Ardupilot, Ardupilot-arduino-1.0.3-gcc-4.8.2-windows, 2016.

[37] Ardupilot, Ardupilot version of arduino, 2016.

[38] Ardupilot, Ardupilot copter guide, 2016.

[39] T. Nagy, Waf book.



[40] Ardupilot, Mission planner ground control station, 2016.

[41] Ardupilot, Accelerometer calibration in mission planner, 2016.

[42] S. S. T. A. M. Co, 015495 RC Toy Transmitter User Manual Planet T7 RC ManualShenzhen Shen's Tongchuang Aeronautic Model Co., Ltd. Planet.

[43] D. C, Arducopter tuning guide, 2012.


BIBLIOGRAFÍA


Anexos

99

Anexo 1: Identicadores de mensajeMAVLink

1. HEARTBEAT://0Es fundamental para el resto de la comunicación MAVLink. La estación de tierraenvía un pulso (en forma de mensaje mensaje) cada 1 segundo para averiguar siestán sincronizados entre ellos. Si se pierde el contacto y un cierto número de latidoslatidos (heartbeats) no se reciben, se activa el sistema a prueba de fallos (failsafe)que provoca que el vehículo aterrice, o continúe la misión a ciegas, o que vuelva alorigen, según lo que se haya preprogramado.

2. REQUEST_DATA_STREAMInformación de los canales RC, posición GPS, datos de sensores y estado actual.

3. ID_COMMAND_LONGÓrdenes de permanecer en estado ocioso (Loiter), de vuelta al origen (RTL), deaterrizar, de comenzar la misión programada, de armar o desarmar los motores, yde reiniciarse.

4. SET_MODEEstablece el modo de vuelo.

5. MISSION_REQUEST_LISTCoordenadas de todos los puntos de ruta establecidos por la misión, excepto lascoordenadas del origen válido para cualquier tipo de vehículo menos los multicóp-teros.

6. IMISSION_REQUESTConjunto de valores para de tipo `MAV_CMD', algunos ejemplos son: `(MAV_CMD_)CHANGE_ALT',`SET_HOME', `CONDITION_YAW', `TAKE_OFF', `NAV_LOITER_TIME'.

7. MISSION_ACKDesactiva el envío de ruta.

8. PARAM_REQUEST_LISTCuenta el número total de parámetros.

9. PARAM_REQUEST_READRecibe y decodica parámetros de acuerdo a su nombre e identicador.

10. MISSION_CLEAR_ALLBorra la memoria EEPROM de la placa. Es lo que se envía cuando hacemos clicksobre `Clear Mission' en la pantalla de datos de vuelo en Mission Planner.

101

11. MISSION_SET_COUNTERCambia la orden activa en medio de una misión. Se transmite por ejemplo cuandose hace click en el mapa de Mision Planner y se le ordena al vehículo `Fly to here'.

12. MISSION_COUNTSimilar a `MISSION_REQUEST_LIST', guarda todos los puntos de ruta para losmulticópteros.

13. MISSION_WRITE_PARTIAL_LISTMantiene el estado de una variable global para dar entender que la placa está reci-biendo órdenes en ese preciso instante. Es conveniente para evitar que se ejecutenotras funciones de comunicación MAVLink mientras se están recibiendo parámetrosimportantes.

14. SET_MAG_OFFSETSDa valores a los parámetros de oset (`mag_ofs_x', `mag_ofs_y' `mag_ofs_z')después de que se haya guardado la conguración de la calibración de la brújulaen la memoria EEPROM de la placa. Se puede hacer manualmente desde la listacompleta de parámetros de Mission Planner.

15. MISSION_ITEMSeñala que el mensaje actual tiene submensajes que se pueden utilizar en tiemporeal.

16. PARAM_SETEstablece el valor de un parámetro. Se recuerda que esta labor se hace desde la listacompleta de parámetros de Mission Planner. Una vez modicado, la placa envía elnuevo valor a modo de conrmación.

17. RC_CHANNELS_OVERRIDEInvalida los valores contenidos en HIL (`Hardware-In-Loop-Simulation') o el con-trol del cambio de posición a través de la interfaz gráca de la estación de tierra,referentes a los valores de los canales RC.

18. HIL_STATESe emplea para la simulación HIL explicada anteriormente, referente al uso de dis-positivos de realidad virtual.

19. DIGICAM_CONFIGUREConguración de los valores estáticos de la cámara acoplada.

20. MOUNT_CONFIGUREConguración de los valores estáticos del sistema de acoplamiento de la cámaraestablecidos por el usuario.

21. MOUNT_CONTROLÓrdenes de control del movimiento del sistema de acoplamiento de la cámara.

22. MOUNT_STATUSRevela el estado actual de la conguración del sistema de acoplamiento de la cámara.



23. RADIOEstudia la tasa frecuencial de la transmisión de paquetes por telemetría o USB yajusta de forma automática el retraso entre el envío y la recepción de paquetes sila señal tiene una intensidad menor de la esperada, o si se detecta que la tasa deerrores va en aumento.

24. RADIO_STATUSInforma del estado del enlace radio mencionado anteriormente.


Anexo 2: Lista Completa de parámetroscongurables presente en`ArduCopter/Parameters.cpp'

const AP_Param : : In f o Copter : : var_info [ ] =

//@Param: SYSID_SW_MREV// @DisplayName : Eeprom format ve r s i on number// @Descript ion : This va lue i s incremented when changes are

made to the eeprom format// @User : Advanced// @ReadOnly : TrueGSCALAR( format_version , "SYSID_SW_MREV" , 0) ,

// @Param: SYSID_THISMAV// @DisplayName : MAVLink system ID of t h i s v e h i c l e// @Descript ion : Al lows s e t t i n g an i n d i v i d u a l MAVLink system

id f o r t h i s v e h i c l e to d i s t i n g u i s h i t from o the r s on thesame network

// @Range : 1 255// @User : AdvancedGSCALAR( sysid_this_mav , "SYSID_THISMAV" , MAV_SYSTEM_ID) ,

// @Param: SYSID_MYGCS// @DisplayName : My ground s t a t i o n number// @Descript ion : Al lows r e s t r i c t i n g rad io o v e r r i d e s to on ly

come from my ground s t a t i o n// @Values : 255: Mission Planner and DroidPlanner , 252: AP

Planner 2// @User : AdvancedGSCALAR( sysid_my_gcs , "SYSID_MYGCS" , 255) ,

// @Param: PILOT_THR_FILT// @DisplayName : Thro t t l e f i l t e r c u t o f f// @Descript ion : Thro t t l e f i l t e r c u t o f f (Hz) − a c t i v e

whenever a l t i t u d e con t r o l i s i n a c t i v e − 0 to d i s a b l e// @User : Advanced// @Units : Hz

105

// @Range : 0 10// @Increment : .5GSCALAR( t h r o t t l e_ f i l t , "PILOT_THR_FILT" , 0) ,

// @Param: PILOT_TKOFF_ALT// @DisplayName : P i l o t t a k e o f f a l t i t u d e// @Descript ion : A l t i t u d e t ha t a l t i t u d e con t r o l modes w i l l

c l imb to when a t a k e o f f i s t r i g g e r e d wi th the t h r o t t l es t i c k .

// @User : Standard// @Units : cm// @Range : 0 .0 1000.0// @Increment : 10GSCALAR( p i l o t_takeo f f_a l t , "PILOT_TKOFF_ALT" ,

PILOT_TKOFF_ALT_DEFAULT) ,

// @Param: PILOT_TKOFF_DZ// @DisplayName : Takeof f t r i g g e r deadzone// @Descript ion : O f f s e t from mid s t i c k at which t a k e o f f i s

t r i g g e r e d// @User : Standard// @Range : 0 500// @Increment : 10GSCALAR( takeo f f_tr igger_dz , "PILOT_TKOFF_DZ" , THR_DZ_DEFAULT

) ,

// @Param: PILOT_THR_BHV// @DisplayName : Thro t t l e s t i c k behav ior// @Descript ion : Bitmask con ta in ing var ious t h r o t t l e s t i c k

op t i ons . Add up the va l u e s f o r op t i ons t ha t you want .// @User : Standard// @Values : 0 :None , 1 : Feedback from mid s t i c k , 2 : High t h r o t t l e

cance l s landing , 4 : Disarm on land d e t e c t i on// @Bitmask : 0 : Feedback from mid s t i c k , 1 : High t h r o t t l e

cance l s landing , 2 : Disarm on land d e t e c t i onGSCALAR( throt t l e_behav ior , "PILOT_THR_BHV" , 0) ,

// @Group : SERIAL// @Path : . . / l i b r a r i e s /AP_SerialManager/AP_SerialManager . cppGOBJECT( serial_manager , "SERIAL" , AP_SerialManager ) ,

// @Param: TELEM_DELAY// @DisplayName : Telemetry s t a r t up de lay// @Descript ion : The amount o f time ( in seconds ) to de lay

rad io t e l eme t r y to prevent an Xbee b r i c k i n g on power up// @User : Advanced// @Units : s// @Range : 0 30



// @Increment : 1GSCALAR( telem_delay , "TELEM_DELAY" , 0) ,

// @Param: GCS_PID_MASK// @DisplayName : GCS PID tuning mask// @Descript ion : b i tmask o f PIDs to send MAVLink PID_TUNING

messages f o r// @User : Advanced// @Values : 0 :None , 1 : Rol l , 2 : Pitch , 4 :Yaw// @Bitmask : 0 : Rol l , 1 : Pitch , 2 :YawGSCALAR(gcs_pid_mask , "GCS_PID_MASK" , 0) ,

#i f MODE_RTL_ENABLED == ENABLED// @Param: RTL_ALT// @DisplayName : RTL A l t i t u d e// @Descript ion : The minimum r e l a t i v e a l t i t u d e the model

w i l l move to b e f o r e Returning to Launch . Set to zero tore turn at curren t a l t i t u d e .

// @Units : cm// @Range : 0 8000// @Increment : 1// @User : StandardGSCALAR( r t l_a l t i t ude , "RTL_ALT" , RTL_ALT) ,

// @Param: RTL_CONE_SLOPE// @DisplayName : RTL cone s l o p e// @Descript ion : Def ines a cone above home which determines

maximum cl imb// @Range : 0 .5 10.0// @Increment : .1// @Values : 0 : Disab led , 1 : Shal low , 3 : Steep// @User : StandardGSCALAR( rtl_cone_slope , "RTL_CONE_SLOPE" ,

RTL_CONE_SLOPE_DEFAULT) ,

// @Param: RTL_SPEED// @DisplayName : RTL speed// @Descript ion : Def ines the speed in cm/s which the

a i r c r a f t w i l l a t tempt to maintain h o r i z o n t a l l y wh i l ef l y i n g home . I f t h i s i s s e t to zero , WPNAV_SPEED w i l l beused in s t ead .

// @Units : cm/s// @Range : 0 2000// @Increment : 50// @User : StandardGSCALAR( rtl_speed_cms , "RTL_SPEED" , 0) ,

// @Param: RTL_ALT_FINAL


// @DisplayName : RTL Fina l A l t i t u d e// @Descript ion : This i s the a l t i t u d e the v e h i c l e w i l l move

to as the f i n a l s t a g e o f Returning to Launch or a f t e rcomple t ing a miss ion . Set to zero to land .

// @Units : cm// @Range : −1 1000// @Increment : 1// @User : StandardGSCALAR( r t l_a l t_ f i na l , "RTL_ALT_FINAL" , RTL_ALT_FINAL) ,

// @Param: RTL_CLIMB_MIN// @DisplayName : RTL minimum cl imb// @Descript ion : The v e h i c l e w i l l c l imb t h i s many cm during

the i n i t i a l c l imb por t i on o f the RTL// @Units : cm// @Range : 0 3000// @Increment : 10// @User : StandardGSCALAR( rtl_climb_min , "RTL_CLIMB_MIN" ,

RTL_CLIMB_MIN_DEFAULT) ,

// @Param: RTL_LOIT_TIME// @DisplayName : RTL l o i t e r time// @Descript ion : Time ( in m i l l i s e c ond s ) to l o i t e r above home

be f o r e beg inn ing f i n a l descent// @Units : ms// @Range : 0 60000// @Increment : 1000// @User : StandardGSCALAR( rt l_ lo i t e r_t ime , "RTL_LOIT_TIME" ,

RTL_LOITER_TIME) ,#endif

#i f RANGEFINDER_ENABLED == ENABLED// @Param: RNGFND_GAIN// @DisplayName : Rangef inder gain// @Descript ion : Used to ad j u s t the speed wi th which the

t a r g e t a l t i t u d e i s changed when o b j e c t s are sensed be lowthe cop ter

// @Range : 0.01 2.0// @Increment : 0.01// @User : StandardGSCALAR( rangef inder_gain , "RNGFND_GAIN" ,

RANGEFINDER_GAIN_DEFAULT) ,#endif

// @Param: FS_GCS_ENABLE// @DisplayName : Ground S ta t i on Fa i l s a f e Enable



// @Descript ion : Contro l s whether f a i l s a f e w i l l be invoked (and what ac t i on to take ) when connect ion wi th Grounds t a t i o n i s l o s t f o r at l e a s t 5 seconds . NB. The GCSFa i l s a f e i s on ly a c t i v e when RC_OVERRIDE i s be ing used tocon t r o l the v e h i c l e .

// @Values : 0 : Disab led , 1 : Enabled always RTL, 2 : EnabledContinue wi th Mission in Auto Mode , 3 : Enabled alwaysSmartRTL or RTL, 4 : Enabled always SmartRTL or Land

// @User : StandardGSCALAR( f a i l s a f e_gc s , "FS_GCS_ENABLE" ,

FS_GCS_ENABLED_ALWAYS_RTL) ,

// @Param: GPS_HDOP_GOOD// @DisplayName : GPS Hdop Good// @Descript ion : GPS Hdop va lue at or be low t h i s va lue

r ep r e s en t a good po s i t i o n . Used f o r pre−arm checks// @Range : 100 900// @User : AdvancedGSCALAR(gps_hdop_good , "GPS_HDOP_GOOD" ,

GPS_HDOP_GOOD_DEFAULT) ,

// @Param: MAG_ENABLE// @DisplayName : Compass enab l e / d i s a b l e// @Descript ion : S e t t i n g t h i s to Enabled (1) w i l l enab l e the

compass . S e t t i n g t h i s to Disab l ed (0) w i l l d i s a b l e thecompass

// @Values : 0 : Disab led , 1 : Enabled// @User : StandardGSCALAR( compass_enabled , "MAG_ENABLE" , MAGNETOMETER

) ,

// @Param: SUPER_SIMPLE// @DisplayName : Super Simple Mode// @Descript ion : Bitmask to enab l e Super Simple mode f o r

some f l i g h t modes . S e t t i n g t h i s to Disab l ed (0) w i l ld i s a b l e Super Simple Mode

// @Values : 0 : Disab led , 1 :Mode1 , 2 :Mode2 , 3 :Mode1+2 ,4:Mode3 , 5 :Mode1+3 ,6:Mode2+3 ,7:Mode1+2+3,8:Mode4 , 9 :Mode1+4 ,10:Mode2+4 ,11:Mode1+2+4,12:Mode3+4 ,13:Mode1+3+4,14:Mode2+3+4,15:Mode1+2+3+4,16:Mode5 , 1 7 :Mode1+5 ,18:Mode2+5 ,19:Mode1+2+5,20:Mode3+5 ,21:Mode1+3+5,22:Mode2+3+5,23:Mode1+2+3+5,24:Mode4+5 ,25:Mode1+4+5,26:Mode2+4+5,27:Mode1+2+4+5,28:Mode3+4+5,29:Mode1+3+4+5,30:Mode2+3+4+5,31:Mode1+2+3+4+5,32:Mode6 , 3 3 :Mode1+6 ,34:Mode2+6 ,35:Mode1+2+6,36:Mode3+6 ,37:Mode1+3+6,38:Mode2+3+6,39:Mode1+2+3+6,40:Mode4+6 ,41:Mode1+4+6,42:Mode2+4+6,43:Mode1+2+4+6,44:Mode3+4+6,45:Mode1+3+4+6,46:Mode2+3+4+6,47:Mode1+2+3+4+6,48:Mode5+6 ,49:Mode1+5+6,50:Mode2+5+6,51:


Mode1+2+5+6,52:Mode3+5+6,53:Mode1+3+5+6,54:Mode2+3+5+6,55:Mode1+2+3+5+6,56:Mode4+5+6,57:Mode1+4+5+6,58:Mode2+4+5+6,59:Mode1+2+4+5+6,60:Mode3+4+5+6,61:Mode1+3+4+5+6,62:Mode2+3+4+5+6,63:Mode1+2+3+4+5+6

// @User : StandardGSCALAR( super_simple , "SUPER_SIMPLE" , 0) ,

// @Param: WP_YAW_BEHAVIOR// @DisplayName : Yaw behav iour during miss ions// @Descript ion : Determines how the a u t o p i l o t c on t r o l s the

yaw during miss ions and RTL// @Values : 0 : Never change yaw , 1 : Face next waypoint , 2 : Face

next waypoint excep t RTL, 3 : Face a long GPS course// @User : StandardGSCALAR(wp_yaw_behavior , "WP_YAW_BEHAVIOR" ,

WP_YAW_BEHAVIOR_DEFAULT) ,

// @Param: LAND_SPEED// @DisplayName : Land speed// @Descript ion : The descent speed f o r the f i n a l s t a g e o f

l and ing in cm/s// @Units : cm/s// @Range : 30 200// @Increment : 10// @User : StandardGSCALAR( land_speed , "LAND_SPEED" , LAND_SPEED) ,

// @Param: LAND_SPEED_HIGH// @DisplayName : Land speed h igh// @Descript ion : The descent speed f o r the f i r s t s t a g e o f

l and ing in cm/s . I f t h i s i s zero then WPNAV_SPEED_DN i sused

// @Units : cm/s// @Range : 0 500// @Increment : 10// @User : StandardGSCALAR( land_speed_high , "LAND_SPEED_HIGH" , 0) ,

// @Param: PILOT_SPEED_UP// @DisplayName : P i l o t maximum v e r t i c a l speed ascending// @Descript ion : The maximum v e r t i c a l ascending v e l o c i t y the

p i l o t may r e que s t in cm/s// @Units : cm/s// @Range : 50 500// @Increment : 10// @User : StandardGSCALAR( pilot_speed_up , "PILOT_SPEED_UP" ,

PILOT_VELZ_MAX) ,



// @Param: PILOT_ACCEL_Z// @DisplayName : P i l o t v e r t i c a l a c c e l e r a t i o n// @Descript ion : The v e r t i c a l a c c e l e r a t i o n used when p i l o t

i s c o n t r o l l i n g the a l t i t u d e// @Units : cm/s/ s// @Range : 50 500// @Increment : 10// @User : StandardGSCALAR( pi lot_acce l_z , "PILOT_ACCEL_Z" ,

PILOT_ACCEL_Z_DEFAULT) ,

// @Param: FS_THR_ENABLE// @DisplayName : Thro t t l e F a i l s a f e Enable// @Descript ion : The t h r o t t l e f a i l s a f e a l l ow s you to

con f i gu r e a so f tware f a i l s a f e a c t i v a t e d by a s e t t i n g onthe t h r o t t l e input channel

// @Values : 0 : Disab led , 1 : Enabled always RTL, 2 : EnabledContinue wi th Mission in Auto Mode , 3 : Enabled always Land, 4 : Enabled always SmartRTL or RTL, 5 : Enabled alwaysSmartRTL or Land

// @User : StandardGSCALAR( f a i l s a f e_ t h r o t t l e , "FS_THR_ENABLE" ,

FS_THR_ENABLED_ALWAYS_RTL) ,

// @Param: FS_THR_VALUE// @DisplayName : Thro t t l e F a i l s a f e Value// @Descript ion : The PWM l e v e l in microseconds on channel 3

be low which t h r o t t l e f a i l s a f e t r i g g e r s// @Range : 925 1100// @Units : PWM// @Increment : 1// @User : StandardGSCALAR( f a i l s a f e_th r o t t l e_va l u e , "FS_THR_VALUE" ,

FS_THR_VALUE_DEFAULT) ,

// @Param: THR_DZ// @DisplayName : Thro t t l e deadzone// @Descript ion : The deadzone above and below mid t h r o t t l e

in PWM microseconds . Used in AltHold , Loi ter , PosHoldf l i g h t modes

// @User : Standard// @Range : 0 300// @Units : PWM// @Increment : 1GSCALAR( thrott le_deadzone , "THR_DZ" , THR_DZ_DEFAULT) ,

// @Param: FLTMODE1


// @DisplayName : F l i g h t Mode 1// @Descript ion : F l i g h t mode when Channel 5 pwm i s <= 1230// @Values : 0 : S t a b i l i z e , 1 : Acro , 2 : AltHold , 3 : Auto , 4 : Guided , 5 :

Loi ter , 6 :RTL, 7 : Circ l e , 9 : Land , 1 1 : Dr i f t , 1 3 : Sport , 1 4 : Fl ip, 1 5 : AutoTune , 1 6 : PosHold , 1 7 : Brake , 1 8 : Throw , 1 9 :Avoid_ADSB, 2 0 :Guided_NoGPS , 2 1 : Smart_RTL, 2 2 : FlowHold , 2 3 : Fol low

// @User : StandardGSCALAR( flight_mode1 , "FLTMODE1" ,

FLIGHT_MODE_1) ,

// @Param: FLTMODE2// @DisplayName : F l i g h t Mode 2// @Descript ion : F l i g h t mode when Channel 5 pwm i s >1230, <=

1360// @Values : 0 : S t a b i l i z e , 1 : Acro , 2 : AltHold , 3 : Auto , 4 : Guided , 5 :



FLIGHT_MODE_2) ,





FLIGHT_MODE_3) ,





FLIGHT_MODE_4) ,

// @Param: FLTMODE5// @DisplayName : F l i g h t Mode 5



// @Descript ion : F l i g h t mode when Channel 5 pwm i s >1620, <=1749

// @Values : 0 : S t a b i l i z e , 1 : Acro , 2 : AltHold , 3 : Auto , 4 : Guided , 5 :Loi ter , 6 :RTL, 7 : Circ l e , 9 : Land , 1 1 : Dr i f t , 1 3 : Sport , 1 4 : Fl ip, 1 5 : AutoTune , 1 6 : PosHold , 1 7 : Brake , 1 8 : Throw , 1 9 :Avoid_ADSB, 2 0 :Guided_NoGPS , 2 1 : Smart_RTL, 2 2 : FlowHold , 2 3 : Fol low


FLIGHT_MODE_5) ,

// @Param: FLTMODE6// @DisplayName : F l i g h t Mode 6// @Descript ion : F l i g h t mode when Channel 5 pwm i s >=1750// @Values : 0 : S t a b i l i z e , 1 : Acro , 2 : AltHold , 3 : Auto , 4 : Guided , 5 :



FLIGHT_MODE_6) ,

// @Param: FLTMODE_CH// @DisplayName : Fl ightmode channel// @Descript ion : RC Channel to use f o r f l i g h t mode con t r o l// @Values : 0 : Disab led , 5 : Channel5 , 6 : Channel6 , 7 : Channel7 , 8 :

Channel8// @User : AdvancedGSCALAR( flight_mode_chan , "FLTMODE_CH" ,

CH_MODE_DEFAULT) ,

// @Param: SIMPLE// @DisplayName : Simple mode bi tmask// @Descript ion : Bitmask which ho l d s which f l i g h t modes use

s imple heading mode ( eg b i t 0 = 1 means F l i g h t Mode 0uses s imple mode)

// @User : AdvancedGSCALAR( simple_modes , "SIMPLE" , 0) ,

// @Param: LOG_BITMASK// @DisplayName : Log bi tmask// @Descript ion : 4 by t e bitmap o f l o g t ype s to enab l e// @Values : 830: Defau l t , 8 94 : De fau l t+RCIN,958 : De fau l t+IMU

,1854 : De fau l t+Motors ,−6146: Near lyAl l−AC315 ,45054 :Near lyAl l ,131071 : A l l+FastATT ,262142 : A l l+MotBatt ,393214 :A l l+FastIMU ,397310 : A l l+FastIMU+PID,655358 : A l l+FullIMU , 0 :Disab l ed

// @Bitmask : 0 :ATTITUDE_FAST, 1 :ATTITUDE_MED, 2 :GPS, 3 :PM, 4 :CTUN, 5 :NTUN, 6 :RCIN, 7 : IMU, 8 :CMD, 9 :CURRENT,10 :RCOUT,11 :


OPTFLOW,12 :PID , 1 3 :COMPASS, 1 4 :INAV, 1 5 :CAMERA,17 :MOTBATT,18 :IMU_FAST, 1 9 :IMU_RAW

// @User : StandardGSCALAR( log_bitmask , "LOG_BITMASK" ,

DEFAULT_LOG_BITMASK) ,

// @Param: ESC_CALIBRATION// @DisplayName : ESC Ca l i b r a t i on// @Descript ion : Contro l s whether ArduCopter w i l l en ter ESC

c a l i b r a t i o n on the next r e s t a r t . Do not ad j u s t t h i sparameter manually .

// @User : Advanced// @Values : 0 : Normal Star t−up , 1 : Star t−up in ESC Ca l i b r a t i on

mode i f t h r o t t l e high , 2 : Star t−up in ESC Ca l i b r a t i onmode r e g a r d l e s s o f t h r o t t l e , 3 : S tar t−up and au t oma t i c a l l yc a l i b r a t e ESCs , 9 : Disab l ed

GSCALAR( esc_ca l ib ra t e , "ESC_CALIBRATION" , 0) ,

// @Param: TUNE// @DisplayName : Channel 6 Tuning// @Descript ion : Contro l s which parameters ( normal ly PID

ga ins ) are be ing tuned wi th t r an sm i t t e r ' s channel 6 knob// @User : Standard// @Values : 0 :None , 1 : Stab Ro l l /Pi tch kP , 4 : Rate Ro l l /Pi tch kP

, 5 : Rate Ro l l /Pi tch kI , 2 1 : Rate Ro l l /Pi tch kD , 3 : Stab Yaw kP, 6 : Rate Yaw kP , 2 6 : Rate Yaw kD , 5 6 : Rate Yaw F i l t e r , 5 5 : MotorYaw Headroom , 1 4 : AltHold kP , 7 : Thro t t l e Rate kP , 3 4 :Thro t t l e Accel kP , 3 5 : Thro t t l e Accel kI , 3 6 : Thro t t l e AccelkD , 1 2 : Lo i t e r Pos kP , 2 2 : Ve l o c i t y XY kP , 2 8 : Ve l o c i t y XY kI, 1 0 :WP Speed , 2 5 : Acro Ro l lP i t ch kP , 4 0 : Acro Yaw kP , 4 5 :RCFeel , 1 3 : He l i Ext Gyro , 3 8 : Dec l inat ion , 3 9 : C i r c l e Rate , 4 1 :RangeFinder Gain , 4 6 : Rate Pi tch kP , 4 7 : Rate Pi tch kI , 4 8 :Rate Pi tch kD , 4 9 : Rate Ro l l kP , 5 0 : Rate Ro l l kI , 5 1 : RateRo l l kD , 5 2 : Rate Pi tch FF, 5 3 : Rate Ro l l FF, 5 4 : Rate Yaw FF, 5 7 :Winch

GSCALAR( radio_tuning , "TUNE" , 0) ,

// @Param: TUNE_LOW// @DisplayName : Tuning minimum// @Descript ion : The minimum va lue t ha t w i l l be app l i e d to

the parameter cu r r en t l y be ing tuned wi th the t r an sm i t t e r 's channel 6 knob

// @User : Standard// @Range : 0 32767GSCALAR( radio_tuning_low , "TUNE_LOW" , 0) ,

// @Param: TUNE_HIGH// @DisplayName : Tuning maximum



// @Descript ion : The maximum va lue t ha t w i l l be app l i e d tothe parameter cu r r en t l y be ing tuned wi th the t r an sm i t t e r 's channel 6 knob

// @User : Standard// @Range : 0 32767GSCALAR( radio_tuning_high , "TUNE_HIGH" , 1000) ,

// @Param: FRAME_TYPE// @DisplayName : Frame Type (+, X, V, e t c )// @Descript ion : Contro l s motor mixing f o r mu l t i c op t e r s .

Not used f o r Tri or Trad i t i ona l He l i c op t e r s .// @Values : 0 : Plus , 1 :X, 2 :V, 3 :H, 4 :V−Tail , 5 :A−Tail , 10 :

Y6B// @User : Standard// @RebootRequired : TrueGSCALAR( frame_type , "FRAME_TYPE" , AP_Motors : :

MOTOR_FRAME_TYPE_X) ,

// @Param: CH7_OPT// @DisplayName : Channel 7 opt ion// @Descript ion : S e l e c t which func t i on i s performed when CH7

i s above 1800 pwm// @Values : 0 :Do Nothing , 2 : Fl ip , 3 : Simple Mode , 4 :RTL, 5 :

Save Trim , 7 : Save WP, 9 :Camera Trigger , 10 : RangeFinder ,11: Fence , 13: Super Simple Mode , 14: Acro Trainer , 15 :Sprayer , 16 :Auto , 17 :AutoTune , 18:Land , 19: Gripper , 21 :Parachute Enable , 22 : Parachute Release , 23: Parachute 3pos, 24 : Auto Mission Reset , 25 : AttCon Feed Forward , 26 :AttCon Accel Limits , 27 : Retrac t Mount , 28: Relay On/Off ,34 : Relay2 On/Off , 35 : Relay3 On/Off , 36 : Relay4 On/Off , 29 :Landing Gear , 30: Lost Copter Sound , 31:Motor EmergencyStop , 32:Motor In t e r l o c k , 33 : Brake , 37:Throw , 38:ADSB−Avoidance , 39 : PrecLoiter , 40 : Object Avoidance , 41 :ArmDisarm , 42:SmartRTL , 43: In v e r t e dF l i g h t , 44 :WinchEnable , 45 :WinchControl

// @User : StandardGSCALAR( ch7_option , "CH7_OPT" ,

AUXSW_DO_NOTHING) ,



Save Trim , 7 : Save WP, 9 :Camera Trigger , 10 : RangeFinder ,11: Fence , 13: Super Simple Mode , 14: Acro Trainer , 15 :Sprayer , 16 :Auto , 17 :AutoTune , 18:Land , 19: Gripper , 21 :Parachute Enable , 22 : Parachute Release , 23: Parachute 3pos


, 24 : Auto Mission Reset , 25 : AttCon Feed Forward , 26 :AttCon Accel Limits , 27 : Retrac t Mount , 28: Relay On/Off ,34 : Relay2 On/Off , 35 : Relay3 On/Off , 36 : Relay4 On/Off , 29 :Landing Gear , 30: Lost Copter Sound , 31:Motor EmergencyStop , 32:Motor In t e r l o c k , 33 : Brake , 37:Throw , 38:ADSB−Avoidance , 39 : PrecLoiter , 40 : Object Avoidance , 41 :ArmDisarm , 42:SmartRTL , 43: In v e r t e dF l i g h t , 44 :WinchEnable , 45 :WinchControl


AUXSW_DO_NOTHING) ,



Save Trim , 7 : Save WP, 9 :Camera Trigger , 10 : RangeFinder ,11: Fence , 13: Super Simple Mode , 14: Acro Trainer , 15 :Sprayer , 16:Auto , 17 :AutoTune , 18:Land , 19: Gripper , 21 :Parachute Enable , 22 : Parachute Release , 23: Parachute 3pos, 24 : Auto Mission Reset , 25 : AttCon Feed Forward , 26 :AttCon Accel Limits , 27 : Retrac t Mount , 28: Relay On/Off ,34 : Relay2 On/Off , 35 : Relay3 On/Off , 36 : Relay4 On/Off , 29 :Landing Gear , 30: Lost Copter Sound , 31:Motor EmergencyStop , 32:Motor In t e r l o c k , 33 : Brake , 37:Throw , 38:ADSB−Avoidance , 39 : PrecLoiter , 40 : Object Avoidance , 41 :ArmDisarm , 42:SmartRTL , 43: In v e r t e dF l i g h t , 44 :WinchEnable , 45 :WinchControl


AUXSW_DO_NOTHING) ,

// @Param: CH10_OPT// @DisplayName : Channel 10 opt ion// @Descript ion : S e l e c t which func t i on i s performed when

CH10 i s above 1800 pwm// @Values : 0 :Do Nothing , 2 : Fl ip , 3 : Simple Mode , 4 :RTL, 5 :

Save Trim , 7 : Save WP, 9 :Camera Trigger , 10 : RangeFinder ,11: Fence , 13: Super Simple Mode , 14: Acro Trainer , 15 :Sprayer , 16:Auto , 17 :AutoTune , 18:Land , 19: Gripper , 21 :Parachute Enable , 22 : Parachute Release , 23: Parachute 3pos, 24 : Auto Mission Reset , 25 : AttCon Feed Forward , 26 :AttCon Accel Limits , 27 : Retrac t Mount , 28: Relay On/Off ,34 : Relay2 On/Off , 35 : Relay3 On/Off , 36 : Relay4 On/Off , 29 :Landing Gear , 30: Lost Copter Sound , 31:Motor EmergencyStop , 32:Motor In t e r l o c k , 33 : Brake , 37:Throw , 38:ADSB−Avoidance , 39 : PrecLoiter , 40 : Object Avoidance , 41 :



ArmDisarm , 42:SmartRTL , 43: In v e r t e dF l i g h t , 44 :WinchEnable , 45 :WinchControl


AUXSW_DO_NOTHING) ,





AUXSW_DO_NOTHING) ,





AUXSW_DO_NOTHING) ,


// @Group : ARMING_// @Path : . . / l i b r a r i e s /AP_Arming/AP_Arming . cppGOBJECT( arming , "ARMING_" , AP_Arming_Copter )

,

// @Param: DISARM_DELAY// @DisplayName : Disarm de lay// @Descript ion : Delay b e f o r e automatic disarm in seconds . A

va lue o f zero d i s a b l e s auto disarm .// @Units : s// @Range : 0 127// @User : AdvancedGSCALAR( disarm_delay , "DISARM_DELAY" ,

AUTO_DISARMING_DELAY) ,

// @Param: ANGLE_MAX// @DisplayName : Angle Max// @Descript ion : Maximum lean ang le in a l l f l i g h t modes// @Units : cdeg// @Range : 1000 8000// @User : AdvancedASCALAR(angle_max , "ANGLE_MAX" ,

DEFAULT_ANGLE_MAX) ,

// @Param: PHLD_BRAKE_RATE// @DisplayName : PosHold brak ing ra t e// @Descript ion : PosHold f l i g h t mode ' s r o t a t i on ra t e dur ing

brak ing in deg/ sec// @Units : deg/ s// @Range : 4 12// @User : AdvancedGSCALAR( poshold_brake_rate , "PHLD_BRAKE_RATE" ,

POSHOLD_BRAKE_RATE_DEFAULT) ,

// @Param: PHLD_BRAKE_ANGLE// @DisplayName : PosHold brak ing ang l e max// @Descript ion : PosHold f l i g h t mode ' s max lean ang l e during

brak ing in cent i−degrees// @Units : cdeg// @Range : 2000 4500// @User : AdvancedGSCALAR( poshold_brake_angle_max , "PHLD_BRAKE_ANGLE" ,

POSHOLD_BRAKE_ANGLE_DEFAULT) ,

// @Param: LAND_REPOSITION// @DisplayName : Land r e p o s i t i o n i n g// @Descript ion : Enables user input during LAND mode , the

l and ing phase o f RTL, and auto mode l and ing s .



// @Values : 0 :No r epo s i t i on in g , 1 : Repos i t i on ing// @User : AdvancedGSCALAR( land_repos i t i on ing , "LAND_REPOSITION" ,

LAND_REPOSITION_DEFAULT) ,

// @Param: FS_EKF_ACTION// @DisplayName : EKF Fa i l s a f e Action// @Descript ion : Contro l s the ac t i on t ha t w i l l be taken when

an EKF f a i l s a f e i s invoked// @Values : 1 : Land , 2 : AltHold , 3 : Land even in S t a b i l i z e// @User : AdvancedGSCALAR( fs_ekf_action , "FS_EKF_ACTION" ,

FS_EKF_ACTION_DEFAULT) ,

// @Param: FS_EKF_THRESH// @DisplayName : EKF f a i l s a f e var iance t h r e s h o l d// @Descript ion : Al lows s e t t i n g the maximum acc ep t a b l e

compass and v e l o c i t y var iance// @Values : 0 . 6 : S t r i c t , 0 . 8 : Defau l t , 1 . 0 : Relaxed// @User : AdvancedGSCALAR( fs_ekf_thresh , "FS_EKF_THRESH" ,

FS_EKF_THRESHOLD_DEFAULT) ,

// @Param: FS_CRASH_CHECK// @DisplayName : Crash check enab l e// @Descript ion : This enab l e s automatic crash check ing . When

enab led the motors w i l l disarm i f a crash i s d e t e c t e d .// @Values : 0 : Disab led , 1 : Enabled// @User : AdvancedGSCALAR( fs_crash_check , "FS_CRASH_CHECK" , 1) ,

// @Param: RC_SPEED// @DisplayName : ESC Update Speed// @Descript ion : This i s the speed in Hertz t h a t your ESCs

w i l l r e c e i v e updates// @Units : Hz// @Range : 50 490// @Increment : 1// @User : AdvancedGSCALAR( rc_speed , "RC_SPEED" , RC_FAST_SPEED) ,

// @Param: ACRO_RP_P// @DisplayName : Acro Ro l l and Pi tch P gain// @Descript ion : Converts p i l o t r o l l and p i t c h in t o a

de s i r e d ra t e o f r o t a t i on in ACRO and SPORT mode . Higherva l u e s mean f a s t e r ra t e o f r o t a t i on .

// @Range : 1 10// @User : Standard


GSCALAR(acro_rp_p , "ACRO_RP_P" ,ACRO_RP_P) ,

// @Param: ACRO_YAW_P// @DisplayName : Acro Yaw P gain// @Descript ion : Converts p i l o t yaw input in t o a de s i r e d

ra t e o f r o t a t i on in ACRO, S t a b i l i z e and SPORT modes .Higher va l u e s mean f a s t e r ra t e o f r o t a t i on .

// @Range : 1 10// @User : StandardGSCALAR(acro_yaw_p , "ACRO_YAW_P" ,

ACRO_YAW_P) ,

#i f MODE_ACRO_ENABLED == ENABLED | | MODE_SPORT_ENABLED ==ENABLED// @Param: ACRO_BAL_ROLL// @DisplayName : Acro Balance Ro l l// @Descript ion : ra t e at which r o l l ang l e r e tu rns to l e v e l

in acro and spor t mode . A h i ghe r va lue causes thev e h i c l e to re turn to l e v e l f a s t e r .

// @Range : 0 3// @Increment : 0 .1// @User : AdvancedGSCALAR( acro_balance_rol l , "ACRO_BAL_ROLL" ,

ACRO_BALANCE_ROLL) ,

// @Param: ACRO_BAL_PITCH// @DisplayName : Acro Balance Pi tch// @Descript ion : ra t e at which p i t c h ang le r e tu rns to l e v e l

in acro and spor t mode . A h i ghe r va lue causes thev e h i c l e to re turn to l e v e l f a s t e r .

// @Range : 0 3// @Increment : 0 .1// @User : AdvancedGSCALAR( acro_balance_pitch , "ACRO_BAL_PITCH" ,

ACRO_BALANCE_PITCH) ,#endif

#i f MODE_ACRO_ENABLED == ENABLED// @Param: ACRO_TRAINER// @DisplayName : Acro Trainer// @Descript ion : Type o f t r a i n e r used in acro mode// @Values : 0 : Disab led , 1 : Leve l ing , 2 : Leve l i ng and Limited// @User : AdvancedGSCALAR( acro_tra iner , "ACRO_TRAINER" ,

ACRO_TRAINER_LIMITED) ,

// @Param: ACRO_RP_EXPO



// @DisplayName : Acro Ro l l /Pi tch Expo// @Descript ion : Acro r o l l / p i t c h Expo to a l l ow f a s t e r

r o t a t i on when s t i c k at edges// @Values : 0 : Disab led , 0 . 1 : Very Low , 0 . 2 : Low , 0 . 3 :Medium , 0 . 4 :

High , 0 . 5 : Very High// @Range : −0.5 1.0// @User : AdvancedGSCALAR( acro_rp_expo , "ACRO_RP_EXPO" ,

ACRO_RP_EXPO_DEFAULT) ,#endif

// v a r i a b l e s not in the g c l a s s which conta in EEPROM savedv a r i a b l e s

#i f CAMERA == ENABLED// @Group : CAM_// @Path : . . / l i b r a r i e s /AP_Camera/AP_Camera . cppGOBJECT( camera , "CAM_" , AP_Camera) ,

#endif

// @Group : RELAY_// @Path : . . / l i b r a r i e s /AP_Relay/AP_Relay . cppGOBJECT( re lay , "RELAY_" , AP_Relay) ,

#i f PARACHUTE == ENABLED// @Group : CHUTE_

// @Path : . . / l i b r a r i e s /AP_Parachute/AP_Parachute . cppGOBJECT( parachute , "CHUTE_" , AP_Parachute ) ,

#endif

// @Group : LGR_// @Path : . . / l i b r a r i e s /AP_LandingGear/AP_LandingGear . cppGOBJECT( landinggear , "LGR_" , AP_LandingGear ) ,

#i f FRAME_CONFIG == HELI_FRAME// @Group : IM_// @Path : . . / l i b r a r i e s /AC_InputManager/AC_InputManager_Heli .

cppGOBJECT( input_manager , "IM_" , AC_InputManager_Heli ) ,

#endif

// @Group : COMPASS_// @Path : . . / l i b r a r i e s /AP_Compass/AP_Compass . cppGOBJECT( compass , "COMPASS_" , Compass ) ,

// @Group : INS_// @Path : . . / l i b r a r i e s /AP_Inertia lSensor /AP_Inertia lSensor .

cpp


GOBJECT( ins , "INS_" , AP_Inert ia lSensor ) ,

// @Group : WPNAV_// @Path : . . / l i b r a r i e s /AC_WPNav/AC_WPNav. cppGOBJECTPTR(wp_nav , "WPNAV_" , AC_WPNav) ,

// @Group : LOIT_// @Path : . . / l i b r a r i e s /AC_WPNav/AC_Loiter . cppGOBJECTPTR( lo iter_nav , "LOIT_" , AC_Loiter ) ,

#i f MODE_CIRCLE_ENABLED == ENABLED// @Group : CIRCLE_// @Path : . . / l i b r a r i e s /AC_WPNav/AC_Circle . cppGOBJECTPTR( circ le_nav , "CIRCLE_" , AC_Circle ) ,

#endif

// @Group : ATC_// @Path : . . / l i b r a r i e s /AC_AttitudeControl /AC_AttitudeControl

. cpp , . . / l i b r a r i e s /AC_AttitudeControl /AC_AttitudeControl_Multi . cpp , . . / l i b r a r i e s /AC_AttitudeControl /AC_AttitudeControl_Heli . cpp

#i f FRAME_CONFIG == HELI_FRAMEGOBJECTPTR( att i tude_contro l , "ATC_" , AC_AttitudeControl_Heli

) ,#else

GOBJECTPTR( att i tude_contro l , "ATC_" ,AC_AttitudeControl_Multi ) ,

#endif

// @Group : PSC// @Path : . . / l i b r a r i e s /AC_AttitudeControl /AC_PosControl . cppGOBJECTPTR( pos_control , "PSC" , AC_PosControl ) ,

// @Group : SR0_// @Path : GCS_Mavlink . cppGOBJECTN(_gcs . _chan [ 0 ] , gcs0 , "SR0_" , GCS_MAVLINK

) ,


) ,


) ,




) ,

// @Group : AHRS_// @Path : . . / l i b r a r i e s /AP_AHRS/AP_AHRS. cppGOBJECT( ahrs , "AHRS_" , AP_AHRS) ,

#i f MOUNT == ENABLED// @Group : MNT// @Path : . . / l i b r a r i e s /AP_Mount/AP_Mount . cppGOBJECT(camera_mount , "MNT" , AP_Mount) ,

#endif

// @Group : LOG// @Path : . . / l i b r a r i e s /DataFlash/DataFlash . cppGOBJECT(DataFlash , "LOG" , DataFlash_Class ) ,

// @Group : BATT// @Path : . . / l i b r a r i e s /AP_BattMonitor/AP_BattMonitor . cppGOBJECT( battery , "BATT" ,

AP_BattMonitor ) ,

// @Group : BRD_// @Path : . . / l i b r a r i e s /AP_BoardConfig/AP_BoardConfig . cppGOBJECT( BoardConfig , "BRD_" , AP_BoardConfig

) ,

#i f HAL_WITH_UAVCAN// @Group : CAN_// @Path : . . / l i b r a r i e s /AP_BoardConfig/AP_BoardConfig_CAN . cppGOBJECT(BoardConfig_CAN , "CAN_" ,

AP_BoardConfig_CAN) ,#endif

#i f SPRAYER_ENABLED == ENABLED// @Group : SPRAY_// @Path : . . / l i b r a r i e s /AC_Sprayer/AC_Sprayer . cppGOBJECT( sprayer , "SPRAY_" , AC_Sprayer ) ,

#endif

#i f CONFIG_HAL_BOARD == HAL_BOARD_SITLGOBJECT( s i t l , "SIM_" , SITL : : SITL) ,

#endif

// @Group : GND_// @Path : . . / l i b r a r i e s /AP_Baro/AP_Baro . cpp


GOBJECT( barometer , "GND_" , AP_Baro) ,

// GPS dr i v e r// @Group : GPS_// @Path : . . / l i b r a r i e s /AP_GPS/AP_GPS. cppGOBJECT( gps , "GPS_" , AP_GPS) ,

// @Group : SCHED_// @Path : . . / l i b r a r i e s /AP_Scheduler/AP_Scheduler . cppGOBJECT( schedule r , "SCHED_" , AP_Scheduler ) ,

#i f AC_FENCE == ENABLED// @Group : FENCE_// @Path : . . / l i b r a r i e s /AC_Fence/AC_Fence . cppGOBJECT( fence , "FENCE_" , AC_Fence) ,

#endif

// @Group : AVOID_// @Path : . . / l i b r a r i e s /AC_Avoidance/AC_Avoid . cpp

#i f AC_AVOID_ENABLED == ENABLEDGOBJECT( avoid , "AVOID_" , AC_Avoid) ,

#endif

#i f AC_RALLY == ENABLED// @Group : RALLY_// @Path : AP_Rally . cpp , . . / l i b r a r i e s /AP_Rally/AP_Rally . cppGOBJECT( r a l l y , "RALLY_" , AP_Rally_Copter ) ,

#endif

#i f FRAME_CONFIG == HELI_FRAME// @Group : H_// @Path : . . / l i b r a r i e s /AP_Motors/AP_MotorsHeli_Single . cpp

, . . / l i b r a r i e s /AP_Motors/AP_MotorsHeli_Dual . cpp , . . /l i b r a r i e s /AP_Motors/AP_MotorsHeli . cpp

GOBJECTVARPTR(motors , "H_" , &copter . motors_var_info ) ,#else

// @Group : MOT_// @Path : . . / l i b r a r i e s /AP_Motors/AP_MotorsMulticopter . cppGOBJECTVARPTR(motors , "MOT_" , &copter . motors_var_info ) ,

#endif

// @Group : RCMAP_// @Path : . . / l i b r a r i e s /AP_RCMapper/AP_RCMapper . cppGOBJECT( rcmap , "RCMAP_" , RCMapper) ,

// @Group : EK2_// @Path : . . / l i b r a r i e s /AP_NavEKF2/AP_NavEKF2. cppGOBJECTN(EKF2, NavEKF2, "EK2_" , NavEKF2) ,



// @Group : EK3_// @Path : . . / l i b r a r i e s /AP_NavEKF3/AP_NavEKF3. cppGOBJECTN(EKF3, NavEKF3, "EK3_" , NavEKF3) ,

#i f MODE_AUTO_ENABLED == ENABLED// @Group : MIS_// @Path : . . / l i b r a r i e s /AP_Mission/AP_Mission . cppGOBJECT( miss ion , "MIS_" , AP_Mission ) ,

#endif

// @Group : RSSI_// @Path : . . / l i b r a r i e s /AP_RSSI/AP_RSSI. cppGOBJECT( r s s i , "RSSI_" , AP_RSSI) ,

#i f RANGEFINDER_ENABLED == ENABLED// @Group : RNGFND// @Path : . . / l i b r a r i e s /AP_RangeFinder/RangeFinder . cppGOBJECT( range f inde r , "RNGFND" , RangeFinder ) ,

#endif

#i f AP_TERRAIN_AVAILABLE && AC_TERRAIN// @Group : TERRAIN_// @Path : . . / l i b r a r i e s /AP_Terrain/AP_Terrain . cppGOBJECT( t e r r a i n , "TERRAIN_" , AP_Terrain ) ,

#endif

#i f OPTFLOW == ENABLED// @Group : FLOW// @Path : . . / l i b r a r i e s /AP_OpticalFlow/Opt ica lF low . cppGOBJECT( optf low , "FLOW" , OpticalFlow ) ,

#endif

#i f PRECISION_LANDING == ENABLED// @Group : PLND_// @Path : . . / l i b r a r i e s /AC_PrecLand/AC_PrecLand . cppGOBJECT( precland , "PLND_" , AC_PrecLand) ,

#endif

#i f RPM_ENABLED == ENABLED// @Group : RPM// @Path : . . / l i b r a r i e s /AP_RPM/AP_RPM. cppGOBJECT( rpm_sensor , "RPM" , AP_RPM) ,

#endif

#i f ADSB_ENABLED == ENABLED// @Group : ADSB_// @Path : . . / l i b r a r i e s /AP_ADSB/AP_ADSB. cpp


GOBJECT( adsb , "ADSB_" , AP_ADSB) ,

// @Group : AVD_// @Path : . . / l i b r a r i e s /AP_Avoidance/AP_Avoidance . cppGOBJECT( avoidance_adsb , "AVD_" , AP_Avoidance_Copter ) ,

#endif

#i f AUTOTUNE_ENABLED == ENABLED// @Param: AUTOTUNE_AXES// @DisplayName : Autotune ax i s b i tmask// @Descript ion : 1−by t e bitmap o f axes to autotune// @Values : 7 : Al l , 1 : Ro l l Only , 2 : Pi tch Only , 4 :Yaw Only , 3 : Ro l l

and Pitch , 5 : Ro l l and Yaw, 6 : Pi tch and Yaw// @Bitmask : 0 : Rol l , 1 : Pitch , 2 :Yaw// @User : StandardGSCALAR( autotune_axis_bitmask , "AUTOTUNE_AXES" , 7) , //

AUTOTUNE_AXIS_BITMASK_DEFAULT

// @Param: AUTOTUNE_AGGR// @DisplayName : Autotune a g g r e s s i v en e s s// @Descript ion : Autotune a g g r e s s i v en e s s . Def ines the bounce

back used to d e t e c t s i z e o f the D term .// @Range : 0.05 0.10// @User : StandardGSCALAR( autotune_aggress iveness , "AUTOTUNE_AGGR" , 0 .1 f ) ,

// @Param: AUTOTUNE_MIN_D// @DisplayName : AutoTune minimum D// @Descript ion : Def ines the minimum D gain// @Range : 0.001 0.006// @User : StandardGSCALAR(autotune_min_d , "AUTOTUNE_MIN_D" , 0 .001 f ) ,

#endif

// @Group : NTF_// @Path : . . / l i b r a r i e s /AP_Notify/AP_Notify . cppGOBJECT( not i f y , "NTF_" , AP_Notify ) ,

#i f MODE_THROW_ENABLED == ENABLED// @Param: THROW_MOT_START// @DisplayName : S t a r t motors b e f o r e throwing i s d e t e c t e d// @Descript ion : Used by THROW mode . Contro l s whether motors

w i l l run at the speed s e t by THR_MIN or w i l l be s toppedwhen armed and wa i t ing f o r the throw .

// @Values : 0 : Stopped , 1 : Running// @User : StandardGSCALAR( throw_motor_start , "THROW_MOT_START" , 0) ,

#endif



#i f AP_TERRAIN_AVAILABLE && AC_TERRAIN// @Param: TERRAIN_FOLLOW// @DisplayName : Terrain Fo l lowing use con t r o l// @Descript ion : This enab l e s t e r r a i n f o l l ow i n g f o r RTL and

LAND f l i g h t modes . To use t h i s op t ion TERRAIN_ENABLE mustbe 1 and the GCS must suppor t sending t e r r a i n data to

the a i r c r a f t . In RTL the RTL_ALT w i l l be cons idered ah e i g h t above the t e r r a i n . In LAND mode the v e h i c l e w i l ls low to LAND_SPEED 10m above t e r r a i n ( in s t ead o f 10mabove home) . This parameter does not a f f e c t AUTO andGuided which use a per−command f l a g to determine i f theh e i g h t i s above−home , a b s o l u t e or above−t e r r a i n .

// @Values : 0 :Do Not Use in RTL and Land , 1 : Use in RTL andLand

// @User : StandardGSCALAR( te r ra in_fo l l ow , "TERRAIN_FOLLOW" , 0) ,

#endif

// @Group :// @Path : Parameters . cppGOBJECT(g2 , "" , ParametersG2 ) ,

AP_VAREND ;

/∗2nd group o f parameters∗/const AP_Param : : GroupInfo ParametersG2 : : var_info [ ] =

// @Param: WP_NAVALT_MIN// @DisplayName : Minimum nav i ga t i on a l t i t u d e// @Descript ion : This i s the a l t i t u d e in meters above which

f o r nav i ga t i on can beg in . This a p p l i e s in auto t a k e o f fand auto land ing .

// @Range : 0 5// @User : StandardAP_GROUPINFO("WP_NAVALT_MIN" , 1 , ParametersG2 , wp_navalt_min

, 0) ,

// @Group : BTN_// @Path : . . / l i b r a r i e s /AP_Button/AP_Button . cppAP_SUBGROUPINFO( button , "BTN_" , 2 , ParametersG2 , AP_Button) ,

#i f MODE_THROW_ENABLED == ENABLED// @Param: THROW_NEXTMODE// @DisplayName : Throw mode ' s f o l l ow up mode


// @Descript ion : Veh ic l e w i l l sw i t ch to t h i s mode a f t e r thethrow i s s u c c e s s f u l l y completed . De fau l t i s to s tay inthrow mode (18)

// @Values : 3 : Auto , 4 : Guided , 5 :LOITER, 6 :RTL, 9 : Land , 1 7 : Brake, 1 8 : Throw

// @User : StandardAP_GROUPINFO("THROW_NEXTMODE" , 3 , ParametersG2 ,

throw_nextmode , 18) ,

// @Param: THROW_TYPE// @DisplayName : Type o f Type// @Descript ion : Used by THROW mode . S p e c i f i e s whether

Copter i s thrown upward or dropped .// @Values : 0 :Upward Throw , 1 : Drop// @User : StandardAP_GROUPINFO("THROW_TYPE" , 4 , ParametersG2 , throw_type ,

Copter : : ModeThrow : : ThrowType_Upward) ,#endif

// @Param: GND_EFFECT_COMP// @DisplayName : Ground E f f e c t Compensation Enable /Di sab l e// @Descript ion : Ground E f f e c t Compensation Enable /Di sab l e// @Values : 0 : Disab led , 1 : Enabled// @User : AdvancedAP_GROUPINFO("GND_EFFECT_COMP" , 5 , ParametersG2 ,

gndeffect_comp_enabled , 0) ,

#i f ADVANCED_FAILSAFE == ENABLED// @Group : AFS_// @Path : . . / l i b r a r i e s /AP_AdvancedFailsafe/

AP_AdvancedFailsafe . cppAP_SUBGROUPINFO( afs , "AFS_" , 6 , ParametersG2 ,

AP_AdvancedFailsafe ) ,#endif

// @Param: DEV_OPTIONS// @DisplayName : Development op t i ons// @Descript ion : Bitmask o f deve l ope r op t i ons . The meanings

o f the b i t f i e l d s in t h i s parameter may vary at any time .Deve lopers shou ld check the source code f o r curren t

meaning// @Bitmask : 0 : ADSBMavlinkProcessing// @User : AdvancedAP_GROUPINFO("DEV_OPTIONS" , 7 , ParametersG2 , dev_options , 0)

,

#i f BEACON_ENABLED == ENABLED// @Group : BCN



// @Path : . . / l i b r a r i e s /AP_Beacon/AP_Beacon . cppAP_SUBGROUPINFO( beacon , "BCN" , 14 , ParametersG2 , AP_Beacon) ,

#endif

#i f PROXIMITY_ENABLED == ENABLED// @Group : PRX// @Path : . . / l i b r a r i e s /AP_Proximity/AP_Proximity . cppAP_SUBGROUPINFO( proximity , "PRX" , 8 , ParametersG2 ,

AP_Proximity ) ,#endif

// @Param: ACRO_Y_EXPO// @DisplayName : Acro Yaw Expo// @Descript ion : Acro yaw expo to a l l ow f a s t e r r o t a t i on when

s t i c k at edges// @Values : 0 : Disab led , 0 . 1 : Very Low , 0 . 2 : Low , 0 . 3 :Medium , 0 . 4 :

High , 0 . 5 : Very High// @Range : −0.5 1.0// @User : AdvancedAP_GROUPINFO("ACRO_Y_EXPO" , 9 , ParametersG2 , acro_y_expo ,

ACRO_Y_EXPO_DEFAULT) ,

#i f MODE_ACRO_ENABLED == ENABLED// @Param: ACRO_THR_MID// @DisplayName : Acro Thr Mid// @Descript ion : Acro Thro t t l e Mid// @Range : 0 1// @User : AdvancedAP_GROUPINFO("ACRO_THR_MID" , 10 , ParametersG2 , acro_thr_mid ,

ACRO_THR_MID_DEFAULT) ,#endif

// @Param: SYSID_ENFORCE// @DisplayName : GCS sy s i d enforcement// @Descript ion : This c on t r o l s whether packe t s from other

than the expec ted GCS system ID w i l l be accepted// @Values : 0 : NotEnforced , 1 : Enforced// @User : AdvancedAP_GROUPINFO("SYSID_ENFORCE" , 11 , ParametersG2 ,

sys id_enforce , 0) ,

#i f STATS_ENABLED == ENABLED// @Group : STAT// @Path : . . / l i b r a r i e s /AP_Stats/AP_Stats . cppAP_SUBGROUPINFO( s ta t s , "STAT" , 12 , ParametersG2 , AP_Stats ) ,

#endif

#i f GRIPPER_ENABLED == ENABLED


// @Group : GRIP_// @Path : . . / l i b r a r i e s /AP_Gripper/AP_Gripper . cppAP_SUBGROUPINFO( gr ipper , "GRIP_" , 13 , ParametersG2 ,

AP_Gripper ) ,#endif

// @Param: FRAME_CLASS// @DisplayName : Frame Class// @Descript ion : Contro l s major frame c l a s s f o r mu l t i c op t e r

component// @Values : 0 : Undefined , 1 :Quad , 2 :Hexa , 3 : Octa , 4 :OctaQuad ,

5 :Y6, 6 : Hel i , 7 : Tri , 8 : S ing leCopter , 9 : CoaxCopter , 11 :Heli_Dual , 12 :DodecaHexa , 13: HeliQuad

// @User : Standard// @RebootRequired : TrueAP_GROUPINFO("FRAME_CLASS" , 15 , ParametersG2 , frame_class ,

0) ,

// @Group : SERVO// @Path : . . / l i b r a r i e s /SRV_Channel/SRV_Channels . cppAP_SUBGROUPINFO( servo_channels , "SERVO" , 16 , ParametersG2 ,

SRV_Channels ) ,

// @Group : RC// @Path : . . / l i b r a r i e s /RC_Channel/RC_Channels . cppAP_SUBGROUPINFO( rc_channels , "RC" , 17 , ParametersG2 ,

RC_Channels ) ,

#i f VISUAL_ODOMETRY_ENABLED == ENABLED// @Group : VISO// @Path : . . / l i b r a r i e s /AP_VisualOdom/AP_VisualOdom . cppAP_SUBGROUPINFO( visual_odom , "VISO" , 18 , ParametersG2 ,

AP_VisualOdom) ,#endif

// @Group : TCAL// @Path : . . / l i b r a r i e s /AP_TempCalibration/AP_TempCalibration

. cppAP_SUBGROUPINFO( temp_cal ibrat ion , "TCAL" , 19 , ParametersG2 ,

AP_TempCalibration ) ,

#i f TOY_MODE_ENABLED == ENABLED// @Group : TMODE// @Path : toy_mode . cppAP_SUBGROUPINFO(toy_mode , "TMODE" , 20 , ParametersG2 , ToyMode

) ,#endif



#i f MODE_SMARTRTL_ENABLED == ENABLED// @Group : SRTL_// @Path : . . / l i b r a r i e s /AP_SmartRTL/AP_SmartRTL. cppAP_SUBGROUPINFO( smart_rtl , "SRTL_" , 21 , ParametersG2 ,

AP_SmartRTL) ,#endif

#i f WINCH_ENABLED == ENABLED// @Group : WENC// @Path : . . / l i b r a r i e s /AP_WheelEncoder/AP_WheelEncoder . cppAP_SUBGROUPINFO(wheel_encoder , "WENC" , 22 , ParametersG2 ,

AP_WheelEncoder ) ,

// @Group : WINCH_// @Path : . . / l i b r a r i e s /AP_Winch/AP_Winch. cppAP_SUBGROUPINFO(winch , "WINCH" , 23 , ParametersG2 , AP_Winch) ,

#endif

// @Param: PILOT_SPEED_DN// @DisplayName : P i l o t maximum v e r t i c a l speed descending// @Descript ion : The maximum v e r t i c a l descending v e l o c i t y

the p i l o t may r e que s t in cm/s// @Units : cm/s// @Range : 50 500// @Increment : 10// @User : StandardAP_GROUPINFO("PILOT_SPEED_DN" , 24 , ParametersG2 ,

pilot_speed_dn , 0) ,

// @Param: LAND_ALT_LOW// @DisplayName : Land a l t low// @Descript ion : A l t i t u d e during Landing at which v e h i c l e

s lows to LAND_SPEED// @Units : cm// @Range : 100 10000// @Increment : 10// @User : AdvancedAP_GROUPINFO("LAND_ALT_LOW" , 25 , ParametersG2 , land_alt_low ,

1000) ,

#i f !HAL_MINIMIZE_FEATURES && OPTFLOW == ENABLED// @Group : FHLD// @Path : mode_flowhold . cppAP_SUBGROUPPTR(mode_flowhold_ptr , "FHLD" , 26 , ParametersG2 ,

Copter : : ModeFlowHold ) ,#endif

#i f MODE_FOLLOW_ENABLED == ENABLED


// @Group : FOLL// @Path : . . / l i b r a r i e s /AP_Follow/AP_Follow . cppAP_SUBGROUPINFO( fo l l ow , "FOLL" , 27 , ParametersG2 , AP_Follow)

,#endif

AP_GROUPEND ;


Índice de guras

1.1. Ave mecánica.[4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Mecanismo helicoidal.[4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3. Kettering Bug.[4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4. MQ-8 Fire Scout.[5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.5. Clasicación reducida de UAVs . . . . . . . . . . . . . . . . . . . . . . . . 5

1.6. Clasicación extendida de UAVs . . . . . . . . . . . . . . . . . . . . . . . . 6

1.7. Coaxcóptero MAV.[8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.8. Coaxcóptero invertido. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.9. Coaxial Dualcopter volando.[9] . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.10. Aspecto interior.[9] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.11. Circuito esquemático del Coaxial Dualcopter [9] . . . . . . . . . . . . . . . . 8

1.12. Sprite.[10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.13. Estructura de Descomposición del Proyecto. . . . . . . . . . . . . . . . . . 11

2.1. Tipos de UAV recreacionales. . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2. Morfologías de UAV de ala rotatoria.[12] . . . . . . . . . . . . . . . . . . . 17

2.3. Dibujo de un singlecopter. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4. Dibujo de un coaxcóptero. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5. Dibujo de un coaxcóptero con hélice invertida. . . . . . . . . . . . . . . . . 21

2.6. Monocóptero (alzado). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.7. Monocóptero (perl). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.8. Movimiento de roll del monocóptero . . . . . . . . . . . . . . . . . . . . . 23

2.9. Movimiento de pitch del monocóptero . . . . . . . . . . . . . . . . . . . . . 24

3.1. Esquema de la electrónica utilizada. . . . . . . . . . . . . . . . . . . . . . . 28

133

ÍNDICE DE FIGURAS

3.2. Entradas y salidas de la APM 2.8 [17] . . . . . . . . . . . . . . . . . . . . . 30

3.3. Conector del Power Module 3DR a la APM. . . . . . . . . . . . . . . . . . 32

3.4. Conexión de la telemetría con la placa. . . . . . . . . . . . . . . . . . . . . 33

3.5. Conexiones de los ESCs.[18] . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.6. Motor sin escobillas.[19] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.7. Motores utilizados (BL-CR28M). . . . . . . . . . . . . . . . . . . . . . . . 35

3.8. Emisora utilizada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.9. Receptor utilizado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1. Estructura general del rmware de Ardupilot. . . . . . . . . . . . . . . . . 41

4.2. Estructura propia del modelo Copter de Ardupilot.[21] . . . . . . . . . . . 43

4.3. Protocolo I2C.[24] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.4. Protocolo SPI.[25] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.5. Protocolo UART. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.6. Protocolo CANBUS.[26] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.7. Lazo de realimentación simplicado.[34] . . . . . . . . . . . . . . . . . . . . 59

4.8. Linealización con Square Root Controller.[34] . . . . . . . . . . . . . . . . . 60

4.9. Lazo de control completo del rmware.[35] . . . . . . . . . . . . . . . . . . 62

4.10. Esquema del código del control de actitud. . . . . . . . . . . . . . . . . . . 63

5.1. Comunicación con el vehículo. . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.2. HUD de la pestaña `Flight Data'[40]. . . . . . . . . . . . . . . . . . . . . . 78

5.3. Reguladores PID en 'Extended Tuning '. . . . . . . . . . . . . . . . . . . . . 82

6.1. Posiciones de calibración.[41] . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6.2. Conguración estándar de la emisora[42]. . . . . . . . . . . . . . . . . . . . 87

6.3. Posiciones de calibración. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

7.1. Carga del programa de AvrBurnTool en Arduino en 'Extended Tuning '. . . 97

7.2. Conexión al Arduino. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

7.3. Conexión al ESC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

7.4. Pantalla de carga exitosa con OllyW's BLHeliTool. . . . . . . . . . . . . . 98

7.5. Versiones del rmware de los módulos de telemetría. . . . . . . . . . . . . 99



7.6. Mensaje de error en los Dataash Logs. . . . . . . . . . . . . . . . . . . . . 105

8.1. Entorno de pruebas basado en barras. . . . . . . . . . . . . . . . . . . . . . 109

8.2. Entorno de pruebas basado en cuerdas. . . . . . . . . . . . . . . . . . . . . 110

8.3. Ensayo en cadena abierta. . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

8.4. Ensayo con P = 0.05. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

8.5. Ensayo en entorno de barras con P = 0.05. . . . . . . . . . . . . . . . . . . 114

8.6. Ensayo en entorno de barras con P = 0.2. . . . . . . . . . . . . . . . . . . 115

8.7. Ensayo en entorno de barras con P = 0.225. . . . . . . . . . . . . . . . . . 116


ÍNDICE DE FIGURAS


Índice de tablas

3.1. Tabla comparativa de las baterías Floureon y Zippy. . . . . . . . . . . . . . 29

4.1. Ejemplos de aplicación de las funciones de `AC_AttitudeControl' . . . . . 64

137

ÍNDICE DE TABLAS


conguración del hardware y - archivo digital upmoa.upm.es/52981/1/tfg_hector_palop_bouza.pdf ·...

Documents