Proyecto: Iteración 1
by Javier Díaz, Patricio Merino
Proyecto: Iteración 1
Introducción
Como hemos visto en entradas anteriores, nuestro proyecto consiste en realizar mejoras a la línea de comando de ROS dado que, en el poco tiempo que hemos trabajado con ella, hemos observado varias tareas que podrían ser mejor facilitadas al usuario.
Además existen algunos errores (bugs) que impiden usar debidamente los comandos y en general una serie de procesos cuya lógica creemos que debería ser modificada para ajustarse a la perspectiva de lo que espera un usuario novato.
Este blog se presenta en este contexto, donde nos damos un espacio para explicar los avances realizados en lo que denominamos la primera iteración (de dos) y donde además contamos nuestras experiencias trabajando en el código interno de ROS.
Dividiremos el blog en cuatro partes (incluyendo esta) donde trataremos abiertamente los tópicos que compenden al problema a nivel teórico y además hablaremos un poco acerca de cómo queremos hacer llegar nuestras ideas para una posible integración con la versión oficial de ROS.
Añadido a esto incluiremos una sección por cada parte de la solución del proyecto donde discutiremos sobre el diseño de esta y, brevemente, sobre la implementación práctica.
Problema
Nuestro proyecto en realidad ataca varios problemas pequeños y localizados en lugar de intentar solucionar uno demasiado grande. Este podría ser descrito de forma general con la siguiente frase: “La línea de comandos que ofrece ROS presenta un conjunto de procedimientos sin la suficiente funcionalidad para adaptarse a nuevos usuarios”, a lo que además agregamos que existen errores en ciertos comandos y lógicas que creemos que deberían ser indispensables pero que no están implementadas.
Se procederá a describir cada sub-problema de modo que para efectos de este blog, las siguientes secciones se referirán a ellos por su número asignado. Además nos hemos encargado de ordenarlos en orden de menor a mayor dificultad.
-
Obtener información extra de un elemento en ROS se hace con el comando ros___ info, sin embargo
rosmsg info
no existe. En su lugar se nos proponerosmsg show
. -
La opción que un usuario espera en
rostopic pub
por default es-1
, pero el default actúa diferente de esta. -
El comando
rostopic pub
nos pide escribir cada vez el tipo de mensaje, pero este es estático sobre el tópico. -
La función de autocompletar no sirve cuando
rostopic pub
lleva opciones. -
Es difícil saber qué tópicos no tienen subscribers o publishers, ya que hay que comparar cada tópico en dos listas distintas (la de tópicos con subscribers y la de tópicos con publishers).
-
No se puede buscar tipos de mensajes dentro de otros tipos de mensajes, como por ejemplo buscar un
Float64
dentro de mensajes de tipoTwist
. -
Al cerrar
roscore
los tópicos asociados a este no mueren, lo que puede presentar fallas en la lógica esperada si se vuelve a abrirroscore
y se hace referencia a tópicos de la sesión anterior. -
No existe ninguna manera de añadir alguna explicación al momento de crear nodos y tópicos que permita entender al usuario el objetivo de estos. En su lugar se debe deducir la funcionalidad solamente del nombre.
Parte 1: No existe rosmsg info
Solución
Se propone la creación de rosmsg info
simplemente como alias de rosmsg show
, es decir, se desea mantener el método anterior por motivos de adaptabilidad de los antiguos usuarios.
Diseño
Para esto se pretende agregar rosmsg info
en el parser de rosmsg
y simplemente redirigir la llamada a rosmsg show
. Además se deben modificar las referencias asociadas como el help de rosmsg
y la función de autocompletar, ambas equivalentes al comando original.
Implementación
Se modificó el archivo rosmsg/\__init__\.py
donde ahora el comando info
es parseado como show
con alias “info”, lo que significa que es equivalente salvo por el help.
Se puede observar el código fuente aquí.
Parte 2: El default de rostopic pub no es -1
Aclaración
En primera instancia se pensaba modificar la opción por defecto a -1
, sin embargo luego de una investigación un poco más profunda se determinó que la opción que está por defecto (latch) si tiene sentido.
Solución
De acuerdo a esto, el nuevo objetivo pasa a ser la modificación de la opción -1
de manera que actúe de acuerdo a la lógica esperada, es decir, que publique a los tópicos que están escuchando y que finalice inmediatamente (actualmente se esperan 3 segundos para terminar).
Diseño
Para esto se busca eliminar el delay que existe en el comando y modificar el mensaje de ejecución para indicar que finaliza inmediatamente en lugar de exponer el tiempo.
Implementación
Se modificó el archivo rostopic/\__init__\.py
cambiando el tiempo de ejecución del comando a una cantidad indiscernible para el ser humano y se imprime en pantalla que la publicación finaliza de inmediato. Esto se realizó así dado que el comando necesita un delay explícito para ser efectivo (con delay 0 no se publica el mensaje).
Se puede observar el código fuente aquí.
Parte 3: Se exige tipo de mensaje en rostopic pub
Solución 1
Se propone que el comando infiera el tipo cuando este no es descrito explícitamente. Esto ocurrirá siempre que el tópico tenga un tipo asociado, es decir, que haya sido creado previamente.
Diseño 1
Para conseguir esto se planea utilizar la información entregada por el comando rostopic info, de modo que cuando se necesita inferir el tipo de un tópico, este sea reemplazado a nivel de parser por el substring de info que lo contiene.
Implementación 1
En la práctica hay una consideración que vuelve ambigua la posibilidad de omitir el tipo y es que los argumentos del mensaje son descritos de la misma manera que los argumentos del comando. Debido a esto, cuando la cantidad de palabras es grande se vuelve arbitrario decidir cual de ellas corresponde a tópico, mensaje o argumentos del mensaje si además se debe lidiar con el hecho de que puede haber o no haber tipo.
Solución 2
Se propone la funcionalidad de autocompletar el tipo de mensaje directamente el tipo estático del tópico en lugar de con una lista con todos los tipos posibles. De este modo, si al presionar tab el tópico ya había sido definido, se rellena automáticamente el comando con la información inferida.
Diseño 2
Para esto se pretende modificar el autocompletado con tab de manera que para rellenar el tipo existan dos opciones. Si el tópico no ha sido creado aún se mantiene el comportamiento inicial (una lista con todos los mensajes); en cambio si el tópico ya es conocido se autocompleta directamente con su tipo estático.
Implementación 2
Se modificó el archivo share/rosbash/rosbash
el cual contiene las funciones de autocompletado que son llamadas por la terminal cuando son requeridas. Dicho archivo está en el lenguaje bash el cual representa una dificultad extra a la hora de realizar las modificaciones.
El cambio en cuestión consistió en preguntar por la existencia anterior del tópico, evitando imprimir el mensaje de error si no existía, para finalmente agregar la nueva opción a partir del tipo entregado por rostopic info
.
Se puede observar el código fuente aquí.
Parte 4: Autocompletar de rostopic pub no sirve con opciones
Solución
Modificar la función de autocompletado para permitir su uso con opciones.
Diseño
Para esto se pretende parsear la parte del comando escrito hasta el momento y determinar las palabras que corresponden al tópico, el tipo y el mensaje, ignorando las opciones. De este modo se reutilizan las funciones anteriores, pero a partir de los nuevos índices determinados.
Implementación
Una consideración a tener en cuenta es que la opción -r
lleva un argumento, por lo que es parseado de forma especial. Además se contabilizan los índices de manera que se correspondan a la manera en que se hacía en el bash, lo que permite comparar si la palabra actual corresponde o no a un caso de autocompletado.
Se puede observar el código fuente aquí.
Parte 5: Difícil saber qué tópicos no tienen subscribers o publishers
Solución 1
Se propone unificar las listas de publishers y subscribers bajo alguna nueva opción. Además
Diseño 1
El diseño aún no está lista para esta iteración.
Implementación 1
La implementación aún no está lista para esta iteración.
Solución 2
Se propone una opción para mostrar la lista de tópicos que no tienen subscribers o bien publishers, denominados tópicos zombies ya que no realizan trabajo útil.
Diseño 2
El diseño aún no está lista para esta iteración.
Implementación 2
La implementación aún no está lista para esta iteración.
Parte 6: No se puede buscar subtipos de mensajes
Solución
Se propone una opción para rostopic find
que permita la búsqueda recursiva entre tipos de mensajes
Diseño
El diseño aún no está lista para esta iteración.
Implementación
La implementación aún no está lista para esta iteración.
Parte 7: Al cerrar roscore los tópicos asociados no mueren
Solución
Se propone corregir el comportamiento de roscore para que al menos se manejen adecuadamente los tópicos zombies al cerrarse.
Diseño
El diseño aún no está lista para esta iteración.
Implementación
La implementación aún no está lista para esta iteración.
Parte 8: Los nodos y tópicos no tienen una descripción asociada
Solución
Se propone una opción para agregar un mensaje de descripción al momento de crear un nodo o un tópico, y que este sea visible a partir del comando ros___ info
.
Diseño
El diseño aún no está lista para esta iteración.
Implementación
La implementación aún no está lista para esta iteración.
Integración con ROS
Después de una investigación sobre los requisitos necesarios para realizar una petición de integración a la versión oficial de ROS obtuvimos que se deben cumplir ciertas normativas en lo que respecta al código y al formato de la propuesta.
En primera instancia se requiere que el trabajo sea manejado en GitHub, y se presente a través un pull request con un commit por cada feature.
Además el formato del título debe indicar como sufijo el nombre del proyecto y el mensaje debe ser suficientemente clarificador respecto de lo que propone la nueva funcionalidad.
Lo anterior conlleva a la observación de que el método de subdividir nuestro proyecto en pequeñas tareas mejore la adaptabilidad al formato requerido por ROS y facilite la construcción de commits, con lo cual es posible presentar todas las funcionalidades nombradas por separado y aumentar la posibilidad de que alguna de ellas sea catalogada como útil y finalmente aceptada.
Conclusión
En el corto plazo observamos modificaciones a ROS que realmente aportan en el desempeño de usuarios tanto nuevos como antiguos, principalmente los asociados al comando rostopic pub
.
Estas modificaciones muestran ser candidatas interesantes para ser presentadas a una versión oficial de ROS debido a que son modificaciones pequeñas de la funcionalidad, pero hacen más grato el trabajo en este sistema.
Con respecto al método de trabajo utilizado, que se basa en tareas pequeñas pero progresivas, creemos que se adaptan en gran medida con la forma en que se presenta nuestro proyecto, de modo que podemos concentrarnos en problemas más acotados y directos. Esto resulta en una ventaja dado que evita que el esfuerzo decaiga con cada jornada.
A largo plazo creemos que los límites impuestos en nuestra Definición de intenciones van en buen camino y son plausibles de realizar durante la realización de este ramo.
Subscribe via RSS