Tenemos el placer de anunciarles el lanzamiento de la web del proyecto CRUMB 🙂
We proudly announce the launching of the CRUMB project website 🙂
¡¡Hola CRUMB :)!!
Mini tech report: Turtlebot + WidowX
Bueno, finalmente ya está disponible (como informe técnico) en Academia y ResearchGate un documento sobre nuestros primeros pasos con Turtlebot + WidowX.
Well, finally we have uploaded (as a tech report) to Academia and ResearchGate some documentation about our first steps with Turtlebot + WidowX arm.
¡Feliz Navidad! Merry Christmas!!
Finalmente, hemos dejado cerradas las primeras pruebas unitarias del Turtlebot con el WidowX. En el vídeo al final del post puede verse al brazo realizando un home (con la pinza funcionando), moviendo cada articulación en ambos sentidos, y relajando cada articulación. El código completo está en mi GitHub. Así que, con la satisfacción del deber cumplido… ¡¡Feliz Navidad :)!!
Finally, we have finished the first unit tests of our Turtlebot with the WidowX on board. The video at the end of this post shows the robot homing (with the gripper opening and closing), moving each joint in both directions, and relaxing each joint. The code can be downloaded from my Github. So, with the satisfaction of the duty fulfilled… Merry Christmas )!!
WidowX + ROS: joints directions
Seguimos con las pruebas unitarias del brazo WidowX, y ahora nos hemos centrado en ver cuáles son los sentidos de movimiento de las articulaciones 1 a 5, partiendo del “home” que hicimos anteriormente. El código se ha añadido a las pruebas unitarias iniciales (fichero widowx_arm_testing.cpp en mi GitHub).
We keep on working on the unit tests for the WidowX arm, but now we have focused on the direction of movement for joints 1 to 5, assuming that the robot is in the “home” position as we explained before. The code has been appended to the first unit tests (file widowx_arm_testing.cpp at my GitHub).
Turtlebot 2 movement analysis
Ahora que ya tenemos el Turtlebot 2 andando, hemos querido caracterizar los motores cuando se mueven con la carga inicial del robot. Para ello, hemos seguido los siguientes pasos, que están documentados en el vídeo al final del post; en mi repositorio de GitHub está el código C++, Matlab y R:
- Hemos creado un nodo ROS que mueve al robot con velocidad lineal x=0.1 m/sec, y almacena en fichero las medidas de los encoders de ambos motores junto con dos marcas de tiempo: las asociadas a los mensajes ROS, y las grabadas por la base Kobuki.
- Después, analizamos las medidas con Matlab.
- Primero, hemos representado gráficamente las medidas de los ticks frente a los dos tipos de marcas de tiempos (tanto relativas como absolutas).
- En segundo lugar hemos representado la velocidad de cada rueda, entendiendo velocidad como la relación entre ticks y variación de tiempo. En el vídeo se observa que la velocidad aparece como rads/sec; para hacer la transformación nos hemos basado en las especificaciones de la base Kobuki. Si manualmente se hace el cálculo V = r*ω se observa que todo es correcto.
- En tercer lugar, aprovechando la Control Toolbox de Matlab, hemos hecho una identificación de los motores de las ruedas usando un método de aproximación mediante sistemas de primer orden con retraso. La K y la τ obtenidas se han tomado como base para hacer después un reajuste manual, que se adapta bastante bien a los datos reales (sobre todo en el caso del motor derecho).
- Finalmente, hemos hecho una representación muy básica (aún sin usar ggplot2, estamos trabajando en ello 😉 ) en R.
Now that our Turtlebot moves, we have characterized its motors when they are moving bearing the initial load of the robot. We have followed these steps, which are documented in the video at the botton of this post; my GitHub repository stores the C++, Matlab and R code:
- We have created a ROS node that makes the robot move with a linear x speed=0.1 m/sec, and then writes to a file the measurements of both encoders along with two timestamps: those related to ROS messages, and those taken by the Kobuki base.
- Then, we have analysed the data using Matlab.
- First, we have plotted the ticks values versus both timestamps (both relative and absolute).
- In the second place, we have plotted the speed of each wheel, where speed is the relationship between ticks and time difference. You can see in the video that speed is represented as rads/sec; we transformed the values using the Kobuki mobile base specifications. If you do your maths by hand (V = r*ω), you will see that calculations are correct.
- In the third place, using the Control Toolbox provided by Matlab, we did the identification of both motors with an approximation using a first order system with delay. The resulting K and τ are the basis for a manual recalculation, which fits quite well to the real data (especially, for the right motor).
- Finally, we prepared a very basic R plotting (still without ggplot2, but we are working on it 😉 )
R + Arduino + ROS
Como ya comenté en un post anterior, es posible integrar Arduino dentro de ROS. Por otra parte, hay un paquete rosR muy interesante que permite crear scripts R trabajando también en ROS; la documentación del paquete es completa y cubre tanto la parte ROS como la parte R:
Combinando ambos paquetes se pueden hacer cosas majas. Por ejemplo, en el vídeo al final del post se muestra cómo un nodo ROS envía las lecturas de un sensor FSR conectado a un Arduino (Duemilanove, en este caso) por un topic al que está suscrito un script R que muestra un plot con esos valores sobre la marcha. El código del sketch y del script, basados en los ejemplos proporcionados en la documentación de ambos paquetes, están en mi Github.
En este caso, he usado la máquina virtual Nootrix con ROS indigo 32, ya que me resulta útil por motivos docentes. La misma combinación Arduino-R también funciona correctamente en un Xubuntu 14.04.3 de 64 bits con ROS indigo instalado.
Por probar, he compilado la versión 64 bits de rosR en un Ubuntu Mate 15 con ROS jade distribuido entre un portátil y el netbook del Turtlebot, y también funciona… ¡¡Turtlebot, R te espera :)!!
As I commented in a previous post, it is possible to use Arduino with ROS. Furthermore, there is a very interesting rosR package that allows to build R scripts also in ROS; the documentation of this package is complete and covers the ROS point of view as well as the R perspective:
You can build nice things using both packages. For example, the video at the bottom of this post shows how a ROS node sends the readings of a FSR sensor connected to an Arduino (Duemilanove, in this case) through a topic; a R script which is subscribed to that topic plots those values on the fly. The code of the skecth and the script, based on the examples provided in the documentation of both packages, is in my Github.
You can see in the video that I use the Nootrix ROS indigo 32 virtual machine, since I find it useful due to teaching reasons. The same Arduino-R combination also works fine under a Xubuntu 14.04.3 64 bits with ROS indigo.
I tried to compile the rosR 64 bits version under Ubuntu Mate 15 with a ROS jade distributed between a desktop and the Turtlebot netbook, and it also works… Turtlebot, R is waiting for you 🙂
WidowX+ROS: Primeras pruebas unitarias / First unit tests
Como comenté en el post anterior, estamos trabajando con un brazo WidowX instalado sobre un Turtlebot. Estas son las muy primeras, muy iniciales y muy parciales pruebas 🙂 que hemos realizado: un “home” básico, en el que las articulaciones de la 1 a la 5 se posicionan en 0º. Por si fuera de utilidad, este código de prueba está disponible en mi GitHub, y poco a poco iremos añadiendo pruebas más complicadas. Está preparado para trabajar con el software ROS para WidowX de Robotnik Automation.
Ahora mismo, las articulaciones no se relajan desde código; para lograrlo, llamar desde consola al servicio de relax de las articulaciones; por ejemplo, rosservice call /arm_5_joint/relax
As I commented in the previous post, we are working with a WidowX arm fixed on a Turtlebot 2. These are the very first, very preliminar and very partial tests 🙂 we have performed: a basic “home”, with joints from 1 to 5 set to 0º . In case it could be useful, I have uploaded this code to my GitHub, though we will keep adding more tests. The code is prepared to work with the ROS software for WidowX created by Robotnik Automation.
Right now, joints are not relaxed from code; to do this, you should call from console to the relax service of every joint; for example, rosservice call /arm_5_joint/relax
WidowX + Arbotix + ROS Indigo
Estamos trabajando con el brazo WidowX instalado en nuestro Turtlebot 2. El brazo utiliza los drivers de Arbotix para ROS Indigo. Estas son las diferencias encontradas con la documentación original de la web:
- La instalación desde apt-get no funciona, ya que cuando se crea el paquete aparecen errores. Es mejor descargar los drivers desde el github de Vanadium. Si se va a escoger sólo una parte de los drivers, es necesario asegurarse que se bajan todos los paquetes ROS necesarios; por ejemplo, no debería faltar el paquete de mensajes de arbotix.
- El código fuente se copia al directorio de trabajo de ROS (en mi caso, que uso el directorio típico creado por ROS, /home/catkin_ws/src). Luego se crea como cualquier otro paquete ROS usando catkin_make .
- El paquete arbotix_python también presenta diferencias con la documentación de ROS. Una vez creado el paquete, en el directorio_de_trabajo/src/arbotix_python/bin aparecen tres ficheros: arbotix_driver, arbotix_gui (en lugar de controllerGUI.py) y arbotix_terminal (y no terminal.py)
- arbotix_terminal debe lanzarse tal cual, es decir, ejecutando ./arbotix_terminal sin lanzar roscore.
- arbotix_driver y arbotix_gui necesitan lanzarse en ROS, es decir, con roscore ejecutándose.
- arbotix_gui, además, parece venir preparado para un modelo URDF/XACRO concreto que no encuentra, ya que al ejecutarlo no aparecen las articulaciones del brazo en el interfaz gráfico que se abre, y en la ventana de comandos se muestra el error No URDF defined, proceeding with defaults. Bicheando un poco en el código, he visto que arbotix_gui llama a la función getJointsFromURDF, que está en directorio_de_trabajo/src/arbotix_python/joints.py y que carga el parámetro robot_description con el modelo URDF que utilizará. He intentado modificar este parámetro robot_description con otro modelo llamando a rosparam set /directorio_del_modelo/modelo.xacro (roscore debe estar lanzado), pero, aunque getJointsFromURDF sí encuentra este nuevo modelo, el resto del código de la función no está, aparentemente, preparado para él, así que por ahora voy a dejarlo y a centrarme en la programación del brazo que realmente necesitamos.
We are working with the WidowX arm set on our Turtlebot 2. This arm uses the Arbotix drivers for ROS Indigo. These are the differences with the documentation in the web:
- Installation from apt-get does not work: errors arise when the package is created. The best option is to download the drivers from the Vanadium repository at github. If you download just a subset of the drivers, make sure that you choose all the basic ROS packages; for example, don’t forget to download de arbotix messages package.
- All the source code should be copied to the ROS workspace (for example, I use the default workspace created by ROS, so I put it into /home/catkin_ws/src). After that, the package is created like any other ROS package with catkin_make .
- arbotix_python package has also differences with ROS documentation. Once the package is created, three files are stored in your_workspace/src/arbotix_python/bin folder: arbotix_driver, arbotix_gui (instead of controllerGUI.py) and arbotix_terminal (not terminal.py)
- arbotix_terminal runs “stand alone”, i.e., calling to ./arbotix_terminal without a launched roscore.
- arbotix_driver and arbotix_gui must be run within ROS, i e., with a running roscore.
- Furthermore, arbotix_gui waits for a specific URDF/XACRO model that cannot find: the gui does not open all the joints of the arm, and the command window shows error No URDF defined, proceeding with defaults. Tracing the code, I found that arbotix_gui calls to function getJointsFromURDF in your_workspace/src/arbotix_python/joints.py, which in turn loads the robot_description parameter, that stores the URDF model used by this function. I tried to set another model in this parameter, running rosparam set /model_folder/model.xacro (roscore must be running), but, though getJointsFromURDF does find this new model, the rest of the code of this function is not prepared to work handle it, so by now I am going to skip this question and move to the programming of the arm that we really need.