Xpider PFC

ESCUELA TECNICA SUPERIOR DE INGENIER IA INFORMATICA INGENIER IA INFORMATICA Curso Acad emico 2010/2011 Proyecto Fin de Carrera
Xpider: Desarrollo de un Veh culo A ereo No Tripulado de Cuatro Motores
Autor: Oscar Higuera Rinc on Tutor: Carlos Ag uero Dur an
A Su.
Agradecimientos
En primer lugar quiero dar las gracias a mi familia por su apoyo y comprensi on constante. Tambi en a Iv an, Jacob, Antonio y el resto de mis eternos compa neros, siempre eles. Sin olvidarme de toda la buena gente que forma el Departamento de Rob otica de la Universidad Rey Juan Carlos, por su disposici on y ayuda, especialmente a Carlos Ag uero.
Indice general
Indice general Indice de guras Resumen 1. Introducci on 1.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1. Militares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2. Civiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Clasicaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4. Carga de Pago . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5. Estaci on de Tierra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6. Situaci on en Espa na . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Objetivos 2.1. Descripci on del Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VII
XI
XV
1 1 2 2 3 3 6 8 9 11 11 12 13 14 14 15 19 19 21
2.2. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1. Requisitos Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2. Requisitos Software Embarcado . . . . . . . . . . . . . . . . . . . . . 2.2.3. Requisitos de Estaci on en Tierra . . . . . . . . . . . . . . . . . . . .
2.3. Metodolog a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Estudio de Alternativas 3.1. Mikrokopter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Aeroquad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
viii
INDICE GENERAL 22 25 25 29 31 31 34 35 36 37 37 38 40 40 41 42 45 47 48 49 50 51 53 55 55 57 57 58 58 58
3.3. Ardupilot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Entorno de Desarrollo 4.1. Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. An alisis 5.1. Principios de Sustentaci on y Movimiento . . . . . . . . . . . . . . . . . . . . 5.1.1. Pitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2. Roll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.3. Yaw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. Plataforma Hardware 6.1. Estructura F sica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1. Incremento V1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.2. Incremento V2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.3. Incremento V3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2. Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1. Aceler ometros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.2. Gir oscopos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.3. Magnet ometros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.4. S onar y Bar ometro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3. Unidad Central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1. Incremento V1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.2. Incremento V2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.3. Incremento V3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. Software Embarcado 7.1. Arquitectura Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2. Drivers de EntradaSalida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.1. Interfaz I2C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.2. M odulo ADXL345Driver . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.3. M odulo ImuAdc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.4. M odulo DigitalCompass . . . . . . . . . . . . . . . . . . . . . . . . .
INDICE GENERAL 7.2.5. M odulo AltimeterDriver . . . . . . . . . . . . . . . . . . . . . . . . . 7.3. Comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4. M odulo IMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ix 59 59 61 62 66 66 68 68 69 71 71 72 73 73 73 74 74 75 76 76 76 77 77 80 81 83 84 84 84 84 85
7.4.1. Algoritmo DCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5. M odulo de Estabilizaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.1. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.2. Parametrizaci on PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.3. Aplicaci on de PID a la estabilizaci on . . . . . . . . . . . . . . . . . . 7.6. Evoluci on de los Incrementos . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. Estaci on de Tierra (GCS) 8.1. Arquitectura Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2. SerialComms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3. MainMenuDisplay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4. PrimaryDisplay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.1. GraphicMotor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4.2. GraphicAHorizon
8.4.3. HeadingIndicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.4. GraphicModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4.5. BatteryMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.6. ValueIndicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4.7. GraphicPID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.8. JoystickControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5. CalibrationDisplay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6. Grabador Reproductor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7. Evoluci on de los Incrementos . . . . . . . . . . . . . . . . . . . . . . . . . . . 9. QSearch 9.1. Antecedentes en b usqueda optimizada . . . . . . . . . . . . . . . . . . . . . . 9.1.1. M etodos num ericos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.2. Algoritmos basados en muestras . . . . . . . . . . . . . . . . . . . . . 9.1.3. Cuckoo Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2. Descripci on del algoritmo QSearch . . . . . . . . . . . . . . . . . . . . . . .
INDICE GENERAL 9.3. Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 91 93 96 97 97 97 98 99
10.Pruebas 10.1. Pruebas en banco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2. Pruebas en vuelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.Conclusiones y Trabajos Futuros 11.1. Conclusiones y Objetivos Alcanzados . . . . . . . . . . . . . . . . . . . . . . 11.1.1. Plataforma Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.2. Software Embarcado . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.3. Estaci on de Tierra (GCS) . . . . . . . . . . . . . . . . . . . . . . . .
11.1.4. QSearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 11.2. Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Bibliograf a 12.Ap endices 103 107
Indice de guras
1.1. Raven RQ-11B de AeroVironment . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Scan Eagle UAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. IAI Eitan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4. Nothrop Grumman Fire Scout . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5. Aeryon Scout de Aeryon Labs . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6. RQ-4 Global Hawk UAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7. Sensor electro- optico t ermico . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8. GSC del Predator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.9. nEUROn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.10. ATLANTE UAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1. Diagrama de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Diagrama iterativo-incremental . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. Diagrama de Incrementos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1. Mikrokopter de 8 motores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. M odulo central de Mikrokopter. . . . . . . . . . . . . . . . . . . . . . . . . . 3.3. NAV Module de Mikrokopter . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4. NicoletoMK basado en Mikrokopter . . . . . . . . . . . . . . . . . . . . . . . 3.5. Aeroquad radiocontrolado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6. Ardupilot IMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7. Ardupilot Easyglider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1. Plataforma hardware Arduino UNO. . . . . . . . . . . . . . . . . . . . . . . 4.2. Arduino Nano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3. Arduino Mini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi 4 5 5 6 7 7 8 9 10 10 12 16 16 20 20 20 21 22 23 23 26 27 27
xii
INDICE DE FIGURAS 4.4. Seeeduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5. Entorno de desarrollo Arduino. . . . . . . . . . . . . . . . . . . . . . . . . . 4.6. Entorno de desarrollo Processing . . . . . . . . . . . . . . . . . . . . . . . . 5.1. An alisis de fuerzas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2. Componentes inerciales resultantes . . . . . . . . . . . . . . . . . . . . . . . 5.3. Inercial y momento angular total . . . . . . . . . . . . . . . . . . . . . . . . 5.4. Relaci on de a ngulos pitch, roll y yaw. . . . . . . . . . . . . . . . . . . . . . . 5.5. Esquema Giro Pith . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6. Esquema de giro Roll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7. Esquema de giro Yaw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1. Chasis b asico de Mikrokopter . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2. Conjunto motor/h elice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3. Detalle ESC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4. Primer banco de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5. Detalle de plataforma aislante . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6. Protector de poliestireno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7. Relaci on orientaci on del aceler ometro . . . . . . . . . . . . . . . . . . . . . . 6.8. IMU 6DoF Razor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.9. ADXL345 con breakboard de Sparkfun. . . . . . . . . . . . . . . . . . . . . . 6.10. Esquema gir oscopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.11. IMU 6DoF sin ltros hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 6.12. Placa breakboard con LPY530AL. . . . . . . . . . . . . . . . . . . . . . . . . 6.13. Magnet ometro HMC 6352 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.14. Bar ometro SCP1000 de MBED. . . . . . . . . . . . . . . . . . . . . . . . . . 6.15. S onar LV MaxSonar EZ-1 de MaxBotics. . . . . . . . . . . . . . . . . . . . . 6.16. UC V1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.17. M odulo Xbee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.18. Placa: conexiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.19. Placa: cortes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.20. Placa V2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.21. Prototipo V2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 28 30 32 32 33 34 34 35 36 38 38 39 39 40 41 43 44 44 45 47 47 48 49 49 50 50 51 52 52 53
INDICE DE FIGURAS 6.22. Placa: pistas V3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.23. UC V3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1. Arquitectura Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2. Proyecciones de una base sobre otra de referencia. . . . . . . . . . . . . . . . 7.3. Diagrama del controlador PI DCM . . . . . . . . . . . . . . . . . . . . . . . 7.4. Esquema de controlador PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5. Parametrizaci on PID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1. Componente gr aco Serial Comms. . . . . . . . . . . . . . . . . . . . . . . . 8.2. Componente MainMenuDisplay. . . . . . . . . . . . . . . . . . . . . . . . . . 8.3. Componente GraphicMotor. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4. Componente GraphicHorizon. . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5. Componente HeadingIndicator. . . . . . . . . . . . . . . . . . . . . . . . . . 8.6. Componente GraphicModel. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7. Componente BatteryMonitor. . . . . . . . . . . . . . . . . . . . . . . . . . . 8.8. ValueIndicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.9. Componente GraphicPid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.10. Componente JoystickControl. . . . . . . . . . . . . . . . . . . . . . . . . . . 8.11. PrimaryDisplay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.12. Espacio de B usqueda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.13. Calibration Cong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.14. Representaci on visual de un Test . . . . . . . . . . . . . . . . . . . . . . . . 8.15. CalibrationDisplay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.16. Grabador/Reproductor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.17. Diagrama de clases principal GCS. . . . . . . . . . . . . . . . . . . . . . . . 9.1. Vuelo Levy convencional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2. Michaelwicz Landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3. Qsearch de Michaelwitz (3-6-3) y (2-7-3) . . . . . . . . . . . . . . . . . . . . 9.4. Qsearch de Michaelwitz (0.5-8-3) y (0.5-6-3,200) . . . . . . . . . . . . . . . . 10.1. Primer banco de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2. Segundo banco de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xiii 54 54 56 64 65 67 68 72 73 73 74 75 75 76 76 76 77 78 78 79 79 80 81 82 85 89 90 90 92 92
xiv
INDICE DE FIGURAS 93 95 95
10.3. Plano pieza adaptadora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4. QSearch iteraci on 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5. QSearch iteraci on 40 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.1. Datasheet de la placa del ADXL34555 . . . . . . . . . . . . . . . . . . . . . 115 12.2. Datasheet de la placa del LPY530AL . . . . . . . . . . . . . . . . . . . . . . 116 12.3. Datasheet de la placa del HMC6352 . . . . . . . . . . . . . . . . . . . . . . . 116 12.4. Datasheet de la placa del SCP1000 . . . . . . . . . . . . . . . . . . . . . . . 116 12.5. Datasheet de la placa del IMU 6DoF de Razor . . . . . . . . . . . . . . . . . 117
Resumen
El Proyecto Fin de Carrera expuesto en este documento presenta la denici on, dise no e implementaci on de un veh culo a ereo aut onomo de corto alcance basado en una conguraci on de cuatro motores con capacidad de vuelo estacionario. El Proyecto abarca tanto el dise no e implementaci on hardware (la elecci on de los componentes electr onicos, tanto sensores como microprocesador y diferentes actuadores, la construcci on f sica de la estructura del veh culo y el dise no e implementaci on de la placa base y las interfaces hardware) como el dise no e implementaci on software, tanto de aquel que ejecutar a embarcado en el veh culo como el software de la aplicaci on de monitorizaci on, mando y control que se ejecutar a en lo que se conoce como Estaci on de Tierra (Ground Control Station o GCS). Dentro de las capacidades del veh culo que han sido implementadas en este Proyecto se encuentra la capacidad de vuelo estacionario estable adecuadamente monitorizado y controlado. Para ello el veh culo debe interpretar adecuadamente todos los datos procedentes de los diferentes sensores, procesar estos datos y ejecutar las diferentes rutinas de control que permiten la capacidad de mantener un vuelo estable, el control autom atico y estabilizaci on de altura, el control autom atico y estabilizaci on del rumbo y la capacidad de mantener comunicaciones inal ambricas con la estaci on de monitorizaci on, mando y control. Tambi en se ha introducido alguna rutina de navegaci on y se han esbozado las capacidades de navegaci on que no ha sido posible implementar por motivos de calendario. Para la realizaci on del proyecto se ha partido de cero, desde la elecci on de los entornos de desarrollo, la plataforma hardware, el dise no e implementaci on del software embebido, y el dise no e implementaci on del software de mando y control. Puntualmente se han utilizado como referencia fragmentos de algoritmos de c alculos matem aticos especicando en todo caso la fuente.
xv
xvi
CAP ITULO 0. RESUMEN
Cap tulo 1 Introducci on

Un veh culo no tripulado es todo aquel veh culo capaz de realizar diferentes tipos de tareas sin la necesidad de contar con un tripulante humano. Los veh culos a ereos no tripulados UAV (Unmanned Aerial Vehicle) han cobrado una gran importancia en la industria aeron autica debido a que son capaces de cubrir un gran n umero de necesidades y posibilidades no exploradas hasta hace bien poco. Aunque aqu nos centremos en veh culos a ereos tambi en existen veh culos no tripulados en tierra y mar. Dentro de los veh culos no tripulados se encuentran veh culos controlados remotamente (Remotely Piloted Vehicle o Drones) y veh culos aut onomos AV (Autonomous Vehicle). En el caso de este proyecto, nos centraremos en UAVs aut onomos, capaces de realizar gran parte de las tareas sin la intervenci on de un humano. Este tipo de veh culos son muy u tiles en circunstancias en las que contar con un tripulando humano puede ser peligroso para su integridad, o en aquellos casos en los que por movilidad, maniobrabilidad o exibilidad es imposible contar con un tripulante.
1.1.
Historia
Si echamos un vistazo a la historia de los UAVs [21] y [31], los primeros UAVs eran aeronaves simples pilotadas remotamente a trav es de sistemas de radio control. Su uso comenz o a introducirse dentro del campo militar tras la Primera Guerra Mundial, us andose en la Segunda Guerra Mundial como blancos m oviles para el entrenamiento de sistemas antia ereos y de diferentes armas. A nales de los a nos 60 y debido al riesgo potencial de bajas de pilotos en misiones de reconocimiento en territorio enemigo, y debido al alto n umero de vuelos de este tipo que se realizaron durante la Guerra Fr a, los ociales norteamericanos jaron su inter es en las posibilidades de los vuelos no tripulados. Esta necesidad se ampli o con la entrada de Estados Unidos en la Guerra de Vietnam donde se produjo el primer uso de UAVs en misiones de combate. Al mismo tiempo, Israel comprendi o la necesidad de invertir en el desarrollo de veh culos no tripulados al perder gran cantidad de aeronaves debido a las bater as de misiles antia ereos que desplegaban sus m ultiples enemigos en los distintos conictos armados que se intensicaron a partir de los a nos 70. En los a nos 80 y 90 se produjo un gran avance en este tipo de veh culos, dot andolos de mayor capacidad aut onoma. Tambi en los diferentes avances en las tecnolog as hicieron 1
CAP ITULO 1. INTRODUCCION
posible el abaratamiento de costes, as como la posibilidad de crear veh culos m as peque nos y vers atiles. Con la llegada del siglo XXI y los nuevos escenarios de guerra moderna lleg o el boom de los UAVs, tanto de reconocimiento como de adquisici on de blancos y combate. El nuevo escenario de guerra urbana contra enemigos dispersos hizo necesario, por un lado, el uso de peque nos y vers atiles UAVs de reconocimiento que pod an ser usados en campo para asistir a las tropas en diferentes tareas, y por otro lado, de sosticados UAVs de medio y largo alcance capaces de jar blancos m oviles e incluso abatirlos con un riesgo m nimo. Las capacidades aut onomas han ido aumentando cada vez m as, desde asistir en vuelo a un piloto situado en una estaci on remota, hasta el vuelo completamente aut onomo siguiendo un determinado plan de vuelo precargado, y el seguimiento de un plan de misi on avanzado con gesti on de la carga de pago (conjunto de elementos y dispositivos destinados a adquirir datos de inteligencia). Actualmente los UAVs siguen siendo utilizados mayoritariamente en entornos militares, donde han conseguido hacerse un hueco como sistemas de vigilancia, inteligencia, reconocimiento y adquisici on de blancos (ISTAR, Intelligence Surveillance Target Adquisition and Reconnaissance). Paulatinamente van haci endose hueco tambi en en aplicaciones civiles, sobretodo en los campos de vigilancia, seguridad, y reconocimiento.
1.2.
1.2.1.
Aplicaciones
Militares
Tal y como se ha adelantado en la introducci on, la mayor parte de las aplicaciones de los UAVs se centran en el campo militar. Dentro de las aplicaciones militares destacan la vigilancia y reconocimiento del entorno, incluyendo la detecci on y clasicaci on de posibles amenazas, reconocimiento y adquisici on de blancos, obtenci on de un mapa completo geogr aco del campo de batalla, e incluso el combate directo, aunque en este u ltimo caso siempre guiado y monitorizado por un piloto humano. De entre todas las aplicaciones, dos de ellas han sufrido un profundo avance en los u ltimos a nos: Por un lado, las aplicaciones de vigilancia y reconocimiento de corto alcance, llevadas a cabo por peque nos UAVs desplegados en campo por los propios soldados. Estos cuentan con una peque na Estaci on de Tierra para recopilar datos y generar inteligencia. Estos UAVs proveen a los combatientes de informaci on casi en tiempo real, de manera que pueden generar un mapa tanto geogr aco como de amenazas y blancos. Estos UAVs son peque nas aeronaves generalmente propulsadas el ectricamente, que pueden ser desplegadas a mano por los soldados y que en algunos casos no retornar an nunca. Cuentan con baja autonom a, muy bajo coste y proporcionan una informaci on muy valiosa a corto plazo. Por otro lado se encuentran UAVs de mayor tama no usados tanto en misiones ISTAR como de combate. Estos veh culos en algunos casos tienen casi el tama no de un avi on de combate convencional, con autonom as que cubren grandes distancias y alturas. La informaci on que proporcionan puede ser, en algunos casos, directamente usada por sistemas de artiller a o incluso pueden contar con armamento embarcado. Los UAVS ISTAR generalmente proporcionan informaci on t actica muy valiosa en inteligencia que puede ser usada tambi en a largo plazo. Tambi en pueden tener la capacidad de
1.3. CLASIFICACION
sincronizarse entre diferentes UAVs para aumentar el valor de dicha informaci on. El estado de Israel ha realizado verdaderos progresos en UAVs capaces de adquirir blancos m oviles a distancias enormes, sin apenas ser detectados, o generando alertas de riesgos y amenazas mientras patrullan regiones cr ticas, como la Franja de Gaza, o las fronteras con L bano, repletas de terroristas ocultos entre poblaci on civil y en poblado.
1.2.2.
Civiles
El a mbito de aplicaci on de los UAVs no se limita al a rea militar, poco a poco, comienzan a demandarse aplicaciones y servicios en el campo civil. Los UAVs civiles de largo alcance son utilizados en tareas de identicaci on de riesgos y vigilancia de zonas amplias en espacios de dif cil acceso, como vigilancia de grandes instalaciones de canalizaci on de gas, gas oleo, o similares. Tambi en en tareas de identicaci on de conatos de incendios en grandes zonas boscosas, incluso en los servicios de protecci on de fronteras, ayudando a las Fuerzas y Cuerpos de Seguridad del Estado en la identicaci on y seguimiento de embarcaciones que pretenden entrar ilegalmente en el pa s a trav es del mar, ya se trate de inmigraci on ilegal, o tr aco ilegal de diferentes sustancias o materiales. Estos veh culos abaratan considerablemente el coste de las misiones de control y vigilancia, ya que antes de estos veh culos estas tareas eran llevadas a cabo por aviones pilotados o helic opteros, cuyo coste de adquisici on, mantenimiento y entrenamiento, es muy elevado. Los cuerpos de seguridad tambi en comienzan a demandar peque nos UAVs de corto alcance para tareas de vigilancia de per metros, o incluso reconocimiento del campo de acci on, por ejemplo, por parte de la Polic a o Guardia Civil. Estos veh culos son similares a los usados en campo por el ej ercito, suelen tener un alcance limitado y un coste muy bajo, proporcionando una gran cantidad de inteligencia a los cuerpos desplegados en campo. Tambi en existen otras aplicaciones civiles como servicios de fotograf a o captura de v deo a ereo, u til para conformar mapas actualizados de parcelas para la construcci on o rehabilitaci on de inmuebles, as como otros usos dirigidos hacia el entretenimiento. Por ultimo, tambi en se usan veh culos no tripulados en aplicaciones cient cas de investigaci on, sustituyendo, por ejemplo, a globos sonda, incluso para el transporte de peque nas cargas en trayectos cortos que ser an muy costosos si tuvieran que ser realizados de otra manera. Podemos decir que el campo de los veh culos no tripulados en general, y el de los a ereos en particular es un mercado en expansi on, en el que van apareciendo nuevos a mbitos de aplicaciones y usos constantemente.
1.3.
Clasicaci on
Los UAVs pueden ser clasicados tanto por su a mbito de aplicaci on como por su alcance y capacidades [20]. Por su ambito de aplicaci on, tal y como ya se ha denido, los UAVs pueden ser clasicados b asicamente en cinco categor as: ISTAR (inteligencia, vigilancia, adquisici on de blancos y reconocimiento), log stica, combate, investigaci on y desarrollo, y UAVs civiles. Dentro de esas cinco categor as se pueden encontrar UAVs de diferentes tama nos, alcances
Figura 1.1: Raven RQ-11B de AeroVironment. De lanzamiento manual y motorizaci on el ectrica. Puede ser controlado remotamente u operar de manera completamente aut onoma, monta c amaras de v deo y de visi on infrarroja, es utilizado para reconocimiento y adquisici on de blancos. Su autonom a es de 40 minutos y pesa 2 kilos. El coste de cada unidad es de 35.000 $ por separado y de 235.000 $ con el sistema completo incluyendo estaci on de control de tierra. (Entrada en servicio: 2006). y capacidades. Si se tiene en cuenta simplemente el tama no y alcance de los veh culos, estos pueden ser clasicados en las siguientes categor as: Handheld: Se trata de peque nos y ligeros veh culos que pueden lanzarse de manera manual, con alcances limitados a menos de 2000 metros y que pueden alcanzar no m as de 500 metros de altura. Close: De alcance cerrado o corto alcance, son capaces de alcanzar 1500 metros de altitud y cuentan con una autonom a por debajo de los 10 kil ometros. Su despegue puede ser manual, ayudados por catapulta o mediante despegue aut onomo. De tipo NATO: UAVs medios capaces de alcanzar 3000 metros de altitud y llegar a los 50 kil ometros de autonom a. Generalmente su tama no ya no permite el lanzamiento manual. T acticos: Capaces de alcanzar 5500 metros de altitud y con autonom as que pueden llegar a los 160 kil ometros. MALE (Medium Altitude, Large Endurance): UAVs capaces de alcanzar altitudes medias si hablamos con terminolog a aeron autica, aproximadamente sobre los 9000 metros de altitud, y con autonom a suciente para poder cubrir grandes distancias, aproximadamente sobre los 200 o 300 kil ometros. HALE (High Altitude, Large Endurance): UAVs capaces de alcanzar altitudes superiores a los 9100 metros y con alcances indenidos (pueden llegar hasta 10000 kil ometros o m as). Hipers onicos y Orbitales: Por u ltimo aquellos veh culos capaces de alcanzar velocidades supers onicas (de MATCH 1 a MATCH 5) o hipers onicas (superior a MATCH 5), o aquellos capaces de ponerse en orbitas bajas alcanzando velocidades de m as de MATCH 25.
1.3. CLASIFICACION
Figura 1.2: Scan Eagle: UAV desarrollado por Boeing de tipo NATO. Cuenta con una autonom a de hasta 20 horas o 100 kil ometros, entre su carga de pago cuenta con c amara auto-estabilizada infrarroja de alta resoluci on. Es capaz de alcanzar 60 nudos de velocidad media (110 Km/h). En la foto lo vemos en su plataforma de lanzamiento m ovil. (Entrada en servicio: 2006).
Figura 1.3: IAI Eitan desarrollado por Israel Aerospace. Se trata de un UAV de tipo MALE con capacidades ISTAR. Capaz de mantenerse en vuelo durante 36 horas a 35.000 pies de altitud (10.600 metros), albergar una carga de pago de 2.000 kilos y cubrir hasta 7000 kil ometros. Es la joya de la corona de los UAVs del ej ercito israel , su tama no es comparable a un Boeing 737. (Entr o en servicio en 2009).
Figura 1.4: Northrop Grumman Fire Scout. Helic optero UAV usado por la fuerza a erea estadounidense en tareas de reconocimiento, identicaci on de amenazas y jaci on precisa de blancos. Autonom a de 8 horas y rango de acci on de 200 kil ometros. (Operacional desde 2006). Dentro de los diferentes tipos de UAVs introducidos, y en el marco de este Proyecto, es interesante diferenciar los UAVs con capacidades de vuelo estacionario y aterrizaje/despegue vertical VTOL (Vertical Take-O and Landing) del resto. Una aeronave VTOL es capaz de mantener vuelo estacionario en altura y direcci on, es decir, sin avanzar en eje alguno de coordenadas. Las m as comunes son los helic opteros. Si hablamos de veh culos no tripulados, existen diferentes modelos de UAVs de tama no medio basados en helic opteros, las particularidades de este tipo de aeronave hacen que sean ideales para determinadas misiones de reconocimiento, rescate, e incluso de combate cerrado. Sin embargo, es en los UAVs de corto alcance donde este tipo de veh culos ha logrado mayor acogida debido a la exibilidad que proporcionan. Los veh culos VTOL con capacidades estacionarias vuelan gracias al impulso directo que ejercen los motores, generalmente aplicado a una o m as h elices, sobre el aire. Esto hace que los motores deban estar en constante funcionamiento para mantener el veh culo en vuelo, por el contrario, en los veh culos de despegue ordinario con alas, gran parte de la fuerza necesaria para mantener el vuelo es ejercida por la resistencia de la carga alar sobre el aire, por lo que el consumo es menor. Dentro de los UAVs de corto alcance con capacidades estacionarias encontramos diversos modelos de veh culos de cuatro h elices, aunque tambi en se encuentran en conguraciones de seis y ocho motores. Estos veh culos son especialmente interesantes al ser capaces de conseguir vuelos muy estables y tener una maniobrabilidad destacada. Son veh culos propulsados por motores el ectricos con autonom as que rondan los 10-12 minutos, cubriendo de 2 a 5 kil ometros.
1.4.
Carga de Pago
En entornos aeron auticos, se denomina carga de pago a aquella carga que es capaz de cargar la aeronave y que no es estrictamente parte de los sistemas de navegaci on y control de la misma. En el caso de los aviones de transporte de pasajeros o mercanc as, la carga de
1.4. CARGA DE PAGO
Figura 1.5: Aeryon Scout de Aeryon Labs. UAV de cuatro motores con su estaci on de tierra. Rango de acci on de 3 kil ometros a partir de la estaci on de tierra, cuenta con una c amara FLIR de visi on nocturna autoestabilizada.
Figura 1.6: RQ-4 Global Hawk UAV desarrollado por Northrop Grumman para la fuerza a erea estadounidense. Se trata de un UAV de tipo HALE capaz de cubrir distancias de hasta 27.000 kil ometros, 20.000 metros de altitud y hasta 36 horas de vuelo. Incluye capacidad de cargar con radar de alta resoluci on SAR (Synthetic Aperture Radar) y sensor electro- optico e infrarrojo capaz de cubrir a reas de 100.000 kil ometros cuadrados. Con un coste de 35 millones de d olares entr o en operaci on en la guerra de Irak a nales de 2006.
Figura 1.7: Sensor electro- optico t ermico. Es uno de los sensores m as demandados en los UAVs por su capacidad de tomar im agenes a grandes distancias y en diferentes condiciones ambientales. pago la conforman los pasajeros y las mercanc as a transportar, en el caso de un UAV, se denomina carga de pago a los sistemas y equipos que son usados para generar informaci on de utilidad t actica o de inteligencia. Una caracter stica muy importante de los UAVs es el peso en carga de pago que es capaz de soportar la aeronave, ya que cuanto m as carga de pago mayor n umero de sensores, c amaras, equipos de comunicaciones o armamento ser a capaz de soportar el UAV. Evidentemente, a mayor carga de pago, mayor consumo, por lo que los UAVs con menor autonom a soportan menores cargas de pago. Entre los equipos m as utilizados como carga de pago en los diferentes UAVs contamos con todo tipo de sensores y equipos de medici on, incluyendo c amaras fotogr acas y de captura de video, c amaras de visi on nocturna y con lentes capaces de captar diferentes espectros, s onar, r adar, sistemas l aser, etc. Tambi en equipos y computadores encargados del procesamiento de dichas se nales de manera embarcada son parte de la carga de pago, as como el armamento, en caso de que lo hubiera, como por ejemplo, ametralladoras, cohetes y hasta misiles de diferentes alcances. Los sensores y equipos con los que el UAV cuenta y que son usados por los propios sistemas de control y navegaci on del veh culo no son tomados en cuenta a la hora de denir la carga de pago del UAV. Entre estos sensores se pueden contar aceler ometros, gir oscopos, completas unidades de medici on inerciales, magnet ometros, bar ometros, sistemas de posicionamiento tales como el GPS1 , y sistemas de comunicaciones por radio. Estos equipos no forman parte formalmente de la carga de pago, aunque tambi en proporcionen informaci on que unida a la de los equipos de la carga de pago puedan generar informaci on u til o inteligencia.
1.5.
Estaci on de Tierra
En cualquier caso, adem as del veh culo no tripulado, es necesario contar con una estaci on en tierra o GCS (Ground Control Station) capaz de recibir la informaci on que percibe el veh culo, y a trav es de la cual se pueda monitorizar y controlar toda la actividad del UAV. En algunos casos, esta estaci on est a formada por una estaci on ja, en otros por una unidad m ovil. En el caso de los veh culos militares, lo m as com un es contar con una unidad movil desplegable, desde la cual monitorizar y comandar al veh culo.
1
Global Positioning System (http://en.wikipedia.org/wiki/Global_Positioning_System)
EN ESPANA 1.6. SITUACION
Figura 1.8: Estaci on de Tierra GCS del UAV estadounidense de combate Predator. En el caso de UAVs de corto alcance, esta estaci on de tierra debe ser lo sucientemente exible como para poder ser desplegada en campo por los operarios. Quiz as cargada en una mochila dentro de un malet n debidamente protegido del exterior siguiendo los est andares militares, de modo que sea f acilmente desplegable y con una interfaz adecuada, de manera que sea capaz de proveer de informaci on u til en unas condiciones de combate.
1.6.
Situaci on en Espa na
En el caso de Espa na existen diferentes proyectos para el desarrollo de UAVs con capacidades tanto de combate como de reconocimiento [27]. Actualmente la empresa Cassidian, perteneciente al grupo EADS2 est a desarrollando un demostrador tecnol ogico UAV de largo alcance con capacidades de vuelo sigiloso y combate llamado nEUROn. Se trata de un proyecto en el que participan distintos pa ses europeos y en el cual Espa na desarrolla toda la estaci on de control en tierra y el software asociado (incluido comunicaciones). Espa na tambi en participa en el programa Talarion (tambi en a trav es de Cassidian) para el desarrollo, a nivel europeo, de un UAV ISTAR, aunque con la crisis iniciada en 2008 los presupuestos han sido congelados y las posibilidades de continuaci on del proyecto est an en el aire. Adicionalmente existe un programa para el desarrollo de un UAV ISTAR de tipo MALE completamente nacional llamado ATLANTE, del cual tanto el Ministerio de Defensa como m ultiples organismos civiles han mostrado inter es en adquirir y cuyo primer vuelo est a programado para Septiembre de 2011. Con el proyecto ATLANTE tanto la industria espa nola como el Ej ercito est an interesados en construir un demostrador tecnol ogico que desarrolle todas las capacidades necesarias para la construcci on de este tipo de veh culos y, de esta manera, poner a Espa na en la punta de lanza en lo que a tecnolog a UAV se reere. La participaci on en el pastel de los UAVs a nivel nacional ha despertado el inter es de peque nas empresas y grandes corporaciones como Indra o Thales.
European Aeronautic Defence and Space Company http://www.eads.com/eads/int/en.html
10
Figura 1.9: Demostrador tecnol ogico nEUROn. Un UAV de combate con capacidades de vuelo invisible (STEALTH). (Primer vuelo programado para 2012).
Figura 1.10: ATLANTE UAV. Proyecto de UAV tipo MALE totalmente espa nol que pretender ser un demostrador tecnol ogico de las capacidades del ej ercito y la industria espa nola. (Primer vuelo programado para Octubre de 2011).
Cap tulo 2 Objetivos

2.1. Descripci on del Problema
El objetivo de este Proyecto Fin de Carrera es la denici on, dise no y construcci on e implementaci on de un UAV de corto alcance (tipo Close) con caracter sticas VTOL (despegue y aterrizaje vertical). En este cap tulo se realizar a primero una descripci on general del objetivo a resolver. A continuaci on se resumir a la colecci on de requisitos impuestos al proyecto para, por u ltimo, denir la metodolog a utilizada durante todo el proceso de desarrollo. El proyecto en cuesti on se divide en tres partes o subobjetivos bien diferenciados: 1. Dise no e integraci on hardware. Esto incluye la selecci on de dispositivos a integrar, el dise no de las placas de circuito, las conexiones y la integraci on con el microcontrolador. Tambi en el dise no y construcci on del chasis del veh culo, la elecci on de componentes, as como la soluci on de los diferentes problemas t ecnicos derivados de la construcci on f sica del veh culo y de su puesta en funcionamiento. 2. Especicaci on, dise no, implementaci on e integraci on del software que ejecutar a en el microcontrolador embarcado del veh culo. Incluyendo la parte de comunicaciones, tanto aquellas destinadas a la telemetr a, como las interfaces hardware para interactuar con todos los sensores y actuadores del veh culo, as como los m odulos software encargados de la estabilizaci on y navegaci on. 3. Especicaci on, dise no, implementaci on e integraci on del software correspondiente a la estaci on en tierra, incluyendo la interfaz gr aca de usuario. En este caso una completa aplicaci on gr aca que permite al operador monitorizar e interactuar con el veh culo. Sin olvidar las utilidades de depuraci on y pruebas. Estas tres partes diferenciadas suman caracter sticas y dicultades muy diferentes, que abarcan desde el dise no e integraci on de componentes electr onicos, motores, bater as, sensores, etc., a la implementaci on de protocolos de comunicaciones por radio, algoritmos que sean capaces de procesar la informaci on de los sensores de modo que pueda ser usada por algoritmos de estabilizaci on, la implementaci on de esos mismos algoritmos de estabilizaci on, pasando por el dise no e implementaci on de interfaces gr acas amigables y u tiles. Sin olvidar 11
12
CAP ITULO 2. OBJETIVOS
Figura 2.1: Diagrama de componentes la costosa tarea de integraci on, depuraci on y pruebas de toda la plataforma que conforma el UAV, que por supupuesto ha de ser realizada con rigor. Aunque el objetivo principal es lograr que el veh culo resultante de este PFC sea funcional, el segundo objetivo, y no menos importante, es estudiar y poner en pr actica todas las fases de desarrollo necesarias para la implementaci on de un proyecto de Ingenier a tan completo. Es decir, analizar las diferentes fases que conllevan este tipo de proyectos, los problemas encontrados, las diferentes maneras de resolverlos, los costes de desarrollo, la capacidad necesaria para poder desarrollarlos, y al nal, estudiar y concluir, sobre el resultado obtenido, las caracter sticas y peculiaridades de este tipo de proyectos. Al tratarse de un proyecto con una complejidad y dimensi on elevada, ha sido necesario poner un l mite al proyecto estableciendo unas caracter sticas y funcionalidades bien delimitadas de modo que sea posible implementarlas en el marco de tiempo de un proyecto n de carrera.
2.2.
Requisitos
En primer lugar se proceder a a denir una serie de requisitos funcionales de alto nivel referidos a las capacidades y caracter sticas del UAV que se desea implementar. En segundo lugar se denir an, para cada una de las tres partes que componen el proyecto, una colecci on de requisitos funcionales con un nivel de especicaci on mayor, que ser an los que denan y limiten el marco del PFC. Dentro de estos requisitos se mezclar an requisitos funcionales, no funcionales y software (de bajo nivel). La intenci on no es presentar un documento 1 de especicaci on de requisitos software (SwRD ) sino orientar y limitar la dimensi on del desarrollo. Los requisitos de alto nivel denen los aspectos que convierten al proyecto en un UAV
1
Software Requirements Document
2.2. REQUISITOS de tipo Close:
13
REQ1. El veh culo debe ser capaz de volar de manera aut onoma, es decir, no radiocontrolado. REQ2. Debe ser capaz de despegar y aterrizar verticalmente, as como tener capacidades de vuelo est atico estable. REQ3. Se debe contar con una estaci on en tierra para monitorizar el estado del veh culo, tanto par ametros de estabilizaci on como de navegaci on. Tambi en se deben poder comandar determinados par ametros de navegaci on que se cargar an en el veh culo. REQ4. El veh culo debe ser capaz de seguir y mantener de manera aut onoma un plan de vuelo comandado a trav es de la estaci on de tierra (dicho plan de vuelo se limitar a en el marco del PFC a un vector de direcci on). REQ5. Debe tener una autonom a de 2 kil ometros desde el punto de lanzamiento, con un techo de altitud de 300 metros. REQ6. La estaci on de tierra debe poder ser ejecutada en un port atil, de manera que el UAV pueda ser f acilmente desplegable. REQ7. El veh culo debe ser capaz de soportar una carga de pago u til de 200 gramos.
Estos requisitos de alto nivel se convierten en las siguientes tres colecciones de requisitos de bajo nivel para cada una de las tres partes en las que se divide el proyecto.
2.2.1.
Requisitos Hardware
REQ8. El veh culo contar a con cuatro motores con sus controladores de velocidad electr onicos ESC2 encargados del impulso del modelo. REQ9. Contar a con un chasis principal con cuatro brazos en forma de cruz de manera que los motores queden en los extremos de los brazos, la separaci on de los motores puede variar entre 40 y 70 cent metros. REQ10. Dispondr a de un soporte para mantener una bater a de alta capacidad que alimentar a tanto los motores como la unidad central de procesamiento UC. REQ11. La unidad central de procesamiento (UC) se situar a en el centro del chasis e incorporar a un microprocesador encargado de realizar todo el procesamiento. REQ12. La UC contar a con una unidad inercial IMU (Inercial Measurement Unit) conformada por tres aceler ometros y tres gir oscopos. Tambi en contar a con un comp as digital y un bar ometro. Todos los sensores deben quedar perfectamente integrados en una placa de circuito consistente. REQ13. La UC dispondr a de un m odulo de radio encargado de comunicar el veh culo con la estaci on de tierra. Dicho m odulo debe tener la suciente autonom a como para cubrir el techo de distancia del veh culo.
2
ESC: Electronic Speed Controller
14
2.2.2.
Requisitos Software Embarcado
REQ14. El software debe ser capaz de comunicarse con los controladores de velocidad ESCs de cada uno de los cuatro motores de modo que sea capaz de inicializarlos y calibrarlos. REQ15. El software debe ser capaz de leer y procesar las lecturas de los sensores de modo que sea capaz de calcular a partir de las mismas el a ngulo de inclinaci on que forma el modelo con los tres ejes de coordenadas. REQ16. Tambi en debe ser capaz de obtener adecuadamente los datos de altitud barom etrica y temperatura. REQ17. El software debe implementar un protocolo de comunicaciones adecuado para poder comunicarse de manera inal ambrica a trav es del m odulo de radio con la estaci on de tierra. Debe ser capaz de enviar datos de telemetr a con la informaci on disponible a trav es de sus sensores, as como recibir y procesar comandos a trav es de los cuales se pueda cambiar el vector de direcci on a seguir. As como otros par ametros como la potencia total de los motores y comandos especiales de reinicio, parada de emergencia, o conguraci on de estabilizaci on. REQ18. El software debe ser capaz de transmitir diferentes tipos de mensajes a trav es del m odulo de comunicaciones, incluyendo mensajes de depuraci on, warnings, alarmas, etc. REQ19. El software contar a con un m odulo de estabilizaci on y otro de navegaci on. REQ20. El m odulo de estabilizaci on debe ser capaz de, tomando como entrada los valores le dos y procesados de la IMU, elegir la potencia adecuada a aplicar en cada uno de los motores para mantener el veh culo estabilizado en vuelo. REQ21. El m odulo de navegaci on debe ser capaz de, tomando como entrada los valores le dos y procesados de la IMU, elegir los cambios en la potencia de cada uno de los motores de modo que el veh culo sea capaz de adquirir el vector de direcci on demandado manteniendo el modelo estabilizado (m odulo de estabilizaci on tendr a mayor prioridad que el de navegaci on). REQ22. El software debe ser capaz de recibir y procesar un plan de vuelo consistente en una serie de vectores de direcci on separados en el tiempo. REQ23. El software debe implementar algoritmos de emergencia (con alta prioridad), tales como aterrizaje de emergencia, estabilizaci on en altura y otros del estilo que puedan ser comandados desde la estaci on de tierra, con independencia del plan de vuelo precargado con anterioridad. REQ24. El software debe estar lo sucientemente optimizado como para que en cada ciclo de ejecuci on el microprocesador sea capaz de realizar todas las tareas de lectura de datos, posterior procesamiento y comando de los actuadores, as como las tareas de comunicaciones y procesamiento de comando recibido, sin que ninguna de estas tareas sufran un retraso en su ejecuci on.
2.2.3.
Requisitos de Estaci on en Tierra
REQ25. El software de la estaci on en tierra (GCS) debe proporcionar una interfaz gr aca que permita al operador interacturar con el veh culo.
2.3. METODOLOG IA
15
REQ26. La GCS debe proporcionar informaci on del estado del enlace de datos con el veh culo, as como los comandos necesarios para establecer el enlace de datos. REQ27. La GCS debe proporcionar informaci on sobre el estado del modelo, incluyendo los a ngulos que forma con los ejes de coordenandas (Pitch, Roll y Yaw), tambi en informaci on sobre el rumbo actual del modelo (Heading), y de las diferentes medidas sin interpretar de los sensores de la IMU (aceleraciones lineales y velocidades angulares en los distintos ejes). REQ28. La GCS debe proporcionar una representaci on simplicada del veh culo en 3D de manera que el operador pueda conocer el estado del modelo sin tener visi on directa 3 del mismo. Tambi en debe contar con un PFD en el que se represente un horizonte articial con el alabeo (Roll) y cabeceo (Pitch) del modelo, as como una rosa de los 4 vientos que indique el rumbo (heading) del modelo respecto al norte magn etico. REQ29. La GCS debe proporcionar la informaci on de potencia comandada a cada uno de los motores, as como la posibilidad de cambiar manualmente la potencia total e individual de los mismos. REQ30. La GCS debe proporcionar una interfaz de calibraci on y pruebas donde se puedan realizar diferentes test de estabilizaci on. REQ31. La GCS debe contar con una consola de texto a trav es de la cual se puedan recibir mensajes con diferente informaci on del veh culo, incluyendo informaci on de depuraci on y test, as como diferentes tipos de avisos y alarmas (Warnings). REQ32. La frecuencia de refresco de los valores de telemetr a deben ser sucientes como para obtener una visi on realista del estado actual del modelo por parte de los operadores. REQ33. La GCS debe poder ser ejecutada en un port atil con recursos limitados (Procesador Intel Atom N260 y 512 MB de RAM) de forma agil y pr actica.
2.3.
Metodolog a
Al tratarse de un proyecto con una carga de hardware muy elevada y con dos desarrollos software bien diferenciados (parte embarcada y estaci on de tierra) la metodolog a debe ser sucientemente exible como para poder ser aplicada con exito a cada uno de las partes del proyecto. Se decidi o seguir una metodolog a basada en un proceso iterativo e incremental utilizado com unmente en entornos guiados por un desarrollo agil de software. De esta manera los incrementos del desarrollo software pueden servir para probar el desarrollo e integraci on de la parte hardware, permitiendo el avance y depuraci on de la parte hardware mientras se contin ua el desarrollo del siguiente incremento software, tanto en su versi on embarcada como de la estaci on de tierra. Para ello se denieron cuatro incrementos principales que suponen peque nos pasos tanto en software y hardware. Estos cuatro incrementos se denieron para cada uno de los tres subsistemas; hardware, software embarcado y estaci on de tierra.
Primary Flight Display Rosa de los Vientos: circulo que tiene marcados alrededor los rumbos en que se divide la circunferencia del horizonte.
4 3
16
Figura 2.2: Diagrama iterativo-incremental: Cada incremento pasa por las cuatro fases
Figura 2.3: Cada uno de los tres componentes evolucionan simult aneamente en los incrementos, coincidiendo a la nalizaci on de cada incremento en la fase de Integraci on y Pruebas.
2.3. METODOLOG IA Para cada uno de los incrementos se establecen cuatro fases: 1. Objetivos y Planicaci on 2. An alisis 3. Desarrollo (Implementaci on/Construcci on) 4. Integraci on y Pruebas Siendo el punto de nexo com un entre las tres partes la fase de pruebas e integraci on.
17
El primer incremento se llamo V0 y se corresponde con la primera toma de contacto y aprendizaje sobre las diferentes plataformas de desarrollo software y hardware. Incluye la familiarizaci on con los diferentes sensores y plataformas hardware a utilizar, sus interfaces, conexiones, etc. Por parte del software embarcado la familiarizaci on con la plataforma de desarrollo elegida (Arduino), su entorno de ejecuci on, peculiaridades de depuraci on e integraci on con las comunicaciones serie. Por parte del software de la GCS supone una introducci on al lenguaje de programaci on utilizado (Processing), la programaci on de interfaces 2D/3D con OpenGL5 y las comunicaciones serie con la plataforma Arduino. El segundo incremento o V1 es el primer incremento con funcionalidad espec ca derivada de requisitos para cada uno de los subsistemas: Plataforma Hardware: Construcci on de la primera versi on del chasis del veh culo, integraci on de motores y ESCs, integraci on del m odulo de comunicaciones radio con el microprocesador, conexiones el ectricas y primera versi on de IMU. Software Embarcado: Descomposici on preliminar en m odulos, primera versi on del protocolo de comunicaciones para permitir la transferencia de los primeros datos de sensores e informaci on de depuraci on a la consola de la GCS, implementaci on de la adquisici on de datos de aceleraciones y velocidades angulares, e inicializaci on y gesti on de la potencia de los motores. Software GCS: Primera versi on de la interfaz gr aca, modelo 3D del veh culo, primera versi on del horizonte articial, interfaz de comunicaciones, primera versi on del protocolo de comunicaciones, enlace activo de datos con el veh culo tanto por radio como por cable serie (conexi on directa a trav es de USB). El tercer incremento o V2 cuenta ya con una versi on avanzada de pr acticamente todas las funcionalidades de comunicaciones, estabilizaci on y depuraci on del UAV: Plataforma Hardware: Segunda versi on del chasis, integraci on en una placa de circuito de todos los sensores y microprocesador con las conexiones adecuadas, todo empaquetado en una caja. Desarrollo de una plataforma de test segura para realizar pruebas de estabilizaci on. Posibles mejoras en sensores, interfaces, conectores, etc. Integraci on de la bater a en el chasis.
OpenGL: Especicaci on est andar que dene una API multiplataforma para producir gr acos 2D y 3D http://www.opengl.org/
5
18
CAP ITULO 2. OBJETIVOS Software Embarcado: Mejoras en protocolo de comunicaciones, procesamiento de las lecturas de sensores, fusi on de los datos para obtener los a ngulos del veh culo con los ejes (Pitch, Roll y Yaw). Dise no e implementaci on del m odulo de estabilizaci on para la selecci on de salida a los motores a trav es de controladores de bucle cerrado PIDs. Esta versi on incluye la interfaz de calibrado y test din amico de par ametros de estabilizaci on. Software GCS: Mejoras en modelo 3D, desarrollo de PFD denitivo, herramientas de depuraci on y test, m odulo de grabaci on y reproducci on de datos con la capacidad de reproducir una sesi on de calibrado y de vuelo.
En el u ltimo incremento o V3 se a nade la funcionalidad necesaria para poder llegar a realizar vuelos de prueba con la suciente solidez, a nadiendo peque nos detalles y solucionando posibles problemas encontrados: Plataforma Hardware: Tercera versi on del chasis, integraci on del bar ometro y s onar, cambios de conectores para mejorar montaje nal, construcci on de un paragolpes protector que facilite las pruebas de vuelo, instalaci on de la antena de telemetr a denitiva. Software Embarcado: Integraci on de bar ometro, s onar y comp as digital. Integraci on en los bucles de control para controlar el rumbo. Optimizaci on de los diferentes algoritmos, incluyendo comunicaciones. Software GCS: Optimizaci on de la interfaz de mando y control, mejora de la disponibilidad y robustez de la aplicaci on, as como la inclusi on de las utilidades necesarias para soportar las pruebas de vuelo.
Cap tulo 3 Estudio de Alternativas

Antes de entrar de pleno en el proceso de desarrollo es necesario realizar un breve repaso de los proyectos m as signicativos en el campo de los UAVs, ya que gracias a ellos se pueden eliminar alternativas no v alidas en el dise no, o solventar problemas ya resueltos sobre los que no se desea profundizar demasiado. Se pueden encontrar, por un lado, proyectos de veh culos radiocontrolados que cuentan con cierto grado de autonom a, entre estos, se encuentran proyectos de aeroplanos radiocontrolados con microprocesador embarcado para facilitar y mejorar el control de vuelo. Tambi en veh culos de despegue vertical VTOL muy similares en conguraci on al objeto de este proyecto como [35],[1] o [45]. El grado de autonom a del veh culo es variable en cada proyecto, y va desde peque nas funcionalidades de auto-estabilizaci on para facilitar el control, hasta la plena autonom a del veh culo desde el despegue al aterrizaje, pasando por veh culos radiocontrolados con capacidades de vuelo en primera persona (haciendo uso de c amaras) e implementando m odulos de telemetr a muy completos [15].
3.1.
Mikrokopter
Mikrokopter es un proyecto no libre de origen alem an desarrollado por la empresa HiSystems [24] con un estado muy avanzado de desarrollo. El objeto del proyecto es un UAV VTOL de tipo Close muy similar al objeto de este proyecto, aunque con diferentes conguraciones de motores, entre 4 y 8. Para controlar el Mikrokopter han utilizado un microprocesador Atmel ATMEGA644 a 200MHz como unidad central, la unidad inercial es un desarrollo cerrado propio. Las principales ventajas de este proyecto es que comenz o su desarrollo en 2006, por lo que tras 5 a nos de desarrollo tanto la plataforma hardware como el software son muy robustos y funcionales. Adem as de la unidad inercial, cuenta con un m odulo de navegaci on opcional con GPS, 3 magnet ometros y soporte de tarjetas de memoria Flash, gestionado por un microcontrolador ARM9. La principal ventaja frente a proyectos similares es la capacidad de usar interfaces I2C1
1
I2C:Inter-Integrated Circuit, bus de comunicaciones serie de dos lineas desarrollado por Phillips
19
20
CAP ITULO 3. ESTUDIO DE ALTERNATIVAS
Figura 3.1: Mikrokopter con una conguraci on de 8 motores.
Figura 3.2: M odulo central de Mikrokopter.
Figura 3.3: M odulo de navegaci on con GPS, el acabado de las placas est a muy conseguido.
3.2. AEROQUAD
21
Figura 3.4: NicoletoMK basado en Mikrokopter (de los que se hablar a en profundidad m as adelante 7.2.1) para comandar potencia a los controladotes de velocidad, ya que esto permite tasas de actualizaci on del orden de 450 Hz en la salida a los motores, lo que les permite tener un control muy no sobre la potencia de los mismos, desembocando en un r egimen de estabilizaci on muy alto. Adem as cuentan con la experiencia de haber realizado gran cantidad de pruebas con diferentes conguraciones, por lo que las caracter sticas de potencia de los motores, distancia entre los mismos, tama no de las h elices, capacidad de las bater as, as como otras caracter sticas f sicas del veh culo son aspectos a tener en consideraci on. Por lo menos para tener la seguridad de que es posible llegar al objetivo con hardware y conguraciones similares. El estado de desarrollo es muy alto, cuentan con una estaci on de tierra muy completa, y el sistema es muy congurable, de modo que se puede desde radiocontrolar el veh culo apoyad andose en su control de estabilizaci on, hasta realizar un plan de vuelo completo con waypoints editables desde la GCS, pasando por la implementaci on de rutinas acrob aticas autom aticas. Tambi en es un buen proyecto para comparar el rendimiento conseguido con el desarrollo de este PFC, teniendo en cuenta las diferencias en presupuestos y recursos, tanto de tiempo, como de desarrolladores. Sobre la base de Mikrokopter existen otros proyectos orientados a explotar comercialmente las posibilidades del veh culo, como NikoletoMK [35] 3.4, que ha mejorado el chasis y ha a nadido una plataforma auto estabilizadora avanzada dedicada a la grabaci on de v deos a ereos en alta denici on.
3.2.
Aeroquad
Aeroquad es un proyecto open source de un UAV con las mismas caracter sticas que Mikrokopter. Cuenta con la ventaja de que es open source y que adem as la plataforma hardware sobre la que se desarrolla tambi en es abierta [1]. Aeroquad se basa en la plataforma Arduino para construir la unidad central (ATmega 328 a 16 MHz), sobre esta plataforma se profundizar a en el cap tulo de plataforma de desarrollo 4.1.
22
Figura 3.5: Aeroquad radiocontrolado Aunque no cuenta con el nivel de nalizaci on que tiene mikrokopter es un proyecto interesante en cuanto a que todo el c odigo es accesible y los resultados obtenidos son muy buenos, si bien, es cierto que estos resultados dependen de la calidad de los sensores y circuitos utilizados, siendo necesario un alto desembolso econ omico para poder replicar el proyecto original. Adem as, una de las desventajas de este proyecto es que, pese a ser un proyecto libre, intentan comercializar tanto con el hardware como con el soporte, por lo que es complicado obtener ayuda de la comunidad alrededor del mismo.
3.3.
Ardupilot
Ardupilot es un proyecto open source dedicado a obtener una unidad de navegaci on inercial libre, basada en la plataforma Arduino. Esta unidad de navegaci on puede ser utilizada en diferentes proyectos, por un lado en aeronaves radiocontroladas, por otro en proyectos de vuelo en primera persona (radiocontrolado pero sin visi on directa del veh culo y control andolo a trav es de c amaras instaladas en el veh culo), y por u ltimo en todo tipo de UAVs, tanto de despegue vertical como tipo aeroplano. Es un proyecto maduro, que cuenta con una buena comunidad alrededor que comercializa las placas de control en diferentes niveles de integraci on. La ventaja principal del proyecto es que han resuelto muy bien el problema de la fusi on de datos de diferentes sensores usando tanto ltros kalman avanzados, como algoritmos basados en matrices de cosenos directrices (DCM2 ). Cuentan en su comunidad con una verdadera eminencia en el desarrollo del algoritmo de Matrices de Cosenos Directrices como W. Premerlani [43], y cuentan con un c odigo muy
2
DCM: Direction Cosine Matrix
3.3. ARDUPILOT
23
Figura 3.6: Ardupilot: unidad de navegaci on inercial.
Figura 3.7: Ardupilot sobre un Easy Glider, implementa funciones de piloto autom atico. optimizado. Por lo que este proyecto es una gran fuente de conocimiento en el caso de tener problemas con este tipo de algoritmia. Existen diferentes proyectos basados en el c odigo de fusi on de datos de Ardupilot. El proyecto pertenece a una comunidad a un mayor llamada DIYDrones (Do It Yourself Drones) [15] orientada al desarrollo de UAVs a peque na escala basados, sobretodo, en aeroplanos. Por u ltimo existen diferentes proyectos orientados al mismo n que no son tan signicativos, en algunos casos porque son clones de los anteriores o basados en ellos, y en otros porque se trata de desarrollos cerrados tanto en hardware como software [39], aunque son dignos de menci on al tener disponible informaci on u til de alguna manera para este PFC. Entre ellos esta Quaduino [45], un proyecto personal de UAV cuadrimotor que toma como base el software de Ardupilot. Tambi en UAVP [34] un proyecto alem an dirigido a conseguir un mikrokopter de c odigo abierto basado en plataformas hardware propias y soluciones de sensores diferentes. Tambi en MiKuadricoptero [16], un proyecto open source espa nol con motivaciones did acticas que comenz o en tiempo a la vez que este PFC y que, aunque nalmente el desarrollo de Mikuadricoptero fue sustancialmente m as lento que el de este PFC, en las primeras fases fue de gran ayuda conocer diferentes maneras de afrontar problemas similares.
24
Cap tulo 4 Entorno de Desarrollo

4.1. Arduino
La primera elecci on importante dentro del proyecto fue la de seleccionar la plataforma hardware y el entorno de desarrollo. En primer lugar se debe elegir el microcontrolador y la arquitectura sobre la que desarrollar el software embarcado. Existen distintas soluciones muy diferentes unas de otras, desde usar microcontroladores tipo PIC1 con arquitectura RISC2 utilizando directamente lenguaje ensamblador, hasta utilizar un computador embebido tipo PC/104 [41] con una arquitectura similar a la de un PC corriente y usando un lenguaje de alto nivel, pasando por plataformas intermedias basadas en diferentes microcontroladores (ARM3 u otros dise nos RISC) con entornos de desarrollo propios, amigables y pr acticos, como los basados en la plataforma .NET MicroFramework4 , o Arduino. Tras analizar los proyectos de UAVs similares y comparar las diferentes opciones de plataformas de desarrollo se decidi o usar la plataforma Arduino. Las principales razones para usar dicha plataforma fueron:
Por un lado las ventajas de ser una plataforma abierta, tanto en software como en hardware y con una amplia comunidad alrededor. Esto posibilita el f acil acceso a foros de ayuda tanto de desarrollo software embarcado como de integraci on de la plataforma con diferentes soluciones hardware, incluyendo integraci on con gran cantidad de sensores y actuadores. En segundo lugar, la existencia de dos o tres proyectos de c odigo abierto con objetivos comunes con este PFC y basados en la plataforma Arduino, siendo el m as importante de ellos ArduPilot. Estos precedentes garantizan la seguridad de que la plataforma es v alida, adem as de proveer una v a de comunicaci on a trav es de la que se puede pedir ayuda en caso de ser necesario.
Peripheral Interface Controller Reduced Instruction Set Computer 3 ARM: Advanced Risc Machines http://es.wikipedia.org/wiki/ARM 4 .NET Microframework es una plataforma open source .NET para usar en dispositivos de recursos limitados que incluye versiones reducidas de las principales librer as y utilidades .NET http://www.microsoft. com/en-us/netmf/default.aspx
2 1
25
26
CAP ITULO 4. ENTORNO DE DESARROLLO
Figura 4.1: Plataforma hardware Arduino UNO. Por u ltimo la familiaridad con el entorno debido a experiencias anteriores con la plataforma, y el conocimiento de las posibilidades tanto del software como de las interfaces externas con las que cuenta. Arduino es una plataforma muy exible de hardware/software abierto para el desarrollo de proyectos de electr onica. B asicamente cuenta con una placa dise nada alrededor de un microprocesador ATmega328 de Atmel de 16MHz que cuenta con 14 entradas/salidas digitales y 6 entradas anal ogicas, 32 KB de memoria Flash, 1 KB de memoria EEPROM y 2 KB de SRAM. Para programar el microprocesador se utiliza un lenguaje de programaci on propio (Arduino Programming Languaje) basado en Wiring [9] y un entorno de desarrollo (Arduino Development Environment) basado en Processing [10], [3]. El lenguaje es de tipo estructurado con una sintaxis similar a la utilizada por el lenguaje Java. El entorno de desarrollo permite desplegar el c odigo f acilmente a trav es de una interfaz USB que conecta con la placa Arduino. Entre las ventajas de la placa Arduino se encuentran la disponibilidad de un controlador UART para comunicarse a trav es de puerto serie, una interfaz USB para comunicaci on con el entorno de desarrollo Arduino, puertos para comunicaciones serie I2C muy utilizado en sensores digitales, soporte de comunicaciones SPI5 , soporte de salidas de modulaci on por ancho de pulsos PWM6 , en denitiva grandes posibilidades de integraci on con circuitos y dispositivos electr onicos. Dentro de la plataforma Arduino existen diferentes conguraciones de placas. Aunque todas cuentan con similares caracter sticas principales y son compatibles entre s , se diferencian entre ellas por el nivel de integraci on y por las capacidades del microprocesador. La versi on est andar de Arduino en la fecha de presentaci on de este documento es la llamada Arduino UNO, basada en el micro Atmega328. Con las mismas caracter sticas de la
5
SPI: Serial Peripheral Interface http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_
Bus PWM: Pulse Width Modulation es una t ecnica utilizada para control de dispositivos electronicos inerciales, consiste en codicar un voltaje midiendo la longitud de pulsos on/o que se env an. http: //en.wikipedia.org/wiki/Pulse-width_modulation
6
4.1. ARDUINO
27
Figura 4.2: Placa Arduino Nano, mayor nivel de integraci on manteniendo las caracter sticas y compatibilidad.
Figura 4.3: Mini, el m as peque no de todos los Arduinos.
Figura 4.4: Plataforma Seeeduino. Basado en Arduino, cuenta con un dise no optimizado y diferentes mejoras y optimizaciones en las prestaciones.
28
Figura 4.5: Entorno de desarrollo Arduino. versi on est andar pero con mayor nivel de integraci on aparecen las versiones Arduino Nano, con un tama no aproximado de una tercera parte de la versi on UNO, y Mini, con un tama no de la mitad del Nano. Tambi en existe una versi on UNO que en lugar de usar un microcontrolador con formato 7 extraible DIP usa uno de montaje supercial SMD8 . Tambi en se puede encontrar una versi on extendida llamada Arduino Mega que cuenta con un micro ATmega2560 con mayor memoria y n umero de entradas anal ogicas/digitales. El proyecto Arduino cuenta, a su vez, con bifurcaciones que, tomando como base la plataforma Arduino, han realizado modicaciones en el hardware para dotar al mismo de mejoras, tanto en dise no optimizado hardware como en las caracter sticas del mismo, mayor n umero de entradas/salidas, reguladores de tensi on, interfaces de comunicaciones, etc. Cabe destacar un proyecto alternativo basado en Arduino llamado Seeeduino desarrollado por la comunidad Seeed Studio [47]. Este proyecto proporciona caracter sticas funcionales extendidas que mejoran el dise no original (diodo zener 3v3 integrado, soporte de mayor amperaje en las salidas, conector mini USB, entrada de potencia tipo JST y conectores inferiores para integrar la placa en una placa de prototipado).
DIP: Dual in-line Package es una forma de encapsulamiento de circuitos integrados donde los pines del circuito quedan dispuestos en hileras paralelas http://es.wikipedia.org/wiki/Dual_in-line_package 8 SMD: Surface Mount Technology, una forma de encapsulamiento m as compacta donde el circuito se monta directamente en la placa o PCB(Board) http://en.wikipedia.org/wiki/Surface-mount_technology
7
4.2. PROCESSING
29
Aunque en el primer prototipo V1 de la plataforma hardware se utiliz o una versi on anterior del Arduino UNO llamado Arduino Duemilanove, en los dos siguientes prototipos se utiliz o un Seeeduino V2.12.
4.2.
Processing
Una vez seleccionada la plataforma de desarrollo hardware y software embarcado, es necesario seleccionar el lenguaje y entorno de desarrollo para la estaci on de tierra (GCS). Para el desarrollo del software de GCS las posibilidades eran a un mayores, ya que dicho software se ejecuta en una plataforma PC (un ordenador port atil), por lo que se pod a haber seleccionado cualquier lenguaje de alto nivel. Dados los requisitos de la interfaz gr aca de la estaci on en tierra, el lenguaje deb a facilitar el dibujado de gr acos 3D/2D. Aunque casi todos los lenguajes se integran f acilmente con 9 las APIs de representaci on de gr acos 3D/2D como OpenGL o DirectX, se decidi o usar Processing [10] dada su especial compatibilidad con la plataforma Arduino. Processing es un lenguaje y entorno de programaci on de c odigo abierto para el desarrollo de aplicaciones gr acas interactivas y proyectos multimedia basado en bocetos o sketches. Al estar basado en Java puede heredar todas las funcionalidades del mismo as como extenderse y usar todo tipo de librer as ya creadas para dicho lenguaje. Adem as provee una interfaz de programaci on para la visualizaci on de gr acos muy intuitiva y con soporte de OpenGL. Los desarrolladores de Arduino tomaron como modelo el lenguaje y el entorno de desarrollo de Processing PDE (Processing Development Environment), por lo que la integraci on de proyectos software/hardware Arduino con aplicaciones Processing es muy completa. Una consecuencia de esta complicidad es la unicaci on de la sintaxis de ambos lenguajes. Aunque uno tome como base Java (Processing) y otro Wiring/C (Arduino) el formato y estructura de los cheros de c odigo fuente es muy similar, por lo que la curva de aprendizaje disminuye considerablemente. Tanto Processing como Arduino cuentan con un modelo de ejecuci on basado en un planicador c clico. La manera de programar en ambos lenguajes es a trav es de sketches. Un sketch no es m as que un c odigo estructurado en dos m etodos principales. El primer m etodo es el procedimiento de setup o inicializaci on, que se ejecutar a una sola vez al comienzo de la ejecuci on del programa y antes que cualquier otro. Sirve para inicializar las diferentes variables, estructuras, librer as o aquello que sea necesario. Tanto en Arduino como en Processing este procedimiento est a instrumentalizado en la funci on setup(). El otro m etodo se ejecutar a de manera c clica. En el caso de Arduino toma el nombre de loop(), mientras que en Processing es void draw(). Aunque estos m etodos se ejecuten una vez en cada ciclo, el dise nador puede utilizar las diferentes estructuras de control para denir los periodos de ejecuci on que desee, implementando un completo planicador que seleccione el c odigo a ejecutar en cada ciclo. En el caso de Arduino, el m etodo loop() hace de punto de entrada a la ejecuci on, pudiendo estructurar la misma en diferentes m etodos y funciones, teniendo en cuenta que el paradigma de programaci on es estructurado, y que la memoria y velocidad de procesado son limitados.
9
Application Programming Interface
30
Figura 4.6: Entorno de desarrollo Processing. Por esta u ltima raz on en algunos casos se ha preferido una codicaci on optimizada y eciente frente a un c odigo legible (elecci on de estructuras de control, dominio de las variables, etc.). Por otro lado Processing permite cierta exibilidad a la hora de programar. Se puede utilizar el lenguaje para implementar c odigo similar al scripting pero sin ser interpretado. Tambi en se puede utilizar toda la potencia del paradigma orientado a objetos que facilita Java. En este caso al no tener problemas de memoria o velocidad de ejecuci on tan importantes como el caso de Arduino, se ha preferido usar siempre un enfoque orientado a objetos siguiendo los preceptos de abstracci on, encapsulaci on y modularidad. Conceptos que se han aprovechado especialmente a la hora de desarrollar elementos gr acos exibles que puedan ser instanciados varias veces, y la composici on de elementos gr acos complejos a partir de elementos simples.
Cap tulo 5 An alisis

Antes de entrar en el detalle del desarrollo es necesario realizar un peque no an alisis del problema a resolver. Ya que el objeto del proyecto es desarrollar un veh culo a ereo no tripulado, en primer lugar cabe preguntarse c omo hacer que el veh culo sea capaz de elevarse, y cu ales son los mecanismos disponibles para controlar el veh culo.
5.1.
Principios de Sustentaci on y Movimiento
La conguraci on de cuatro motores en los extremos de una cruz, que le coneren la caracter stica de despegue y aterrizaje vertical, tambi en hace que el veh culo no se apoye en planos aerodin amicos jos para lograr el empuje necesario para elevarse, tal y como sucede en los veh culos con conguraci on de aeroplanos. Para elevar el modelo es necesario conseguir un empuje hacia abajo cuyo resultado sea una fuerza inercial hacia arriba que venza la fuerza de la gravedad elevando as el veh culo. Dicho empuje es generado por el rozamiento de los planos de las h elices con el aire debido al giro. Cada h elice est a formada por dos palas, cuya forma es tal que el plano de cada pala no es paralelo al plano XY de la horizontal, sino que se encuentran giradas formando un angulo con la horizontal. De esta manera, al girar la h elice se ejerce un empuje sobre el aire en dos componentes por cada pala, donde una de ellas ser a vertical. El sentido del giro de la h elice se elige de manera que la componente vertical sea hacia abajo. El a ngulo de una pala es el inverso del de la contraria para que ambos empujes tengan el mismo sentido. El resultado es una fuerza inercial hacia arriba sobre todo el conjunto 5.1. Sin embargo, no es la u nica componente generada, el empuje del plano de la h elice contra el aire es perpendicular al plano de cada pala, por lo que existe una componente horizontal que sigue el sentido del giro de las palas. Estos empujes resultan en una fuerza inercial en el sentido contrario al giro de cada pala. Cada h elice esta formada por dos palas que forman angulos contrarios con el plano, por esta raz on la componente horizontal inercial en cada pala est a formada por el mismo vector pero con sentidos contrarios. Esto hace que las componentes lineales se anulen, pero aparece un momento en sentido contrario al giro de la h elice tal y como se muestra en 5.1. Al sumar todas las fuerzas ejercidas queda una resultante vertical hacia arriba y un momento en el sentido contrario al giro de la h elice. Con un solo motor el veh culo se elevar a, pero tambi en girar a sobre el eje del motor 31
32
CAP ITULO 5. ANALISIS
Figura 5.1: Diagrama de descomposici on de las distintas fuerzas, as como la fuerza inercial resultante y el momento angular resultante.
Figura 5.2: Inerciales y momentos resultantes: Se pueden ver las inerciales y momentos que aporta cada h elice al conjunto.
Y MOVIMIENTO 5.1. PRINCIPIOS DE SUSTENTACION
33
Figura 5.3: Inercial total y momento angular total del conjunto. El momento total es nulo.
en el sentido contrario al giro del mismo. Si en lugar de uno contamos con dos motores en paralelo separados por una distancia, y sentidos contrarios entre s , los momentos debidos al giro de cada motor se superpondr an. Anul andose el momento total sobre el conjunto del veh culo (suponiendo misma velocidad de giro en ambas h elices). Sin embargo, para permitir al veh culo moverse con los diferentes grados de libertad con solo dos motores ser a necesario contar con la capacidad de controlar el a ngulo que forma el plano que se abstrae del giro de las h elices respecto a la horizontal. Inclinando dichos planos la inercial resultante, antes vertical, ahora tendr a otras componentes, y jugando con dichas componentes se conseguir a el movimiento en las diferentes direcciones. Controlar los angulos que forman h elices y horizontal es complicado ya que la mec anica debe permitir el giro independiente de cada bloque motor. Mientras que a nadiendo dos motores m as al conjunto y jugando con las potencias suministradas a cada motor, se pueden conseguir las diferentes resultantes que hacen que el veh culo se mueva con los grados de libertad deseados. En la gura 5.2 aparecen los momentos e inerciales para cuatro motores. Para facilitar el control y simplicar el modelo te orico de componentes, lo ideal es situar los motores de manera que los planos de las h elices sean los mismos y paralelos al plano horizontal, formando los v ertices de un cuadrado, situando los dos motores que giran en el mismo sentido en los v ertices de la diagonal del cuadrado. De esta manera, para elevar el veh culo tan solo es necesario aplicar la misma fuerza angular a cada h elice, as las diferentes componentes horizontales quedar an anuladas, adem as del momento angular del conjunto 5.3, quedando tan solo la fuerza inercial vertical hacia arriba que har a que el veh culo se elevase. En la gura 5.4 se muestran los diferentes angulos de movimiento y los ejes de giro para cada tipo de movimiento, que se describir an detalladamente a continuaci on.
34
Figura 5.4: Relaci on de a ngulos pitch, roll y yaw.
5.1.1.
Pitch
Si consideramos uno de los lados del cuadrado que forman los motores como el frente del veh culo y trazamos una l nea recta perpendicular a dicho lado que cruce el plano del veh culo, estar amos deniendo el eje de cabeceo. Se llama a ngulo de cabeceo o pitch al a ngulo que forma dicho eje con el plano horizontal de referencia. Cuando el a ngulo pitch es positivo el veh culo se encuentra inclinado hacia atr as, de manera que el frente o cabeza del veh culo mira hacia arriba, de igual manera, cuando es negativo el frente del veh culo mirar a hacia abajo. As , cuando el veh culo est a completamente horizontal el angulo de pitch ser a 0, y si el veh culo se encuentra perpendicular a la horizontal el pitch ser a 90 o -90 dependiendo de la orientaci on del mismo.
Figura 5.5: Para ganar a ngulo de pitch aumenta el empuje de los motores frontales respecto al resto, de manera que aparece un desplazamiento horizontal asociado.
Y MOVIMIENTO 5.1. PRINCIPIOS DE SUSTENTACION
35
Figura 5.6: Para que el veh culo se incline ganando roll, aumenta la potencia de los motores laterales respecto al resto, como consecuencia aparece un desplazamiento lateral asociado. Para avanzar en una determinada direcci on, la t ecnica utilizada por este tipo de veh culos a ereos consiste en desequilibrar el mismo, de manera que la resultante inercial tenga una componente horizontal en la direcci on deseada, tal y como se muestra en la gura 5.5. Los dos motores que quedan en los extremos del lado del cuadrado que hemos denominado frente son los dos motores frontales. Si se proporciona mayor velocidad angular a dichos motores se producir a un mayor empuje del frente del veh culo, haciendo que el veh culo comience a girar sobre s mismo ganando angulo de pitch. Al girar el modelo sobre s mismo se genera una componente horizontal en el empuje que permitir a moverse hacia atr as a todo el conjunto. Las velocidades de rotaci on de los motores deben compensarse de modo que el veh culo gire sobre s mismo hasta alcanzar un pitch determinado que sea capaz de mantener. Al aumentar la potencia de los motores delanteros es necesario regular la potencia de los traseros para que la componente vertical se mantenga constante y, de esta manera, el veh culo se mantenga estable en la vertical. Al ser el giro de los dos motores delanteros contrario entre s (al igual que ocurre con los traseros), se anular an los momentos por lo que no existir a ning un otro giro. Para hacer el veh culo avanzar hacia delante se realiza la misma estrategia pero logrando un pitch negativo, la cabeza del veh culo mirar a hacia abajo.
5.1.2.
Roll
Si an alogamente al eje de pitch se traza un eje perpendicular que atraviesa longitudinalmente el plano del veh culo se obtendr a el eje de alabeo o roll. El a ngulo formado por dicho eje con el plano horizontal se denomina a ngulo de alabeo o simplemente roll. De la misma manera que en el caso del pitch, se puede lograr movimiento lateral si se aumenta la velocidad de giro de dos motores de un mismo lateral de forma que se logre un
36
Figura 5.7: Esquema de giro Yaw. Para que el veh culo gire sobre s mismo se aumenta la potencia por igual a una de las parejas de motores que giran en el mismo sentido respecto al otro par, como consecuencia aparece un momento angular no nulo que permite el giro. determinado angulo de roll tal y como se muestra en la gura 5.6. En cualquiera de los casos (pitch o roll ), se podr a lograr que el modelo girara sobre s mismo completamente aplicando la suciente diferencia de potencia en los motores de dos extremos. Sin embargo, este giro completo vendr a acompa nado siempre por un movimiento de traslaci on ya que el empuje de todos los motores tiene el mismo sentido (dado por la geometr a de las h elices). Aunque esta traslaci on en los giros puede ser corregida una vez alcanzada la posici on deseada.
5.1.3.
Yaw
El giro sobre s mismo del veh culo mientras se mantiene en el plano horizontal (pitch y roll nulos) se denomina gui nada o yaw. Para lograr este tipo de giro el plano del veh culo permanece horizontal, y el desequilibrio no afecta a las componentes lineales del empuje, sino a los momentos resultantes de los giros. En los casos anteriores de pitch y roll, se establec a siempre la misma velocidad angular a pares de motores con sentidos de giro contrarios para mantener el momento total nulo. Sin embargo, en la gura 5.7 se puede ver como si se da diferente potencia a motores con giros contrarios aparece un momento angular que hace girar sobre s mismo el veh culo. Este desequilibrio del momento angular no afecta a las componentes lineales debido a que se proporciona la misma velocidad angular por pares de motores que giran en el mismo sentido y que se encuentran situados en la misma diagonal. Para girar en un sentido u otro tan solo hay que elegir adecuadamente los pares de motores a potenciar, de manera que el momento tenga un sentido u otro.
Cap tulo 6 Plataforma Hardware

En este cap tulo se describir a el dise no e implementaci on de la plataforma hardware, incluyendo la integraci on hardware, as como las dicultades encontradas y la soluci on propuesta a cada una de ellas. El cap tulo se divide en tres secciones, una dedicada a la estructura f sica, otra a los sensores y la u ltima al dise no de la placa que conforma la unidad central. Dentro de cada secci on se diferenciar a entre los tres prototipos resultantes de cada incremento realizado deniendo los avances entre cada uno de ellos.
6.1.
Estructura F sica
La estructura b asica o chasis del veh culo es parte fundamental del proyecto ya que de ella depende la correcci on de las asunciones realizadas respecto al control del modelo. Tal y como se ha descrito en el cap tulo de an alisis, el veh culo estar a equipado con 4 motores montados en una estructura que permita mantener los motores equidistantes. Adem as dicha estructura debe permitir montar una unidad central que ocupa espacio al estar formada por una unidad de procesamiento, todos los sensores, las bater as, los controladores de los motores, incluso la antena de comunicaciones, adem as del cableado que permite la interconexi on de todos los elementos. Para la estructura principal existen diferentes alternativas, desde construirla en madera de balsa mezclada con diferentes materiales livianos, hasta usar varillas de bra de carbono. Sin embargo, existen multitud de proyectos de multic opteros que permiten adquirir parte del chasis por separado, como Mikrokopter, por lo que se decidi o no perder demasiado tiempo en la construcci on del chasis y se opt o por comprar un chasis b asico de Mikrokopter. Dicho chasis est a formado por cuatro varillas de aluminio que se unen en una cruceta central. En dicho chasis se pueden montar los motores en los extremos. La distancia elegida entre motores fue de 50 cm que se corresponde con la distancia entre motores de los modelos m as grandes de Mikrokopter o Aeroquad. Los motores elegidos fueron unos HackerStyle Outrunner 20-20L. Estos motores sin escobillas son capaces de girar a 1050 rpm (revoluciones por minuto) por Voltio y precisan unos 15 Amperios de media (con picos de 19 A), alimentados a trav es de controladores 37
38
CAP ITULO 6. PLATAFORMA HARDWARE
Figura 6.1: Chasis b asico de Mikrokopter
Figura 6.2: Conjunto de motor con h elice APC de 4.7 x 10 o variadores electr onicos de velocidad ESC com unmente utilizados en radio control y que fuesen capaces de soportar dicho amperaje. Estos motores se escogieron tras un an alisis de las diferentes alternativas teniendo en cuenta el peso, potencia, amperaje y tasa de giro por voltio (en el Ap endice 12 se puede consultar la comparativa). Junto con los motores se estudiaron las h elices, seleccionando unas h elices de 4.7 x 10 de la marca APC, elegidas por su rendimiento de empuje en relaci on con resistencia. En el Ap endice 12 se puede observar la comparativa de h elices respecto a empuje y consumo.
6.1.1.
Incremento V1
Para el primer incremento se usaron los motores descritos anteriormente en conjunto con los ESC Turnigy Plush 30. Dichos variadores soportan picos de hasta 30 A a 11.1 V, suciente para dar el mayor rendimiento a los motores/h elices. Para alimentar dichos variadores se eligi o usar bater as de Litio Pol mero (LiPo) dado su
6.1. ESTRUCTURA F ISICA
39
Figura 6.3: Detalle de los ESCs con los conectores cambiados para facilitar la conexi on con la UC
Figura 6.4: Primer banco de pruebas
gran relaci on peso capacidad. Para este incremento se usaron bater as LightMax formadas por tres celdas de 3.7 V. Estas bater as soportan una tasa de descarga de hasta 20 A y cuentan con una capacidad de 1500 mAh (Miliamperios/Hora). Para m as informaci on sobre las bater as LiPo y sus peculiaridades se puede consultar el Ap endice 12. En lo que respecta a la unidad central de proceso (UC), esta no contaba con soporte a un y quedaba sujeta a trav es de un velcro a la parte central del chasis. Las conexiones entre UC y ESCs se realizan usando los conectores originales de los ESCs de radio control. Como en este primer incremento a un no se pod a usar el chasis nal para probar, se construy o un banco de pruebas en madera, simulando uno de los ejes, dos motores con sus ESCs y una visagra central de modo que se pudiera mover como un balanc n En el cap tulo de Pruebas 10 se dan detalles sobre los bancos de tests. Para estas pruebas se utiliz o una fuente de alimentaci on para no malgastar ciclos de carga/descarga de las baterias y evitar perder tiempo entre cargas.
40
Figura 6.5: Detalle de plataforma aislante, soporte de bater as y variadores ESC HK nales.
6.1.2.
Incremento V2
Para el segundo incremento se construy o un banco de pruebas avanzado que permitiera ajustar el chasis del veh culo entre dos posiciones elevadas, de modo que se dejase libre un solo eje del veh culo para probar la estabilizaci on. En este incremento tambi en se cambi o el soporte de la UC por una caja de un pol mero resistente. Se dise no una peque na plataforma de metacrilato para unir el soporte de la UC con la parte central del chasis a trav es de velcro. Por u ltimo se realiz o un soporte inferior para las bater as tambi en usando metacrilato. Tambi en se cambiaron los conectores originales de los ESCs de tres cables por otros de dos cables (ya que solo se necesitaba la l nea de tierra y la de control, ver Ap endice 12 ). En esta iteraci on se realizaron tests con bater as de 1500 mAh y de 1800 mAh para analizar el consumo y autonom a del veh culo.
6.1.3.
Incremento V3
En la u ltima iteraci on se procedi o a cambiar el cableado para ajustarlo de modo que quedasen los cables lo m as ordenados y el modelo m as compacto. Sin embargo, al cambiar el cableado de los ESCs y cambiar de nuevo los conectores por otros m as id oneos ocurri o un accidente con los ESCs que hizo que se estropeasen dos de ellos. Al ir a sustituirlos result o que no exist a stock de dicho modelo, por lo que hubo que adquirir cuatro ESCs nuevos diferentes. Se opt o por los m as econ omicos que cumpliesen las caracter sticas de Rpm por Voltio, seleccionando unos HobbyKing SS Series 18-20 que soportan picos de 20 A (menos que los Turnigy), pero pesan menos y son m as econ omicos. Adicionalmente se adquirieron varias bater as de distinta capacidad, incluyendo una de 4000 mAh y 360 gramos de peso (las anteriores de 1800 mAh pesaban 160 gramos), para poder hacer pruebas de autonom a y poder seleccionar las que mejor relaci on diesen.
6.2. SENSORES
41
Figura 6.6: Protector de poliestireno usado en pruebas de vuelo. Debido a un problema con las vibraciones trasladadas desde los motores a la unidad central y a la distorsi on que provocaba dicha vibraci on en los sensores, se estudiaron varias soluciones para aislar la UC. Entre las soluciones estaba el uso de un gel diel ectrico para envolver a la unidad inercial, el uso de gomas para amortiguar el anclaje de los motores al chasis y la construcci on de una plataforma aislante para el anclaje de la UC al chasis. El gel diel ectrico se descart o por el alto coste. Se dispusieron gomas entre los motores y el chasis y se construy o la plataforma aislante a base de varias capas de metacrilato y polietileno elasticado unidas por cola de contacto (Fig.6.5). La soluci on aislante result o todo un exito al hacer desaparecer casi al completo las vibraciones y liberar a la UC de costosos ltros software para paliar el efecto de las mismas. Por u ltimo, para poder realizar pruebas completas de estabilizaci on fuera del banco de pruebas, se construy o un protector formado por cuatro placas de poliestireno expandido cubriendo todo el chasis, como se muestra en la g 6.6 se dejan aperturas para las h elices y la antena de comunicaciones. De esta manera se pueden realizar pruebas m as seguras al proteger las h elices de posibles choques.
6.2.
Sensores
Los sensores involucrados en la estabilizaci on del veh culo deben proporcionar las entradas sucientes para que la UC pueda calcular con precisi on los a ngulos que forma el veh culo respecto a los diferentes ejes de referencia. B asicamente se trata de encontrar los a ngulos que separan los ejes del modelo de los ejes que forman el sistema de coordenadas de referencia, teniendo en cuenta que no podemos asegurar que el modelo no est a en movimiento, ni tampoco que no cuenta con cierta aceleraci on en alguno de sus ejes, por lo que el modelo puede considerarse un marco de referencia no inercial. Por lo tanto, el conjunto de sensores y algoritmos matem aticos, necesarios para conocer
42
con precisi on los a ngulos de estabilizaci on, deben ser capaces de calcular dichos a ngulos independientemente de si el modelo est a acelerado o no. Este conjunto se denomina IMU (Inercial Measurement Unit) o unidad de medici on inercial, ya que permite calcular la orientaci on exacta del veh culo respecto al eje de referencia de la tierra independientemente de si el veh culo est a acelerado o no. Aunque existen soluciones de IMUs completas que solucionan el c alculo de los angulos, estas son soluciones caras. Adem as se consider o interesante analizar y resolver este problema como una parte m as del proyecto. Por esta raz on se decidi o implementar los algoritmos y construir la IMU a partir de los sensores implicados para lograr una IMU eciente de bajo coste. Para la construcci on de una IMU existen varios tipos de sensores en el mercado. El primero es el grupo de sensores que miden aceleraciones lineales o aceler ometros. Estos sensores son capaces de medir la aceleraci on instant anea que sufre el veh culo en un eje concreto en un momento dado. Dentro del marco de referencia de la tierra, cualquier objeto con masa est a sometido constantemente a una aceleraci on conocida en la direcci on del eje z y hacia abajo. Esta aceleraci on es debida a la fuerza de la gravedad. Ya que esta aceleraci on siempre est a presente se puede llegar a realizar una primera aproximaci on al c alculo de los a ngulos (pitch ), (roll ) y (yaw ) midiendo la proporci on de la aceleraci on de la gravedad que se mide en los diferentes ejes del veh culo. La aceleraci on de la gravedad se descompondr a en los diferentes ejes del modelo proporcionalmente a los angulos que estos ejes formen con el eje z. El segundo tipo de sensores u tiles para el prop osito de la IMU son los gir oscopos o giroscopios, sensores que miden la velocidad angular en un instante dado para un eje del modelo. En otra aproximaci on se podr an acumular las diferentes velocidades angulares que el modelo ha sufrido durante un periodo de tiempo y calcular una aproximaci on del giro total que ha sufrido el veh culo desde su posici on inicial.
6.2.1.
Aceler ometros
El aceler ometro es un sensor que es capaz de medir las aceleraciones sufridas en un eje particular, tambi en existen sensores que miden aceleraciones en diferentes ejes. Hay diferentes tipos de aceler ometros. Los aceler ometros mec anicos cuentan con un peque no peso y varios muelles que lo sujetan dentro de un espacio cerrado al vac o. Los muelles se encuentran dispuestos en l nea con el eje que se desea medir y sujetan el peso entre medias, de modo que si el peso sufre alguna aceleraci on la inercia har a que el peso se desplace, estirando o encogiendo los muelles que lo sujetan. El sensor se limita a medir la deformaci on de los muelles y convertirlo en una se nal el ectrica. Otro tipo de aceler ometros no son mec anicos, sino que se basan en traspaso t ermico por convecci on natural, es decir, miden cambios internos por la transferencia de calor causada por la aceleraci on sobre mol eculas de gas. Estos aceler ometros son m as compactos y precisos que los mec anicos y se pueden encontrar f acilmente en el mercado a un precio competitivo. Como ya se ha mencionado en la introducci on, cualquier cuerpo con masa est a sometido, al menos, a una aceleraci on debida a la fuerza de la gravedad. Sin embargo, la aceleraci on de la gravedad no tiene por qu e ser la u nica aceleraci on a la que est e sometido dicho cuerpo.
6.2. SENSORES
43
Figura 6.7: Diagrama de relaci on entre orientaci on y salidas del aceler ometro. El principio de equivalencia garantiza que la fuerza gravitacional experimentada localmente mientras se encuentra cerca de un cuerpo masivo, como la tierra, es la misma que la pseudo fuerza experimentada por un observador en un marco de referencia no inercial (acelerado). Esto quiere decir que la fuerza de la gravedad ser a equivalente en magnitud y direcci on a aquella que soporta un objeto acelerado, por lo que no variar a la aceleraci on sufrida por la gravedad aunque el veh culo en el que est a instalado el sensor se encuentre acelerado. Cuando el veh culo se encuentre sometido a una aceleraci on diferente a la de la gravedad lo u nico que ocurrir a es que la aceleraci on total ser a la composici on de dicha aceleraci on con la de la gravedad. Esto signica que la aceleraci on captada por los aceler ometros instalados en el veh culo tendr a una componente debida a la aceleraci on de la gravedad, y otra debida a la aceleraci on externa del veh culo. El mayor problema es que el sensor nos dar a un u nico valor de aceleraci on y no es posible diferenciar a priori qu e parte de la magnitud de aceleraci on es debida a la gravedad y qu e parte no. Esto hace que la primera aproximaci on presentada para el c alculo de los a ngulos sea err onea, ya que cualquier fuerza a la que sometamos el veh culo derivar a en una aceleraci on que provocar a un error de c alculo de los angulos, pudi endose dar el caso de que se llegue a anular la aceleraci on debida a la gravedad. De esta manera no es recomendable construir una IMU basada tan solo en las lecturas de los aceler ometros puesto que, aunque si el modelo no est a acelerado se estimar a adecuadamente la orientaci on, cualquier aceleraci on diferente de la gravedad que sufra el modelo provocar a un cambio articial en los a ngulos , y . Durante el primer incremento V1 se hicieron pruebas con la IMU 6DoF Razor desarrollada por Sparkfun1 . Esta unidad cuenta con un aceler ometro de tres ejes de Analog Devices, en concreto el modelo ADXL335, capaz de medir aceleraciones de hasta 3g. Este sensor cuenta con salida anal ogica referenciada a 3.3 V. La IMU cuenta con ltros para la estabilizaci on de las salidas y se alimenta a trav es de una entrada de 3.3 V. En la ilustraci on 6.8 se puede ver el esquema de conexiones del aceler ometro de tres ejes ADXL335 tal y como viene en la IMU 6DoF Razor.
Sparkfun es una conocida tienda online y fabricante de circuitos y dispositivos electr onicos http://www. sparkfun.com
1
44
Figura 6.8: IMU 6DoF Razor.
Figura 6.9: ADXL345 con breakboard de Sparkfun.
Sin embargo, aunque las primeras pruebas de medici on resultaron satisfactorias, m as adelante se comenzaron a detectar problemas con el sensor. El primero de ellos era debido a que, al tratarse de una placa con todos los sensores integrados, un defecto en alguno de los sensores supon a el reemplazo de la unidad completa, y las primeras pruebas en el banco balanc n conrmaron la facilidad de fallo de estos sensores de bajo coste. Por otro lado, la limitaci on en el n umero de entradas anal ogicas en la placa Arduino y la necesidad de usar el conversor anal ogico digital del microprocesador para procesar las entradas, fueron clave para la sustituci on de esta unidad por peque nos m odulos de sensores independientes y la preferencia por m odulos con salida digital (Incremento V2). El sensor elegido para sustituir al ADXL335 fue su hermano mayor ADXL345 (Fig. 6.9), tambi en de Analog Devices, pero esta vez con mejor precisi on (detecta cambios menores o a 1 ), mayores aceleraciones m aximas (9g), y una salida digital a trav es de interfaz I 2 C (Ap endice 12) muy amigable. En el Ap endice 12 se puede consultar m as informaci on sobre estos sensores. Antes de usar las medidas del aceler ometro hay que realizar el ajuste de la magnitud de la aceleraci on de la gravedad en la conguraci on seleccionada. Esta conguraci on consiste en seleccionar el rango de medida m aximo a 3g, ya que no ser a necesario medir mayores aceleraciones y adem as esta conguraci on es la que mayor precisi on tiene (13 bits). Para esta conguraci on el valor de la aceleraci on de la gravedad medida en est atico es de 260, por lo que hay que calibrar las medidas de modo que en est atico el sensor proporcione una medida de 260 en eje Z y 0 en los ejes X e Y.
6.2. SENSORES
45
Figura 6.10: Esquema de funcionamiento de un giroscopio encapsulado MEMS (Micro Electro Mechanical Systems)
6.2.2.
Gir oscopos
Un gir oscopo o giroscopio es un sensor que basado en el principio de conservaci on del momento angular es capaz de medir velocidades angulares en un determinado eje. Esto quiere decir que es capaz de medir la velocidad instant anea a la que est a girando un cuerpo sobre un eje dado. Al proporcionar magnitudes de velocidad de giro es posible calcular el giro al que se ha sometido un cuerpo determinado durante un periodo de tiempo. Adem as, como el momento angular se mantiene inalterado independientemente de las aceleraciones lineales a la que se vea sometido el cuerpo, la magnitud de velocidad angular proporcionada por este sensor no var a aunque se encuentre en un marco de referencia no inercial. Esto es una gran ventaja ya que este tipo de sensores no se ven afectados ni por la aceleraci on debida a la gravedad ni por aquellas aceleraciones debidas a otras fuerzas, por lo que nos permite calcular la tasa de giro del veh culo independientemente de la orientaci on actual del veh culo y de su aceleraci on. Sin embargo, este tipo de sensores cuentan con dos problemas. El primero es que las magnitudes se corresponden con velocidades angulares instant aneas, y la frecuencia de las mediciones viene dada por las caracter sticas t ecnicas del gir oscopo as como de la velocidad con la que es capaz la IMU de consultar al sensor. Esto quiere decir que es necesario realizar una estimaci on de la velocidad angular entre medida y medida que, dependiendo de las caracter sticas de precisi on y frecuencia de medida, puede provocar peque nas diferencias entre los giros calculados y los giros reales. Adem as, como para calcular el giro total se han de acumular las mediciones efectuadas desde el momento en el cual el modelo se encuentra en un angulo de referencia, si el giro se prolonga en el tiempo al acumular las mediciones tambi en se acumulan los errores. Por otro lado, el segundo de los problemas al usar estos sensores es que es necesario
46
conocer el angulo de referencia para poder aplicar el giro medido por el gir oscopo a dicho a ngulo para conocer la orientaci on del modelo. En el primer incremento V1 se utilizaron dos gir oscopos integrados en la IMU 6DoF de Razor que se ha mencionado anteriormente. Esta IMU cuenta con dos gir oscopos de ST Microelectronics, un LPR530AL que es capaz de medir en los ejes X e Y (pitch y roll ) con un rango m aximo de 300o /s y salidas anal ogicas amplicadas 4x, y un LY530ALH que es capaz de medir velocidad angular en torno al eje Z (yaw ) con las mismas caracter sticas de precisi on y rango m aximo. Al realizar pruebas en el banco de test con esta IMU se encontraron diferentes problemas al usar las magnitudes devueltas por los gir oscopos. El primero de los problemas encontrados tiene que ver con una correcci on abrupta encontrada en las salidas de los gir oscopos cuando la velocidad angular pasaba a 0. B asicamente el problema consist a en una correcci on de giro cuando el modelo paraba de girar, esta correcci on era en el sentido de giro contrario al realizado y no era menospreciable. En un primer momento se achac o este comportamiento a la deriva inercial que sufren los gir oscopos al parar bruscamente un giro, sin embargo, investigando en diferentes foros especializados [15] y consultando al fabricante se encontr o que este efecto es debido a los diferentes ltros que el fabricante incorpora a la salida de los gir oscopos, en este caso un ltro de paso alto y otro de paso bajo como se puede observar en el esquema del Ap endice 12. La cuesti on reside en las caracter sticas de los sensores y de la adquisici on de la informaci on de los mismos, en principio la adquisici on de los sensores se realizar a a una frecuencia dada, y el software se encargar a de integrar los valores para reconstruir lo que ha ocurrido en funci on del tiempo, sin embargo, al tomar medidas cada cierto tiempo se pierde la informaci on de lo que ha ocurrido entre medida y medida. Para poder limitar los efectos de este periodo de tiempo durante el cual no tenemos medidas y ltrar la salida para que quede en un rango adecuado lo que hace el fabricante es incorporar unos ltros que cuentan con condensadores. De este modo los valores que dan los sensores pasan por estos condensadores carg andolos, y cuando se realiza la lectura correspondiente no se lee directamente la salida de los sensores, sino la descarga de estos condensadores, que ofrece la se nal ltrada. En otros casos, el uso de ltros es benecioso para poder acotar la se nal y suavizarla. Sin embargo, para los c alculos que realiza el software embarcado estos ltros provocan que la deriva de los gir oscopos se amplique debido a los diferentes tiempos de carga y descarga de los condensadores. En concreto es el ltro de paso alto el que introduce este indeseable efecto colateral del ltrado. Para solucionar este problema basta con eliminar f sicamente los ltros de paso alto conectados a las salidas de los gir oscopos. Para ello es necesario eliminar los condensadores, uno por cada salida, y realizar un puente en el lugar que ocupaban de modo que la se nal pase libre. Tambi en hay que eliminar las resistencias asociadas a los ltros de paso alto y sustituirlas por una resistencia innita (se deja desconectado), de modo que la se nal no pierda nada. En la ilustraci on 6.11 se puede observar el resultado de eliminar los ltros en la IMU de Razor. Como se puede observar en la imagen, al eliminar uno de los condensadores se perdi o tambi en la pista correspondiente, por lo que fue imposible realizar el puente. Para solucionarlo se realiz o el puente a la salida sin amplicar 1x y la entrada al amplicador de la se nal. Sin embargo los problemas con la IMU de Razor no quedaron ah , tras varias pruebas
6.2. SENSORES
47
Figura 6.11: IMU 6DoF RAZOR una vez eliminados los ltros de paso alto. En Verde se resaltan los condensadores cortocircuitados y en azul las resistencias eliminadas.
Figura 6.12: Placa breakboard con LPY530AL. con el prototipo V1 uno de los gir oscopos comenz o a tener un comportamiento an omalo. Las magnitudes de salida ten an grandes errores en velocidades bajas y la se nal era inestable. Posiblemente debido al problema que surgi o al eliminar los ltro el sensor se habr a sobrecalentado y hab a quedado defectuoso, por lo que se procedi o a cambiar toda la IMU por una nueva. La segunda IMU volvi o a estropearse al intentar integrarla con el prototipo de la iteraci on V2. Aunque el fallo fue humano al desoldar la IMU de la placa de prototipado, el problema de sustituci on de toda la IMU al fallar alguno de los sensores, unido al alto precio de la unidad de Razor, y unido al uso de salidas anal ogicas (y limitaci on de entradas anal ogicas en la plataforma Arduino), hizo que se eliminase del proyecto el uso de esta unidad y se sustituyera por m odulos independientes. Por tanto en el incremento V3 se sustituy o denitivamente la IMU de Razor por dos gir oscopos de dos ejes LPY530AL con breakboard de Sparkfun 6.12, de modo que uno se situase en el eje de pitch y otro en el de roll (ejes X e Y del modelo). Ambos cuentan con ltros de paso alto incorporados que hubo que eliminar como en el caso de la IMU de Razor.
6.2.3.
Magnet ometros
El tercer tipo de sensores que intervienen en la estabilizaci on son los magnet ometros. En este caso el magnet ometro es un sensor magn etico que es capaz de detectar el campo magn etico de la tierra y, al igual que un comp as tradicional, es capaz de denir d onde se
48
Figura 6.13: Magnet ometro HMC6352 de Honeywell con placa breakboard de Sparkfun. encuentra el norte magn etico. Este tipo de sensores son u tiles en navegaci on, pero tambi en en estabilizaci on, puesto que es necesario un sensor que nos de una referencia able para calcular el giro en el eje Z o Yaw. Realmente el comp as digital o magnet ometro nos da una referencia del norte geogr aco, u til para calcular el rumbo o heading. En el caso del yaw, cuando el modelo tenga cualquier inclinaci on en cualquiera de los ejes X e Y al contar con una componente no nula a partir del eje Z se pueden usar los aceler ometros como referencia para corregir y calcular el a ngulo de referencia del giro. Por lo que tan solo se utilizar a el comp as digital cuando la componente debido a la aceleraci on de la gravedad caiga completamente en el eje Z, ya que al tener componentes nulas en los ejes X e Y ser a imposible determinar el angulo de origen de yaw. En realidad introduciremos el componente de heading como uno m as en la estabilizaci on, en cuanto a que se desea que el modelo no tenga ninguna velocidad angular en el eje Z y que est e dirigido hacia un rumbo particular. Para calcular dicho rumbo se toma como referencia la medida del comp as digital para determinar el error en rumbo y corregirlo. El sensor elegido para medir el rumbo fue el HMC6352 de Honeywell en la versi on de breakboard de Sparkfun debido a que dicha placa cuenta con se nal ltrada estabilizada y 2 salida digital a trav es de bus I C . Despu es de hacer diversas pruebas con el comp as digital se encontraron resultados no satisfactorios. En primer lugar con el comp as en reposo las medidas que da el componente var an en un rango de dos, incluso tres, grados. Por lo que en la pr actica la precisi on del comp as es muy deciente. El segundo resultado no esperado ha sido que hay rangos de grados en los que el comp as proporciona medidas extra nas. En concreto lo detectado es que al comenzar a girar sobre s mismo hay un peque no instante en el que las medidas se paran incluso se han obtenido medidas en sentido contrario durante un breve espacio de tiempo. Por lo tanto habr a que tener en cuenta la mala precisi on del comp as a la hora de preparar el m odulo de navegaci on para orientar al modelo, de modo que se considere aceptable un error de grados.
6.2.4.
S onar y Bar ometro
Por u ltimo, para el tercer incremento V3 se incorporaron dos nuevos sensores: un bar ometro con salidas digilates SCP1000 de MBed para ser usado de alt metro y un sonar LVMaxSonar EZ1 de MaxBotics para gestionar la altitud con mayor precisi on cuando el veh culo
6.3. UNIDAD CENTRAL
49
Figura 6.14: Bar ometro SCP1000 de MBED.
Figura 6.15: S onar LV MaxSonar EZ-1 de MaxBotics. se encuentra a baja altitud. El Bar ometro SCP1000 realmente obtiene medidas de presi on que hay que ltrar y transformar a valores de altura por software. Tiene una resoluci on de 1 metro y un error tambi en de 1 metro, por lo que no puede utilizarse como medida precisa para estabilizaci on a baja altura, aunque es muy u til en campo abierto. Para poder realizar la conversi on de presiones a altura hay que realizar un calibrado software a trav es del cual se establece la altura de referencia y se utiliza la temperatura actual para transformar las diferencias de presi on en diferencias de altitud. El s onar seleccionado tiene salidas anal ogicas y en serie, aunque en este caso se utilizaron las salidas anal ogicas por motivos de latencia. Tiene una resoluci on de una pulgada (2.54 cm) y un error igual a la resoluci on. Cuenta con un alcance m aximo de 6 metros, la altura m nima detectada es de 1 pulgada, aunque comienza a dar medidas exactas de distancia a partir de 5 pulgadas (unos 12 cm).
6.3.
Unidad Central
La unidad central es el cerebro del veh culo, integra la placa Arduino con el microprocesador, reguladores de tensi on, conversor serie FTDI2 (USB a RS232) y resistencias unidas a las entradas/salidas anal ogicas, y todos los sensores utilizados por el microprocesador. En esta secci on se explicar an los diferentes prototipos resultados de cada incremento, as como la evoluci on de las pistas, conexiones y dem as detalles que conforman la placa principal.
Future Technology Devices International, empresa escocesa de circuitos integrados especializada en la tecnolog a USB
2
50
Figura 6.16: Montaje de UC para Iteraci on V1, se puede ver el Arduino Duemilanove con el adaptador para comunicaciones Xbee de Libelium (sin el m odulo Xbee de Maxtream) y la IMU 6DoF de Razor.
Figura 6.17: M odulo de comunicaciones Xbee (Zigbee) de MaxStream.
6.3.1.
Incremento V1
En el primer incremento se utiliz o un Arduino Duemilanove como base. Se utiliz o una placa de prototipado corriente para integrar los sensores que se fueron probando con el Arduino. Aunque en las primeras pruebas se anclaba el conjunto al banco de test con cinta adhesiva o velcro, m as tarde se adquiri o una caja de Sparkfun donde montar los prototipos de modo que quedase un montaje compacto y seguro para las pruebas. Para el m odulo de comunicaciones se eligi o utilizar comunicaciones basadas en el est andar Zigbee3 . La decisi on de usar Zigbee como enlace de datos inal ambrico residi o en su bajo consumo 4 respecto a Bluetooth , tasa de transferencia y alcance razonables (250 kbps / 1600 metros) y sobretodo su buena integraci on con la plataforma Arduino. Dentro del rango de opciones posibles se seleccion o usar un Shield (adaptador) para
Zigbee: Especicaci on de un conjunto de protocolos de comunicaci on inal ambrica basados en el est andar IEEE 802.15.4. (http://standards.ieee.org/getieee802/download/802.15.4a-2007.pdf) 4 Bluetooth: Especicaci on industrial para Redes Inal ambricas de Area Personal a trav es de radiofrecuencia en la banda ISM de los 2,4 GHz (http://es.wikipedia.org/wiki/Bluetooth)
3
6.3. UNIDAD CENTRAL
51
Figura 6.18: Capas representado las conexiones deseadas sobre la placa de Measure Explorer Arduino5 desarrollado por la empresa Libelium6 , una spin-o de la Universidad de Zaragoza. Este adaptador es capaz de integrar un m odulo de comunicaciones Zigbee Xbee de MaxStream7 facilitando el acceso desde Arduino a dicho m odulo. Se puede consultar m as informaci on sobre el protocolo Zigbee en el Ap endice A secci on Zigbee. Como se puede ver en la ilustraci on 6.16, las conexiones entre sensores y microprocesador se hacen a trav es de cable ordinario de prototipado. En el prototipo resultado del incremento V1 la unidad central tomaba alimentaci on (5V) a trav es del cable USB que conectaba la placa Arduino con el PC de desarrollo.
6.3.2.
Incremento V2
En la segunda iteraci on se sustituy o la placa Arduino Duemilanova por una placa Seeeduino v2.12 basada en Arduino, que facilitaba la integraci on de la plataforma Arduino en una placa de prototipado. Una de las ventajas de Seeeduino es que cuenta con un regulador de tensi on tanto de 5 V como un diodo Zener 3v3 que puede usarse como referencia para las entradas anal ogicas, eliminando la necesidad de usar un diodo externo as como un regulador de 5V externo (en primera instancia se iba a utilizar un L7805CV de ST Microelectronics). Como base para las conexiones se sustituy o la primera tipo protoboard por una placa de prototipado de una capa de Measure Explorer (ME) obtenidas a trav es de la tienda de ME en ebay. Se trata de placas de prototipado que cuentan con todos los agujeros conectados entre s por nos hilos superciales, de manera que para trazar las pistas tan solo se deben cortar las conexiones no u tiles. Para facilitar el dise no de las pistas se utiliz o una plantilla de GIMP8 con diferentes capas
5 6
http://www.arduino.cc/playground/Shields/Xbee01 Libelium:http://www.libelium.com/ 7 MaxStream ahora absorvida por Digi http://www.digi.com 8 The GNU Image Manipulation Program http://www.gimp.org/
52
Figura 6.19: Capa de cortes que permiten las conexiones seleccionadas
Figura 6.20: Resultado al trasladar los cortes y los headers a la placa de prototipado, en este caso se pueden ver los sensores tambi en acoplados a sus cabeceras.
para cada uno de los componentes a integrar, y dos capas especiales, una que representa la placa de prototipado con todos sus agujeros y otra que representa las conexiones de la placa Seeeduino. Sobre estas dos capas se superponen una capa que representa las conexiones deseadas, y otra que representa los cortes a realizar para tener las conexiones dadas, por lo que se puede realizar un buen dise no de los cortes de modo que se produzca el menor n umero de cortes posible. Se utilizaron dos placas de ME de 18 x 28 agujeros a las que se soldaron diferentes conectores (headers) para poder integrar f acilmente los sensores, de modo que se pudieran sustituir f acilmente. La alimentaci on en esta iteraci on proviene del conector de la bater a LiPo principal. Seeeduino cuenta con un interruptor para seleccionar alimentaci on a trav es de USB para la programaci on o alimentaci on externa. El montaje nal puede verse en la gura 6.21.
6.3. UNIDAD CENTRAL
53
Figura 6.21: Montaje nal del prototipo de la Iteraci on V2
6.3.3.
Incremento V3
El tercer incremento se centr o en mejorar la integraci on de los componentes con la plataforma Arduino y en la integraci on de los u ltimos sensores como el bar ometro y el s onar para el m odulo de estabilizaci on en altura. Se incorpor o una nueva placa de prototipado de Measure Explorer, esta vez mucho m as grande (42 x 42 agujeros) en la que integrar todos los componentes. Al ser una placa nueva se realiz o un dise no completamente nuevo de las pistas para facilitar la integraci on y alimentaci on de todos los componentes, y facilitar la expansi on de la misma, permitiendo dejar visibles conexiones no utilizadas. Tras los problemas de alimentaci on encontrados en la segunda iteraci on, donde los cambios de potencia a los motores supon an interferencias en las lecturas de los sensores anal ogicos, se decidi o alimentar la UC con una bater a LiPo propia de 7.4 V y 500 mAh. Adem as de esta manera la UC mantiene el control y las comunicaciones operativas aunque la tensi on de la bater a principal caiga, lo que permitir a, en caso de emergencia, mantener la telemetr a operativa. Adem as se a nadi o un interruptor para permitir encender/apagar la alimentaci on de la UC. Por u ltimo se sustituy o la antena cer amica integrada del m odulo XBee de MaxStream por una antena externa de mayor alcance, y se situ o dicha antena fuera de la caja principal, de modo que las interferencias en los sensores debido a la radiofrecuencia se suavizaran.
54
Figura 6.22: Diagrama de pistas para la placa nal de la iteraci on V3
Figura 6.23: Montaje nal de la UC Incremento V3
Cap tulo 7 Software Embarcado

En este cap tulo se realizar a una descripci on inform atica de la parte de software que ejecutar a embarcado en la Unidad de Control (UC). En primer lugar se especicar a la arquitectura software para luego pasar a detallar los m odulos de los que est a compuesta, las evoluciones sufridas en cada uno de los incrementos, las dicultades encontradas, as como las soluciones propuestas.
7.1.
Arquitectura Software
La arquitectura del software embarcado est a sujeta a la estructura general de un programa desplegable en la plataforma Arduino. Tal y como se ha explicado anteriormente todo software embarcable en Arduino debe contar con dos procedimientos a modo de punto de entrada o entry point que ser an llamados autom aticamente por el planicador del Framework Arduino. Un procedimiento setup() que se llamar a una sola vez y un procedimiento loop() que ser a llamado c clicamente. A partir de ah el resto del c odigo se puede modularizar y estructurar como se desee. El procedimiento setup() engloba las llamadas a los m etodos de inicializaci on de cada uno de los m odulos. En dichos m etodos se inicializan los registros y variables de cada driver, tambi en se ejecutan los posibles procedimientos de calibrado de los sensores anal ogicos, incluso los protocolos de inicializaci on en caso de ser necesario. Para poder controlar los ciclos de ejecuci on de cada m odulo software y gestionar adecuadamente los recursos, se decidi o implementar un planicador en el procedimiento loop(). Este planicador realiza las llamadas al resto de los m odulos. Entre los m odulos se encuentran los diferentes manejadores o drivers de entrada/salida. En el diagrama 7.1 se pueden observar los manejadores de entrada de los diferentes sensores, as como el manejador de salida hacia los motores. Cada uno de estos drivers se encarga de comunicarse con los sensores de diferentes maneras, as como de proveer una interfaz c omoda de acceso a los valores recibidos de los sensores o escritura de los valores de salida hacia los motores, de manera que el resto de m odulos pueda hablar con todos los dispositivos de entrada/salida sin preocuparse del protocolo o tecnolog a usada por el manejador o driver. 55
56
CAP ITULO 7. SOFTWARE EMBARCADO
Figura 7.1: Diagrama de arquitectura Software.
7.2. DRIVERS DE ENTRADASALIDA
57
Adem as de los drivers de entrada/salida el software embarcado se compone de tres m odulos importantes de procesamiento:
Modulo de Comunicaciones: Encargado de procesar los comandos recibidos de la estaci on de tierra y enviar la informaci on de telemetr a del veh culo. Modulo IMU: Fusiona los datos de sensores para calcular la posici on relativa del veh culo. M odulo de Estabilizaci on: Encargado de la seleccionar la salida adecuada hacia los motores dependiendo de la situaci on del veh culo y los comandos recibidos.
Cada uno de estos m odulos cuenta con un procedimiento de inicializaci on, que es llamado desde el punto de entrada setup() y que se ejecutar a una sola vez. Y dependiendo de si se trata de un m odulo de entrada/salida o de procesamiento contar a con un m etodo de acceso a los datos o escritura de los mismos (del tipo get() /set() ) o con un m etodo procesamiento (process() ).
7.2.
7.2.1.
Drivers de EntradaSalida
Interfaz I2C
La interfaz I 2 C 1 fue denida por Philips para conectar de forma simple componentes electr onicos. Consta de dos l neas, una de datos y la otra de sincronizaci on de reloj. Tambi en es necesaria una l nea de tierra que suele ser la misma utilizada para alimentar el circuito. La nomenclatura de las l neas es: SDA (Datos), SCL (Reloj), GND (Tierra). A trav es de 2 I C podemos enviar datos con una tasa de transferencia de hasta 100kbps. Los dispositivos conectados por I 2 C cuentan con una direcci on u nica de 7 bits, adem as pueden ser congurados en modo maestro o esclavo. El maestro es el que inicia la transmisi on mientras que el esclavo solo responde a lo que el maestro pida. En toda comunicaci on I 2 C el maestro es el encargado de generar la se nal de reloj. Despu es de cada transferencia de 8 bits el maestro genera un pulso en la se nal de reloj y deja libre la l nea, entonces el esclavo responde con un ack poniendo la l nea SDA a nivel bajo o con un nack dejando la l nea a nivel alto. Todas las transiciones en la linea SDA deben ocurrir cuando SCL est a a nivel bajo ya que las transiciones cuando SCL est a a nivel alto se reservan para los comandos de Start y Stop. Al iniciar las comunicaciones el maestro debe enviar el comando de Start seguido por la direcci on de destino. Como la direcci on est a formada por 7 bits y las transferencias I 2 C son de 8 bits, se usan los 7 bits m as signicativos. Esto hay que tenerlo en cuenta ya que antes de enviarla habr a que mover un bit hacia la izquierda la direcci on de modo que quede en los 7 bits m as signicativos. El bit menos signicativo se usa para indicar si se trata de una lectura (1) o una escritura (0).
1 2
I C : Inter-Integrated Circuit, tambi en llamado Twice Wires Interface TWI
58
Afortunadamente existe una librer a implementada para Arduino llamada Wire que implementa todo el protocolo. Para poder usar la librer a Wire de Arduino es necesario conectar la l nea SCL a la entrada anal ogica 5 y la linea SDA a la entrada anal ogica 4.
7.2.2.
M odulo ADXL345Driver
En general se ha desarrollado un driver independiente para cada sensor o grupo de sensores. El primero de ellos es el ADXL345Driver encargado de realizar las lecturas del aceler ometro de 3 ejes. La interfaz del sensor es a trav es de bus I 2 C . Para adquirir los datos del sensor se ha utilizado la librer a Wire de Arduino. La direcci on de 7 bits I 2 C asignada seg un especicaci on del sensor es 0x1D, aunque se pueden usar dos direcciones a elegir dependiendo de si la entrada SD0 se encuentra a nivel alto o a tierra, si es a nivel alto se usa 0x1D y si es tierra usar a la direcci on 0x53. Hay que tener en cuenta que ambas direcciones se conguran en los 7 bits m as signicativos dejando el menos signicativo para indicar lectura o escritura. Una vez inicializado el bus I 2 C y congurada la direcci on y par ametros del bus, el m odulo provee tres funciones get() que devuelven la aceleraci on medida en un entero, donde la aceleraci on de la gravedad se sit ua en el valor 260 (medida resultante al medir la aceleraci on sobre el eje Z sin ninguna otra aceleraci on externa).
7.2.3.
M odulo ImuAdc
El m odulo ImuAdc provee una interfaz de acceso a los datos de los dos gir oscopos de dos ejes (uno de los ejes es com un a ambos gir oscopos). En este caso las salidas amplicadas de los sensores se conectan a entradas anal ogicas, por lo que se utilizan los conversores AD de micro que tienen una precisi on de 10 bits (1024 valores). En lugar de proveer funciones de acceso a cada una de las lecturas, este m odulo guarda los valores le dos de velocidades angulares en un vector donde son corregidos. La raz on de esto es la necesidad de calibrar los gir oscopos, para ello se toman medidas con los sensores est aticos para conocer el ruido de los mismos y se utilizan estos valores para corregir y mejorar las medidas. Este m odulo est a directamente vinculado al m odulo ImuDcm encargado de corregir las lecturas y fusionarlas con las lecturas de los aceler ometros para obtener los valores netos de pitch, roll y yaw.
7.2.4.
M odulo DigitalCompass
Este m odulo provee una interfaz de acceso a los valores de heading obtenidos a trav es del magnet ometro digital. Se conecta a trav es de bus I 2 C que, seg un especicaci on, est a congurado en modo esclavo con la direcci on 0x48. Para obtener lecturas de heading es necesario primero inicializar las comunicaciones I 2 C (initDigitalCompas() ). Para acceder al u ltimo valor obtenido se puede llamar a la funci on getHeading() que devuelve un entero que representa grados 10, de modo que tiene 0.1 grados de precisi on. Para actualizar la u ltima lectura de heading es necesario llamar al procedimiento processDigitalCompass(). Este procedimiento env a el comando A al sensor, espera 6 ms y recibe dos bytes que se corresponde con el rumbo dado en d ecimas de grados
7.3. COMUNICACIONES
59
desde 0 a 3599. Se puede consultar m as informaci on sobre los procedimientos de calibraci on del magnet ometro en el Ap endice A secci on de sensores. Tras realizar diferentes pruebas con el m odulo se encontraron resultados no demasiado satisfactorios. En primer lugar, las medidas obtenidas con el comp as en reposo var an en un rango de 2 grados, por lo que en la pr actica la precisi on del comp as es muy mala. Adem as al tratarse de un magnet ometro de un solo eje las medidas de rumbo son ables tan solo cuando el sensor est a completamente horizontal, por lo que hay que tener en cuenta la posici on del veh culo para considerar v alidas las medidas, o bien realizar solo actualizaciones de heading cuando el modelo se encuentre con pitch y roll nulos.
7.2.5.
M odulo AltimeterDriver
El m odulo AltimeterDriver provee dos funciones para obtener la altitud y la temperatura. Para poder obtener la altitud se utilizan dos sensores diferentes, por un lado un sensor de presi on SCP1000 con interfaz I 2 C , y por otro un s onar MaxSonar con interfaz anal ogica. En un principio el m odulo estaba compuesto por el sensor de presi on, sin embargo, dicho sensor tiene un error de 1 metro, inaceptable para vuelo en interiores e insuciente para los procedimientos de despegue y aterrizaje. Por lo que se opt o por complementarlo con un s onar con precisi on suciente a corta distancia. El procedimiento processAltitude() realiza la fusi on de estos dos sensores. Por un lado lee los valores anal ogicos del s onar utilizando un ltro simple de moda para eliminar posibles lecturas sucias, convierte a pulgadas aplicando el factor de conversi on que especica el fabricante para luego convertir los valores recibidos de pulgadas a metros. Si el resultado es mayor a 5 metros (el s onar tiene un alcance m aximo de 6.5 metros) entonces descarta la 2 medida del s onar y solicita a trav es de I C el valor de presi on al sensor de presi on. Se aplica una conversi on logar tmica a los valores de presi on recibidos para convertirlos a metros, para eso se busca el valor de la presi on a una determinada temperatura en la zona de vuelo estimada (en este caso sur de Madrid) y se aplica dicha presi on de referencia en la funci on de conversi on. Debido a que la presi on var a con la temperatura ambiente las medidas del sensor de presi on deben tomarse teniendo en cuenta una posible calibraci on de la medida de la presi on le da cuando el veh culo se encuentra en tierra. Dado que el sensor de presi on cuenta con un term ometro, aprovechando el acceso al sensor para conocer la presi on se obtiene la temperatura, que es almacenada y puede ser consultada a trav es de la interfaz de la GCS.
7.3.
Comunicaciones
El m odulo SerialComms provee toda la interfaz referida a comunicaciones, tanto de salida de telemetr a como de entrada de comandos y o rdenes. Tal y como se ha explicado en la secci on de Plataforma Hardware 6 las comunicaciones se procesan a trav es de un m odulo Xbee que implementa el protocolo Zigbee. Adem as del m odulo Xbee instalado en el veh culo, habr a otro m odulo Xbee conectado a la GCS al que llamaremos Router. Este segundo m odulo redigir a el tr aco a un puerto USB
60
de la GCS, dotando de esta manera de comunicaciones Zigbee a la GCS. El m odulo Xbee del veh culo se conecta directamente con el puerto serie de Arduino. Adem as, el m odulo de radio se congura d andole una direcci on determinada ja (de modo que el Router sepa la direcci on del m odulo de radio del veh culo). Se congura el protocolo en modo Ad-Hoc (Router-Veh culo), por lo que todo lo que se env a a trav es del puerto serie de Arduino es redirigido a trav es de Zigbee a la direcci on Zigbee especicada como Router. Se implementaron dos programas Arduino de conguraci on que autom aticamente conguran los m odulos de radio tanto del veh culo como del router siguiendo el protocolo de conguraci on de las radios a trav es de puerto serie. Una vez congurado el enlace a trav es de Zigbee se desarroll o un protocolo de comunica2 ciones basado en ASCII para poder enviar y recibir los diferentes mensajes. Este protocolo establece cabeceras simples que delimitan y clasican los tipos de mensajes. Se decidi o codicar en ASCII para facilitar la lectura de c odigo y la depuraci on, teniendo en cuenta que el problema del ancho de banda no era signicativo. Se establecen dos tipos de mensajes, por un lado comandos que recibe el veh culo desde la estaci on de tierra, y por otro lado mensajes de telemetr a que env a el veh culo con informaci on de diferente tipo. De esta manera un mensaje se compone de una cabecera de comienzo y nal de mensaje, y entre medias un identicador de mensaje sucedido de los datos del mensaje. Para el env o y recepci on se implementa un buer de recepci on, de manera que en cada ciclo de ejecuci on se vac a el b ufer de recepci on de la pila Zigbee y, dependiendo de una m aquina de estados que indica si se espera una cabecera de comienzo o n de mensaje o datos, se decide si los bytes le dos son v alidos, si es as se almacenan en el b ufer local de recepci on. Cada vez que la m aquina de estados de recepci on considera que se ha recibido un mensaje v alido (por ejemplo al recibir una cabecera de n de mensaje que se esperaba), vac a el b ufer sacando el mensaje v alido y lo env a a un clasicador de mensajes que lo decodica y llama al procesador de mensaje adecuado. El procesador correspondiente al mensaje recibido env a asentimiento en caso de requerirlo, y en caso de tratarse de un comando implementado llama a la funci on correspondiente. En la tabla 7.1 se puede ver la relaci on de mensajes implementados, tanto de telemetr a como de comandos. Adicionalmente se implement o un mensaje especial de depuraci on y otro de alarmas para poder enviar mensajes espec cos desde el software embarcado a la estaci on de tierra. De esta manera, adem as de la informaci on de telemetr a presentada en la estaci on de tierra gr acamente, tambi en se provee informaci on adicional que se presenta a trav es de una ventana de texto, muy u til para conocer qu e ocurre en el software embarcado (trazas de c odigo, informaci on de depuraci on, tiempos de ejecuci on, etc). Entre los comandos m as importantes se encuentran los comandos de inicio de comunicaciones y los correspondientes asentimientos (Ok, Fail y Reconnect) que permiten establecer (y reestablecer en su caso) el enlace entre veh culo y estaci on de tierra. Hasta que dicho enlace no est a establecido el software embarcado no ejecutar a determinadas rutinas, como las de estabilizaci on, proceso de comandos, y c alculo de la posici on relativa. Adicionalmente hay comandos espec cos que ordenan al software comenzar a procesar
2
ASCII: American Standard Code for Information Interchange http://www.asciitable.com/
7.4. MODULO IMU Tipo Cmd Cmd Cmd Cmd Cmd Cmd Cmd Cmd Cmd Cmd Cmd Cmd Cmd Info Info Info Info Info Info Info Info Info Info Info Info Info Descripcion Comms Init Reconnect Motor Power Kp Param Set Td Param Set Ti Param Set Pitch Dmd Roll Dmd Heading Dmd Start Stop Ok Fail Pitch Info Roll Info Yaw Info Heading Info Altitude Info X Acceleration Y Acceleration Z Acceleration X Angular Vel Y Angular Vel Z Angular Vel Power Motor Debug Id I M K TD TI P R H B S OK FAIL P R Y H B AX AY AZ GX GY GZ PM D Datos [MotId][Value] [PidId][Value] [PidId][Value] [PidId][Value] [Value] [Value] [Value] [Value] [Value] [Value] [Value] [Value] [Value] [Value] [Value] [Value] [Value] [Value] [MotId][Value] [String]
61
Cuadro 7.1: Mensajes implementados en el protocolo de comunicaciones los angulos de pith, roll y heading solicitados desde la estaci on de tierra (Start ), as como un comando de parada total de emergencia (Stop ). Los comandos Pitch Dmd, Roll Dmd y Heading Dmd son los encargados de establecer los a ngulos de pitch y roll, as como el rumbo que debe tomar el veh culo y que ser an las entradas que utilizar a el m odulo de estabilizaci on para realizar sus c alculos.
7.4.
M odulo IMU
Uno de los m odulos m as importantes es el encargado de fusionar los datos obtenidos de los sensores que forman la unidad inercial del veh culo (IMU), formado por aceler ometros y gir oscopos, para obtener la posici on del veh culo en a ngulos de pitch, roll y yaw. Existen dos enfoques principales para la fusi on de datos y obtenci on de a ngulos de Euler a partir de aceleraciones absolutas y velocidades angulares. Uno de ellos es utilizar las aceleraciones como datos principales y usar un ltro Kalman en el que se utilizan los valores de velocidad angular como dato corrector [2]. El segundo es utilizar las velocidades angulares como dato principal y utilizar matrices de cosenos directores para, por un lado corregir los vectores unitarios que forman la base de coordenadas del veh culo con la informaci on de
62
aceleraciones, y por otra renormalizar estos vectores para mantener la ortogonalidad de los mismos. El algoritmo DCM (Direction Cosine Matrix) [43] desarrolla el segundo enfoque, y al tratarse de un m etodo nuevo y m as efectivo que el tradicional uso de ltros Kalman se decidi o utilizarlo.
7.4.1.
Algoritmo DCM
El algoritmo DCM funciona de la siguiente manera: 1. Las medidas de los gir oscopos se usan como la fuente principal de informaci on de orientaci on. Se procede a integrar la ecuaci on diferencial no lineal que relaciona el tiempo durante el cual el modelo ha estado cambiando de orientaci on con la velocidad angular y con la orientaci on actual del modelo. Esto se hace a una frecuencia sucientemente alta como para dar informaci on lo sucientemente fresca al controlador de modo que pueda corregir la potencia a enviar a cada uno de los motores. B asicamente se obtienen datos de velocidad de giro, y se integran en tiempo para obtener posici on. 2. El resultado de la primera fase tiene la forma de una matriz de rotaci on 3x3 que representa el giro en los tres ejes. Los errores en la integraci on provocar an que se viole el principio de ortogonalidad que la matriz DCM debe satisfacer, por lo que se van haciendo peque nas correcciones para mantener la ortogonalidad de la matriz. 3. Los errores num ericos debidos a las medidas de los gir oscopos se van acumulando en los elementos de la matriz DCM. Para poder corregir estos errores o paliarlos en gran medida se usar an las medidas de los aceler ometros para poder corregir pitch y roll y las medidas del comp as digital para corregir el yaw.
7.4.1.1.
Rotaciones
Una manera de representar una rotaci on en tres ejes es a trav es de una matriz de rotaci on. Dicha matriz es una matriz 3x3 compuesta de nueve elementos, tres las y tres columnas, que representa la orientaci on de cada sistema de coordenadas respecto a otro. Las columnas de la matriz son los vectores unitarios de un sistema de coordenadas visto desde el otro. Un vector en un sistema de coordenadas puede ser transformado hacia el otro sistema multiplic andolo por la matriz de rotaci on correspondiente. La transformaci on en el sentido contrario se obtiene multiplicando el vector por la matriz inversa a la de rotaci on que resulta ser igual a la traspuesta (resultado de intercambiar las por columnas). Los vectores unitarios son muy u tiles a la hora de realizar los c alculos ya que al tener valor uno pueden ser usados en los productos escalares y cruzados para obtener los senos y cosenos de varios angulos. Un grupo de rotaci on es el grupo de posibles rotaciones. Se llama grupo porque dos posibles rotaciones pueden combinarse para formar una nueva rotaci on del grupo. Toda rotaci on cuenta con su rotaci on inversa, y tambi en existe la rotaci on identidad que al ser aplicada no cambia la orientaci on. Lo interesante es que el grupo de rotaci on es cerrado, es decir, se pueden aplicar sucesivas rotaciones hasta dejar al modelo con la orientaci on inicial.
7.4. MODULO IMU
63
La idea base es que la matriz de rotaci on que dene la orientaci on del modelo (respecto a una orientaci on inicial dada) puede ser actualizada integrando la ecuaci on diferencial no lineal que describe la cinem atica de la rotaci on. Esta cinem atica tiene que ver con la geometr a de la rotaci on de un cuerpo r gido y c omo la rotaci on transforma una conguraci on r gida en otra. Esto se hace teniendo en cuenta que la integraci on se puede conseguir a trav es de una serie de composiciones de matrices, con composici on se entiende la multiplicaci on de dos matrices de rotaci on, y la resultante representa la matriz de rotaci on resultante de haber aplicado secuencialmente las rotaciones que representan las matrices de rotaci on multiplicadas. Sin embargo, esta integraci on introduce dos tipos de errores, por un lado el error num erico debido a que la integraci on utiliza periodos de tiempo acotados y la informaci on se obtiene con una determinada frecuencia (correspondiente a la frecuencia de actualizaci on de los sensores). Dependiendo del m etodo de integraci on se asumen ciertos supuestos sobre lo que ha pasado entre cada muestra de datos, en este caso se puede asumir que la velocidad de rotaci on es constante entre cada lectura de los gir oscopos. Por tanto el error es proporcional a la aceleraci on angular. El segundo tipo de error es el cuantitativo y tiene que ver con la propiedad discreta de las lecturas digitales, en denitiva cada lectura de los gir oscopos es una lectura digital (los sensores anal ogicos pasan por un conversor A/D), en nuestro caso con una resoluci on de 10 bits (precisi on del A/D de Arduino). Una propiedad clave de la matriz de rotaci on es su ortogonalidad, que implica que si dos vectores son perpendiculares en un marco de referencia deben ser perpendiculares en cualquier otro marco de referencia, y tambi en que la longitud de cada vector es la misma independientemente del marco de referencia. Los errores num ericos anteriores pueden hacer que se viole esta propiedad de las matrices. Las las y columnas de la matriz representan vectores unitarios cuya longitud debe ser siempre uno, pero los errores acumulados pueden hacer que var e la longitud ligeramente por debajo o por encima de uno. Aunque la matriz de rotaci on cuenta con nueve elementos, realmente tan solo tres de ellos son independientes. La ortogonalidad de la matriz indica que cualquier par de columnas o las debe ser perpendicular y que la suma de los cuadrados de los elementos de cada la o columna debe resultar uno. Esta propiedad puede ser usada para renormalizar la matriz. 7.4.1.2. Matriz de Cosenos Directores
Tal y como se ha denido anteriormente, algunos vectores como desplazamiento, direcci on, velocidad o aceleraci on, pueden ser transformados de un marco de referencia a otro con solo multiplicarlo por una matriz de rotaci on 3x3. Esta matriz de rotaci on es resultado de calcular las proyecciones de un marco de referencia sobre el otro como se puede ver en la gura 7.2. La relaci on entre la matriz de cosenos directrices y a ngulos de Euler se muestra en la ecuaci on 7.1
cos cos sin sin cos cos sin cos sin cos + sin sin R = cos sin sin sin sin + cos cos cos sin sin sin cos sin sin cos cos cos
(7.1)
Al ser la frecuencia de actualizaci on muy r apida se asume que los giros producidos son
64
Figura 7.2: Proyecciones de una base sobre otra de referencia. tan peque nos que se puede simplicar los cosenos por 1, los senos por el valor del arco medido en radianes () y los productos seno x seno por 0. Suponiendo velocidad angular () constante durante el periodo de c alculo el arco queda = dt Teniendo la matriz de rotaci on para un instante dt, la matriz para un instante (t + dt) es igual a la del instante t multiplicada por la rotaci on, como se observa en la ecuaci on 7.2: 1 dz dy 1 dx R(t + dt) = R(t) dz dy dx 1 Donde: z = z dty = y dtx = x dt (7.3)
(7.2)
Una vez obtenido el resultado de la rotaci on es necesario realizar una renormalizaci on para corregir posibles violaciones del principio de ortogonalidad, para ello se usa el producto escalar de cada pareja de vectores perpendiculares. As conseguimos el error de ortogonalidad y es posible aplicar una correcci on a cada vector igual a la mitad del producto del error calculado por el vector perpendicular utilizado. Por u ltimo se convierten a vectores unitarios normalizando. En este punto es donde entran en acci on los valores de aceleraciones obtenidos de los aceler ometros. Dichos valores se utilizan para cancelar el efecto de deriva de los gir oscopos. Para ello se utiliza un controlador retroalimentado proporcional derivativo (PI) que genera la correcci on a aplicar a los giros, se detallar a en qu e consiste un controlador de bucle cerrado de este tipo en la secci on7.5.1. Se introduce como entrada del controlador PI el error entre los a ngulos calculados en funci on de los valores de los aceler ometros y los obtenidos por el DCM en la ejecuci on anterior. Se toma una peque na fracci on del error como correcci on de la parte proporcional, y la acumulaci on de dicha correcci on como correcci on de la parte integral.
7.4. MODULO IMU
65
Figura 7.3: Diagrama del controlador PI DCM 7.4.1.3. Angulos de Euler
Para obtener el a ngulo Pitch solo hay que referirse a la relaci on entre la matriz de rotaci on y los a ngulos de Euler ya vista anteriormente, de la misma manera se puede obtener el angulo Roll y Yaw acudiendo a la matriz de rotaci on y despejando: P itch = T oDeg (asin(DCM M atrix[2][0])) Roll = T oDeg (atan2(DCM M atrix[2][1], DCMM atrix[2][2])) Y aw = T oDeg (atan2(DCM M atrix[1][0], DCMM atrix[0][0])) (7.4) (7.5) (7.6)
7.4.1.4.
Notas sobre la implementaci on
Para implementar y probar adecuadamente el algoritmo DCM se parti o de los documentos de Mahony [33] y del draft de documentaci on de William Premerlani, DCM Imu Theory [43]. Adem as se ha contado con una implementaci on basada en el c odigo abierto del proyecto DIYDrones encontrada en el proyecto VoidBot [8], en el que casualmente adapta el c odigo DCM para ser utilizado con la IMU 6DoF de Razor que se utiliz o en los primeros incrementos (V0 y V1) de la plataforma hardware. Adem as se ha consultado tambi en el propio c odigo del proyecto DIYDrones [15], as como los foros de discusi on sobre DCM [15], por lo que el c odigo nal de la implementaci on DCM est a basado en la implementaci on de DIYDrones, aunque modicado, adaptado y optimizado para ser utilizado con los sensores seleccionados y el planicador implementado en el software embarcado. Todas las funciones de c alculo algebr aico se han implementado de cero, as como la adquisici on y conversi on de datos de los sensores. El c odigo correspondiente a la renormalizaci on y al controlador PI aplicado para las correcciones es una adaptaci on del c odigo original de DIYDrones a la plataforma propia. La transformaci on de coordenadas se ha optimizado e implementado de manera diferente a la original.
66
Hay que tener en cuenta que el c odigo original de DIYDrones est a orientado a ser utilizado por un avi on radiocontrolado, por lo que tanto la adquisici on como la correcci on de datos adquiridos diere respecto a un veh culo de despegue vertical (VTOL). Por lo que fue necesario estudiar los cambios y recticaciones a aplicar al algoritmo original.
7.5.
M odulo de Estabilizaci on
El m odulo de estabilizaci on es el encargado de procesar el estado actual del veh culo y calcular la potencia a suministrar a cada uno de los motores para llevar al veh culo al estado deseado. En este caso las entradas del controlador de estabilizaci on las forman los tres a ngulos calculados por el m odulo IMU, mientras que las salidas son las potencias que puede comandar a cada uno de los motores. Para solucionar la estabilizaci on del veh culo, se ha decidido abordar el c alculo de las salidas debidas a cada eje como un problema independiente. De esta manera la estabilizaci on del veh culo se convierte en tres problemas de estabilizaci on, uno para cada uno de los ejes. Para cada eje se tiene una u nica entrada, que es el angulo correspondiente calculado por el m odulo IMU, y cuatro salidas correspondientes a las potencias de los motores. En realidad, tal y como se ha descrito en el cap tulo 5.1, las potencias a suministrar a los cuatro motores para provocar un cambio en un eje, se pueden simplicar a un u nico valor que representa un diferencial de potencia entre dos parejas de motores. De esta manera, dado un angulo que se corresponde con el a ngulo real (calculado por m odulo IMU) en un eje concreto, y por otro lado el a ngulo objetivo, se puede calcular el error absoluto entre ambos (que se corresponde con la diferencia entre ambos). Dicho error es la entrada al controlador, mientras que la salida representar a el giro necesario para paliar dicho error (siempre se habla de un eje jo concreto) en forma de diferencia de potencia entre dos pares de motores. Para solucionar este problema se usar a un controlador Proporcional, Integral, Derivativo PID [36] para el a ngulo pitch y otro para el roll. Tambi en se usar a un controlador PID para el a ngulo Yaw, aunque este impactar a en el control del rumbo y no de la estabilizaci on en s .
7.5.1.
PID
Un controlador de bucle cerrado es aquel que cuenta con feedback o retroalimentaci on de su salida adem as de las entradas habituales, esto es para poder conocer c omo de bien se ajusta la salida proporcionada por el propio controlador y poder corregirla adecuadamente. Digamos que existe la posibilidad de actuar sobre una variable de salida a la que llamaremos salida del controlador (CO, CV o simplemente OUTPUT). Adem as se cuenta con una entrada que es la variable a procesar (PV de Process Variable) y con un tercer valor que nos indica si se ha alcanzado el objetivo, que suele tratarse de un valor deseado para la variable de entrada y a la que se denomina Set Point (SP). En principio, las variaciones en la variable de salida o CO afectan en el siguiente ciclo al valor de entrada PV, por esa raz on existe un bucle cerrado.
7.5. MODULO DE ESTABILIZACION
67
Figura 7.4: Esquema de controlador PID 7.5.1.1. Acci on Proporcional
El controlador PID cuenta con tres factores, si tan solo se tuviese en cuenta la variable de entrada PV y se usase una funci on de proporcionalidad entre esta y el valor objetivo SP (error entre el valor actual y el objetivo) ser a un controlador proporcional simple. Se dene una constante de proporcionalidad en la acci on proporcional, una constante que dene la relaci on entre la salida CO y el efecto de esta en la entrada PV de modo que la entrada se acerque al objetivo SP. Esta constante se denomina Kp. La acci on proporcional es r apida de calcular y f acil de sintonizar (tune) pero no elimina el error en estado estacionario. Kp recibe el nombre de ganancia proporcional.
7.5.1.2.
Acci on Integral
Para minimizar las perturbaciones debidas a factores externos se aplica un factor integral encargado de conocer la historia de la relaci on entre la acci on aplicada y la entrada retroalimentada. En un s mil electr onico es el mismo efecto que tiene la colocaci on de un condensador como ltro en un circuito de modo que en lugar de tomar las lecturas de una se nal el ectrica se toman las medidas del condensador, para estabilizar la se nal y evitar que nos impacten las variaciones an omalas. Adem as ayuda a mantener la variable controlada en el valor objetivo. Este factor integral necesita una variable que indique el tiempo durante el cual se va a tomar. A mayor tiempo la acci on integral ser a menor y a menor tiempo la acci on integral ser a mayor (tendr a m as peso). Esto es normal porque si se reduce el tiempo es m as probable que las perturbaciones afecten a la salida pero tambi en hace que en caso de error muy grande el controlador sea m as agresivo al sumarse la acci on integral a la proporcional. La constante de tiempo integral se denomina Ti.
7.5.1.3.
Acci on Derivativa
Por u ltimo hay un tercer factor que es el derivativo, este factor prevee hacia d onde va a ir la variable controlada en el siguiente ciclo dada la salida actual debida al controlador Proporcional/Integral. Se dene una constante de tiempo Td que se usa para calcular el efecto de la acci on proporcional, durante ese tiempo Td la salida va a variar proporcionalmente a la acci on proporcional, estima a qu e velocidad se est a reduciendo el error para abstraer, conociendo el tiempo de aplicaci on, cual ser a la posici on en el siguiente ciclo de ejecuci on respecto al error.
68
Figura 7.5: Comportamiento PID respecto a parametros Kp,Ti,Td
7.5.2.
Parametrizaci on PID
Antes de utilizar un controlador PID hay que calibrarlo, es decir, denir los valores de Kp, Ti y Td . Existen diferentes m etodos para congurar estos par ametros, algunos consisten en ir dejando a nulo cada valor e ir midiendo la respuesta del controlador a diferentes valores de uno solo de los coecientes hasta lograr el mejor efecto, jar dicho valor y luego realizar otras pruebas con los otros factores (M etodo Ziegler-Nichols [14]). Sin embargo, debido a la baja calidad de los sensores (al ser de bajo coste) y de la necesidad de una calibraci on lo m as exacta posible debido a la criticidad de un fallo por peque no que sea en la salida de los controladores, es necesario realizar una calibraci on lo m as precisa posible. Teniendo esto en cuenta se decidi o implementar un m etodo de autocalibraci on que aprovechase el banco de pruebas existente. Si se simplican los par ametros de un controlador PID a Kp, Ti y Td se puede construir un espacio tridimensional con las posibles parametrizaciones del PID. Si se construye una funci on que valore c omo de buena es una parametrizaci on (Kp,Ti,Td ) respecto a una serie de variables objetivas, como por ejemplo el error medio obtenido mientras se ejecuta el PID durante un tiempo jo dado, el error m aximo, o cualquier otro par ametro medible durante un experimento, entonces se reduce la calibraci on del PID a un problema de b usqueda en un espacio tridimensional. Se ha desarrollado un algoritmo espec co para resolver este problema, que ser a presentado en el cap tulo 9.
7.5.3.
Aplicaci on de PID a la estabilizaci on
Una vez que se obtiene la salida del controlador, se debe convertir dicha salida a potencias a aplicar a los motores. La salida del controlador se puede traducir en una proporci on de giro en un sentido u otro. Tal y como se describi o en el cap tulo de an alisis, un giro en un solo eje se puede transformar en la aplicaci on de una potencia determinada a cada pareja de motores.
DE LOS INCREMENTOS 7.6. EVOLUCION
69
Si nombramos X (1,2) e Y (3,4) a cada pareja de motores, se logra un giro en un sentido aplicando un factor de correcci on a una de las parejas y aplicando la correcci on inversa al otro par de motores. El sentido del giro lo determinar a el signo de dicho factor de correcci on, mientras que la determinaci on del giro se basa en la elecci on de las parejas de motores seg un los diagramas mostrados en el cap tulo de An alisis 5. Para simplicar la elecci on de los factores se decidi o congurar la salida de los PIDs de modo que la salida de cada controlador sea directamente el factor de correcci on a aplicar. Este factor de correcci on es el mismo para los ejes de pitch y roll y tiene un rango que va axima de P M M AX P ID LIM IT a P M M AX P ID LIM IT siendo P M M AX la m potencia posible para los motores y P ID LIM IT una constante de proporcionalidad que va de 0 a 1 e indica el porcentaje de potencia de motor dedicado a la estabilizaci on de un eje dado. La aplicaci on del factor de correcci on debido a un controlador se realiza sobre la potencia actual de los motores, es decir, los motores tienen una potencia dada currentThrottle y a del factor de correcci on. esa potencia se aplica una fracci on de 1 4 Por ejemplo, si la pareja de motores 3 y 4 inciden en el giro de pitch mientras que la pareja 1 y 2 lo hacen sobre el roll, y la pareja 1 y 3 lo hacen sobre el giro sobre s mismo (yaw se convierte en rumbo o heading si el veh culo se encuentra horizontal), la aplicaci on de las salidas de tres controladores PID uno para cada eje ser a: motor3Pow motor4Pow motor1Pow motor2Pow = = = = currentThrott+(PitchOut/4) currentThrott+(PitchOut/4) currentThrott-(PitchOut/4) currentThrott-(PitchOut/4) + + (RollOut/4) (RollOut/4) (RollOut/4) (RollOut/4) + + (HeadOut/4); (HeadOut/4); (HeadOut/4); (HeadOut/4);
Si el giro de correcci on es en un sentido equivocado tan solo hay que cambiar los signos, mientras que si el giro es demasiado brusco siempre se puede variar el l mite PID LIMIT.
7.6.
Evoluci on de los Incrementos
El desarrollo del software embarcado ha seguido la metodolog a descrita basada en incrementos. El incremento inicial V0 sirvi o para familiarizarse con la plataforma Arduino y las diferentes librer as disponibles. En el primer incremento real V1 se desarroll o el protocolo de comunicaciones y se prob o su correcto funcionamiento. Tambi en se realiz o el primer draft del planicador, as como diferentes versiones de los m odulos de drivers de los sensores, primero para comunicarse con la IMU 6DoF de Razor, y luego adapt ando el c odigo para comunicarse con las placas de gir oscopos y aceler ometros independientes. Tambi en se realizaron pruebas de salida de potencia de motores. En el segundo incremento V2 se introdujo todo el desarrollo del algoritmo DCM, tambi en los drivers de los magnet ometros y del bar ometro. Por u ltimo, se a nadieron nuevos mensajes para poder solicitar los comandos de inicio y parada de emergencia. En el m odulo de estabilizaci on se implement o el controlador PID de pitch y roll para poder realizar las primeras pruebas de calibraci on.
70
En el u ltimo incremento V3 se implement o el planicador completo, se introdujo la gesti on del s onar y comp as digital, se implementaron los PIDs de heading y altitud. Se introdujeron comandos para cambiar los par ametros de los PIDs f acilmente al vuelo, tambi en para poder variar los a ngulos de pitch, roll, heading y la altitud objetivo de los PIDs. Finalmente se optimiz o el c odigo para que ocupara menos memoria y pudiese ejecutar en los tiempos de ejecuci on marcados para cada m odulo.
Cap tulo 8 Estaci on de Tierra (GCS)

La estaci on de tierra es una pieza clave del proyecto al conformar la interfaz entre el veh culo aut onomo y el usuario en tierra. La GCS se encarga de monitorizar los datos de telemetr a que env a el veh culo y de mostrar dicha informaci on de manera que sea productiva y usable por el personal de tierra. Tambi en es capaz de enviar comandos al veh culo, desde el plan de vuelo, hasta los comandos de parada de emergencia, incluso es posible comandar el veh culo en modo semiautom atico y poder controlar pitch, roll y rumbo o heading. Por u ltimo, desde la GCS se gestionan todas las acciones relacionadas con la carga de pago y el uso de los datos recibidos por el veh culo. En este caso la GCS desarrollada muestra por un lado toda la informaci on que env a el veh culo y por otra permite enviar distintos comandos, entre los que se encuentran comandos de inicializacion y parada, par ametros de los diferentes PIDs utilizados, as como los comandos que mandan al veh culo de los angulos de pitch, roll, heading y altitud a tomar. Por otro lado, la GCS muestra una pantalla dedicada a la ejecuci on y gesti on de tests, as como la ejecuci on y calicaci on de pruebas de calibraci on del veh culo. Para facilitar el an alisis de todos los datos, la GCS cuenta con un grabador/reproductor de datos que es capaz de grabar todos los datos de una prueba concreta, tanto de telemetr a como de calibraci on de los controladores PID. De esta manera se pueden grabar todos los datos de una prueba concreta, ya sea en banco o en vuelo real, para poder reproducir y analizar a posteriori todos los datos y poder sacar informaci on u til sobre el vuelo/prueba.
8.1.
Arquitectura Software
El entorno de desarrollo utilizado para implementar la GCS es Processing. Como se ha comentado en el cap tulo Plataforma de Desarrollo 4, el entorno Processing es an alogo al de Arduino, con la diferencia del lenguaje de programaci on utilizado, que es Java. Processing cuenta con un API de gr acos 2D/3D, utilizando como render tanto OpenGL1 como Java3D2 . Adicionalmente se ha utilizado la librer a guicomponents [29] que facilita el uso de botones y otros componentes gr acos, adem as de proporcionar gesti on de eventos.
OpenGL Open Graphics Library http://www.opengl.org Java3D es un API para gr acos 3D del lenguaje de programaci on Java que puede ejecutar sobre OpenGL o sobre DirectX https://java3d.dev.java.net/
2 1
71
72
DE TIERRA (GCS) CAP ITULO 8. ESTACION
Figura 8.1: Componente gr aco Serial Comms. En la u ltima iteraci on se ha introducido el uso de la librer a procontroll [13] que facilita la gesti on de joysticks, para proporcionar control semiautom atico en tests de vuelo. De manera similar al software embarcado, la aplicaci on de GCS cuenta con dos puntos de entrada que son llamados autom aticamente por el planicador de Processing. En el caso de Processing existe el m etodo setup() que es llamado una u nica vez y que sirve para inicializar todos los controles gr acos, y el m etodo draw() que es llamado en cada ciclo de ejecuci on y que es el encargado de actualizar el modelo de datos y pintar en pantalla los gr acos 2D/3D. Para facilitar el dise no y gesti on de los componentes de la interfaz se decidi o dividir la interfaz gr aca en componentes gr acos (tambi en llamados widgets ) independientes. Cada uno de estos componentes debe implementar un constructor y una m etodo draw() o paint() que ser a llamado en cada ciclo desde el m etodo draw() principal. Cada componente recibe en su constructor las coordenadas (x,y), el tama no del componente gr aco, y otras propiedades como el t tulo a mostrar en caso de que pinte uno. Adicionalmente, los componentes gr acos que gestionen eventos deben implementar los m etodos handle() correspondientes a los eventos a implementar (handleMouse(), handleKey(), etc.). Existe un manejador de eventos gestionado por la librer a guicomponents que recibe los eventos y los reparte a los m etodos handle() de cada componente. Los componentes gr acos pueden ser simples o complejos y todos son autocontenidos, por lo que cada componentes contiene y gestiona sus datos. Los componentes simples no est an formados por otros componentes y normalmente cuentan con un m etodo paint() o draw() que pueden recibir los datos actualizados (integer, oat, etc.). Mientras que los componentes complejos est an formados a su vez por otros componentes, por lo que los m etodos paint() o draw() reciben todos los datos necesarios para ser pasados a los componentes contenidos. Adicionalmente, tanto componentes simples como complejos pueden gestionar eventos, por lo que deben implementar los m etodos handle() adecuados, los componentes complejos deben llamar a los m etodos handle() de los componentes contenidos. La interfaz gr aca se ha dividido en tres subcomponentes principales: MainMenuDisplay, que muestra el men u principal (siempre visible). PrimaryDisplay, que contiene todos los componentes principales de telemetr a y comando. CalibrationDisplay, que gestiona la pantalla de calibraci on y test.
8.2.
SerialComms
Este componente muestra y gestiona el estado del enlace de datos. Por un lado informa del estado del enlace inal ambrico de manera que este puede encontrarse NOT INITIATED,
8.3. MAINMENUDISPLAY
73
Figura 8.2: Componente MainMenuDisplay.
Figura 8.3: Componente GraphicMotor. WAITING ACK en caso de estar esperando respuesta de veh culo, y CONNECTED si se ha completado el establecimiento de conexi on. Adem as informa del puerto de comunicaciones utilizado, de manera que se puede conectar a trav es del enlace Zigbee inal ambrico o por un cable USB directo a la UC del veh culo. Este componente adem as gestiona la recepci on y env o de todos los mensajes del protocolo implementado y especicado en la secci on de comunicaciones del software embarcado, de manera que los mensajes enviados por el software embarcado son los que es capaz de recibir la GCS y viceversa. La gesti on de comunicaciones es similar a la implementada en la UC, se cuenta con un b ufer de recepci on y un m etodo de gesti on de mensaje para cada mensaje. Cuando se detecta un mensaje correctamente formado en el b ufer se manda dicho mensaje a un distribuidor que a su vez elimina cabeceras y se queda con los datos u tiles, los cuales pasa al m etodo que gestiona dichos datos. Normalmente la informaci on de telemetr a se almacena en variables globales y son pasadas a cada subcomponente para que actualicen su estado. Por u ltimo, el componente SerialComms cuenta con botones para solicitar conexi on o desconexi on del enlace de datos, y para enviar los comandos de parada de emergencia e inicio del bucle de control del veh culo (comandos que deben estar disponibles desde el momento de habilitar la conexi on).
8.3.
MainMenuDisplay
Este componente contiene los botones para cambiar de la primaryDisplay a la calibrationDisplay, as como los t tulos de la interfaz y la informaci on de la versi on actual.
8.4.
8.4.1.
PrimaryDisplay
GraphicMotor
Este componente muestra el estado de cada uno de los motores, as como la potencia total que el veh culo est a administrando. Para cada motor se muestra una barra que indica
74
Figura 8.4: Componente GraphicHorizon. la potencia de cada motor. Estas barras son sensibles a los eventos de click de rat on, por lo que un click en una posici on de una barra concreta env a un comando de potencia de motor que intentar a forzar dicha potencia al motor en cuesti on. Depender a del estado del veh culo el que el comando sea tomado en cuenta o no, por ejemplo, si el veh culo se encuentra con los controladores de estabilizaci on desactivados, los comandos de potencia de motor ser an tenidos en cuenta, de otra manera no ya que las potencias estar an bajo el control del m odulo estabilizador.
8.4.2.
GraphicAHorizon
Este componente muestra un horizonte articial en el que se representa la posici on relativa del veh culo respecto al horizonte. Esta vista es muy u til para que el piloto en tierra tenga una idea de la posici on o movimiento que est a realizando el veh culo, incluso si este se encuentra fuera del alcance visual del mismo. Para facilitar la identicaci on de la orientaci on del veh culo se pinta de color marr on lo que se corresponde con la tierra y en azul la parte de cielo (de la l nea de horizonte hacia arriba). Se a nade una escala semicircular que indica la inclinaci on en roll marcando los a ngulos de 10, 20, 30 y 45 grados. Tambi en se cuenta con una escala vertical que indica la inclinaci on en pitch de cinco en cinco grados (numerando las decenas). El m etodo paint() de este componente recibe los valores actualizados de pitch y roll que son usados para realizar una traslaci on (pitch ) y una rotaci on (roll ) de las texturas correspondientes. El constructor recibe la posici on en coordenadas (x,y), y el tama no (width ).
8.4.3.
HeadingIndicator
En el componente del horizonte articial no se representa de manera alguna el giro sobre s mismo y el a ngulo correspondiente (yaw ). Aunque m as u til que este angulo que es relativo a la posici on del veh culo, es aquel que representa el rumbo, el a ngulo que forma el morro del veh culo con el norte magn etico. La mejor manera de representar el rumbo o heading es a trav es de una rosa de los vientos, donde se marque una escala con el rumbo cada 30 grados. En este caso el componente recibe en su m etodo de pintado el valor actualizado de heading, y lo usa para transformar y rotar
8.4. PRIMARYDISPLAY
75
Figura 8.5: Componente HeadingIndicator.
Figura 8.6: Componente GraphicModel. la escala de modo que se represente el rumbo actual del veh culo.
8.4.4.
GraphicModel
El tercer componente gr aco usado para mostrar la posici on del veh culo es una representaci on en 3D del veh culo, de manera que se muestre c omo se est a moviendo el modelo y la posici on relativa respecto a los ejes x,y,z del mundo real. El modelo 3D es un modelo simplicado realizado a base de cubos. Dicho modelo se gira en los tres ejes seg un los valores actualizados de pitch, roll y yaw recibidos en la llamada al m etodo paint(). Para lograr algo de perspectiva, antes de aplicar las rotaciones debidas a los angulos, se realiza una peque na rotaci on en el eje x e y para lograr un punto de vista desde una perspectiva algo superior.
76
Figura 8.7: Componente BatteryMonitor.
Figura 8.8: Distintas instancias del componente ValueIndicator.
8.4.5.
BatteryMonitor
Este componente gr aco representa el nivel de carga de la bater a. Al ser una barra peque na y poco precisa se establece un valor de voltaje de emergencia a partir del cual el color de la barra pasa a ser rojo, considerando de esta manera que se debe tomar una acci on urgente para poner a salvo el veh culo. El valor de emergencia es congurable aunque por defecto est a marcado en 10.5 V.
8.4.6.
ValueIndicator
Este componente gr aco es un componente gen erico que muestra un valor junto con un t tulo, en el caso del PrimaryDisplay se usa para mostrar los valores sin tratar de aceleraciones y velocidades angulares del veh culo. Tambi en se utiliza para mostrar el valor num erico de la altitud y de la temperatura medida en el veh culo. Como el resto de componentes, en el constructor se puede especicar, adem as de las posiciones a mostrar y el t tulo, el tama no del componente gr aco.
8.4.7.
GraphicPID
Este componente gr aco se introdujo en la u ltima iteraci on para poder monitorizar y cambiar f acilmente los par ametros de un controlador PID. Se pueden cambiar los valores de Kp, Ti y Td, incluso con el veh culo en funcionamiento. Cuenta con un bot on para enviar el comando correspondiente. Para poder conocer la correspondencia del componente gr aco con la instancia de PID asociada en el software embarcado, al crear el componente se le pasa (a trav es del constructor) un identicador enumerado que se corresponde con el enumerado declarado en la parte de software embarcado
Figura 8.9: Componente GraphicPid, una instancia para cada PID existente.
8.5. CALIBRATIONDISPLAY
77
Figura 8.10: Componente JoystickControl. para identicar los mismos PIDs. En este caso se construyen cuatro componentes para controlar los PIDs de pitch, roll, heading, y altitud.
8.4.8.
JoystickControl
Este componente se a nadi o en la u ltima iteraci on para permitir gestionar un joypad de manera que se pueda utilizar para semicomandar al veh culo peque nas variaciones en los a ngulos de pitch y roll, as como poder tener a mano botones mapeados a comandos de emergencia como parada, etc. Por un lado, el componente muestra la posici on del joystick. Dicha posici on se retroalimenta con la posici on de los ejes proporcionada por la librer a procontrol. Por otro lado muestra una serie de combos que permiten congurar los ejes a utilizar e incluso el dispositivo de entrada en caso de existir varios. Para permitir el control semiautom atico se mapean los ejes X e Y del joystick con un rango de grados del orden de 2 grados. De esta manera, con el joystick se pueden solicitar variaciones de pitch y roll objetivo de 2 grados. El componente detecta cuando ha cambiado la posici on respecto al ciclo anterior para comandar el mensaje correspondiente. Tambi en permite el mapeo de botones a diferentes comandos, por ejemplo, se pueden usar dos botones para aumentar o disminuir la altitud objetivo, o, cuando el control de altura se encuentra desactivado, aumentar o disminuir la potencia total a repartir entre los motores por los controladores de estabilizaci on. De esta forma se pueden realizar pruebas de estabilizaci on gestionando la navegaci on de manera manual.
8.5.
CalibrationDisplay
La pantalla de calibraci on est a dise nada para congurar pruebas de calibraci on (Fig. 8.13) y para mostrar, por un lado el resultado de un test concreto de modo que pueda ser evaluado gr acamente, y por otro mostrar el resultado actual de la calibraci on siguiendo el algoritmo Qsearch desarrollado para el proyecto y detallado en el cap tulo 9. Para ello, se cuenta con un apartado de conguraci on de calibraci on donde se pueden seleccionar los valores l mites de cada uno de los par ametros, junto con el tiempo de duraci on de cada test, el tiempo de reposo entre cada ejecuci on de los tests, el n umero de tests que componen la calibraci on, y la iteraci on actual en la que se encuentra el algoritmo.
78
Figura 8.11: PrimaryDisplay.
Figura 8.12: Representaci on tridimensional del espacio de b usqueda.
8.5. CALIBRATIONDISPLAY
79
Figura 8.13: Secci on de conguraci on de la calibraci on o test a realizar.
Figura 8.14: Representaci on visual del test realizado junto con los par ametros ejecutados y el resultado obtenido.
El bot on Apply inicia la calibraci on seleccionada, una vez iniciada la GCS comanda parada e inicializaci on de los controladores PIDs. Entonces ejecuta el algoritmo Qsearch implementado en el chero qsearch. Dicho algoritmo cuenta con una funci on de inicializaci on, y varias funciones importantes. La funci on calculateNextPoint() que devuelve las coordenadas del siguiente punto a probar (aplica a la posici on actual la funci on que dene el salto teniendo en cuenta la iteraci on actual), la funci on calculateFitness() que calcula la calidad de la prueba realizada actualmente y la m aquina de estados que gestiona el estado del algoritmo. El pseudoc odigo del algoritmo se puede consultar en el cap tulo QSearch 9. En la parte izquierda de la pantalla se encuentra una representaci on 3D del espacio de b usqueda (Fig. 8.12), en el que se muestran los puntos correspondientes a las parametrizaciones probadas as como l neas que indican el progreso del algoritmo. Esta visi on del espacio muestral es muy interesante ya que a trav es de ella se puede percibir el sentido del algoritmo y comprobar c omo las soluciones van acerc andose a la soluci on o ptima. Adem as esta representaci on 3D es interactiva, de manera que el usuario puede hacer click y girar el espacio para ver de forma m as clara la progresi on del algoritmo, tambi en permite realizar zoom para apreciar mejor los valores probados.
80
Figura 8.15: CalibrationDisplay. Por u ltimo, en la parte inferior de la derecha se encuentra una gr aca que se construye en tiempo real y en la que se representa los valores de error en el eje que se est a calibrando, y que dan una perspectiva gr aca de c omo de bien o mal ha ido la prueba (Fig. 8.14). Esta gr aca puede servir tambi en para comprobar c omo de el es la funci on de evaluaci on o tness respecto a la realidad de lo ocurrido, por lo que puede usarse para modicar la funci on de tness para adecuarla a las necesidades concretas del proyecto.
8.6.
Grabador Reproductor
Tanto en la pantalla principal, como en la de calibraci on se cuenta con un m odulo grabador/reproductor. Este componente se encarga de grabar en chero todos los par ametros que se est an recibiendo a un rate determinado (generalmente 20 frames por segundo), de manera que luego puede ser reproducido el comportamiento a posteriori reproduciendo los datos al mismo rate al que fueron grabados. El m odulo grabador reproductor ofrece la posibilidad de pausar la reproducci on en cualquier momento. Para grabar una sesi on tan solo hay que pulsar el bot on de grabar o rec, entonces se abre una ventana auxiliar que permite seleccionar el chero a escribir la sesi on. Una vez seleccionado comienza la grabaci on, y esta no para hasta ser pulsado el bot on de parada o stop. Al pulsar el bot on de reproducci on o play otra ventana auxiliar permite seleccionar el chero que contiene la sesi on a reproducir. Una vez abierto, si es v alido, la sesi on comienza a reproducir hasta que es parada (stop ) o pausada (pause ). Despu es de una pausa se puede volver a reproducir desde el punto en el que se qued o pulsando de nuevo play.
DE LOS INCREMENTOS 8.7. EVOLUCION
81
Figura 8.16: Controles gr acos del Grabador/Reproductor. En la captura se ve una reproducci on pausada. El componente grabador reproductor utiliza un m odulo llamado LogManager que es el encargado de grabar y leer cheros. El componente gr aco GraphicRecorder tan solo gestiona la m aquina de estados del grabador reproductor y el LogManager utilizado (asociado a un chero concreto), pero no la l ogica de las variables a leer o escribir. Dicha l ogica est a implementada en el componente complejo CalibrationDisplay o PrimaryDisplay, que consultan en cada ciclo el estado del grabador reproductor para escribir o leer las variables deseadas en el chero asociado.
8.7.
Evoluci on de los Incrementos
Al igual que el resto de desarrollos, el desarrollo de la GCS ha ido marcado por los incrementos realizados y su planicaci on. En el incremento inicial (V0) se realizaron pruebas simples de dibujado con el API gr aco de Processing, as como pruebas de comunicaciones con el entorno Arduino a trav es de la conexi on serie USB directa con la placa. En el segundo incremento (V1) se desarroll o una versi on preliminar de casi todos los widgets, salvo los controles de los PIDs, del joystick y la ventana de calibraci on que se introdujeron en la siguiente iteraci on. Se realiz o un primer dise no de toda la interfaz en cuanto a tama no y colocaci on de los widgets, tambi en se traz o la estructura general de un componente gr aco, se instrument o el procedimiento de paso de eventos y se compuso la jerarqu a de widgets simples/complejos. En el tercer incremento (V2) se actualizaron todos los widgets, dot andolos de enlace entre la parte de visualizaci on y la l ogica de comunicaciones. Tambi en se desarroll o la pantalla de calibraci on guiada por las necesidades del algoritmo QSearch y las pruebas necesarias para validarlo. En el cuarto y u ltimo incremento se introdujeron los controles de los PIDs, as como el control por joystick para realizar las pruebas de vuelo semiautom atico. Se recolocaron casi todos los elementos gr acos redise nando la aparencia de los widgets y de las ventanas principales y se introdujeron mejoras en la pantalla de calibraci on, como la posibilidad de moverse por el espacio de soluciones con el rat on, y la posibilidad de seleccionar manualmente la iteraci on a mostrar. Tambi en se introdujo el grabador/reproductor en ambas pantallas ya que result o crucial para analizar los diferentes resultados de test, tanto en la pantalla de calibraci on como en la principal.
82
Figura 8.17: Diagrama de clases principal GCS.
Cap tulo 9 QSearch

En este cap tulo se presenta un algoritmo de b usqueda optimizada desarrollado para ser aplicado a la calibraci on de controladores PID. El objetivo es encontrar una parametrizaci on PID que ofrezca estabilidad de vuelo con el m nimo n umero de casos de prueba. Cuando se desea resolver un problema de optimizaci on del cual no se tiene una descripci on matem atica, o a un teni endola no es posible aplicar (o no son efectivos) los m etodos anal ticos de resoluci on conocidos, se puede recurrir a los m etodos de b usqueda optimizada. Los algoritmos de b usqueda optimizada son m etodos computacionales que intentan optimizar un problema a base de ir eligiendo posibles soluciones dentro del espacio de b usqueda del problema, apoy andose en una funci on objetivo que indica c omo de buena es la soluci on seleccionada. Hasta ah la descripci on encaja con cualquier algoritmo de b usqueda usual, el secreto de los algoritmos de b usqueda optimizada reside en explorar el espacio de b usqueda ecientemente, dando una soluci on al problema antes de lo que lo har a un m etodo aleatorio. El caso de la parametrizaci on de controladores PID es un caso concreto de problema de optimizaci on. El objetivo es elegir los valores o ptimos de las variables que parametrizan el controlador,Kp, Ti y Td. Para ello normalmente es necesario contar con un modelo de simulaci on del proceso que permita escoger los valores bas andose en el modelo din amico. Sin embargo, en ocasiones no se cuenta con dicho modelo (ya sea por complejidad o limitaciones en recursos). En estos casos se puede optar por realizar b usquedas optimizadas. Para ello se dene el espacio de b usqueda (espacio de soluciones) como un espacio tridimensional formado por todos los posibles valores de Kp, Ti y Td. A la hora de realizar la b usqueda se cuenta con la gran restricci on del coste de calcular la calidad de la soluci on seleccionada, ya que la funci on de calidad no es instant anea. Para calcular la calidad de una soluci on es necesario realizar una medida del comportamiento del modelo que puede incluir diferentes factores, tales como tiempo de reacci on, oscilaci on, precisi on y muchos otros indicadores que deben ser medidos con el sistema en marcha durante un tiempo determinado. Por esa raz on el objetivo de este algoritmo de b usqueda optimizada no es encontrar la mejor soluci on, o una soluci on con un grado de resoluci on dado, sino encontrar una soluci on sucientemente buena con el m nimo n umero de candidatos seleccionados. En el caso de la estabilizaci on de un UAV de cuatro motores la soluci on debe permitir una salida estable, m nima oscilaci on y m nimo tiempo de reacci on ya que este control es cr tico. Para ello es primordial una gran eciencia en la exploraci on del espacio de soluciones y un alto nivel de convergencia del algoritmo de b usqueda, d andole menor valor a otros factores como gran resoluci on de la soluci on, o conocimiento de los diferentes m aximos/m nimos locales, etc. 83
84
CAP ITULO 9. QSEARCH
9.1.
Antecedentes en b usqueda optimizada
Cuando surgi o el problema de la optimizaci on de los par ametros PID, se realiz o un estudio sobre los diferentes m etodos de optimizaci on existentes para examinar qu e m etodos pod an ser aplicados y si eran pr acticos en el caso concreto de nuestro problema.
9.1.1.
M etodos num ericos
Existen diferentes tipos de algoritmos de optimizaci on [44] [7]. Cuando el problema en cuesti on puede ser modelado matem aticamente pero la resoluci on anal tica es complicada se pueden usar m etodos de optimizaci on num ericos, basados en la aproximaci on usando diferentes vertientes, tales como el m etodo de Newton, el m etodo del Gradiente, o diferentes combinaciones que aprovechan las virtudes de ambos m etodos [7]. Estos m etodos necesitan que los problemas sean derivables, ya que precisan del c alculo 1 de Gradientes y Hessianas para conocer hacia d onde buscar. Otros m etodos especulan sobre las propiedades de concavidad/convexidad del problema para poder atacarlo. Al no contar con un modelo matem atico de comportamiento estos m etodos no son aplicables.
9.1.2.
Algoritmos basados en muestras
Los ltros de part culas se basan en el concepto de muestra estad stica. El conjunto muestral es una poblaci on de part culas generadas y repartidas de manera pseudoaleatoria por todo el espacio de b usqueda. En lugar de aplicar la funci on objetivo sobre todas las posibles soluciones se aplica a cada una de las part culas (muestras). Una vez evaluada la poblaci on de part culas, se mueven o se generan nuevas part culas siguiendo una ley matem atica de alg un tipo, de manera que con las siguientes iteraciones el algoritmo converge en probabilidad al o ptimo. Dicho de otra manera, al aumentar las iteraciones la probabilidad de contar con la soluci on o ptima entre la poblaci on de part culas seleccionadas tiende a uno. Los algoritmos gen eticos [17] y el algoritmo PSO2 [28] son otros tipos de algoritmos basados en muestras que usan diferentes aproximaciones y heur sticas. El problema com un de los algoritmos basados en ltros de part culas reside en la cantidad de evaluaciones de la calidad o tness a realizar, al menos una para cada part cula por cada iteraci on.
9.1.3.
Cuckoo Search
El algoritmo Cuckoo Search [50] (en adelante CS) es un reciente algoritmo de muestras basado en la aplicaci on de metaheur sticas provenientes de la naturaleza. Como muchos otros algoritmos de optimizaci on, las dos caracter sticas principales de estas metaheur sticas son la intensicaci on o capacidad de buscar siempre cerca de las mejores soluciones, y la diversicaci on o capacidad de explorar todo el espacio de b usqueda ecientemente. B asicamente CS comienza esparciendo aleatoriamente una poblaci on de part culas a lo largo del espacio de b usqueda, se calican las soluciones y se queda con las mejores. Una
La matriz hessiana de una funci on f de n variables, es la matriz cuadrada de n x n, de las segundas derivadas parciales http://es.wikipedia.org/wiki/Matriz_hessiana 2 Particle Swarm Optimization
1
DEL ALGORITMO QSEARCH 9.2. DESCRIPCION
85
Figura 9.1: Vuelo Levy convencional parte de las peores soluciones se descartan y sustituyen por nuevas soluciones y el resto de part culas se mueven siguiendo una distribuci on L` evy [40]. Para modelizar el movimiento de las part culas los autores se jaron en el comportamiento del vuelo de algunas moscas de la fruta y aves, que se ajusta a los denominados L` evy Flights. Este tipo de vuelo se caracteriza por largos recorridos en l nea recta seguidos de bruscos cambios de direcci on con giros de 90 grados. La direcci on del giro se distribuye uniformemente y el tama no del incremento est a distribuido de acuerdo a una distribuci on a de L` evy de la forma y = x , donde 1 < a < 3. Para CS cada soluci on del espacio de b usqueda es un nido, de ellos se elige una poblaci on de nidos en los que depositar huevos (soluciones candidatas). La funci on objetivo pone nota a la calidad de cada nido, en cada iteraci on se descarta una fracci on de los peores nidos, y se seleccionan nuevos nidos a trav es de L` evy Flights (la poblaci on de nidos permanece constante). La potencia del algoritmo se basa en usar vuelos L` evy para explorar el espacio de soluciones y para a nadir aleatoriedad a la selecci on de nuevas soluciones candidatas. Aunque todos los algoritmos revisados generan soluciones muy buenas, ninguno asegura encontrar el m aximo global. Adem as, aunque cuentan con estrategias de exploraci on del espacio de b usqueda ecientes, necesitan grandes cantidades de pruebas de soluciones candidatas, al tratarse de algoritmos iterativos es necesario realizar varias iteraciones para que las part culas converjan. Si contamos con una poblaci on de tama no n constante, necesitaremos de n Iteraciones ejecuciones de la funci on de calidad, lo que en el caso que nos ocupa es un n umero demasiado grande.
9.2.
Descripci on del algoritmo QSearch
El algoritmo QSearch parte del intento de usar el Cuckoo Search para el caso de la calibraci on de PIDs. A la hora de realizar las primeras pruebas se constat o que el n umero de
86 Algorithm 1 Pseudoc odigo del algoritmo QSearch Fitness Function f (x), x = (x1 , x2 , ..., xd )T ; 1: Init x0 randomly; 2: Init Fg = min(f (x)) (best global solution); 3: t = 0; i = 1; 4: while (t < M axIterations) or (StopCriterion) do 5: Calculate tness of xt , Fxt ; 6: if (Fxt > Fg ) then 7: Update Fg and Reinit the ight from xt 8: else 9: if (i > ) then 10: Reinit the Flight from Fg 11: end if 12: Update StepLength and calculate new UCN 13: t + +; i + +; 14: xt = xt1 + StepLength UCN ; 15: end if 16: end while 17: Process Result;
ejecuciones de la funci on de calidad necesitadas por el Cuckoo Search supon a una limitaci on debido al tiempo consumido por cada ejecuci on. Adicionalmente, a la hora de analizar los algoritmos existentes, todos ellos hac an hincapi e en la precisi on con la que se acercaban a los m aximos te oricos en las pruebas que ejecutaban, pero a costa del n umero de ejecuciones de la funci on de calidad. Sin embargo, para nuestro objetivo no es tan importante la resoluci on de la soluci on como minimizar el n umero de ejecuciones necesarias para llegar a una resoluci on m nima. Como ya se ha comentado anteriormente, un algoritmo de b usqueda optimizada debe cumplir dos caracter sticas principales, la diversicaci on o exploraci on del espacio de b usqueda ecientemente, y la intensicaci on o la capacidad de aprovechar el principio de localidad espacial. Esta u ltima se reere a la caracter stica de continuidad de las funciones sobre las que se aplica el algoritmo que hace que los m aximos locales o el m aximo global est e localizado espacialmente muy cerca de soluciones muy cercanas a dicho m aximo, por continuidad. Para realizar una exploraci on eciente del espacio de soluciones, la idea de usar paseos aleatorios (random walks) como los obtenidos por L` evy Flights pareci o muy buena. Un vuelo L` evy (gura 9.1) es un paseo aleatorio que sigue una distribuci on de L` evy, de la a forma y = x , como ya se ha mencionado. Los vuelos L` evy son procesos de Markov3 , muy u tiles para modelizar datos que exhiben el agrupamiento, y usados para modelar fen omenos naturales al azar. Se caracterizan por largos saltos seguidos de peque nos saltos con cambios bruscos de direcci on, y modelan muy bien comportamientos de b usqueda en el mundo animal. Tiburones, moscas, y aves presentan este tipo de patr on de b usqueda de alimentos cuando no consiguen buenos resultados con los patrones est andar. QSearch utiliza algunas caracter sticas del vuelo L` evy, pero la longitud de los saltos
Tipo especial de proceso estoc astico discreto en el que la probabilidad de que ocurra un evento depende del evento inmediatamente anterior http://es.wikipedia.org/wiki/Cadena_de_Markov
3
DEL ALGORITMO QSEARCH 9.2. DESCRIPCION
87
utilizada sigue una distribuci on exponencial del tipo y = xa , por lo que a la trayectoria la he llamado vuelo L` evy invertido (a partir de ahora vuelo invertido). Adem as no se trata de un ltro de part culas. Puesto que deseamos minimizar el n umero de ejecuciones, tan solo existir a una u nica part cula que se mover a siguiendo un vuelo invertido de longitud limitada. Para que sea efectivo, cada nuevo vuelo debe iniciarse desde la posici on de la mejor soluci on encontrada hasta el momento. Entonces buscar a cerca de esta posici on, y si no consigue mejorar el resultado realizar a algunos saltos muy lejos, se alejar a exponencialmente con cambios de direcci on de 90 grados y sentidos aleatorios hasta encontrar una mejor soluci on o llegar al l mite de saltos. La direcci on a tomar cambia en cada salto, siendo siempre normal al vector que caracteriz o el salto anterior. Cada vez que un nuevo salto encuentra una soluci on que mejora a la actual el vuelo se reinicia, de modo que se vuelve a intentar buscar cerca de dicho punto. StepLength = i (9.1)
La longitud del salto viene dada por la ecuaci on 9.1, donde > 0 es una constante de proporcionalidad asociada a las dimensiones del espacio de soluciones y a la resoluci on que es capaz de alcanzar la b usqueda. tendr a un valor entre 1 y 3 siendo la constante que dene c omo de grande ser a el siguiente salto respecto al anterior, parametrizando c omo de r apido crece la longitud de los saltos de un vuelo. Finalmente, i es la variable que indica la iteraci on del vuelo en la que se encuentra el algoritmo, comenzar a siendo 1 y se incrementar a con cada salto, al reiniciar el vuelo volver a a tomar valor 1. La longitud del salto sigue una distribuci on con varianza innita, donde la distancia del origen de un vuelo al azar tiende a una distribuci on estable, adem as el escalamiento de los saltos da al vuelo una propiedad de escala invariante. Una vez denida la longitud del salto se calcula la direcci on del mismo. Obtenemos un nuevo vector unitario que nos dena la direcci on a seguir, este vector lo llamaremos UCN puesto que viene dado por el punto C (Current/Actual) que es el punto de origen del salto y el punto N (New/Nuevo) que es el nuevo punto correspondiente a la nueva soluci on a probar (ser a sometido a la funci on de calidad). Para ello partimos del vector OC que se corresponde con el vector que deni o el salto anterior y que est a denido por el punto O (Old/Antiguo) que es el punto de origen del salto anterior, y el punto C (Current) que es el punto de origen del salto actual (y se corresponde con la u ltima soluci on probada, o destino del u ltimo salto realizado). Como UCN debe ser perpendicular a OC , para conseguir un vector normal a OC tan solo se debe seleccionar cualquier vector del espacio y realizar el producto cruzado de este vector cualquiera con OC . Para seleccionar este vector para el producto cruzado podemos elegir el vector compuesto por el punto C (Current/Actual) y un punto seleccionado de manera aleatoria R (Random/Aleatorio), de esta manera introducimos el factor aleatorio que dirigir a UCN . Una vez seleccionado R de manera aleatoria (eligiendo coordenadas que se encuentren dentro del espacio de soluciones), componemos el vector CR y realizamos el producto cruzado OCxCR y conseguimos un vector normal (perpendicular) a OC (y a CR) pero no unitario, tan solo debemos convertir dicho vector en un vector unitario y obtendremos UCN . Xi+1 = Xi + StepLength UCN (9.2)
88
La nueva posici on del salto viene dado por la ecuaci on 9.2. En la primera iteraci on a un no existe ning un vector OC , por lo que basta con elegir un punto origen al azar y otro punto destino tambi en al azar de modo que podamos construir un primer vector unitario UCN que nos d e la direcci on y sentido del primer salto, entonces el punto origen (C ) se convertir a en O y el punto destino (N ) se convertir a en C , y a partir de ah ya se pueden calcular el resto de saltos tal y como se ha indicado. Despu es de calcular un nuevo salto se obtiene un punto nuevo N que se corresponde con una soluci on a probar, entonces se calcula la calidad de la soluci on con la funci on de Fitness especicada. Si la calidad del nuevo punto no mejora a la de la mejor soluci on encontrada hasta el momento se sigue con el vuelo y se calcula un nuevo salto y un nuevo punto N , para ello el actual punto C pasa a ser el punto O en la nueva iteraci on, de la misma manera el punto N pasa a ser el nuevo punto C y el nuevo punto N a probar se calcula siguiendo el algoritmo, realizando un salto desde el punto C tal y como se ha denido. Para limitar el n umero de saltos de un vuelo se a nade una restricci on adicional, de modo que si el vuelo invertido realiza saltos sin encontrar una soluci on mejor que la existente, entonces se reinicia el vuelo de modo que se realiza un vuelo invertido nuevo. El par ametro indica, por tanto, la longitud m axima de un vuelo, el sentido de este par ametro es evitar que se llegue a saltos en el vuelo de tal magnitud que se salgan del espacio de b usqueda y queden reducidos a los l mites del mismo. Por lo que hay que parametrizar este par ametro junto con y de modo que en saltos con los valores seleccionados se pueda llegar de cualquier punto a cualquier otro punto en el espacio de soluciones, de esta manera aseguramos que la exploraci on del espacio de soluciones sea optima. Como regla general, para tener una buena relaci on de n umero de pruebas a realizar y calidad de las soluciones, deber a bastar con seleccionar entre 6 y 8, de modo que en 6 a 8 saltos se abarque la m axima separaci on en el espacio de b usqueda. Los par ametros y deben parametrizarse una vez denido , dene la longitud m nima del salto, o la resoluci on que es capaz de alcanzar el algoritmo y la aceleraci on del vuelo.
9.3.
Experimentos
Para vericar el correcto comportamiento del algoritmo, antes de probarlo con el veh culo, se realizaron varias pruebas usando como funciones objetivo funciones conocidas, de modo que nos permitiese comparar los resultados obtenidos con los conseguidos con otros algoritmos. Una de las funciones de prueba usada fue la funci on de Michaelwicz 9.3: f (x) = sin(x)sin2m ( 2y 2 x2 sin(y )sin2m ( ))
(9.3)
En la gr aca 9.2 podemos ver el comportamiento de dicha funci on cuando (x, y ) [0, 4]x[0, 4]. Podemos observar que la funci on tiene varios m nimos locales y un m nimo global situado en el punto (2.2031,1.5704) en la que la funci on toma el valor -1.8013. En las siguientes gr acas vemos la trayectoria seguida por Qsearch con diferentes conguraciones. En la gr aca 9.3-izquierda vemos una conguraci on 3-6-3 ( ) y 100 iteraciones (ejecuciones de la funci on de calidad) con un resultado de -1.7836 en el punto
9.3. EXPERIMENTOS
89
Figura 9.2: Michaelwicz Landscape (2.2354,1.5736), bastante aceptable para solo 100 ejecuciones, con esa conguraci on no mejora la precisi on signicativamente con el n umero de iteraciones al tener el par ametro un valor alto. En la gr aca 9.3-derecha vemos una conguraci on 2-7-3 y 100 iteraciones obteniendo una mejora en la resoluci on de la soluci on encontrada. En las gr acas 9.4 vemos c omo el comportamiento mejora sustancialmente al bajar y aumentar las iteraciones, con 240 iteraciones el resultado es muy bueno obteniendo un m nimo de -1.80128 en el punto (2.2017,1.5706). Aunque la mejor relaci on de ejecuciones/resoluci on lo tenemos en la gr aca 9.4-izquierda con una conguraci on 0.5-6-3 y 200 iteraciones, obteniendo un resultado de 1,80107 en el punto (2.2022,1.5731). Tras los alentadores resultados de Qsearch aplicado a la funci on de prueba usada, se procedi o a probar el algoritmo integrado en el software embarcado. Para ello se us o el banco de pruebas dise nado para probar el controlador PID de cabeceo y alabeo (pitch y roll). Las pruebas realizadas y los resultados asociados se detallan en el cap tulo 10.
90
Figura 9.3: A la izquierda vemos uan ejecuci on Qsearch de Michaelwitz con 3-6-3 y 100 iteraciones (2.2354,1.5736) = - 1.7836. A la derecha vemos una ejecuci on Qsearch de Michaelwitz con 2-7-3 y 100 iteraciones (2.2079,1.5649) = - 1.7995
Figura 9.4: A la izquierda vemos una ejecuci on Qsearch de Michaelwitz con 0.5-8-3 y 240 iteraciones (2.2017,1.5706) = - 1.80128. A la derecha vemos una ejecuci on Qsearch de Michaelwitz con 0.5-6-3 y 200 iteraciones (2.2022,1.5731) = - 1.80107.
Cap tulo 10 Pruebas

Una parte fundamental de este proyecto lo constituyen las diferentes pruebas realizadas a lo largo del proyecto. Se han realizado multitud de pruebas unitarias para probar cada uno de los componentes hardware de manera independiente, incluyendo rangos soportados, saturaci on de los sensores, frecuencias de adquisici on m aximas soportadas, etc. Por otro lado, se han realizado pruebas unitarias de los algoritmos utilizados, tanto del algoritmo DCM, como de los PIDs implementados. En el caso del algoritmo DCM se han utilizado los diferentes bancos de test construidos para probar la exactitud de los a ngulos calculados a partir de los valores de los sensores, midiendo en el banco de test el a ngulo real y compar andolo con el obtenido usando el algoritmo. Tambi en se han realizado pruebas de estabilidad de los resultados, sacando medidas como media, moda y desviaci on t pica, tanto de los valores obtenidos del algoritmo DCM como de cada uno de los drivers de los sensores. Gracias a esto, se han podido introducir peque nos ltros software para estabilizar las medidas, o incluso se han a nadido o eliminado en su caso ltros hardware cuando ha sido necesario. Para realizar pruebas de mayor nivel, como pruebas de integraci on completa, y test concretos para probar la abilidad de los algoritmos de control, fue necesario construir varios bancos de pruebas. El primer banco de pruebas consisti o en la construcci on de un balanc n de madera que oscilaba sobre una visagra que un a el balanc n con una base tambi en de madera que elevaba el modelo a 30 cent metros del suelo. En los extremos del balanc n se montaron dos motores con sus respectivas h elices (primero un solo motor en un lado y m as adelante uno en cada extremo). Las primeras versiones de la UC se montaban rudimentariamente en el centro del balanc n. Con este primer banco de pruebas se pudo validar el correcto funcionamiento del algoritmo DCM, as como la integraci on de los m odulos de acceso a sensores y de alimentaci on de los motores. En las iteraciones siguientes, y para poder probar con exactitud los controladores de estabilizaci on fue necesario construir un segundo banco de pruebas m as sosticado. Esta vez era el propio veh culo el que quedaba perfectamente encajado en el banco de pruebas, 91
92
CAP ITULO 10. PRUEBAS
Figura 10.1: Primer banco de test utilizado, el balanc n.
Figura 10.2: Segundo banco de pruebas: permite libre movimiento del veh culo sin apenas rozamiento.
10.1. PRUEBAS EN BANCO
93
Figura 10.3: Plano de dise no de pieza adaptador para el banco de test. Minimiza el rozamiento al ajustar el veh culo en el banco a trav es de un rodamiento de bolas. construido de manera m as robusta. Para facilitar el giro del modelo eliminando toda resistencia y simular de este modo el comportamiento en el aire se dise no una pieza especial que permitiese unir los ejes del veh culo con el banco de pruebas a trav es de rodamientos de bolas (Figura 10.3). El banco de pruebas, que podemos ver en la gura 10.2, permite el movimiento libre del modelo en un eje, minimizando el rozamiento, de manera que las pruebas de estabilizaci on se acercaban de manera precisa al comportamiento del veh culo en el aire. Este banco de pruebas sirvi o para poder realizar tambi en las pruebas de calibraci on usando el algoritmo QSearch, ejecutando tandas de calibraci on con el veh culo movi endose durante m as de 4 horas consecutivas. El banco de pruebas ha sido todo un exito uno de los elementos sin el cual el proyecto hubiese avanzado de manera mucho m as lenta.
10.1.
Pruebas en banco
Adem as de las pruebas te oricas realizadas sobre el algoritmo QSearch, se han realizado pruebas pr acticas del algoritmo de calibraci on usando QSearch aplicadas al veh culo montado sobre el segundo banco de pruebas. La funci on de calidad (tness ) utilizada ha sido tambi en implementada desde cero teniendo en cuenta varios factores que pasaremos a resumir. Dicha funci on debe medir la estabilidad del modelo, entendi endose por estabilidad la uni on de varios aspectos. La entrada del PID ser a el a ngulo calculado por el procesador embebido en el veh culo respecto a la horizontal. Se establecen unos l mites de estabilidad, caracterizados por la constante MARE (M axi mo Angulo en R egimen de Estabilizaci on), que situaremos en 5 grados, y que denen el error permitido dentro del r egimen de estabilizaci on. Mientras el angulo (AngAct ) est e en dichos
94
m argenes consideraremos que el modelo se encuentra estabilizado, la ecuaci on 10.1 resume esta idea. AngObj M ARE < AngAct < AngObj + M ARE (10.1)
Deniremos cuatro m etricas que unidas conformar an la m etrica de calidad. Dichas m etricas son: M etrica 1: Porcentaje de tiempo durante el cual el modelo ha estado dentro de los m argenes de estabilidad. Se debe maximizar. M etrica 2: Se calcula para cada periodo de desestabilizaci on la media de error en a ngulo respecto al objetivo seleccionando el m aximo de dichas medias. Hay que minimizar esta m etrica. M etrica 3: M aximo tiempo transcurrido desde que el modelo se ha desestabilizado hasta que ha vuelto a entrar en r egimen de estabilizaci on, mide el tiempo de reacci on, se debe minimizar. M etrica 4: An aloga a la m etrica 2 pero minimizando el error en r egimen de estabilizaci on. La funci on de calidad se dene como la suma ponderada de las cuatro m etricas, para ello se normalizan todas las m etricas y se ponderan asignando costes a cada m etrica, las m etricas a maximizar se suman y las m etricas a minimizar se restan como se puede ver en la ecuaci on 10.2. F itness = P1 M et1 P2 M et2 P3 M et3 P4 M et4 (10.2)
Para la realizaci on de las pruebas se congur o una parametrizaci on de Qsearch en la que se limit o el espacio de b usqueda de la siguiente manera: (p, i, d) [200, 600]x[1, 200]x[1, 50] Aunque las dimensiones de cada par ametro est an acotadas de modo que los rangos se limiten a valores comprensibles para un controlador PID y cada uno tiene una dimensi on diferente, a la hora de realizar los vuelos se normalizan todos para que el espacio de soluciones tenga forma de cubo de (200x200x200). De manera que se simplique la visualizaci on de los datos. Aunque la primera estimaci on para una calibraci on adecuada, habla de un n umero de iteraciones de entre 200 y 350, se puede comprobar el buen comportamiento del algoritmo de calibraci on al realizar una calibraci on de tan solo 40 iteraciones. El tiempo medio de cada ejecuci on de la funci on de tness es de 35 segundos con 5 segundos de reposo entre test y test. En la gr aca 10.4 se puede ver la primera iteraci on y el resultado de la funci on de calidad. En la gr aca 10.5 se puede ver el resultado nal del Qsearch y la gr aca correspondiente a la mejor soluci on encontrada. El resultado de esta calibraci on ha sido un tness de 27.490 (en una escala de -50 a 50), cuando la mejor calibraci on realizada a mano siguiendo los m etodos de calibraci on manual encontrados no hab a sido mejor de 22.670. Por lo que podemos concluir que el algoritmo QSearch aplicado a la calibraci on del PID del UAV es muy efectivo.
10.1. PRUEBAS EN BANCO
95
Figura 10.4: QSearch aplicado al UAV, tercera iteraci on de 40
Figura 10.5: Qsearch aplicado al UAV, muestra el resultado tras 40 iteraciones
96
10.2.
Pruebas en vuelo
Adicionalmente se realizaron pruebas de vuelo libre que resultaron interesantes y provocaron cambios tanto en bancos de tests como en algoritmos de control. La primera prueba de estabilizaci on fuera de banco consisti o en colgar el veh culo de cuerdas ancladas al techo del laboratorio de rob otica de la URJC. La prueba no logr o los resultados esperados, la tensi on de la cuerda ejerc a fuerzas secundarias que imped an a los controladores obtener resultados reales de sus acciones y la prueba tuvo que ser suspendida. En la segunda prueba se tendieron cuerdas por el laboratorio de manera que sujetaran el veh culo por los cuatro extremos. Una quinta cuerda aseguraba el veh culo al suelo a trav es de un peso. Las cuerdas no se encontraban en tensi on sino que permit an cierto movimiento. Pronto se comprob o que era in util la prueba al ser demasiado corto el recorrido de las cuerdas y al ser insuciente la calibraci on realizada en los controladores PIDs. Como resultado de dicha prueba se construy o el segundo banco de test m as preciso y con menor rozamiento. La tercera prueba libre fue similar a la segunda, esta vez el modelo calibrado en el segundo banco de test de manera m as precisa, y las cuerdas de los extremos manejadas por asistentes humanos. La idea era que los asistentes pudieran soltar cuerda suciente como para comprobar el comportamiento del modelo en vuelo, pero con la precauci on de poder tensar las mismas en caso de error de estabilizaci on. Aunque la prueba fue algo mejor que la anterior los resultados no fueron positivos, en gran medida debido a una variaci on inusual de las lecturas de aceleraci on, debido a fallos de los sensores que debieron ser sustituidos. La siguiente prueba no se realiz o hasta obtener una calibraci on optima en banco de test usando QSearch. Fue la primera prueba de vuelo sin cuerdas, utilizando el protector de poliestireno. Una persona se encargaba de controlar que el veh culo no se estrellase, mientras otra controlaba las potencias aplicadas a trav es de la GCS. El resultado fue mucho mejor que los obtenidos hasta el momento, sin embargo, las pruebas delataron un comportamiento err atico cuando la potencia de los motores alcanzaba cierto nivel. Despu es de varias pruebas se descubrieron problemas de vibraciones que hac an que los sensores devolviesen valores sin sentido, haciendo que el algoritmo DCM no calculase bien la posici on del veh culo. Una vez solucionados los problemas de vibraciones usando una plataforma absorvente y gomas en las juntas de motores y UC se procedi o a realizar una nueva prueba de estabilizaci on en vuelo libre. Esta vez la prueba result o un exito, consiguiendo un nivel de estabilizaci on bastante alto. Aunque a un quedaba un problema importante, y es que el modelo era estable, pero el control de la altitud y el desplazamiento horizontal hac an imposible la realizaci on de pruebas largas en interiores. La u ltima prueba realizada de vuelo libre antes de la redacci on de esta memoria prob o el modelo integrado con el control autom atico de altura usando s onar y control de rumbo utilizando el comp as digital. Fue la primera vez que el veh culo realizaba una prueba de vuelo sin ning un tipo de sujeci on. El resultado no fue muy positivo al estrellarse el veh culo con un obst aculo del laboratorio, destrozando el protector de poliestireno y causando da nos en las h elices. El an alisis del siniestro parece concluir que el problema estuvo relacionado con una mala calibraci on tanto de los PIDs responsables del control de altitud como de rumbo. Dichos PIDs no pueden ser calibrados autom aticamente usando QSearch y se establecieron de manera manual. La pr oxima prueba, una vez perfeccionada la calibraci on de los PIDs e introducido el control semiautom atico con joystick, consistir a en un primer vuelo al aire libre.
Cap tulo 11 Conclusiones y Trabajos Futuros

11.1. Conclusiones y Objetivos Alcanzados
El primer objetivo de este proyecto era analizar y proponer una soluci on a los principales retos implicados en el desarrollo de un proyecto de ingenier a completo como el desarrollo. Estudiar las capacidades necesarias para llevar a cabo el dise no e implementaci on de un veh culo a ereo aut onomo con capacidades de aterrizaje y despegue vertical con las restricciones de bajo coste impuestas. Teniendo en cuenta estos factores, se puede armar que se ha logrado ese objetivo. Se han cubierto todas las fases de un proyecto software, desde el an alisis de los requisitos y su especicaci on, a la realizaci on de pruebas, tanto unitarias, de integraci on y en banco de ensayos, pasando por el dise no e implementaci on. Y se puede armar que es posible llevar a la pr actica dicho proyecto con un ndice de exito bastante grande. Siguiendo una metodolog a agil, basada en incrementos, se han completados todas las fases que intervienen en el desarrollo, pero lo que es m as, se ha realizado simult aneamente para tres disciplinas: por un lado software embarcado, por otro dise no y construcci on de la plataforma hardware, y por u ltimo una aplicaci on de mando y control con una completa interfaz gr aca de usuario. Este proyecto Fin de Carrera constituye un buen ejemplo de proyecto multidisciplinar que integra diferentes tipos de desarrollos, desde la optimizaci on de algoritmos y rutinas para su correcta ejecuci on en una plataforma hardware con recursos limitados en capacidad de procesamiento, memoria y tama no del c odigo, hasta las complicaciones del desarrollo de interfaces gr acas usando librer as gr acas. Con el a nadido de construir la plataforma de ejecuci on, afrontando la elecci on de materiales, la construcci on del chasis, o el dise no de la placa de circuito donde montar los diferentes dispositivos.
11.1.1.
Plataforma Hardware
En lo que respecta a la plataforma hardware, se ha realizado un profundo an alisis de los componentes necesarios, las restricciones encontradas, y las diferentes soluciones existentes. Y se ha encontrado una soluci on sucientemente elegante y efectiva, tanto para el chasis del veh culo, como para la integraci on de sensores y actuadores con el microcontrolador. 97
98
CAP ITULO 11. CONCLUSIONES Y TRABAJOS FUTUROS
Una de las primeras conclusiones respecto a la plataforma hardware es que la integraci on de dispositivos con una plataforma embebida es muy compleja y supone un gran esfuerzo de integraci on. Adem as la fase de an alisis y pruebas de integraci on lleva una gran cantidad de esfuerzo en tiempo y presupuesto. Una vez completada la integraci on nal, se puede armar que la calidad de los dispositivos (y por tanto su coste) inuye en gran medida de la calidad de los resultados obtenidos. Una mala elecci on de dispositivos, ya sean estos sensores, ESCs, motores, h elices, incluso el microprocesador, deriva en un desarrollo software embarcado m as complejo y con mayor riesgo. En este caso concreto, si se tuviese que comenzar un desarrollo de cero, quiz as se probar a con otros tipos de microprocesadores, con m as memoria y capacidad de procesamiento. Quiz as una plataforma basada en un microprocesador ARM con mayor rendimiento (200MHz, 128MB de RAM y sin limitaciones de tama no de c odigo) evitar a gran cantidad de problemas de rendimiento, existen soluciones con un coste similar a la elegida (Arduino, Seeeduino), que implementan el .Net MicroFramework, que podr an usarse. Tambi en se invertir a mayor presupuesto en la calidad de los sensores para evitar problemas como los de las vibraciones, y se seleccionar an ESCs no basados en PWM de manera que tuviesen tasas de actualizaci on del orden de los 400 Hz (la actual es de 50 Hz). Por u ltimo, un dato muy interesante obtenido es el coste, tanto en horas como en presupuesto del desarrollo de la plataforma hardware. El presupuesto total utilizado para el desarrollo de la plataforma hardware ha sido de 700, este presupuesto es mucho m as elevado del estimado al comienzo del proyecto. La causa principal del desajuste ha sido la nula experiencia al enfrentarse a diferentes tipos de dispositivos, as como el mismo problema orientado al desarrollo de circuitos, desde el dise no de pistas, a conocimiento de diferentes buses y tecnolog as, incluso la pericia a la hora de realizar soldaduras, manejar componentes electr onicos, etc. Esto ha hecho que sea necesario comprar componentes alternativos para sustituir a aquellos no v alidos, o inutilizados en el proceso de desarrollo. Con la experiencia obtenida, el presupuesto necesario para volver a realizar este proyecto desde cero se quedar a en aproximadamente 250, teniendo en cuenta que la calidad de los componentes ser a mayor. En cuanto a los recursos necesarios, la plataforma hardware, incluyendo integraci on y pruebas, ha supuesto un total de 255 horas de trabajo repartidas a lo largo de 18 meses.
11.1.2.
Software Embarcado
En cuanto al software embarcado, se han comprobado las capacidades de la plataforma Arduino y sus limitaciones. Aunque la curva de aprendizaje y la dicultad del desarrollo para la plataforma no es alto, para proyectos complejos como este, puede resultar complicado cumplir los requisitos de rendimiento, debido por un lado a la limitaci on del tama no del c odigo embebido, y por otro, y m as importante, a las limitaciones del microprocesador Atmel 328 en aplicaciones con necesidades de tiempo real como la implementada. Una de las grandes limitaciones encontradas en el proceso de desarrollo ha sido la incapacidad de la plataforma Arduino de ofrecer un mecanismo sencillo de depuraci on de c odigo. Es necesario implementar un sistema complementario de mensajes de depuraci on tanto para poder realizar pruebas unitarias, como para depurar c odigo en caso de comportamientos an omalos.
11.1. CONCLUSIONES Y OBJETIVOS ALCANZADOS
99
Por otra parte, se ha adquirido una gran experiencia en optimizaci on de c odigo para su ejecuci on en una plataforma concreta, desde la forma y el lugar donde declarar variables, hasta optimizar el uso de tipos de datos de manera que se aproveche al m aximo el espacio ocupado en memoria. Tambi en el uso de los timers hardware que ofrece la plataforma as como otros mecanismos espec cos del hardware, la implementaci on de planicadores para controlar y limitar el tiempo de ejecuci on de cada rutina. Y, por supuesto, la manera de modularizar y estructurar el c odigo para optimizar tanto el rendimiento como el uso de memoria. En cuanto a costes y recursos, el proceso de desarrollo del software embarcado, incluyendo pruebas ha supuesto 240 horas repartidas a lo largo de los 18 meses de duraci on del proyecto. Hay que tener en cuenta que el desarrollo del software embarcado est a muy relacionado con el desarrollo de la plataforma hardware, y que se han utilizado gran parte de las horas en an alisis, investigaci on y pruebas. Los diferentes m odulos est an dise nados de manera que ofrecen una interfaz compacta, por lo que pueden ser reutilizados en otros proyectos. El software embarcado en su versi on 0.3 (la entregada en el CD anexo) cuenta con un total de 1551 l neas, que ocupan en microprocesador 23.194 Bytes.
11.1.3.
Estaci on de Tierra (GCS)
Respecto a la estaci on de tierra, ha sido muy interesante el conocer la manera adecuada de representar ciertos datos, de manera que se aproveche al m aximo y se obtenga la m axima inteligencia de los mismos. Otro de los retos satisfechos ha sido desarrollar una interfaz gr aca, totalmente escrita con directivas gr acas, limitando el uso de componentes gr acos externos. Tambi en el uso optimizado de instrucciones de OpenGL, ya que el PC utilizado para desplegar la GCS ten a contaba con limitaciones de rendimiento (ATOM 1.6 GHz, 512 MB RAM y chip gr aco Intel). Las mayores dicultades encontradas han sido aquellas relacionadas con solventar c omo realizar rotaciones y traslaciones aplicadas a diferentes objetos, para que estos se mostrasen adecuadamente al usuario. Por u ltimo, es importante hacer notar la gran cantidad de esfuerzo en an alisis y dise no gr aco aplicado para desarrollar determinados componentes gr acos, como el horizonte articial, el modelo 3D, o la representaci on tanto de los resultados de calibraci on como del espacio de b usqueda de la vista de calibraci on. Todos los componentes gr acos y m odulos implementados cuentan con una interfaz compacta y completa, por lo que pueden ser utilizados de una manera muy sencilla en otros proyectos como elementos independientes. El cuanto a los recursos necesarios para el desarrollo de GCS, han sido necesarias un total de 190 horas para el desarrollo completo de la aplicaci on, la cual est a compuesta por un total de 4045 l neas de c odigo.
100
11.1.4.
QSearch
Aunque no era un objetivo inicial del proyecto, el dise no e implementaci on del algoritmo QSearch se ha convertido en pieza fundamental del proyecto. Por un lado, Qsearch ha derivado en un profundo trabajo de investigaci on que ha concluido con el nacimiento de un nuevo algoritmo de b usqueda optimizada cuya aplicaci on es aplicable a muchos otros a mbitos, muy diferentes del utilizado. El proceso de investigaci on abierto concluye que la aplicaci on de un algoritmo de b usqueda optimizada para la optimizaci on de los par ametros de un controlador PID puede mejorar sensiblemente los resultados obtenidos con calibraciones manuales. Sobre todo puede ser de gran ayuda cuando no se dispone de un modelo matem atico de comportamiento, ni de un simulador conable del sistema, abriendo, adem as, otras v as interesantes de investigaci on utilizando QSearch como punto de partida. En el caso particular del proyecto QUAV la calibraci on llevada a cabo ha logrado un resultado sensiblemente el nivel de estabilizaci on conseguida hasta entonces, facilitando el desarrollo del resto de controladores del sistema de estabilizaci on, as como los diferentes sistemas de control de altura, posici on y navegaci on. El coste en horas del desarrollo del algoritmo, as como de la investigaci on asociada al mismo ha sido de 110 horas. Es preciso destacar que dicho trabajo ha culminado en un art culo ((QSearch: B usqueda Optimizada Aplicada a la Calibraci on de Controladores PID o en un Cuadric optero Aut onomo)) presentado y publicado en el 8 Workshop Robocity 2030 ((Robots de Exteriores)) celebrado en el Centro de Autom atica y Rob otica CSIC-UPM en Diciembre de 2010. En total, el coste del desarrollo del proyecto ha sido de 700 en compras m as un total de 780 horas de ingenier a repartidas a lo largo de los 18 meses que han transcurrido desde el comienzo del mismo, a raz on de una media de 10 horas y media a la semana. Suponiendo un coste hora de 30 por hora de ingenier a el coste total del proyecto ascender a a 24.100.
11.2.
Trabajos Futuros
Al ser este un proyecto tan complejo y extenso, el n umero de posibles ramas de desarrollo es demasiado grande como para detallar cada una de ellas, por lo que se expondr an los inminentes pasos a dar sobre el trabajo desarrollado. El primer paso a dar una vez completada la fase de desarrollo actual consiste en una mejora de los sensores y componentes hardware actuales que permita una mayor precisi on en la estabilizaci on del veh culo. Una vez lograda dicha estabilizaci on, se comenzar a a trabajar en los m odulos de navegaci on, en los que no se ha querido entrar en esta memoria, debido a que, aunque se ha realizado alg un desarrollo, a un no han podido ser integrados adecuadamente. Entre ellos, el m odulo de gesti on del rumbo, el m odulo de gesti on de altitud, y el m as importante de ellos, el m odulo de gesti on de la posici on. Para este u ltimo es necesario integrar un m odulo GPS a nivel hardware, para lo que
11.2. TRABAJOS FUTUROS
101
ser a necesario, o bien a nadir un microcontrolador espec co, o bien sustituir la plataforma Arduino por otra con mayor rendimiento basada en microprocesador ARM-8. Tambi en existen m odulos de entrada/salida espec cos para ser usados con plataformas embebidas en tel efonos m oviles como las nuevas arquitecturas Tegra de NVidia basadas en Cortex A8 y que suponen un salto cualitativo espectacular, tanto en rendimiento como en otras capacidades. Una vez integrado el m odulo de posicionamiento se podr a avanzar en la GCS en la vista de navegaci on, la cual puede absorver todo el trabajo que se desee invertir, desde la integraci on de Google Maps en la aplicaci on para monitorizar y crear planes de vuelo, hasta la grabaci on y reproducci on de misiones completas. El cap tulo de carga de pago tambi en est a totalmente inexplorado y cuenta con posibilidades ilimitadas, desde la incorporaci on de c amaras de video, sensores electro- opticos, t ermicos, etc. Con las innitas aplicaciones asociadas a estos m odulos, aplicaciones de visi on computacional, seguimiento de objetos, identicaci on de objetos, modelado 3D a partir de los datos obtenidos, integraci on con nuevos sensores como Kinect de Microsoft. Adem as de otras aplicaciones como la sincronizaci on de varios veh culos, la gesti on de planes de misi on multiples, vuelo acrob atico, y todos los que la imaginaci on pueda enumerar. Los trabajos futuros respecto al algoritmo desarrollado QSearch tienen un cap tulo aparte, como algoritmo de b usqueda optimizado, los resultados obtenidos han sido muy positivos. Uno de los trabajos futuros consiste en un estudio comparativo m as detallado sobre los resultados de Qsearch comparado con resultados al mismo nivel de otros algoritmos de b usqueda optimizada, como los expuestos en el cap tulo correspondiente a QSearch. Otro de los trabajos futuros es el estudio y an alisis de un ltro de part culas m as complejo que permita la ejecuci on de tantos QSearch como part culas en cada iteraci on, complementando los resultados individuales con los globales, permitiendo la implementaci on de un nuevo algoritmo de part culas basado en QSearch y que pueda ser comparado con el resto de algoritmos similares existentes.
102
Bibliograf a
[1] Aeroquad project. http://aeroquad.com/. [2] Gina Angelosanto. Kalman ltering of imu sensore for robot balance control. Bachelor of Science in Mechanical Engineering at the Massachusetts Institute of Technology, June 2008. [3] Arduino project. http://arduino.cc/. [4] Gu a de Arduino con sensor ADXL3xx. http://arduino.cc/en/Tutorial/ADXL3xx. [5] Shield de Arduino para chip Xbee de MaxStream. http://www.arduino.cc/en/Main/ ArduinoXbeeShield. [6] Gu a de Libelium para conguraci on de radios Xbee sobre Shield Arduino. http: //www.libelium.com/squidbee/index.php?title=How_to_set_XBee_parameters. [7] J. Arora. Introduction to Optimum Design. McGraw-Hill, 1989. [8] automatik. Voidbot project. http://voidbot.net/razor-6dof.html. [9] Hernando Barrag an. Wiring. http://wiring.org.co/, 2004. [10] Casey Reas Ben gettingstarted/. Fry. Processing. http://processing.org/learning/
[11] C. Blum and A. Roli. Metaheuristics in combinatorial optimization: Overview and conceptural comparison. ACM Comput. Surv., (35):268308, 2003. [12] P. Castillo, P. Garcia, R. Lozano, and P. Albertos. Modelado y estabilizaci on de un helic optero con cuatro rotores. Revista iberoamericana de autom atica e inform atica industrial, 4(1):4157, Enero 2007. [13] Creative Compunting. p5libs/procontroll/. Procontrol library. http://www.creativecomputing.cc/
[14] B.R. Copeland. Design of pid controllers using ziegler nichols tuning. March 2008. [15] DIY Drones. Ardupilot project. ardupilot-main-page. [16] Marcos Echeita. Mi mikuadricoptero/, 2010. http://diydrones.com/profiles/blogs/ https://sites.google.com/site/
kuadricoptero.
[17] A. Eiben. Genetic algorithms with multi-parent recombination. PPSN III: Proceedings of the International Conference on Evolutionary Computation. The Third Conference on Parallel Problem Solving from Nature, pages 7887, 1994. 103
104 [18] SparkFun Electronics. Sparkfun. http://www.sparkfun.com.
BIBLIOGRAF IA
[19] M. Euston, P. Coote, R. Mahony, J. Kim, and T. Hamel. A complementary lter for attitude estimation of a xed-wing uav. 2008. [20] Federation of American Scientist: UAVs. collect/uav.htm. http://www.fas.org/irp/program/
[21] Greg Goebel. Unmanned Aerial Vehicles. http://www.vectorsite.net/twuav.html. [22] D. E. Goldberg. Genetic Algorithms in Search Optimization and Machine Learning. Addison Wesley, 1984. [23] O. Higuera, C. Aguero, J.M. Ca nas, and S. Millan. Qsearch: B usqueda optimizada aplicada a la calibraci on de controladroes pid en un cuadric optero aut onomo. 8o Workshop Robots de Exteriores, Robocity-2030, pages 269288, Diciembre 2010. [24] HiSystem GmbH. http://www.hisystems.de/. [25] Especicaci on I2C alojada en NXP. http://www.nxp.com/documents/user_manual/ UM10204.pdf. [26] Gu a de uso I2C con Arduino. http://tronixstuff.wordpress.com/2010/10/20/ tutorial-arduino-and-the-i2c-bus/. [27] Instituto de T ecnica Aeroespacial. http://www.inta.es/programasAltaTecnologia. aspx?Id=1&SubId=3. [28] J. Kennedy and R. Eberhart. Particle swarm optimization. Proceedings of IEEE International Conference on Neural Networks, 4:19421948, 1995. [29] Peter Lager. Guicomponent library. http://www.lagers.org.uk/g4p/index.html. [30] Libelium. Xbee arduino shield project. http://www.libelium.com/. [31] University of Florida LIST Lab. Commercial Use of UAVs. http://www.list.ufl. edu/uav/index.htm. [32] R. Mahony, S. Cha, and T. Hamel. A coupled estimation and control analysis for attitude stabilisation of mini aerial vehicles. November 2006. [33] R. Mahony, T. Hamel, and J.M. Pimlin. Nonlinear complementary lters on the special orthogonal group. IEEE Transactions on automatic control, 53(5):12031218, June 2008. [34] Next generation universal aerial video platform project. FrontPage, 2007-2011. [35] Nicoleto Project. http://www.nicoleto.com. [36] M. Araki University of Kyoto. Pid control. Control Systems, Robotics, and Automation, 2, 2001. [37] C. Painter and A. Shkel. Structural and thermal analysis of a mems angular gyroscope. SPIEs 8th annual symposium on Smart Structures and Materials, Newport Beach, CA, March 2001. http://uavp.ch/moin/
BIBLIOGRAF IA [38] William Park. Uav center. america/eCR.asp.
105 http://www.uavcenter.com/english/wwuavs/north_
[39] Parrot. Ar drone. http://ardrone.parrot.com/parrot-ar-drone/es/, 2010. [40] I. Pavlyukevich. L evy ights, non-local search and simulated annealing. J. Computational Physics, (226):18301844, 2007. [41] Pc 104 embedded consortium. http://www.pc104.org/. [42] Phillips. Nxp i2 c bus. http://www.i2c-bus.org/. [43] W. Premerlani and P. Bizard. Direction cosine matrix imu: Theory. DIYDrones Web Seminar, May 2009. [44] R.L. Rardin. Optimization in Operations Research. Prentice Hall, 1997. [45] Paul Rene. Quaduino project. http://quaduino.org/. [46] Y. Shi and R.C. Eberhart. A modied particle swarm optimizer. Proceedings of IEEE International Conference on Evolutionary Computation, pages 6973, 1998. [47] Seeed Studio. Seeeduino project. http://www.seeedstudio.com/blog/. [48] J. Vaganay, M. Aldon, and A. Fournier. Mobile robot attitude estimation by fusion of inertial data. Proc. IEEE Int. Conf. Robotics Automation, 1:277282, 1993. [49] Wikipedia. http://www.wikipedia.org/. [50] X. Yang and S. Deb. Cuckoo search via l` evy ights. Proc. of World Congress on Nature & Biologically Inspired Computing (NaBIC 2009), India, pages 210214, 2009. [51] X. Yang and S. Deb. Engineering optimisation by cuckoo search. Int. J. Mathematical Modelling and Numerical Optimisation, 1(4):330343, 2010. [52] Web en Espa nol de Zigbee Alliance. http://www.zigbee.es/. [53] Web Ocial de Zigbee Alliance. http://www.zigbee.org/.
106
BIBLIOGRAF IA
Cap tulo 12 Ap endices

Zigbee
ZigBee dene una especicaci on de un conjunto de protocolos de alto nivel de comunicaci on inal ambrica para su utilizaci on con radio digital de bajo consumo, basada en el est andar IEEE 802.15.4 de WPAN (wireless personal area network). Su objetivo son las aplicaciones que requieren comunicaciones seguras con baja tasa de env o de datos y maximizaci on de la vida u til de sus bater as. Es una tecnolog a id onea para la conguraci on de redes de sensores inal ambricos debido a: Su bajo consumo Su topolog a de red en malla Su f acil integraci on (se pueden fabricar nodos con muy poca electr onica) La relaci on entre IEEE 802.15.4-2003 y ZigBee es parecida a la existente entre IEEE 802.11 y Wi-Fi Alliance. La especicaci on 1.0 de ZigBee se aprob o el 14 de diciembre de 2004 y est a disponible a miembros del grupo de desarrollo (ZigBee Alliance). Un primer nivel de suscripci on, denominado adopter, permite la creaci on de productos para su comercializaci on adoptando la especicaci on por 3500 d olares anuales. Esta especicaci on est a disponible al p ublico para nes no comerciales en la petici on de descarga. La revisi on actual de 2006 se aprob o en diciembre de dicho a no. ZigBee utiliza la banda ISM para usos industriales, cient cos y m edicos; en concreto, 868 MHz en Europa, 915 en Estados Unidos y 2,4 GHz en todo el mundo. Sin embargo, a la hora de dise nar dispositivos, las empresas optar an pr acticamente siempre por la banda de 2,4 GHz, por ser libre en todo el mundo. El desarrollo de la tecnolog a se centra en la sencillez y el bajo coste m as que otras redes inal ambricas semejantes de la familia WPAN, como por ejemplo Bluetooth. El nodo ZigBee m as completo requiere en teor a cerca del 10 % del hardware de un nodo Bluetooth o Wi-Fi t pico; esta cifra baja al 2 % para los nodos m as sencillos. No obstante, el tama no del c odigo en s es bastante mayor y se acerca al 50 % del tama no del de Bluetooth. Se anuncian dispositivos con hasta 128 kB de almacenamiento. En 2006 el precio de mercado de un transceptor compatible con ZigBee se acerca al d olar y el precio de un conjunto de radio, procesador y memoria ronda los tres d olares. En 107
108
CAP ITULO 12. APENDICES
comparaci on, Bluetooth ten a en sus inicios (en 1998, antes de su lanzamiento) un coste previsto de 4-6 d olares en grandes vol umenes; a principios de 2007, el precio de dispositivos de consumo comunes era de unos tres d olares. Los protocolos ZigBee est an denidos para su uso en aplicaciones embebidas con requerimientos muy bajos de transmisi on de datos y consumo energ etico. Se pretende su uso en aplicaciones de prop osito general con caracter sticas autoorganizativas y bajo coste (redes en malla, en concreto). Puede utilizarse para realizar control industrial, albergar sensores empotrados, recolectar datos m edicos, ejercer labores de detecci on de humo o intrusos o dom otica. La red en su conjunto utilizar a una cantidad muy peque na de energ a de forma que cada dispositivo individual pueda tener una autonom a de hasta 5 a nos antes de necesitar un recambio en su sistema de alimentaci on. ZigBee es muy similar al Bluetooth pero con algunas diferencias: Una red ZigBee puede constar de un m aximo de 65535 nodos distribuidos en subredes de 255 nodos, frente a los 8 m aximos de una subred (Piconet) Bluetooth. Menor consumo el ectrico que el de Bluetooth. En t erminos exactos, ZigBee tiene un consumo de 30mA transmitiendo y de 3uA en reposo, frente a los 40mA transmitiendo y 0.2mA en reposo que tiene el Bluetooth. Este menor consumo se debe a que el sistema ZigBee se queda la mayor parte del tiempo dormido, mientras que en una comunicaci on Bluetooth esto no se puede dar, y siempre se est a transmitiendo y/o recibiendo. Tiene un velocidad de hasta 250 kbps, mientras que en Bluetooth es de hasta 1 Mbps. Debido a las velocidades de cada uno, uno es m as apropiado que el otro para ciertas cosas. Por ejemplo, mientras que el Bluetooth se usa para aplicaciones como los tel efonos m oviles y la inform atica casera, la velocidad del ZigBee se hace insuciente para estas tareas, desvi andolo a usos tales como la Dom otica, los productos dependientes de la bater a, los sensores m edicos, y en art culos de jugueter a, en los cuales la transferencia de datos es menor. Existe una versi on que integra el sistema de radiofrecuencias caracter stico de Bluetooth junto a una interfaz de transmisi on de datos v a infrarrojos desarrollado por IBM mediante un protocolo ADSI y MDSI. Se denen tres tipos distintos de dispositivo ZigBee seg un su papel en la red: Coordinador ZigBee (ZigBee Coordinator, ZC). El tipo de dispositivo m as completo. Debe existir uno por red. Sus funciones son las de encargarse de controlar la red y los caminos que deben seguir los dispositivos para conectarse entre ellos. Router ZigBee (ZigBee Router, ZR). Interconecta dispositivos separados en la topolog a de la red, adem as de ofrecer un nivel de aplicaci on para la ejecuci on de c odigo de usuario. Dispositivo nal (ZigBee End Device, ZED). Posee la funcionalidad necesaria para comunicarse con su nodo padre (el coordinador o un router), pero no puede transmitir informaci on destinada a otros dispositivos. De esta forma, este tipo de nodo puede estar dormido la mayor parte del tiempo, aumentando la vida media de sus bater as. Un ZED tiene requerimientos m nimos de memoria y es por tanto signicativamente m as barato.
109 Bas andose en su funcionalidad, puede plantearse una segunda clasicaci on: Dispositivo de funcionalidad completa (FFD): Tambi en conocidos como nodo activo. Es capaz de recibir mensajes en formato 802.15.4. Gracias a la memoria adicional y a la capacidad de computar, puede funcionar como Coordinador o Router ZigBee, o puede ser usado en dispositivos de red que act uen de interface con los usuarios. Dispositivo de funcionalidad reducida (RFD): Tambi en conocido como nodo pasivo. Tiene capacidad y funcionalidad limitadas (especicada en el est andar) con el objetivo de conseguir un bajo coste y una gran simplicidad. B asicamente, son los sensores/actuadores de la red. Un nodo ZigBee (tanto activo como pasivo) reduce su consumo gracias a que puede permanecer dormido la mayor parte del tiempo (incluso muchos d as seguidos). Cuando se requiere su uso, el nodo ZigBee es capaz de despertar en un tiempo nmo, para volverse a dormir cuando deje de ser requerido. Un nodo cualquiera despierta en aproximadamente 15 ms. ZigBee permite tres topolog as de red: Topolog a en estrella: el coordinador se sit ua en el centro. Topolog a en a rbol: el coordinador ser a la ra z del arbol. Topolog a de malla: al menos uno de los nodos tendr a m as de dos conexiones. La topolog a m as interesante (y una de las causas por las que parece que puede triunfar ZigBee) es la topolog a de malla. Esta permite que si, en un momento dado, un nodo del camino falla y se cae, pueda seguir la comunicaci on entre todos los dem as nodos debido a que se rehacen todos los caminos. La gesti on de los caminos es tarea del coordinador. Estrategias de conexi on de los dispositivos en una red Zigbee. Las redes ZigBee han sido dise nadas para conservar la potencia en los nodos esclavos. De esta forma se consigue el bajo consumo de potencia. La estrategia consiste en que, durante mucho tiempo, un dispositivo esclavo est a en modo dormido, de tal forma que solo se despierta por una fracci on de segundo para conrmar que est a vivo en la red de dispositivos de la que forma parte. Esta transici on del modo dormido al modo despierto (modo en el que realmente transmite), dura unos 15ms, y la enumeraci on de esclavos dura alrededor de 30ms, como ya se ha comentado anteriormente. En las redes Zigbee, se pueden usar dos tipos de entornos o sistemas: Con balizas: Es un mecanismo de control del consumo de potencia en la red. Permite a todos los dispositivos saber cu ando pueden transmitir. En este modelo, los dos caminos de la red tienen un distribuidor que se encarga de controlar el canal y dirigir las transmisiones. Las balizas que dan nombre a este tipo de entorno, se usan para poder sincronizar todos los dispositivos que conforman la red, identicando la red dom otica, y describiendo la estructura de la supertrama. Los intervalos de las balizas son asignados por el coordinador de red y pueden variar desde los 15 ms hasta los 4 minutos.
110
Este modo es m as recomendable cuando el coordinador de red trabaja con una bater a. Los dispositivos que conforman la red, escuchan a dicho coordinador durante el balizamiento (env o de mensajes a todos los dispositivos -broadcast-, enre 0,015 y 252 segundos). Un dispositivo que quiera intervenir, lo primero que tendr a que hacer es registrarse para el coordinador, y es entonces cuando mira si hay mensajes para el. En el caso de que no haya mensajes, este dispositivo vuelve a dormir, y se despierta de acuerdo a un horario que ha establecido previamente el coordinador. En cuanto el coordinador termina el balizamiento, vuelve a dormirse.
Sin balizas: Se usa el acceso m ultiple al sistema Zigbee en una red punto a punto cercano. En este tipo, cada dispositivo es aut onomo, pudiendo iniciar una conversaci on, en la cual los otros pueden interferir. A veces, puede ocurrir que el dispositivo destino puede no o r la petici on, o que el canal est e ocupado. Este sistema se usa t picamente en los sistemas de seguridad, en los cuales sus dispositivos (sensores, detectores de movimiento o de rotura de cristales), duermen pr acticamente todo el tiempo (el 99,999 %). Para que se les tenga en cuenta, estos elementos se despiertan de forma regular para anunciar que siguen en la red. Cuando se produce un evento (en nuestro sistema ser a cuando se detecta algo), el sensor despierta instant aneamente y transmite la alarma correspondiente. Es en ese momento cuando el coordinador de red, recibe el mensaje enviado por el sensor, y activa la alarma correspondiente. En este caso, el coordinador de red se alimenta de la red principal durante todo el tiempo. Los dispositivos ZigBee deben respetar el est andar de WPAN de baja tasa de transmisi on IEEE 802.15.4-2003. Este dene los niveles m as bajos: el nivel f sico (PHY) y el control de acceso al medio (MAC, parte del nivel de enlace de datos, DLL). El est andar trabaja sobre las bandas ISM de uso no regulado detalladas m as arriba. Se denen hasta 16 canales en el rango de 2,4 GHz, cada uno de ellos con un ancho de banda de 5 MHz. La frecuencia central de cada canal puede calcularse como: F C = (2405 + 5 (k 11)) MHz, con k = 11, 12, ..., 26. Las radios utilizan un espectro de dispersi on de secuencia directa. Se utiliza BPSK en los dos rangos menores de frecuencia, as como un QPSK ortogonal que transmite dos bits por s mbolo en la banda de 2,4 GHz. Esta permite tasas de transmisi on en el aire de hasta 250 kbps, mientras que las bandas inferiores se han ampliado con la u ltima revisi on a esta tasa desde los 40 kbps de la primera versi on. Los rangos de transmisi on oscilan entre los 10 y 75 metros, aunque depende bastante del entorno. La potencia de salida de las radios suele ser de 0 dBm (1 mW). Si bien en general se utiliza CSMA/CA para evitar colisiones en la transmisi on, hay algunas excepciones a su uso: por una parte, las tramas siguen una temporizaci on ja que debe ser respetada; por otra, las conrmaciones de env os tampoco siguen esta disciplina; por u ltimo, si se asignan slots de tiempo garantizados para una transmisi on tampoco es posible que exista contenci on.
Bus I2C
I 2 C es el nombre de un bus de comunicaciones serie dise nado por Phillips. Cuenta con una velocidad de 100kbps en su modelo est andar, aunque puede alcanzar los 3.4 Mbps. Es un bus muy utilizado en la industria, principalmente para comunicar microcontroladores y
111 sus perif ericos en sistemas integrados. y generalizados para comunicar circuitos integrados que residen en el mismo circuito impreso entre si. La principal caracter stica de I 2 C es que utiliza dos l neas para transmitir la informaci on: una para los datos y por otra la se nal de reloj. Tambi en es necesaria una tercera l nea, pero esta s olo es la referencia (masa). Como suelen comunicarse circuitos en una misma placa que comparten una misma masa esta tercera l nea no suele ser necesaria. Las l neas se llaman: SDA: datos SCL: reloj GND: tierra Las dos primeras l neas son drenador abierto, por lo que necesitan resistencias de pull-up. Los dispositivos conectados al bus I 2 C tienen una direcci on u nica para cada uno de 7 bits. Tambi en pueden ser maestros o esclavos. El dispositivo maestro inicia la transferencia de datos y adem as genera la se nal de reloj, pero no es necesario que el maestro sea siempre el mismo dispositivo, esta caracter stica se la pueden ir pasando los dispositivos que tengan esa capacidad. Esta caracter stica hace que al bus I 2 C se le denomine bus multimaestro. Las transacciones en el bus I 2 C tienen este formato: | start | A7 A6 A5 A4 A3 A2 A1 | R/W | ACK | ... DATA ... | ACK | stop | idle | 1. El bus esta libre cuando SDA y SCL est an en estado l ogico alto. 2. En estado bus libre, cualquier dispositivo puede ocupar el bus I 2 C como maestro. 3. El maestro comienza la comunicaci on enviando un patr on llamado start condition. Esto alerta a los dispositivos esclavos, poni endolos a la espera de una transacci on. 4. El maestro se dirige al dispositivo con el que quiere hablar, enviando un byte que contiene los siete bits (A7-A1) que componen la direcci on del dispositivo esclavo con el que se quiere comunicar, y el octavo bit (A0) de menor peso se corresponde con la operaci on deseada (L/E), lectura=1 (recibir del esclavo) y escritura=0 (enviar al esclavo). 5. La direcci on enviada es comparada por cada esclavo del bus con su propia direcci on, si ambas coinciden, el esclavo se considera direccionado como esclavo-transmisor o esclavo-receptor dependiendo del bit R/W. 6. El esclavo responde enviando un bit de ACK que le indica al dispositivo maestro que el esclavo reconoce la solicitud y est a en condiciones de comunicarse. 7. Seguidamente comienza el intercambio de informaci on entre los dispositivos. 8. El maestro env a la direcci on del registro interno del dispositivo que se desea leer o escribir. 9. El esclavo responde con otro bit de ACK
112
10. Ahora el maestro puede empezar a leer o escribir bytes de datos. Todos los bytes de datos deben constar de 8 bits, el n umero m aximo de bytes que pueden ser enviados en una transmisi on no est a restringido, siendo el esclavo quien ja esta cantidad de acuerdo a sus caracter sticas. 11. Cada byte leido/escrito por el maestro debe ser obligatoriamente reconocido por un bit de ACK por el dispositivo maestro/esclavo. 12. Se repiten los 2 pasos anteriores hasta nalizar la comunicaci on entre maestro y esclavo. 13. Aun cuando el maestro siempre controla el estado de la l nea del reloj, un esclavo de baja velocidad o que deba detener la transferencia de datos mientras efect ua otra funci on, puede forzar la l nea SCL a nivel bajo. Esto hace que el maestro entre en un estado de espera, durante el cual, no transmite informaci on esperando a que el esclavo est e listo para continuar la transferencia en el punto donde hab a sido detenida. 14. Cuando la comunicaci on naliza, el maestro transmite una stop condition para dejar libre el bus. 15. Despu es de la stop condition, es obligatorio para el bus estar idle durante unos microsegundos. La especicaci on I 2 C se puede consultar en [25], tambi en se puede consultar una gu a de uso con Arduino en [26].
Propulsi on
El conjunto propulsor basado en motor el ectrico sin escobillas (brushless) est a formado por tres componentes, por un lado el controlador electr onico de velocidad ESC (Electronic Speed Controller), por otro el motor el ectrico y por u ltimo la h elice.
ESC
El controlador de velocidad es el encargado de alimentar al motor con la energ a adecuada. Los motores el ectricos sin escobillas funcionan con corriente alterna en tres fases (trif asicos), esto quiere decir que cuentan con tres entradas de potencia. La funci on principal del ESC es actuar de inversor (DC - AC trif asico) controlando la intensidad de corriente a suministrar al motor seg un le comanden a trav es de las l neas de control. Los ESCs que se han utilizado en el proyecto son ESCs comunmente utilizados en radio control. Estos ESCs cuentan con tres lineas de control, de las cuales una de ellas es utilizada para alimentar un receptor de radio control, en este caso, al no ser necesario est a l nea no se utiliz o (l nea roja). Las otras dos l neas son tierra (l nea negra) y la l nea de control (l nea blanca). Para controlar la potencia a suministrar se utiliza modulaci on por ancho de pulso PWM (Pulse Width Modulation). La modulaci on por ancho de pulsos es una t ecnica utilizada para regular la velocidad de giro de los motores el ectricos de inducci on o as ncronos. Mantiene el
113 par motor constante y no supone un desaprovechamiento de la energ a el ectrica. Se utiliza tanto en corriente continua como en alterna, como su nombre lo indica, al controlar: un momento alto (encendido o alimentado) y un momento bajo (apagado o desconectado), controlado normalmente por relevadores (baja frecuencia) o MOSFET o tiristores (alta frecuencia). Esta t ecnica se basa en recortar la alimentaci on en forma de una onda cuadrada, la energ a que recibe el motor disminuir a de manera proporcional a la relaci on entre la parte alta (habilita corriente) y baja (cero corriente) del ciclo de la onda cuadrada. Controlando esta relaci on se logra variar la velocidad del motor de una manera bastante aceptable. Cuanto mayor sea el tiempo que pasa entre la fase alta y la baja, menor ser a la potencia suministrada al motor, por lo que, de manera proporcional, al ir disminuyendo el ancho del pulso la potencia media aumenta y la velocidad del motor hace lo propio.
Motores
Un motor el ectrico sin escobillas o motor brushless es un motor el ectrico que no emplea escobillas para realizar el cambio de polaridad en el rotor. Los motores el ectricos sol an tener un colector de delgas o un par de anillos rozantes. Estos sistemas, que producen rozamiento, disminuyen el rendimiento, desprenden calor y ruido, requieren mucho mantenimiento y pueden producir part culas de carb on que manchan el motor de un polvo que, adem as, puede ser conductor. Los primeros motores sin escobillas fueron los motores de corriente alterna as ncronos. Hoy en d a, gracias a la electr onica, se muestran muy ventajosos, ya que son m as baratos de fabricar, pesan menos y requieren menos mantenimiento, pero su control era mucho m as complejo. Esta complejidad pr acticamente se ha eliminado con los controles electr onicos. Los motores utilizados en el proyecto son comunmente utilizados en radio control, en concreto en aviones radiocontrolados de vuelo interior (indoor). Existen multitud de variantes de estos motores que se diferencian en el voltaje de entrada, la corriente m axima utilizada y el tama no de los mismos. Aunque para este proyecto las tres caracter sticas fundamentales a tener en cuenta ser an las revoluciones por minuto, el par motor y el peso. Como la fuente de alimentaci on de entrada a los motores ser a, paroximadamente, de 12 V, las opciones se reducen a motores de este voltaje, adem as el consumo hay que mantenerlo controlado, por lo que reduciremos la corriente m axima a utilizar a 18-20 Amperios. Dentro de este rango a un existen multitud de modelos diferentes de motores que se diferencian en las revoluciones por minuto, peso y consumo. En el estudio de componentes se podr a encontrar una lista completa de los diferentes motores analizados y los seleccionados.
H elices
Las h elices son los instrumentos a trav es de los cuales se transforma la energ a angular de los motores en empuje. En el cap tulo de an alisis ya se ha estudiado el funcionamiento de la h elice y los componentes de empuje que se desarrollan al girar la misma.
114 Motor Dualsky Dualsky Dualsky Dualsky Turnigy Plush 30A Turnigy Plush 30A Turnigy Plush 30A Turnigy Plush 30A TowerPro 2410 TowerPro 2410 TowerPro 2410 TowerPro 2410 H elice 11x4.7 10x4.7 9x4.7 8x6 11x4.7 10x4.7 9x4.7 8x6 11x4.7 10x4.7 9x4.7 8x6
CAP ITULO 12. APENDICES Empuje 540g 500g 455g 372g 860g 832g 630g 502g 452g 430g 372g 298g Consumo 10.27 A 9.6 A 7.6 A 6.4 A 16 A 15.3 A 12.5 A 11 A 8A 7.25 A 5.93 A 555 A
Cuadro 12.1: Relaci on motores/empuje/consumo La elecci on del tama no de la h elice es importante ya que inuye directamente en el empuje, consumo y velocidad de reacci on. Cuanto m as corta sea la h elice mayor velocidad de reacci on, pero tambi en menor consumo y menor empuje. Cuanto m as ancha sea la h elice mayor empuje genera, pero tambi en mayor consumo. Lo ideal es elegir una h elice sucientemente larga y ancha para generar el empuje necesario para elevar el veh culo, pero que tenga un consumo moderado y un tiempo de reacci on adecuado. Para este tipo de helic opteros lo recomendable es utilizar motores de aproximadamente 1000 revoluciones por minuto y voltio, por lo que jando ese par ametro la h elice con mejor relaci on de consumo/empuje es una h elice 10x4.7 pl astica de dos aspas (tambi en las hay de cuatro aspas). La relaci on de empuje y consumo en diferentes motores se puede ver en la tabla 12.1.
LiPos
Las bater as basadas en Litio Pol mero han supuesto un gran avance en cuanto a gran capacidad de carga, peso reducido y posibilidad de suministrar altos amperajes. Las bater as LiPos est an formadas por celdas (unidades elementales) con una tensi on de 3.7V por celda. Normalmente estas celdas se unen en serie permitiendo tensiones m ultiplo de 3.7, seg un el n umero de celdas en serie se denominan 1S(una u nica celda, 3.7V), 2S (dos celdas, 7.4V), 3S (11.1V), etc. Tambi en se pueden unir celdas en paralelo, con lo que se logra duplicar su capacidad y duplicar el amperaje que se puede obtener del conjunto. La capacidad de una bater a LiPo viene dada en miliamperios-hora (mAh) y corresponde al producto de la intensidad capaz de soportar por el tiempo durante el cual pueden funcionar. El u ltimo par ametro que caracteriza a una bater a LiPo es el valor C (C Rating) que indica la intensidad m axima que es capaz de soportar la bater a de manera segura.
115 Para cargar una bater a LiPo es necesario contar con un cargador especial debido a los dos ciclos de carga necesarios. Durante la primera parte de la carga se efectua una carga a corriente constante hasta alcanzar 4.2V por celda, a partir de ese momento se mantiene la tensi on de carga y va disminuyendo paulativamente la intensidad hasta que la intensidad llega a un 10 % de la inicial, momento en que se corta autom aticamente. La intensidad de carga normalmente es igual o inferior a 1C, es decir, la carga de una LiPo se realiza aproximadamente en una hora. Cuanto menor sea la intensidad de carga menos probabilidad de fallo y m axima carga tendr a la bater a. En la descarga la tensi on de cada celda nunca debe ser inferior a 3 V ya que la celda se deteriora irreversiblemente. Para evitar este problema los ESCs cuentan con circuitos de corte autom atico o reducci on de la corriente de entrada antes de que se alcance dicho umbral. Las bater as LiPo no cuentan con efecto memoria y pueden cargarse y descargarse parcialmente. Sin embargo, si deben tener equilibrado la tensi on de cada una de las celdas que forman la bater a, de modo que no ocurra que alguna de las celdas quede por debajo de la tensi on m nima. La mayor a de los cargadores modernos cuentan con conectores de equilibrado, que se conectan a los conectores de equilibrado de las bater as y permiten controlar la tensi on individual de cada celda de modo que se puedan igualar. Por u ltimo es muy importante el considerar el peso de las bater as, cuanto m as capacidad mayor ser a el peso, por lo que habr a que estudiar las relaciones de peso y capacidad para obtener el equilibrio necesario. En la secci on de An alisis de Componentes 12 se detallan las bater as analizadas junto con sus caracter sticas.
Especicaciones de los sensores utilizados
Figura 12.1: Datasheet de la placa del ADXL34555
116
Figura 12.2: Datasheet de la placa del LPY530AL
Figura 12.3: Datasheet de la placa del HMC6352
Figura 12.4: Datasheet de la placa del SCP1000
117
Figura 12.5: Datasheet de la placa del IMU 6DoF de Razor
Componentes analizados para el proyecto XPider

Sensores
Para el control de estabilidad es necesario mediciones de velocidad angular en los tres ejes, para ello se usan giroscopios de 3 ejes o combinaciones de giroscopios, con estos sensores podremos tener medida de velocidad angular para controlar la variaci on de pitch, roll y yaw. Dual Axis Gyro Breakout - IXZ500: http://www.sparkfun.com/commerce/product_ info.php?products_id=9410 Gyro Breakout Board - ADXRS610 - 300 /s: http://www.sparkfun.com/commerce/ product_info.php?products_id=9058 Gyro Breakout Board - LISY300AL 300 /s: http://www.sparkfun.com/commerce/ product_info.php?products_id=8955 Gyro Breakout Board - LPR503AL Dual 30 /s: http://www.sparkfun.com/commerce/ product_info.php?products_id=9422 Con los giros podemos controlar c omo de r apido el veh culo gira en los diferentes ejes, pero no controlamos si el veh culo est a sometido a aceleraciones en alguno de los tres ejes, para ello es necesario contar con un aceler ometro de tres ejes o combinaci on de aceler ometros, estos miden la aceleraci on lineal en los tres ejes, por lo que con estas medidas sabremos si el veh culo se est a moviendo y en qu e sentido, adem as con los aceler ometros podemos
118
medir la cantidad de aceleraci on debida a la gravedad en cada uno de los ejes y, por tanto, establecer la posici on del veh culo respecto al suelo, esto nos puede servir para ajustar los motores y parar el movimiento del veh culo permitiendo que el veh culo permanezca en vuelo estacionario. En [4] encontramos una gu a de c omo usar el ADXL3xx con Arduino Dual Axis Accelerometer Breakout Board - ADXL321 +/-18g: http://www.sparkfun. com/commerce/product_info.php?products_id=848 Evaluation Board - ADXL345: http://www.sparkfun.com/commerce/product_info. php?products_id=9364 Triple Axis Accelerometer Breakout - ADXL335: http://www.sparkfun.com/commerce/ product_info.php?products_id=9269 Triple Axis Accelerometer Breakout - MMA7260Q: http://www.sparkfun.com/commerce/ product_info.php?products_id=252 Existen soluciones que brindan 4, 5, 6 y hasta 9 grados de libertad o DoF, en el caso de 9 grados los tres grados extra se deben a magnet ometros que miden fuerzas magn eticas en los tres ejes. ArduIMU Sensor Board - Six Degrees of Freedom (Daughter): http://www.sparkfun. com/commerce/product_info.php?products_id=9373 Ardupilot: http://diydrones.com/profiles/blogs/ardupilot-main-page Comparativa de opciones de integrados IMUs de diferentes DoF Atomic IMU 6 Degrees of Freedom - XBee Ready Atmel ATMega168 UART interface (0-3.3V,115200bps) LISY300AL Gyros: 88Hz, 0.977 /tick (ADC count) MMA7260Q Accelerometer: 350Hz, X and Y axes 150Hz, Z axis 0.00403g/tick @ 1.5g 0.00537g/tick @ 2g 0.0107g/tick @ 4g 0.0161g/tick @ 6g Ventajas: 6 grados de libertad, micro Atmega propio, interfaz serie, facilidad de uso, regulador de voltaje incorporado
119 Inconvenientes: interfaz serie, quiz as demasiado lento al leer por serie. Es caro. D onde comprarlo: http://www.sparkfun.com/commerce/product_info.php?products_ id=9184 Precio: 125$ 9 Degrees of Freedom - Razor IMU - AHRS compatible 9 Degrees of Freedom on a single, at board: LY530ALH - 300 /s single-axis gyro LPR530ALH - 300 /s dual-axis gyro ADXL345 - 13-bit resolution, 16g , triple-axis accelerometer HMC5843 - triple-axis, digital magnetometer Outputs of all sensors processed by on-board ATmega168 and sent out via a serial stream Ventajas: interfaz serie, micro Atmega propio, facilidad de uso, magnet ometros. Inconvenientes: interfaz serie, lecturas lentas para luego tener que procesar en otro Atmega, es voluminoso y caro. D onde comprarlo: http://www.sparkfun.com/commerce/product_info.php?products_ id=9623 Precio: 125$ ArduIMU Sensor Board - Six Degrees of Freedom Main board (4 degrees of freedom): ADXL335 - three axes of acceleration, 3g range LISY300AL - one axis of angular velocity, 300 /s range Compatible with ArduIMU 6DOF daughter boards to get up to 6 degrees of freedom Analog output of all 6 axes is sent to ArduIMU analog pins 0.1pitch headers to connect to daughter boards and ArduIMU D onde comprarlo: http://www.sparkfun.com/commerce/product_info.php?products_ id=9372 Precio: 45$ Daughter Board (2 modules): LISY300AL - single-axis gryo, 300 /s range
120 All ltering components included
When paired with a ArduIMU 6DOF main board up to 6 degrees of freedom can be attained Analog output of all 6 axes is sent to ArduIMU analog pins Access to power-down and self-test pins 0.1pitch headers to connect to ArduIMU 6DOF main board D onde comprarlo: http://www.sparkfun.com/commerce/product_info.php?products_ id=9373 Precio: 50$los dos m odulos Ventajas: Los sensores son precisos, para integrar con arduimu, buen precio Inconvenientes: muy voluminoso, viene en componentes diferentes, necesita regulador de voltaje Precio del conjunto: 95$
IMU 5 Degrees of Freedom IDG500/ADXL335 IDG500 dual-axis gyroscope and Analog Devices triple axis ADXL335 accelerometer. Ventajas: Solucion muy compacta, precio muy ajustado, gran popularidad, se integra muy bien con Arduino, sensores muy probados y precisos. Inconvenientes: Falta un girosc opio que habr a que acoplar, necesario un regulador de voltaje. D onde comprarlo: http://www.sparkfun.com/commerce/product_info.php?products_ id=9268 Precio: 75$en Sparkfun, 55 en Bricogeek IMU 6DOF Razor - Ultra-Thin IMU There is no on-board regulation, so youll need to provide a clean 3.3VDC power source 2.7-3.6VDC power supply. Low power consumption Pitch, yaw, and roll gyro outputs 1x and 4x amplied (0.83 and 3.33 mV/ /s sensitivity, respectively) 300 /s range 3g range 300mV/g sensitivity All necessary ltering components
121 Ventajas: La soluci on m as compacta, solo 2g de peso, 6 DoF en un solo plano, se puede acoplar muy bien en una placa de prototipado, ultra-low consumption. Inconvenientes: Falta regulador de tensi on para darle 3.3VDC, todas las salidas son anal ogicas (uso intensivo de los convertidores A/D de Arduino), el fallo de uno de los sensores precisa sustituir toda la placa. D onde comprarlo: http://www.sparkfun.com/commerce/product_info.php?products_ id=9431 Precio: 90$ Sensor de Presi on Adicionalmente se puede incorporar un sensor de presi on para poder tener feedback de la altura, el sensor de presi on mide la presi on barom etrica, esta var a con la altura, de modo que es capaz de medir la altura, este sensor posiblemente hay que calibrarlo de modo que termine midiendo la altura relativa. Este sensor es conveniente que sea protegido con alg un recubrimiento para evitar que se vea afectado por el viento y por el propio ujo de aire producido por las h elices del veh culo. Barometric Pressure Sensor MEMs - SCP1000-D01 http://www.sparkfun.com/commerce/ product_info.php?products_id=8128 MEMs Barometric Pressure Sensor - SCP1000 Breakout:http://www.sparkfun.com/ commerce/product_info.php?products_id=8161 Se opt o por adquirir el MEMs Barometric Pressure Sensor - SCP1000 Breakout Comp as Digital Es neesario contar con un comp as digital para que el modelo sepa orientarse. Aunque por software se puede sustituir haciendo que el veh culo se mueva primero y de las medidas de trayectoria del GPS abstraer la orientaci on del veh culo y hacer luego que se dirija al waypoint deseado. Compass Module - HMC6352 Simple I2C interface 2.7 to 5.2V supply range 1 to 20Hz selectable update rate True drop-in solution 0.5 degree heading resolution Ventajas: Comp as digital muy barato y con interfaz I 2 C . Inconvenientes: Al ser un comp as de muy bajo coste la precisi on que tiene y la tasa de fallos, as como la tasa de ruido, es muy alta, por lo que necesita ltrado software.
122
D onde comprar: http://www.sparkfun.com/commerce/product_info.php?products_ id=7915 Precio: 35$
Propulsi on
Para propulsar el veh culo y mover las h elices se usan cuatro motores brushless (sin escobillas), estos motores son m as peque nos, ligeros y ecientes que los motores tradicionales con escobillas, pero tambi en necesitan un controlador electr onico de velocidad (ESC) especial ya que son alimentados con precisos pulsos de corriente alterna (AC). Hay diferentes combinaciones de ESCs y motores, var an en potencia, consumo, peso, precio, etc, habr a que estudiar qu e opciones usar al principio.
Motores Turnigy 2209 28turn Caracter sticas: 1050rpm 4-12amp(15max) 46gr 12$ D onde comprarlo: http://www.hobbycity.com/hobbycity/store/uh_viewItem.asp? idProduct=5687 Turnigy 2209 26turn Caracter sticas: 1130rpm 4-13amp (15max) 46gr 13$ Hacker Style Brushless Outrunner 20-22L Caracter sticas: 924rpm 6-14amp (17max) 56gr 17$ D onde comprarlo: http://www.hobbycity.com/hobbycity/store/uh_viewItem.asp? idProduct=4700 Hacker Style Brushless Outrunner 20-20L Caracter sticas: 1053rpm 6-15amp (19max) 56gr 20$ D onde comprarlo: http://www.hobbycity.com/hobbycity/store/uh_viewItem.asp? idProduct=2048&Product_Name=hacker_Style_Brushless_Outrunner_20-20L Bell Motor - 2410-09 Caracter sticas: 1100rpm 0.5-12amp 55gr 8$ D onde comprarlo: http://robotbirds.com/catalog/product_info.php?products_id= 714 Turnigy 2213 22turn Caracter sticas: 924rpm 6-14amp (17max) 59gr 14$ D onde comprarlo: http://www.hobbycity.com/hobbycity/store/uh_viewItem.asp? idProduct=5689
123 Turnigy 2213 20turn Caracter sticas: 1050rpm 6-15amp (19max) 59gr 13$ D onde comprarlo: http://www.hobbyking.com/hobbyking/store/uh_viewItem.asp? idProduct=5688 ESCs (Electronic Speed Controller) Turnigy Plush 12amp Caracter sticas: 12amp (15max) 13gr 10$ D onde comprarlo: http://www.hobbycity.com/hobbycity/store/uh_viewItem.asp? idProduct=2161 Turnigy Plush 30amp Caracter sticas: 30amp (40max) 25gr 15$ D onde comprarlo: http://www.hobbyking.com/hobbyking/store/uh_viewItem.asp? idProduct=2164&Product_Name=TURNIGY_Plush_30amp_Speed_Controller Existen modicaciones que se pueden realizar sobre estos ESCs (Turnigy Plush) para mejorar sus tiempos de respuesta, se trata de modicaciones sobre el rmware y peque nas modicaciones sobre el hardware para cambiar la interfaz PWM por I 2 C . El motor es m as complicado de elegir, hay que tener en cuenta pesos, rendimientos, revoluciones por minuto, etc, me decido por el Hacker Style Brushless Outrunner 2020L por stock y porque las opiniones son bastante buenas. Tras analizar los resultados de consumos y duraci on de bater a, se llegaron a las siguientes conclusiones: El modelo es demasiado pesado, los motores seleccionados (Hacker Style 20-20) son muy pesados (60 gramos cada uno) y de bajas revoluciones (apenas 1000 rpm), hubiese sido mejor haber optado por motores m as ligeros de 20-25 gramos y de m as revoluciones (3000 a 3500 rpms), esto hubiese supuesto menor consumo y mejor reacci on del modelo en vuelo, adem as de ESCs menos potentes y menos pesados (de 35 gramos a 17 gramos). Se barajaron dos opciones para mejorar el sistema, acoplar h elices de mayor carga y, por tanto, mayor empuje, con el aumento de consumo asociado, y sustituci on de las bater as de 1800 mA/h por otras de mayor capacidad (5000 mA/h), o probar motores m as livianos y m as rapidos con el mismo tama no de h elice. Finalmente se decidi o usar las bater as de mayor capacidad y peso ya que la sustituci on del conjunto propulsor no era factible, tambi en se intent o reducir el peso del modelo cambiando los motores por otros m as ligeros, aunque no se lleg o a ninguna mejora perceptible. Tras realizar diferentes pruebas se decidi o seleccionar con los Hacker Style 20-20, por otro lado uno de los ESCs se rompi o y al no existir stock para poder sustituirlo se opt o por adquirir un set de cuatro HobbyKings HK-20A m as baratos y ligeros pero con menor carga m axima soportada (de 18 a 20 Amperios).
124
La modicaci on de los Turnigy Plush result o m as complicada de lo habitual y result o en varias ocasiones en el deterioro de los mismos, por lo que se decidi o seguir adelante con los HobbyKing con interfaz PWM, aunque la tasa de refresco sea de tan solo 50 Hz.
H elices (Propellers) Las elegidas son de 4.7 x 10, se puede probar diferentes medidas, seg un las medidas var an los empujes, a mayor empuje mayor peso se es capaz de elevar pero mayor potencia se necesita, h elices mayores necesitan motores de menos revoluciones por minuto pero mayor potencia a baja revoluci on, normalmente consumen m as y pueden necesitar un mayor voltaje. H elices m as peque nas tienen menor empuje y menor consumo (mucho menor, no es proporcional) tambi en pueden montarse en motores con mayor rpms y tienen una mejor respuesta, por lo que son m as manejables.
Radio
Se decidi o usar un enlace Zigbee para que el modelo mande telemetr a y el puesto de mando y control en tierra pueda mandar ordenes como el cambio del vector de movimiento o el ajuste del plan de vuelo en el futuro. En concreto se seleccion o un un chip Xbee de Maxstream comunic andose con el protocolo Zigbee a trav es de un Shield para Arduino [5]. La comunicaci on a trav es de xbee es f acilmente congurable y el enlace alcanza los 100 metros en su version A y hasta el kil ometro en su versi on B. En [6] se encuentra un tutorial de conguraci on de los par ametros de las radios. La posibilidad de a nadir una video c amara en el futuro hace plantearse la posibilidad de usar WiFi para el enlace de radio, el consumo es mayor y el alcance puede ser una limitaci on. Existen shields de WiFi para Arduino y no es descabellado usar ambos, zigbee para telemetr a y control b asico y WiFi para datos pesados como el video. Un completo mote basado en Arduino: http://www.libelium.com/products/ waspmote Wi Shield para Arduino: http://www.bricogeek.com/shop/238-arduino-wifly-shield. html Otro Shield Wi: http://www.asynclabs.com/store?page=shop.product_details&flypage= flypage.tpl&product_id=17&category_id=6&vmcchk=1 Otro shield muy recomendable: http://www.sparkfun.com/commerce/product_ info.php?products_id=9367
Alimentaci on
Para alimentar los motores y los micros es necesario una bater a, esta es de tipo LiPo, es decir, de litio pol mero, ya que estas bater as son m as ligeras y duran m as. Lo normal es que sea de 3 celdas 11 V y m nimo de 1500mAh.
125 Tambi en ser a necesario un cargador de bater as LiPo con balanceador. Recomendable el avisador de bater a que hace sonar una alarma ac ustica cuando la tensi on de la bater a alcanza un determinado umbral. El tema de la capacidad de las bater as es delicado puesto que a m as capacidad se supone mayor duraci on del vuelo, sin embargo no siempre es as ya que a mayor capacidad m as peso tiene la misma, y el peso hay que cuidarlo puesto que a mayor peso mayor potencia en los motores ser a necesaria y mayor consumo, por lo que hay que encontrar el equilibrio. Adem as es posible que el modelo a partir de cierto peso no pueda ser estabilizado con facilidad.
LiPos ZIPPY Flightmax 1500mAh 3S1P 20C Caracter sticas: 15500mAh 140gr 10$ D onde Comprar: http://www.hobbycity.com/hobbycity/store/uh_viewItem.asp?idProduct= 6307 ZIPPY Flightmax 1800mAh 3S1P 20C Caracter sticas: 1800mAh 150gr 13$ D onde Comprar: http://www.hobbycity.com/hobbycity/store/uh_viewItem.asp?idProduct= 6293 Turnigy 1800mAh 3S 20C Lipo Pack Caracter sticas: 1800 mAh 150gr 9.5$ ZIPPY Flightmax 2200mAh 3S1P 20C Caracter sticas: 2200mAh 170g 11$ D onde Comprar: http://www.hobbycity.com/hobbycity/store/uh_viewItem.asp?idProduct= 6306 ZIPPY Flightmax 2650mAh 3S1P 20C Caracter sticas: 2650mAh 212gr 20$ D onde Comprar: http://www.hobbycity.com/hobbycity/store/uh_viewItem.asp?idProduct= 8912 ZIPPY Flightmax 3000mAh 3S1P 20C Caracter sticas: 3000mAh 240gr 18$ D onde Comprar: http://www.hobbycity.com/hobbycity/store/uh_viewItem.asp?idProduct= 8851 ZIPPY Flightmax 4000mAh 3S1P 20C Caracter sticas: 4000mAh 306gr 20$ D onde Comprar: http://www.hobbycity.com/hobbycity/store/uh_viewItem.asp?idProduct= 7634
126 ZIPPY Flightmax 5000mAh 3S1P 20C Caracter sticas: 5000mAh 360gr 27$
D onde Comprar: http://www.hobbycity.com/hobbycity/store/uh_viewItem.asp?idProduct= 8579 Despues de probar con las bater as LightMax de 1800 mA/h y 1500 mA/h se lleg o a dos conclusiones, la primera es que 1500 mA/h se quedan muy cortos, la segunda es que se debe evaluar el uso de las LightMax de 5000 mA/h, tienen un peso de 353 gramos, pero 5000 mA/h pueden compensar en duraci on de las mismas. Adem as el modelo esta pesando mucho m as de lo pretendido y suceden dos cosas, la primera que 352 gramos de bater a en comparacion con 150 gramos puede parecer mucho, y lo es si lo ponemos en perspectiva con un modelo que pesa 500 o 600 gramos, pero el XPider est a pesando cerca de 1300 gramos, por lo que 200 gramos m as comparado con 3500 mA/h m as no es tanto. Finalmente se utiliz o la LightMax 5000 mA/h: http://www.hobbycity.com/hobbycity/ store/uh_viewItem.asp?idProduct=8579 Cargador Turnigy Accucel-6 50W 5A Balancer/Charger D onde Comprar: http://www.hobbycity.com/hobbycity/store/uh_viewItem.asp?idProduct= 7028

Xpider PFC

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Xpider PFC

Încărcat de

Drepturi de autor:

Formate disponibile

ESCUELA TECNICA SUPERIOR DE INGENIER IA INFORMATICA INGENIER IA INFORMATICA Curso Acad emico 2010/2011 Proyecto Fin de Carrera

Xpider: Desarrollo de un Veh culo A ereo No Tripulado de Cuatro Motores

Autor: Oscar Higuera Rinc on Tutor: Carlos Ag uero Dur an

2.3. Metodolog a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Estudio de Alternativas 3.1. Mikrokopter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Aeroquad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

8.4. PrimaryDisplay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.1. GraphicMotor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.4.3. HeadingIndicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.4. GraphicModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.4.5. BatteryMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.6. ValueIndicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.2. Descripci on del algoritmo QSearch . . . . . . . . . . . . . . . . . . . . . . .

INDICE GENERAL 9.3. Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 91 93 96 97 97 97 98 99

CAP ITULO 0. RESUMEN

Cap tulo 1 Introducci on

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

1.4. CARGA DE PAGO

CAP ITULO 1. INTRODUCCION

Global Positioning System (http://en.wikipedia.org/wiki/Global_Positioning_System)

EN ESPANA 1.6. SITUACION

European Aeronautic Defence and Space Company http://www.eads.com/eads/int/en.html

CAP ITULO 1. INTRODUCCION

Cap tulo 2 Objetivos

CAP ITULO 2. OBJETIVOS

Software Requirements Document

2.2. REQUISITOS de tipo Close:

ESC: Electronic Speed Controller

CAP ITULO 2. OBJETIVOS

Requisitos Software Embarcado

Requisitos de Estaci on en Tierra

CAP ITULO 2. OBJETIVOS

Cap tulo 3 Estudio de Alternativas

CAP ITULO 3. ESTUDIO DE ALTERNATIVAS

Figura 3.1: Mikrokopter con una conguraci on de 8 motores.

Figura 3.2: M odulo central de Mikrokopter.

CAP ITULO 3. ESTUDIO DE ALTERNATIVAS

DCM: Direction Cosine Matrix

Figura 3.6: Ardupilot: unidad de navegaci on inercial.

CAP ITULO 3. ESTUDIO DE ALTERNATIVAS

Cap tulo 4 Entorno de Desarrollo

CAP ITULO 4. ENTORNO DE DESARROLLO

SPI: Serial Peripheral Interface http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_

Figura 4.3: Mini, el m as peque no de todos los Arduinos.

CAP ITULO 4. ENTORNO DE DESARROLLO

Application Programming Interface

CAP ITULO 4. ENTORNO DE DESARROLLO

Cap tulo 5 An alisis

Principios de Sustentaci on y Movimiento

CAP ITULO 5. ANALISIS

Y MOVIMIENTO 5.1. PRINCIPIOS DE SUSTENTACION

CAP ITULO 5. ANALISIS

Figura 5.4: Relaci on de a ngulos pitch, roll y yaw.

Y MOVIMIENTO 5.1. PRINCIPIOS DE SUSTENTACION

CAP ITULO 5. ANALISIS

Cap tulo 6 Plataforma Hardware

CAP ITULO 6. PLATAFORMA HARDWARE

Figura 6.1: Chasis b asico de Mikrokopter

6.1. ESTRUCTURA F ISICA

Figura 6.4: Primer banco de pruebas

CAP ITULO 6. PLATAFORMA HARDWARE

CAP ITULO 6. PLATAFORMA HARDWARE

CAP ITULO 6. PLATAFORMA HARDWARE

Figura 6.8: IMU 6DoF Razor.

Figura 6.9: ADXL345 con breakboard de Sparkfun.

CAP ITULO 6. PLATAFORMA HARDWARE