Advise

ADVISE

RESPONSABLE: JORGE SANCHEZ GARCIA

El sector de la vigilancia y la seguridad privada está viviendo un entusiasmo creciente por la utilización de RPAS-MR como apoyo a sus actuales sistemas de seguridad. Con el fin de dar respuesta a las demandas del sector, proporcionando una solución comercialmente viable, que facilite el uso real de estos dispositivos en condiciones reales, el consorcio de ADVISE afrontará el reto de diseñar, desarrollar y validar un nuevo RPAS-MR autónomo de peso inferior a 2kg, adaptado a la normativa vigente, que integrado dentro de un sistema de seguridad, realice labores de vigilancia perimetral de forma automática y autónoma, tanto en interiores como exteriores, mediante un sistema HW/SW embebido y configurable.

Para la consecución de este objetivo, el proyecto ADVISE plantea como líneas de trabajo en investigación y desarrollo, el diseño de un airframe RPAS-MR, que permita el embarcado de la instrumentación necesaria para la navegación, control y detección. Esto es, al menos GPS, sensor espectro visible, sensor de Infrarrojos, cámaras de ATOL, sistemas de detección de obstáculos tipo RADAR y LIDAR, procesamiento embarcado. Diseño e implementación de una arquitectura Hardware/Software basada en FPGA y GPU de tal manera que todo el procesamiento de elevado consumo computacional se realice a bordo enviando únicamente la información relevante e importante. Y desarrollo de un sistema de decisión, capaz de mejorar el aterrizaje y despegue, la navegación autónoma en condiciones degradadas y acudir a alarmas generadas por el sistema donde está integrado.

La limitada capacidad para operar de forma autónoma, cómo su autonomía, dificulta en sí mismo la entrada en mercado. Es en este punto donde ADVISE centra su potencial innovador proporcionando un sistema con mayores capacidades de percepción y razonamiento, para generar robots autónomos, integrables en un sistema de seguridad tradicional.

CONSORCIO

Para afrontar el proyecto se ha constituido un consorcio capaz de proveer a la solución de la innovación necesaria sobre el estado actual de la tecnología, con la viabilidad de esta solución para ser comercializable. Así, el consorcio está formado por la empresa IXION Industry & Aerospace, que asegura la perspectiva comercial del producto del proyecto, y tres grupos universitarios punteros en su área que aseguran la innovación tecnológica de la solución.

Estos grupos universitarios son el Grupo GIAA, de la Universidad Carlos IIII de Madrid, y los grupos CVG y ASLAB de la Universidad Politécnica de Madrid, todos con amplia experiencia nacional e internacional en proyecto I+D+i.

APORTACIÓN DEL GIAA

El GIAA participará en tareas de gestión del proyecto, definición de requisitos técnicos, especificaciones y subsistemas, además de mantener el proyecto actualizado en cuanto a avances tecnológicos.

En cuanto a desarrollo, el GIAA se encargará de la integración de todos los subsistemas para la construcción del prototipo, validación de la plataforma de vuelo e implementación de algoritmos para evasión de obstáculos y generación de rutas.

Información adicional de aportación

T1. Gestión del proyecto.

Reuniones mensuales con la empresa IXION para la definición de hitos, comunicación de progreso del proyecto, gestión del presupuesto asignado para adquisición de fungible destinado según requisitos del proyecto.

T2. Ingeniería y Arquitectura del Sistema.

Arquitectura de fusión del sistema de navegación

El sistema de navegación será el encargado de proporcionar la posición de los vehículos en tiempo real e ininterrumpidamente. Es decir, el sistema debe ser capaz de dar la localización en situaciones con pérdidas de señal GPS o sensores deteriorados por circunstancias del entorno y tratar con ruido blanco normalmente asociado con todos los sensores.

La arquitectura del sistema de navegación propuesta será una arquitectura centralizada donde todos los datos recabados por lo sensores irán a un único nodo central. De esta forma, los sensores con medidas relativas (como la IMU) no comprometerán la calidad del sistema y aportarán información extra cuando otros sensores tomen medidas ruidosas.

Arquitectura de fusión del sistema de detección y evasión

El sistema de detección y evasión debe ser capaz de distinguir los objetos en el escenario cambiante donde se encontrarán los vehículos autónomos y diferenciarlos entre ellos para estimar sus posibles dinámicas. De esta forma se evaluarán cuáles de dichos objetos representan una amenaza para la integridad del UGV y UAV y realizar maniobras de evasión respecto a la información recopilada.

La arquitectura del sistema de detección y evasión contarán con una arquitectura distribuida. Esta arquitectura ha sido elegida debido a la capacidad de los sensores utilizados en este sistema son capaces de detectar objetos sin información adicional de otros sensores (LIDAR y RADAR). Por tanto, al realizar varios niveles de fusión el sistema obtendrá mejores resultados.

Cada uno de los nodos, tanto los locales como el nodo local aplicarán dos procesos a las medidas recibidas. El primero sería un proceso de asociación para después aplicar un proceso de estimación, como el descrito anteriormente.

La asociación consiste en relacionar los nuevos datos producidos por los sensores con las detecciones producidas por el sistema en anteriores ciclos. Si nos encontramos en la primera iteración del sistema, debemos percibir cuantos elementos se encuentran en nuestro entorno. Esto es esencial porque los datos recibidos por los distintos sensores no tienen ninguna etiqueta que identifique los obstáculos en un instante determinado de tiempo.

