Evaluación de sensores para la transición de ambiente exterior interior de una plataforma quadrotor para búsqueda y rescate

Texto completo

(1)PONTIFICIA UNIVERSIDAD CATÓLICA DE CHILE ESCUELA DE INGENIERÍA. EVALUACIÓN DE SENSORES PARA LA TRANSICIÓN DE AMBIENTE EXTERIOR-INTERIOR DE UNA PLATAFORMA QUADROTOR PARA BÚSQUEDA Y RESCATE. JUAN ANDRÉS MORA RAMÍREZ. Tesis para optar al grado de Magı́ster en Ciencias de la Ingenierı́a. Profesor Supervisor: MIGUEL TORRES TORRITI. Santiago de Chile, Abril 2014 c MMXIII, J UAN A NDR ÉS M ORA R AM ÍREZ.

(2) PONTIFICIA UNIVERSIDAD CATÓLICA DE CHILE ESCUELA DE INGENIERÍA. EVALUACIÓN DE SENSORES PARA LA TRANSICIÓN DE AMBIENTE EXTERIOR-INTERIOR DE UNA PLATAFORMA QUADROTOR PARA BÚSQUEDA Y RESCATE. JUAN ANDRÉS MORA RAMÍREZ. Tesis presentada a la Comisión integrada por los profesores: MIGUEL TORRES TORRITI ÁLVARO SOTO ARRIAZA FERNANDO AUAT CHEEIN JUAN DE DIOS RIVERA AGÜERO Para completar las exigencias del grado de Magı́ster en Ciencias de la Ingenierı́a. Santiago de Chile, Abril 2014 c MMXIII, J UAN A NDR ÉS M ORA R AM ÍREZ.

(3) A mi madre..

(4) AGRADECIMIENTOS. Agradezco la ayuda y el conocimiento entregados por el Profesor Miguel Torres durante la investigación plasmada en este documento. Le doy también las gracias a los miembros de la comisión revisora por sus contribuciones a este trabajo. Se agradece también el apoyo del proyecto Fondap 2011 No. 15110017, Centro Nacional de Investigación para la Gestión Integrada de Desastres Naturales. Agradezco especialmente a Jorge Reyes por su apoyo a lo largo de la investigación. Sin su esfuerzo este trabajo no hubiese sido posible. Finalmente agradezco a mi familia y amigos por el constante ánimo en los momentos más necesarios.. IV.

(5) ÍNDICE GENERAL. AGRADECIMIENTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. IV. ÍNDICE GENERAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. V. ÍNDICE DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. IX. ÍNDICE DE TABLAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. XI. RESUMEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. XII. ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. XIII. INTRODUCCION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1. 1.1. Descripción del Problema . . . . . . . . . . . . . . . . . . . . . . . . . .. 1. 1.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2. 1.3. Métodos Existentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2. Desventajas de los enfoques existentes . . . . . . . . . . . . . . . . .. 4. 1.4. Resumen de Contribuciones . . . . . . . . . . . . . . . . . . . . . . . .. 5. 1.5. Organización de la Tesis . . . . . . . . . . . . . . . . . . . . . . . . . .. 5. MARCO TEORICO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 7. 2.1. Modelo Dinámico del Quadrotor . . . . . . . . . . . . . . . . . . . . . .. 7. 2.2. Filtro de Luenberger . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 10. 2.3. Control de Posición . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 11. 2.4. ROS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 13. IMPLEMENTACION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 15. Descripción del Hardware Asctec . . . . . . . . . . . . . . . . . . . . . .. 15. 3.1.1. Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 15. 3.1.2. Procesador de Bajo Nivel. . . . . . . . . . . . . . . . . . . . . . . .. 16. 3.1.3. Procesador de alto nivel . . . . . . . . . . . . . . . . . . . . . . . .. 16. 3.1.4. Atomboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 16. 1.. 1.3.1. 2.. 3.. 3.1. V.

(6) Hardware Adicional . . . . . . . . . . . . . . . . . . . . . . . . . .. 17. Comunicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 19. 3.2.1. Comunicación interna . . . . . . . . . . . . . . . . . . . . . . . . .. 19. 3.2.2. Comunicación externa . . . . . . . . . . . . . . . . . . . . . . . . .. 20. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 22. 3.3.1. Control y fusión de datos . . . . . . . . . . . . . . . . . . . . . . . .. 22. 3.3.2. Medición GPS de Desplazamiento y Posición . . . . . . . . . . . . .. 23. 3.3.3. Medición Visual de Desplazamiento y Posición . . . . . . . . . . . .. 26. Parámetros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 30. 3.4.1. Observador de Luenberger . . . . . . . . . . . . . . . . . . . . . . .. 30. 3.4.2. Control de Posición . . . . . . . . . . . . . . . . . . . . . . . . . .. 30. 3.4.3. Odometrı́a Visual . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 31. METODOLOGIA DE PRUEBAS . . . . . . . . . . . . . . . . . . . . . . . .. 33. 4.1. Pruebas del sensor GPS . . . . . . . . . . . . . . . . . . . . . . . . . . .. 33. 4.2. Pruebas del sensor Kinect . . . . . . . . . . . . . . . . . . . . . . . . . .. 34. RESTULADOS EXPERIMENTALES . . . . . . . . . . . . . . . . . . . . .. 37. 5.0.1. Resumen de Resultados . . . . . . . . . . . . . . . . . . . . . . . .. 37. 5.0.2. Resultados odometrı́a GPS . . . . . . . . . . . . . . . . . . . . . . .. 38. 5.0.3. Resultados Odometrı́a Kinect . . . . . . . . . . . . . . . . . . . . .. 40. CONCLUSIONES Y TRABAJO FUTURO . . . . . . . . . . . . . . . . . . .. 49. 6.1. Discusión y resultados . . . . . . . . . . . . . . . . . . . . . . . . . . .. 49. 6.2. Trabajo futuro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 52. BIBLIOGRAFÍA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 53. ANEXOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 57. PERDIDA DE SENAL GPS . . . . . . . . . . . . . . . . . . . . . . . . . .. 58. . . . . . . . . . . . . . . . . . . . . . . . . . . .. 58. Detección del problema . . . . . . . . . . . . . . . . . . . . . . . .. 58. 3.1.5 3.2. 3.3. 3.4. 4.. 5.. 6.. A.. A.1. Pérdida de señal GPS. A.1.1. VI.

(7) Soluciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 59. B.. CONFIGURACION WIFI . . . . . . . . . . . . . . . . . . . . . . . . . . .. 61. C.. INSTALACION UBUNTU . . . . . . . . . . . . . . . . . . . . . . . . . . .. 63. C.1. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 63. C.2. Detalles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 63. C.3. Procedimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 63. CODIGO ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 73. D.1. Código nodo odom to posewithcovstamp . . . . . . . . . . . . . . . . .. 73. D.2. Código nodo odom to posewithcovstamp2. . . . . . . . . . . . . . . . .. 76. D.3. Código nodo kinect to posewithcovstamp . . . . . . . . . . . . . . . . .. 79. ROS Y OTROS AVANCES . . . . . . . . . . . . . . . . . . . . . . . . . . .. 83. asctec drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 83. E.1.1. asctec msgs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 84. E.1.2. asctec autopilot . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 84. E.1.3. asctec proc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 85. E.1.4. asctec mon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 85. E.2. rviz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 85. E.3. Comunicación Serial . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 87. E.3.1. Protocolo de Comunicación . . . . . . . . . . . . . . . . . . . . . .. 87. E.3.2. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 89. E.3.3. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 90. Teleoperación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 92. asctec teleop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 92. CODIGO BASICO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 94. F.1. main.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 94. F.2. Serial.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 95. F.3. definitions.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102. A.1.2. D.. E.. E.1. E.4. E.4.1 F.. VII.

(8) F.4. Serial.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105. G.. CODIGO RVIZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107. H.. CODIGO ASCTEC TELEOP. I.. J.. . . . . . . . . . . . . . . . . . . . . . . . . . 112. H.1. asctec key.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112. H.2. drivers control.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116. H.3. mav control.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127. H.4. drivers control.launch . . . . . . . . . . . . . . . . . . . . . . . . . . . 132. H.5. mav control.lauch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133. ANEXO GRAFICOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 I.1. Resultados medición de posiciń GPS . . . . . . . . . . . . . . . . . . . . 134. I.2. Resultados medición de posición visual . . . . . . . . . . . . . . . . . . . 137. ANEXO VIDEOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 J.1. Estimación vuelo manual GPS . . . . . . . . . . . . . . . . . . . . . . . 140. J.2. Control GPS mayor ganancia . . . . . . . . . . . . . . . . . . . . . . . . 140. J.3. Estimación vuelo manual Kinect . . . . . . . . . . . . . . . . . . . . . . 140. J.4. Control Kinect 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140. J.5. Control Kinect 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140. J.6. Control Kinect menor ganancia 1 . . . . . . . . . . . . . . . . . . . . . . 140. J.7. Control Kinect menor ganancia 2 . . . . . . . . . . . . . . . . . . . . . . 140. J.8. Control Kinect mayor ganancia 1 . . . . . . . . . . . . . . . . . . . . . . 141. J.9. Control Kinect mayor ganancia 2 . . . . . . . . . . . . . . . . . . . . . . 141. VIII.

