Se supone que el título debe ser original, captar la atención del lector, así que he copiado el que mi mujer utilizó en su libro “Cómo sobrevivir a una mediación familiar” y, lo cierto es que el verbo sobrevivir es bastante preciso.
Lo que no se de las aplicaciones de visión artificial
Lo que voy a intentar es explicar en qué consiste la parte que no se ve de las aplicaciones de visión, aquello a lo que nunca se le da importancia y que, a la postre, es tan importante como el resto: una cadena se rompe siempre por su eslabón más débil.
Y en este caso, como en tantos otros, el eslabón débil somos nosotros, los humanos. Nosotros somos los responsables de no escoger la tecnología adecuada, o de no definir correctamente el proyecto, de no planificar adecuadamente y, lo peor de todo, de enrocarnos cuando salta el problema.
Imaginemos una tarta, en el centro hay una gran guinda (la guinda del pastel). Esta guinda es la tecnología, el hardware o el software que hayamos escogido para resolver la aplicación. Ahora recortamos la parte que se corresponde con la guinda y la retiramos. Nos queda un donut.
De este donut es del que quiero hablar. Nada de 2D ni de 3D ni siquiera de complejas librerías de análisis de visión o de Deep Learning. Acerca de esto podemos encontrar decenas de artículos muy buenos, pero del donut… nada.
¿Qué se supone que es el donut? El donut es todo lo demás. Una vez quitamos el hardware y la parte puramente de análisis de la imagen, todo lo demás:
- Arquitectura: cómo se organizan todos los elementos que intervienen (punto clave).
- Comunicaciones: PLC, Robot, IT, otras aplicaciones, etc.
- Gestión del proceso: en qué momento y en qué orden se realiza cada una de las operaciones, cómo se gestionan los resultados, diferentes casuísticas, etc.
- Gestión de la información: registros de eventos, errores, imágenes, resultados, etc.
- Supervisión del sistema: control de errores, disponibilidad de equipos o dispositivos, etc.
- Otros.
Las aplicaciones PAR
Evidentemente, hay muchos casos en los que este apartado se puede resolver en cinco minutos, son las aplicaciones PAR (Picture, Analyse, Respond).
Imaginemos una impresora que imprime la fecha de caducidad en la caja de un medicamento. Detrás de la impresora siempre hay una cámara que verifica que la impresión sea correcta (legible y con la información adecuada). En este caso, si el tiempo de análisis del software es menor que el tiempo de impresión, no hay gran cosa a tener en cuenta excepto la comunicación con la línea de proceso para que pueda descartar las cajas que no se puedan leer adecuadamente o que tengan información incorrecta.
Aún y así, hay que dedicarle 5 minutos. A parte de definir de qué modo comunican cámara/PC y línea de proceso (contactos libres de potencial, Profinet, Modbus/TCP, …) es importante definir una comunicación sólida. Aunque sea un caso muy simple, ilustra el concepto.
Si la cámara responde con una señal cada vez que una caja está mal impresa y debe ser expulsada, podemos tener un problema si el sistema falla, se queda colgado, el cable falla en su conexión… Podría darse el caso de que no recibiéramos la señal que indica que la caja tiene una impresión defectuosa y no se expulsara.
Esto podemos tomarlo como norma: siempre se debe responder. Si la caja es Ok, con una señal de Ok, y si no con una señal de defecto. De este modo la línea de producción “sabe” que siempre obtendrá una y solo una señal de respuesta y, de no ser así, algo falla.
Además, estas señales tienen que activarse cada vez, no vale con que se mantenga si la siguiente tiene el mismo resultado.
Algunos llevamos ya más de 25 años en temas de visión artificial y aún nos encontramos con planteamientos en los que se trabaja solo con una señal.
Pero no todas las aplicaciones son del tipo PAR. Pongamos otro ejemplo: Imaginemos el kit de pedales de un coche eléctrico. Un eje en el que están el pedal de freno y el del acelerador. Son piezas articuladas, con movimiento y se debe garantizar que todos los elementos están presentes (ejes, clips, gomas, …), que las dimensiones y posiciones de montaje son las correctas y también se debe verificar que ambos pedales se mueven dentro del rango especificado.
Una línea de montaje y verificación de este tipo está formada por estaciones independientes a lo largo de una cinta transportadora. Los kits de pedales tienen un número de serie. Por otro lado, la verificación no se realiza en una única estación, sino que puede realizarse a lo largo de 3, 4 o más estaciones para un mismo kit. Al final de la línea es preciso conocer si el kit con número de serie X es ok o no.
Además, los controles que se realizan incluyen 2D, 3D e inspecciones por medio de Deep Learning y, como no, algunos resultados se calculan con datos que provienen de dos estaciones distintas, por lo que no son completamente independientes.
Ahora tenemos un donut realmente grande. Alguno podría plantear que cada estación es independiente a nivel de visión y que el PLC de la línea realice el seguimiento, del mismo modo que ya acumula resultados de otras pruebas o mediciones que no son de visión artificial. Es un planteamiento válido, pero pobre, y en ocasiones inadecuado.
Es pobre por que la capacidad de acumular y relacionar información del PLC nunca es comparable a la de un PC. El usuario final desea tener en reporte de todos los controles, incluyendo imágenes registradas. Tener que buscar en varios sitios y luego juntarlo todo no es lo que se busca, aunque sea posible.
Lo de inadecuado obedece a que, si se trata cada estación como un elemento independiente, el PLC debe realizar los cálculos para determinar si es Ok o no conjugando información de varias estaciones y dicha valoración puede obedecer a un algoritmo que incluso puede ser distinto según el modelo que se fabrique.
Esto también se puede considerar una norma: al césar lo que es del césar. El PLC se encarga de la maniobra y el PC de todo lo relacionado con la visión y valoración.
Creo que llegados a este punto está claro que se requiere de una aplicación suficientemente compleja para gestionar todo el proceso. Vamos a abrir el donut.
Por un lado, el fabricante de la línea de producción huye de cualquier planteamiento a medida. Siempre se opta por elementos estándar. El problema es que se opta por elementos estándar en muchos casos en los que no cumplen o no es adecuado.
Es perfectamente entendible que se pretenda acudir a “cosas de mercado”, pero no siempre es conveniente. He sido testigo de aplicaciones hechas con software estándar que han resultado más caras que desarrollos a medida y que nunca funcionan correctamente, por muy estándar y probado que sea el software estándar empleado.
También es cierto que hay aplicaciones a medida que tampoco cumplen.
¿Cuál es la clave?
Unos párrafos más arriba, al enumerar qué es lo que compone el donut, el primer elemento es arquitectura. Por norma general, lo adecuado es diseñar una estructura que encaje perfectamente con nuestras necesidades y luego, valorar muy detalladamente como encajan en ella los elementos de mercado que se podrían utilizar. Si el encaje no es suficientemente bueno, es mejor optar por un traje a medida.
Si se opta por un traje a medida, lo importante, a parte de la tela, es el sastre.
Si estás pensado que, llegados a este punto, este artículo no aporta solución o receta, tienes razón. La experiencia no consiste en es saber cómo hay que hacer las cosas. Nunca se puede estar seguro de que la forma de hacerlas sea la óptima. La experiencia es, en realidad, saber cómo no se deben hacer las cosas. Algo que no se aprende en ningún curso, si no a base de solucionar problemas.
Al principio he comentado que uno de los problemas es que nos enrocamos cuando aparece un determinado problema. Es algo muy habitual y muy humano, pero contraproducente. Nadie está exento de cometer errores. La diferencia es cómo se afrontan. De todo el código que he escrito en mi vida, más del 50% ha sido reemplazado por correcciones o mejoras. Y no han sido pocas la ocasiones en las que me he sentado con el cliente para informarle de que el proyecto se dilataría por que necesitaba reestructurarlo. Ese no es el problema, el problema es no hacerlo.
Así que volvemos al punto de inicio: el factor humano es la parte débil.
Demasiadas ocasiones se opta por lo conocido sobre lo adecuado. Por lo barato que acaba saliendo caro. Por copiar y pegar para aprovechar y luego colocar innumerables parches que son más parte del problema que de la solución.
¿Qué se puede sacar de todo esto? Busca asesoramiento.
Como habrás observado, no se ha dicho nada acerca de la tecnología de visión, cámaras, escáneres, redes neuronales, …
Hay gente que lleva en este campo más de 25 años y que, acerca de equipos, pueden darte un asesoramiento de calidad.
Otros nos dedicamos a escribir código y podemos orientarte acerca de cómo plantear la arquitectura que necesitas. Es un caso perfectamente homólogo al de la arquitectura de edificios. El arquitecto hace los planos y el constructor levanta el edificio. No tienen por qué ser de la misma empresa. Es más, en ocasiones es mejor que no sean de la misma empresa para evitar que ambos estén sometidos a las mismas presiones o directrices.
A modo de resumen: si tienes una aplicación compleja no empieces por buscar qué hay en el mercado que pueda solucionarlo. Empieza por diseñar qué estructura resuelve tu proyecto y luego valora si encuentras algo que encaje o no.
En un próximo blog hablaremos de arquitectura. En el mundo del software hay que distinguir entre modas y evolución. Ha habido muchas técnicas o tecnologías que han caído en desuso por ser más moda que evolución. Otras siguen ahí después de muchos años y otras están emergiendo.
¡Hasta pronto!