Turtlebot simulation with ROS in the Nootrix virtual machine

Facebooktwittergoogle_plusredditpinterestlinkedinmail


[In English]

Siguiendo con la idea de utilizar la máquina virtual de Nootrix para Indigo 32, he estado trabajando con las opciones incluidas en ROS para simular  el robot Turtlebot usando Gazebo y rviz.

Para lograr una visualización y teleoperación básicas hay que ejecutar lo siguiente:

  • Instalar todo lo que haga falta para simular el Turtlebot:
    • sudo apt-get install ros-indigo-turtlebot-simulator
    • sudo apt-get install ros-indigo-turtlebot-apps
    • sudo apt-get install ros-indigo-simulators
  • Abrir un terminal y ejecutar roslaunch turtlebot_gazebo turtlebot_world.launch
  • Abrir otro terminal y ejecutar roslaunch turtlebot_rviz_launchers view_navigation.launch
  • Abrir un último terminal y lanzar un nodo que permita la teleoperación. Yo he utilizado roslaunch kobuki_keyop keyop.launch, ya que el funcionamiento de la otra opción de teleoperación (roslaunch turtlebot_teleop keyboard_teleop.launch) no me queda claro.
  • El resultado puede verse en este vídeo.

Para navegar con Turtlebot y construir un mapa, se puede consultar este tutorial o este otro. Ninguno de los dos funciona:

  • En un terminal, se ejecuta roslaunch turtlebot_gazebo turtlebot_world.launch. Hasta ahí, todo ok.
  • En otro terminal, ejecutar roslaunch turtlebot_gazebo gmapping_demo.launch. Ahí se fastidia el invento, y al cabo de unos momentos aparece el mensaje [ WARN] [1437734908.414750431, 97.100000000]: MessageFilter [target=odom ]: Dropped 100.00% of messages so far. Please turn the [ros.gmapping.message_notifier] rosconsole logger to DEBUG for more information.
  • Si en un tercer terminal se lanza rviz con roslaunch turtlebot_rviz_launchers view_navigation.launch, el fixed frame por defecto es map, y el elemento map aparece en amarillo y con el mensaje No map received.
  • Si se abre otro terminal para teleoperar el robot (roslaunch kobuki_keyop keyop.launch), el robot se mueve tanto en Gazebo como en rviz, pero sin mostrar las lecturas de las sensores.
  • Finalmente, si en otro terminal intentamos grabar el mapa con rosrun map_server map_saver -f mimapa, el mensaje que aparece es Waiting for the map.

Para averiguar qué estaba fallando, comprobé diferentes cosas:

  • Si el árbol de transformadas estaba completamente conectado: rosrun tf view_frames. Aparentemente, sí lo está.tftree
  • Hacer un source antes de cada roslaunch: source /opt/ros/indigo/setup.bash 
  • Comprobar el topic /map (en el que, según rviz, se lee el mapa), para ver si los nodos implicados accedían a él: rqt_graph, rosnode info slam_gmapping, rosnode info rviz. Todo bien también.
  • Comprobar qué información se transmitía por el topic /map. A pesar de que los nodos estaban bien conectados, al hacer rosrun tf tf_echo /map /odom los valores que circulaban por él eran siempre nulos, incluso si movía el robot con la teleoperación del kobuki.

Después de buscar ayuda infructuosamente por tooooda internet ;), pensé en instalar ROS directamente sobre mi Xubuntu 14.04, sin máquina virtual. Lo hice, volví a lanzar Gazebo, rviz y la teleoperación del kobuki, y tachán tachán, apareció un error distinto: [ERROR] [1433813576.466253926, 24.270000000]: Scan message must contain angles from -x to x, i.e. angle_min = -angle_max. Este error me sonaba de haberlo visto reportado y resuelto en answers.ros.org, así que hice lo que se decía en esta respuesta y conseguí hacer un mapa con gmapping.

Así que se me ocurrió replicar esa solución en el ROS de la máquina virtual, y esta vez sí, logré un hermoso mapilla virtualmente simulado 🙂

mapiki