(9) ÍNDICE DE FIGURAS. 1.1.. Plataforma Asctec Pelican . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1. 2.1.. Marco de referencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 8. 2.2.. Algoritmo de Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 12. 3.1.. Esquema LLP-HLP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 17. 3.2.. Jaula de Faraday . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 18. 3.3.. Plataforma con Kinect . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 19. 3.4.. Puerto serial HLP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 20. 3.5.. Conexión HLP-Atomboard . . . . . . . . . . . . . . . . . . . . . . . . . .. 20. 3.6.. Interacción nodos GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 26. 3.7.. Interacción nodos Kinect . . . . . . . . . . . . . . . . . . . . . . . . . . .. 27. 3.8.. Algoritmo de Odometrı́a Visual . . . . . . . . . . . . . . . . . . . . . . . .. 28. 4.1.. Ambiente de pruebas GPS . . . . . . . . . . . . . . . . . . . . . . . . . . .. 34. 4.2.. Espacio de pruebas Kinect. . . . . . . . . . . . . . . . . . . . . . . . . . .. 35. 4.3.. Ambiente de pruebas Kinect. . . . . . . . . . . . . . . . . . . . . . . . . .. 36. 5.1.. Vuelo manual GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 39. 5.2.. Control GPS mayor ganancia . . . . . . . . . . . . . . . . . . . . . . . . .. 40. 5.3.. Vuelo manual Kinect . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 42. 5.4.. Altura vuelo manual Kinect . . . . . . . . . . . . . . . . . . . . . . . . . .. 43. 5.5.. Control Kinect 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 44. 5.6.. Control Kinect 1 Altura . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 44. 5.7.. Control Kinect 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 45. 5.8.. Control Kinect 2 Altura . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 46. 5.9.. Control Kinect menor ganancia 1 . . . . . . . . . . . . . . . . . . . . . . .. 47 IX.

(10) 5.10. Control Kinect menor ganancia 2 . . . . . . . . . . . . . . . . . . . . . . .. 47. 5.11. Control Kinect mayor ganancia 1 . . . . . . . . . . . . . . . . . . . . . . .. 48. 5.12. Control Kinect mayor ganancia 2 . . . . . . . . . . . . . . . . . . . . . . .. 48. E.1. Interfaz asctec mon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 86. E.2. Gráfico 3D vuelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 87. I.1.. Gráfico XY GPS estático . . . . . . . . . . . . . . . . . . . . . . . . . . . 134. I.2.. Altura GPS estático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135. I.3.. Trayectorı́a Odometrı́a GPS . . . . . . . . . . . . . . . . . . . . . . . . . . 135. I.4.. Altura Odometrı́a GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136. I.5.. Comparación a y GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136. I.6.. Trayectoria con odometrı́a Kinect en PC . . . . . . . . . . . . . . . . . . . 137. I.7.. Altura de la trayectoria con odometrı́a Kinect en PC . . . . . . . . . . . . . 137. I.8.. Trayectoria con odometrı́a Kinect sin giro . . . . . . . . . . . . . . . . . . . 138. I.9.. Altura de la trayectoria con odometrı́a Kinect sin giro. . . . . . . . . . . . . 138. I.10. Trayectoria con odometrı́a Kinect con giro . . . . . . . . . . . . . . . . . . 139 I.11. Altura algoritmo Kinect con giro . . . . . . . . . . . . . . . . . . . . . . . 139. X.

(11) ÍNDICE DE TABLAS. 2.1.. Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 9. 2.2.. Constantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 9. 3.1.. Comparación de sensores de profundidad.. . . . . . . . . . . . . . . . . . .. 18. 3.2.. Parámetros del modelo de referencia. . . . . . . . . . . . . . . . . . . . . .. 30. 3.3.. Parámetros control PID ejes X e Y. . . . . . . . . . . . . . . . . . . . . . .. 31. 3.4.. Parámetros control PID eje Z. . . . . . . . . . . . . . . . . . . . . . . . . .. 31. 3.5.. Parámetros de la odometrı́a visual. . . . . . . . . . . . . . . . . . . . . . .. 32. 5.1.. Resultados de la medición de posición GPS. . . . . . . . . . . . . . . . . .. 37. 5.2.. Resultados de la medición de posición visual. . . . . . . . . . . . . . . . . .. 38. XI.

(12) RESUMEN. En esta tesis se presentan nuestros avances para lograr una transición de espacios exteriores a interiores de una plataforma quadrotor. Los quadrotors son plataformas aéreas ágiles, lo que las hace idóneas para la exploración de terrenos desconocidos y peligrosos. Las contribuciones de esta tesis se dividen en dos áreas principales. Primero, la investigación en torno al quadrotor AscTec Pelican, detallando su funcionamiento, el hardware y el software utilizado. Segundo, la evaluación de dos sensores, GPS y Kinect, los cuales se postulan como los mejores candidatos para la transición indoor-outdoor, utilizando técnicas de fusión de datos de alta velocidad y el framework ROS. A partir de esta investigación se demuestra que el GPS equipado no es apto para la estabilización de la plataforma, mientras que los algoritmos de odometrı́a visual basados en el Kinect tienen una frecuencia muy baja como para lograr estabilidad.. Palabras Claves: quadrotor, kinect, odometrı́a, exterior, interior. XII.

(13) ABSTRACT. In this thesis we present our achievements towards a robust indoor-outdoor transition using a quadrotor platform. Quadrotors are agile flying platforms, this makes them the perfect candidates for the task of exploring dangerous areas. We divide the contributions of this thesis in two main points. First, the research of the AscTec Pelican quadrotor platform, explaining the hardware and software in detail. Second, we study two sensors, a GPS and a Kinect RGBD camera, which we believe are the best option to achieve an indoor-outdoor transition, using a high-frequency filter for data fusion and the Robot Operating System (ROS) framework. Our work shows that the GPS equipped is not capable of stabilizing the platform, while the visual odometry algorithms need a higher frequency in order to achieve stability.. Keywords: quadrotor, kinect, odometry, indoor, outdoor XIII.

(14) 1. INTRODUCCION. 1.1 Descripción del Problema El trabajo con plataformas aéreas ha sido extensivamente estudiado resultando en la aparición de distintos diseños comerciales disponibles para varios niveles, desde aficionados hasta investigación avanzada, como se ve en el trabajo de Kendoul (2012). Esta tesis presenta el resultado del trabajo con una plataforma quadrotor Pelican fabricada por Ascending Technologies GmbH, la cual se muestra en la figura 1.1, enfocada principalmente en la investigación.. F IGURA 1.1. Plataforma quadrotor Pelican fabricada por Ascending Techonologies.. El trabajo realizado consta de tres partes: Comprensión y funcionamiento general del quadrotor Pelican de Asctec. Implementación de un filtro y sistema de control aprovechando las ventajas del framework ROS. Integración de dos sensores (GPS y Kinect) con la plataforma y la evaluación de su odometrı́a como propuesta para una transición de ambientes exteriores a interiores. 1.

(15) El principal objetivo de esta tesis es estudiar dos métodos propuestos para la estabilización de la plataforma, uno en ambientes interiores y otro en ambientes exteriores. En relación con este objetivo, se propone también presentar un documento que permita entender el funcionamiento de la plataforma en detalle, tanto en lo que respecta al hardware especı́fico, como tambien el software utilizado. Para lograr la estabilización de la plataforma en los ambientes interiores se propone como solución el uso de un sensor Kinect, mientras que para la estabilización de en ambientes exteriores se propone el uso de un GPS equipado sobre la plataforma. Considerando la combinación de ambos sensores se estima que la plataforma logrará un vuelo robusto en distintos ambientes, obteniéndose un primer paso para realizar la transición indoors-outdoors. 1.2 Motivación Los quadrotors son equipos de vuelo ligero, por lo que pueden ingresar en zonas de difı́cil acceso terrestre. Adicionalmente, son capaces de maniobrar en zonas reducidas donde sus contrapartes aéreas no son capaces. Por estas razones son buenos candidatos para la exploración de zonas peligrosas para el ingreso humano, como por ejemplo: túneles, derrumbes, zonas con peligro de radioactividad, etc. En una situación real, la plataforma no puede ser ubicada en el interior de estas zonas, sino que debe ser capaz de ingresar por su cuenta y navegar en el interior de forma autónoma. Con este concepto en mente, el enfoque de esta investigación es en dos métodos de vuelo: uno que permita el control en áreas abiertas y otro que permita el control en espacios cerrados, apuntando a una futura transición entre ambos. 1.3 Métodos Existentes El problema de estimación de posición y control de plataformas quadrotors ha sido previamente estudiado utilizando distintos enfoques. Las alternativas de los autores dependen principalmente de los sensores utilizados, el ambiente (interior o exterior) y los algoritmos implementados. Se presenta a continuación un breve resumen de las alternativas más relevantes. 2.

