4. Descripción del sistema - bibing.us.esbibing.us.es/proyectos/abreproy/30213/fichero/Capítulo+4... · módulo de control electrónico de velocidad, ordenador de a bordo o tarjeta

Arquitectura de Fault Tolerance System distribuido entre UAVs

78

4. Descripción del sistema

En este bloque se hace una descripción del sistema, partiendo de describir sus dos componentes: hardware y software. Por un lado, el hardware está comprendido por todos los dispositivos físicos dispuestos en el sistema. Por otro lado el software se diferencia en dos grandes partes, la arquitectura y la algoritmia de detección y corrección de fallos desarrollado por el departamento de Ingeniería de Sistemas y Automática de la Escuela Técnica Superior de Ingeniería de la Universidad de Sevilla.

4.1 Descripción del sistema físico y sus componentes.

El sistema físico que engloba el hardware del sistema de tolerancia de fallos se puede resumir en los siguientes componentes: quadrotor, XBee, Sistema Vicon, Testbed y red de ordenadores.

4.1.1 Quadrotor

Un quadrotor, también llamado helicóptero quadrotor, quadrocopter o quadcopter, es un tipo de aeronave de ala rotatoria o en inglés rotor-craft que emplea cuatro rotores coplanares para generar empuje para la sustentación aerodinámica o hovering y maniobrar. Los quadrotors se clasifican como helicópteros, en contraposición a las aeronaves de ala fija, debido a que su elevación es generada por un conjunto de perfiles acordes de ala giratoria. A diferencia de la mayoría de los helicópteros, los quadrotors suelen utilizar hojas simétricamente inclinadas, las cuales pueden ajustarse como un grupo, es decir, trabajan de forma colectiva, pero no individual, basándose en la posición de la hoja en el disco del rotor llamada «cíclica». El control de movimiento del vehículo se consigue mediante la alteración del terreno de vuelo y / o la tasa de rotación de uno o más discos de rotor, cambiando de ese modo su carga de par y características de empuje / ascensión.

Mecánica


79

Los principales componentes mecánicos necesarios para la construcción son el marco, hélices (ya sea de paso fijo o de paso variable), y los motores eléctricos. Para un mejor rendimiento y algoritmos de control más simples, los motores y las hélices deben ser colocados con la misma distancia entre ellos como se muestra en las figuras de estos. Varios materiales pueden ser utilizados para las diferentes partes, aunque recientemente se han hecho populares materiales compuestos de fibra de carbono debido a su peso ligero y rigidez estructural. [63]

Eléctrica

Los componentes eléctricos necesarios para construir un quadrotor son similares a las necesarias para un helicóptero de radio control moderno. Estos componentes son el módulo de control electrónico de velocidad, ordenador de a bordo o tarjeta controladora, y la batería. Típicamente, también se hace uso de un mando a distancia para permitir la intervención humana. [64]

4.1.2 Control de Vuelo

Cada rotor produce empuje y par de torsión alrededor de su centro de rotación, así como una fuerza de arrastre opuesta a la dirección del vehículo de vuelo. Si todos los rotores están girando a la misma velocidad angular, con los rotores uno y tres girando en sentido horario y los rotores dos y cuatro en sentido antihorario (véase Figura 17), el par aerodinámico, y por lo tanto la aceleración angular alrededor del eje de yaw es exactamente igual a cero, lo que implica que la estabilización de yaw del rotor de los helicópteros convencionales no es necesario en los quadrotors. El yaw es inducido por una mala adaptación del equilibrio en pares aerodinámicos (es decir, mediante la


80

compensación de los comandos de empuje acumulados entre los pares de aspas que giran en sentidos contrarios). [65]

Figura 17: Esquema de los rotores del quadrotor.

Esquema de pares de reacción en cada motor de un quadrotor, debido al giro de los rotores. Los rotores 1 y 3 giran en una dirección, mientras que los rotores 2 y 4 giran en la dirección opuesta, produciendo pares opuestos para el control.

Normalmente, el cuerpo central alberga la batería, el piloto automático y otros dispositivo hardware como el XBee. Dos de los quadrotores utilizados en las instalaciones del Centro Avanzado de Tecnologías Aeroespaciales están ilustrados en la Figura 18.


81

Figura 18: Quadrotors.

Un rotor es la parte rotativa compuesto con palas que se acciona con un motor. En este caso, cada rotor presenta dos palas en una única pieza. [66]


82

Figura 19: Detalle de la electrónica del quadrotor.

Estos quadrotores (Figura 19) son del modelo Hummingbird de AscTec. El Hummingbird está dotado del sistema X-3D-BL ResearchPilot, formado a su vez por una serie de subsistemas como la X-Base (unidad central de control), el ResearchPilot (unidad de sensores) o el módulo X-ACC que añaden distintas funcionalidades. Algunos de estos subsistemas se distinguen en la figura 3.2 c). Cada rotor cuenta con su propio motor y cada motor es controlado independientemente por un X-BLDC. En el manual de Hummingbird se detallan todas las características de los subsistemas. Sin embargo, se van a describir determinados aspectos necesarios en este proyecto:

• En la X-Base se encuentra el interruptor que enciende y apaga el quadrotor. Siempre debe encenderse o apagarse con la emisora encendida. Una breve pulsación es suficiente para activar el quadrotor, mientras que para desactivarlo el interruptor debe mantenerse presionado hasta que el led indicativo se apague. Es importante que el quadrotor no se mueva en absoluto durante la inicialización.

• Si el quadrotor lleva mucho tiempo encendido sin utilizarse puede descalibrarse. Si

ocurriera, el quadrotor debe apagarse y volverse a encender.


83

• Si la temperatura cambia rápidamente, por ejemplo cuando salga de una habitación

con temperatura alta, los ángulos medidos por el sistema X-3D-BL ResearchPilot

podrían no ser totalmente correctos. En este caso, debe esperarse unos minutos a

que los sensores se adapten o cambiar al modo de vuelo HH ya que es más robusto

frente a los cambios de temperatura. Ahora bien, el modo de vuelo utilizado en este

proyecto es el modo X-ACC. El módulo X-ACC permite que el quadrotor sea capaz

de volver a una orientación horizontal por sí mismo.

• Se añaden marcas reflectantes para identificarlo como objeto dentro del sistema Vicon.

• La pegatina naranja se utiliza para orientar ese brazo en la dirección donde el ángulo

Yaw es cero, para una estabilidad mayor en vuelo.

• Se añade un módulo ZigBee, el dispositivo XBee, para permitir la comunicación entre

el quadrotor y el ordenador. Como se muestra en la figura 3.1 y en la figura 3.2 c),

el ordenador también dispone de un XBee. Mediante un interruptor de la emisora se

habilita el control del quadrotor por ordenador. Este trabajo se ha realizado en un

Proyecto Fin de Carrera anterior. [67]

El quadrotor tiene dos ventajas principales respecto a las aeronaves de ala fija para ciertas aplicaciones de UAV (Unmanned Aerial Vehicle). En primer lugar, tiene la capacidad de flotar, y en segundo lugar, es omni direccional, lo que le permite maniobrar libremente en cualquier dirección. Estas capacidades lo hacen una opción popular para el vuelo en interiores.


84

Por último, existe el software X-control que hace posible comunicar directamente las distintas placas del Hummingbird y el ordenador. X-control permite actualizar el firmware y modificar parámetros de control. Por ejemplo, se pueden seleccionar los niveles de tensión de la batería para los cuales se considera como batería llena, casi llena o vacía. También se cuenta con el programa X-3D-BL ResearchPilot Testsoftware, para visualizar los paquetes de datos que transmite el ResearchPilot y mandar comandos. En el proyecto no ha sido necesario hacer uso de estos programas.

4.1.3 XBee

La comunicación entre el quadrotor y el ordenador se realiza de manera inalámbrica mediante módulos ZigBee. El ZigBee utilizado será XBee-PRO® DigiMesh™ 2.4GHz

RF (véase Figura 20).

Figura 20: XBee-PRO.

La conexión del XBee al equipo servidor es por un cable USB pero el extremo que se conecta al XBee tiene que ser tipo X-USB; ya que se utiliza un módulo X-USB para hacer posible la conexión entre el XBee y el ordenador (véase Figura 21).