Arquitectura de fusión distribuida

Codiseño Hardware/Software

En cuanto al empleo de MPSoC y co-diseño HW/SW, se plantea albergar el pre-procesado de sensores en la parte programable (PL) del SoC para liberar al procesador de la carga computacional más pesada, de tal manera que pueda dedicarse a tareas de más alto nivel.

MPSoc de Xilinx modelo Zynq-7000

En la anterior figura se muestra el diseño de bloques de un SoC de Xilinx modelo Zynq-7000, en el cual se detalla el Sistema de Procesamiento compuesto por un microprocesador ARM de doble núcleo, junto con los distintos periféricos. Y en la zona inferior de la imagen se muestra la Lógica Programable, donde se incluirán los algoritmos de pre-procesado de los sensores, que incluirán filtros e identificación de obstáculos.

T4. Sistema de Navegación y Control

Integración RADAR

El SRR 200 es un sistema de sensor radar de corto alcance desarrollado por Continental para la industria automovilística para realizar funciones avanzadas de asistencia al conductor. La interfaz usual de este sistema se basa principalmente en solicitudes de indicación a la red del vehículo. Por ejemplo, para indicar que un vehículo entra entrando en el punto ciego del propio vehículo.

El sensor SRR utiliza radiación de radar para analizar su entorno. Las señales reflejadas se procesan y después de múltiples pasos están disponibles en forma de clusters y tracks. Un cluster consiste en múltiples reflexiones que tienen una posición y un movimiento similares y por lo tanto se pueden combinar. La posición se representa en un sistema de coordenadas angulares por la distancia y el ángulo de acimut con respecto al sensor. Los clusters se evalúan nuevamente cada ciclo. En contraste con esto, los tracks tienen un histórico y consisten en clústeres rastreados a lo largo del tiempo. La posición del objeto se calcula en relación con el sensor y la salida en un sistema de coordenadas cartesianas.

RADAR modelo SRR 208-2 marca Continental
Campo de visión con azimut y elevación

Para entender la trama CAN que transmite el RADAR, se ha recurrido al uso de una placa de control PixHawk para que haga la función de transceptor entre el RADAR y ordenador donde se prueban los algoritmos de fusión. La placa PixHawk cuanta con un puerto CAN conectado con un conversor de señal para convertir señales diferenciales del bus CAN a single-ended. El microcontrolador de la placa, modelo ST32F4 ha sido flaseado, con un programa de propia creación para configurar el micro y permitir la comunicación por el puerto CAN con el RADAR, y por el puerto USB con el ordenador.

Comunicación entre ordenador y microcontrolador por USB-VCP

T7. Validación y testeo

Las pruebas realizadas para los sensores de uso común como IMU o barómetro, se hará uso de la placa de control PixHawk junto con los drones propios del GIAA para tomar lecturas. Los modelos de sensores facilitados por Ixion son de uso generalizado, por lo que es fácil operar con el mismo modelo.

Plataforma de real de pruebas

Para realizar las pruebas en entorno real, se ha recurrido a la placa de control de vuelo PixHawk. Una computadora de hardware abierta diseñada por 3D Robotics específicamente para crear vehículos no tripulados, que surge de la combinación de placas PX4FMU y PX4IO. Ambas tarjetas, de su versión v2, se integran en la misma PCB (Placa de circuito impreso) dando origen a PixHawk.

Plataforma de desarrollo multirotor del GIAA

Además, PixHawk cuenta con alta conectividad para dispositivos externos y periféricos que pueden aumentar las capacidades del vehículo. Por un lado, hay algunos conectores específicos para ciertos periféricos, tales como: 2 conectores para comunicación de telemetría, 1 para GPS y 1 toma de receptor Spektrum. Por otro lado, existen algunos puertos y buses de uso general como: 2 puertos UART, 2 SPI, 1 conector I2C, 1 conector USB, 1 conector de bus CAN y conectores ADC 3.3V y 6.6V.

El proceso de adquisición de datos está siendo respaldado por varias misiones de prueba de vuelo que han tenido lugar en el circuito especificado en la siguiente figura.

Diagrama del circuito de prueba

Para cada misión, hemos aplicado diferentes parámetros de configuración para analizar las diferencias de rendimiento entre cada configuración. El controlador de vuelo siempre registró los datos que se guardaron junto con los ajustes de configuración para analizarlos en los resultados presentados más adelante.

Antes de explotar los datos de los sensores para la mejora de la navegación, es importante conocer el comportamiento, las limitaciones y las principales características de los datos con los que trabajamos, para establecer una medida de la confianza y la consistencia de los datos. Estas propiedades fueron determinadas por el sensor y el algoritmo de medición. Los datos registrados pueden ser útiles para depurar los algoritmos de estimación y el rendimiento del vuelo, pero en este trabajo solo prestaremos atención a aquellos datos que podrían explicar las estimaciones de la posición local, el rendimiento del sistema de navegación o las capacidades del filtro.

Aumentar Tamaño del texto Disminuir Tamaño del texto

EQUIPO DE TRABAJO

  • Alvaro Luis Bustamante 
  • Jorge Sanchez Garcia
  • Antonio Berlanga de Jesús
  • Jesús García Herrero (Investigador Principal)
  • José Manuel Molina López 
  • Miguel Angel Patricio Guisado