Detección de indicadores de fatiga basado en la obtención de imágenes en tiempo real.

Dentro del proyecto Simbiosys buscamos la detección de fatiga mediante imágenes obtenidas por cámara, como apoyo al sistema de detección de indicadores de fatiga mediante EEG.

Este módulo del sistema multisensor consiste en una cámara de bajo coste que obtiene las imágenes del sujeto para analizar en tiempo real. Además, es necesario que pueda detectar luz infrarroja, para los casos en los que la luz sea escasa. El módulo se basa en la detección facial de la cara, para poder obtener posteriormente la detección de ambos ojos.

 

El objetivo es obtener el porcentaje de tiempo en el que el ojo se encuentra cerrado durante un minuto (AVECLOS). Por tanto, si el porcentaje es mayor que el porcentaje normal de tiempo en el que una persona presenta los ojos cerrados, se considera que el sujeto se encuentra cansado o fatigado.

anigif_enhanced-1921-1443102494-2

 

El sistema final comparará la información obtenida tanto como por el electroencefalograma como por la cámara, para obtener con mayor seguridad el estado en el que se encuentra el sujeto.

Demotherm. Pruebas del robot en entorno real de trabajo

Finalizados los desarrollos software en el laboratorio B105, era momento de volver a la universidad de Oviedo para realizar pequeñas reparaciones en la parte mecánica del robot.

Estas modificaciones mecánicas fueron rápidas ya que básicamente consistieron en cambiar piezas ya desarrolladas por otras modificadas que cumplían mejor con su misión.

Cuando el robot estuvo a punto tanto en la parte mecánica como electrónica, era momento de visitar las instalaciones de Therman, la empresa responsable del proyecto Demotherm. El objetivo de esta visita era el enfrentar el robot a un escenario real de trabajo y comprobar si la parte mecánica y electrónica cumplían con las especificaciones con las que se definió el proyecto.

El robot de demolición de refractario para ciclones cumplió holgadamente sus expectativas y fue capaz de agarrarse a las paredes del ciclón con sus orugas y realizar desplazamientos verticales. Una vez realizadas estas pruebas de comunicación, control, fuerza y movimientos en un ciclón de ensayo sólo nos queda probar la bomba de agua. 

Pruebas All-in-One preliminares

En el proyecto All in One el objetivo fundamental es recoger datos de tráfico para, mediante diferentes métodos, monitorizar el tráfico y realizar un conteo de vehículos.

Para realizar las primeras pruebas nos pusimos en contacto con nuestros compañeros de Aceinsa que nos facilitaron varios puntos clave de la ciudad de Majadahonda como posibles lugares para realizar las pruebas. Gracias a su colaboración, y a la del ayuntamiento de Majadahonda, hemos podido realizar las mismas y tener de forma permanente una caja con alimentación que nos servirá para las pruebas futuras.

El objetivo de estos tests ha consistido en la toma de, aproximadamente, una hora de medidas acompañadas de la correspondiente filmación de vídeo para el cotejo de los datos recogidos a posteriori.

Esperamos que, como resultado de estas pruebas, seamos capaces de realizar una calibración más apropiada de los cabezales radar utilizados en el sistema y que la detección y conteo de vehículos aumente en fiabilidad.

 

IMG_6204
Caja para pruebas situada en la misma farola juntos con dos cabezales radar y una cámara de vídeo

Demotherm. Desarrollo software del robot

Una vez concluyeron las primeras pruebas de integración de la parte electrónica-mecánica el robot viajó al B105 en su sede de Teleco-Madrid para continuar con los desarrollos del proyecto Demotherm.

Antes de este momento ya se había avanzado bastante en diferentes módulos tanto de software como de hardware electrónico. Por un lado se habían diseñado, fabricado y soldado varias placas de circuito impreso para probar las comunicaciones CAN entre la unidad central de proceso del robot y los motores y sensores del mismo. Por otro lado estaban ya bastante avanzados los desarrollos de drivers para los motores y sensores y la arquitectura software que iba a seguir el proyecto.

Una vez el robot estuvo con nosotros se pudieron probar estos desarrollos software y hardware con un interacción directa sobre la mecánica del robot. Los desarrollos dieron sus frutos y todo funcionaba como se esperaba. Mientras el robot estuvo en el B105 se realizaron numerosos avances en el software de control. Desde las diferentes capas de control de los motores, potenciómetros, acelerómetros, etc. hasta la parte de comunicaciones remotas.

El robot está basado en un ARM® 32-bit Cortex®-M7 CPU con FPU, y todo su software ha sido desarrollado en lenguaje C, basando su arquitectura en el sistema operativo FreeRTOS.

No hay que perder de vista que este robot se debe controlar de forma remota por un operario, por lo que debemos tener una interfaz de usuario a partir de la cual el operario tenga control total del robot, y además pueda obtener la información que considere necesaria para operar.

Cuando todos estos desarrollos fueron testeados y se llegó a un estado estable de funcionamiento, era momento de volver a Gijón para probar el robot en un entorno real de trabajo, y ver si tanto mecánica como electrónica cumplen con sus especificaciones.

 

Demotherm. Integración electrónica-mecánica

El pasado mes de julio el grupo de trabajo de nuestro laboratorio B105, responsable del desarrollo del robot del proyecto Demotherm se desplazó a Gijón. Concretamente a la universidad de Oviedo, para trabajar conjuntamente con el Grupo de Ingeniería de los Procesos de Fabricación.

El objetivo de la visita era hacer la integración electrónica-mecánica del robot que se encuentra en desarrollo. La parte electrónica había sido desarrollada por nosotros en Teleco (Madrid), mientras que la parte mecánica había sido desarrollada por el grupo de Gijón. Este encuentro era el primero en el que ambos desarrollos se unirían.

Durante varios días se realizaron diversas pruebas e integraciones para probar cada uno de los pequeños módulos que conforman el robot. A lo largo de este periodo se detectaron pequeños errores de fácil arreglo y se comprobó que ambos desarrollos seguían la línea de desarrollo previamente acordada.

Tras estos productivos días en Gijón, se decidió que el robot viajara al laboratorio B105 para continuar allí con el desarrollo del software y su implementación en el robot.