85

Figura 21: Módulo X-USB.

En el otro lado de la comunicación, el interfaz por el cual se conecta el módulo ZigBee al quadrotor Hummingbird es a través de un enlace serie situado en la placa ResearchPilot (véase Figura 22). [68]

Figura 22: Arquitectura del XBee.


86

.

XBee es el nombre comercial de Digi International para una familia de módulos de radio de factor compatibles entre sí. Las primeras radios XBee se introdujeron bajo la marca MaxStream en 2005 y se basa en el estándar 802.15.4-2003 diseñado para aplicaciones punto a punto y comunicaciones estrella en over-the-air y velocidades de transmisión de 250 kbit / s. [69]

Dos modelos fueron introducidos inicialmente con un costo menor de 1 mW XBee y una mayor potencia de 100 mW XBee-PRO. Desde la presentación inicial se han introducido una serie de nuevas radios XBee y son comercializadas y vendidas bajo la marca Digi. [70]

Una versión de las Xbees llamada Programmable XBee tiene un procesador adicional para código de usuario. El Programable XBee y una nueva versión de superficie de montaje (SMT) de las radios XBee fueron introducidos en 2010. Se peuden encontrar una extensa colección de proyectos XBee con fotos, vídeos, información y documentación en la Galería de proyectos Digi Xbee. La galería se actualiza periódicamente y los proyectos pueden ser presentados en el sitio. [71][72]

Factores de forma, antenas y modos de datos


87

Figura 23: Antenas del XBee.

En la Figura 23 se puede ver un par de radios XBee (Through-Hole con el tipo de antena de cable de látigo).

Los módulos XBee están disponibles en dos factores de forma, through-hole y de montaje en superficie. Todos los XBees (con la excepción de la 868LP XBee) están disponibles en el popular 20-pin through-hole de factor de forma. Algunos módulos XBee también están disponibles en una plataforma de diseño 37-Surface Mount, que es muy popular para aplicaciones de mayor volumen, debido a la reducción de los costes de fabricación de la tecnología SMT.

Los módulos XBee normalmente vienen con varias opciones de antena, incluyendo U.FL, PCB embebido, Wire y RPSMA.

Los XBees pueden funcionar en un modo de datos transparente o en un modo basado en paquetes de interfaz de programación de la aplicación (API). En el modo transparente, los datos entran por el pin Data IN (DIN) que transmite directamente e inalámbricamente a las radios receptoras sin ninguna modificación. Los paquetes entrantes pueden ser dirigidos directamente a un destino (punto a punto) o a varios destinos (estrella). Este modo se utiliza principalmente en los casos en que un protocolo existente no puede tolerar cambios en el formato de datos. Los comandos AT se usan para controlar los ajustes de la radio. En el modo API los datos se envuelve en una estructura de paquetes que permite la configuración de direccionamiento de parámetros, y la retroalimentación de entrega de paquetes, incluida la teledetección y control de E / S digitales y pines de entrada analógica. [70]

XBee Internet Gateway (XIG)

La puerta de enlace de Internet de XBee hace que sea fácil conectar radios XBee a Internet. El XIG se ejecuta en Windows, Macintosh y Linux, así como el Digi ConnectPort serie X. El XIG permite a las radios XBee cargar datos, recibir mensajes de


88

texto y comandos remotos, acceder a los recursos de Internet, como páginas web, bases de datos, redes sociales y usar la nube del dispositivo iDigi. [70]

La tecnología ZigBee se caracteriza por operar en las bandas libres ISM (Industrial,

Scientific & Medical) de 2.4 GHz (16 Canales). Tiene una tasa de transferencia de 250 Kb/s y un rango de cobertura de 10 a 75 metros dependiendo del entorno. A pesar de coexistir en la misma frecuencia con otro tipo de redes como WiFi o Bluetooth su funcionamiento no se ve afectado debido a características propias del estándar IEEE 802.15.4. Cada red ZigBee tiene un identificador de red único, lo que permite que coexistan varias redes en un mismo canal de comunicación sin ningún problema.

Por lo tanto es un protocolo que permite tener un enlace de comunicación con cada quadrotor que está en vuelo sin que se produzcan interferencias por otros ZigBee o por otro tipo de señal. En consecuencia, se cuenta con una pareja de XBee para cada quadrotor5 (uno alojado en él y otro para el ordenador).

4.1.4 Sistema Vicon MX

Vicon MX es una suite de red Vicon MX de cámaras de captura de movimiento y dispositivos que proporcionan datos de captura digital-optica de movimiento en tiempo real y offline. Los elementos clave de una arquitectura Vicon MX incluyen [73]:

• Cámaras

Las cámaras cuentan con múltiples procesadores de alta velocidad que realizan procesamiento de imágenes en tiempo real.


89

Cámara Vicon MX

• Unidades

El puente MX, MX control, Link MX, MX Net, MX Sync, y MX unidades Ultranet que se utilizan para crear una arquitectura distribuida permite personalizar el número de cámaras y dispositivos de terceros.

Panel frontal de MX Bridge


90

Panel trasero de MX Ultranet

• Software

Vicon MX soporta BodyBuilder, Nexus, Vicon iQ, y el software de aplicación de las estaciónes de trabajo software de aplicación.

• Host PC

Vicon MX requiere un PC con un puerto dedicado Gigabit Ethernet para permitir las comunicaciones del sistema (además de cualquier otro puerto de red en el PC). Cualquier captura de movimiento Vicon y análisis software para su uso con Vicon MX está instalado en este PC host. (Los PCs remotos pueden ser utilizados para el software Vicon de terceros.)

• Cables

Los cables MX son los encargados de conectar los componentes del sistema, proporcionando la comunicación Ethernet, señales de sincronización, señales de vídeo, y datos.

• Periféricos


91

Vicon MX se suministra con un kit de calibración que contiene las herramientas requeridas para calibrar con precisión el sistema y un kit de accesorios con suministros para el uso inicial del sistema.

Ejemplo de kit de calibración

• Dispositivos de terceros (opcional)

Vicon MX puede estar integrado con una gama de dispositivos de terceros, incluyendo dispositivos analógicos (por ejemplo, placas de fuerza y equipos EMG), los dispositivos de audio (tales como micrófonos), de vídeo de fuentes externas (por ejemplo, PAL o NTSC grabadoras de cinta de vídeo), y cámaras de vídeo externas (como cámaras DV y vídeo digital DCAM). Tales dispositivos se pueden integrar usando la Ultranet MX. [73]

Basic Motion Capture Architecture

La arquitectura Vicon MX más básica se compone de uno hasta ocho MX cámaras, una Ultranet MX, y el PC host.

Esta arquitectura básica se ilustra en la Figura 24:


92

Figura 24: Arquitectura básica Vicon MX.

Large Camera-Count Arquitectura

Al contar el sistema Vicon con más de ocho cámaras MX, se deberá incluir otras unidades MX Ultranet en la arquitectura Vicon MX. Si el sistema dispone de una unidad de red MX, deberá incluir unidades MX Net adicionales a lo largo de las unidades de enlace MX para conectarlos entre sí.

Esta arquitectura de camera-count se ilustra en la Figura 25:


93

Figura 25: Arquitectura Vicon MX con 40 cámaras y 5 unidades MX Ultranet.

Arquitectura de la aplicación integrada de terceros

Con la tarjeta apropiada instalada en la arquitectura Vicon MX. MX Ultranet puede incluir una sincronización entre la unidad MX y el dispositivo de otro fabricante.

Esta arquitectura de la aplicación integrada de terceros se ilustra en la Figura 26:


94

Figura 26: Arquitectura Vicon MX con MX Control y dispositivos de terceros.

Arquitectura de Cámaras V-series Integrada

Las cámaras soportadas previamente por sistemas Vicon V-Series, deben incluir un puente MX en el MX Vicon [73]. Este enfoque de la arquitectura integrada de las cámaras V-series se ilustra en la Figura 27:


95

Figura 27: Arquitectura Vicon MX con MX Bridge y cámaras V-series.

