 Hola, buenos días a todos. Muchas gracias por venir a esta charla. Mi nombre es Joaquín Amad. Trabajo como científico de datos en CEPSA y está conmigo Ramiro Manso, que trabaja como lead data scientist en Kipler. Hoy estamos aquí para contaros un proyecto en el que las dos compañías hemos estado trabajando de forma conjunta. Como muchos de vosotros sabréis, todos los proyectos de data tienen su semilla en un problema o en una situación que queremos mejorar. Así que permitirme que os presente cómo empieza toda esta historia. La seguridad. En toda empresa madura y con cierta responsabilidad, la seguridad es uno de los objetivos principales. Y esto es más importante si cabe si los trabajadores desempeñan su labor en un entorno de alto riesgo. En CEPSA somos en torno a unos 10,000 trabajadores, de los cuales más de la mitad trabajan en refinerías, en plantas químicas, en plataformas petrolíferas, en pozos y instalaciones de este estilo en las que, como podéis imaginar, se tiene que dedicar muchísimo esfuerzo y muchísimos recursos para evitar que cualquier trabajador sufra algún daño. Además, la empresa lo intenta hacer de una forma preventiva. Es decir, nos esforzamos al máximo para que los accidentes no lleguen a ocurrir. Y para esto, nuestro equipo de safety es una estrategia de tres niveles. En primer lugar, cualquier persona que trabaje en CEPSA, bien como contratado interno o como contrata externa, debe de realizar un curso de seguridad general. Un segundo nivel en el que, además de un curso específico para la posición que va a desempeñar, cada vez que hay una nueva tarea, por ejemplo, una reparación, una expansión de las instalaciones, un mantenimiento, se analiza cuál va a ser la labor y se realiza un estudio detallado de cuáles son las medidas de prevención y los elementos de protección que se van a tener que llevar a cabo. Y por último, para asegurar que todos estos puntos se cumplen, se realizan auditorías e inspecciones frecuentes en los lugares donde está realizando la labor. Y después de esto, es posible que os estéis preguntando qué tiene que ver todo esto con ciencia de datos. Pues bien, en 2018, CEPSA crea un nuevo departamento llamado Transformación Digital con el objetivo de ayudar a transformar la compañía, interaccionando con todas las unidades de negocio y departamentos que tenemos. Como parte de la compañía que somos, se nos lanza el reto de contribuir a seguir mejorando la seguridad de los trabajadores. Además, como os podéis imaginar, somos un nuevo departamento, así que se espera de nosotros que hagamos algo innovador. Y tomamos el reto, nos ponemos a investigar. Por un lado, hablando con los compañeros del departamento de Safety, nos comentan y nos muestran que el casco, a pesar de ser un elemento clave en la protección individual y que su uso es prácticamente obligatorio en todas las áreas industriales de CEPSA, debido a la facilidad con la que se puede poner y quitar, sufre cierto grado de incumplimiento por despiste. Imaginaos trabajando en el desierto a 50 grados, lo fácil que se puede quitar uno en un momento dado el casco. Si a esto le juntamos que los compañeros de Safety, el Departamento de Seguridad, nos habla de que la mayoría de las instalaciones de CEPSA dispone para protegerlas de circuitos de cámara cerrada. Juntamos los dos puntos y eureka. Sabemos que lo que tenemos que crear es un sistema de visión por computación capaz de alimentarse en real time de todos estos vídeos y de hacer tracking del uso de cascos. Así que, como a muchos de vosotros habrá pasado, los científicos de datos, cuando aparece un proyecto en el que finalmente podemos aplicar todas esas nuevas tecnologías de deep learning, nos ponemos inmediatamente a recopilar imágenes y a entrenar modelos. Lo que no es una buena idea de cómo empezar este tipo de proyectos. Aunque no me adelanto, Ramiro os contará todas las cosas que funcionar y que no. Pero, después de unas semanas, habíamos logrado un modelo, nos habíamos etiquetado un banco de imágenes en las 3.300, con cascos y no cascos. Y habíamos entrenado un modelo de detección de objetos empleando YOLO 2, que en ese momento era el estado del arte, como sabéis en los benchmark de comparativas, pues tiene un buen performance en cuanto a capacidad de detección y a rapidez. Y como framework, empleamos Keras y TensorFlow. Esto debe reproducirse, no lo hace una astia, solo un vídeo. Bueno, después de celebrar con entusiasmo que habíamos sido capaces entrar un modelo estado del arte de detección de objetos, tuvimos que hacer frente a la verdadera pregunta, de cómo da esto valor a la compañía. Así que nos volvimos a sentar y definimos bien cuáles son las características que tenía que tener el producto digital que queríamos crear y que tenía que aportar valor a la compañía. Y el resultado de ello fueron estos puntos. En primer lugar, queríamos un producto que fuera agnóstico a la cámara. No todos los dispositivos se pueden instalar en zonas industriales, por ejemplo, por qué requieran de especificaciones para entornos explosivos. En segundo punto, se trata de zonas industriales muy dinámicas. Debido a rotaciones, mantenimiento, expansiones de la infraestructura, tenía que ser un sistema en el que los alarmados, incluso la disposición de los dispositivos, pudiese variar de forma sencilla. Se tenía que salvaguardar la privacidad, seguridad y borrado de los datos, ya que todo lo relacionado con imágenes de personas está cubierto por la protección de datos biométricos. Tenía que tener una interfaz web donde se pudiese gestinar todo el alarmado en las métricas y las infracciones, ya que el usuario final de este producto es el equipo de seguridad y de safety. No son data scientists, no son ingenieros. No necesitan acceder en ningún momento al código. Queríamos que los usuarios, los tenants, fueran totalmente aislados. Y alguno de los motivos principales es que CEPSA tiene infraestructuras en muchos países. Cada uno de estos países tiene una legislación propia y distinta, por lo que, a pesar de ser la misma compañía, puede estar sometido en cada planta, en cada refinería, a diferente legislación. También queríamos tener en cuenta el coste en que podíamos inferir, ya que procesar vídeo 24 horas, 7 días a la semana, implica un tráfico de datos bastante elevado. Y, por último, que fuera escalable a otros casos de uso. Hoy os vamos a presentar la detección de cascos, pero también podría ser la detección de vehículos, barcos en las zonas de docking o otros elementos de protección personal. Como resultado, la propuesta fue que queríamos un sistema de computing, de forma que la mayoría del cómputo no tuviese que enviarse a la nube y, por lo tanto, nos ahorrabamos mucho tráfico de datos de vídeo y con ello también de seguridad en parte, que debía tener una interfaz web que fuese amigable para el usuario final, donde gestionar toda la parte de incidencias, dispositivos, activación de alarmado, desactivado. Y, por último, como os hemos comentado, era muy importante que se pudiera distribuir como un producto digital e independiente. Y qué mejor que hacerlo a través de una plataforma, como es el Amazon Marketplace. Y todo esto intentando hacerlo en un tiempo máximo de tres meses, lo cual suponía muchos retos que Ramiro va a contar a su continuación. Unos poquitos, tres meses. Principalmente, parte de lo complicado que es esto, no solo ya tratar con temas de computing, sino encima añadir la complejidad Marketplace, que significa que tienes que crear un producto que sea compatible con SAS Factory, que es el cosistema que tenía Amazon para todo esto, que sea compatible con todo ese cosistema, encima significa que tienes que asegurarte de que cumples todos estos reglitos que son los necesarios para seguir ese framework y que te dejen publicarlo en el Marketplace. Y para explicaros un poco lo que llegamos, vamos a hacer un poco al revés. Voy a explicar primero qué logramos conseguir durante esos tres meses y luego hablamos de un poco lecciones aprendidas y cómo llevamos a ello. Entonces, hablamos primero de lo que conseguimos. En esos tres meses realmente creamos una arquitectura que permitía tener diferentes dispositivos hechos, dispositivos donde la propia cámara hacia la inferencia subía las detecciones al todo el cosistema. Y otros dispositivos que lo que utilizaba era aprovechar las cámaras ya existentes en una red de vigilancia, se conectara a esos streams de vídeo y fuera un dispositivo un poco más potente el que subiera las diferentes detecciones. Estas diferentes detecciones serán procesadas y eran mostradas, como decíamos, en una interfaz que el técnico de seguridad, el manager, quien fuera la persona encargada, poder utilizar donde cada una de las detecciones apareciera, cuando ha sido, donde ha sido, con qué seguridad, creo que la he detectado, qué nivel de criticidad. Y ese nivel de criticidad también podía marcar el hecho de que podían enviar una notificación, un correo, un mensaje a ese técnico de seguridad para que si hubiera una zona especialmente peligrosa pudiera verla en el momento y salir y decir, oye, Paco, ponte el casco, tío. ¿Qué más tenía? Tenía para seguir un poco los requisitos que nos pedía es poder hacer un poco toda la gestión dentro de la web. Dentro de la web significa gestionar qué dispositivos hay activados, cuáles quiero activar, quiero es que me mover, qué localización tienen y etiquetas para poder vigilarlos. Aparte de una visión de un timeline sobre cuando han sido detectados, ¿cuál es el porcentaje de personas con casco y sin casco que me han visto? Filtrarlo por zona, filtrarlo por franja temporal. Esto era importante porque, como nos habían comunicado más de una vez, querrían ver si tomando diferentes acciones de seguridad o concienciación se detectaba algún tipo de cambio o poder vigilar si había zonas o plantas donde fuera especialmente conflictiva y tuvieran que hacer algún tipo de labor de concienciación. Entonces, esto está muy bien. La verdad es que quedó muy chulo, pero no os interesa enseñaros qué hemos hecho, sino más bien cómo hemos llegado a esto. Entonces, hablemos un poco de lo que hay detrás de todo esto. Hablamos un poco de la parte de arquitectura. La arquitectura se basaba principalmente en un dispositivo, en este caso, una deep lens, que lo que hicieran fuera en el propio dispositivo analizar el stream del vídeo y cada una de las detacciones que se realizarán, de hecho, separadas por detección, si había una misma imagen, cuatro, bueno, en el mismo momento del vídeo, cuatro personas sin casco, pues, son cuatro detacciones diferentes, subirlas a S3, esas imágenes con el JSON de la detección, el scoring, donde ha sido, cuando ha sido, y algún tipo de información extra. Las imágenes con un trigger son almacenadas en una base de datos y en caso de que tuvieran algún tipo de criterio de criticidad, se lanzaría un tipo de notificación. Luego, por otro lado, teníamos toda la parte del frontal, que la creamos en una web alojada en S3 y que se comunicaba con toda la lógica de negocio mediante una API. Eso liberaba y permitía utilizar simplemente una web estática y poder securizar todo eso con cognito para asegurarte de que solo las personas adecuadas acceden a las partes de la web adecuadas. Además, de forma cross, todo otro conjunto de servicios de Amazon, como sistema de notificación, greengrass para toda la gestión de dispositivos, logs, etcétera, etcétera, etcétera. Este mismo framework, como digo, es compatible y nos aseguró de que fuera compatible con todos estos criterios que hemos hablado de un proyecto SAS. Esto lo que nos dejaba es hacerlo compatible y, de hecho, lo desplegamos de forma privada, pero que pudiera acceder solo a las personas concretas. Está desplegado en Amazon Marketplace. A nivel de modelos, no venimos a hablar de cómo funciona Deep Learning. Hay un montón de charlas que van a contar cómo es eso. No nos centramos aquí. Nos centramos en realmente cómo son los frameworks, qué requisitos tienen, qué sutilezas hay, qué arquitecturas tienes, y cómo tratar todo eso a nivel tecnológico. Pero, si queréis situar palabras, darles aquí. Sí, problema. Honestamente, esto es una excusa para poner amigatos en una presentación, no lo queréis. Bien, la idea. Vamos a utilizar las Amazon Deep Lens. Está este dispositivo, lo sacó Amazon hace unos años, 100% integrado en el ecosistema, 100% integrado con Greengrass para la gestión de dispositivos IoT, y ya con proyectos de detección de objetos que ya nos aseguraban de que, al menos lo que buscamos, era viable de conseguir. Y de hecho, gracias a esto, nos centramos precisamente en cumplir todos los criterios de la arquitectura que hemos puesto y asegurarnos de que el producto en ese sentido era estable y fuerte. Entonces, ¿por qué hicimos esto? Porque, además, nosotros desde la parte de desarrollo no teníamos capacidad de acción sobre el modelo. El modelo ya estaba entrenado. Era algo que el equipo de Chimo había estado trabajando. Entonces, nuestro único trabajo era colocarlo en el dispositivo y asegurarnos de que todo el resto de piezas funcionaba correctamente, lo cual no es la mejor idea. ¿Por qué? Porque, veamos, ¿cómo funcionan estas Deep Lens? Deep Lens se apoya por debajo en un framework de Intel, llamado Open Vino, que es lo que se compone de dos piezas principales, una el optimizador, que lo que hace es coger el modelo en el clavo de computación y traducirlo a instrucciones de CPU muy, muy, muy bajo nivel para optimizar todo lo posible. Una segunda pieza, coge ese modelo, ya esa representación intermedia, optimizada, y hace inferencia con ella. Y yo puedes ver cómo, sin GPU, alcanzas una performance bastante, bastante interesante. Pero, problemas. ¿Por qué? Empezamos por el primero. Primero, el modelo que entrenaron, como ha comentado, es un tipo de YOLO. Y los modelos de YOLO tienen un par de peculiaridades especiales. La primera que utilizan operaciones que no son muy estándares, están implementados en DarkNet y el resto de frameworks, lo hace, como quien dice, cada uno a su manera. Eso significa que no hay una forma estándar de traducirlo y que tienes que delegar en el vaquén para decirle, oye, lo que no se pasa a hacer, haz que lo haga TensorFlow. Y tienes una lista de instrucciones específicas dentro de OpenBino para ver cómo transformar YOLO. Pero una vez que te empapas de esto en la documentación suficiente, ya es seguir los pasos. Y el primero sería el congerar el modelo, que es simplemente coger el gráfico de computación, quitarle todo lo que tiene que ver con el entrenamiento y dejarlo solo para la parte de inferencia, lo que lo reduce. Segundo paso, volver a plenaerte con la documentación y mirar todos los pasos que necesitas para decirle a la configuración, oye, esta es la capa de entrada, esta es la capa de salida, este es el tipo de cuadrado que quiero que tengas, etcétera. Tercero, generar el modelo de intermedio. Y cuarto, ejecutarlo y ver que todo funciona. Me gustaría por una vez poder decir eso de verdad, ¿eh? Pero no, no, seguimos los pasos adicionales, así que el estándar. El consolo es que no estábamos solos, especialmente, ¿vale? Esto, veamos que YOLO con OpenBino nos lleva muy bien. Y veamos issues abiertos desde 2017 hasta la misma semana en la que estábamos trabajando. Lo cual, bueno, estaban contestados casi todos. El problema es que la contestación solía ser la misma, que es, oye, actualiza la versión de OpenBino. Con eso ya lo arreglas. Pero curiosamente, al actualizar el firmware de las deeplands, no actualizabas OpenBino. Recuerdais, teníamos tres meses, ¿no? Entonces, en esos pasos de tiempo, y dado que habíamos gastado prácticamente todos en toda la arquitectura, confianza de las deeplands, le dijimos a Chimo, oye, necesitamos en el poquito, poquito espacio que tenéis de tiempo ver si hay alguna opción alternativa. Pues, bueno, aquí nos devolvieron la pelota. Y hemos de reconocer que pecamos del error que se suele cometer en toda esta ciencia de datos, que es ir directamente al estado de arte, a la aproximación más compleja y que más de moda está. En este punto, los compañeros nos dijeron que no se podía desplegar, no éramos capaces de desplegar el modelo, y había dos dudas. O bien que fuera por el tipo de modelo, en este caso, YOLO 2, o bien por el framework y la tecnología empleada. Así que decidimos utilizar otra aproximación en cuanto al tipo de modelo algo más sencillo, un single shot detector. Y en cuanto a la tecnología, como mucho de lo que estábamos haciendo, está relacionado con Amazon y MXNet, ha sido, ante mucho tiempo, su referente, pues decidimos ir por esa línea. En concreto, utilizando GLUON, que es la API que va por encima de MXNet, y que facilita mucho el transfer learning en todo suzo de modelos. Así que el resultado fue crear un nuevo modelo, en este caso, un single shot detector, que parecía que no funcionaba peor o al menos igual de bien. Y por lo menos el tamaño era muchísimo menor en cuanto a la necesidad de RAM, a priori. Y se lo devolvimos al equipo. ¿Y qué pasó? ¿Qué sorpresa? Tres meses. Vale, en este momento empezamos a pensar. Llega hasta el punto en el que tienes que decir, vale, este plan no va a funcionar. Y tenemos muy poquito tiempo para pensar qué hacemos. Así que hablamos con vosotros, con Chimo, y dijimos, oye, realmente, nuestro plan de utilizar las deep lands no va a seguir adelante. No era el enfoque que teníamos en el tiempo. Vamos a ver qué podemos conseguir. ¿Por qué? Porque llegar con Chimo es algo. Gracias a nos apoyó mucho Amazon, nos ayudó bastante, pero en lograr arreglar este problema no lo conseguimos. Tenemos un modelo de clasificación que funciona en tiempo real y te va indicando, pues sí, hay alguien con casco o alguien sin casco, pero sin marcar dónde la imagen y demás, el caso se queda un poquito corto. Así que hicimos, pues nada, a esperar otras opciones. Primera opción. Vamos a empezar desde la base, desde el principio. Una Raspberry, que es donde todo el mundo comienza cuando quiere cacharrear a nivel de dispositivo. Pues vamos a coger la Raspberry, la que había en ese momento más reciente, el modelo V+. Y vamos a intentar meter ahí toda la lógica de integración con Amazon y toda la lógica de la inferencia. El resumen rápido es este. No cabe. No hay quien logre mover un modelo tan grande como yo, además, en este dispositivo. Aparte de que no tiene GPU y la CPU es bastante, bastante limitadita. Entonces, con mucho esfuerzo llegamos a algo, pero un frame cada 30 segundos no es algo que yo consideraría tiempo real, no muy usable. Aparte de las increíbles aventuras de compilar todo un framework, por ejemplo, de MxNet durante 12 horas en un cacharro, así. No lo aconsejo. Entonces, dijimos, OK, no, nos hemos pasado. Bueno, vamos a pensar otro escenario. Realmente, a nivel de diferentes zonas, van a tener ya cámaras instaladas, van a tener diferentes sistemas de vigilancia. Y si podemos conectarnos a ellos y en un dispositivo más potente ejecutar toda la inferencia que venga desde ahí, ya estaríamos cumpliendo una parte de lo que nos piden. Y, de hecho, es un caso bastante, bastante clásico, sobre todo para cámaras rugrizadas y con el estilo. Entonces, dijimos, vamos a centrarnos en crano en un contenedor que sea Plug and Play, tú lo descargues en el dispositivo, lo conectas al stream de vídeo, y fin. Entonces, para ello, lo que hicimos es crear dos contenedores especializados, uno para CPU y otro para GPU. Para CPU, apoyado en la librería de MKLED Nvidia, digo, de Intel, perdón, que incluyen ciertas operaciones que muy, muy aprovechadas en temas de deep learning, por lo cual, aunque funciona en CPU y no llega a ser tan bueno con Open Bino, funciona bastante bien y bastante rápido, a nivel de inferencia. Luego, creamos otro segundo contenedor, utilizando el plugin de Media Container, que es un plugin construido sobre Docker que te da visibilidad a la GPU que no viene de base. Entonces, después de currarnos estos dos contenedores, mantenerlos y dejarlo todo cerrado, dijimos, OK, esto está hecho. Mismo día que decimos, todo está hecho. Aquí tenéis como Docker, dice, ahora ya hay visibilidad de la GPU, por cierto. Así que espero que vuestro trabajo muy rico. Frustrante el estado de arte. Bueno, el caso es que sí conseguimos tener un dispositivo de contenedores y cumplir el caso de uso de una red de cámaras conectado a ello, lo cual nos venía muy bien. Pero seguimos un poco con la frustración de que no teníamos ese otro dispositivo que nos pedían de aquí tienes una cámara, la voy colocando donde quiero para esos momentos de obras temporales, algo puntual, donde no tengas que hacer toda una instalación gigante. Entonces, dijimos que ya lo hacemos. Y justo, justo, justo envidia sacó este dispositivo, un nuevo dispositivo entre la familia de su familia Jetson, llamada Jetson Nano, que voy a describir realmente mal como una raspberry con esteroides. Vale, realmente no lo es. Es un módul que tiene una capa de más, pero la pinta lo parece. Y es bastante, bastante potente. Tiene una GPU tipo tigra, tiene una CPU bastante potente, 4 gigal de RAM compartidos entre uno y otro. Y todo el ecosistema de envidia ya ha integrado con CV, Jetson y demás. Y realmente, funcionó. Voy a esperar a que el GIF continúe. Ahí está. Funciona. Efectivamente, confirmó que funcionó. Bueno, el caso es que funciona y este dispositivo ya con una cámara podía efectivamente revisar todas esas detacciones, enviar esas detacciones a Amazon y continuar todo el pipeline. Y este ecosistema funciona bastante, bastante bien. Tenemos una limitación igualmente. El tamaño del modelo sigue haciendo muy grande. Y en modo completo GPU, módulos yo lo no cabe. Porque son 4 gigal de RAM compartidas y yo lo 2 ocupan memoria al final como entre los 6, 4 y 6. Así que no cabía. Pero modo CPU con ciertas optimizaciones era razonablemente aceptable. Aparte, está muy bien el dispositivo. Porque quieras que no, el consumo máximo son 10 vatios. Si lo quieres poner así y lo puedes mover con un power bank. O sea que, pero dijimos, ya que tenemos otro modelo que nos han entrenado, vamos a probar con ello. Y este otro modelo era el de MekisNet. Entonces, ya que no han pasado, ya que hemos compilado MekisNet para la Raspberry, vamos a instalarlo aquí, fracasando. Porque la arquitectura no es exactamente la misma. Entonces con un poco de suerte le elegimos a la gente envidia. Oye, nos podéis ayudar a modificar las instrucciones para compilar MekisNet en el dispositivo. Y lo que nos contaron es, aquí las tenéis. Pero bueno, volvamos al binario directamente. Al día siguiente. Tremendo el tema del foro aquí. Y lo probamos, ya que lo teníamos. Adelante. Y el caso es que funcionaba más lento en GPU que en CPU. ¿Por qué? Porque al parecer había que meter un flag más que no les habíamos comentado. Entonces tenemos que recompilar todo y dijimos, mira, ya, se nos acaba el tiempo. No tenemos más tiempo. Volvamos a los tres meses del principio. Pero vamos a probar la última cosa. ¿Por qué? Ya que estamos. Dijimos, OK, hay un último, último pipeline que debería ya venir todo integrado y le podemos probar en una tarde. Que es el de ONNX y TensorFlow.RT. ONNX es un lenguaje intermedio de representación de redes neuronales. Y prácticamente todos los frameworks tienen un conversor a ONNX para utilizarlo en cualquier otro lugar. Y TensorFlow.RT, entre otros, tiene un consumidor de ONNX. Entonces tú entrenas con el framework que quieras, hacer la representación intermedia. Y lo consumes con el framework que te interese. Muy estilo open-vinyl, pero un poco más abierto. El caso es que dijimos, vamos a hacerlo con MxNet, que es un modelo más pequeño, más funcional y debería ir mal directo. Y descubrimos que no, ¿vale? Porque resulta que el zoo de gluón, que es esa capa de MxNet ponen encima, no es compatible con ONNX, porque tiene parámetros tipo no ni demás perdidos por ahí que a los que no les gustan. Abrimos un isio, preguntamos y nos lo confirmaron. Y pues nada, como que no. Pero bueno, ya teníamos por fin el dispositivo EchFinal. Habíamos llegado a sus tres meses. Fue una semana divertida con la Yetson. Y funcionó todo correctamente. Había cosas que nos gustaría haber hecho mejor, como utilizar la conversión correctamente de TensorFlow.RT y aprovechar un poquito mejor la GPU. O algo que ha aparecido ya en julio, ya habiendo pasado todo esto, que es el runtime de envía containers en los dispositivos de Yetson, lo cual nos quitaba problemas de cómo gestionar desde Amazon la actualización del modelo, cómo gestionar todo eso. Ya podríamos crear un propio contenedor con todo empaquetado. Gringrad directamente se baja el contenedor, ejecuta todo y se acabó. Entonces, este es el punto donde un montón de gente anda preguntando, ¿por qué no utilizaste esto? ¿Por qué no utilizaste esto otro? ¿Por qué este modelo? ¿Por qué utilizar yo lo completo en lugar de mí y yo? Honestamente, la respuesta es no había tiempo. Dado que planteamos todo al principio como centramos en la arquitectura y utilizamos la Amazon DeepLens, el tiempo luego de margen con el que tuvimos que operar, era escaso. De aquí, probablemente, el que más rabia me dio no poder utilizar correctamente fue el de Nvidia DeepStream, que es su propio ecosistema de dispositivos IoT, que habría simplificado ciertas partes, como, por ejemplo, lo de tener múltiples contenedores para múltiples cámaras en lugar de lo que haría DeepStream, que sería mezclar en un mismo vídeo los múltiples Steam de vídeos, tendríamos un vídeo con múltiples imágenes, y hacer la inferencia sobre ello, lo cual es bastante más eficiente. Pero bueno, sea como sea, conseguimos esto, lo tenemos entrenado, lo tenemos disponible, están las cámaras desplegadas, está disponible en Amazon Market, o sea que lo consideramos un éxito cuesta arriba. Así que, de todas formas, ¿qué aprendimos con esto? ¿Por qué es realmente el core de la charla? Pues aprendimos que el estado del arte en tema de Deep Learning y escomputing se mueve muy, muy de prisa, aunque para eso no habría que haber venido a esta charla. Primero también que los frameworks tienen interesantes casos límite poquito de mala leche. Sobre todo, si os vais de algo con esta charla que sea, que a la hora de pensar cómo desplegar este tipo de cosas, pensar primero en los requisitos de ingeniería, en dónde lo quiero desplegar, cuál va a ser mi dispositivo o cuáles van a ser mis dispositivos, qué capacidad tienen, qué frameworks hay existentes para ellos y qué limitaciones pueden tener. Aparte de memoria, CPU, KB, o no KB. La segunda cosa con la que sí que me gustaría que os fuera ir aquí, si es que os vais con algo, es no diferenciar o no desacoplar los grupos de ciencia datos y de tecnología. Hay muchas empresas que lo que deciden es el trabajo del proyecto. Y el científico de datos es tipo factoría de modelo, me entra un problema, genero un modelo, aquí lo tienes y me desentiendo. El científico de datos debería estar a lo largo de todo el proceso, de la ideación hasta el despliegue, hasta cumplir el objetivo del proyecto. Y si tus equipos están muy diferenciados técnicamente en la parte tecnológica, de la parte científica, deberías tener un rol intermedio del Machine Learning Engineer, que viene a ser alguien que está a medio camino entre una cosa y otra y entiende los problemas de ambos. Aquí solo añadir que como científico de datos que ha sufrido justo esto que comenta Ramiro, creo que las empresas y en general estamos evolucionando hacia esta línea. Los equipos cada vez son, bueno, siempre han sido mixtos, pero cada vez más integrados, sino trabajando como creadores de piezas independientes de un producto final, sino que todos tenemos visibilidad. Como ha comentado, el estado del arte evoluciona muy rápido y sobre todo para el área de prototipado. Pero no va tan rápido para después los despliegues, las puestas en producción a una escala considerable. Y esa visión, si no se trabaja con equipos mixtos, a veces no la tenemos, vamos directos a lo último o intentamos que nuestros modelos, como científico de datos, sean lo más precisos y lo más modernos posibles, pero luego no son útiles. Entonces hacer hincapié en esa parte de compartir conocimiento desde el diseño del proyecto o del producto. No, de esa copla de equipos. También aprendimos sobre ONNX, este lenguaje intermedio, que tiene mucha funcionalidad y en serio el pipeline es bastante, bastante agradable, pero tiene sus limitaciones y no intentes hacer operaciones un poco fuera de lo estándar, porque realmente el conversor no la soporta. Luego OpenBino, pese a la potencia que tiene y aquí romper una lanza a favor de OpenBino, mejoran mucho con las nuevas releases, como backend igualmente es un poquito incómodo, delicado de utilizar, de mi experiencia no es la más, no es el más amigable. Luego la media Jetson es un una pieza de hardware, muy muy potente, pero aunque podemos decir que para el caso de uso cumplimos lo que buscábamos, habría hecho falta ampliar cosas ahí, probablemente cambiar el tipo de placa que tiene y meterla en una caja, una funda rubberizada que soporte un poco más movimientos, o sea no tener una caja imprimida en una empresa la 3D, para decir, aquí está. Y también por último a nivel de este tipo de caso de uso pensar que tu arquitectura de dispositivos va a ser una mezcla, vas a tener esa red de cámaras que te hachimos un montón de refinerías con otros dispositivos un poquito más especiales concretos, con otros dispositivos que tienen que ser móviles así que planea para ello, piensa que son múltiples cosas que requisitos van a tener cada uno de ellos y si eres capaz de cumplirlos con todos. Y después de esto un poco más, muchas gracias por habernos aguantado aquí un poco esperamos que nos habíamos aburrido y si hay preguntas que sean fáciles. Aún quedan unos minutos si hay alguna pregunta. Gracias. Hay una cuestión ahí. No es una cuestión. Muchas gracias por la presentación, muy interesante. Quisiera saber si ahora el sistema está en producción y en tal caso cuántos accidentes ha permitido prevenir. En este caso están siguientes pasos en el sentido de que las personas están a nivel de poco implementada pero como hemos comentado hay ciertas cosas que tenemos que mejorar como el que dispositivo sería el potente a incluir y cómo proteger mejor un dispositivo como la Yetzo. No estaría en un estado actualmente para poner 100% en producción una planta. Más añadir también que el objetivo de este proyecto en parte era saber si éramos capaces en caso de querer desplegarlo, de poder hacerlo. Todo esto de la mano del ámbito legal y de protección de dato que implica y que tiene que ir al mismo nivel. Muchas gracias por la charla y una pregunta respecto al hardware estábais hablando de Raspberry Pi entiendo que por precio hasta que punto o en que tipo de proyectos sería interesante hacer un hardware a medida? Tecnicamente todos los hardware a medida se acaban basando en piezas un poco más estandas si lo quieres hacer 100% a medida No, acoplando módulos no tiene porque ser evidentemente es acoplar una placa que acople módulos a medida. Ahí va a depender del vamos a utilizar Roy que quieras tener en el sentido de que cuántos dispositivos vas a querer desplegar cuánto cuesta por dispositivo y cuánto te va a aportar toda esa red de dispositivos no te puedo dar realmente un número en el cual a partir de aquí es viable donde puedo indicar que tienes que estudiar o tener en cuenta. Si no me equivoco la Jetson estaba en torno a 200 dólares 120 dólares y consideramos que era asequible e incluso se había que desplegar un número considerable de ellas Muchas gracias Gracias