(16) Para la localización de plataformas en ambientes abiertos la solución actual más popular se basa en el uso de sensores georreferenciados, en especı́fico, el GPS. Existen otras alternativas, como por ejemplo, la odometrı́a en base a un sistema monocular o un sistema estéreo. Un ejemplo del caso monocular se ve en el trabajo de Weiss et al. (2013). El caso de un sistema estéreo fue presentado por Garcı́a Carrillo, Dzul López, Lozano, y Pégard (2012). Para los ambientes cerrados, existen diversas alternativas que tienen ventajas y desventajas. Existe la posibilidad de usar sistemas de cámaras, al igual que en los ambientes outdoors. Dryanovski, Valenti, y Xiao (2013), entre otros, presentan la alternativa de usar sensores láser que permiten la ejecución de algoritmos de SLAM. La alternativa más novedosa es el uso de sensores Kinect, que entregan una imagen que incluye datos de profundidad, como lo muestra la investigación de Huang, Bachrach, y Roy (2011). También existen alternativas en lo que respecta al lugar donde se realiza el procesamiento. Autores como Bachrach et al. (2012) han optado por transmitir los datos desde la plataforma a una estación base, donde se ejecuta un algoritmo y luego se transmiten los datos hacia la plataforma nuevamente. La alternativa a esto es realizar todo el procesamiento en la plataforma y ocupar una estación de apoyo para iniciar-detener el algoritmo y capturar datos. Esta última es la alternativa que se utilizará ya que es lo que más se asemeja a una situación real. Otros autores que han utilizado esta aproximación son Huang et al. (2011) y Achtelik, Achtelik, Weiss, y Siegwart (2011). Dentro de las alternativas de algoritmos existe una gran variedad de elecciones. La opción más popular para la fusión de datos de la estimación de posición son los filtros de Kalman. Para el control de la plataforma existen desde las alternativas más simples, como el control PID, hasta opciones más complejas como los modelos MPC (Abdolhosseini, Zhang, y Rabbath (2013)). En lo que respecta a la transición exterior-interior el trabajo más relevante es el presentado por Shen y Michael (2013), donde explora la transición entre GPS y láser en la navegación desde ambientes abiertos hacia el interior de un edificio, y los desafı́os para. 3.

(17) lograr una estimación de estado correcta. La diferencia con nuestro trabajo radica en los sensores y el software utilizado, como se explica a continuación. Los avances realizados en esta tesis toman como base principalmente el trabajo presentado en Achtelik, Achtelik, et al. (2011), en donde el autor utiliza la misma plataforma en conjunto con el framework ROS, pero a diferencia de esta investigación, utiliza una cámara monocular para la odometrı́a visual, mientras que en este trabajo se utilizará un sensor Kinect en conjunto con el GPS disponible en la plataforma. 1.3.1 Desventajas de los enfoques existentes La principal desventaja de la mayorı́a de los enfoques existentes es que se limitan a un solo tipo de ambiente para el desarrollo de sus algoritmos, lo que no les permite ser útiles en el caso de que una transición sea necesaria. El uso de solo GPS no permite el ingreso al interior de construcciones, o la navegación en lugares donde existen edificios en los alrededores. Por otro lado, el uso de únicamente sensores Kinect no permite navegar en el exterior ni en espacios demasiado abiertos, ya que estos sensores tienen un rango de alcance corto y no logran detectar profundidad en espacios muy iluminados por el sol. Las cámaras pueden ser una solución en ambos tipos de ambientes, pero sus principales desventajas son el alto nivel de procesamiento, y el bajo nivel de textura que se encuentra al interior de construcciones, lo que no permite una buena odometrı́a (Huang et al. (2011)). En lo que respecta al trabajo de Shen y Michael (2013), la principal desventaja se encuentra en sus elecciones de hardware y software. Con respecto al hardware, el uso de scanners permite una buena detección de los objetos en el ambiente, pero suelen ser más pesados y costosos que el Kinect. El software que utiliza no es abierto y no se encuentra basado en ROS, lo que dificulta su desarrollo y desecha todas las ventajas del framework. El trabajo presentado por Achtelik, Achtelik, et al. (2011) permite la navegación en ambos tipos de ambientes utilizando una cámara monocular y aprovecha las ventajas de ROS. El principal problema de este enfoque es la baja robustez de este sensor, presentando los problemas mencionados anteriormente para las cámaras monoculares. 4.

(18) 1.4 Resumen de Contribuciones Las principales contribuciones de esta tesis se resumen a continuación: La evaluación de dos sensores, GPS y Kinect, utilizando el algoritmo propuesto por Achtelik, Achtelik, et al. (2011) para la estimación de posición y control de la plataforma, implementado con ROS. La detección de problemas especı́ficos del hardware y las soluciones implementadas. La publicación de código e interfaces abiertas que muestran el funcionamiento de los algoritmos y facilitan su uso. La generación de un documento público que detalla el funcionamiento y procedimientos necesarios en la plataforma, tanto de software como de hardware, con información que no se encontraba previamente disponible en forma pública. 1.5 Organización de la Tesis A continuación la tesis se organiza de la siguiente forma: En el capı́tulo 2 se describen los algoritmos utilizados. En el capı́tulo 3 se entregan los detalles de la plataforma, tanto en hardware como software. En el capı́tulo 4 se definen los experimentos por realizar, y sus resultados se exponen en el capı́tulo 5. Finalmente las conclusiones de la tesis se entregan en el capı́tulo 6. Se incluyen anexos como información adicional de la plataforma y respaldo de los avances logrados. En el anexo A se describe en detalle el problema de la señal GPS. En el anexo B se dan los detalles del acceso WIFI de la plataforma. Se entrega un manual para lograr la configuración de todo el software de la plataforma en el anexo C. El código utilizado en la investigación se publica en el anexo D. En el anexo E se muestran paquetes adicionales de ROS estudiados y otros avances en términos de comunicación. Todo el código usado para graficar y las interfaces desarrolladas se publican en los anexos G y H. El anexo I entrega los gráficos de los experimentos resumidos en las tablas 5.1 y 5.2. 5.

(19) de la sección 5. Los videos de los experimentos que son utilizados en la investigación se encuentran en el anexo J.. 6.

(20) 2. MARCO TEORICO. En esta sección se presentan los antecedentes preliminares que fundamentan esta tesis. En la sección 2.1 se muestran las ecuaciones del modelo dinámico del quadrotor. En la sección 2.2 se detalla el filtro implementado para la estimación de estado y fusión sensorial. Los detalles sobre el lazo de control de la plataforma se presentan en la sección 2.3. Finalmente se entregan los fundamentos del software ROS en la sección 2.4. 2.1 Modelo Dinámico del Quadrotor A continuación se presenta el modelo dinámico de las plataformas tipo quadrotor. La derivación de estas ecuaciones en detalle se encuentra en el trabajo de Bresciani (2008). En el mismo trabajo se pueden encontrar los cálculos de coeficientes aerodinámicos y momentos de inercia. El modelo se resume en las siguientes ecuaciones:. U1 m U1 (− cos ψ sin φ + sin ψ sin θ cos φ) m U1 −g + (cos θ cos φ) m IY Y − IZZ JT P U2 qr − qΩ + IXX IXX IXX IZZ − IXX JT P U3 pr + pΩ + IY Y IY Y IY Y IXX − IY Y U4 pq + IZZ IZZ. Ẍ = (sin ψ sin φ + cos ψ sin θ cos φ). (2.1). Ÿ. (2.2). =. Z̈ = ṗ = q̇ = q̇ =. (2.3) (2.4) (2.5) (2.6) (2.7). 7.

(21) donde Ui , i = 1.,4 y Ω están definidos por las velocidades de las hélices según las siguientes ecuaciones: U1 = b(Ω21 + Ω22 + Ω23 + Ω24 ). (2.8). U2 = lb(−Ω22 + Ω24 ). (2.9). U3 = lb(−Ω21 + Ω23 ). (2.10). U4 = d(−Ω21 + Ω22 − Ω23 + Ω24 ). (2.11). Ω = −Ω1 + Ω2 − Ω3 + Ω4 .. (2.12) (2.13). Las ecuaciones de la aceleración son expresadas con respecto a un marco fijo global, mientras que las aceleraciones angulares son expresadas con respecto a un eje fijo en el cuerpo. Estos ejes se muestran en la figura 2.1.. F IGURA 2.1. Ubicación de los marcos de referencia y sus ejes.. La descripción de las variables y constantes utilizadas se muestran en las tablas 2.1 y 2.2, respectivamente.. 8.