El sistema Vicon MX es el sistema óptico más avanzado de captura de movimientos disponibles. Sus principales componentes son las cámaras Vicon T20 (figura ), el módulo de hardware de control, llamado MX Giganet (figura ), el software (para analizar y presentar los datos) y el equipo para ejecutar el software (equipo Vicon en la figura ).

El sistema Vicon MX sustituye al GPS (Global Positioning System). El sistema Vicon MX determina la posición de los objetos que se mueven con una precisión milimétrica y muy baja latencia.

La arquitectura del sistema Vicon se representa en la figura . Cada sistema Vicon MX incluye al menos un MX Giganet para proporcionar comunicación de datos con hasta 10 cámaras y otros dispositivos. El MX Giganet también gestiona el flujo de datos del PC que ejecuta el software que se utilizará para analizar los datos. Un sistema Vicon MX instalado cuenta con 20 cámaras por lo que son necesarios dos módulos MX Giganet como se aprecia en la figura 27. Esta característica hace que la arquitectura sea fácilmente escalable.


96

Es interesante conocer que la cámara T20 incluye el sensor CMOS de diseño propio “Vicon Vegas CMOS” que proporciona un obturador real full frame. Las cámaras con obturador son tolerantes a la luz ambiental y a la típica iluminación de laboratorio a fin de aumentar la precisión del sistema. La T20 ofrece un verdadero obturador electrónico de fotograma congelado.

La lente de la cámara capta los rayos infrarrojos que son reflejados ya sea por las marcas reflectantes o por elementos reflectantes indeseados del entorno (el software

Tracker permite eliminarlos). Las marcas reflectantes serán colocadas en aquellos objetos que deseamos captar su movimiento. Como se aprecia en la figura , se añaden estas marcas a los quadrotores.

En cuanto al MX Giganet, incluye 5 puertos Ethernet gigabit para la conexión al PC y a otros dispositivos; y otros 10 puertos Ethernet gigabit para proporcionar energía y comunicación de datos con hasta 10 cámaras.

4.1.4.1 Software del sistema Vicon

El software con el cual se analizan los datos captados por las cámaras está albergado en un PC. El programa Vicon Tracker 1.1.0 es el encargado de calibrar las cámaras, definir los objetos, eliminar reflejos indeseados y establecer el origen de coordenadas entre otras utilidades.

También existe el programa en tiempo real Vicon Nexus aunque no se ha trabajado con él. Nexus permite ver todos los datos en el mismo tiempo en el que están sucediendo.

Con Nexus se puede comprobar la calidad de los datos, almacenarlos y luego se pueden reproducir para comprobarlos.

Ahora se pasa a describir los aspectos más importantes del programa Vicon Tracker, su interfaz de usuario gráfica se expone en la figura


97

Vicon Tracker es una potente solución de seguimiento de objetos que proporciona una exactitud sin precedentes para la integración de datos en aplicaciones 3D. Puede seguir fácilmente 50 objetos únicos de forma simultánea y reconoce los cuerpos rígidos en 2D; por lo tanto, sus datos continuarán incluso si los marcadores se hacen visibles a una sola cámara. Esto se traduce en menos lagunas y datos más fiables.

Vicon Tracker tiene una latencia de 2,5 milisegundos, lo que es hasta 5 veces menos que otros sistemas. Esto reduce los problemas de retroalimentación y así se pueden rastrear objetos en movimiento a gran velocidad.

4.1.5 Testbed

Figura 28: Banco de pruebas


98

El sistema Vicon será integrado en un banco de pruebas de dimensiones 18x18x6 metros construido con una estructura del tipo truss. Las 20 cámaras Vicon T20 estarán situadas por el banco de pruebas de tal forma que visualicen la mayor parte del volumen del banco de pruebas, como se puede observar en la Figura 28. A pesar de tener un número de cámaras considerable aparecen zonas muertas en el banco de pruebas, donde el sistema Vicon pierde la visibilidad del objeto (quadrotor) al entrar en alguna de ellas. Estas zonas muertas están situadas principalmente en la parte inferior y superior de cada una de las columnas que forman el banco de pruebas. Por tanto, los quadrotores no deben maniobrar en las zonas muertas. [66]

En la imagen se muestra parte de una columna del banco de pruebas con su cámara inferior.

Figura 29: Cámara alojada en la estructura truss.


99

Además, por seguridad el banco de pruebas está cubierto por redes evitando que un quadrotor salga del recinto por error.

4.1.6 Red de ordenadores

Hay cuatro equipos involucrados en el sistema, exceptuando la parte de detección y corrección de fallos, que será desarrollada por la Universidad de Sevilla. El equipo donde ha sido desarrollada la arquitectura puede no ser el equipo donde trabaje el sistema.

Sus características son:

• Equipo HLA y TestbedHalWrapper:

- Estación de trabajo HP Z800. - Sistema Operativo Ubuntu Desktop LTS 10.04 64 bits.

• Equipo CamerHalService:

- Estación de trabajo HP Z800. - Sistema Operativo Windows 7 64 bits.

• Equipo Vicon:

- Dell Precision T3500.

- Sistema Operativo Windows XP.

• Equipo Servidor:

- Sistema Operativo Kubuntu 8.04 LTS.

Los equipos se interconectan para formar una red de área local de manera que, el equipo servidor se comunique con el equipo Vicon y los equipos del sitema de tolerancia de fallos. El equipo Vicon y los equipos del sistema de tolerancia de fallos no requieren intercambiar datos. Para ello, se configura un direccionamiento IP estático.


100

4.2 Tecnologías usadas

El sistema software que forma parte del sistema de tolerancia de fallos se dividen en dos partes diferenciadas. Por un lado está la arquitectura del sistema, y por otro lado el programa que se encargara de la detección de fallos y la corrección de estos. Este apartado se centra en la descripción de la arquitectura software del sistema. Esta arquitectura se ha desarrollado en los equipos de desarrollo (Estación de trabajo HP Z800).

4.2.1 Lenguaje de programación y entorno

El presente proyecto se ha desarrollado en el lenguaje C++. El desarrollo se ha llevado a cabo en dos estaciones de trabajo, una de ellas con sistema operativo Ubuntu y otra con sistema operativo Windows 7. Para el desarrollo en Ubuntu, se ha hecho uso del IDE Eclipse, mientras que para el desarrollo en Windows 7 se ha hecho uso del IDE Visual Studio.

Eclipse

La arquitectura software donde se va a enmarcar el sistema de tolerancia de fallos ha sido desarrollado en el entorno de desarrollo Eclipse. Eclipse es un entorno de desarrollo software multilenguaje que comprende un espacio de trabajo base y un sistema extensible de plug-in para personalizar el entorno. Puede ser usado para desarrollar aplicaciones en diferentes plataformas, principalmente en JAVA, aunque en este proyecto se ha usado el lenguaje C++, que aunque tradicionalmente se ha enmarcado en el entorno de desarrollo Visual Studio, se ha elegido Eclipse al ser open

source y por el uso de plug-in para incluir las funcionalidades requeridas, aunque fundamentalmente se debe a que se ha desarrollado en Ubuntu. Para el desarrollo en Windows se ha usado Visual Studio como IDE. El Eclipse Helios v3.6 ha sido extendido mediante la instalación de diferentes plug-in tal como:

- Módulo Qt4, el cual permite desarrollar aplicaciones usando la biblioteca Qt. - Módulo HgEclipse, que es el responsable de añadir soporte para el sistema de

control de versiones distribuido Mercurial dentro de Eclipse. - Módulo Eclox, que es el encargado de integrar el sistema de documentación

Doxygen

Herramienta de compilación


101

Comparativa

De entre las herramientas propuestas en un principio para utilizar en el proyecto (a saber: MAVEN, ANT, CMAKE y SCONS), se escogió ANT después de ver las siguientes comparativas:

· MAVEN está pensado únicamente para proyectos JAVA por lo que se descarta directamente.

· CMAKE vs SCONS.

SCONS CMAKE

Dependencias

Scons y Python dependen entre si y sus actualizaciones pueden hacer inservibles los scripts creados anteriormente

Cmake sólo depende de C++

Extensibilidad Con Python se puede extender la funcionalidad todo lo que se desee

Permite introducir nuevos comandos a través de una instrucción de su propio lenguaje

Velocidad Más lento en grandes proyectos

