Turtlebot 2 con brazo WidowX: primeros pasos

Turtlebot 2 con brazo WidowX: primeros pasos Ana Cruz Martín Dpto. de Ingeniería de Sistemas y Automática, Universidad de Málaga Octubre-Diciembre 2015

Aviso de exención de responsabilidad: los procedimientos y opiniones aquí expresados son reflejo de la experiencia de la autora, no están exentos de error, y no son en absoluto un manual oficial ni del robot ni del brazo; por tanto, no se ofrece ningún tipo de garantía. Este documento resume los pasos iniciales básicos necesarios para usar el robot Turtlebot 2 con un brazo WidowX incorporado. Se trata de una descripción informal del trabajo realizado hasta ahora, por si pudiera servir de ayuda a quienes estén empezando a trabajar (y a pelear) con el robot :) Existe un tutorial relativamente bien documentado: http://wiki.ros.org/Robots/TurtleBot La versión de ROS que se utiliza a lo largo del documento es indigo, si no se indica lo contrario. 1) Netbook del Turtlebot • La wifi debe conectarse sólo cuando sea imprescindible, ya que si no la batería se descarga rápidamente. Si hay que usarla, intentar tener el netbook cargando a la vez, y no olvidar desconectar después el cable del cargador para evitar accidentes si se va a mover el robot. •

Igualmente, desactivar también el bluetooth para mantener la batería cargada el mayor tiempo posible.

•

Para trabajar desde un PC remoto es necesario instalar el servidor ssh en el netbook (en nuestro caso, no venía instalado por defecto). Después, basta conectarse desde el PC al netbook con ssh turtlebot@direcciónIPdelnetbook. Algunas consideraciones: ◦ Nuestro netbook actualmente no tiene IP fija, así que hay que comprobar cuál es con ifconfig. ◦ No olvidar, en cada terminal que se abra, ir al directorio catkin_ws y hacer source ./devel/setup.bash ◦ Si se va a lanzar algún paquete gráfico de ROS (rviz, rqt_graph…) la llamada a ssh debe ser ssh -X turtlebot@direcciónIPdelnetbook.

2) Conexión ROS netbook – ROS otro equipo • Para facilitar la visualización de los datos, es posible ejecutar el ROS del netbook como maestro, y que otros ROS corriendo en otras máquinas se comuniquen con él. •

El

tutorial

a

seguir

es

este:

http://wiki.ros.org/turtlebot/Tutorials/indigo/Network

%20Configuration ◦ Para averiguar las direcciones IP del netbook y el PC desde el que queramos conectarnos, ifconfig. En nuestro netbook hay que comprobarlo cada vez, ya que no es fija, como se comentó anteriormente. ◦ El setup que nosotros hemos seguido en el Turtlebot es el “Deb installation”. ◦ En el lado del PC remoto, una vez cambiadas las variables, cerrar la ventana de comandos y abrir una nueva. ◦ Para poder probar que todo ha ido bien, se pueden usar los ejemplos de los topics que vienen en el tutorial; es necesario que en el netbook esté lanzado roscore. ◦ Para comprobar que las direcciones son correctas en las dos máquinas: printenv | grep ROS. ◦ La prueba que he hecho conecta bien un portátil (ROS jade, red de cable) con el netbook del Turtlebot (ROS indigo, wifi). Por ahora, sólo se pueden lanzar desde el PC remoto algunas funciones ROS: (rostopic, rqt_graph), pero no módulos. Creo que la razón puede estar en los .bash, que son diferentes, pero hay que investigarlo. •

La explicación anterior es útil si se quieren lanzar varios módulos ROS de forma distribuida entre el PC remoto (por ejemplo, rviz) y el netbook. Si únicamente se va a trabajar en el netbook, usar ssh en el PC remoto y listo… ¡¡sin olvidar que estamos en el netbook, cuidado al tocar algo y al lanzar módulos!!

3) Base móvil Kobuki • LED indicador de carga ◦ Naranja: recargar cuanto antes. ◦ Verde: carga alta. ◦ Verde intermitente: cargando. ◦ La diferencia entre “verde” (carga suficiente) y “naranja” (poner a cargar) es “difusa”. Digamos que “verde” es verde fuerte, y “naranja” es verde clarito (o verde manzana, o verde pistacho… bueno, es un tono de verde más amarillento).

4) Manejo de la base Kobuki desde ROS • Comprobación de carga: rosrun kobuki_testsuit test_battery_voltage.py •

Primeras pruebas: roslaunch kobuki_node minimal.launch -screen ◦ Primer día: aparece el error Kobuki timed out while waiting for serial… tras moverse un poquito. ▪ Aparentemente, se debe a que había poca carga en el robot, pero no es seguro; después de la carga inicial no ha vuelto a aparecer. Otros usuarios indican que el error está asociado a problemas con el USB: https://github.com/yujinrobot/kobuki/issues/174 ◦ Aparecen tres warnings de que no recibe comandos de velocidad (Kobuki: incoming velocity commands not received for more than 0.60 seconds → zero'ing velocity commands), pero se mueve correctamente y durante bastante rato. Esporádicamente estos avisos aparecen, pero no parecen afectar al funcionamiento del robot. ◦ Aparece el warning Kobuki: no robot description given on the parameter server.

Relacionado con la falta de modelo del robot. •

Para mover la base directamente desde el topic correspondiente: rostopic pub /mobile_base/commands/velocity geometry_msgs/Twist '[0.1,0.0,0.0],[0.0,0.0,0.0]' La velocidad máxima del robot es 0.7 m/s, según las especificaciones, yo prefiero mover el robot a velocidades bajas (por ejemplo, 0.2 m/s). Cuidado con este tutorial, ya que se da al robot una velocidad de 1.0, o sea, superior a la máxima: http://wiki.ros.org/kobuki/Tutorials/Examine%20Kobuki

•

rviz A veces no se abre bien la cámara al lanzar rviz; en ese caso cerrar tanto rviz como openni y volver a lanzar ambos. Por ahora parece que este error ocurre cuando al lanzar openni NO aparecen los siguientes warnings: ▪ Camera calibration file path_del_fichero.yaml not found (tanto para rgb como para ir) Using default parameters (tanto para rgb como para ir) ◦ La nube de puntos se sobreimpresiona sobre la imagen de la cámara, por eso se ve “borrosa”. ◦ Aparece un error al añadir el modelo del robot, quizás se debe a que al lanzar el Kobuki ya se nos avisa de que no puede cargar el modelo. ◦ Para ver la nube de puntos y la imagen en color es necesario registrar la imagen: http://wiki.ros.org/openni_launch/Tutorials/QuickStart ▪ Por defecto, ya tenemos activada en rviz la PointCloud2, que está escuchando en el topic /camera/depth/point; no veo necesario cambiar el color de fondo a gris claro. ▪ rosrun rqt_reconfigure rqt_reconfigure: tarda en arrancar. A partir de ahí, seguir los pasos del enlace mencionado: escoger /camera/driver, activar depth_registration, en rviz escoger como topics /camera/depth_registered/points y color transformer RGB8. ▪ Aparentemente, las imágenes con profundidad son especulares, se ven reflejadas de izda a dcha: ◦

▪ No parece que el registro se mantenga cuando se cierra ROS completamente, es decir, hay que registrar cada vez que se quieran ver ambas imágenes juntas si ROS se ha cerrado previamente. •

Para ver las imágenes sin usar rviz, que enlentece la máquina si no es potente, como el netbook: ◦ rosrun image_view image_view image:=/camera/rgb/image_color