Digamos que he logrado la solución ingenieril (funciona) pero no la científica (no sé por qué) 😉 Cualquier explicación sobre qué estaba fallando será bienvenida.


[En español]

According to my idea of using the Indigo 32 Nootrix virtual machine, I have been checking the options included in ROS for simulating the Turtlebot robot with Gazebo and rviz.

In order to get a basic visualization and teleoperation, you should follow these steps:

  • First, get all the tools to simulate the Turtlebot:
    • sudo apt-get install ros-indigo-turtlebot-simulator
    • sudo apt-get install ros-indigo-turtlebot-apps
    • sudo apt-get install ros-indigo-simulators
  • Open a terminal and run roslaunch turtlebot_gazebo turtlebot_world.launch
  • Open another terminal and run roslaunch turtlebot_rviz_launchers view_navigation.launch
  • Open a third terminal and launch something that lets you to teleoperate the robot. I have used  roslaunch kobuki_keyop keyop.launch, since how the other ROS option for teleoperation works (roslaunch turtlebot_teleop keyboard_teleop.launch) is not clear to me.
  • You can see the results in this video.

If you want to navigate the Turtlebot and get a map, you have this tutorial or this other. None of them works:

  • Open a terminal and run roslaunch turtlebot_gazebo turtlebot_world.launch. Everything is ok.
  • In other terminal, run roslaunch turtlebot_gazebo gmapping_demo.launch. This is where things go wrong and you get the message [ WARN] [1437734908.414750431, 97.100000000]: MessageFilter [target=odom ]: Dropped 100.00% of messages so far. Please turn the [ros.gmapping.message_notifier] rosconsole logger to DEBUG for more information.
  • If you open a third terminal with roslaunch turtlebot_rviz_launchers view_navigation.launch, the default fixed frame is map, and the map element is shown in yellow, with the message No map received.
  • If you open another terminal for teleoperation (roslaunch kobuki_keyop keyop.launch), the robot moves both in Gazebo and rviz, but it does not show the sensor readings.
  • Finally, if you open another terminal and try to store the map with rosrun map_server map_saver -f mimap, you get a Waiting for the map message.

Here is a list of all the things I tried to solve the problem:

  • Was the transforms tree properly connected (rosrun tf view_frames)?. Apparently, it was.tftree
  • I sourced before every roslaunch: source /opt/ros/indigo/setup.bash 
  • I checked the /map topic (where the map is read, according to rviz), in order to see in the involved nodes were properly connected: rqt_graph, rosnode info slam_gmapping, rosnode info rviz. Everything seemed ok too.
  • I checked which information was sent through the /map topic. Despite of the nodes being well connected, rosrun tf tf_echo /map /odom proved that all the values moving across the topic were always null, even if the robot was teleoperated with the kobuki node.

After vainly googling half the internet ;), I thought I could install ROS directly on my Xubuntu 14.04, without virtual machine. I did it, run again Gazebo, rviz and kobuki teleoperation and, oh boy, I got a different error: [ERROR] [1433813576.466253926, 24.270000000]: Scan message must contain angles from -x to x, i.e. angle_min = -angle_max. I recalled this error from answers.ros.org, so I did what it was explained  in this answer and finally I got a map.

So I applied that solution to the ROS on the virtual machine, and finally I got a lovely virtually simulated little map 🙂

mapiki

We could say that this is the engineering solution (it works), but not the scientific solution (I don’t know why) 😉 Any explanation on what was failing will be heartily welcomed.

Free chapter of “Simultaneous Localization and Mapping for Mobile Robots: Introduction and Method”

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Capítulo gratis del libro Simultaneous Localization and Mapping for Mobile Robots: Introduction and Method, Juan-Antonio Fernández-Madrigal y José-Luis Blanco-Claraco (Universidad de Málaga),  IGI Global (2013)

Free chapter of  Simultaneous Localization and Mapping for Mobile Robots: Introduction and Method, Juan-Antonio Fernández-Madrigal and José-Luis Blanco-Claraco (Universidad de Málaga),  IGI Global (2013)

Maps for Mobile Robots: Types and Construction