Mayor rapidez de ejecución

Tareas comunes Más cantidad de código Implementación sencilla

Estabilidad - Más estable y robusto

Aprendizaje Hay que aprender Python Sintaxis sencilla

Plataforma Funciona bien en Linux Funciona bien en Linux y Windows

Documentación

Muy buena, distintos formatos, bien estructurada y gran comunidad de desarrolladores

Buena, bien estructurada y gran comunidad de desarrolladores

· CMAKE vs ANT.

ANT CMAKE


102

Dependencias Es necesario instalar la JVM

Cmake sólo depende de C++

Scripting XML (Aporta mayor legibilidad)

Lenguaje propio (Heredado de versiones anterios de make y autoconf)

Plataforma Cross-platform (JVM) Linux y Windows

Extensibilidad Permite definir etiquetas nuevas para aumentar su funcionalidad

Permite introducir nuevos comandos a través de una instrucción de su propio lenguaje

Documentación Poco documentado para C++

Buena, bien estructurada y gran comunidad de desarrolladores

Otros - Recomendado para GoogleTest y otras tecnologías

Debido a la potencia ofrecida por CMAKE y ANT frente a SCONS (que tiene una alta dependencia con las versiones de Python) se decidió descartar SCONS como herramienta de compilación, testing, etc.

Como solución final se implementó ANT frente a CMAKE dada la facilidad de integración con Eclipse, mayor facilidad de uso y aprendizaje, y la posibilidad de poder invocar a CMAKE u otra herramienta en caso de necesitar alguna funcionalidad específica no contemplada en ANT de forma sencilla.

4.2.2 Descripción del software de terceros

Mercurial


103

Mercurial es una herramienta multiplataforma distribuida de control de versiones para desarrolladores de software. Mercurial es un programa para ser ejecutado con comandos desde la consola, aunque existen extensiones que proporcionan interfaces grafica de usuario. Una de estas es TortoiseHg, que es la que se ha usado en este proyecto. Las principales características de Mercurial incluyen un alto rendimiento y escalabilidad, descentralizada, desarrollo colaborativos distribuido, manejo robusto tanto de texto plano como de archivos binarios, y avanzadas capacidades de ramificación y unión, sin dejar de ser conceptualmente simple. Mercurial también ha dispuesto de medidas para facilitar la transición a los usuarios de SVN.

Doxygen

Doxygen es un generador de documentación, una herramienta para escribir la documentación de referencia del software desarrollado. La documentación es escrita dentro del código, y es por tanto relativamente fácil de mantener actualizada. Doxygen soporta múltiples lenguajes, especialmente C++, en el cual se desarrolla el proyecto. Es además software libre bajo los términos GNU General Public License, y puede ser ejecutado en Unix, Mac OS y Windows.

Doxygen extrae la documentación desde los comentarios de los archivos fuente. Doxygen soporta las etiquetas de la documentación usadas en Qt toolkit y puede generar salidas en HTML.

En el proyecto, se instala el plug-in de Eclipse Eclox para tener disponible todas las características de Doxygen en el entorno de desarrollo integrado. Igualmente, se instala el paquete Graphviz con la finalidad de obtener los distintos gráficos. En la figura 30, se muestra una vista de la ventana de configuración básica de Doxygen en Eclipse y posteriormente otra de la configuración avanzada (figura 31).

Con los manuales generados se pretende que cualquier programador C++ comprenda en su totalidad el código fuente creado para el proyecto y su funcionalidad; contando como apoyo el presente documento. [66]


104

Figura 30: Configuración básica.


105

Figura 31: Configuración avanzada.

A continuación se ilustra la visualización que tiene en el navegador un archivo

generado por Doxygen:


106

Figura 32: Principio.

Figura 33: Continuación de la figura anterior.


107

Figura 34: Salida de Doxygen en HTML.

Google C++ testing framework

El framework de Google para la realización de tests en C++ en diferentes plataformas (Linux, Mac OS X, Windows, Cygwin, Windows CE y Simbian). Basado en una arquitectura xUnit, soporta tests automáticos, un amplio conjunto de aserciones, aserciones definidas por los usuarios, fallos fatales y no fatales, tests de valores y tipos parametrizados, varias opciones para ejecutar tests y generación de reportes de tests XML.

¿Por qué usar el Google C + + framework?

Algunos tipos de tests tienen problemas de memoria que sólo salen a la superficie durante ciertas ejecuciones. El framework de test de Google proporciona soporte para el manejo de estas situaciones.


108

Contrariamente a muchos otros frameworks de tests, el framework de tests de Google tiene incorporado aserciones de que son desplegables en el software donde el control de excepciones está desactivado (por lo general por razones de rendimiento). Por lo tanto, las aserciones pueden utilizarse con seguridad en los destructores también.

La ejecución de tests es simple. Sólo hay que hacer una llamada a la macro predefinida RUN_ALL_TESTS, en lugar de crear o derivar una clase independiente para la ejecución de tests. Esto contrasta con marcos como CPPUnit.

La generación de un informe en lenguaje extensible de marcado (XML) es tan fácil como lo siguiente: - gtest_output = "xml: <nombre de archivo>". En frameworks como CPPUnit y CppTest, es necesario escribir mucho más código para generar la salida XML.

Aserciones

Las aserciones de Google Test son macros que se asemejan a las llamadas a funciones. Cuando una aserción falla, Google Test imprime un mensaje de error que se puede complementar con un mensaje de error personalizado.

A continuación se muestran las aserciones más típicas:

Aserciones típicas de Google Test


109

Valgrind

Es una herramienta de programación con licencia GPL para la depuración de memoria, detección de pérdidas de memoria y rendimiento de análisis.

Valgrind es un marco de instrumentación para la construcción de herramientas de análisis dinámico. Existen herramientas Valgrind que puede detectar automáticamente la gestión de memoria y muchos errores en el subproceso, y perfilar sus programas en detalle. También puede utilizar Valgrind para construir nuevas herramientas.

La distribución Valgrind actualmente incluye seis herramientas de calidad de producción: un detector de error de memoria, dos detectores de hilo, un error de caché y un perfilador de rama de predicción, una caché de generación de call-graph y un perfilador de rama de predicción, y varios perfiles.

La suite de herramientas Valgrind proporciona una serie de herramientas de depuración y perfilado que le ayudarán a hacer sus programas más rápido y más correcto. La más popular de estas herramientas se llama MemCheck. Es capaz de detectar muchos errores relacionados con la memoria que son comunes en C y C ++ y que puede conducir a accidentes y a comportamientos impredecibles.

También incluye tres herramientas experimentales: una pila/matriz global, un profiler de pila secundaria que examina la forma en que se utilizan los bloques de la pila, y un generador de bloque básico SimPoint. Se ejecuta en las siguientes plataformas: x86/Linux, amd64/Linux, ARM / Linux, PPC32/Linux, PPC64/Linux, S390X/Linux, MIPS / Linux, ARM / Android (2.3.x en adelante), X86/Android (4.0 y posterior), y X86/Darwin AMD64/Darwin (Mac OS X 10.6 y 10.7, con un apoyo limitado a 10,8).

Biblioteca Qt

Qt es un framework de aplicaciones multiplataforma que se utiliza ampliamente para desarrollar aplicaciones software con una interfaz gráfica de usuario (GUI) (en algunos casos Qt está clasificado como un conjunto de herramientas de widget), y también se utiliza para el desarrollo de programas sin interfaz gráfica como la línea de comandos y consolas para servidores.


110

Qt utiliza el estándar C++, pero hace un amplio uso de un generador de código especial (llamado compilador Meta Object, o MOC), junto con varias macros para enriquecer el lenguaje. Qt también se puede utilizar en varios otros lenguajes de programación a través de enlaces de lenguaje. Se ejecuta en las principales plataformas de escritorio y algunas de las plataformas móviles. Tiene un extenso soporte internacional. Incluye acceso a base de datos SQL, análisis de XML, gestión de hilos, soporte de red, y una interfaz de programación de aplicaciones multi-plataforma (API) para el manejo de archivos.

En resumen, Qt es un framework de desarrollo integral con herramientas diseñadas para simplificar la creación de aplicaciones e interfaces de usuario para plataformas de escritorio, embebidas y móviles. Está compuesta por:

Qt framework - API intuitiva para C ++ y CSS / JavaScript similar a la programación con Qt Quick para una rápida creación de interfaz de usuario

Qt Creator IDE - potente entorno de desarrollo integrado multiplataforma, que incluye herramientas de diseño de interfaz de usuario y la depuración en el dispositivo

Conjunto de herramientas - todo lo que se necesita: simulador, compiladores local y remoto, soporte internacional, cadenas de herramientas del dispositivo y mucho más.

Con Qt, se puede reutilizar el código de manera eficiente para múltiples plataformas con un código base. La biblioteca de clases modulares de C++ y las herramientas de desarrollo permite a los desarrolladores crear aplicaciones para una plataforma y fácilmente generar y ejecutar en otra plataforma.

4.3 Descripción de la arquitectura general


111

4.3.1 Arquitectura general del proyecto

El objetivo de la arquitectura general es implementar una arquitectura software como la que se detalla en la siguiente imagen.

Figura 35: Arquitectura software general.

En la capa más baja de la arquitectura se encuentran los dispositivos disponibles del sistema de tolerancia de fallos, como son:

· El Testbed de las instalaciones de CATEC. · Cámara del quadrotor.

Estos dispositivos serán accesibles mediante una capa de abstracción hardware (HAL). Este proyecto se compone de una serie de librerías con las que se puede acceder a los datos de cada dispositivo y enviarlos sin tener en cuenta los detalles hardware de cada plataforma. Gracias a esta capa se simplifica en gran medida la comunicación con cada dispositivo. Common Data Library es la librería base del proyecto, en ella se especifican todos los datos comunes, como las IDL, que van a ser usados por los subproyectos. En una capa superior se encuentra DDS (Data Distribution Service). Esta capa de comunicaciones permite publicar y subscribirse a todos los datos accesibles de todos los dispositivos, es decir, interconecta todos los dispositivos de una forma rápida y sencilla. Una vez desarrolladas tanto las librerías de comunicaciones como las de abstracción de hardware, se desarrollarán las aplicaciones concretas que hagan uso de ambos tipos de librerías para formar una arquitectura centrada en la red, estas aplicaciones se


112

denominarán por conveniencia aplicaciones de bajo nivel. La función de estas aplicaciones de bajo nivel será hacer de puente entre ambas visiones del sistema: como nodos dentro de una red y como abstracción de hardware. Por ejemplo, esta aplicación se subscribiría al tópico Posición(x,y,z) y cuando recibiera este dato procedente de la red daría la orden al testbed (por ejemplo) de desplazar un quadrotor a dicha posición, valiéndose de la capa de abstracción hardware. Para la publicación de la posición actual del quadrotor obtendría la información directamente del hardware, a través de la API de la capa de abstracción y la publicaría a la red a través de las librerías de comunicaciones. Por último, en la capa más alta, se encuentran la aplicación de alto nivel como son la aplicación de Tolerancia de Fallos y la HMI (Human Machine Interface) como se puede ver en las Figuras 36 y 37. Estas aplicaciones harán uso de la capa de comunicaciones (CL) para la publicación/suscripción de datos manejados por el programa final.

Figura 36: Módulos de la Arquitectura


113

La arquitectura general sigue el siguiente diagrama:

Figura 37: Diagrama de la arquitectura general.

Esta arquitectura está compuesta por diferentes capas que son (de la más baja a la más alta):

• Controladores: Estos son los controladores de dispositivos específicos dados por el proveedor del dispositivo.

• HALWRAPPER: Es la capa más baja del proyecto. Esta capa tiene como objetivo crear una envoltura para cada controlador y tiene como objetivo ser un punto de acceso común para los dispositivos, habiendo un HALWRAPPER para cada uno de ellos.

• HALSERVICE: Esta capa está compuesta por el controlador del proveedor y el HALWRAPPER. Hay un HALSERVICE para cada dispositivo. Este servicio tiene como objetivo publicar y / o subscribir los datos mediante la capa CL.

• CL: Esta capa tiene como objetivo abstraer todas las bibliotecas de la comunicación (QoS, protocolos de comunicación, etc). Esta es una biblioteca dinámica compartida por todos los procesos.

• HALLIB: Esta capa tiene como objetivo publicar y / o subscribir los datos para las aplicaciones de alto nivel (o HMI) utilizando la capa de CL. Esta capa abstrae a los desarrolladores de alto nivel de cualquier comunicación o tipo de datos específico de un dispositivo.

• Aplicaciones de alto nivel y HMI: Esta capa utiliza uno o más HALLIB especifico de dispositivo. Cada HALLIB ofrecerá el mismo tipo de datos para todos los dispositivos lo que hace muy fácil el uso de cualquier dispositivo.


114

En el nivel más bajo del sistema están los dispositivos testbed y cámara. Estos están conectados a una HAL SERVICE PC que implementa una envoltura para los controladores de dispositivo (HAL Wrapper). Esta envoltura tiene como objetivo unificar todos los controladores de dispositivos diferentes en una interfaz común para todos los tipos de datos (posición, rotación, etc). El proceso HAL SERVICE es el responsable de la publicar y / o subscribir a los diferentes tópicos a través de la capa CL, la cual utiliza DDS.

El nivel más alto del sistema está compuesto por un HMI o aplicaciones de alto nivel que utilizan una biblioteca compartida llamada HALLIB para comunicarse con la capa CL para la publicación y / o suscripción de los datos de un dispositivo específico.

Estructura del proyecto

Los subproyectos tendrán una estructura general de desarrollo cuyo esquema se presenta en la siguiente figura en la que se ha puesto como ejemplo el subproyecto HAL.

Figura 38: Estructura de la capa de abstracción hardaware (HAL).

En un primer nivel se encuentra el archivo build.xml, que es un archivo especifico de la


115

herramienta Ant en Eclipse. Este archivo se encarga de llamar a los distintos build.xml de cada subcarpeta para compilar, ejecutar tests, hacer clean del proyecto, etc. Tanto los binarios como toda la documentación del proyecto se alojará en este primer nivel de la estructura en carpetas separadas para cada subproyecto.

En el segundo nivel se encuentra cada proyecto Eclipse que está estructurado como un proyecto normal del mismo. Es decir, la carpeta sources (src) en la que se encuentra todo el código fuente estructurado en paquetes, y la de tests, en la que está el código de los tests (tests de integración y unitarios). Tal y como se dijo anteriormente, en el primer nivel de cada proyecto de Eclipse se tiene un archivo build.xml que se encargará de ejecutar distintas tareas de cada proyecto. Por último decir que el archivo doxyfile es el encargado de generar la documentación de cada uno de estos subproyectos, y se almacenará en el primer nivel de esta estructura tanto en formato HTML como LaTeX (carpeta Doc).

4.3.2 Arquitectura del proyecto CL

El objetivo del subproyecto CL es el desarrollo de una librería para la publicación/suscripción de datos mediante el protocolo de comunicaciones DDS, utilizando la implementación del middleware de RTI. El objetivo principal es facilitar al desarrollador el uso de este middleware haciendo transparente su uso, es decir se ha de crear una capa que abstraiga de las peculiaridades del uso del protocolo DDS.

Arquitectura orientada a datos

La arquitectura orientada a datos, como su propio nombre indica, tiene como objetivo la transmisión de datos a través de una red. Éste, se diferencia de la arquitectura orientada a servicios (SOA) en que, los datos son publicados haciendo uso de unas especificaciones de calidad de servicio óptimas para aplicaciones en tiempo real, además de utilizar un protocolo basado en publicación-suscripción en lugar de estar basado en peticiones de servicios propias del protocolo RPC. El protocolo DDS puede verse desde el punto de vista del productor como un sistema que produce datos y los distribuye por la red mientras que el protocolo RPC simplemente ejecuta el procedimiento bajo demanda. De modo que en el protocolo DDS, existirán nodos que se conecten a una red teniendo el rol de publicador y/o subscriptor, de tal manera que pueden producir o consumir datos de dicha red.

Características:

· Transparente a la hora de conectar y desconectar nodos, siendo posible hacerlo de manera dinámica.


116

