Aprendizaje supervisado aplicado - Smart office

En este charla trataremos un caso práctico en el que se ha implementado un solución de *smart-office* dentro del ecosistema **IoT de AWS**.
El sistema se apoya en hardware básico (Raspberrypi) y mediante un algoritmo de **aprendizaje supervisado** a través del reconocimiento de imágenes con *OpenCV* monitorizamos el uso de salas y zonas comunes de la oficina.

Analizaremos problemas y soluciones aplicadas durante su desarrollo, desde el propio entrenamiento del algoritmo hasta la arquitectura del sistema implementada para ser capaces de ponerlo en marcha sobre hardware poco potente.

Transcript

1. Spaces. Iot aplicado a un caso real
2. Durante el día las personas se reúnen muchas veces Está muy instaurado el uso de salas de reuniones para abordar diversos asuntos. Pero el proceso, no suele ser tan fácil como debería… - No se reserva la sala con antelación - Se producen interrupciones en las reuniones - No se encuentran salas disponibles - Salas reservadas que finalmente no se usan - Espacios que no son reservables, pero tampoco se tiene conocimiento de su estado
3. Estado de los espacios Conoce de primera mano el estado de los diferentes espacios disponibles en el edificio: - Salas de reunión reservadas o libres - Grado de ocupación de los espacios comunes Haciendo uso de los sensores de paso y el sistema de reserva de salas tendrás la información más completa.
4. Benito Alcántara Glez. Características del espacio Conoce el espacio que vas a reservar para elegirlo adecuadamente a las necesidades de tu reunión. Estado actual En tiempo real, muestra el evento activo, informando del asunto, el organizador, sus participantes y duración. Ocupación del día Línea temporal la disponibilidad de la sala. Ocupación del espacio Indicador de si el espacio está siendo utilizado, en base al sensor.
5. Ubicación y reserva de salas Hemos implantado tablets y pantallas in-situ integradas con el sistema de identificación de empleados para gestionar las reservas: - Vemos la ubicación de la sala
6. Ubicación y reserva de salas Hemos implantado tablets y pantallas in-situ integradas con el sistema de identificación de empleados para gestionar las reservas: - Liberamos la sala cuando terminamos antes de tiempo - Modificamos la reserva si necesitamos más tiempo - Reservamos sala antes de entrar aunque esté vacía - Podemos buscar otras salas disponibles
8. Mundo IoT 8
9. Arquitectura IoT DEVICES GATEWAY CORE IoT INSIGHT STORAGE API APPS CLOUD
10. Mayor eficacia en el conteo en tiempo real de la personas, procesando el tránsito de la persona en el propio dispositivo, y solo notificando al sistema IoT Core con la información de entrada y salida. Con esta arquitectura ganamos velocidad frente al envío de un flujo de video constante desde cada uno de los dispositivos al nodo central, lo que nos hubiese supuesto un paradigma con respecto a la alta disponibilidad de la red en cada uno de los dispositivos.. Edge computing
11. Tablets para reserva deben tener unas características mínimas de: - 1GB de RAM - Procesador Duo-Core 1.7 Ghz o similar. - Android 5.x o superior - Power over Ethernet - NFC El sistema de reconocimiento de paso de personas, funciona bajo las siguientes especificaciones: - Raspberry PI 3 B+ - Power over Ethernet - Cámara 1080p Dispositivos
12. Gestión de dispositivos Alta / baja / tipado / búsqueda / shadow Analíticas Métricas agregadas sobre estado de los dispositivos y operaciones ejecutadas Seguridad Comunicación segura online, auditoría, monitorización Ejecución basado en reglas Sobre los mensajes recibidos, para envío selectivo a otros sistemas o servicios de AWS Shadowing Es una representación de los dispositivos en la nube. Jobs Sobre los mensajes recibidos, para envío selectivo a otros sistemas o servicios de AWS AWS IoT Core Edge computing Ejecución de funciones ‘serverless’ de forma local para actuación sobre los dispositivos Posibilidad de funcionamiento offline Lógica dentro del gateway con sincronización Seguridad Comunicación segura, de forma local y online Respuesta a eventos En modo de funcionamiento Gateway puro, incluso de forma local Machine Learning Ejecución de modelos de ML previamente entrenados. AWS GreenGrass
13. Flujos de Comunicación MQTT AWS IoT Core AWS GreenGrass Devices /start-next /get/accepted /update/accepted /start-next /get/accepted /update/accepted
14. Shadowing El Shadowing es un documento JSON que nos permite guardar y recuperar la información de estado de un dispositivo. Parametrización: - Línea de paso de las personas - Tiempo de vida de las personas - Identificador del dispositivo - Buffer de procesamiento - Orientación de la cámara - etc. Los cambios propagan a través de un Delta sólo con las modificaciones con respecto al original.
15. Los jobs nos permiten ejecutar tareas en remoto sobre los dispositivos: - Actualizaciones de software/firmware - Limpieza de datos A través de los topics habilitados por AWS, para un ejemplo típico de actualización de software del dispositivo el flujo sería el que sigue: 1. Pusheamos nuestros cambios en Git 2. Jenkins escucha y sube “la receta” del job a S3 y notifica a IoT Core quién debe ejecutar dicho job. 3. IoT Core notifica a los dispositivos identificados. /job/get/accepted 4. El dispositivo se descarga el job. 5. El dispositivo invoca un script que es capaz de ejecutar las órdenes descritas en el job. 6. El propio dispositivo notifica a AWS IoT Core el resultado del job. /job/update/accepted Jobs AWS S3 AWS IoT Core Devices Script
16. Ingesta de datos
17. Ingesta de datos Datos en bruto.
18. Ingesta de datos Información en tiempo real.
19. Ingesta de datos Analítica.
20. Editar el estilo de texto del patrón Detección de paso 20
21. Proceso de detección Procesado de la imagen Pasos Detección de elementos Clasificación de elementos
22. El objetivo es reconocer tránsito de personas, no identificarlas. Condiciones: - Plano de la cámara fijo - Umbral de paso conocido OpenCV para la manipulación de imágenes en tiempo real. - Desenfoque gaussiano, - Procesado morfológico de la imagen: - Erosión - Dilatación Procesamiento de imagen
25. Detección de elementos Después del procesado del frame, debemos detectar los elementos diferenciadores dentro de la imagen. Se realiza detección de objetos, y cuantificamos el tamaño del objeto con un umbral mínimo.
26. Mono thread Se crea un sistema en dos fases: lectura de frames y detección. Se comienzan a hacer pruebas con nuestro entorno de ‘test’. Se crea el concepto de ‘persona’ para detectar el origen y la dirección de las detecciones y permitir hacer el ‘tracking’ de un objeto Problemas El rendimiento no es bueno (2 fps) lo que produce grandes variaciones entre las distintas detecciones. Lectura de Frames Detección
27. Multithread Cambiamos a un sistema multithread en la capa de detecciones, mejorando el rendimiento de hasta 22 fps. Se crean un conjunto de vídeos que servirán de ‘test unitarios’ para validar cada cambio en el sistema. El thread de tratamiento se modifica para ‘dejar’ que se acumulen threads (usando una lista priorizada a modo de buffer). Problemas Los resultados son muy variables, la distancia entre la cámara y los objetos es muy reducida, e impide un buen trackeo de la difereccion del objeto. Lectura de Frames . . . Detección Priority
28. Cámara Ojo de pez Se hace una prueba con una cámara de ojo de pez, consiguiendo ángulos mucho mayores y logrando que la imagen sea mucho más lejana. Una persona ya no ocupa demasiado espacio dentro de la imagen facilitando la detección. Se crea un sistema de ‘babies’ en el que una detección reciente no se trata como ‘persona’ hasta lograr un número determinado de detecciones consecutivas. Problemas El sistema funciona correctamente en sitios de paso grandes o en salas con puerta de cristal. En el resto, los objetos que se mueven (principalmente las puertas) siguen siendo un problema. Lectura de Frames . . . Detección Ojo de pez Priority
30. Algoritmo final Se itera con los diferentes objetivos de las cámaras, y se analizan cada paso necesario en la detección llegando a un algoritmo final. Pasos: - Lectura frames - Detección - Clasificación Usando siempre listas priorizadas entre la comunicación de cada paso. . . . Lectura de Frames Priority . . . Detección Tratamiento y envío de eventos Priority
31. Un gran cambio 31
32. Fuente: https://www.xataka.com/robotica-e-ia/machine-learning-y-deep-learning-como-entender-las-claves-del-presente-y-futuro-de-la-inteligencia-artificial Contexto Deep Learning
33. Deep Learning Supervisado Tipos de aprendizaje No Supervisado Por Refuerzo
34. Machine Learning! Buscando alternativas al sistema, se planteó la posibilidad de entrenar un modelo que reconociera ‘cabezas’. Dada la vista cenital de las cámaras, ninguno de los modelos pre-entrenados disponibles se ajustaba. Una búsqueda entre los distintos sistemas nos llevó a Yolo. Es especialmente recomendado para sistemas que necesiten una rápida detección de objetos. con la desventaja de que no siempre detecta correctamente pequeños objetos, sobre todo si estos objetos están muy juntos entre sí. Por este motivo se usó YOLO frente a otros sistemas de detección como R-CNN, o SSD’s. Real-Time Object Detection
35. Machine Learning! Las principales características que proporciona Yolo frente a otras soluciones son: - Rendimiento: puesto que el objetivo es hacerlo funcionar en un hw reducido una de las principales limitaciones era la del rendimiento. - Calidad de detección: Con las posibilidades de las cámaras que se iban a implantar, una persona tarde de media 1 segundo en cruzar una línea de detección. Las detecciones deben ser por lo tanto lo más precisas posibles. - Facilidad: se intentaba ver la viabilidad. Debía ser sencillo y rápido comprobarlo. Comparativamente, Yolo ofrece un buen ratio calidad / velocidad y existe bastante documentación para realizar una prueba en poco tiempo.
36. Entrenamiento El entrenamiento se intentó hacer de forma ‘asistida’. Imagen del programa LabelImg
37. Entrenamiento - etiquetado
38. Entrenamiento El entrenamiento se intentó hacer de forma ‘asistida’. Se etiquetaron frames alternos (1 por segundo) del vídeo (en total unos 100 frames). Estas imágenes etiquetadas se utilizaron para realizar el primer entrenamiento. El modelo entrenado se utilizó para que el sistema reconociera los frames intermedios. De estos frames se escogieron únicamente los que mayor precisión tenían, se refinaron y entraron a formar parte del set de entrenamiento. Se empezó de nuevo el ciclo hasta completar el primer vídeo. Imagen del programa LabelImg
39. Entrenamiento - etiquetado El entrenamiento se realizó en máquinas sobre AWS de tipo p3 (incluyen GPU y la AMI viene ya preparada), en este caso se eligió una instancia p3.8xlarge. La duración de los ciclos de entrenamientos era de unas 2 horas en cada ejecución (cuando la calidad del entrenamiento alcanzaba los valores adecuados. El proceso de subida de ficheros (imágenes y ficheros de etiquetado) se realizó mediante scripts para optimizar el tiempo que la máquina estaba levantada.
40. Agrupación La inferencia del algoritmo se hace más pesada, lo que aumenta el tiempo de detección. Se crea un proceso para crear grupos de frames de forma que el primero pueda ser detectado mediante el algoritmo de ML, mientras que el resto se detectan con la librería Dlib ‘rellenando los huecos’ entre los frames de detección. Contamos con todos los test ya creados para la validación. Problemas Conseguir un tamaño de agrupación óptimo no es sencillo. Optamos por hacerlo dinámico para lograr el mejor rendimiento posible. . . . Lectura de Frames Priority Agrupación . . . Detección en grupos Tratamiento y envío de eventos Priority Throttling agrupación
42. Mejorando el sistema
43. El proceso de entrenamiento El entrenamiento del modelo requiere de un volumen muy alto de imágenes etiquetadas con distintas posibilidades para que el grado de fiabilidad sea elevado. Cambios en la luz ambiente en el momento de tomar la imagen o del contraste pueden llevar a errores (detecciones fallidas o detecciones falsas). ¿Cómo incrementar esta base de imágenes?
44. ¿Cómo mejorar el entrenamiento? El entrenamiento del modelo requiere de un volumen muy alto de imágenes etiquetadas con distintas posibilidades para que el grado de fiabilidad sea elevado. Cambios en la luz ambiente en el momento de tomar la imagen o del contraste pueden llevar a errores (detecciones fallidas o detecciones falsas). ¿Cómo mejorar el entrenamiento?
45. ¿Cómo mejorar el entrenamiento? El entrenamiento del modelo requiere de un volumen muy alto de imágenes etiquetadas con distintas posibilidades para que el grado de fiabilidad sea elevado. Cambios en la luz ambiente en el momento de tomar la imagen o del contraste pueden llevar a errores (detecciones fallidas o detecciones falsas). ¿Cómo mejorar el entrenamiento? No a la discriminación de los Vulcanianos!!!
46. Situación actual Entrada de planta 2 Entrada de planta 2 Office planta 2 Sala planta 2 (entrada 1) Sala planta 2 (entrada 2) Sala planta 2 Comedor planta 3 (entrada 1) Comedor planta 3 (entrada 2) Gimnasio Ojo de pez
47. Detecciones con bajo ‘confidence’ El proceso de detección proporciona datos con el porcentaje de seguridad con las que el algoritmo ejecuta. Si el porcentaje supera un determinado umbral (90%) determinamos que la detección ha sido válida y se sigue el flujo indicado. Sino la detección no es válida. . . . Lectura de Frames Priority Agrupación . . . Detección en grupos Tratamiento y envío de eventos Priority Throttling agrupación
48. Detecciones con bajo ‘confidence’ El proceso de detección proporciona datos con el porcentaje de seguridad con las que el algoritmo ejecuta. Si el porcentaje supera un determinado umbral (90%) determinamos que la detección ha sido válida y se sigue el flujo indicado. Sino la detección no es válida. Para obtener imágenes con las que mejorar nuestro algoritmo, almacenamos las detecciones fallidas que superen un 50% ‘confidence’ para analizarlas y etiquetarlas a posteriormente. Se han establecido mecanismos para evitar el llenado del disco. . . . Lectura de Frames Priority Agrupación . . . Detección en grupos Tratamiento y envío de eventos Priority Throttling agrupación Almacenamiento en disco
49. Automatización Un proceso automatizado saca todos los días las imágenes almacenadas las raspis (Jenkins + Ansible). AWS S3
50. Automatización Un proceso automatizado saca todos los días las imágenes almacenadas las raspis (Jenkins + Ansible). Utilizamos los scripts creados anteriormente para ayudar a preparar el ‘entorno’ de etiquetado ‘asistido’ y volcar los resultados a S3. AWS S3 AWS S3
51. Automatización Un proceso automatizado saca todos los días las imágenes almacenadas las raspis (Jenkins + Ansible). Utilizamos los scripts creados anteriormente para ayudar a preparar el ‘entorno’ de etiquetado ‘asistido’ y volcar los resultados a S3. Generamos varios playbook (ansible) para el proceso entrenamiento. • Levanta la instancia • Descarga el nuevo conjunto de imágenes etiquetadas • Arranca el proceso de entrenamiento • Para el proceso llegado a un umbral • Descarga el modelo entrenado AWS S3 AWS S3 AWS S3
52. Automatización Un proceso automatizado saca todos los días las imágenes almacenadas las raspis (Jenkins + Ansible). Utilizamos los scripts creados anteriormente para ayudar a preparar el ‘entorno’ de etiquetado ‘asistido’ y volcar los resultados a S3. Generamos varios playbook (ansible) para el proceso entrenamiento. • Levanta la instancia • Descarga el nuevo conjunto de imágenes etiquetadas • Arranca el proceso de entrenamiento • Para el proceso llegado a un umbral • Descarga el modelo entrenado Cuando existan nuevas versiones de los modelos, un playbook de ansible los instala. AWS S3 AWS S3 AWS S3