(22) TABLA 2.1. Variables Sı́mbolo Descripción Ẍ. Aceleración linear del quadrotor en el eje x0 con respecto al marco global.. Ÿ. Aceleración linear del quadrotor en el eje y0 con respecto al marco global.. Z̈. Aceleración linear del quadrotor en el eje z0 con respecto al marco global.. p. Velocidad angular del quadrotor alrededor del eje xB con respecto al marco local.. q. Velocidad angular del quadrotor alrededor del eje yB con respecto al marco local.. r. Velocidad angular del quadrotor alrededor del eje zB con respecto al marco local.. ṗ. Aceleración angular del quadrotor alrededor del eje xB con respecto al marco local.. q̇. Aceleración angular del quadrotor alrededor del eje yB con respecto al marco local.. ṙ. Aceleración angular del quadrotor alrededor del eje zB con respecto al marco local.. θ. Pitch. φ. Roll. ψ. Yaw. U1. Empuje vertical (thrust). U2. Torque de roll. U3. Torque de pitch. U4. Torque de yaw. Ωi. Velocidad de los propulsores (i = 1 frontal, i = 2 derecho, i = 3 trasero, i = 4 izquierdo TABLA 2.2. Constantes. Sı́mbolo Unidad. Descripción. b. N s2. d. N ms2. Coeficiente de resistencia del aire. g. ms−2. Aceleración de gravedad. m. kg. Masa del quadrotor. l. m. Distancia del centro del quadrotor al centro del propulsor. IXX. N ms2. Momento de inercia en torno al eje X. IY Y. N ms2. Momento de inercia en torno al eje Y. IZZ. N ms2. Momento de inercia en torno al eje Z. JT P. N ms2. Momento de inercia rotacional total en torno al eje de los propulsores. Factor de empuje. 9.

(23) El control de atitud utilizando el modelo de la plataforma se encuentra implementado en el procesador de bajo nivel (LLP, por su traducción Low-Level Processor), por lo que la implementación del filtro se centra en la estimación de posición en base a las aceleraciones lineales. 2.2 Filtro de Luenberger Se utiliza el filtro de Luenberger presentado por Narendra y Annaswamy (1990) para lograr una fusión a 1 kHz entre los datos de los acelerómetros e IMU y los sensores externos (GPS y Kinect en nuestro caso), con el objetivo de obtener una estimación de posición. Este filtro se explica en detalle por Achtelik, Achtelik, et al. (2011). Los inputs del filtro son las aceleraciones provenientes del LLP con una frecuencia de 1 kHz y las medidas de posición y orientación absolutas, en nuestro caso del GPS o del Kinect, con una frecuencia entre 5 y 2 Hz. Este filtro se asume desacoplado para los tres ejes X, Y, Z y sus cálculos son realizados con respecto a un eje de referencia global. A continuación se describe el filtro para el eje X, siendo los otros ejes análogos. El estado del sistema x, el input u y la medición y se definen como: h. x = p x v x bx. iT. iT h h iT , u = ax , y = pm,x .. (2.14). Donde px es la posición, vx la velocidad, bx el sesgo de la aceleración, ax el input de aceleración y pm,x la posición medida por el sensor. Considerando que la velocidad horizontal máxima del quadrotor Pelican es de 3 m/s, el hecho de que el filtro funcione a 1 kHz se traduce en que entre cada medición puede existir como máximo un error de 3 mm. Esto es un error que se considera como imperceptible, por lo que el filtro se modela como uno de. 10.

(24) tiempo continuo. Las ecuaciones dinámicas del sistema son: p̂˙x = v̂x + L1 (pm,x − p̂m,x ). (2.15). v̂˙ x = b̂x + L2 (pm,x − p̂m,x ) + ax. (2.16). ˙ b̂x = L3 (pm,x − p̂m,x ). (2.17) (2.18). Estas ecuaciones pueden ser ordenadas como: x̂˙ = Ax̂ + L(y − ŷ) + Bu con:. (2.19).   0 1 0   h iT h iT   A = 0 0 1 , B = 0 1 0 , L = L1 L2 L3   0 0 0. . La ecuación de medición es ŷ = H x̂. (2.20). con: h i H= 1 0 0 . El error se define como e = x − x̂ y satisface la ecuación: ė = (A − LH)e.. (2.21). 2.3 Control de Posición Para el control de posición se utiliza el concepto de inversión dinámica no-lineal. Esta aproximación, presentada por Isidori (1995), establece que se puede transformar un sistema no lineal en un sistema lineal equivalente sin el uso de simplificaciones, obteniendo una transformación del estado exacta. La implementación en el procesador de alto nivel (HLP, por su nombre en ingles High-Level Processor) es detallada por Achtelik, Achtelik, et al. (2011). Su esquema general se muestra en la figura 2.2.. 11.

(25) F IGURA 2.2. Algoritmo de control, sub-ı́ndice 0 indica coordenadas con respecto a un eje global, sub-ı́ndice B con respecto a la plataforma.. El control de posición posee una estructura en cascada. A partir de la plataforma y sus sensores se obtienen los datos del LLP que luego se fusionan con un sensor de posición externo, proceso que se explica en detalle en la sección anterior. Con esto se obtiene la posición y velocidad estimada. Esto se compara con los datos de un modelo de referencia en un controlador de error para cada eje en el HLP. Ası́ se obtienen los controles necesarios en la plataforma para lograr la posición deseada. A través de la inversión se transforman los controles en los ángulos y el empuje deseado, los cuales se entregan como input al control de atitud del LLP. Este finalmente entrega como output las aceleraciones a cada uno de los motores.. 12.

(26) Las ecuaciones obtenidas de la inversión dinámica no-lineal para el torque (T ), el ángulo roll (Φ) y el ángulo pitch (Θ) son: T =m·. q. a2x + a2y + (az − g)2. (2.22). may T ax Θ = arctan az − ω Φ = arctan. (2.23) (2.24). Con estas ecuaciones se pueden transformar los controles ν = [ax ay az ], que representan las aceleraciones con respecto al marco global, en los controles del sistema Φ, Θ, T. Debido a que los controles son definidos como la segunda derivada de los comandos de posición pc , la trayectoria comandada debe ser suave para que exista su segunda derivada. Con esto en consideración, el modelo de referencia utilizado para generar las trayectorias de referencia pR satisface: p̈R = ω02 · (pc − pR ) − 2ζω0 · ṗR .. (2.25). Usando este modelo, el controlador de error diseñado es: Z ν = p̈R + (ṗR − ṗ) · kd + (pR − p) · kp +. (pR − p) · ki ,. (2.26). donde p es la posición y ṗ es la velocidad obtenidas del filtro. kp , kd , ki son las ganancias proporcionales, derivativas e integrales del controlador de error. 2.4 ROS ROS (Robot Operating System) es un sistema operativo para robots de código abierto presentado por Quigley, Gerkey, Conley, y Faust (2009). Los pilares de su filosofı́a de desarrollo son: Peer-to-peer, en el sentido de que puede ejecutarse simultáneamente en distintos dispositivos capaces de interactuar entre ellos.. 13.

(27) Tools-based, lo que significa que los procesos son separados en grupos pequeños de herramientas, logrando un esquema modular. Multi-lenguaje, permitiendo el uso de C++ y Python, entre otros. Thin, concepto que apunta a que los drivers y algoritmos no dependan de ROS. Idealmente, se deben crear ejecutables modulares que expongan las funcionalidades de las librerias a ROS sin mezclarse con el código original. Gratis y Open-Source. Los paquetes son la base del funcionamiento de ROS. Estos paquetes al ejecutarse pueden crear nodos que realizan distintas tareas. Por ejemplo, puede existir un nodo que lea los datos de un láser, otro que controle la velocidad de las ruedas y otro que exponga los datos al usuario. Los nodos tienen la capacidad de publicar mensajes, que son simplemente una estructura de datos. Los mensajes son manejados con un sistema de publicación/subscripción. Esto significa que los nodos envı́an un mensaje publicándolo a un cierto tema. Los nodos que estén interesados en ese tipo de mensajes se subscriben al tema correspondiente para recibirlos. Cabe destacar que los nodos pueden ejecutarse en distintas máquinas e interactuar con otros siempre que se encuentren en la misma red.. 14.

(28) 3. IMPLEMENTACION. En este capı́tulo se entregan los detalles de la plataforma Asctec y el software utilizado. En la sección 3.1 se entregan todos los detalles sobre el hardware de la plataforma y su funcionamiento, junto con las modificaciones realizadas para los experimentos. En la sección 3.2 se detalla la comunicación interna y externa de la plataforma. Para concluı́r el capı́tulo, en la sección 3.3, se dan los detalles de los principales paquetes implementados en la plataforma y las modificaciones realizadas a estos. 3.1 Descripción del Hardware Asctec La plataforma utilizada es el quadrotor modelo Pelican diseñado por Ascending Technologies (AscTec), el cual puede ser observado en la figura 1.1. Su base es el marco mecánico X-CSM, hecho por partes livianas de magnesio cortado por láser. La distribución de poder es manejada por una placa que se alimenta de baterı́as LiPo a 12.4V y entrega salidas a 12V y 5V reguladas. Se utilizan cuatro motores brushless X-BL-52 fabricados por HACKER Motors Germany, los cuales fueron especialmente diseñados para esta plataforma. Estos se utilizan con los controladores X-BLDC los cuales fueron especı́ficamente optimizados para este tipo de motores. A continuación se detallan los principales componentes involucrados en la tesis con mayor profundidad. 3.1.1 Sensores Para determinar la orientación de la plataforma se cuenta con un magnetómetro AscTec 3D-MAG, mientras que para determinar la posición se ubica un módulo GPS en la parte superior. Para la determinación de la atitud se utiliza una unidad IMU (Inertial Measurement Unit) incorporada en una placa montada en la plataforma.. 15.

(29) 3.1.2 Procesador de Bajo Nivel El procesador de bajo nivel (LLP por sus siglas en inglés: Low-Level Processor) es un microcontrolador ARM7 de 32 bit funcionando a 60 MHz. Sus tareas comprenden todo el manejo de hardware, fusionando los datos de los distintos sensores y entregando sus mediciones a una tasa aproximada de 1 KHz. Este procesador tiene programadas rutinas de control para el quadrotor, permitiendo distintos modos de vuelo maniobrados por el control marca Futaba: modo manual, control de altura y control de posición. Cuando el control mediante comunicación serial es activado, el procesador permite recibir comandos de control (yaw, pitch, roll, thrust), calculando mediante un algoritmo propio la velocidad necesaria en los motores. Los algoritmos que implementan estas rutinas no son públicos y no pueden ser modificados por el usuario. 3.1.3 Procesador de alto nivel El procesador de alto nivel (HLP por sus siglas en inglés: High-Level Processor) esta basado en el mismo hardware, un microcontrolador ARM7 de 32 bits funcionando a 60 MHz. En este microcontrolador se puede implementar código hecho por los usuarios para ejecución a alta velocidad. 3.1.4 Atomboard El Asctec Atomboard es un computador embebido basado en la tecnologı́a Intel Atom de 1.6 GHz. Cuenta con 1 GB de RAM y utiliza una tarjeta de memoria micro SD de 8 GB. El Atomboard tiene acceso a redes inalámbricas a través de la tarjeta WiFi miniPCI Express 802.11n. Entre sus periféricos cuenta con puertos mini USB que permiten el uso de mouse y teclado, entre otros, y un conector para una pantalla display LSVD.. 16.

(30) F IGURA 3.1. Arquitectua de comunicación entre LLP, HLP y sensores. Todos los sensores se comunican con el LLP a excepción del GPS. La comunicación entre el LLP y el HLP es a 1 kHz. Imagen original de Achtelik, Stumpf, et al. (2011).. 3.1.5 Hardware Adicional a) Módulo WLAN USB El módulo es utilizado para la comunicación WIFI como substituto de la tarjeta miniPCI Express WLAN debido a la interferencia que esta causa en el GPS. Es ubicado debajo de uno de los ESC y conectado a un puerto miniUSB del Atomboard. Detalles sobre la detección y solución del problema de interferencia con la señal GPS se pueden encontrar en el anexo A. b) Jaula de Faraday Debido a los problemas de pérdida de señal del GPS en espacios abiertos, se agrega una jaula de Faraday alrededor de la electrónica de la plataforma con el objetivo de aislarla y reducir posibles interferencias que esta induce en el receptor GPS. Los detalles de esta solución también se encuentran en el anexo A. En la figura 3.2 se observa la plataforma con la jaula.. 17.