· Estructura invariable de datos que al compartirse permite un nivel de desacoplamiento entre los componentes muy alto.

· Es un sistema totalmente distribuido, donde el fallo de un nodo no tiene por qué perjudicar el funcionamiento del sistema ya que los nodos no son interdependientes, por lo que la caída de uno no afecta a los demás.

· Las calidades de servicio permite la configuración tanto de los datos como de los nodos, pero deben ser compatibles entre el publicador y el subscriptor. No hace falta recompilar si se cambian las calidades del servicio, ya que se pueden configurar mediante un xml.

Organización del proyecto CL

Figura 39: Estructura de la capa de comunicación (CL).

Como se puede apreciar el proyecto se ha organizado en dos módulos:

Módulo ddsLibs

Es la base para el posterior desarrollo del resto de módulos del proyecto. Esta librería define las bases de la implementación de DDS, como son los métodos básicos de creación de participantes, publicadores y suscriptores. Los principales componentes de la librería ddsLibs son:

· ddsWrapperCommon: Se trata de una factoría que define los métodos comunes a la creación de entidades básicas de DDS, es decir, creación de participantes, publicadores y subscriptores, algunas de las funcionalidades más importantes que ofrece son:

o Crear un nuevo participante. o Añadir un nuevo publicador al participante. o Añadir un nuevo subscriptor al participante.

Ejemplo de uso:

nombreproyecto::ddsLibs::DdsWrapperCommon* instance; instance = nombreproyecto::ddsLibs::DdsWrapperCommon::getInstance(logger); participant = instance->createParticipant(domainId);


117

· ddsWrapperPublisher: Define aquellos métodos que son específicos de los publicadores. En la construcción de este objeto se instancian todas las funcionalidades necesarias para la implementación de un nuevo publicador y posteriormente se define el método sendData que será el utilizado para mandar datos a través de DDS. Cabe mencionar, que esta clase ha sido diseñada mediante plantillas, por lo que no será necesario definir nuevas clases para cada tipos de datos, en su lugar, se instanciará a esta clase con el nuevo tipo de datos a utilizar.

Ejemplo de uso:

DDSDomainParticipant* participant;

nombreproyecto::ddsLibs::DdsWrapperPublisher* publisher; nombreproyecto::ddsLibs::DdsWrapperCommon* instance; instance = nombreproyecto::ddsLibs::DdsWrapperCommon::getInstance(logger); participant = instance->createParticipant(domainId); publisher = instance->createPublisher(participant); publisher->sendData<IdlRotation,IdlRotationDataWriter,IdlRotationTypeSupport>(instance,"HelloTopic");

· ddsWrapperSubscriber: Define aquellos métodos que son específicos de los subscriptores. En la construcción de este objeto se instancian todas las funcionalidades necesarias para la implementación de un nuevo subscriptor. Cabe mencionar, que esta clase ha sido diseñada mediante plantillas, por lo que no será necesario definir nuevas clases para cada tipos de datos, en su lugar, se instanciará a esta clase con el nuevo tipo de datos a utilizar.

Ejemplo de uso:


118

DDSDomainParticipant* participant; nombreproyecto::ddsLibs::DdsWrapperSubscriber* subscriber; nombreproyecto::ddsLibs::DdsWrapperCommon* instance; instance = nombreproyecto::ddsLibs::DdsWrapperCommon::getInstance(logger); participant = instance->createParticipant(domainId); subscriber = instance->createSubscriber(participant); subscriber->subscribe<IdlPosition,IdlPositionSeq,IdlPositionDataReader,IdlPositionTypeSupport>("HelloTopic");

Módulo idlLibs

Este módulo será el encargado de abstraer al usuario de la librería CL de la instanciación de las diferentes plantillas definidas por ddsLibs, ocultando al usuario final de las peculiaridades del protocolo DDS como pueden ser el uso de las clases TypeSupport, DataWriter, DataReader, etc, propias de este protocolo de comunicaciones. Este módulo está compuesto de tres clases principales que serán el punto de acceso a la librería animoCL para el usuario final.

· DdsParticipant: Es el punto de entrada de la librería animoCL. Es la clase encargada de la creación de suscriptores y publicadores asociados a esta instancia de DDSParticipant que representa a un participante en el protocolo de comunicaciones DDS. Además esta clase ofrece métodos de creación y eliminación de instancias de los tipos de datos a utilizar. A continuación se incluye un ejemplo de creación de participante en una aplicación cliente o servidor.

DdsParticipant* participant = new DdsParticipant(0,logger); DdsParticipant* participantWithQoS = new DdsParticipant(0,logger, "ANIMO", "HighThroughtput"); DdsParticipant* participantWithQoSFile = new DdsParticipant(0,logger, "ANIMO", "HighThroughtput", "<path_to_other_qos_file>.xml"); // Do something // Delete all participants at the end of the application using any order. delete participantWithQos; delete participant; delete participantWithQosFile;

· PublishService: Es la clase encargada de la publicación de los diferentes tipos de datos definidos en el fichero dataTypes.txt utilizando diferentes calidades de servicio. A continuación se muestra un ejemplo de publicación de distintos tipos de datos haciendo uso de un mismo publicador y con calidades de servicio diferentes.

DdsParticipant participant(0,logger); PublishService* publisher = participant.createPublishService(); IdlPosition* position; position = participant.createIdlInstance<IdlPosition>();


119

position->x = 1.2; position->y = 1.3; position->z = 1.4; position->coordinates = LOCAL_POSITION; // Send a position with default QoS profile. bool result = publisher->publish(position, "IS900"); IdlRotation* rotation; rotation = participant.createIdlInstance<IdlRotation>(); rotation->roll = 10.7; rotation->pitch = 20.2; rotation->yaw = 30.5; rotation->coordinates = LOCAL_ROTATION; result = publisher->publish(rotation, "IS900", "ANIMO", "HighThroughtput"); // Send a rotation with a higher QoS profile. participant.deleteIdlInstance(position); // Delete publisher entity. delete publisher;

· SubscribeService: Es la clase encargada de la suscripción de los diferentes tipos de datos definidos en el fichero dataTypes.txt utilizando diferentes calidades de servicio. A continuación se muestra un ejemplo de suscripción a distintos tipos de datos haciendo uso de un mismo publicador y con calidades de servicio diferentes.

void IdlRotationListener::processData(IdlRotation& rotation) { std::cout << "Received!" << std::endl; } DdsParticipant participant(0,logger); SubscribeService* subscribe = participant.createSubscribeService(); // This declaration is mandatory even if you want to use a NULL instance. IdlPositionListener* positionListener = NULL; // Subscribe to position with default QoS profile and no listener (then no status change will be notified). bool result = subscriber->subscribe("IS900", positionListener); IdlRotationListener* rotationListener = new IdlRotationListener(); // Subscribe to position with higher QoS profile and a rotation listener. result = subscriber->subscribe("IS900", rotationListener, "ANIMO", "HighThroughtput"); // Delete listener. delete listener; // Delete subscriber entity. delete subscriber;


120

Scripts para incluir nuevos tipos de datos

Estructura

Dentro del proyecto CL, se encuentra el directorio idl, donde se encuentran todos los ficheros necesarios para la creación de un nuevo tipo de datos para la capa de comunicaciones CL.

· Los directorios src y obj son los directorios que contienen las cabeceras y el código fuente autogenerado de los tipos de datos definidos mediante los ficheros .idl y los ficheros .o compilados. Estos directorios, se eliminan cada vez que que se hace un clean sobre el proyecto CL.

· El directorio templates contiene las plantillas utilizadas por el script de generación automática del código fuente de los ficheros .idl.

· El archivo dataTypes.txt es el archivo de configuración que contiene el listado de los tipos de datos que van a ser incluidos a la librería animoCL.

· Todos los tipos de datos que se quieran definir deben ser copiados en el directorio idl con la nomenclatura específica.

Fichero de configuración


121

Para facilitar el mantenimiento y actualización de CL, se ha incluido un script para generar el código fuente referente a los tipos de datos que se hayan definido. Dicho script, utiliza un fichero de configuración (dataTypes.txt) en el que el usuario debe escribir el nombre de los tipos de datos que se quieren utilizar (compilar) en la librería. Para ello, la sintaxis de estos ficheros de configuración debe cumplir con la siguiente sintaxis: IdlNombreDelTipoDeDato Un ejemplo del contenido del fichero de configuración dataTypes.txt sería:

IdlPosition IdlRotation IdlAngularSpeed

Una vez hecho esto, el script genera en base a unas plantillas el código necesario a incluir en el proyecto por cada uno de los tipos de datos listados en el fichero de configuración, es decir, obviará cualquier otro tipo de dato existente mientras no se liste correctamente en el fichero.

Los ficheros de cabecera de cada tipo de datos que debe utilizar el usuario final de la librería animoCL se encuentran en el directorio idl/src.

Creación de un nuevo tipo de datos

Para la creación de un nuevo tipo, es necesario que todos tengan una sintaxis ya predefinida (después de definir el contenido del fichero, se nombrará como IdlNombreDelTipoDeDato.idl ) :

const string IdlNombreDelTipoDeDato_ID = "IDENTIFICADOR_UNICO_DEL_TIPO_DE_DATOS"; /*! * \brief Structure used for NombreDelTipoDeDato. */ struct IdlNombreDelTipoDeDato { double x; /*!< Eje X. */ double y; /*!< Eje Y. */ double z; /*!< Eje Z. */ double timestamp; /*!< El timestamp. */ coordinateTypeNombreDelTipoDeDato coordinates; /*!< Tipo de coordenadas. */ string type; };

Compilación de nuevos tipos de datos


122

Una vez realizados los pasos anteriores, el proyecto se encuentra listo para compilar. Para ello, se ejecuta con ANT el build.xml general del proyecto CL, que es el encargado de llamar al script dedicado a los tipos de dato.

4.3.3 HMI

El Human-Machine Interface ha sido previamente implementado en el departamento de Simulación y Software. El proyecto al igual que la arquitectura de Fault Tolerance System se divide en varias capas: la capa de comunicación, la capa de servidor de dispositivo y la capa de librería de dispositivo. Por último, al más alto nivel se encuentra la aplicación gráfica.

La finalidad de la aplicación de alto nivel es implementar prácticamente una Estación de Tierra. Implementar practicamente se debe a que se centra en mostrar al piloto u operario los datos más relevantes de los sistemas en vuelo rápidamente mediante indicadores donde estos siempre están a la vista sin sobrecargar la pantalla y sin distraer al usuario. Otra característica de esta interfaz que agiliza su utilización y aprendizaje es que ha sido diseñada para poder acceder a las distintas funcionalidades en el menor número posible de clicks.

La Interfaz Hombre-Máquina es altamente flexible, lo que significa que se pueden programar nuevos módulos para aumentar las funcionalidades según se requiera. Se considera un módulo a cualquier entidad que aporte funcionalidad a la interfaz, mientras que esta individualmente es únicamente un contenedor. Por lo tanto cada módulo es independiente de la interfaz gráfica y del resto de módulos, por lo que estos pueden ser desarrollados en paralelo por diferentes desarrolladores mientras se respete la estructura del proyecto.

Con respecto al diseño, la arquitectura empleada para desarrollar el HMI es muy simple en el sentido de que esta se separa en los módulos necesarios para un eficiente mantenimiento, modificación y/o ampliación de las funcionalidades.


123

Figura 40: Esquema del sistema con el módulo HMI.

La Interfaz Hombre-Máquina aprovecha las ventajas de una pantalla táctil haciendo uso de una interfaz también táctil (véase Figura 41). El menú se encuentra disponible bajo una pestaña desplegable. En estado de reposo, la interfaz solo provee un botón con forma de pestaña, que al pulsarlo, aparece un panel del tamaño de la ventana, mostrando en él una serie de botones que irán albergando los diferentes módulos para mostrar, tal como el que lanza el visor de log o el de cierre de la aplicación. El panel expandido, se oculta al pulsar cualquiera de los botones o pulsando de nuevo el botón con forma de pestaña.


124

Figura 41: Interfaz HMI.

Con este diseño se puede realizar cualquier acción con un máximo de 2 clicks, lo que facilita en gran medida el uso y elimina elementos que pueden resultar innecesarios mientras se esta interactuando con la interfaz. [74]

4.4 Descripción del software desarrollado


125

4.4.1 Introducción al sistema de tolerancia de fallos

El proyecto EC-SAFEMOBIL (ESTIMATION AND CONTROL FOR SAFE WIRELESS

HIGH MOBILITY COOPERATIVE INDUSTRIAL SYSTEMS) se centra en el desarrollo del sistema de detección de errores en marcha de un UAV específico, para que una vez detectado este mal funcionamiento se controle el UAV afectado y se guíe hasta un punto seguro en tierra.

El proyecto EC-SAFEMOBIL apunta a:

• Detectar y localizar el mal funcionamiento en un UAV especifico.

• Guiar al UAV afectado a un punto seguro en tierra.

Conceptos preliminares.

La comunicación entre UAVs se establece mediante el middleware DDS-RTI. DDS-RTI es un servicio de mensajes publicador/suscriptor de datos para aplicaciones distribuidas integradas en tiempo real.

Otro concepto a tener claro es el de Communication Layer (CL), que también ha sido estudiado previamente en el capítulo 4.3.2. A modo de resumen de este capítulo, CL es una capa común entre el servidor que publica y recibe datos de los dispositivos, y la aplicación de alto nivel que estará usando el dispositivo. CL encapsula DDS-RTI. CL simplifica el uso de DDS y resuelve el acceso a la capa de comunicación.

Repositorio

El repositorio del proyecto está en el directorio subversionado de SAFEMOBIL.

4.4.2 Aplicación de alto nivel de tolerancia de fallos

Fault Tolerance HLA es una parte del proyecto SAFEMOBIL. Este subproyecto es una aplicación de alto nivel del sistema SAFEMOBIL. Hace uso de CameraHalLib y TestbedHalLib. Tanto CameraHalLib como TestbedHalLib se explicará más


126

detalladamente en el capítulo Descripción de los módulos desarrollados. Todos los datos necesarios son accesibles y están disponibles permitiendo enfocar el comportamiento de los UAVs a través de callbacks periódicos al código de control específico de los UAVs

.

Diseño de la arquitectura.

El sistema se basa en tres módulos separados: CameraHAL, TestbedHAL y FaultToleranceWrapper. Estos módulos se comunican entre ellos a través de DDS-RTI. Además se abstrae el código de control de los UAV de todos los otros componentes.


127

Figura 42: Arquitectura de Fault Tolerance System.

· TestbedHAL

Se implementa una librería específica para usar el testbed. Se abstrae la capa de comunicación usando TestbedHALLib.

· CameraHAL

Se abstraen todos los datos necesarios del procesamiento de imágenes usando el software de detección de objetos desarrollado por la universidad que puede encontrar la


128

posición del UAV in la imagen capturada. Se comunica usando DDS-RTI. Se abstrae la capa de comunicación usando la librería CameraHALLib.

· Fault Tolerance Wrapper

Esta arquitectura es extensible y hace uso de CameraHALLib y de TestbedHALLib. Todos los datos necesarios son de fácil acceso y están siempre disponibles. Este módulo permite el enfoque al comportamiento de los UAVs, mediante callbacks periódicos al código específico de control de los UAVs.

Diseño de la comunicación entre módulos.

Los datos específicos compartidos entre los sensores, cámaras y UAVs será necesarios para implementar el código de control de los UAVs.


129

Figura 43: Diagramas de comunicación entre los módulos.

Como se puede ver en la Figura 43, las entidades cámaras son las encargadas de proveer de la información de la situación del UAV seguido en la imagen captada. Esta información se ofrece como dos puntos en la imagen, con los cuales podemos trazar un


130

cuadrado donde el UAV está contenido en dicha imagen. Estos dos puntos son el vértice izquierdo inferior y el vértice derecho superior del cuadro detectado. Estos punto son pasados como cuatro parámetros (coordenada X vértice inferior. Coordenada Y vértice inferior, coordenada X vértice superior y coordenada Y vértice superior) a la entidad UAV. Por otro lado, las entidades de sensores de posición son las encargadas de proveer de la información en forma de tres parámetros (posición, actitud y velocidad) a las entidades UAVs.

