23 mar 2021

FEWOD Error: lo que debes saber antes de comenzar un proyecto de robótica aérea usando drones de DJI

AUTOR: JESÚS PÉREZ MARTÍNEZ

    En los últimos años los vehículos aéreos no tripulados, más conocidos como UAVs o drones, están aumentando su relevancia de forma exponencial en el mundo actual. Por ejemplo, hace unas semanas aparecía la noticia de que, con gran seguridad, se abrirá en los próximos meses (de forma experimental) el primer aeropuerto establecido en Londres para taxis voladores y drones de reparto, bautizado como Air One. Esto, que hasta hace no mucho parecía ciencia ficción, es ya una realidad y son numerosas las empresas que empiezan a usar drones en multitud de tareas, principalmente porque permiten aumentar la seguridad y la eficiencia en determinadas operaciones. 


    Drone M300 en vuelo, un modelo industrial de DJI.

    Una de las marcas líderes en este sector es DJI, bien conocida entre el público general por la amplia gama de productos para todo tipo de usuarios que presenta. Su línea referente a drones industriales tiene una característica bastante interesante, que nos proporciona una serie de herramientas de desarrollo o SDKs para crear nuestras propias aplicaciones y personalizar el comportamiento de nuestra aeronave al máximo. Es tal el grado de desarrollo que el fabricante nos quiere dar, que es posible implementar soluciones de robótica aérea basada en ROS a través del OSDK, su kit de desarrollo para aplicaciones a bordo del propio drone. Sin duda esto es un factor que puede ser muy influyente a la hora de plantear el proyecto de un nuevo producto o línea de desarrollo basada en este tipo de aeronaves, pero, ¿cuál es el nivel de madurez del OSDK de DJI?, ¿realmente se pueden crear soluciones capaces de ejecutar acciones de forma autónoma con los productos del gigante asiático en materia de drones?. 

    Estas son algunas de las preguntas que podemos llegar a hacernos antes de comenzar un proyecto de desarrollo de estas características, y dada la poca información que podemos encontrar sobre este tema actualmente, intentaré responderlas a través de mi experiencia personal y de un error de seguridad que encontré hace unos meses al trabajar con el OSDK.


    Componentes principales de una plataforma de robótica aérea

    Antes de comenzar más en detalle, pasaré a recapitular algunos conceptos clave de los componentes que podemos encontrar en un desarrollo de robótica aérea, partiendo siempre desde el uso de una aeronave industrial de DJI.

    1. En primer lugar, lo fundamental es elegir nuestro modelo de drone o fabricarlo nosotros mismos. Debido a la dificultad que supone la segunda opción, partiremos de una aeronave ya construida y con una serie de garantías que nos proporciona el fabricante. Una parte muy importante del drone y que se relaciona con los siguientes componentes es la controladora, encargada de procesar y analizar los datos de los sensores (GPS, IMU...), así como regir el correcto funcionamiento de los actuadores (motores principalmente).
    2. Una solución basada en robótica aérea requiere sensores más especializados que no suelen estar incluidos en nuestro modelo de drone, como cámaras estereoscópicas de alta precisión o sensores LIDAR. Estos sensores serán una pieza clave a la hora de reconocer patrones u objetos que influirán en el comportamiento de nuestro drone.
    3. Para procesar los datos que proporcionan estos sensores en tiempo real se necesita una capacidad de cómputo bastante elevada, por lo que una solución es añadir un procesador de abordo. Esta parte del sistema estará conectada a la controladora y a los sensores específicos. DJI proporciona una serie de plataformas de procesamiento denominadas Manifold 2 con el fin de dar solución a este problema.

    Debido a la necesidad de cómputo elevada y al notable peso de sensores como los LIDAR, es necesario usar drones industriales para que puedan llevar esta carga de pago sin dificultad. Además, es necesario satisfacer las exigencias de consumo de estos componentes, por lo que se necesitan baterías de gran capacidad, las cuales no encontramos en modelos destinados al público general.


    Failsafe error when OSDK disconnected: un error de seguridad con consecuencias peligrosas

    Para ilustrar la forma en la que encontré este error de seguridad, al cual llamé simplemente “Failsafe error when OSDK disconnected” en el título del reporte que envié a DJI a través de su repositorio de GitHub, primeramente haré un supuesto ficticio de un proyecto de robótica aérea. A partir de aquí, para abreviar usaré sus siglas y me referiré a este error como FEWOD.

    Imaginemos que queremos crear un producto enfocado a dar servicio a empresas petrolíferas, más concretamente para realizar inspecciones de oleoductos con drones. Para automatizarlo, incluiremos una inteligencia artificial en la propia aeronave, que analizará las imágenes tomadas por la cámara y detectará daños en la estructura. Al detectar uno de los posibles daños contemplados, el drone pausará la misión y cederá el control al piloto para que haga una evaluación más exhaustiva. Cuando el piloto lo crea conveniente, le dará la señal para que continúe la misión y siga haciendo la inspección de manera autónoma. Además, se incluirá un sensor LIDAR para detectar posibles obstáculos en la ruta, cuando esto ocurra se cederá el control al piloto.

    Este robot aéreo tendrá, a modo resumido, una cámara que puede ser la principal del drone, un sensor LIDAR y un ordenador de abordo, supongamos que es la Manifold 2 para que no haya problemas de compatibilidad con nuestro drone de DJI. Ahora que tenemos el hardware especificado, pasaremos a definir la parte software y cómo se va a comportar. Podemos distinguir diferentes acciones o comportamientos posibles a los que nuestro producto tiene que dar respuesta, pero para llegar a descubrir el error, nos centraremos en los anómalos. Es necesario contemplar el mayor número de escenarios/situaciones posibles que pueden darse al utilizar nuestro futuro robot aéreo, con el fin de crear un diseño robusto y seguro.


    Algunas de las situaciones anómalas que pueden ocurrir para este ejemplo.

    Una infografía de estas posibles situaciones puede ser la mostrada en la Ilustración 2, y nos centraremos en el caso de “Desconexión del Módulo”, donde por un motivo imprevisto y externo al piloto o la aeronave, se pierde la conexión entre el ordenador de abordo (Manifold 2) y la controladora. Esta pérdida de conexión puede darse por un fallo de alimentación de la Manifold, por interferencias o por otros motivos externos. Pero, ¿DJI ha implementado algún mecanismo de control para detectar esta posible pérdida de comunicación?. Pues, en teoría sí. Existe una opción si entramos a la configuración del drone por medio de la aplicación DJI Assistant llamada Failsafe error que si la activamos marcando la casilla (Ilustración 3), nuestro drone teóricamente pasaría a ejecutar de forma automática una de las siguientes opciones:

    • Hovering: se mantiene estático en el aire.
    • Vuelta a casa: también conocida como RTH (Return to Home), hace que nuestra aeronave vuelva al punto de despegue y aterrice en él.


    Opciones para configurar el comportamiento del drone ante un fallo del SDK.

    Esta opción en un principio es suficiente para satisfacer la situación anómala que estamos analizando, pero al realizar una prueba conectando nuestro drone (con la Manifold) al simulador que incluye DJI Assistant para llevar a cabo diferentes pruebas en un entorno controlado, comprobamos que no era así. En nuestra Manifold, se pasa a ejecutar una misión a través de ROS y en un momento cualquiera desconectábamos el cable de comunicación que conecta el ordenador de abordo con la controladora del drone. El resultado, en vez de que nuestro robot comience a volver al punto de origen o que entrara en modo hovering, seguía ejecutando la misión

    Podéis imaginar el riesgo que supone este error, ya que puede provocar no sólo daños a estructuras, sino también a personas. En concreto, para el caso del ejemplo propuesto para inspecciones de oleoductos, la existencia de este fallo puede suponer perjuicios graves a infraestructuras críticas, ya que recordemos que este tipo de aeronaves tienen un peso considerable y sus baterías pueden llegar a provocar incendios o explosiones si sufren daños severos.


    Soluciones propuestas por DJI a través de GitHub

    Como he comentado en el punto anterior, al encontrar el error lo reporté al repositorio del OSDK de DJI para informar de lo ocurrido en la versión con la que estaba trabajando, y pregunté si existía una solución. Tal y como podéis comprobar, no me dieron una solución muy útil, ya que me recomendaban que usara una función llamada flightCtrl, que básicamente su cometido es la de enviar señales en tiempo real para que nuestro dron se mueva en una determinada dirección. Por lo tanto, si deja de enviarse esta señal la aeronave pasará a estar estática, igual que ocurre cuando la controlamos con el mando.

    Esta solución puede ser útil dependiendo del proyecto. Por ejemplo, para solucionar problemas de mapping en los que se busca reconstruir una zona en tres dimensiones por medio de un sensor LIDAR, es factible usar este método para que el drone adapte su trayectoria en función de los obstáculos que va descubriendo. Un ejemplo de esta aproximación es la solución Hovermap de Emesent.

    Sin embargo, si conocemos la región del espacio donde nuestro robot se va a mover, ¿qué sentido tiene aplicar esta función?, ¿por qué tenemos que perder las capacidades de la controladora de ejecutar y procesar misiones definidas por una serie de puntos específicos en el espacio?. Obviamente, sería un engorro tener que volver a implementar una aplicación de creación de misiones, ya que es algo que nuestro drone lo trae de serie. Además, la aplicación destaca por su robustez por la cantidad de modelos en los que se ha implementado desde el Phantom 1, el primer modelo que DJI lanzó en 2013.

    Parece ser que este error, a día de publicar este artículo, se encuentra parcialmente resuelto. Volví a preguntar para informarme de si, al menos, se encontraba solucionado para los modelos industriales más recientes (M210 y M300) en una nueva entrada de GitHub. La respuesta fue que actualmente se había implementado una estrategia para lidiar con el error, en la que la acción de volver a casa tiene más prioridad que una misión, y ésta última a su vez tiene más prioridad que el modo estático (hovering). Por lo tanto:

    • Si elegimos la opción de hovering para tratar la desconexión con el OSDK, nuestro robot seguirá ejecutando la misión e intentará pasar por los puntos que le hemos indicado.
    • Si elegimos la opción RTH o vuelta a casa, el drone al detectar la desconexión volverá al punto de partida.


    Conclusión

    Si bien esta última solución puede no ser la más adecuada, sí que nos permite al menos proponer un punto de partida más robusto y adaptar el planteamiento de nuestro proyecto para cumplir los estándares de calidad y seguridad. Sin embargo, esta solución parcial sólo es válida para el M300 y el M210, que como he indicado corresponden a los últimos modelos de la serie industrial de DJI. Por lo tanto, si tenemos el M600 (que es el modelo anterior) o la controladora A3 en un drone que hayamos fabricado nosotros, esta solución no será válida porque, aunque aparece la opción de Failsafe Error en la configuración, realmente no tiene un mecanismo de control implementado para detectar este error.

    Volviendo a las preguntas que nos hacíamos al principio, en primer lugar y dada mi experiencia personal, a la pregunta de ¿cuál es el nivel de madurez del OSDK de DJI?, tengo que responder que aún queda mucho camino por recorrer. Si echamos un vistazo a la documentación de este kit de herramientas de desarrollo, veremos que es poco intuitiva, los ejemplos son escasos y de limitada claridad. Sin duda la línea principal de negocio de DJI son los drones más enfocados al uso recreativo y fotográfico, pero es una pena que su línea industrial en materia de robótica aérea parezca estar algo abandonada, a pesar del potencial que tiene. 

    Hace unos días el Ministerio de Ciencia e Innovación de España lanzaba el Programa Tecnológico Aeronáutico (PTA) para posicionar al país como referente internacional en el campo de los drones, y recordemos que sólo en España hay actualmente activos 1500 proyectos de investigación relacionados con esta temática. Ya existen numerosas empresas que están trabajando en crear todo tipo de soluciones implicando a drones, por lo que es cuestión de tiempo que se demande robustez en este tipo de kits de desarrollo.

    ARTÍCULO CORTESÍA DE JESÚS PÉREZ MARTÍNEZ

    1 comentario: