Hoy aprendí #4

En Eryx nos gusta compartir el conocimiento y eso es lo que hacemos en Hoy Aprendí. Descubrí tips e insights claves de nuestro equipo técnico para aplicarlos en tu día a día.

Trackeando objetos en el mundo real

por Maxi Suppes y Lucas Rodriguez

Contexto

¿Qué herramientas tenemos para trackear la posición de un objeto de manera simple?

Hoy en día existen múltiples tecnologías que nos permiten realizar esta tarea cómo los tags RFID o sistemas basados en radiofrecuencia (RTLS). Todas estas opciones tienen una desventaja: requieren no sólo dominar e implementar una determinada tecnología, sino también tener un componente electrónico para cada uno de los objetos que necesitamos seguir.

Una alternativa más sencilla y escalable es generar un código QR que represente el objeto que queremos seguir y pegarlo al mismo. De esta manera, podríamos utilizar una cámara para “buscar” el QR que pegamos al objeto y, a partir de esto, inferir su posición dentro de un ambiente conocido.

Los códigos QRs son útiles para codificar información en general y son utilizados para una gran cantidad de aplicaciones que van desde credenciales para conectarnos a una red Wi-FI hasta el visualizar el menú de una cafetería.

Problema

Si bien esta es una buena solución para muchos casos de uso, algunas condiciones del entorno podrían impedir la correcta lectura del código. La luminosidad, la resolución de la cámara, la distancia a la que se encuentra del objeto o la velocidad del obturador, son parámetros importantes a la hora de lograr una identificación y decodificación exitosa del QR.

¿Qué sucede si, además de las condiciones ya mencionadas, el objeto está en movimiento?

#FiducialMarkers - QR Output no detectado

Cuando analizamos los cuadros obtenidos por la cámara (como se ve en la imagen), nos encontramos con un efecto conocido como Motion Blur. Este efecto hace imposible decodificar el QR y, por lo tanto, identificar la posición del objeto.

Solución

Para resolver este problema, podemos usar otros códigos que ofrecen ventajas significativas cuando las condiciones del entorno no son las ideales.

Un marcador de referencia (o fiducial) es un patrón visual que proporciona puntos de referencia en el entorno físico sobre los cuales se puede calcular la posición relativa respecto a una cámara u otros objetos en el espacio tridimensional. Esto es útil en una variedad de aplicaciones de visión por computadora, realidad aumentada, robótica y, en particular, el seguimiento (trackeo) de un objeto.

Existen distintos tipos de fiducial markers

Dependiendo de la aplicación, algunos funcionan mejor en términos de robustez frente a la oclusión, ángulo de la cámara, condiciones de luz, desenfoque de movimiento, rapidez para decodificar la información, etc. En general los fiducial markers no contienen ninguna información definida por el usuario en la etiqueta, sino que son IDs predefinidos y acotados.

Si bien tienen la apariencia de un QR tradicional, los fiducials tienen una resolución más baja y, por lo tanto, pueden ser detectados a distancias mayores.

#FiducialMarkers - Stag output

Como puede verse, utilizando esta variante a los clásicos QRs, podemos resolver un problema muy común en los sistemas de visión por computadora cuando debemos trabajar en ambientes no ideales.

Yaml y sus ayudas

Por Laski

Hoy aprendí, por las malas, que YAML tiene un sistema de tipado “flexible” que intenta ayudarte interpretando tus intenciones. Por ejemplo, si escribís:

holu

en yaml “sabe” que es un string aunque no le pongas comillas. Si escribís:

34

sabe que es un int. Y si escribís:

true

sabe que es un bool (obvio que lo mismo pasa con false).

En algunas ocasiones es muy práctico pero en otras puede entorpecer el proceso: ya me pasó un par de veces querer escribir el string “true” (no el valor booleano verdadero, sino el string compuesto por cuatro caracteres) y tener que ponerlo entre comillas sí o sí, lo cual obviamente me obliga a poner entre comillas todos los demás strings porque “A foolish consistency…” etc. Pero en otras ocasiones es directamente contraproducente. Como me pasó recientemente.

Para quienes no lo conocen, Helm es un programa que te permite, entre otras cosas, crear YAMLs a partir de ciertos “templates” con valores dinámicos. Por ejemplo esta línea en donde la versión de un deployment se genera a partir del “SHA corto” del commit.

version: {{ .Values.application.commit_short_sha }}

¿Tiene sentido no? El SHA corto en general son los primeros ocho caracteres del “nombre” de un commit, es decir que si el commit es por ejemplo:

e83c5163316f89bfbde7d9ab23ca2e25604af290

su SHA corto es:

e83c5163

Esa línea de Helm funcionó bien por AÑOS hasta que hoy un commit inofensivo rompió el pipeline de deploy con un error de sintaxis rarísimo. El commit era:

7047461054ba7ca0ae3a1dc7f4b5f6870b78f398

¿Notan algo curioso? El SHA corto del commit está compuesto enteramente por números. El valor de la versión, en mi pipeline, tenía que ser siempre un string pero cuando YAML ve solo números asume que es un int.

Resultado: un pipeline roto y el “syntax error” más esotérico que encontré en mucho tiempo.

Seguinos también en Instagram y LinkedIn.