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 necesitamos guardar otros archivos que no son código. Por ejemplo, si estamos diseñando 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.

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 una 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, hoy nos permite usar ese archivo en lugar del binario dentro del repositorio. En este post voy a dar dos ejemplos de uso de este truco: ficheros de FreeCAD y bases de datos de SQLite.

Archivos de FreeCAD

Este truco lo aprendí de Jaime 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 que, como 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 escribimos un archivo .gitattributes con el siguiente contenido:

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

Este archivo lo que le dice a git es que los archivos con la extensión *.FCStd o *.fsctd (archivos 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 tiene realizar para poder acceder al texto plano, tenemos que crear un archivo .gitconfig en el que explicaremos a git qué hacer con un archivo zip:

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

Este archivo lo podemos instalar a nivel de un repo concreto, editando el archivo .git/config dentro de nuestro repo y añadiendo esas líneas. También podemos optar por instalarlo a nivel global para todos nuestros repos, 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 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.

La semana pasada tuvieron lugar las XXX Jornadas Técnicas del GUL. Alguien había propuesto una charla de diseño en FreeCAD, para la cual no apareció ningún ponente, así que me ofrecí voluntario. Mi idea era dar la típica charla introductoria a FreeCAD, pero Julián Caro me dio la idea de hablar de diseño paramétrico, y ese se convirtió en el tema de la charla.

La charla transcurrió sin incidentes, y aunque no dio tiempo a hacer todos los ejemplos, la gente se fue contenta. Muchos quedaron sorprendidos de la potencia de FreeCAD y del software paramétrico. Desde aquí me gustaría dar las gracias a la gente del GUL por preparar un evento de la talla de las Jornadas Técnicas y por darme la oportunidad de contribuir a ellas con un taller.

Para los que se quedaron con ganas de más, aquí están las diapositivas de la charla, y en este repo están los ejemplos para practicar en casa.

En mi anterior post compartí un tutorial de Git que había redactado como guía para los nuevos de las asociaciones ASROB y UC3Music, y que publiqué de forma abierta por si le resultaba útil a alguien más.

Al compartir el tutorial por Twitter, me llevé una grata sorpresa al ver que había mucha gente a la que le había gustado la iniciativa:

Mi filosofía es que sólo se aprende realmente haciendo cosas, poniendo en práctica lo que se lee. Y qué mejor forma de motivarse y poner en práctica esos conocimientos que un reto. Por ello os propongo el reto “Troll My Repo” (trolea mi repo).

La idea es simple: perder el miedo a colaborar con un proyecto haciendo que el proyecto en el que colaboras sea totalmente absurdo. Un repositorio creado específicamente para ser “troleado”, en el que las equivocaciones no importan en absoluto porque el contenido no tiene demasiado sentido.

¿El objetivo? Que el mayor número de personas pierdan el miedo a usar Git y colaborar. Los repositorios de GitHub tienen un apartado de contribuidores, queremos que ese número sea el más alto posible.

¿Cómo puedo participar? Muy simple. Sigue el tutorial de Git y completa los siguientes pasos:

  1. Haz un fork del repositorio troll-my-repo en que subir tus cambios.
  2. Añade lo que quieras al repositorio. Archivos de texto, imágenes, lo que sea. O cambia algo del repositorio. Si no se te da bien lo de imaginarte formas de “trolear” el repositorio, puedes simplemente escribir “X estuvo aquí” en el archivo README.md (poniendo tu nombre o alias en la X, claro).
  3. Sube los cambios a tu fork, y haz un pull request al repositorio principal. En unas horas tendrás tus cambios integrados en el repositorio troll-my-repo, y habrás contribuído a tu primer proyecto en GitHub, !Enhorabuena!