Característica del proyecto.

Esta arquitectura da lugar a tres proyectos: FaultToleranceHLA, que tiene la funcionalidad del wrapper, CameraHalService y CameraHalLib, que forman el CameraHal. Tanto FaulToleranceHLA como CameraHalLib se han desarrollado en el entorno Eclipse y con Ubuntu como sistema operativo. Por otro lado, CameraHalService se ha desarrollado en el entorno Visual Studio en Windows.

4.4.3 Descripción de los módulos desarrollados

4.4.3.1 Proyecto Camera HAL Library

Camara Hal Lib es una parte del proyecto. Este subproyecto es la biblioteca para el servicio de la cámara para publicar la configuración y los datos para la aplicación de alto nivel (o HMI) usando la capa CL. Esta capa abstrae al desarrollo de alto nivel de cualquier tipo de datos de comunicación o especifico de un dispositivo.

Este proyecto se puede descomponer en dos partes. Por un lado se tiene de para registrar la aplicación de alto nivel Fault Tolerance a través de un único punto de acceso y se incluye las funciones de registrar y desregistrar la interfaz de HLA. Y por otro lado se tiene la parte de interfaz de la capa de comunicación donde se realiza la conexión a través de la librería de CL. En esta parte se dispone de un container de comunicación DDS, el cual encapsula y gestiona todos los objetos involucrados en la comunicación


131

DDS (inicia DDSReceiver, la cual es usada para recibir los datos, con la QoS configurada en el archivo de configuración), un subscriber manager encargado de gestionar los suscriptores para la recepción de los datos, y un listener que recibe las configuraciones de cámara que son gestionadas por un manager que dispone de un un store (map) para guardar la configuración recibida de las cámaras por DDS de manera que sea accesible. Este manager es usado por la clase padre listener (ver figura 44), de manera que los datos de cámara no son procesados hasta que sus configuraciones no se reciban. Además este manager es utilizado como una clase Singlenton de manera que el usuario puede usarla para acceder a las configuraciones de cámaras recibidas. En este sentido un segundo listener es el encargado de recibir los datos de cámara (el cuadrado en la imagen donde se ha identificado el UAV que se sigue).

Figura 44: Herencia de Listeners.

4.4.3.2 Proyecto Camera HAL Service

Camara HAL Service es una parte del proyecto. Este subproyecto es un servidor de datos para el dispositivo de cámara. Esta capa está compuesta por el controlador y el HALWRAPPER. Este servicio tiene como función publicar y/o suscribir datos usando la capa de CL. Provee la interfaz para publicar y suscribir datos a través del DDS middleware, que está basado en la solución RTI. El objetivo principal es simplificar el uso de este middleware y hacerlo transparente para el usuario. Esta es una librería de Windows OS.

El proyecto se compone de una clase principal la cual es la encargada de mandar los datos de configuración y los datos provenientes de las cámaras. Esta clase se ayuda de una clase sender (ver figura 45) que es la usada para la publicación de los datos de cámaras y de la interfaz que provee el método que envía los datos actualizados de cámaras.


132

Figura 45: Clase Sender.

4.4.3.3 Proyecto Testbed Hal Library.

Testbed Hal Library es una parte del proyecto. Este es una librería dinámica, que permite el acceso múltiple a los datos recabados ya que se piensa en un paradigma punto-multipunto (un servidor de datos, y numerosos equipos y aplicaciones a la espera de información). Este subproyecto es una biblioteca para el dispositivo Testbed para publicar la configuración y los datos para la aplicación de alto nivel (o HMI) usando la capa CL. Esta capa abstrae al desarrollo de alto nivel de cualquier tipo de datos de comunicación o especifico de un dispositivo disponiendo de unos métodos virtuales los cuales se llaman al recibir un dato. Es por ello que la aplicación de alto nivel debe implementar todos los métodos virtuales (uno por cada tipo de dato posible).

4.4.3.4 Proyecto Testbed Hal Service

Testbed Hal Service es una parte del proyecto. Este subproyecto es una biblioteca para el dispositivo Testbed. Esta capa está compuesta por el controlador de proveedor y el HALWRAPPER. . Este servicio tiene como función publicar y/o suscribir datos usando la capa de CL. Provee la interfaz para publicar y suscribir datos a través del middleware DDS, que está basado en la solución RTI. El objetivo principal es simplificar el uso de este middleware y hacerlo transparente para el usuario.

Este, al igual que el CameraHalService, es un servicio encargado de mandar datos de a través de DDS. Se dispone de una clase receiver que recibe los datos de DDS, y una clase sender que analiza los datos de interfaz de envoltura y los publica usando, al igual, DDS. Los datos tratados se ciernen a comandos que son “órdenes” de control para los UAVs. En la siguiente imagen se puede ver la jerarquía de las clase command (comandos).


133

Proyecto Testbed AccessPoint

El TestbedAccessPoint es el punto de acceso a la funcionalidad de la librería, siendo la clase a la cual llamara el desarrollador para poder registrar la aplicación en la lista de observadores. Además, ofrece al usuario métodos para dar la orden de empezar a recibir datos y dejar de recibirlos.

TestbedCLListener

El TestbedCLListener es una interfaz de la cual heredan todos los listeners. Dispone de un atributo de clase RegisterCallback que se le pasa mediante el constructor a todos los objetos hijo, con el objetivo de que todos tengan la misma lista accesible. Los objetos hijo por otro lado, tienen un método virtual para la recepción de los datos, el cual debe de ser implementado en la aplicación final. De esta manera, se está realizando un callback, ya que el objeto es el llamado cuando se recibe un dato por DDS en vez de ejecutar una función o método


134

4.4.3.5 Proyecto Fault Tolerance HLA

Este proyecto es la aplicación de alto nivel del sistema. Esta aplicación hace uso de las librerías CameraHalLib y TestbedHalLib. Todos los datos necesarios son accesibles y están disponibles permitiendo la supervisión del comportamiento de los UAVs a través de callbacks periódicos al específico código de control de los UAVs.

Diagrama de estado.

Estados en un ciclo normal de actividad en Fault Tolerance Wrapper.

Figura 46: Estados de actividad.


135

Figura 47: Diagrama de estados.

Al iniciar la aplicación se inicia el receiver y el timer. Gracias al receiver se actualizará los datos del UAV. Por otro lado con la frecuencia que dicte el timer se ejecutará el


136

código de control, el cual enviará nuevos waypoints para enrutar al UAV seguido en caso de que sus sensores fallaran tal como se ilustra en las Figuras 46 y 47.

Diagrama de clases.

Diagrama de clases del módulo de Fault Tolerance Wrapper.

Figura 48: Diagrama de clases.

Habiendo hecho previamente un estudio de patrones de diseño, se ha aplicado en este caso el patrón factoría abstracta. Se ha hecho uso de este patrón debido a que ofrece una fácil solución para crear diferentes familias de objetos. En este caso AbstractQuadrotor es la factoría abstracta que crea las dos entidades quadrotor, una con cámara y la otra sin cámara.

Como resumen del sistema, tanto a la comunicación de los módulos como el flujo de información se podría decir que: el módulo CameraHALService recibe los datos de la cámara, donde se especifica las coordenadas donde se encuentra el objeto que se está siguiendo por parte de los dos UAV seguidores, gracias a la librería CameraHAL. La aplicación de alto nivel Fault Tolerance es la encargada de orquestar los datos recibidos de las cámaras y el algortimo de detección y corrección de errores desarrollado por la


137

universidad. El módulo de Fault Tolerance determina la posición a partir de los datos recabados gracias a dichas imágenes (por eso se necesitan dos UAV, para tener visión espacial en 3 dimensiones) y se controla por medio del módulo TestbedHAlService (a través de su librería TestbedHAL) al UAV que está fallando para enviarlo a un lugar seguro enviando a dicho UAV los correspondientes waypoints. El algoritmo de detección y corrección es el encargado de detectar que los sensores del UAV seguido con las cámaras están fallando.


138

Documents

4. Descripción del sistema - bibing.us.esbibing.us.es/proyectos/abreproy/30213/fichero/Capítulo+4... · módulo de control electrónico de velocidad, ordenador de a bordo o tarjeta