Colaboración de tipo cordada entre UGVs en entornos de búsqueda y rescate

Henche Guijarro, Javier (2018). Colaboración de tipo cordada entre UGVs en entornos de búsqueda y rescate. Proyecto Fin de Carrera / Trabajo Fin de Grado, E.T.S.I. Industriales (UPM), Madrid, España.

Descripción

Título: Colaboración de tipo cordada entre UGVs en entornos de búsqueda y rescate
Autor/es:
  • Henche Guijarro, Javier
Director/es:
  • León Rivas, Jorge de
  • Barrientos Cruz, Antonio
Tipo de Documento: Proyecto Fin de Carrera/Grado
Grado: Grado en Ingeniería en Tecnologías Industriales
Fecha: 15 Noviembre 2018
Materias:
Escuela: E.T.S.I. Industriales (UPM)
Departamento: Automática, Ingeniería Eléctrica y Electrónica e Informática Industrial
Licencias Creative Commons: Ninguna

Texto completo

[img]
Vista Previa
PDF (Document Portable Format) - Se necesita un visor de ficheros PDF, como GSview, Xpdf o Adobe Acrobat Reader
Descargar (3MB) | Vista Previa
[img] Archivo comprimido ZIP - Acceso permitido solamente a usuarios en el campus de la UPM
Descargar (30MB)

Resumen