(31) F IGURA 3.2. Plataforma con la jaula de Faraday.. c) Sensor de profundidad Se ubica un Asus Xtion PRO Live en la parte superior de la plataforma para ser utilizado como sensor de profundidad. Este modelo de sensor presenta una serie de ventajas frente al Microsoft Kinect: es más pequeño, más liviano y no requiere alimentación externa. Los detalles se muestran en la tabla 3.1. TABLA 3.1. Comparación de sensores de profundidad.. Microsoft Kinect. Asus Xtion PRO Live. Tamaño [cm]. 30.5 x 7.6 x 6.3. 17.8 x 5 x 3.8. Peso [kg]. 1.4. 0.23. Alimentación. Externa. USB. Rango de operación [cm]. 80 - 400. 50 - 920. Resolución [pixeles]. 640x480. 640x480(30Hz) 320x240(60Hz). Frecuencia [Hz]. 30. 30 / 60. El Kinect fue colocado a una altura de 10 cm sobre la base de la plataforma, centrado y alineado con el origen del sistema de referencia del quadrotor, como se muestra en la. 18.

(32) figura 3.3. Al ser los movimientos de rotación muy pequeños en todos los ejes excepto en eje Z (yaw), se considera que el Kinect se encuentra en el mismo origen que la plataforma. La posición del Kinect se basa en el trabajo de Bouffard (2010), donde ubica el sensor en la parte superior de un quadrotor Pelican sin afectar la estabilidad de la plataforma y logra capturar claramente los alrededores.. F IGURA 3.3. Plataforma con el Kinect montado.. 3.2 Comunicación 3.2.1 Comunicación interna La comunicación interna entre el LLP y el HLP es una conexión serial de 1 kHz implementada por hardware. Mientras que el Atomboard puede comunicarse con el HLP o el LLP mediante una conexión serial utilizando un cable entre los puertos correspondientes. La conexión utilizada es entre el HLP y el Atomboard. El puerto serial correspondiente al HLP y el cable de conexión se muestran en la figura 3.4. La conexión con el Atomboard se muestra en la figura 3.5.. 19.

(33) F IGURA 3.4. Conexión del HLP a través del puerto serial.. F IGURA 3.5. Conexión del HLP y el Atomboard.. 3.2.2 Comunicación externa a) Comunicación Serial El LLP tiene protocolos que definen una interfaz para la comunicación con el usuario. Esta comunicación es de tipo serial, teniendo la posibilidad de ser realizada con un cable adaptador USB-serial o de forma inalámbrica, utilizando un módulo Xbee, en ambos casos con una tasa de transferencia de 57600 Baud. 20.

(34) El protocolo define un sistema de polling en el cual se envı́an paquetes con estructuras definidas para solicitar información del sistema o para enviar instrucciones a la plataforma. La plataforma posee un Xbee fijado en la parte inferior de una de las alas del marco y otro Xbee con adaptador Serial-MiniUSB, con el cable MiniUSB-USB correspondiente para la conexión a través de un computador. También existe la posibilidad de conectar el quadrotor directo al computador utilizando un adaptador miniUSB-Serial el cual se conecta directo al LLP. La principal ventaja de utilizar el par Xbee como medio de comunicación es que no se requiere de equipamiento adicional, a diferencia de otras alternativas, como por ejemplo, configurar una red inalámbrica. La principal limitación es la cantidad de datos que puede transferir, limitándose en la práctica a uno o dos topics de ROS como máximo. b) Comunicación WIFI La comunicación WIFI se realiza a través de la tarjeta miniPCI Express y permite la comunicación directa con el Atomboard. Esta comunicación permite tasas de transferencia más altas que la alternativa serial, pero depende de la presencia de una red WLAN, y por lo tanto las caracterı́sticas de esta red definen el rango y robustez de la comunicación. Para poder utilizar este tipo de comunicación se configura un router D-Link DI-524 Airplus G 802.11g/2.4GHz. Los detalles de la configuración pueden ser encontrados en el anexo B y la configuración del quadrotor en el anexo C. Se utilizaron baterı́as con un cable que se adaptó para su conexión con el router, de forma que la red WLAN sea portátil, aunque sin conexión a Internet en estos casos. Se utilizó este tipo de comunicación para los experimentos debido a que permite la recolección de una mayor cantidad de datos a una alta tasa en comparación con la alternativa serial.. 21.

(35) 3.3 Software El software utilizado se divide en tres partes principales presentadas a continuación. La primera parte se refiere al trabajo desarrollado por Achtelik, Achtelik, et al. (2011), agrupado en el stack asctec mav framework. La segunda y tercera parte entregan detalles de los paquetes utilizados para el posicionamiento GPS y la odometrı́a visual Kinect, respectivamente, y los detalles de su implementación. Más detalles sobre otros paquetes ROS estudiados y otros avances en lo que respecta a software se pueden encontrar en el anexo E. Los paquetes ROS se ejecutan en el Atomboard que originalmente se entrega con Ubuntu 10.04 y ROS en su versión Electric. Este fue actualizado a Ubuntu 12.04 con ROS Fuerte. Las instrucciones para obtener una imagen nueva en la tarjeta micro SD se pueden encontrar en el anexo C. 3.3.1 Control y fusión de datos El algoritmo de control y fusión de datos presentado en la sección 2 fue implementado utilizando el sistema ROS como parte del trabajo de Achtelik, Achtelik, et al. (2011) bajo el nombre de asctec mav framework. Las principales caracterı́sticas de este framework son: Tasa de transmisión de datos configurable hasta 921600 Baud mediante comunicación WIFI. Tasa de publicación de paquetes configurable para obtener los datos del HLP (no hay sistema de polling). Permite distintos modos de vuelo cuyos comandos son retransmitidos al LLP. Algoritmo de control de posición funcionando a 1kHz. Fusión de datos de la IMU a 1kHz con datos de posición externos que permiten utilizar el control de posición con fuentes que entregan datos a baja frecuencia.. 22.

(36) Los paquetes que componen este stack son asctec hl comm, asctec hl firmware y asctec hl interface. El primero de los paquetes define los mensajes utilizados por el stack. El paquete asctec hl firmware entrega una actualización de firmware que debe ser grabada en el HLP para que este ejecute los algoritmos de alta velocidad. El paquete asctec hl interface entrega una interfaz para comunicarse con el HLP. Esta interfaz permite distintos modos de vuelo: de aceleración directa, control de velocidad y control de posición. El control de interés para esta tesis es el control de posición con input externo de mediciones. Como interfaz, este paquete permite acceder mediante ROS a datos de los sensores y algoritmos. Los mensajes publicados en detalle pueden encontrarse en Achtelik (2013). 3.3.2 Medición GPS de Desplazamiento y Posición El proceso de odometrı́a GPS se basa en el sistema de coordenadas UTM (Universal Transverse Mercator). Este sistema divide el plano de la Tierra en 60 zonas y utiliza la proyección cartográfica transversa de Mercator tangente al meridiano correspondiente. La ventaja de utilizar este sistema es que las mediciones entregan un par de coordenadas en metros, en contraste con la convención de latitud-longitud cuya medición no corresponde al sistema métrico. Las coordenadas del sistema UTM corresponden a la distancia con respecto a un punto de referencia de la zona correspondiente. El paquete gps common es utilizado para realizar la transformación latitud-longitud a UTM mediante el nodo utm odometry node. El primer problema encontrado utilizando este nodo es que la medición de odometrı́a se entrega con respecto a un origen fijo en el plano del mundo, por lo que la medición entrega valores altos al momento de procesar y graficar. La segunda dificultad es que la odometrı́a del GPS entrega una posición pero no una orientación. Debido a que el algoritmo requiere de una orientación como input, es necesario obtener estos datos de otra fuente.. 23.

(37) Para solucionar estos problemas se crea el nodo odom to posewithcovstamp. El primer objetivo de este nodo es fijar la ubicación de la plataforma como el origen de la odometrı́a. Para esto espera cuatro mediciones y fija la siguiente medición como el punto de origen, esto debido a que las primeras mediciones del GPS son inexactas. El segundo objetivo de este nodo es obtener la medición de la orientación de la IMU y agregarla al mensaje publicado. Al no tener una medición de la covarianza de estas medidas, se fija en 29 · 10−9 rad2 , según sugiere ROS para sensores IMU (Rockey (2011)).. 24.

(38) A continuación se muestra el algoritmo del nodo. El código completo se encuentra en el anexo D.1. Algoritmo 1: odom to posewithcovstamp Input: Odometrı́a GPS, Orientación IMU Result: Mensaje tipo PoseWithCovarianceStamped Inicialización; Subscripción a mensajes de odometrı́a e IMU; while Nodo en funcionamiento do if Nuevo mensaje IMU then Guardar valores de orientación recibidos; end if Nuevo mensaje odometrı́a then if mensajes recibidos < 5 then Ignorar; end if mensajes recibidos == 5 then Asignar posición como origen; end if mensajes recibidos > 5 then Restar valores de origen a valores recibidos; Agregar al mensaje última orientación recibida de IMU; Asignar covarianza; Publicar mensaje tipo PoseWithCovarianceStamped; end end end Para contrastar la altura calculada por la odometrı́a del GPS con la medición de otro sensor se crea odom to posewithcovstamp2. Este nodo es esencialmente el mismo que el anterior, con la única diferencia que en la medición del eje Z entrega la altura del altı́metro normalizada según la quinta medición. El código se encuentra en el anexo D.2. 25.

(39) Un resumen de la interacción entre los nodos ROS se muestra en la figura 3.6.. F IGURA 3.6. Esquema de la interacción de los nodos en la odometrı́a GPS. XG , YG , ZG representan las coordenadas con respecto a un eje global, mientras que Xr , Yr , Zr representan las coordenadas con respecto al punto inicial de la plataforma. Or representa los ángulos de orientación de la plataforma y Σor su matriz de covarianza.. 3.3.3 Medición Visual de Desplazamiento y Posición El Kinect es leı́do utilizando el paquete openni launch, que entrega los drivers necesarios para obtener la imagen rectificada en formato RGB y con profundidad. El paquete fovis ros es utilizado para traducir estos datos en una odometrı́a visual. La calibración utilizada son los valores por defecto. Los datos de la covarianza de las mediciones no son conocidos por lo que se les asigna un valor de 0.05 según sugiere ROS para experimentos con este tipo de sensores. Existen situaciones en las que no se puede estimar la posición, como por ejemplo cuando no se tienen suficientes inliers. En estos casos, el resultado de la odometrı́a entregado por el algoritmo son ceros. Esto genera saltos de una posición cualquiera al origen. Es evidente que esto tendrı́a consecuencias negativas al ingresarlo como input de posición al algoritmo de vuelo. Para corregir este problema y agregar la matriz de covarianza se crea el nodo kinect to posewithcovstamp. Este nodo esta suscrito a la publicación de odometrı́a, agrega la covarianza y publica el mensaje tipo PoseWithCovarianceStamped necesario para el algoritmo. Adicionalmente guarda el último valor de odometrı́a correcto registrado. En. 26.

(40) caso de que exista error (todas las mediciones son 0), entrega en vez de esta medición una repetición del último valor correcto. El código completo se encuentra en el anexo D.3. La interacción entre los nodos se muestra en la figura 3.7.. F IGURA 3.7. Esquema de la interacción de los nodos en la odometrı́a Kinect. X, Y, Z representan las coordenadas de la odometrı́a directa, mientras que X 0 , Y 0 , Z 0 representan las coordenadas luego de la corrección y Σ la matriz de covarianza de las mediciones.. La odometrı́a utilizada se obtiene del paquete fovis ros que implementa el código presentado por Huang et al. (2011). Un esquema general del algoritmo se muestra en la figura 3.8. El algoritmo consta de seis partes principales se describen brevemente a continuación. a) Pre-procesamiento de la imagen A partir de la imagen en escala de grises, una pirámide gaussiana es generada para encontrar features en niveles más altos. Estos corresponden a objetos más grandes, por lo que tienen mayor probabilidad de repetirse y son más robustos frente a imágenes borrosas generadas por el movimiento. b) Extracción de features Se extraen features de cada nivel de la pirámide utilizando el algoritmo FAST para detección de features de Rosten y Drummond (2006). Cada feature se extrae junto con su profundidad, en caso de no tener este dato, se descarta. El threshold del algoritmo FAST se adapta con un control proporcional simple para alcanzar suficientes features en cada cuadro. Los niveles de la pirámide son divididos en buckets dentro de los cuales se elije un. 27.

(41) F IGURA 3.8. Algoritmo de odometrı́a visual implementado.. subconjunto de features que tengan mayor FAST corner score. El objetivo es lograr una distribución uniforme de los features en la imagen. c) Estimación de rotación inicial La rotación 3D es lo que causa la mayor parte del aparente desplazamiento de features en cuadros sucesivos. En este paso es utilizada la técnica propuesta por Mei, Sibley, Cummins, Newman, y Reid (2009), que propone estimar la rotación inicial minimizando la suma de los errores de pixeles al cuadrado de cuadros submuestreados. Esto es preferido frente a otras alternativas, como por ejemplo, el uso de la IMU, debido a que hace el algoritmo más independiente de la plataforma y sus sensores, mientras se mantiene una precisión razonable. d) Matching de features Un descriptor es asignado a cada feature y se emparejan entre distintos cuadros usando el método de mutual consistency check propuesto por Nister, Naroditsky, y Bergen. 28.

(42) (2004). A estos matches se les asigna un score según la fórmula SAD (sum-of-absolutedifferences) de sus descriptores propuesta por Howard (2008). El match con menor score que se encuentre dentro de la ventana definida por la estimación de rotación inicial se declara como el par. La ubicación de los features en el cuadro nuevo es refinada a nivel de subpixel minimizando la suma de error cuadrático de todos los features. Para esto, el método ESM propuesto por Malis (2004) es usado para resolver el problema de iteración no lineal de mı́nimos cuadrados. e) Detección de inliers Este es otro paso en el que matches incorrectos son descartados. Se ocupa la aproximación de Howard (2008) para generar un gráfico de los matches y descartar outliers basándose en el hecho de que para movimientos de cuerpos rı́gidos se mantienen las distancias, por lo que la distancia euclideana entre features se debe mantener en cuadros distintos. Esto se detalla en las publicaciones de Howard (2008) y Hirschmuller, Innocent, y Garibaldi (2002). f) Estimación de Movimiento El método de orientación absoluta propuesto por Horn (1987) es utilizado para obtener una estimación inicial. Este método minimiza la distancia euclideana entre matches clasificados como inliers. La estimación inicial es refinada minizando el error de reproyección de los features a través del algoritmo para problemas no lineales de mı́nimos cuadrados de Malis (2004). Matches que excedan cierto error de reproyección son descartados del set de inliers y la estimación se refina nuevamente. Finalmente, con el objetivo de reducir drift de baja escala se utiliza lo que es denominado “keyframe technique”. Inicialmente se tiene un cuadro de referencia, y se consideran tres posibilidades:. 29.

