142
ESCUELA T ´ ECNICA SUPERIOR DE INGENIER ´ IA INFORM ´ ATICA INGENIER ´ IA INFORM ´ ATICA 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

Xpider Pfc

Embed Size (px)

Citation preview

  • ESCUELA TECNICA SUPERIOR DE INGENIERIAINFORMATICA

    INGENIERIA INFORMATICA

    Curso Academico 2010/2011

    Proyecto Fin de Carrera

    Xpider: Desarrollo de un Vehculo Aereo NoTripulado de Cuatro Motores

    Autor: Oscar Higuera Rincon

    Tutor: Carlos Aguero Duran

  • A Su.

  • Agradecimientos

    En primer lugar quiero dar las gracias a mi familia por su apoyo y comprension constante.

    Tambien a Ivan, Jacob, Antonio y el resto de mis eternos companeros, siempre fieles.

    Sin olvidarme de toda la buena gente que forma el Departamento de Robotica de laUniversidad Rey Juan Carlos, por su disposicion y ayuda, especialmente a Carlos Aguero.

    v

  • Indice general

    Indice general VII

    Indice de figuras XI

    Resumen XV

    1. Introduccion 1

    1.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

    1.2. Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

    1.2.1. Militares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

    1.2.2. Civiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

    1.3. Clasificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

    1.4. Carga de Pago . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

    1.5. Estacion de Tierra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

    1.6. Situacion en Espana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

    2. Objetivos 11

    2.1. Descripcion del Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

    2.2. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

    2.2.1. Requisitos Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

    2.2.2. Requisitos Software Embarcado . . . . . . . . . . . . . . . . . . . . . 14

    2.2.3. Requisitos de Estacion en Tierra . . . . . . . . . . . . . . . . . . . . 14

    2.3. Metodologa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

    3. Estudio de Alternativas 19

    3.1. Mikrokopter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

    3.2. Aeroquad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

    vii

  • viii INDICE GENERAL

    3.3. Ardupilot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

    4. Entorno de Desarrollo 25

    4.1. Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

    4.2. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

    5. Analisis 31

    5.1. Principios de Sustentacion y Movimiento . . . . . . . . . . . . . . . . . . . . 31

    5.1.1. Pitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

    5.1.2. Roll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

    5.1.3. Yaw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

    6. Plataforma Hardware 37

    6.1. Estructura Fsica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

    6.1.1. Incremento V1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

    6.1.2. Incremento V2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

    6.1.3. Incremento V3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

    6.2. Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

    6.2.1. Acelerometros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

    6.2.2. Giroscopos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

    6.2.3. Magnetometros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

    6.2.4. Sonar y Barometro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

    6.3. Unidad Central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

    6.3.1. Incremento V1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

    6.3.2. Incremento V2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

    6.3.3. Incremento V3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

    7. Software Embarcado 55

    7.1. Arquitectura Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

    7.2. Drivers de EntradaSalida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

    7.2.1. Interfaz I2C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

    7.2.2. Modulo ADXL345Driver . . . . . . . . . . . . . . . . . . . . . . . . . 58

    7.2.3. Modulo ImuAdc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

    7.2.4. Modulo DigitalCompass . . . . . . . . . . . . . . . . . . . . . . . . . 58

  • INDICE GENERAL ix

    7.2.5. Modulo AltimeterDriver . . . . . . . . . . . . . . . . . . . . . . . . . 59

    7.3. Comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

    7.4. Modulo IMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

    7.4.1. Algoritmo DCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

    7.5. Modulo de Estabilizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

    7.5.1. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

    7.5.2. Parametrizacion PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

    7.5.3. Aplicacion de PID a la estabilizacion . . . . . . . . . . . . . . . . . . 68

    7.6. Evolucion de los Incrementos . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

    8. Estacion de Tierra (GCS) 71

    8.1. Arquitectura Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

    8.2. SerialComms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

    8.3. MainMenuDisplay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

    8.4. PrimaryDisplay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

    8.4.1. GraphicMotor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

    8.4.2. GraphicAHorizon . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

    8.4.3. HeadingIndicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

    8.4.4. GraphicModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

    8.4.5. BatteryMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

    8.4.6. ValueIndicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

    8.4.7. GraphicPID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

    8.4.8. JoystickControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

    8.5. CalibrationDisplay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

    8.6. Grabador Reproductor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

    8.7. Evolucion de los Incrementos . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

    9. QSearch 83

    9.1. Antecedentes en busqueda optimizada . . . . . . . . . . . . . . . . . . . . . . 84

    9.1.1. Metodos numericos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

    9.1.2. Algoritmos basados en muestras . . . . . . . . . . . . . . . . . . . . . 84

    9.1.3. Cuckoo Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

    9.2. Descripcion del algoritmo QSearch . . . . . . . . . . . . . . . . . . . . . . . 85

  • x INDICE GENERAL

    9.3. Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

    10.Pruebas 91

    10.1. Pruebas en banco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

    10.2. Pruebas en vuelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

    11.Conclusiones y Trabajos Futuros 97

    11.1. Conclusiones y Objetivos Alcanzados . . . . . . . . . . . . . . . . . . . . . . 97

    11.1.1. Plataforma Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

    11.1.2. Software Embarcado . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

    11.1.3. Estacion de Tierra (GCS) . . . . . . . . . . . . . . . . . . . . . . . . 99

    11.1.4. QSearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

    11.2. Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

    Bibliografa 103

    12.Apendices 107

  • Indice de figuras

    1.1. Raven RQ-11B de AeroVironment . . . . . . . . . . . . . . . . . . . . . . . . 4

    1.2. Scan Eagle UAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

    1.3. IAI Eitan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

    1.4. Nothrop Grumman Fire Scout . . . . . . . . . . . . . . . . . . . . . . . . . . 6

    1.5. Aeryon Scout de Aeryon Labs . . . . . . . . . . . . . . . . . . . . . . . . . . 7

    1.6. RQ-4 Global Hawk UAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

    1.7. Sensor electro-optico termico . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

    1.8. GSC del Predator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

    1.9. nEUROn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

    1.10. ATLANTE UAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

    2.1. Diagrama de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

    2.2. Diagrama iterativo-incremental . . . . . . . . . . . . . . . . . . . . . . . . . 16

    2.3. Diagrama de Incrementos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

    3.1. Mikrokopter de 8 motores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

    3.2. Modulo central de Mikrokopter. . . . . . . . . . . . . . . . . . . . . . . . . . 20

    3.3. NAV Module de Mikrokopter . . . . . . . . . . . . . . . . . . . . . . . . . . 20

    3.4. NicoletoMK basado en Mikrokopter . . . . . . . . . . . . . . . . . . . . . . . 21

    3.5. Aeroquad radiocontrolado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

    3.6. Ardupilot IMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

    3.7. Ardupilot Easyglider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

    4.1. Plataforma hardware Arduino UNO. . . . . . . . . . . . . . . . . . . . . . . 26

    4.2. Arduino Nano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

    4.3. Arduino Mini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

    xi

  • xii INDICE DE FIGURAS

    4.4. Seeeduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

    4.5. Entorno de desarrollo Arduino. . . . . . . . . . . . . . . . . . . . . . . . . . 28

    4.6. Entorno de desarrollo Processing . . . . . . . . . . . . . . . . . . . . . . . . 30

    5.1. Analisis de fuerzas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

    5.2. Componentes inerciales resultantes . . . . . . . . . . . . . . . . . . . . . . . 32

    5.3. Inercial y momento angular total . . . . . . . . . . . . . . . . . . . . . . . . 33

    5.4. Relacion de angulos pitch, roll y yaw. . . . . . . . . . . . . . . . . . . . . . . 34

    5.5. Esquema Giro Pith . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

    5.6. Esquema de giro Roll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

    5.7. Esquema de giro Yaw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

    6.1. Chasis basico de Mikrokopter . . . . . . . . . . . . . . . . . . . . . . . . . . 38

    6.2. Conjunto motor/helice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

    6.3. Detalle ESC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

    6.4. Primer banco de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

    6.5. Detalle de plataforma aislante . . . . . . . . . . . . . . . . . . . . . . . . . . 40

    6.6. Protector de poliestireno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

    6.7. Relacion orientacion del acelerometro . . . . . . . . . . . . . . . . . . . . . . 43

    6.8. IMU 6DoF Razor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

    6.9. ADXL345 con breakboard de Sparkfun. . . . . . . . . . . . . . . . . . . . . . 44

    6.10. Esquema giroscopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

    6.11. IMU 6DoF sin filtros hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 47

    6.12. Placa breakboard con LPY530AL. . . . . . . . . . . . . . . . . . . . . . . . . 47

    6.13. Magnetometro HMC 6352 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

    6.14. Barometro SCP1000 de MBED. . . . . . . . . . . . . . . . . . . . . . . . . . 49

    6.15. Sonar LV MaxSonar EZ-1 de MaxBotics. . . . . . . . . . . . . . . . . . . . . 49

    6.16. UC V1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

    6.17. Modulo Xbee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

    6.18. Placa: conexiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

    6.19. Placa: cortes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

    6.20. Placa V2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

    6.21. Prototipo V2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

  • INDICE DE FIGURAS xiii

    6.22. Placa: pistas V3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

    6.23. UC V3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

    7.1. Arquitectura Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

    7.2. Proyecciones de una base sobre otra de referencia. . . . . . . . . . . . . . . . 64

    7.3. Diagrama del controlador PI DCM . . . . . . . . . . . . . . . . . . . . . . . 65

    7.4. Esquema de controlador PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

    7.5. Parametrizacion PID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

    8.1. Componente grafico Serial Comms. . . . . . . . . . . . . . . . . . . . . . . . 72

    8.2. Componente MainMenuDisplay. . . . . . . . . . . . . . . . . . . . . . . . . . 73

    8.3. Componente GraphicMotor. . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

    8.4. Componente GraphicHorizon. . . . . . . . . . . . . . . . . . . . . . . . . . . 74

    8.5. Componente HeadingIndicator. . . . . . . . . . . . . . . . . . . . . . . . . . 75

    8.6. Componente GraphicModel. . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

    8.7. Componente BatteryMonitor. . . . . . . . . . . . . . . . . . . . . . . . . . . 76

    8.8. ValueIndicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

    8.9. Componente GraphicPid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

    8.10. Componente JoystickControl. . . . . . . . . . . . . . . . . . . . . . . . . . . 77

    8.11. PrimaryDisplay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

    8.12. Espacio de Busqueda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

    8.13. Calibration Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

    8.14. Representacion visual de un Test . . . . . . . . . . . . . . . . . . . . . . . . 79

    8.15. CalibrationDisplay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

    8.16. Grabador/Reproductor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

    8.17. Diagrama de clases principal GCS. . . . . . . . . . . . . . . . . . . . . . . . 82

    9.1. Vuelo Levy convencional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

    9.2. Michaelwicz Landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

    9.3. Qsearch de Michaelwitz (3-6-3) y (2-7-3) . . . . . . . . . . . . . . . . . . . . 90

    9.4. Qsearch de Michaelwitz (0.5-8-3) y (0.5-6-3,200) . . . . . . . . . . . . . . . . 90

    10.1. Primer banco de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

    10.2. Segundo banco de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

  • xiv INDICE DE FIGURAS

    10.3. Plano pieza adaptadora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

    10.4. QSearch iteracion 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

    10.5. QSearch iteracion 40 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

    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 definicion, diseno eimplementacion de un vehculo aereo autonomo de corto alcance basado en una configuracionde cuatro motores con capacidad de vuelo estacionario.

    El Proyecto abarca tanto el diseno e implementacion hardware (la eleccion de los compo-nentes electronicos, tanto sensores como microprocesador y diferentes actuadores, la cons-truccion fsica de la estructura del vehculo y el diseno e implementacion de la placa base ylas interfaces hardware) como el diseno e implementacion software, tanto de aquel que eje-cutara embarcado en el vehculo como el software de la aplicacion de monitorizacion, mandoy control que se ejecutara en lo que se conoce como Estacion de Tierra (Ground ControlStation o GCS).

    Dentro de las capacidades del vehculo que han sido implementadas en este Proyecto seencuentra la capacidad de vuelo estacionario estable adecuadamente monitorizado y contro-lado. Para ello el vehculo debe interpretar adecuadamente todos los datos procedentes delos diferentes sensores, procesar estos datos y ejecutar las diferentes rutinas de control quepermiten la capacidad de mantener un vuelo estable, el control automatico y estabilizacionde altura, el control automatico y estabilizacion del rumbo y la capacidad de mantener co-municaciones inalambricas con la estacion de monitorizacion, mando y control. Tambien seha introducido alguna rutina de navegacion y se han esbozado las capacidades de navegacionque no ha sido posible implementar por motivos de calendario.

    Para la realizacion del proyecto se ha partido de cero, desde la eleccion de los entornosde desarrollo, la plataforma hardware, el diseno e implementacion del software embebido, yel diseno e implementacion del software de mando y control. Puntualmente se han utilizadocomo referencia fragmentos de algoritmos de calculos matematicos especificando en todocaso la fuente.

    xv

  • xvi CAPITULO 0. RESUMEN

  • Captulo 1

    Introduccion

    Un vehculo no tripulado es todo aquel vehculo capaz de realizar diferentes tipos de ta-reas sin la necesidad de contar con un tripulante humano. Los vehculos aereos no tripuladosUAV (Unmanned Aerial Vehicle) han cobrado una gran importancia en la industria ae-ronautica debido a que son capaces de cubrir un gran numero de necesidades y posibilidadesno exploradas hasta hace bien poco.

    Aunque aqu nos centremos en vehculos aereos tambien existen vehculos no tripuladosen tierra y mar. Dentro de los vehculos no tripulados se encuentran vehculos controladosremotamente (Remotely Piloted Vehicle o Drones) y vehculos autonomos AV (AutonomousVehicle). En el caso de este proyecto, nos centraremos en UAVs autonomos, capaces derealizar gran parte de las tareas sin la intervencion de un humano.

    Este tipo de vehculos son muy utiles en circunstancias en las que contar con un tripu-lando humano puede ser peligroso para su integridad, o en aquellos casos en los que pormovilidad, maniobrabilidad o flexibilidad 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 eranaeronaves simples pilotadas remotamente a traves de sistemas de radio control. Su usocomenzo a introducirse dentro del campo militar tras la Primera Guerra Mundial, usandoseen la Segunda Guerra Mundial como blancos moviles para el entrenamiento de sistemasantiaereos y de diferentes armas. A finales de los anos 60 y debido al riesgo potencial debajas de pilotos en misiones de reconocimiento en territorio enemigo, y debido al alto numerode vuelos de este tipo que se realizaron durante la Guerra Fra, los oficiales norteamericanosfijaron su interes en las posibilidades de los vuelos no tripulados. Esta necesidad se amplio conla entrada de Estados Unidos en la Guerra de Vietnam donde se produjo el primer uso deUAVs en misiones de combate.

    Al mismo tiempo, Israel comprendio la necesidad de invertir en el desarrollo de vehculosno tripulados al perder gran cantidad de aeronaves debido a las bateras de misiles an-tiaereos que desplegaban sus multiples enemigos en los distintos conflictos armados que seintensificaron a partir de los anos 70.

    En los anos 80 y 90 se produjo un gran avance en este tipo de vehculos, dotandolosde mayor capacidad autonoma. Tambien los diferentes avances en las tecnologas hicieron

    1

  • 2 CAPITULO 1. INTRODUCCION

    posible el abaratamiento de costes, as como la posibilidad de crear vehculos mas pequenosy versatiles.

    Con la llegada del siglo XXI y los nuevos escenarios de guerra moderna llego el boomde los UAVs, tanto de reconocimiento como de adquisicion de blancos y combate. El nuevoescenario de guerra urbana contra enemigos dispersos hizo necesario, por un lado, el uso depequenos y versatiles UAVs de reconocimiento que podan ser usados en campo para asistira las tropas en diferentes tareas, y por otro lado, de sofisticados UAVs de medio y largoalcance capaces de fijar blancos moviles e incluso abatirlos con un riesgo mnimo.

    Las capacidades autonomas han ido aumentando cada vez mas, desde asistir en vuelo aun piloto situado en una estacion remota, hasta el vuelo completamente autonomo siguiendoun determinado plan de vuelo precargado, y el seguimiento de un plan de mision avanzadocon gestion de la carga de pago (conjunto de elementos y dispositivos destinados a adquirirdatos de inteligencia).

    Actualmente los UAVs siguen siendo utilizados mayoritariamente en entornos militares,donde han conseguido hacerse un hueco como sistemas de vigilancia, inteligencia, reconoci-miento y adquisicion de blancos (ISTAR, Intelligence Surveillance Target Adquisition andReconnaissance). Paulatinamente van haciendose hueco tambien en aplicaciones civiles, so-bretodo en los campos de vigilancia, seguridad, y reconocimiento.

    1.2. Aplicaciones

    1.2.1. Militares

    Tal y como se ha adelantado en la introduccion, la mayor parte de las aplicaciones delos UAVs se centran en el campo militar. Dentro de las aplicaciones militares destacanla vigilancia y reconocimiento del entorno, incluyendo la deteccion y clasificacion de posi-bles amenazas, reconocimiento y adquisicion de blancos, obtencion de un mapa completogeografico del campo de batalla, e incluso el combate directo, aunque en este ultimo casosiempre guiado y monitorizado por un piloto humano. De entre todas las aplicaciones, dosde ellas han sufrido un profundo avance en los ultimos anos:

    Por un lado, las aplicaciones de vigilancia y reconocimiento de corto alcance, llevadasa cabo por pequenos UAVs desplegados en campo por los propios soldados. Estos cuentancon una pequena Estacion de Tierra para recopilar datos y generar inteligencia. Estos UAVsproveen a los combatientes de informacion casi en tiempo real, de manera que pueden ge-nerar un mapa tanto geografico como de amenazas y blancos. Estos UAVs son pequenasaeronaves generalmente propulsadas electricamente, que pueden ser desplegadas a mano porlos soldados y que en algunos casos no retornaran nunca. Cuentan con baja autonoma, muybajo coste y proporcionan una informacion muy valiosa a corto plazo.

    Por otro lado se encuentran UAVs de mayor tamano usados tanto en misiones ISTARcomo de combate. Estos vehculos en algunos casos tienen casi el tamano de un avion decombate convencional, con autonomas que cubren grandes distancias y alturas. La infor-macion que proporcionan puede ser, en algunos casos, directamente usada por sistemas deartillera o incluso pueden contar con armamento embarcado.

    Los UAVS ISTAR generalmente proporcionan informacion tactica muy valiosa en inte-ligencia que puede ser usada tambien a largo plazo. Tambien pueden tener la capacidad de

  • 1.3. CLASIFICACION 3

    sincronizarse entre diferentes UAVs para aumentar el valor de dicha informacion. El estadode Israel ha realizado verdaderos progresos en UAVs capaces de adquirir blancos movilesa distancias enormes, sin apenas ser detectados, o generando alertas de riesgos y amenazasmientras patrullan regiones crticas, como la Franja de Gaza, o las fronteras con Lbano,repletas de terroristas ocultos entre poblacion civil y en poblado.

    1.2.2. Civiles

    El ambito de aplicacion de los UAVs no se limita al area militar, poco a poco, comienzana demandarse aplicaciones y servicios en el campo civil.

    Los UAVs civiles de largo alcance son utilizados en tareas de identificacion de riesgosy vigilancia de zonas amplias en espacios de difcil acceso, como vigilancia de grandes ins-talaciones de canalizacion de gas, gasoleo, o similares. Tambien en tareas de identificacionde conatos de incendios en grandes zonas boscosas, incluso en los servicios de proteccion defronteras, ayudando a las Fuerzas y Cuerpos de Seguridad del Estado en la identificacion yseguimiento de embarcaciones que pretenden entrar ilegalmente en el pas a traves del mar,ya se trate de inmigracion ilegal, o trafico ilegal de diferentes sustancias o materiales.

    Estos vehculos abaratan considerablemente el coste de las misiones de control y vigilan-cia, ya que antes de estos vehculos estas tareas eran llevadas a cabo por aviones pilotadoso helicopteros, cuyo coste de adquisicion, mantenimiento y entrenamiento, es muy elevado.

    Los cuerpos de seguridad tambien comienzan a demandar pequenos UAVs de corto al-cance para tareas de vigilancia de permetros, o incluso reconocimiento del campo de accion,por ejemplo, por parte de la Polica o Guardia Civil. Estos vehculos son similares a losusados en campo por el ejercito, suelen tener un alcance limitado y un coste muy bajo,proporcionando una gran cantidad de inteligencia a los cuerpos desplegados en campo.

    Tambien existen otras aplicaciones civiles como servicios de fotografa o captura de vdeoaereo, util para conformar mapas actualizados de parcelas para la construccion o rehabili-tacion de inmuebles, as como otros usos dirigidos hacia el entretenimiento. Por ultimo,tambien se usan vehculos no tripulados en aplicaciones cientficas de investigacion, susti-tuyendo, por ejemplo, a globos sonda, incluso para el transporte de pequenas cargas entrayectos cortos que seran muy costosos si tuvieran que ser realizados de otra manera.

    Podemos decir que el campo de los vehculos no tripulados en general, y el de los aereosen particular es un mercado en expansion, en el que van apareciendo nuevos ambitos deaplicaciones y usos constantemente.

    1.3. Clasificacion

    Los UAVs pueden ser clasificados tanto por su ambito de aplicacion como por su alcancey capacidades [20].

    Por su ambito de aplicacion, tal y como ya se ha definido, los UAVs pueden ser clasificadosbasicamente en cinco categoras: ISTAR (inteligencia, vigilancia, adquisicion de blancos yreconocimiento), logstica, combate, investigacion y desarrollo, y UAVs civiles.

    Dentro de esas cinco categoras se pueden encontrar UAVs de diferentes tamanos, alcances

  • 4 CAPITULO 1. INTRODUCCION

    Figura 1.1: Raven RQ-11B de AeroVironment. De lanzamiento manual y motorizacionelectrica. Puede ser controlado remotamente u operar de manera completamente autonoma,monta camaras de vdeo y de vision infrarroja, es utilizado para reconocimiento y adqui-sicion de blancos. Su autonoma es de 40 minutos y pesa 2 kilos. El coste de cada unidades de 35.000 $ por separado y de 235.000 $ con el sistema completo incluyendo estacion decontrol de tierra. (Entrada en servicio: 2006).

    y capacidades. Si se tiene en cuenta simplemente el tamano y alcance de los vehculos, estospueden ser clasificados en las siguientes categoras:

    Handheld: Se trata de pequenos y ligeros vehculos que pueden lanzarse de maneramanual, con alcances limitados a menos de 2000 metros y que pueden alcanzar no masde 500 metros de altura.

    Close: De alcance cerrado o corto alcance, son capaces de alcanzar 1500 metros dealtitud y cuentan con una autonoma por debajo de los 10 kilometros. Su despeguepuede ser manual, ayudados por catapulta o mediante despegue autonomo.

    De tipo NATO: UAVs medios capaces de alcanzar 3000 metros de altitud y llegar a los50 kilometros de autonoma. Generalmente su tamano ya no permite el lanzamientomanual.

    Tacticos: Capaces de alcanzar 5500 metros de altitud y con autonomas que puedenllegar a los 160 kilometros.

    MALE (Medium Altitude, Large Endurance): UAVs capaces de alcanzar altitudesmedias si hablamos con terminologa aeronautica, aproximadamente sobre los 9000metros de altitud, y con autonoma suficiente para poder cubrir grandes distancias,aproximadamente sobre los 200 o 300 kilometros.

    HALE (High Altitude, Large Endurance): UAVs capaces de alcanzar altitudes superio-res a los 9100 metros y con alcances indefinidos (pueden llegar hasta 10000 kilometroso mas).

    Hipersonicos y Orbitales: Por ultimo aquellos vehculos capaces de alcanzar velocidadessupersonicas (de MATCH 1 a MATCH 5) o hipersonicas (superior a MATCH 5), oaquellos capaces de ponerse en orbitas bajas alcanzando velocidades de mas de MATCH25.

  • 1.3. CLASIFICACION 5

    Figura 1.2: Scan Eagle: UAV desarrollado por Boeing de tipo NATO. Cuenta con una au-tonoma de hasta 20 horas o 100 kilometros, entre su carga de pago cuenta con camaraauto-estabilizada infrarroja de alta resolucion. Es capaz de alcanzar 60 nudos de velocidadmedia (110 Km/h). En la foto lo vemos en su plataforma de lanzamiento movil. (Entradaen servicio: 2006).

    Figura 1.3: IAI Eitan desarrollado por Israel Aerospace. Se trata de un UAV de tipo MALEcon capacidades ISTAR. Capaz de mantenerse en vuelo durante 36 horas a 35.000 piesde altitud (10.600 metros), albergar una carga de pago de 2.000 kilos y cubrir hasta 7000kilometros. Es la joya de la corona de los UAVs del ejercito israel, su tamano es comparablea un Boeing 737. (Entro en servicio en 2009).

  • 6 CAPITULO 1. INTRODUCCION

    Figura 1.4: Northrop Grumman Fire Scout. Helicoptero UAV usado por la fuerza aereaestadounidense en tareas de reconocimiento, identificacion de amenazas y fijacion precisade blancos. Autonoma de 8 horas y rango de accion de 200 kilometros. (Operacional desde2006).

    Dentro de los diferentes tipos de UAVs introducidos, y en el marco de este Proyecto, esinteresante diferenciar los UAVs con capacidades de vuelo estacionario y aterrizaje/despeguevertical VTOL (Vertical Take-Off and Landing) del resto. Una aeronave VTOL es capaz demantener vuelo estacionario en altura y direccion, es decir, sin avanzar en eje alguno decoordenadas. Las mas comunes son los helicopteros.

    Si hablamos de vehculos no tripulados, existen diferentes modelos de UAVs de tamanomedio basados en helicopteros, las particularidades de este tipo de aeronave hacen que seanideales para determinadas misiones de reconocimiento, rescate, e incluso de combate cerrado.Sin embargo, es en los UAVs de corto alcance donde este tipo de vehculos ha logrado mayoracogida debido a la flexibilidad que proporcionan.

    Los vehculos VTOL con capacidades estacionarias vuelan gracias al impulso directo queejercen los motores, generalmente aplicado a una o mas helices, sobre el aire. Esto hace quelos motores deban estar en constante funcionamiento para mantener el vehculo en vuelo,por el contrario, en los vehculos de despegue ordinario con alas, gran parte de la fuerzanecesaria 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 capacidadesestacionarias encontramos diversos modelos de vehculos de cuatro helices, aunque tambiense encuentran en configuraciones de seis y ocho motores. Estos vehculos son especialmenteinteresantes al ser capaces de conseguir vuelos muy estables y tener una maniobrabilidaddestacada. Son vehculos propulsados por motores electricos con autonomas que rondan los10-12 minutos, cubriendo de 2 a 5 kilometros.

    1.4. Carga de Pago

    En entornos aeronauticos, se denomina carga de pago a aquella carga que es capaz decargar la aeronave y que no es estrictamente parte de los sistemas de navegacion y controlde la misma. En el caso de los aviones de transporte de pasajeros o mercancas, la carga de

  • 1.4. CARGA DE PAGO 7

    Figura 1.5: Aeryon Scout de Aeryon Labs. UAV de cuatro motores con su estacion de tierra.Rango de accion de 3 kilometros a partir de la estacion de tierra, cuenta con una camaraFLIR de vision nocturna autoestabilizada.

    Figura 1.6: RQ-4 Global Hawk UAV desarrollado por Northrop Grumman para la fuerzaaerea estadounidense. Se trata de un UAV de tipo HALE capaz de cubrir distancias de hasta27.000 kilometros, 20.000 metros de altitud y hasta 36 horas de vuelo. Incluye capacidad decargar con radar de alta resolucion SAR (Synthetic Aperture Radar) y sensor electro-opticoe infrarrojo capaz de cubrir areas de 100.000 kilometros cuadrados. Con un coste de 35millones de dolares entro en operacion en la guerra de Irak a finales de 2006.

  • 8 CAPITULO 1. INTRODUCCION

    Figura 1.7: Sensor electro-optico termico. Es uno de los sensores mas demandados en losUAVs por su capacidad de tomar imagenes a grandes distancias y en diferentes condicionesambientales.

    pago la conforman los pasajeros y las mercancas a transportar, en el caso de un UAV, sedenomina carga de pago a los sistemas y equipos que son usados para generar informacion deutilidad tactica o de inteligencia. Una caracterstica muy importante de los UAVs es el pesoen carga de pago que es capaz de soportar la aeronave, ya que cuanto mas carga de pagomayor numero de sensores, camaras, equipos de comunicaciones o armamento sera capaz desoportar el UAV. Evidentemente, a mayor carga de pago, mayor consumo, por lo que losUAVs con menor autonoma soportan menores cargas de pago.

    Entre los equipos mas utilizados como carga de pago en los diferentes UAVs contamos contodo tipo de sensores y equipos de medicion, incluyendo camaras fotograficas y de captura devideo, camaras de vision nocturna y con lentes capaces de captar diferentes espectros, sonar,radar, sistemas laser, etc. Tambien equipos y computadores encargados del procesamiento dedichas senales 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 dediferentes alcances.

    Los sensores y equipos con los que el UAV cuenta y que son usados por los propios sis-temas de control y navegacion del vehculo no son tomados en cuenta a la hora de definirla carga de pago del UAV. Entre estos sensores se pueden contar acelerometros, giroscopos,completas unidades de medicion inerciales, magnetometros, barometros, sistemas de posi-cionamiento tales como el GPS1, y sistemas de comunicaciones por radio. Estos equiposno forman parte formalmente de la carga de pago, aunque tambien proporcionen informa-cion que unida a la de los equipos de la carga de pago puedan generar informacion util ointeligencia.

    1.5. Estacion de Tierra

    En cualquier caso, ademas del vehculo no tripulado, es necesario contar con una estacionen tierra o GCS (Ground Control Station) capaz de recibir la informacion que percibe elvehculo, y a traves de la cual se pueda monitorizar y controlar toda la actividad del UAV.En algunos casos, esta estacion esta formada por una estacion fija, en otros por una unidadmovil. En el caso de los vehculos militares, lo mas comun es contar con una unidad movildesplegable, desde la cual monitorizar y comandar al vehculo.

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

  • 1.6. SITUACION EN ESPANA 9

    Figura 1.8: Estacion de Tierra GCS del UAV estadounidense de combate Predator.

    En el caso de UAVs de corto alcance, esta estacion de tierra debe ser lo suficientementeflexible como para poder ser desplegada en campo por los operarios. Quizas cargada en unamochila dentro de un maletn debidamente protegido del exterior siguiendo los estandaresmilitares, de modo que sea facilmente desplegable y con una interfaz adecuada, de maneraque sea capaz de proveer de informacion util en unas condiciones de combate.

    1.6. Situacion en Espana

    En el caso de Espana existen diferentes proyectos para el desarrollo de UAVs con capa-cidades tanto de combate como de reconocimiento [27]. Actualmente la empresa Cassidian,perteneciente al grupo EADS2 esta desarrollando un demostrador tecnologico UAV de largoalcance con capacidades de vuelo sigiloso y combate llamado nEUROn. Se trata de un pro-yecto en el que participan distintos pases europeos y en el cual Espana desarrolla toda laestacion de control en tierra y el software asociado (incluido comunicaciones).

    Espana tambien participa en el programa Talarion (tambien a traves de Cassidian) parael desarrollo, a nivel europeo, de un UAV ISTAR, aunque con la crisis iniciada en 2008 lospresupuestos han sido congelados y las posibilidades de continuacion del proyecto estan enel aire.

    Adicionalmente existe un programa para el desarrollo de un UAV ISTAR de tipo MALEcompletamente nacional llamado ATLANTE, del cual tanto el Ministerio de Defensa comomultiples organismos civiles han mostrado interes en adquirir y cuyo primer vuelo esta pro-gramado para Septiembre de 2011. Con el proyecto ATLANTE tanto la industria espanolacomo el Ejercito estan interesados en construir un demostrador tecnologico que desarrolletodas las capacidades necesarias para la construccion de este tipo de vehculos y, de estamanera, poner a Espana en la punta de lanza en lo que a tecnologa UAV se refiere.

    La participacion en el pastel de los UAVs a nivel nacional ha despertado el interes depequenas empresas y grandes corporaciones como Indra o Thales.

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

  • 10 CAPITULO 1. INTRODUCCION

    Figura 1.9: Demostrador tecnologico nEUROn. Un UAV de combate con capacidades devuelo invisible (STEALTH). (Primer vuelo programado para 2012).

    Figura 1.10: ATLANTE UAV. Proyecto de UAV tipo MALE totalmente espanol que preten-der ser un demostrador tecnologico de las capacidades del ejercito y la industria espanola.(Primer vuelo programado para Octubre de 2011).

  • Captulo 2

    Objetivos

    2.1. Descripcion del Problema

    El objetivo de este Proyecto Fin de Carrera es la definicion, diseno y construccion e im-plementacion de un UAV de corto alcance (tipo Close) con caractersticas VTOL (despeguey aterrizaje vertical).

    En este captulo se realizara primero una descripcion general del objetivo a resolver. Acontinuacion se resumira la coleccion de requisitos impuestos al proyecto para, por ultimo,definir la metodologa utilizada durante todo el proceso de desarrollo.

    El proyecto en cuestion se divide en tres partes o subobjetivos bien diferenciados:

    1. Diseno e integracion hardware. Esto incluye la seleccion de dispositivos a integrar, eldiseno de las placas de circuito, las conexiones y la integracion con el microcontrolador.Tambien el diseno y construccion del chasis del vehculo, la eleccion de componentes,as como la solucion de los diferentes problemas tecnicos derivados de la construccionfsica del vehculo y de su puesta en funcionamiento.

    2. Especificacion, diseno, implementacion e integracion del software que ejecutara en elmicrocontrolador embarcado del vehculo. Incluyendo la parte de comunicaciones, tan-to aquellas destinadas a la telemetra, como las interfaces hardware para interactuarcon todos los sensores y actuadores del vehculo, as como los modulos software encar-gados de la estabilizacion y navegacion.

    3. Especificacion, diseno, implementacion e integracion del software correspondiente a laestacion en tierra, incluyendo la interfaz grafica de usuario. En este caso una completaaplicacion grafica que permite al operador monitorizar e interactuar con el vehculo.Sin olvidar las utilidades de depuracion y pruebas.

    Estas tres partes diferenciadas suman caractersticas y dificultades muy diferentes, queabarcan desde el diseno e integracion de componentes electronicos, motores, bateras, sen-sores, etc., a la implementacion de protocolos de comunicaciones por radio, algoritmos quesean capaces de procesar la informacion de los sensores de modo que pueda ser usada poralgoritmos de estabilizacion, la implementacion de esos mismos algoritmos de estabilizacion,pasando por el diseno e implementacion de interfaces graficas amigables y utiles. Sin olvidar

    11

  • 12 CAPITULO 2. OBJETIVOS

    Figura 2.1: Diagrama de componentes

    la costosa tarea de integracion, depuracion y pruebas de toda la plataforma que conformael UAV, que por supupuesto ha de ser realizada con rigor.

    Aunque el objetivo principal es lograr que el vehculo resultante de este PFC sea fun-cional, el segundo objetivo, y no menos importante, es estudiar y poner en practica todaslas fases de desarrollo necesarias para la implementacion de un proyecto de Ingeniera tancompleto. Es decir, analizar las diferentes fases que conllevan este tipo de proyectos, losproblemas encontrados, las diferentes maneras de resolverlos, los costes de desarrollo, la ca-pacidad necesaria para poder desarrollarlos, y al final, estudiar y concluir, sobre el resultadoobtenido, las caractersticas y peculiaridades de este tipo de proyectos.

    Al tratarse de un proyecto con una complejidad y dimension elevada, ha sido necesarioponer un lmite al proyecto estableciendo unas caractersticas y funcionalidades bien delimi-tadas de modo que sea posible implementarlas en el marco de tiempo de un proyecto fin decarrera.

    2.2. Requisitos

    En primer lugar se procedera a definir una serie de requisitos funcionales de alto nivelreferidos a las capacidades y caractersticas del UAV que se desea implementar. En segundolugar se definiran, para cada una de las tres partes que componen el proyecto, una coleccionde requisitos funcionales con un nivel de especificacion mayor, que seran los que definany limiten el marco del PFC. Dentro de estos requisitos se mezclaran requisitos funciona-les, no funcionales y software (de bajo nivel). La intencion no es presentar un documentode especificacion de requisitos software (SwRD1) sino orientar y limitar la dimension deldesarrollo.

    Los requisitos de alto nivel definen los aspectos que convierten al proyecto en un UAV

    1Software Requirements Document

  • 2.2. REQUISITOS 13

    de tipo Close:

    REQ1. El vehculo debe ser capaz de volar de manera autonoma, es decir, no radio-controlado.

    REQ2. Debe ser capaz de despegar y aterrizar verticalmente, as como tener capaci-dades de vuelo estatico estable.

    REQ3. Se debe contar con una estacion en tierra para monitorizar el estado del vehcu-lo, tanto parametros de estabilizacion como de navegacion. Tambien se deben podercomandar determinados parametros de navegacion que se cargaran en el vehculo.

    REQ4. El vehculo debe ser capaz de seguir y mantener de manera autonoma un plande vuelo comandado a traves de la estacion de tierra (dicho plan de vuelo se limitara enel marco del PFC a un vector de direccion).

    REQ5. Debe tener una autonoma de 2 kilometros desde el punto de lanzamiento, conun techo de altitud de 300 metros.

    REQ6. La estacion de tierra debe poder ser ejecutada en un portatil, de manera queel UAV pueda ser facilmente desplegable.

    REQ7. El vehculo debe ser capaz de soportar una carga de pago util de 200 gramos.

    Estos requisitos de alto nivel se convierten en las siguientes tres colecciones de requisitosde bajo nivel para cada una de las tres partes en las que se divide el proyecto.

    2.2.1. Requisitos Hardware

    REQ8. El vehculo contara con cuatro motores con sus controladores de velocidadelectronicos ESC2 encargados del impulso del modelo.

    REQ9. Contara con un chasis principal con cuatro brazos en forma de cruz de maneraque los motores queden en los extremos de los brazos, la separacion de los motorespuede variar entre 40 y 70 centmetros.

    REQ10. Dispondra de un soporte para mantener una batera de alta capacidad quealimentara tanto los motores como la unidad central de procesamiento UC.

    REQ11. La unidad central de procesamiento (UC) se situara en el centro del chasis eincorporara un microprocesador encargado de realizar todo el procesamiento.

    REQ12. La UC contara con una unidad inercial IMU (Inercial Measurement Unit)conformada por tres acelerometros y tres giroscopos. Tambien contara con un compasdigital y un barometro. Todos los sensores deben quedar perfectamente integrados enuna placa de circuito consistente.

    REQ13. La UC dispondra de un modulo de radio encargado de comunicar el vehculocon la estacion de tierra. Dicho modulo debe tener la suficiente autonoma como paracubrir el techo de distancia del vehculo.

    2ESC: Electronic Speed Controller

  • 14 CAPITULO 2. OBJETIVOS

    2.2.2. Requisitos Software Embarcado

    REQ14. El software debe ser capaz de comunicarse con los controladores de velocidadESCs de cada uno de los cuatro motores de modo que sea capaz de inicializarlos ycalibrarlos.

    REQ15. El software debe ser capaz de leer y procesar las lecturas de los sensores demodo que sea capaz de calcular a partir de las mismas el angulo de inclinacion queforma el modelo con los tres ejes de coordenadas.

    REQ16. Tambien debe ser capaz de obtener adecuadamente los datos de altitud ba-rometrica y temperatura.

    REQ17. El software debe implementar un protocolo de comunicaciones adecuado parapoder comunicarse de manera inalambrica a traves del modulo de radio con la estacionde tierra. Debe ser capaz de enviar datos de telemetra con la informacion disponiblea traves de sus sensores, as como recibir y procesar comandos a traves de los cualesse pueda cambiar el vector de direccion a seguir. As como otros parametros como lapotencia total de los motores y comandos especiales de reinicio, parada de emergencia,o configuracion de estabilizacion.

    REQ18. El software debe ser capaz de transmitir diferentes tipos de mensajes a travesdel modulo de comunicaciones, incluyendo mensajes de depuracion, warnings, alarmas,etc.

    REQ19. El software contara con un modulo de estabilizacion y otro de navegacion.

    REQ20. El modulo de estabilizacion debe ser capaz de, tomando como entrada losvalores ledos y procesados de la IMU, elegir la potencia adecuada a aplicar en cadauno de los motores para mantener el vehculo estabilizado en vuelo.

    REQ21. El modulo de navegacion debe ser capaz de, tomando como entrada los valoresledos y procesados de la IMU, elegir los cambios en la potencia de cada uno de losmotores de modo que el vehculo sea capaz de adquirir el vector de direccion demandadomanteniendo el modelo estabilizado (modulo de estabilizacion tendra mayor prioridadque el de navegacion).

    REQ22. El software debe ser capaz de recibir y procesar un plan de vuelo consistenteen una serie de vectores de direccion separados en el tiempo.

    REQ23. El software debe implementar algoritmos de emergencia (con alta prioridad),tales como aterrizaje de emergencia, estabilizacion en altura y otros del estilo quepuedan ser comandados desde la estacion de tierra, con independencia del plan devuelo precargado con anterioridad.

    REQ24. El software debe estar lo suficientemente optimizado como para que en cadaciclo de ejecucion el microprocesador sea capaz de realizar todas las tareas de lecturade datos, posterior procesamiento y comando de los actuadores, as como las tareas decomunicaciones y procesamiento de comando recibido, sin que ninguna de estas tareassufran un retraso en su ejecucion.

    2.2.3. Requisitos de Estacion en Tierra

    REQ25. El software de la estacion en tierra (GCS) debe proporcionar una interfazgrafica que permita al operador interacturar con el vehculo.

  • 2.3. METODOLOGIA 15

    REQ26. La GCS debe proporcionar informacion del estado del enlace de datos con elvehculo, as como los comandos necesarios para establecer el enlace de datos.

    REQ27. La GCS debe proporcionar informacion sobre el estado del modelo, incluyen-do los angulos que forma con los ejes de coordenandas (Pitch, Roll y Yaw), tambieninformacion sobre el rumbo actual del modelo (Heading), y de las diferentes medidassin interpretar de los sensores de la IMU (aceleraciones lineales y velocidades angularesen los distintos ejes).

    REQ28. La GCS debe proporcionar una representacion simplificada del vehculo en 3Dde manera que el operador pueda conocer el estado del modelo sin tener vision directadel mismo. Tambien debe contar con un PFD3 en el que se represente un horizonteartificial con el alabeo (Roll) y cabeceo (Pitch) del modelo, as como una rosa de losvientos4 que indique el rumbo (heading) del modelo respecto al norte magnetico.

    REQ29. La GCS debe proporcionar la informacion de potencia comandada a cadauno de los motores, as como la posibilidad de cambiar manualmente la potencia totale individual de los mismos.

    REQ30. La GCS debe proporcionar una interfaz de calibracion y pruebas donde sepuedan realizar diferentes test de estabilizacion.

    REQ31. La GCS debe contar con una consola de texto a traves de la cual se puedanrecibir mensajes con diferente informacion del vehculo, incluyendo informacion dedepuracion y test, as como diferentes tipos de avisos y alarmas (Warnings).

    REQ32. La frecuencia de refresco de los valores de telemetra deben ser suficientescomo para obtener una vision realista del estado actual del modelo por parte de losoperadores.

    REQ33. La GCS debe poder ser ejecutada en un portatil con recursos limitados(Procesador Intel Atom N260 y 512 MB de RAM) de forma agil y practica.

    2.3. Metodologa

    Al tratarse de un proyecto con una carga de hardware muy elevada y con dos desarrollossoftware bien diferenciados (parte embarcada y estacion de tierra) la metodologa debe sersuficientemente flexible como para poder ser aplicada con exito a cada uno de las partes delproyecto.

    Se decidio seguir una metodologa basada en un proceso iterativo e incremental utilizadocomunmente en entornos guiados por un desarrollo agil de software. De esta manera losincrementos del desarrollo software pueden servir para probar el desarrollo e integracionde la parte hardware, permitiendo el avance y depuracion de la parte hardware mientrasse continua el desarrollo del siguiente incremento software, tanto en su version embarcadacomo de la estacion de tierra.

    Para ello se definieron cuatro incrementos principales que suponen pequenos pasos tantoen software y hardware. Estos cuatro incrementos se definieron para cada uno de los tressubsistemas; hardware, software embarcado y estacion de tierra.

    3Primary Flight Display4Rosa de los Vientos: circulo que tiene marcados alrededor los rumbos en que se divide la circunferencia

    del horizonte.

  • 16 CAPITULO 2. OBJETIVOS

    Figura 2.2: Diagrama iterativo-incremental: Cada incremento pasa por las cuatro fases

    Figura 2.3: Cada uno de los tres componentes evolucionan simultaneamente en los incremen-tos, coincidiendo a la finalizacion de cada incremento en la fase de Integracion y Pruebas.

  • 2.3. METODOLOGIA 17

    Para cada uno de los incrementos se establecen cuatro fases:

    1. Objetivos y Planificacion

    2. Analisis

    3. Desarrollo (Implementacion/Construccion)

    4. Integracion y Pruebas

    Siendo el punto de nexo comun entre las tres partes la fase de pruebas e integracion.

    El primer incremento se llamo V0 y se corresponde con la primera toma de contacto yaprendizaje sobre las diferentes plataformas de desarrollo software y hardware. Incluye lafamiliarizacion con los diferentes sensores y plataformas hardware a utilizar, sus interfaces,conexiones, etc. Por parte del software embarcado la familiarizacion con la plataforma dedesarrollo elegida (Arduino), su entorno de ejecucion, peculiaridades de depuracion e integra-cion con las comunicaciones serie. Por parte del software de la GCS supone una introduccional lenguaje de programacion utilizado (Processing), la programacion de interfaces 2D/3Dcon OpenGL5 y las comunicaciones serie con la plataforma Arduino.

    El segundo incremento o V1 es el primer incremento con funcionalidad especfica derivadade requisitos para cada uno de los subsistemas:

    Plataforma Hardware: Construccion de la primera version del chasis del vehculo, in-tegracion de motores y ESCs, integracion del modulo de comunicaciones radio con elmicroprocesador, conexiones electricas y primera version de IMU.

    Software Embarcado: Descomposicion preliminar en modulos, primera version del pro-tocolo de comunicaciones para permitir la transferencia de los primeros datos de sen-sores e informacion de depuracion a la consola de la GCS, implementacion de la ad-quisicion de datos de aceleraciones y velocidades angulares, e inicializacion y gestionde la potencia de los motores.

    Software GCS: Primera version de la interfaz grafica, modelo 3D del vehculo, primeraversion del horizonte artificial, interfaz de comunicaciones, primera version del proto-colo de comunicaciones, enlace activo de datos con el vehculo tanto por radio comopor cable serie (conexion directa a traves de USB).

    El tercer incremento o V2 cuenta ya con una version avanzada de practicamente todaslas funcionalidades de comunicaciones, estabilizacion y depuracion del UAV:

    Plataforma Hardware: Segunda version del chasis, integracion en una placa de circuitode todos los sensores y microprocesador con las conexiones adecuadas, todo empaque-tado en una caja. Desarrollo de una plataforma de test segura para realizar pruebasde estabilizacion. Posibles mejoras en sensores, interfaces, conectores, etc. Integracionde la batera en el chasis.

    5OpenGL: Especificacion estandar que define una API multiplataforma para producir graficos 2D y 3Dhttp://www.opengl.org/

  • 18 CAPITULO 2. OBJETIVOS

    Software Embarcado: Mejoras en protocolo de comunicaciones, procesamiento de laslecturas de sensores, fusion de los datos para obtener los angulos del vehculo con losejes (Pitch, Roll y Yaw). Diseno e implementacion del modulo de estabilizacion para laseleccion de salida a los motores a traves de controladores de bucle cerrado PIDs. Estaversion incluye la interfaz de calibrado y test dinamico de parametros de estabilizacion.

    Software GCS: Mejoras en modelo 3D, desarrollo de PFD definitivo, herramientas dedepuracion y test, modulo de grabacion y reproduccion de datos con la capacidad dereproducir una sesion de calibrado y de vuelo.

    En el ultimo incremento o V3 se anade la funcionalidad necesaria para poder llegar a rea-lizar vuelos de prueba con la suficiente solidez, anadiendo pequenos detalles y solucionandoposibles problemas encontrados:

    Plataforma Hardware: Tercera version del chasis, integracion del barometro y sonar,cambios de conectores para mejorar montaje final, construccion de un paragolpes pro-tector que facilite las pruebas de vuelo, instalacion de la antena de telemetra definitiva.

    Software Embarcado: Integracion de barometro, sonar y compas digital. Integracion enlos bucles de control para controlar el rumbo. Optimizacion de los diferentes algoritmos,incluyendo comunicaciones.

    Software GCS: Optimizacion de la interfaz de mando y control, mejora de la disponi-bilidad y robustez de la aplicacion, as como la inclusion de las utilidades necesariaspara soportar las pruebas de vuelo.

  • Captulo 3

    Estudio de Alternativas

    Antes de entrar de pleno en el proceso de desarrollo es necesario realizar un breve repasode los proyectos mas significativos en el campo de los UAVs, ya que gracias a ellos se puedeneliminar alternativas no validas en el diseno, o solventar problemas ya resueltos sobre losque no se desea profundizar demasiado.

    Se pueden encontrar, por un lado, proyectos de vehculos radiocontrolados que cuentancon cierto grado de autonoma, entre estos, se encuentran proyectos de aeroplanos radio-controlados con microprocesador embarcado para facilitar y mejorar el control de vuelo.Tambien vehculos de despegue vertical VTOL muy similares en configuracion al objeto deeste proyecto como [35],[1] o [45].

    El grado de autonoma del vehculo es variable en cada proyecto, y va desde pequenasfuncionalidades de auto-estabilizacion para facilitar el control, hasta la plena autonoma delvehculo desde el despegue al aterrizaje, pasando por vehculos radiocontrolados con capa-cidades de vuelo en primera persona (haciendo uso de camaras) e implementando modulosde telemetra muy completos [15].

    3.1. Mikrokopter

    Mikrokopter es un proyecto no libre de origen aleman desarrollado por la empresa HiSys-tems [24] con un estado muy avanzado de desarrollo. El objeto del proyecto es un UAV VTOLde tipo Close muy similar al objeto de este proyecto, aunque con diferentes configuracionesde motores, entre 4 y 8.

    Para controlar el Mikrokopter han utilizado un microprocesador Atmel ATMEGA644a 200MHz como unidad central, la unidad inercial es un desarrollo cerrado propio. Lasprincipales ventajas de este proyecto es que comenzo su desarrollo en 2006, por lo que tras5 anos de desarrollo tanto la plataforma hardware como el software son muy robustos yfuncionales.

    Ademas de la unidad inercial, cuenta con un modulo de navegacion opcional con GPS, 3magnetometros y soporte de tarjetas de memoria Flash, gestionado por un microcontroladorARM9.

    La principal ventaja frente a proyectos similares es la capacidad de usar interfaces I2C1

    1I2C:Inter-Integrated Circuit, bus de comunicaciones serie de dos lineas desarrollado por Phillips

    19

  • 20 CAPITULO 3. ESTUDIO DE ALTERNATIVAS

    Figura 3.1: Mikrokopter con una configuracion de 8 motores.

    Figura 3.2: Modulo central de Mikrokopter.

    Figura 3.3: Modulo de navegacion con GPS, el acabado de las placas esta muy conseguido.

  • 3.2. AEROQUAD 21

    Figura 3.4: NicoletoMK basado en Mikrokopter

    (de los que se hablara en profundidad mas adelante 7.2.1) para comandar potencia a loscontroladotes de velocidad, ya que esto permite tasas de actualizacion del orden de 450 Hzen la salida a los motores, lo que les permite tener un control muy fino sobre la potencia delos mismos, desembocando en un regimen de estabilizacion muy alto.

    Ademas cuentan con la experiencia de haber realizado gran cantidad de pruebas con di-ferentes configuraciones, por lo que las caractersticas de potencia de los motores, distanciaentre los mismos, tamano de las helices, capacidad de las bateras, as como otras carac-tersticas fsicas del vehculo son aspectos a tener en consideracion. Por lo menos para tenerla seguridad de que es posible llegar al objetivo con hardware y configuraciones similares.

    El estado de desarrollo es muy alto, cuentan con una estacion de tierra muy completa,y el sistema es muy configurable, de modo que se puede desde radiocontrolar el vehculoapoyadandose en su control de estabilizacion, hasta realizar un plan de vuelo completo conwaypoints editables desde la GCS, pasando por la implementacion de rutinas acrobaticasautomaticas.

    Tambien es un buen proyecto para comparar el rendimiento conseguido con el desarrollode 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 comercial-mente las posibilidades del vehculo, como NikoletoMK [35] 3.4, que ha mejorado el chasis yha anadido una plataforma auto estabilizadora avanzada dedicada a la grabacion de vdeosaereos en alta definicion.

    3.2. Aeroquad

    Aeroquad es un proyecto open source de un UAV con las mismas caractersticas queMikrokopter. Cuenta con la ventaja de que es open source y que ademas la plataformahardware sobre la que se desarrolla tambien es abierta [1].

    Aeroquad se basa en la plataforma Arduino para construir la unidad central (ATmega 328a 16 MHz), sobre esta plataforma se profundizara en el captulo de plataforma de desarrollo4.1.

  • 22 CAPITULO 3. ESTUDIO DE ALTERNATIVAS

    Figura 3.5: Aeroquad radiocontrolado

    Aunque no cuenta con el nivel de finalizacion que tiene mikrokopter es un proyectointeresante en cuanto a que todo el codigo es accesible y los resultados obtenidos son muybuenos, si bien, es cierto que estos resultados dependen de la calidad de los sensores ycircuitos utilizados, siendo necesario un alto desembolso economico para poder replicar elproyecto original.

    Ademas, 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 complicadoobtener ayuda de la comunidad alrededor del mismo.

    3.3. Ardupilot

    Ardupilot es un proyecto open source dedicado a obtener una unidad de navegacion iner-cial libre, basada en la plataforma Arduino. Esta unidad de navegacion puede ser utilizadaen diferentes proyectos, por un lado en aeronaves radiocontroladas, por otro en proyectos devuelo en primera persona (radiocontrolado pero sin vision directa del vehculo y controlando-lo a traves de camaras instaladas en el vehculo), y por ultimo en todo tipo de UAVs, tantode despegue vertical como tipo aeroplano.

    Es un proyecto maduro, que cuenta con una buena comunidad alrededor que comercializalas placas de control en diferentes niveles de integracion. La ventaja principal del proyectoes que han resuelto muy bien el problema de la fusion de datos de diferentes sensores usandotanto filtros kalman avanzados, como algoritmos basados en matrices de cosenos directrices(DCM2).

    Cuentan en su comunidad con una verdadera eminencia en el desarrollo del algoritmode Matrices de Cosenos Directrices como W. Premerlani [43], y cuentan con un codigo muy

    2DCM: Direction Cosine Matrix

  • 3.3. ARDUPILOT 23

    Figura 3.6: Ardupilot: unidad de navegacion inercial.

    Figura 3.7: Ardupilot sobre un Easy Glider, implementa funciones de piloto automatico.

    optimizado. Por lo que este proyecto es una gran fuente de conocimiento en el caso de tenerproblemas con este tipo de algoritmia.

    Existen diferentes proyectos basados en el codigo de fusion de datos de Ardupilot. Elproyecto pertenece a una comunidad aun mayor llamada DIYDrones (Do It Yourself Drones)[15] orientada al desarrollo de UAVs a pequena escala basados, sobretodo, en aeroplanos.

    Por ultimo existen diferentes proyectos orientados al mismo fin que no son tan signifi-cativos, en algunos casos porque son clones de los anteriores o basados en ellos, y en otrosporque se trata de desarrollos cerrados tanto en hardware como software [39], aunque sondignos de mencion al tener disponible informacion util de alguna manera para este PFC.

    Entre ellos esta Quaduino [45], un proyecto personal de UAV cuadrimotor que toma comobase el software de Ardupilot. Tambien UAVP [34] un proyecto aleman dirigido a conseguirun mikrokopter de codigo abierto basado en plataformas hardware propias y soluciones desensores diferentes. Tambien MiKuadricoptero [16], un proyecto open source espanol conmotivaciones didacticas que comenzo en tiempo a la vez que este PFC y que, aunque final-mente el desarrollo de Mikuadricoptero fue sustancialmente mas lento que el de este PFC,en las primeras fases fue de gran ayuda conocer diferentes maneras de afrontar problemassimilares.

  • 24 CAPITULO 3. ESTUDIO DE ALTERNATIVAS

  • Captulo 4

    Entorno de Desarrollo

    4.1. Arduino

    La primera eleccion importante dentro del proyecto fue la de seleccionar la plataformahardware y el entorno de desarrollo. En primer lugar se debe elegir el microcontrolador y laarquitectura sobre la que desarrollar el software embarcado.

    Existen distintas soluciones muy diferentes unas de otras, desde usar microcontroladorestipo PIC1 con arquitectura RISC2 utilizando directamente lenguaje ensamblador, hasta uti-lizar un computador embebido tipo PC/104 [41] con una arquitectura similar a la de un PCcorriente y usando un lenguaje de alto nivel, pasando por plataformas intermedias basadasen diferentes microcontroladores (ARM3 u otros disenos RISC) con entornos de desarrollopropios, amigables y practicos, como los basados en la plataforma .NET MicroFramework4,o Arduino.

    Tras analizar los proyectos de UAVs similares y comparar las diferentes opciones deplataformas de desarrollo se decidio 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 enhardware y con una amplia comunidad alrededor. Esto posibilita el facil acceso a forosde ayuda tanto de desarrollo software embarcado como de integracion de la platafor-ma con diferentes soluciones hardware, incluyendo integracion con gran cantidad desensores y actuadores.

    En segundo lugar, la existencia de dos o tres proyectos de codigo abierto con objetivoscomunes con este PFC y basados en la plataforma Arduino, siendo el mas importantede ellos ArduPilot. Estos precedentes garantizan la seguridad de que la plataforma esvalida, ademas de proveer una va de comunicacion a traves de la que se puede pedirayuda en caso de ser necesario.

    1Peripheral Interface Controller2Reduced Instruction Set Computer3ARM: Advanced Risc Machines http://es.wikipedia.org/wiki/ARM4.NET Microframework es una plataforma open source .NET para usar en dispositivos de recursos limi-

    tados que incluye versiones reducidas de las principales libreras y utilidades .NET http://www.microsoft.com/en-us/netmf/default.aspx

    25

  • 26 CAPITULO 4. ENTORNO DE DESARROLLO

    Figura 4.1: Plataforma hardware Arduino UNO.

    Por ultimo la familiaridad con el entorno debido a experiencias anteriores con la plata-forma, y el conocimiento de las posibilidades tanto del software como de las interfacesexternas con las que cuenta.

    Arduino es una plataforma muy flexible de hardware/software abierto para el desarrollode proyectos de electronica. Basicamente cuenta con una placa disenada alrededor de un mi-croprocesador ATmega328 de Atmel de 16MHz que cuenta con 14 entradas/salidas digitalesy 6 entradas analogicas, 32 KB de memoria Flash, 1 KB de memoria EEPROM y 2 KB deSRAM.

    Para programar el microprocesador se utiliza un lenguaje de programacion propio (Ar-duino Programming Languaje) basado en Wiring [9] y un entorno de desarrollo (ArduinoDevelopment Environment) basado en Processing [10], [3]. El lenguaje es de tipo estructu-rado con una sintaxis similar a la utilizada por el lenguaje Java. El entorno de desarrollopermite desplegar el codigo facilmente a traves de una interfaz USB que conecta con la placaArduino.

    Entre las ventajas de la placa Arduino se encuentran la disponibilidad de un controladorUART para comunicarse a traves de puerto serie, una interfaz USB para comunicacion conel entorno de desarrollo Arduino, puertos para comunicaciones serie I2C muy utilizado ensensores digitales, soporte de comunicaciones SPI5, soporte de salidas de modulacion porancho de pulsos PWM6, en definitiva grandes posibilidades de integracion con circuitos ydispositivos electronicos.

    Dentro de la plataforma Arduino existen diferentes configuraciones de placas. Aunquetodas cuentan con similares caractersticas principales y son compatibles entre s, se diferen-cian entre ellas por el nivel de integracion y por las capacidades del microprocesador.

    La version estandar de Arduino en la fecha de presentacion de este documento es lallamada Arduino UNO, basada en el micro Atmega328. Con las mismas caractersticas de la

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

    6PWM: Pulse Width Modulation es una tecnica utilizada para control de dispositivos electronicosinerciales, consiste en codificar un voltaje midiendo la longitud de pulsos on/off que se envan. http://en.wikipedia.org/wiki/Pulse-width_modulation

  • 4.1. ARDUINO 27

    Figura 4.2: Placa Arduino Nano, mayor nivel de integracion manteniendo las caractersticasy compatibilidad.

    Figura 4.3: Mini, el mas pequeno de todos los Arduinos.

    Figura 4.4: Plataforma Seeeduino. Basado en Arduino, cuenta con un diseno optimizado ydiferentes mejoras y optimizaciones en las prestaciones.

  • 28 CAPITULO 4. ENTORNO DE DESARROLLO

    Figura 4.5: Entorno de desarrollo Arduino.

    version estandar pero con mayor nivel de integracion aparecen las versiones Arduino Nano,con un tamano aproximado de una tercera parte de la version UNO, y Mini, con un tamanode la mitad del Nano.

    Tambien existe una version UNO que en lugar de usar un microcontrolador con formatoextraible DIP7 usa uno de montaje superficial SMD8. Tambien se puede encontrar unaversion extendida llamada Arduino Mega que cuenta con un micro ATmega2560 con mayormemoria y numero de entradas analogicas/digitales.

    El proyecto Arduino cuenta, a su vez, con bifurcaciones que, tomando como base laplataforma Arduino, han realizado modificaciones en el hardware para dotar al mismo demejoras, tanto en diseno optimizado hardware como en las caractersticas del mismo, mayornumero de entradas/salidas, reguladores de tension, interfaces de comunicaciones, etc.

    Cabe destacar un proyecto alternativo basado en Arduino llamado Seeeduino desarrolladopor la comunidad Seeed Studio [47]. Este proyecto proporciona caractersticas funcionalesextendidas que mejoran el diseno original (diodo zener 3v3 integrado, soporte de mayoramperaje en las salidas, conector mini USB, entrada de potencia tipo JST y conectoresinferiores para integrar la placa en una placa de prototipado).

    7DIP: Dual in-line Package es una forma de encapsulamiento de circuitos integrados donde los pines delcircuito quedan dispuestos en hileras paralelas http://es.wikipedia.org/wiki/Dual_in-line_package

    8SMD: Surface Mount Technology, una forma de encapsulamiento mas compacta donde el circuito se mon-ta directamente en la placa o PCB(Board) http://en.wikipedia.org/wiki/Surface-mount_technology

  • 4.2. PROCESSING 29

    Aunque en el primer prototipo V1 de la plataforma hardware se utilizo una versionanterior del Arduino UNO llamado Arduino Duemilanove, en los dos siguientes prototiposse utilizo un Seeeduino V2.12.

    4.2. Processing

    Una vez seleccionada la plataforma de desarrollo hardware y software embarcado, esnecesario seleccionar el lenguaje y entorno de desarrollo para la estacion de tierra (GCS).

    Para el desarrollo del software de GCS las posibilidades eran aun mayores, ya que dichosoftware se ejecuta en una plataforma PC (un ordenador portatil), por lo que se poda haberseleccionado cualquier lenguaje de alto nivel.

    Dados los requisitos de la interfaz grafica de la estacion en tierra, el lenguaje deba facilitarel dibujado de graficos 3D/2D. Aunque casi todos los lenguajes se integran facilmente conlas APIs9 de representacion de graficos 3D/2D como OpenGL o DirectX, se decidio usarProcessing [10] dada su especial compatibilidad con la plataforma Arduino.

    Processing es un lenguaje y entorno de programacion de codigo abierto para el desarrollode aplicaciones graficas interactivas y proyectos multimedia basado en bocetos o sketches. Alestar basado en Java puede heredar todas las funcionalidades del mismo as como extendersey usar todo tipo de libreras ya creadas para dicho lenguaje.

    Ademas provee una interfaz de programacion para la visualizacion de graficos muy in-tuitiva y con soporte de OpenGL. Los desarrolladores de Arduino tomaron como modelo ellenguaje y el entorno de desarrollo de Processing PDE (Processing Development Environ-ment), por lo que la integracion de proyectos software/hardware Arduino con aplicacionesProcessing es muy completa. Una consecuencia de esta complicidad es la unificacion de lasintaxis de ambos lenguajes. Aunque uno tome como base Java (Processing) y otro Wirin-g/C (Arduino) el formato y estructura de los ficheros de codigo fuente es muy similar, porlo que la curva de aprendizaje disminuye considerablemente.

    Tanto Processing como Arduino cuentan con un modelo de ejecucion basado en un pla-nificador cclico. La manera de programar en ambos lenguajes es a traves de sketches. Unsketch no es mas que un codigo estructurado en dos metodos principales.

    El primer metodo es el procedimiento de setup o inicializacion, que se ejecutara una solavez al comienzo de la ejecucion del programa y antes que cualquier otro. Sirve para inicializarlas diferentes variables, estructuras, libreras o aquello que sea necesario. Tanto en Arduinocomo en Processing este procedimiento esta instrumentalizado en la funcion setup().

    El otro metodo se ejecutara de manera cclica. En el caso de Arduino toma el nombre deloop(), mientras que en Processing es void draw(). Aunque estos metodos se ejecuten una vezen cada ciclo, el disenador puede utilizar las diferentes estructuras de control para definirlos periodos de ejecucion que desee, implementando un completo planificador que seleccioneel codigo a ejecutar en cada ciclo.

    En el caso de Arduino, el metodo loop() hace de punto de entrada a la ejecucion, pudiendoestructurar la misma en diferentes metodos y funciones, teniendo en cuenta que el paradigmade programacion es estructurado, y que la memoria y velocidad de procesado son limitados.

    9Application Programming Interface

  • 30 CAPITULO 4. ENTORNO DE DESARROLLO

    Figura 4.6: Entorno de desarrollo Processing.

    Por esta ultima razon en algunos casos se ha preferido una codificacion optimizada y eficientefrente a un codigo legible (eleccion de estructuras de control, dominio de las variables, etc.).

    Por otro lado Processing permite cierta flexibilidad a la hora de programar. Se puedeutilizar el lenguaje para implementar codigo similar al scripting pero sin ser interpretado.Tambien se puede utilizar toda la potencia del paradigma orientado a objetos que facilitaJava. En este caso al no tener problemas de memoria o velocidad de ejecucion tan impor-tantes como el caso de Arduino, se ha preferido usar siempre un enfoque orientado a objetossiguiendo los preceptos de abstraccion, encapsulacion y modularidad. Conceptos que se hanaprovechado especialmente a la hora de desarrollar elementos graficos flexibles que puedanser instanciados varias veces, y la composicion de elementos graficos complejos a partir deelementos simples.

  • Captulo 5

    Analisis

    Antes de entrar en el detalle del desarrollo es necesario realizar un pequeno analisisdel problema a resolver. Ya que el objeto del proyecto es desarrollar un vehculo aereo notripulado, en primer lugar cabe preguntarse como hacer que el vehculo sea capaz de elevarse,y cuales son los mecanismos disponibles para controlar el vehculo.

    5.1. Principios de Sustentacion y Movimiento

    La configuracion de cuatro motores en los extremos de una cruz, que le confieren lacaracterstica de despegue y aterrizaje vertical, tambien hace que el vehculo no se apoye enplanos aerodinamicos fijos para lograr el empuje necesario para elevarse, tal y como sucedeen los vehculos con configuracion de aeroplanos.

    Para elevar el modelo es necesario conseguir un empuje hacia abajo cuyo resultado seauna fuerza inercial hacia arriba que venza la fuerza de la gravedad elevando as el vehculo.Dicho empuje es generado por el rozamiento de los planos de las helices con el aire debidoal giro.

    Cada helice esta formada por dos palas, cuya forma es tal que el plano de cada pala noes paralelo al plano XY de la horizontal, sino que se encuentran giradas formando un angulocon la horizontal. De esta manera, al girar la helice se ejerce un empuje sobre el aire en doscomponentes por cada pala, donde una de ellas sera vertical. El sentido del giro de la helicese elige de manera que la componente vertical sea hacia abajo. El angulo de una pala es elinverso del de la contraria para que ambos empujes tengan el mismo sentido. El resultadoes una fuerza inercial hacia arriba sobre todo el conjunto 5.1.

    Sin embargo, no es la unica componente generada, el empuje del plano de la helice contrael aire es perpendicular al plano de cada pala, por lo que existe una componente horizontalque sigue el sentido del giro de las palas. Estos empujes resultan en una fuerza inercialen el sentido contrario al giro de cada pala. Cada helice esta formada por dos palas queforman angulos contrarios con el plano, por esta razon la componente horizontal inercialen cada pala esta formada por el mismo vector pero con sentidos contrarios. Esto hace quelas componentes lineales se anulen, pero aparece un momento en sentido contrario al girode la helice tal y como se muestra en 5.1. Al sumar todas las fuerzas ejercidas queda unaresultante vertical hacia arriba y un momento en el sentido contrario al giro de la helice.

    Con un solo motor el vehculo se elevara, pero tambien girara sobre el eje del motor

    31

  • 32 CAPITULO 5. ANALISIS

    Figura 5.1: Diagrama de descomposicion de las distintas fuerzas, as como la fuerza inercialresultante y el momento angular resultante.

    Figura 5.2: Inerciales y momentos resultantes: Se pueden ver las inerciales y momentos queaporta cada helice al conjunto.

  • 5.1. PRINCIPIOS DE SUSTENTACION Y MOVIMIENTO 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 enparalelo separados por una distancia, y sentidos contrarios entre s, los momentos debidosal giro de cada motor se superpondran. Anulandose el momento total sobre el conjunto delvehculo (suponiendo misma velocidad de giro en ambas helices).

    Sin embargo, para permitir al vehculo moverse con los diferentes grados de libertad consolo dos motores sera necesario contar con la capacidad de controlar el angulo que forma elplano que se abstrae del giro de las helices respecto a la horizontal. Inclinando dichos planosla inercial resultante, antes vertical, ahora tendra otras componentes, y jugando con dichascomponentes se conseguira el movimiento en las diferentes direcciones.

    Controlar los angulos que forman helices y horizontal es complicado ya que la mecanicadebe permitir el giro independiente de cada bloque motor. Mientras que anadiendo dosmotores mas al conjunto y jugando con las potencias suministradas a cada motor, se puedenconseguir las diferentes resultantes que hacen que el vehculo se mueva con los grados delibertad deseados. En la figura 5.2 aparecen los momentos e inerciales para cuatro motores.

    Para facilitar el control y simplificar el modelo teorico de componentes, lo ideal es situarlos motores de manera que los planos de las helices sean los mismos y paralelos al planohorizontal, formando los vertices de un cuadrado, situando los dos motores que giran en elmismo sentido en los vertices de la diagonal del cuadrado.

    De esta manera, para elevar el vehculo tan solo es necesario aplicar la misma fuerza an-gular a cada helice, as las diferentes componentes horizontales quedaran anuladas, ademasdel momento angular del conjunto 5.3, quedando tan solo la fuerza inercial vertical haciaarriba que hara que el vehculo se elevase.

    En la figura 5.4 se muestran los diferentes angulos de movimiento y los ejes de giro paracada tipo de movimiento, que se describiran detalladamente a continuacion.

  • 34 CAPITULO 5. ANALISIS

    Figura 5.4: Relacion de angulos pitch, roll y yaw.

    5.1.1. Pitch

    Si consideramos uno de los lados del cuadrado que forman los motores como el frentedel vehculo y trazamos una lnea recta perpendicular a dicho lado que cruce el plano delvehculo, estaramos definiendo el eje de cabeceo. Se llama angulo de cabeceo o pitch alangulo que forma dicho eje con el plano horizontal de referencia.

    Cuando el angulo pitch es positivo el vehculo se encuentra inclinado hacia atras, demanera que el frente o cabeza del vehculo mira hacia arriba, de igual manera, cuando esnegativo el frente del vehculo mirara hacia abajo. As, cuando el vehculo esta completa-mente horizontal el angulo de pitch sera 0, y si el vehculo se encuentra perpendicular a lahorizontal el pitch sera 90 o -90 dependiendo de la orientacion del mismo.

    Figura 5.5: Para ganar angulo de pitch aumenta el empuje de los motores frontales respectoal resto, de manera que aparece un desplazamiento horizontal asociado.

  • 5.1. PRINCIPIOS DE SUSTENTACION Y MOVIMIENTO 35

    Figura 5.6: Para que el vehculo se incline ganando roll, aumenta la potencia de los motoreslaterales respecto al resto, como consecuencia aparece un desplazamiento lateral asociado.

    Para avanzar en una determinada direccion, la tecnica utilizada por este tipo de vehculosaereos consiste en desequilibrar el mismo, de manera que la resultante inercial tenga unacomponente horizontal en la direccion deseada, tal y como se muestra en la figura 5.5.

    Los dos motores que quedan en los extremos del lado del cuadrado que hemos denominadofrente son los dos motores frontales. Si se proporciona mayor velocidad angular a dichosmotores se producira un mayor empuje del frente del vehculo, haciendo que el vehculocomience a girar sobre s mismo ganando angulo de pitch.

    Al girar el modelo sobre s mismo se genera una componente horizontal en el empujeque permitira moverse hacia atras a todo el conjunto. Las velocidades de rotacion de losmotores deben compensarse de modo que el vehculo gire sobre s mismo hasta alcanzar unpitch determinado que sea capaz de mantener.

    Al aumentar la potencia de los motores delanteros es necesario regular la potencia delos traseros para que la componente vertical se mantenga constante y, de esta manera, elvehculo se mantenga estable en la vertical. Al ser el giro de los dos motores delanteroscontrario entre s (al igual que ocurre con los traseros), se anularan los momentos por lo queno existira ningun otro giro.

    Para hacer el vehculo avanzar hacia delante se realiza la misma estrategia pero lograndoun pitch negativo, la cabeza del vehculo mirara hacia abajo.

    5.1.2. Roll

    Si analogamente al eje de pitch se traza un eje perpendicular que atraviesa longitudinal-mente el plano del vehculo se obtendra el eje de alabeo o roll. El angulo formado por dichoeje con el plano horizontal se denomina angulo de alabeo o simplemente roll.

    De la misma manera que en el caso del pitch, se puede lograr movimiento lateral si seaumenta la velocidad de giro de dos motores de un mismo lateral de forma que se logre un

  • 36 CAPITULO 5. ANALISIS

    Figura 5.7: Esquema de giro Yaw. Para que el vehculo gire sobre s mismo se aumenta lapotencia por igual a una de las parejas de motores que giran en el mismo sentido respectoal 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 figura 5.6.

    En cualquiera de los casos (pitch o roll), se podra lograr que el modelo girara sobres mismo completamente aplicando la suficiente diferencia de potencia en los motores de dosextremos. Sin embargo, este giro completo vendra acompanado siempre por un movimientode traslacion ya que el empuje de todos los motores tiene el mismo sentido (dado por lageometra de las helices). Aunque esta traslacion en los giros puede ser corregida una vezalcanzada la posicion deseada.

    5.1.3. Yaw

    El giro sobre s mismo del vehculo mientras se mantiene en el plano horizontal (pitch yroll nulos) se denomina guinada o yaw. Para lograr este tipo de giro el plano del vehculopermanece 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 estableca siempre la misma velocidad angulara pares de motores con sentidos de giro contrarios para mantener el momento total nulo.Sin embargo, en la figura 5.7 se puede ver como si se da diferente potencia a motores congiros contrarios aparece un momento angular que hace girar sobre s mismo el vehculo.

    Este desequilibrio del momento angular no afecta a las componentes lineales debido aque se proporciona la misma velocidad angular por pares de motores que giran en el mismosentido y que se encuentran situados en la misma diagonal.

    Para girar en un sentido u otro tan solo hay que elegir adecuadamente los pares demotores a potenciar, de manera que el momento tenga un sentido u otro.

  • Captulo 6

    Plataforma Hardware

    En este captulo se describira el diseno e implementacion de la plataforma hardware,incluyendo la integracion hardware, as como las dificultades encontradas y la solucion pro-puesta a cada una de ellas.

    El captulo se divide en tres secciones, una dedicada a la estructura fsica, otra a lossensores y la ultima al diseno de la placa que conforma la unidad central. Dentro de cadaseccion se diferenciara entre los tres prototipos resultantes de cada incremento realizadodefiniendo los avances entre cada uno de ellos.

    6.1. Estructura Fsica

    La estructura basica o chasis del vehculo es parte fundamental del proyecto ya que deella depende la correccion de las asunciones realizadas respecto al control del modelo.

    Tal y como se ha descrito en el captulo de analisis, el vehculo estara equipado con4 motores montados en una estructura que permita mantener los motores equidistantes.Ademas dicha estructura debe permitir montar una unidad central que ocupa espacio al estarformada por una unidad de procesamiento, todos los sensores, las bateras, los controladoresde los motores, incluso la antena de comunicaciones, ademas del cableado que permite lainterconexion de todos los elementos.

    Para la estructura principal existen diferentes alternativas, desde construirla en maderade balsa mezclada con diferentes materiales livianos, hasta usar varillas de fibra de carbono.

    Sin embargo, existen multitud de proyectos de multicopteros que permiten adquirir partedel chasis por separado, como Mikrokopter, por lo que se decidio no perder demasiado tiempoen la construccion del chasis y se opto por comprar un chasis basico de Mikrokopter.

    Dicho chasis esta formado por cuatro varillas de aluminio que se unen en una crucetacentral. En dicho chasis se pueden montar los motores en los extremos. La distancia elegidaentre motores fue de 50 cm que se corresponde con la distancia entre motores de los modelosmas grandes de Mikrokopter o Aeroquad.

    Los motores elegidos fueron unos HackerStyle Outrunner 20-20L. Estos motores sin es-cobillas son capaces de girar a 1050 rpm (revoluciones por minuto) por Voltio y precisanunos 15 Amperios de media (con picos de 19 A), alimentados a traves de controladores

    37

  • 38 CAPITULO 6. PLATAFORMA HARDWARE

    Figura 6.1: Chasis basico de Mikrokopter

    Figura 6.2: Conjunto de motor con helice APC de 4.7 x 10

    o variadores electronicos de velocidad ESC comunmente utilizados en radio control y quefuesen capaces de soportar dicho amperaje. Estos motores se escogieron tras un analisis delas diferentes alternativas teniendo en cuenta el peso, potencia, amperaje y tasa de giro porvoltio (en el Apendice 12 se puede consultar la comparativa).

    Junto con los motores se estudiaron las helices, seleccionando unas helices de 4.7 x 10de la marca APC, elegidas por su rendimiento de empuje