La robótica ha conseguido introducirse en diversos aspectos de las vidas de las personas. Se pueden encontrar robots en la industria, realizando tareas con alta precisión, rapidez y eficiencia. También se puede encontrarlos realizando servicios domésticos, o incluso en el ejército de algunos países. Pero una de las aplicaciones donde más puede interesar aprovecharse de las ventajas que ofrece la robótica, y donde su utilización no esta tan extendida como en otros ámbitos, es en los entornos de búsqueda y rescate. En estas circunstancias, se debe hacer frente a escenarios desconocidos que deben de ser explorados, y que pueden presentar algún peligro, por lo que sustituir a personas por robots para evitar riesgos innecesarios parece lo más lógico. Teniendo en cuenta que es difícil predecir qué tipo de retos va a tener que superar el robot, se suele confiar en un agente humano para la toma de decisiones, y en muchas ocasiones también para pilotar la plataforma robótica que se vaya a utilizar. Lo que se pretende conseguir en este trabajo es precisamente facilitar la labor de esta persona, para aumentar las probabilidades de superar con éxito las misiones que se desarrollen en estos escenarios de búsqueda y rescate. Para ello, en vez de utilizar un único robot tele-operado, se va a incluir otro robot de apoyo, que ofrecerá imágenes desde una perspectiva exterior, para que el piloto pueda situar el robot que está manejando de una manera más adecuada en el entorno. Al tener este nuevo punto de vista externo, el operador dispondrá de más información para poder superar los obstáculos que se le presenten en su camino. El robot de apoyo, al que también se le denominará robot esclavo en este trabajo, debe de ser capaz de realizar su objetivo de manera autónoma, ya que en caso contrario, podría dificultar al piloto su tarea al tener este que preocuparse de controlar dos robots en vez de uno. Y como justo lo que se quiere conseguir en este proyecto es lo contrario, es decir, facilitar la tele-operación, resulta indispensable desarrollar una serie de algoritmos para que el esclavo pueda completar sus objetivos sin la ayuda o la supervisión del operador. Las plataformas robóticas utilizadas en este trabajo serán dos Summit_XL. Este modelo es un UGV (Unmanned ground vehicle), de cuatro ruedas, con una cinemática diferencial o “skid-steering”, que en su chasis incluye una cámara PTZ, la cual permitirá la toma de imágenes dese dos puntos de vista, y un escáner laser Hokuyo, para poder ser capaz de detectar obstáculos en las cercanías del robot. Además, también dispone de un conjunto de sensores que componen la unidad de medida inercial, de GPS, y de “encoders” o codificadores en las ruedas para la obtención de la odometría, y que en su conjunto harán posible la navegación por un entorno desconocido como es en el caso de este trabajo. Para la programación de los algoritmos con los que se controlará a los Summit_XL, se utilizara ROS (Robot Operating System), que ofrece un marco de trabajo flexible para la programación del software de plataformas robóticas. Trabajar en este entorno permite utilizar librerías y demás software libre disponible gracias al aporte de otros usuarios y de los fabricantes de los robots. Gracias a esto, se ha podido concentrar el esfuerzo en el desarrollo de los algoritmos. Estos, se ejecutarán dentro de “nodos”, que son procesos que ROS ejecuta y supervisa en paralelo, y que pueden interactuar con el resto de nodos para finalmente, controlar los robots. Como se ha comentado anteriormente, lo que se quiere conseguir es la toma de imágenes del robot pilotado o maestro, desde el robot esclavo, que se moverá de manera autónoma. Para conseguir esto, se controlará la orientación de la cámara del esclavo para que apunte en todo momento al maestro. De este modo, independientemente de la posición en la que se encuentren los dos robots, si hay una línea de visión libre, se podrán obtener imágenes del robot tele-operado desde donde se encuentre el esclavo. Este proceso se realizará desde el nodo de la cámara, que controlara los ángulos “pan” y “tilt” de la PTZ en función del posicionamiento de los dos robots, para conseguir tener siempre en la imagen grabada por esta cámara tener centrado al robot maestro. Para controlar el movimiento y la posición del Summit_XL esclavo, y conseguir que se comporte de manera autónoma, se ha desarrollado otro nodo diferente del que controla la cámara, y que se ejecutará junto a ella, llamado nodo de navegación. Lo que se quiere conseguir no es sólo que el robot esclavo sea competente a la hora de navegar por el escenario junto con el maestro, sino que también sea capaz de posicionarse en el punto que más interese en cada momento para tomar imágenes del maestro. En un primer supuesto, en el que se considera que el robot pilotado se encuentra en un terreno plano sin obstáculos de por medio, se ha considerado que la perspectiva más interesante para el tele-operador es un punto de vista trasero, desde el que además de observarse lo que tiene de frente el maestro, se puede ver el contorno del mismo y sus dimensiones físicas, y de esta manera es más sencillo que el piloto se sitúe su posición dentro del escenario. Cuando aparezca un obstáculo, esta perspectiva permitirá afrontarlo de una mejor manera al poder ver al maestro junto al obstáculo y disponer de mayor información para evitar choques y poder superarlo. Con el objetivo de situar al esclavo en la parte trasera, en este supuesto, el esclavo estará en modo de seguimiento, que será su modo de funcionamiento por defecto. En este estado, el robot autónomo se mantendrá a una distancia detrás del maestro, y le seguirá allá a donde vaya. En la práctica, el piloto es capaz de decidir a dónde van los dos robots, ya que uno sigue al otro. Si hay alguna pared, o algún otro obstáculo insalvable, debe de poder ser esquivado por el robot esclavo, ya que este no puede confiar en el maestro para que lo maneje y evite los obstáculos por él. Dentro del modo de seguimiento, se ha implementado un algoritmo que lee los datos del escáner laser, y si detecta algún objeto con el que se pueda chocar, el esclavo corregirá su orientación con un giro pará no colisionar. Gracias a esto, se asegura que durante el seguimiento el esclavo no va a tener problemas cuando algún obstáculo entre él y el maestro. El otro supuesto considerado en este proyecto, es en el que los dos robots deben de subir una rampa, para hacer frente a los posibles desniveles que puedan encontrarse en el escenario. En este caso, se ha decidido que en vez de tomar imágenes desde atrás, una vez se detecte que hay una rampa, el esclavo se situará en un lateral de la misma, para observar el progreso del maestro mientras la está atravesando. Cuando el robot tele-operado comience a entrar en la rampa, el esclavo abandonará el seguimiento al maestro para entran en otro estado, llamado modo en rampa. En el modo en rampa, se asignan una serie de puntos meta en el escenario dependiendo de dónde se encuentre la rampa. El primero de ellos será el punto lateral a la rampa, al que el esclavo irá, y desde el cual obtendrá las imágenes del maestro subiendo la rampa. Una vez el maestro haya subido la rampa, el esclavo irá al resto de metas, que se han asignado para que sea capaz de superar la rampa de manera completamente autónoma. Una vez el esclavo supere la rampa, después de que lo haya hecho anteriormente el robot maestro, se volverá al modo de seguimiento, hasta que se encuentre otra rampa, ya sea de subida o de bajada. También se quiere permitir al piloto que pueda cambiar el robot que está manejando, lo que supone que haya un intercambio de roles entre el maestro y el esclavo cuando se realice esta acción. La implementación de esta funcionalidad se ha hecho en los dos nodos, ya que se ven afectados el control de la cámara y del movimiento del robot esclavo. Con la intención de evaluar el correcto funcionamiento de los dos nodos desarrollados en el trabajo, se han diseñado tres tipos de pruebas en las que se juzgará la calidad de las imágenes que se obtienen desde el esclavo, en función de lo centrado que está el maestro en ellas. También se recogerá el tiempo que se tarda en realizar estas pruebas. El primer tipo de prueba consiste en realizar un recorrido en forma de ocho o infinito, para comprobar que el seguimiento se hace correctamente, y que las imágenes están centradas incluso cuando los dos robots están en movimiento. En el segundo tipo de prueba, se debe de atravesar un pasillo cuyo recorrido tiene forma de uve. En esta prueba se pretende valorar si el esclavo es capaz de evitar chocar con las paredes del pasillo mientras realiza el seguimiento, y si la toma de imágenes se ve afectada por las correcciones que tenga que hacer para no chocar. Por último, el tercer tipo de prueba dispone de una plataforma con una rampa una rampa de subida y otra de bajada, en la que evaluará el correcto funcionamiento del modo en rampa del esclavo, y cómo de buenas son las imágenes tomadas durante todo el proceso. Se harán tres iteraciones de las pruebas para cada tipo, para asegurar la consistencia de los resultados. Y en una de las iteraciones, se realizará un cambio de rol. En el pasillo, el cambio de rol se hará dentro del mismo, y en la rampa, se realizara encima de la plataforma. Tras obtener los resultados de las pruebas hechas en simulador, recogidos en una serie de tablas, se puede afirmar que el Summit que ejerce el rol de esclavo es capaz de mantener al robot maestro centrado en la imagen de su cámara la mayor parte del tiempo en el que existe una línea de visión directa. También se puede concluir que la navegación del esclavo, tanto en el modo de seguimiento, como en la rampa, ha sido exitosa. El cambio de roles ha sido posible realizarlo en las tres pruebas, aunque en la prueba de la rampa, y sobre todo en la del pasillo, en las que el espacio para maniobrar es muy ajustado, se ha hecho con mucha dificultad, llegando casi a colisionar los dos robots durante las maniobras. Debido a esto, en el futuro, el cambio de rol debería estar reservado a circunstancias en las que se tenga un espacio más abierto. En un futuro, sería conveniente abordar el problema que se quería resolver en este trabajo de una manera más flexible, dotando al esclavo de la suficiente inteligencia como para que él pudiera elegir el punto de observación más adecuado, en función del obstáculo que se quiera superar. También se podría explorar diferentes soluciones en los que los dos robots fueran autónomos, y colaboraran sin la intervención de un agente humano para tomar datos del escenario y completar satisfactoriamente la misión que se les plantee.

Más información

ID de Registro: 53439
Identificador DC: http://oa.upm.es/53439/
Identificador OAI: oai:oa.upm.es:53439
Depositado por: Javier HEnche Guijarro
Depositado el: 08 Ene 2019 09:17
Ultima Modificación: 08 Ene 2019 09:17
  • InvestigaM
  • GEO_UP4
  • Open Access
  • Open Access
  • Sherpa-Romeo
    Compruebe si la revista anglosajona en la que ha publicado un artículo permite también su publicación en abierto.
  • Dulcinea
    Compruebe si la revista española en la que ha publicado un artículo permite también su publicación en abierto.
  • Recolecta
  • Observatorio I+D+i UPM
  • OpenCourseWare UPM