Arduino Day Zaragoza 2018

El pasado 6 de Abril asistimos al Arduino Day Zaragoza 2018. Pablo nos invitó a JorFru y a mi a dar un taller de Drawdio durante el evento. Junto a nosotros viajaron otros tantos makers madrileños que no quisieron perderse este evento.

Corriendo hacia el coche
Julián y yo corriendo hacia el coche con las provisiones para el viaje

Al llegar allí tras un largo viaje nos encontramos unas instalaciones fabulosas y unos organizadores muy majos que nos enseñaron lo que tenían preparado para el día siguiente. Estuvimos compartiendo experiencias y jugando con sus robots de combate de globos, a los que JorFru les puso cámara para poder manejarlos en primera persona. Tras la cena seguimos frikeando nos fuimos a la cama para estar listos para el día siguiente.

Aforo completo
¡La feria estaba a rebosar de gente!

El día siguiente lo comenzamos asistiendo a las charlas de Robots con Patas de Javier Isabel y Robots, gatitos y FPGAs libres donde Julián nos habló de sus robots bioinspirados con osciladores. Siempre es un placer escucharles hablar porque saben transmitir perfectamente la pasión que sienten hacia sus trabajos y hacia los robots en general y enganchar al público. Tras estas charlas hicimos un descanso para visitar algunos stands como los de Akirasan, OPRobots o el de Rubén donde pudimos ver todos sus robots de competición, incluyendo a Pumatrón (que creo que es el robot siguelíneas más rápido que he visto en persona).

Tras la comida, dimos nuestro taller. La mayoría de los asistentes al taller fueron niños y sobre todo niñas pequeñas, que no tuvieron miedo alguno a la hora de coger el soldador y ponerse a montar sus Drawdios. ¡Ojalá que a muchas de ellas les haya picado el gusanillo maker y continúen investigando y construyendo cosas!

El día acabó con el esperado combate de robots a muerte. Mucha espectación por ver quién ganaría finalmente el torneo y si los perdedores volverían a casa enteros o por partes, y los participantes estuvieron a la altura de las espectativas. Aunque (spoiler alert!) la mayoría volvió a casa en cachitos muy pequeños.

Tras la feria nos fuimos a cenar a un bar cercano, donde pusimos a prueba nuestras habilidades maker secuestrando la tele (la culpa fue de Melendi) y jugando a juegos improvisados con el tragómetro de Nuria.

JorFru y yo con unas cervezas
JorFru y yo con unas cervezas Ámbar

Desde aquí me gustaría agradecer a todos los organizadores del Arduino Day Zaragoza por el curro que se han pegado organizando este pedazo de evento, y sobre todo por invitarnos y por lo bien que cuidaron de nosotros durante nuestra estancia en Zaragoza. Y también a todos los makers que estuvieron por allí haciendo que lo pasáramos genial, ¡sois unos cracks!

Ejes de coordenadas impresos en 3D

Este curso he comenzado a impartir clases de robótica industrial en la universidad como parte de mi doctorado. Una de los primeros conceptos que se enseñan en esta asignatura es el de sistema de coordenadas, puntos y orientaciones en esos sistemas de coordenadas, y cómo realizar transformaciones entre distintos sistemas de coordenadas.

Recuerdo que, como alumno, una de las partes más complicadas de esta asignatura era el conseguir imaginarse todas las transformaciones geométricas (rotaciones, translaciones, etc) de los distintos sistemas de referencia. Una vez eras capaz de visualizar en tu mente la transformación, expresarlo numéricamente era bastante sencillo. Por ello, y para ayudar a mis alumnos a imaginarse las distintas transformaciones (y para evitar perderme mientras explico, para qué nos vamos a engañar…) decidí diseñar e imprimir en 3D unos ejes de coordenadas sencillos. Las partes de las flechas encajan a presión, aunque se puede añadir un poco de pegamento de contacto para mejorar la unión. Las flechas se unen al núcleo también por presión, y disponen además de huecos en los que colocar imanes de neodimio de 12x2mm para facilitar el desmontaje y que se puedan guardar fácilmente.

Ejes de coordenadas desmontados

Los archivos y las fuentes de FreeCAD se encuentran disponibles en Thingiverse y YouImagine para que el que quiera se las baje y se las pueda imprimir y adaptar a sus necesidades:

Git es un sistema de control de versiones ideal para guardar el código de nuestros proyectos en distintas etapas de su desarrollo. Pero a veces, para nuestros proyectos, necesitamos guardar otros archivos que no son código. Por ejemplo, si diseñamos una placa o un robot, querremos guardar también las fuentes de los esquemáticos de la placa o de las piezas que lo componen.

Octocat al rescate!

Git fue diseñado para almacenar código fuente, que normalmente se guarda en archivos de texto. La forma que tiene Git de guardar internamente las distintas versiones del código es analizando los ficheros de texto y guardando los cambios de una versión a la siguiente. De esta forma, aunque el código sea muy largo, si sólo cambiamos una línea el repositorio no guardará dos copias de nuestro código (que serían idénticas salvo por esa línea), sino el archivo original y la línea cambiada. Con esta información git es capaz de reconstruir ambas versiones. Eso está muy bien si lo que queremos guardar son archivos de texto, pero deja de funcionar cuando lo que guardamos son archivos binarios como imágenes o archivos de FreeCAD. En este caso, cada vez que hacemos cambios en los archivos git no es capaz de analizar cuáles han sido los cambios de una versión a otra, y guarda ambos archivos. Esta es la razón por la que los repositorios en los que guardamos imágenes crecen tanto de tamaño en disco.

No obstante, en algunos casos hay solución. Si tenemos alguna forma de obtener un archivo de texto a partir del binario que queremos guardar, git nos permite usar ese archivo en lugar del binario dentro del repositorio. En este post voy a dar dos ejemplos de casos de uso para este truco: ficheros de FreeCAD y bases de datos de SQLite.

Archivos de FreeCAD

Este truco lo aprendí de Jaime García Villena (elgambitero) cuando ambos trabajábamos en BQ. En aquella época Jaime, que es un mago del FreeCAD, se encontraba trabajando en la Sunrise, una impresora de resina libre. Durante el desarrollo guardaba el progreso en un repositorio de git el cual, debido a que los archivos de FreeCAD son binarios, comenzó a crecer desorbitadamente de tamaño. Investigando un poco descubrimos que los archivos de FreeCAD no eran más que varios archivos de texto comprimidos en un archivo Zip, entre ellos un XML con los datos del diseño mecánico. Esto significa que, si git fuese capaz de descomprimir el archivo Zip y analizar ese archivo de texto, podría guardar sólo las diferencias entre versiones, ahorrando un montón de espacio en disco. Y lo grande de git es no solo que puede, sino que resulta que esto se tuvo en cuenta al programarlo, por lo que no hace falta hackear git para conseguirlo. Sólo hay que editar un par de archivos de configuración.

Primero, tenemos que especificar qué tipo de acción queremos ejecutar cuando git se encuentre con un archivo de FreeCAD. Para ello creamos un archivo .gitattributes con el siguiente contenido:

*.FCStd diff=zip
*.fcstd diff=zip

Este archivo lo que le dice a git es que los ficheros con la extensión *.FCStd o *.fsctd (propios de FreeCAD) debe tratarlos como archivos comprimidos zip. Pero git no sabe todavía cómo descomprimir un zip. Para especificar la acción que git debe realizar para poder acceder al texto plano, tenemos que crear un archivo .gitconfig en el que explicaremos a git qué hacer con un zip:

 [diff "zip"]
 textconv = unzip -c -a

Este archivo lo podemos instalar a nivel de un repositorio concreto, editando el archivo .git/config dentro de nuestro repositorio y añadiendo esas líneas. También podemos optar por instalarlo a nivel global para todos nuestros repositorios, editando el archivo ~/.gitconfig.

Bases de datos de SQLite

El otro caso de uso en el que este truco nos puede resultar útil es con bases de datos SQLite. En mi caso, me interesaba tener una copia de seguridad diaria de una base de datos SQLite, pero no quería guardar cientos de copias de la misma base de datos. Ya que es incremental, pensé en git para guardar la copia de seguridad, pero las bases de datos de SQLite son binarias. Solución: usar el comando dump para convertir la base de datos en un archivo de texto con los comandos SQL que generan esa base de datos. De esta forma el repositorio puede guardar los cambios en los comandos SQL.

En este caso los cambios a realizar son parecidos al caso anterior. Primero tenemos que crear el archivo .gitattributes que le dice a git que trate los archivos con extensión *.sqlitecomo bases de datos de sqlite3:

*.sqlite diff=sqlite3

Y luego definimos en el archivo .git/config (o ~/.gitconfig) lo que debe hacer con una base de datos de sqlite3 para extraer una versión de la base de datos en texto plano (usar el comando dump de sqlite):

[diff "sqlite3"]
textconv = echo ".dump" | sqlite3

¡Y más!

Todo esto se puede aplicar a cualquier fichero que se pueda convertir en un archivo de texto plano, como por ejemplo un archivo *.docx, que no es más que un archivo zip con archivos xml dentro. No hay más que adaptar los ejemplos de este post con los comandos necesarios para el tipo de archivo en el que estés interesado.

Referencias

  • https://github.com/gvJaime/Sunrise
  • https://ongardie.net/blog/sqlite-in-git/

La M Prime One es una impresora 3D diseñada por Diego Trapero. Desde que la ví en persona en la Maker Faire Madrid me enamoré de su diseño, y me entró un tremendo SAV (Síndrome del Ansia Viva) por tener una. Así que, cuando Diego la puso en oferta, ya no me quedaron excusas para no tener una y me la acabé comprando. Al montarla tuve algunos pequeños problemillas, pero pedí ayuda a Diego y me dió un soporte excelente. Sin mucho esfuerzo mi M Prime estaba ya empezando a imprimir sus primeras piezas.

Uno de los problemas que más me ocurrió fue que el autonivelado no funcionaba bien, y a veces la punta bajaba demasiado y chocaba con la base al imprimir. Observando un par de impresiones, me di cuenta de que en la secuencia de autonivelado, cuando la punta baja sobre varios puntos para medir la base y calcular el plano real de la base algo iba mal. En una de las esquinas la punta bajaba demasiado al aproximarse al punto de muestreo y no medía el punto correctamente. Pensaba que era un fallo que sólo le ocurría a mi impresora, pero el otro día en el taller de zowimanoides de ASROB Rosa nos trajo su M Prime para que le echásemos un ojo, y le sucedía exactamente lo mismo. Como la solución es sencilla, y puede que le solucione la vida a más gente con una M Prime, he hecho este post explicando cómo arreglarlo.

Como he dicho, la solución es sencilla: aumentar la distancia a la que sube la punta en cada punto antes de medir la distancia a la base. Los pasos para llevar a cabo este cambio son los siguientes:

  1. Instalar, si no se tiene ya instalado, el entorno de Arduino y los drivers correspondientes.
  2. Ir al repositorio online de la M Prime y descargarlo. Nos interesan los archivos del firmware, que están en la carpeta firmware/Marlin.
  3. Abrimos el código descargado con el entorno de Arduino. Tenemos que realizar las siguientes modificaciones al código:
    • Archivo firmware/Marlin/Configuration.h: modificar la línea 549, cambiando el valor de 5mm a 1mm:
       #define Z_PROBE_DEPLOY_HEIGHT 1 // Raise to make room for the probe to deploy /
      
    • Archivo firmware/Marlin/Configuration_adv.h: modificar la línea 316, cambiando el valor de 2mm a 5mm:
       #define Z_HOME_BUMP_MM 5
      
  4. Subir el código modificado al Arduino Mega de la impresora.

Y ya está. Una vez hechos esos cambios, mi M Prime One empezó a funcionar genial, y no me ha vuelto a dar nada de guerra. ¡Ahora es darle a “imprimir” y listo!

Conferencia ICARSC 2017

La semana pasada asistí a la International Conference on Autonomous Robot Systems and Competitions (ICARSC), que tuvo lugar del 26 al 28 de Abril en Coimbra, Portugal.

Fui junto con mis compañeros de laboratorio a presentar nuestros trabajos, que habían sido aceptados en la conferencia. Concretamente, yo presenté dos de mis trabajos sobre manipulación y percepción de prendas con robots: uno sobre desdoblado de ropa y otro sobre planchado automático mediante robots. Pasé unos días geniales junto a mis compañeros de laboratorio, compartiendo risas y buenos ratos, y también madrugones y caminatas interminables por la ciudad. Coimbra, pese a sus muchas cuestas, es realmente bonita.

Nosotros haciendo un poco el gandul
Nosotros haciendo un poco el gandul.

Una vez presentados los artículos, los organizadores nos llevaron a visitar la Universidad de Coimbra y a cenar. Tras la cena de gala, los organizadores anunciaron los artículos premiados de la conferencia. Uno de los trabajos que presenté, “Improving and Evaluating Robotic Garment Unfolding: A Garment-Agnostic Approach”, fue seleccionado y se le concedió el Best Student Paper Award, lo que puso la guinda a un gran día.

Posando con el diploma
Posando con el diploma.

Este pequeño post quería dedicárselo a mis compañeros, a los co-autores del artículo premiado y a todas las personas que están siempre ahí cuando se las necesita, porque sin ellas no habría sido posible este premio. ¡Muchas gracias, chic@s!

Foto de familia con la furgoneta, en la que pasamos bastantes horas de viaje.
Foto de familia con la furgoneta, en la que pasamos demasiadas muchas horas de viaje.