(43) Si el movimiento de la cámara relativo al cuadro de referencia se calcula con suficientes inliers, se mantiene el cuadro de referencia. Si no se cumple con el número de inliers, se reemplaza la referencia por el nuevo cuadro. Si la estimación de movimiento con respecto a la referencia falla, se reintenta usando el segundo cuadro más reciente. 3.4 Parámetros 3.4.1 Observador de Luenberger El observador se basa en el uso de una matriz de ganancia L que depende de los polos del sistema. La matriz se calcula ocupando el comando place de MATLAB ubicando los polos en -15, -3 y -0.01 para la posición, velocidad y sesgo de aceleración correspondientemente. Estos valores se basan en el framework de Visual SLAM, PTAM, de Klein y Murray (2007). La matriz resultante para X, Y y Z se muestra a continuación: h iT L = 18,01 45,18 0,45 3.4.2 Control de Posición Los parámetros usados para el modelo de referencia se muestran en la tabla 3.2. Estos parámetros fueron ajustados en base a experimentos prácticos de Achtelik, Achtelik, et al. (2011). TABLA 3.2. Parámetros del modelo de referencia.. Parámetro Valor ω0. 2.5. ζ. 1. Para el control PID original los parámetros de la tabla 3.3 son utilizados para los ejes XB e YB . 30.

(44) TABLA 3.3. Parámetros control PID ejes X e Y.. Parámetro Valor Kp. 12.0. Kd. 5.0. Ki. 2.0. Los parámetros del eje Z se muestran en la tabla 3.4. TABLA 3.4. Parámetros control PID eje Z.. Parámetro Valor Kp. 15.0. Kd. 15.0. Ki. 4.0. 3.4.3 Odometrı́a Visual Los parámetros que se utilizan para la odometrı́a visual se muestran en la tabla 3.5 ordenados según etapa del algoritmo. La sección ROS de la tabla corresponde a los parámetros modificables del paquete fovis ros.. 31.

(45) TABLA 3.5. Parámetros de la odometrı́a visual. Sección. Parámetro. Pre-procesamiento. Gaussian Kernel (σ). Extracción de features Tamaño de buckets Features por bucket Matching. Tamaño del descriptor Área del feature considerada para el descriptor. ROS. Valor 0.85 80x80 pixeles 25 80 bytes 9x9 pixeles. “feature-window-size”. 9. “max-pyramid-level”. 3. “inlier-max-reprojection-error”. 1.5. “clique-inlier-threshold”. 0.1. “min-features-for-estimate”. 10. “max-mean-reprojection-error”. 10. “use-subpixel-refinement”. 1. “feature-search-window”. 25. “target-pixels-per-feature”. 250. “update-target-features-with-refined”. 0. 32.

(46) 4. METODOLOGIA DE PRUEBAS. Las pruebas realizadas para ambos sensores fueron cuatro: Evaluación de la odometrı́a del sensor mientras la plataforma se mantiene estática. Evaluación de la odometrı́a del sensor y estimación de posición en una trayectoria de 7 m: Se avanza 7 m, se da media vuelta y se retrocede 7 m manteniendo la plataforma a una altura constante. Evaluación de la odometrı́a del sensor en un vuelo controlado manualmente, intentando mantener la plataforma en un punto fijo en el plano XY y a una altura lo más constante posible. Evaluación de la odometrı́a, estimación de posición y control del algoritmo en vuelos en los que sólo se envı́a la instrucción de elevarse a una altura determinada. Se experimenta en estos casos variando las ganancias del control. Todas las pruebas de vuelo fueron grabadas y se presentan en conjunto con los datos recopilados en el anexo J. Las pruebas presentan variaciones dependiendo del sensor utilizado. Los detalles de cada una de estas pruebas se explican a continuación. 4.1 Pruebas del sensor GPS El sensor GPS es evaluado con la plataforma en reposo en un espacio abierto, sin la presencia de edificios u otros objetos que puedan bloquear la señal. La trayectoria de 7 m es realizada dos veces: Primero utilizando el GPS para estimar la altura de la plataforma y luego utilizando los datos del altı́metro. Para mostrar el nivel de precisión del GPS, la prueba de vuelo manual solo muestra la odometrı́a del GPS directamente. Finalmente se experimenta aumentando las ganancias kp y kd de los ejes X e Y para estudiar el efecto del sensor GPS en el control.. 33.

(47) F IGURA 4.1. Ambiente de pruebas de vuelo usando GPS.. 4.2 Pruebas del sensor Kinect El sensor Kinect es evaluado con la plataforma en reposo en un espacio cerrado, con iluminación artificial y la presencia de objetos y texturas que permiten una correcta estimación. Se muestra el lugar en la figura 4.2. La trayectoria de 7 m es realizada tres veces en el mismo espacio descrito anteriormente: Primero, se realiza la trayectoria con el Kinect conectado a un computador con un procesador Intel i7 de 2.80 GHz con 4 GB de memoria RAM. Esto permite mostrar las diferencias en la odometrı́a que hace la capacidad computacional de la plataforma. Segundo, se realiza la trayectoria con el Kinect conectado a la plataforma solo avanzando y retrocediendo 7 m (sin dar media vuelta). Finalmente se realiza la misma trayectoria pero dando media vuelta, con el objetivo de mostrar el efecto del giro en la estimación. La siguiente prueba es el vuelo manual utilizando la estimación del Kinect. Se realizan las pruebas de vuelo en un espacio abierto distinto al mostrado anteriormente, pero con las mismas caracterı́sticas generales. El espacio se puede ver en los videos del anexo J correspondientes a cada prueba.. 34.

(48) F IGURA 4.2. Espacio de pruebas Kinect.. Finalmente se experimenta variando las ganancias kp , kd y ki de los ejes X e Y en distintos niveles para ver el efecto sobre el control.. 35.

(49) F IGURA 4.3. Ambiente de pruebas de vuelo Kinect.. 36.

(50) 5. RESULTADOS EXPERIMENTALES. En este capı́tulo se presentan los resultados de los experimentos descritos en la sección anterior. Primero se presenta una tabla que resume los resultados de los experimentos en que la plataforma no se encuentra en vuelo para la medición de posición visual y GPS. Luego se comentan estos resultados más en detalle para cada caso, incluyendo además los experimentos de vuelo. 5.0.1 Resumen de Resultados En la tabla 5.1 se muestran los resultados de los experimentos en que la plataforma no se encuentra en vuelo utilizando la medición de posición GPS. El número de muestras indica las mediciones del sensor, ası́ como también el número de datos obtenidos del filtro de Luenberger. El error en el plano XY (εXY ) que se muestra en la tabla corresponde al error máximo para el caso de la plataforma en reposo, y a la diferencia con respecto a una lı́nea de 7 m desde el origen hasta el punto de retorno en el caso de las trayectorias. Se muestra también el error promedio en el eje Z con respecto al punto inicial (ε̄Z ) y el valor de la mayor variación (εmax Z ). Los gráficos correspondientes a estos experimentos se encuentran en el anexo I. TABLA 5.1. Resultados de la medición de posición GPS.. Muestras Setpoint εXY [m] ε̄Z [m] εmax [m] Z Mediciones Filtro Reposo 506 A→A 2 2.07 6 7m Trayectoria 119 234 A −→ A 1.2 2.42 3.85 7m Trayectoria Altı́metro 138 272 A −→ A 1.1 0.006 0.3 Experimento. En la tabla 5.2 se muestran los resultados del mismo tipo de experimentos para la plataforma Kinect. Los datos mostrados corresponden a las mismas descripciones anteriores. Los gráficos se encuentran en el anexo I.. 37.

(51) TABLA 5.2. Resultados de la medición de posición visual.. Experimento. Muestras Mediciones Filtro Reposo 52 Trayectoria PC 1022 Trayectoria sin giro 73 430 Trayectoria con giro 78 539. Setpoint. εXY [m]. A → A 2,151̇0−6 7m A −→ A 0.2 7m A −→ A 1.1 7m A −→ A -. ε̄Z [m] εmax [m] Z 0 0.38 0.006 0.4. 0 1 0.3 0.6. 5.0.2 Resultados odometrı́a GPS a) Plataforma en reposo La odometrı́a a partir de la información del GPS es muy inexacta, como se puede ver en la figura I.1, la cual muestra 120 segundos de datos en reposo. A pesar de que la plataforma se encuentra en un punto fijo, se puede observar una variación de las mediciones de hasta 2 m en el plano XY. La altura calculada a partir del GPS también varı́a considerablemente, como se observa en la figura I.2. Se observan variaciones de hasta 6 m con la plataforma en reposo. El valor promedio de la altura es -2.07 m. b) Trayectoria utilizando odometrı́a GPS La trayectoria de 7 m se muestra en la figura I.3. Se observa una diagonal de aproximadamente 8.2 m, es decir, se ve cerca de 1 m de error en movimiento. Se destaca además que el output del filtro de Luenberger es muy cercano a las mediciones del GPS. La altura registrada en al trayectoria se ve en la figura I.4. Se puede notar una variación progresiva, alcanzando hasta 3.85 m de error, con un promedio de 2.42 m en el valor detectado por el GPS. Notar el efecto de la fusión de datos del filtro en el número de muestras que se observa, aumentando la frecuencia aproximadamente al doble. Los resultados obtenidos al utilizar el altı́metro para medir la altura de la plataforma en la trayectoria se muestran en la figura I.5. Se puede observar que el error disminuye. 38.