◦ rosrun image_view image_view image:=/camera/depth/image ◦ Si se intentan ver las imágenes registradas con las image:=/camera/depth/disparity e image:=/camera/depth_registered/disparity, el driver openni da un error (ahora mismo no sé si estos datos se guardarían correctament con rosbag): ▪ Client [/image_view_1386373547072140271] wants topic /camera/depth_registered/disparity to have datatype/md5sum [sensor_msgs/Image/90da67007c26525f655c1c269094e39f], but our version has [stereo_msgs/DisparityImage/bad6b1546b9ebcabb49fb3b858d78964]. Dropping connection. ▪ Posiblemente hay una disparidad de tipos entre los topics del driver e image_view (http://answers.ros.org/question/12228/dropping-connection/)

◦ También se pueden ver las imágenes sin lanzar la Kobuki, sólo con roscore y openni, pero en ese caso no es posible registrar las imágenes. •

rosbag ◦ Grabar datos: rosbag record -O /tmp/ROS.bag /scan /tf ▪ El path y el nombre del fichero se pueden cambiar. ▪ /scan /tf son los topics de los que se guardan los datos; se pueden añadir más topics (si se van a reproducir los datos con rviz, /tf debe aparecer siempre) ▪ El tamaño inicial del buffer en rosbag es 256 Mb, pero con ese tamaño, si rviz está activado en el netbook, el buffer se llena y se van perdiendo las medidas iniciales. He probado a aumentar el buffer con la opción -b nuevo_tamaño (explicado en http://answers.ros.org/question/193857/rosbag-exits-recording-abruptly-aftermaximum-file-size-is-reached/), y estos son los resultados: • -b 1024: no se pierden datos para el bag, pero parece que se pierde el contacto con la Kobuki (aparece el error Kobuki timed out while waiting for serial…) y la base se sigue moviendo sin responder a keyop. ¡Cuidado! • -b 512: no se pierden datos para el bag, y aparentemente tampoco se pierde el contacto con el Kobuki (me ha parecido que sí, pero en seguida se ha recuperado). ◦ Recuperar datos: rosbag play /tmp/ROS.bag ▪ Debe estar lanzado roscore en otro terminal. ◦ Recuperar datos gráficamente: rosrun rqt_bag rqt_bag /tmp/ROS.bag

▪ Debe estar lanzado roscore en otro terminal. ◦ Recuperar datos de rosbag con rviz: ▪ roscore ▪ rosparam set use_sim_time true • Cuidado con esta instrucción, puede dar problemas si se sigue trabajando con el robot sin usar la simulación; mejor poner a false cuando se acabe. ▪ rosrun rviz rviz ▪ rosbag play name_of_bagfile.bag - - clock ▪ En el netbook, para reproducir el fichero hay que cerrar todas las ventanas de ROS que controlan el robot. A pesar de eso, la reproducción no tira bien y el equipo se queda bloqueado. ▪ He probado a reproducir el fichero .bag en otra máquina; hay que añadir un PointCloud2 a rviz, lanzar rosbag, y escoger entonces el topic adecuado de la PointCloud2 y como fixed frame camera_depth_frame. Reproduce correctamente hasta el final del fichero .bag. ▪ Conclusión: rviz en el netbook, sólo para lo imprescindible, nunca para guardar/reproducir datos con rosbag. •

rqt_robot_monitor ◦ Monitor que controla los principales elementos del Turtlebot (baterías, sensores básicos, etc)

◦ Usando ssh puedo lanzarlo en el PC (que tiene jade en vez de indigo) si en el netbook está lanzado el nodo del turtlebot: rosrun rqt_robot_monitor rqt_robot_monitor ◦ Documentación: wiki.ros.org/kobuki/Tutorial/Diagnostics 5) Brazo WidowX • La base móvil Kobuki debe estar encendida, ya que el brazo se alimenta de ella. Según el proveedor, posiblemente haya problemas de alimentación al trabajar con el brazo y la base a la vez, habrá que estar pendiente.

•

Los puertos usb donde se conectan Kobuki y WidowX al netbook no dan igual: aparece un error de python al lanzar tanto el roslaunch como arbotix_terminal directamente (mensaje: maximum recursion depth exceeded…) si el WidowX no está conectado al puerto que se indica en el fichero de configuración arbotix.yaml (en nuestro caso, puerto /dev/ttyUSB0), que está en $HOME/catkin_ws/src/widowx_arm-master/widowx_arm_controller/config. Lo más sencillo es conectar el usb del brazo al netbook, arrancar ROS, y una vez arrancado, conectar al netbook el usb del Kobuki (por seguridad, se puede comprobar con ls /dev -la que el Kobuki no esté conectado al ttyUSB0)

•

La documentación para trabajar con el brazo depende toda del arbotix (y no siempre está muy actualizada): ◦ http://wiki.ros.org/arbotix_python ◦ http://www.trossenrobotics.com/widowxrobotarm ◦ https://github.com/vanadiumlabs/arbotix ◦ Documentación auxiliar: ▪ http://answers.ros.org/question/188104/arbotix-m-with-dynamixel-tutorial-exampledoc/ ▪ https://github.com/RobotnikAutomation/widowx_arm ▪ http://wiki.ros.org/turtlebot_arm/Tutorials/indigo/SettingUpServos

•

Antes de lanzarlo, he tenido que irme al directorio catkin_ws y hacer source ./devel/setup.bash. Este source hay que hacerlo en cada ventana de comando en la que se vaya a trabajar con arbotix.

•

Para lanzarlo dentro de widowx_arm_controller.launch

•

Los motores dynamixel trabajan en el rango [-pi/2, pi/2] ◦ Los comandos que se pueden mandar a las articulaciones 1-5 están, por tanto, en ese rango. ◦ La pinza es diferente: funciona en un rango entre 0 y 2.5 (este último valor es aproximado, aún no he probado a cerrar la pinza completamente) ◦ Articulaciones 2-3-4, funcionan igual; articulaciones 1 y 5 son diferentes.

•

Para poder trabajar con el brazo es necesario: ◦ Comprobar con arbotix_terminal que todas las articulaciones está bien conectadas. ◦ Lanzar el controlador del WidowX con el roslaunch anterior. ◦ Hacer un rostopic list para comprobar que todos los topics del brazo están bien. ◦ Para mover una articulación (ejemplos): ▪ rostopic pub /arm_1_joint/command std_msgs/Float64 - - 0 ▪ rostopic pub /arm_4_joint/command std_msgs/Float64 - - 1.57 ◦ ¡¡La velocidad de movimiento no puede controlarse (o, al menos, no he visto aún cómo hacerlo)!! → Cuidado con la cabeza y la cara, tener siempre accesible el botón de apagado del Kobuki. ◦ Una vez hecho el movimiento, el brazo se queda en tensión. Para relajar el brazo: ▪ Forma “bruta”: parar el controlador del brazo en la ventana correspondiente, y apagar la base. (Provisional, hay que hacer más pruebas, a veces apagando la base es suficiente para algunas articulaciones, pero no para todas). ▪ Forma civilizada: usar el servicio de relax del brazo

catkin_ws:

roslaunch

widowx_arm_controller

• •

obtener el listado de servicios disponibles: rosservice list llamada a un servicio concreto (ejemplo): rosservice call /arm_5_joint/relax

•

El interfaz gráfico de arbotix (arbotix_gui) está en /catkin_ws/src/arbotix_ros/arbotix_python/bin. Se lanza llamándolo directamente desde una ventana de comandos con ./arbotix_gui, y con roscore o roslaunch del arbotix lanzado. La ventana se abre y aparece la parte izquierda con el punto rojo, pero no la derecha con los deslizadores de las articulaciones. Aparece el mensaje de error “No URDF defined, proceeding with defaults”. Ver blog (http://jafma.net/ana/theweekendarchaeologist/?p=547) para una explicación más detallada.

•

El terminal de arbotix (arbotix_terminal) está en /catkin_ws/src/arbotix_ros/arbotix_python/bin. Se lanza llamándolo directamente desde una ventana de comandos con ./arbotix_terminal. Para comprobar que todas las articulaciones están visibles, hacer un ls; si faltan articulaciones, repetir el ls. El roslaunch del controlador del brazo debe estar sin lanzar; si está lanzado, aparece este error:

6) Creación de un paquete ROS para manejar el WidowX o la base Kobuki • Para las pruebas, he creado en catkin_ws/src dos paquetes: widowx_arm_testing y kobuki_testing. Ambos se han subido a mi repositorio github (https://github.com/WeekendArchaeo/ROS). •

Para añadir un paquete nuevo que se refiera al brazo, hacemos lo siguiente: ◦ Primero, y sobre todo si eres novato con ROS, realizar este proceso en una máquina de desarrollo (no el netbook del robot) para comprobar que todo está bien hasta donde se pueda sin usar el brazo real: ▪ Crear el paquete en catkin_ws/src: catkin_create_pkg widowx_nombrepaquete std_msgs rospy roscpp arbotix_python (esas son las dependencias básicas que hacen falta por ahora) ▪ En package.xml, modificar el nombre del autor

▪ Copiar, dentro del directorio del paquete nuevo, el directorio launch que se encuentra dentro de widowx_arm_controller • Modificarlo añadiendo ▪ Crear el .cpp dentro del directorio src del nuevo paquete ▪ Modificar CMakeLists.txt, añadiendo al final: include_directories(include ${catkin_INCLUDE_DIRS}) add_executable(widowx_nombrepaquete src/widowx_nombrepaquete.cpp) target_link_libraries(widowx_ nombrepaquete ${catkin_LIBRARIES}) add_dependencies(widowx_ nombrepaquete ${catkin_EXPORTED_TARGETS}) ▪ Hacer catkin_make ▪ Hacer source ./devel/setup.bash ▪ Llamar con roslaunch nombrepaquete nombrepaquete.launch •

Para trabajar con el paquete widowx_arm_testing, ahora mismo hay que hacer lo siguiente: ◦ Lanzar el controlador del brazo: roslaunch widowx_arm_controller widowx_arm_controller.launch ◦ Lanzar el ejecutable que hemos creado: rosrun widowx_arm_testing widowx_arm_testing ◦ Lo suyo sería hacer un launch que llamase primero al controlador y luego a nuestro paquete; he creado uno, pero no va bien: aparentemente nuestro paquete se lanza antes que el controlador, y no envía los comandos por el topic.

•

El paquete widowx_arm_testing primero hace un home, es decir, pone todas las articulaciones a 0, dejando el brazo en la configuración mostrada en la imagen; después mueve cada articulación en ambos sentidos, y finalmente, relaja todas las articulaciones en el orden adecuado (hay que tener cuidado, en este caso, de que el brazo no caiga bruscamente; ver los vídeos indicados en el punto siguiente).

•

Vídeos relacionados con el paquete widowx_arm_testing: ◦ Home básico: https://www.youtube.com/watch?v=ZKKxhOrOpJI ◦ Direcciones de las articulaciones: https://www.youtube.com/watch?v=EiHU8jJHdtE ◦ Proceso completo: https://www.youtube.com/watch?v=IiFa5pgHPdo

•

Comentarios sobre el paquete kobuki_testing: ◦ Vuelvo a repetir: ¡¡cuidado con las velocidades del robot, no mover a más de 0.2!! (Igual yo también soy un poquito exagerada con la seguridad :)) ◦ Lo he creado con catkin_create_pkg kobuki_testing std_msgs rospy roscpp ◦ Para saber qué topics y mensajes usar: ▪ Topics: rostopic list (no coincide exactamente con la documentación de http://wiki.ros.org/kobuki/Tutorials/Examine%20Kobuki, sólo hay cuatro topics de sensores: core, dock_ir, imu_data e imu_data_row) ▪ Mensajes: rostopic info nombretopic. A partir de ahí, buscar directamente el mensaje. Algunos mensajes están en: • https://github.com/yujinrobot/kobuki_msgs/tree/indigo/msg • https://github.com/yujinrobot/kobuki_msgs ◦ Para probarlo, debe estar lanzado roslaunch kobuki_node minimal.launch --screen, ya que es el que crea todos los topics para comunicarse con la base. ◦ Los nuevos datos se van guardando al final del fichero, cuidado con mezclar experimentos sucesivos. ◦ Acostumbrarse a los mensajes y campos de los mensajes puede ser lioso, aquí van algunos enlaces útiles: ▪ https://github.com/yujinrobot/kobuki_msgs/blob/indigo/msg/SensorState.msg ▪ http://docs.ros.org/diamondback/api/rostime/html/classros_1_1Time.html ▪ http://docs.ros.org/jade/api/std_msgs/html/msg/Header.html ▪ https://github.com/ros/std_msgs/blob/groovy-devel/msg/UInt32.msg