(52) hasta el rango de los 0.3 m máximo, con un valor promedio de altura de 0.006 m. Este nivel de variación no permite estabilizar la plataforma en una altura determinada. c) Resultados en vuelo. F IGURA 5.1. Resultados de la estimación GPS en un vuelo manual. Datos del video J.1.. Al realizar un vuelo manual se obtiene una trayectoria ruidosa que no representa el movimiento real de la plataforma, principalmente debido a los datos del GPS. Estos se muestran en la figura 5.1. El video del vuelo corresponde al anexo J.1. Se observa que a pesar del movimiento de la plataforma, existe un error de al menos 4 m que no corresponde al movimiento real. Al utilizar las ganancias mostradas en la seccion 3.4 no existe respuesta por parte de la plataforma a las mediciones. Debido a esto, la ganancia proporcional se aumenta progresivamente hasta obtener una respuesta. Los valores utilizados son Kp = 24, Kd = 7,5, Ki = 2 para la ganancia proporcional, derivativa e integral, respectivamente, en el plano XY. El resultado se muestra en la figura 5.2. El video del vuelo corresponde al anexo 39.

(53) J.2. Se observa que debido a la estimación errática y con alta variabilidad, la plataforma responde con movimientos bruscos en distintas direcciones y pierde estabilidad. De esta forma se ve que las mediciones del GPS son demasiado imprecisas como para lograr un control correcto de la plataforma.. F IGURA 5.2. Resultados del control GPS al aumentar la ganancia a Kp = 24, Kd = 7,5, Ki = 2. Datos del video J.2.. 5.0.3 Resultados Odometrı́a Kinect a) Plataforma en reposo La posición determinada por la odometrı́a del Kinect al estar en reposo es en promedio X, Y = (−1,1041 · 10−6 , −2,1497 · 10−6 ) con valores máximos de X, Y = (5,302 · 10−5 , 3,9468 · 10−5 ), es decir, prácticamente cero. La altura promedio de la odometrı́a y el filtro de Luenberger presentan valores similares, aproximándose a cero.. 40.

(54) b) Trayectoria usando odometrı́a Kinect La trayectoria que se obtiene al utilizar la odometrı́a del Kinect desde un computador se muestra en la figura I.6. La frecuencia de la odometrı́a es de 26.5 Hz. La diagonal obtenida es de 7.2 m, es decir, aproximadamente 0.2 m de error. La altura determinada por la odometrı́a Kinect utilizando un computador se muestra en la figura I.7. Se acumula progresivamente un error que alcanza 1 m aproximadamente, siendo en promedio 0.38 m. La trayectoria determinada por la plataforma sin girar mientras se ejecuta el filtro de Luenberger se muestra en la figura I.8. La frecuencia de la odometrı́a es en promedio 2 Hz, mientras que el output del filtro de Luenberger se mantiene fijo en 10 Hz. La frecuencia de publicación del output del filtro se mantiene constante para todos los resultados siguientes, recordando que el filtro funciona a 1 kHz. La diagonal es de aproximadamente 6.6 m, lo que implica un error cercano a 0.4 m. Se nota que la principal diferencia con respecto a la medición desde el computador es la frecuencia, la que al disminuir degrada considerablemente la odometrı́a. La altura estimada por la odometrı́a y el filtro de Luenberger se ve en la figura I.9. Se obtiene un error máximo de 0.6 m, siendo en promedio -0.3 m para los datos del Kinect y el output del filtro de Luenberger. La trayectoria determinada por la plataforma dando un giro se muestra en la figura I.10. La frecuencia de la odometrı́a es en promedio 1.5 Hz, mientras que el output del filtro de Luenberger se mantiene fijo en 10 Hz. En este caso no existe diagonal: existe una detección correcta del desplazamiento frontal por 5 m, errando por 2 m la distancia real. El giro no es detectado correctamente, asumiendo 90◦ en vez de 180◦ . Luego se muestra un desplazamiento de 1.2 m en vez de los 7 m de retorno. Estos resultados descartan la posibilidad de implementar giros en las trayectorias actuales. La altura en este caso se muestra en la figura I.11. No se observa mayor error que en los casos anteriores, llegando al nivel máximo de 0.6 m de error, con un promedio de -0.4 m. Este nivel de precisión no permitirı́a estabilizar la plataforma a una altura fija. 41.

(55) c) Resultados en vuelo Los resultados de la estimación del sensor Kinect y del filtro de Luenberger en un vuelo manual se muestran en la figura 5.3. Se recomienda estudiar también el video J.3. La estimación es correcta en escala y sentido del movimiento mientras la plataforma se mantiene en un área de 1 m2 aproximadamente. Se observa también un retardo evidente en la actualización de las mediciones con respecto al movimiento de la plataforma. La frecuencia de actualización de las mediciones del Kinect es aproximadamente 1.6 Hz.. F IGURA 5.3. Resultados de la estimación Kinect en un vuelo manual. Datos del video J.3.. La altura estimada durante este vuelo se muestra en la figura 5.4. La estimación es correcta con cierto grado de error (aproximadamente 0.2 m), sobretodo en los primeros instantes. Los resultados son menos confiables superado el minuto de vuelo, caso en que el error lleva a estimar que la plataforma se encuentra en una altura negativa.. 42.

(56) F IGURA 5.4. Resultados de la estimación Kinect para la altura en un vuelo manual. Datos del video J.3.. Al utilizar las ganancias mostradas en la sección 3.4 se tiene el resultado que se muestra en la figura 5.5 (Se sugiere ver el video J.4). Se nota que la plataforma corrige sus movimientos en el sentido adecuado, actualizando los datos del Kinect con una frecuencia de 2 Hz. Se observa que no es capaz de mantenerse en una zona de aproximadamente 2 m2 . Existen además errores de escala: la plataforma estima que termina su vuelo aproximadamente a 0.1 m de su punto de despegue, mientras que en la realidad este valor fue de un orden de magnitud mayor. La figura 5.6 muestra los resultados de la altura estimada. Esta estimación es correcta, mostrando los momentos en que la plataforma asciende (segundos 19 y 21 en el video J.4), pero no logra detectar el descenso brusco de la plataforma ya que para esta maniobra se desactiva el control. En términos de escala la estimación entrega resultados de 0.2 m, mientras que en la realidad la altura es de aproximadamente 0.4 m. El ascenso a 0.3 m corresponde al golpe de la caı́da, por lo que no se considera como un resultado válido.. 43.

(57) F IGURA 5.5. Resultados del control Kinect con ganancias normales. Se aprecia la lentitud de reacción en el video del anexo J.4.. F IGURA 5.6. Resultados del control Kinect en altura estimada. Datos del video J.4.. 44.

(58) Al realizar el mismo experimento en un ambiente distinto se obtienen resultados similares. Estos se muestran en las figuras 5.7 y 5.8, y el video J.5.. F IGURA 5.7. Resultados del control Kinect con ganancias normales en otro ambiente. Se aprecia la lentitud de reacción en el video del anexo J.5.. Los efectos de disminuir la ganancia se muestran en las figuras 5.9 y 5.10. En el caso de la figura 5.9 solo la ganancia proporcional es menor con un valor de Kp = 6, correspondiente a la mitad del valor original. En el caso de la figura 5.10 las ganancias son Kp = 3, Kd = 2,5, Ki = 2. Se recomienda estudiar los videos adjuntos en el anexo J.6 y J.7. Al disminuir solo la ganancia proporcional (figura 5.9), se ve que existen dos intentos de corrección de la posición (segundo 4 y segundo 6 del video anexo J.6). Esto provoca que luego del segundo intento la corrección sea muy acentuada, con lo que la plataforma adquiere una velocidad horizontal más alta que lo esperado. Esto genera que la plataforma. 45.

(59) F IGURA 5.8. Resultados del control Kinect en altura estimada en otro ambiente. Datos del video J.5.. se aleje demasiado antes de lograr una estimación correcta de su posición y corregirla. La frecuencia de los datos del Kinect en este caso es de 1.8 Hz. En el caso en que se disminuyen todas las ganancias se obtiene una trayectoria de vuelo recta, como se ve en la figura 5.10. Esto es producto de que no existe reacción de parte del control, como se puede ver en detalle en el video anexo J.7. Los efectos de aumentar la ganancia se muestran en las figuras 5.11 y 5.12. En este caso solo la ganancia proporcional es mayor con un valor de Kp = 24, correspondiente al doble del valor original. Se recomienda estudiar los videos adjuntos en el anexo J.8 y J.9. Aumentar la ganancia genera sobreoscilación que luego es capaz de converger a estabilidad, como se observa en ambos casos. Esto no ayuda al control, como se puede ver en el video J.9, ya que al momento de detectar el desplazamiento la reacción es suficientemente brusca como para inestabilizar la plataforma. Esto puede explicarse por la frecuencia de actualización de datos del Kinect, que en este caso es 1.8 Hz. 46.

(60) F IGURA 5.9. Resultados del control Kinect al disminuir la ganancia a Kp = 6. Datos del video J.6.. F IGURA 5.10. Resultados del control Kinect al disminuir la ganancia a Kp = 3, Kd = 2,5, Ki = 2. Datos del video J.7.. 47.

(61) F IGURA 5.11. Resultados del control Kinect al aumentar la ganancia a Kp = 24. Datos del video J.8.. F IGURA 5.12. Resultados del control Kinect al aumentar la ganancia a Kp = 24. Datos del video J.9.. 48.