lunes, 27 de mayo de 2013

Resumen: Data Collection, Storage, and Retrieval with an Underwater Sensor Network

Data Collection, Storage, and Retrieval with an Underwater Sensor Network
por I. Vasilescu , K. Kotay , D. Rus , M. Dunbabin , P. Corke

En el paper se presenta una nueva plataforma para redes sensoras submarinas para utilizarse en monitoreo de arrecifes de coral a largo término. La red sensora consiste en nodos sensores tanto estáticos y móviles, bajo el agua. Losnodos se comunican punto a punto utilizando un sistema de comunicación óptico de alta velocidad integrado dentro del stack TinyOS, y difunden la señal utilizando un protocolo acústico integrado en el mismo TinyOS. Cuentan con una gran variedad de capacidades de sensores, incluyendo cámaras, sensores para la temperatura del agua y presión. Los nodos móviles pueden localizar y flotar encima de los nodos estáticos, para realizar tareas de mantenimiento de la red como la relocalización y recuperación.

Se describen las arquitecturas de hardware y software para la red sensora submarina, además de los protocolos de redes acústicas y ópticas usados.

Introducción

La aplicación de las redes sensoras inalámbricas bajo el mar tiene un alto potencial para el monitoreo del estado de los ríos y ambientes marinos. Los océanos por sí mismos cubren 70% del planeta y junto a los ríos y lagos son críticos como fuentes de agua para nosotros. Monitorear estos ambientes es difícil y costoso para los humanos (los buzos usualmente regulan el tiempo y las profundidades a las que llegan, y requieren un bote en la superficie, lo que es costoso y depende del clima).

Una red sensora lanzada bajo el agua, puede monitorear variables físicas como la temperatura, presión, conductividad, turbiedad y ciertos contaminantes. Además se pueden añadir sensores para obtener imágenes y poder visualizar y medir los cambios en el ambiente o hasta contar y clasificar especies.

Sin embargo, problemas como la eficiencia de la batería, el lanzamiento y reparación de los dispositivos son comunes en tierra, por lo que bajo el agua sería mucho más difícil. 

Recolección de Datos

La red sensora submarina que se propone facilita el estudio de sistemas complejos submarinos, regulando y automatizando la recolección de datos. Los sensores estáticos permiten la grabación sintomática de datos. Los nodos móviles permiten "data muling" eficiente e integración, envío de datos a la base en la superficie (independiente de la localización física de los sensores) y operaciones submarinas en largo término.

Por ejemplo, se considera una gran área del fondo del mar donde los nodos se colocan en una cuadrilla de 200m y cubren un área de 10 x 10 km con 50 x 50 nodos. El largo del camino que se necesitaría para visitar todos los nodos es 50km, que en una velocidad eficiente de un submarino a 0.5 m/s tomaría 28 horas de viaje. Además, cada nodo hace mediciones cada 10 minutos, lo que comprende 4 bytes, dando un total de 24 bytes por hora o .56 Kbytes por día. La red de 50 x 50 nodos entonces almacenaría 1.37 MBytes por día. 

Los datos pueden ser recolectados de dos formas: con un robot autónomo funcionando como un cargador de datos utilizando comunicación óptica de rango corto ó usando una red de comunicación acústica con ruteo de nodo a nodo. Si el robot visito cada nodo y utilizo la transmisión óptica desarrollada en el paper (con una tasa de 320 Kbytes por segund) 6.86 MBytes serán cargados en 21 segundos. Este proceso consumiría solo 48 mJ de energía de cada nodo.


Infraestructura de Hardware


La investigación del paper contiene dos elementos de hardware críticos, los nodos sensores submarinos, y los vehículos autónomos submarinos que proveen comunicaciones, movilidad y un medio para recuperar y despliegue de nodos. En el paper se utilizan dos vehículos: Starbug y Amour.

Nodo sensor submarino Aquafleck

Se utilizan 20 nodos sensores submarinos llamados Aquaflecks. Cada nodo está construido al rededor de un CPU llamado Fleck, basado en el procesador ATmega128, con 128Kbytes de memoria flash, 4 Kbytes de RAM. El CPU Fleck es una interfaz a una placa de comunicación óptica especial con dos pines digitales IO. Uno de esos pines es usado para encender o apagar un LED, mientras que otro es usado para sentir  la salida de un diodo. Todos los electrónicos analógicos están en la placa de interfaz. El Fleck es además una interfaz con la placa de sensores. 



Amour

Amour es un nodo móvil (vehículo submarino autónomo) usado para ensamblar y transportar los nodos Aqua Fleck. Amour puede también localizar un nodo sensor submarino y flotar encima de el para recolectar datos. 




El cuerpo del robot consiste en un tubo acrílico de 48.26 cm de largo y 15.24 cm de diámetro. Tiene cuatro propulsores con un máximo poder de 150W y una propulsión estática máxima de 35 N cada uno. Dos de sus propulsores están alineados verticalmente. Un sensor de presión proporciona una retroalimentación acerca de la profundidad.  Una brújula magnética es usada para conocer la orientación y permite patrones en la navegación, como por ejemplo movimiento a través de la cuadrícula, y búsqueda en espiral. La batería es de polímero de lítio a 140W. El procesador principal es un microcontrolador de 8 bits con 64 Kbytes de memoria para programas y 2 Kbytes de RAM.

Starbug 

El vehículo submarino autónomo Starbug es usado para localizar los nodos Aquafleck por visión, para flotar encima de los AquaFleck para recolectar datos y para ensamblarse con el Amour para proveer retroalimentación y control visual para un gran largo de navegación. Starbug es un híbrido diseñado para optimizar la duración, maniobrabilidad y funcionalidad. 


La duración se logra de mejor manera mediante un vehículo con estilo de torpedo, aunque requiere que el vehículo tenga movimiento longitudinal. La maniobrabilidad se logra mediante los vehículos tipo caja típicos para la mayoría de plataformas de investigación. 

La red

La comunicación entre redes sensoras en tierra es primeramente basada en radio, debido al bajo costo en energía necesario para transmitir mensajes de radio y la básica naturaleza omnidireccional de la propagación de radio. Desafortunadamente, la mayoría del espectro electromagnético es significativamente atenuado por el agua salada, dejando las aplicaciones de radio sin uso en esta situación. La excepción está en la porción visible de luz del espectro que es menos atenuada, especialmente en las frecuencias de luz verde y azul. La ventaja principal de la comunicación óptica es la alta tasa de datos (en teoría) debido a la frecuencia de alta señal, mientras que las desventajas son el rango y la operación en línea de visión. 

El otro acercamiento obvio para comunicación submarina es el sonido. Éste ha sido usado extensivamente para la localización (en forma de sonar) y para comunicaciones en rangos cortos. Mientras que la comunicación acústica puede ser usado para rangos mucho mayores a los ópticos, también sufre de atenuación, con altas frecuencias siendo atenuadas más que bajas frecuencias de señal. En el paper, se incorpora un híbrido entre ambos.

La comunicación óptica, aunque está restringida a aplicaciones con rango corto, tiene un ancho de banda teórico mucho más alto que la comunicación acústica. Esto la hace interesante cuando se necesitan transmitir grandes cantidades de datos. En una situación donde se requiere hacer mediciones bajo el agua por un tiempo largo, cada sensor puede acumular una cantidad de datos, especialmente si los nodos están equipados con cámaras. 

Enviar ésta cantidad de datos sobre un enlace de comunicación acústico de baja velocidad requeriría una cantidad significativa de tiempo, y prevendría otros nodos de comunicarse acústicamente debido a la naturaleza de la comunicación acústica. Sin embargo, usando comunicación óptica, los datos pueden ser transferidos rápidamente sin prevenir señalización de eventos  usando comunicación acústica. 


Conclusión del Paper


En el paper se reporta un primer prototipo para una red sensora submarina, describiendo el hardware, la infraestructura de la red, entre otras características. El trabajo demuestra que las redes sensoras son factibles bajo el agua. Demuestra además los beneficios de crear un sistema submarino que combina nodos estáticos y móviles en una misma red, como una combinación de comunicación acústica para transmisiones de baja tasa de datos y comunicación óptica para alta tasa de datos en comunicaciones punto a punto.

Conclusión personal


El paper establece una buena alternativa para realizar mediciones bajo el agua utilizando redes sensoras. Las aplicaciones que un sistema como éste puede tener son enormes, pensando en cosas como monitorear el estado de arrecifes, o la contaminación de un determinado río o lago, o hasta monitorear y clasificar diferentes especies marinas a diferentes profundidades.

Presenta un interesante modelo, combinando tanto comunicaciones acústicas como comunicaciones ópticas, para poder hacer un balance entre las ventajas y desventajas de ambas y contar con un sistema de nodos estáticos que realizan las mediciones y nodos móviles que flotan sobre ellos cada cierto tiempo recolectando los datos.

Referencias:
  • I. Vasilescu , K. Kotay , D. Rus , M. Dunbabin , P. Corke,
    "Data Collection, Storage, and Retrieval with an Underwater Sensor Network",
  • (Proceedings of the International Conference on Embedded Networked Sensor Systems ),(ACM SenSys 2005)

viernes, 24 de mayo de 2013

Laboratorio Extra: Wavelets

Para puntos extras se dió la oportunidad de realizar un pequeño ejercicio utilizando wavelets para el procesamiento de imágenes, en particular utilizando la librería pywavelets.



Lo que realicé (con ayuda del ejemplo incluido en las referencias) fue un generador y eliiminador de ruido utilizando diferentes familias de wavelets de la librería pywavelet.

El procedimiento es simple, primero es convertir la imagen en un arreglo (dependiente de su tamaño) el cual contiene valores entre 0 y 255, esto significa que la imagen debe convertirse a escala de grises. Después se le aplica ruido blanco dependiente de una variable $\sigma$ (entre mayor, más ruido) y se busca después recuperar la mayor parte de la imagen del ruido posible, utilizando diferentes familias de wavelets.

De izquierda a derecha, imagen original y con ruido añadido.


Eliminación de ruido utilizando el wavelet haar (Sin cambio aparente)



Eliminación de ruido utilizando el wavelet sym15


Eliminación de ruido utilizando el wavelet coif2



Eliminación de ruido utilizando el wavelet bior2.8



En general, la eliminación de ruido es aceptable usando los wavelets de la familia bior, coif y sym predefinidos en pywavelets, pero haar no parece tener ningún efecto notable sobre el ruido. Todo esto considerando que se utilizó la misma $\sigma = 5.0$ para tanto generar ruido, como para eliminarlo, de ser diferente la eliminación de ruido podría empeorar.

Código:




Referencias:

martes, 21 de mayo de 2013

Resumen: Ad hoc Positioning system

Ad hoc Positioning system
Dragos Niculescu, Badri Nath
Computer Science Department
Rutgers University

Encontrar las localizaciones de cada nodo en una red ad hoc sin la ayuda de GPS es importante en los casos en los que el GPS no este accesible o no sea práctico de usar debido a limitaciones energéticas u otras condiciones. Conociendo la localización, sería posible realizar ruteo suficientemente isotrópico (uniforme en todas las direcciones), sin el uso de grandes tablas de ruteo.

El método que se propone en el paper es un algoritmo de posicionamiento de brinco a brinco distribuido, que funciona como una extensión de tanto el ruteo con posicionamiento GPS para proveer una localización aproximada para todos los nodos de una red donde solo una fracción limitada de nodos tienen capacidad para conocer su localización por sí mismos.

Existen algunos requerimientos que debe satisfacer un algoritmo de posicionamiento.
  • Tiene que ser distribuido. En una red muy grande con poca memoria y nodos de banda ancha baja, diseñados para operación intermitente, ir y venir por una topología entera a un servidor en brinco por brinco pondría una carga alta en los nodos cercanos al servidor. Áreas particionadas harían la centralización imposible, y las redes antisotrópicas pondrían aún más carga en los nodos que tienen que soportar más reenvío de tráfico que los demás. Cambiar las topologías haría también que la solución centralizada sea no deseable.
  • Debe minimizar la catidad de comunicación de nodo a nodo y el poder de cómputo, ya que la comunicación por radio y el procesador son las principales fuentes de gasto de energía de la batería. También es deseable tener una baja complejidad en el envío de señales en caso de que la red cambie de topología.
  • El sistema de posicionamiento debería de funcionar aún cuando la red esté desconectada. En el contexto de redes sensoras, la información puede ser recolectada más adelante por una estación base que esté sobre volando.
  • Finalmente debe proveer un posicionamiento absoluto, en el sistema de coordenadas global del GPS, opuesto a las coordenadas relativas debido a las siguientes razones: el posicionamiento relativo puede incurrir a altos costos en el envío de señales en el caso de que la topología cambie, y el posicionamiento absoluto permite un espacio de nombres único, el de las coordenadas GPS.

Algoritmo APS

No es eficiente tener "landmarks" que emitan señales usando gran cantidad de energía para cubrir toda la red por diferentes razones: colisiones con comunicación local, alto uso de energía, y problemas de cobertura al moverse. También, no es aceptable asumir ciertas posiciones para los landmarks, debido a que las aplicaciones que pueden existir puede estar en vuelo sobre áreas inaccesibles, o posiblemente dependiendo de la reconfiguración de la red. 

En el algoritmo algunos nodos (landmarks) conocen sus posiciones, otros nodos infieren los rangos a por lo menos 3 de estos landmarks para estimar sus distancias y calcular su distancia estimada a los vecinos. Los  nodos usan:

  •  Medición de fuerza de señal
  • Conteo de saltos, un híbrido entre GPS y enrutamiento vector distancia
    • Como en el vector distancia, las distancias hacia los landmarks son propagadas brinco a brinco.
    • Como en GPS, cada nodo estima su propia localización.
Propagación

Como en el vector de distancia, los vecinos intercambian estimados de las distancias a los landmarks. Para ello se utilizan cuatro métodos posibles:
  • "DV-hop": Distancia al landmark, en saltos (vector de distancia estándar)
    • Nunca mide la distancia entre vecinos por ser insensible a errores. 
    • Cada nodo mantiene una tabla con ${X_{i}, Y_{i}, j_{i}}$  utilizando vector de distancia.
    • Cada landmark ${X_{i}, Y_{i}}$ computa una corrección y la inunda en la red, usando la fórmula:
    • Cada nodo usa la corrección del landmark más cercano y multiplica sus distancias de brincos por la corrección.
                                       
  • "Propagación con Distancia DV": 
    • Utiliza distancia de viaje, en metros.
    • Cada nodo mantiene una tabla ${X_{i}, Y_{i}, d_{i}}$
    • Cada landmark ${X_{i}, Y_{i}}$
      • Computa una corrección y la inunda en la red, usando:


      • Cada nodo usa la corrección de su landmark más cercano y multiplica sus distancias por la corrección.

  • "Euclideano": Distancia euclideana al landmark.

    • El nodo A mide la distancia a sus vecinos inmediatos B y C.
    • Aprende la distancia BC de cualquiera de los dos o posiblemente la infiere, mapeando todos uss vecinos
    • B y C conocen sus distancias euclideanas a el landmark L
    • A necesita encontrar la diagonal AL.
  • "Coordenada": Cordenadas propias de los nodos en un sistema de coordenadas basado en los landmarks.
    • Cada landmark $i$ escoge un sistema de coordenadas aleatorios en el cual las coordenadas son ciertas ($XL_i ;  YL_i $), obtenidas por GPS.
    • Un nodo N
      • Mantiene una tabla ${(X_{i}, Y_{i}), (X_{Li}, Y_{Li}) }$
      • Mide distancias a sus nodos vecinos
      • Cuanto tiene las coordenadas de hasta 3 nodos computa su propia localización usando el procedimiento GPS.
Conclusión

Un sistema de posicionamiento global utilizando redes adhoc proveen una buena alternativa a un GPS (en cuestiones energéticas y de precisión, siendo mejor APS). 

Básicamente, los nodos en una red adhoc deberían saber su localización en coordenadas globales, tener bajo costo para movilidad, precisión comparable con el rango de comunicación del  del nodo, regiones desconectadas que puedan operar independientemente.  El recalculo de las posiciones de los nodos se hace entonces solo en los nodos en movimiento.

Referencia:

Redes Adhoc

Para esta tarea se pidió realizar un simulación de redes adhoc.


Básicamente el código genera una cantidad de nodos fija al inicio, y los comienza a mover por la pantalla en base a un punto con un radio definido al que llamo misión. Los nodos buscan llegar a la misión, pero algunos nodos tienen un nodo líder, siguiendo sus movimientos para llegar a la misión. Cuando un nodo llega al área de la misión se imprime su ID. La misión cambia cada cierto tiempo aleatoriamente (a una distancia mínima de 300 pixeles de la última misión para evitar que aparezca muy cerca consecutivamente). 

Además algunos nodos envían mensajes y otros no cada cierto tiempo, denotando los que envían con color verde, y los que no de color celeste. Cada que envían información los nodos gastan una batería que tienen definida. Cuando la batería muere el nodo es borrado y se genera uno nuevo en algún lugar, conectándolo con otro nodo para evitar que la red no esté totalmente conectada.

Aquí la animación:



Código:


Retroalimentaciones finales a proyectos

SeguriLap

Como a muchos hubiera audado una buena organización más temprana, pero eso esta de menos. Me pareció que ola idea era muy buena, una detección de caras para bloquear la pantalla en caso de no ser la cara del usuario. El único punto negativo en cuanto a recursos es el uso constante de la cámara web, que requeriría estar encendido todo el tiempo, pero para una aplicación en oficinas o algo en donde la computadora está conectada todo el tiempo no hay problema. 

En general me pareció que el proyecto fue bueno, ya que hace lo que se prometió con una simple configuración para definir la cara del usuario.

CarNXP

Igual que nosotros, cumplieron con la mayoría de las funcionalidades definidas al inicio de su planeación, pero fueron incapaces de integrar todo de forma conjunta. Atribuyo esto a tanto falta de tiempo (porque definieron muchas funcionalidades, para un prototipo de 6 meses) como a falta de planeación en como integrarlo conjunto, que es un problema que normalmente no se piensa que puede suceder cuando se proponen ideas o mejoras para un proyecto. 

Alarma Inteligente (Despertador)


Un buen proyecto, personalmente considerando que siempre me despierto antes que la alarma, y es molesto cuando empieza a sonar cuando ya no estoy dormido y ni siquiera estoy cerca del cuarto como para apagarla. Mostraron el prototipo, y cumplieron con lo prometido, asi que en cuanto a organización pienso que fue de los mejores equipos en planear el proyecto de forma adecuada.

Galería Inteligente

Un proyecto muy interesante con aplicaciones a museos, y a mi parecer fue de los pocos que concluirán lo que se prometió de manera satisfactoria (vigilar con sensores si alguien está próximo a la pintura/exhibición correspondiente y ejecutar una grabación con información acerca del mismo).

Me hubiera gustado que funcionara con RFID y algún dispositivo rentado por el museo, para que solo las personas que deseen escuchar/leer la información eligieran tener esa funcionalidad.

Casa Inteligente

Creo que el proyecto era muy bueno fundamento, una casa inteligente que con un solo botón o algo así se colocará en un estado de seguridad determinado, cerrando todas las puertas y ventanas y encendiendo sensores para detectar movimiento. Al igual que nosotros decidieron simular el proceso utilizando una casa a tamaño escala, lo que según mi propio aprendizaje durante nuestro proyecto es una mala idea, ya que si en verdad no se planea realizarlo en su aplicación física real, se debe optar por simularla de alguna manera, mediante software o hardware simple (LEDS).

Alarma Inteligente (Carro)

Fue el único proyecto que aplicó su proyecto a la aplicación real directamente (galería inteligente lo hizo pero por motivos obvios no en un museo real). La idea de una alarma que pudiera activarse al salir del auto, pero que envíe notificaciones a un dispositivo móvil es mucho mejor que la simple idea de sonar una alarma, lo que mucha gente hoy en dia ignora.

En cuanto a planeación, sufrieron igual que muchos el hecho de no seguir correctamente la calendarización, y por lo tanto no cumplieron con todo lo prometido, pero por ser 6 meses me parece que hicieron más de lo necesario.

Localizador Inteligente


Faltó realizar un mejor prototipo para entender el funcionamiento correcto del proyecto, porque cambio de localización de niños y ancianos a localización de objetos y de nuevo localización de personas, pero en sí la idea final era interesante.

Oficina Inteligente

Los tags para automáticamente abrir aplicaciones al ser registradas la veo como una idea muy fácil de expandir para usuarios normales de computación que desean personalizar el contenido que los usuarios acceden por defecto al iniciar sesión.

Es decir, personalmente me gustaría que al iniciar se abra el navegador web y el reproductor de música, pero alguien más que use la misma computadora puede querer algo diferente, y separar en sesiones quizás no sea lo mejor.  En conclusión, el proyecto tiene muchas más aplicaciones que la original que plantearon, lo que me parece muy útil.

Autoretroalimentación: UGarage

¿Qué se tenía planeado?

Contar con un sistema añadido a un Garage con el cual sería posible expandir sus funcionalidades para poder hacer lo siguiente:
  • Abrir el Garage con un Smartphone mediante Bluetooth.
  • Abrir el Garage desde una Plataforma Web de forma segura.
  • Abrir el Garage con códigos QR generados para amigos con una fecha de expiración.
  • Utilizar la misma cámara usada para detectar códigos QR para informar sobre actividad sospechosa en el frente del Garage, tomar fotos y enviarlas a un correo.
  • Generación de historial de apertura y cerrado.
Todo lo anterior integrado en un solo gran proyecto.

¿Qué se hizo?

Todo lo anterior está programado en cuanto a software y una simulación en Hardware. 

Nosotros en nuestro proyecto, proponemos un sistema añadido al Garage para las tareas antes mencionadas, asumiendo que el Garage y su funcionamiento ya esta implementado. Por ello, la forma de simularlo fue utilizando simples LEDS de colores (que igualmente deberían de estar disponibles en el sistema o algún panel para informar de la situación). Un LED verde que enciende cuando se abre la puerta, un LED amarillo cuando se cierra la puerta y un LED rojo que avise que no se puede abrir por alguna razón (contraseña incorrecta, QR no válido). 

Con eso, las funcionalidades que se buscaron se implementaron en un prototipo probado localmente, y hace lo siguiente:
  • Apertura con Smartphone: La aplicación, disponible para Android, se conecta con el dispositivo y envía por bluetooth una señal para abrir o cerrar el Garage, adjuntando la contraseña además para validar que en verdad el usuario puede manipular la puerta. Básicamente, si la contraseña configurada es correcta y se presiona el botón abrir se enciende el LED verde (abrir puerta), y si se presiona el botón cerrar se enciende el led Amarillo. En caso de ingresar una contraseña no válida se enciende el LED amarillo.
  • Abrir desde plataforma web:  La plataforma web, con un usuario autentificado puede abrir la puerta de Garage desde la sección Mi Garage. En dicha sección se presenta un botón de abrir y uno para cerrar, además de información acerca del último estado registrado de la puerta (Abierto o cerrado) y un timestamp con la fecha del momento cuando ocurrió.
  • Abrir con código QR: Desde la plataforma web, con un usuario autenficado se pueden generar códigos QR a nombre de alguien en específico con una fecha de expiración dada y los almacena en una base de datos. Esto hace que cuando una persona se presente al dispositivo y muestre el código QR, la puerta se abra o cierra dependiendo del estado actual de la misma. Para eliminar QRs cuya fecha de expiración ya ha pasado, verifica el código en una base de datos para eliminarlo si la fecha ha pasado, ignorandolo de ahí en adelante.
  • Notificaciones: Con una cámara grabando la entrada del Garage y un programa corriendo en el fondo analizando el video, se busca detectar cambios en el fondo regular para enviar notificaciones cuando ese cambio permanece un tiempo dado en la pantalla. Al cumplirse el tiempo se envía una notificación y una foto de lo ocurrido a un correo dado. Para evitar enviar múltiples fotos de un mismo objeto, y por lo tanto spam, el fondo regular se recalcula cuando se detecta ese cambio, y automáticamente cada cierto tiempo para eliminar fallas por cambio en la iluminación (día/noche).
  • Historial: Toda apertura y cerrado del Garage se registra en una base de datos, con el timestamp en cuando se abrió, si se abrió o cerró, y con que servicio se abrió (actualmente implementado solo para QR y el servicio web, no con dispositivo móvil). Este historial se puede acceder en el servicio web en la cuenta del usuario.

¿Qué hice yo?

Inicialmente, mi asignación fue el servicio web y el prototipo del Garage a escala. Cuando se definió que nos enfocaríamos más en el servicio web, el prototipo de Garage pasó a ser de baja prioridad. 

Al final, terminé realizando el servicio web con lo definido (probado localmente) y además por fallas en el detector QR implementado por nosotros, agregue la funcionalidad con QR, para decodificar los QR, compararlos con la base de datos y saber si es válido o no, y después conectarse con el Arduino y encender la señal correspondiente.

Además, realicé la conexión a Bluetooth con el Arduino.

¿Qué se debió hacer?

Pienso que se debió de haber planeado mejor la forma de integrar todo conjunto en un solo proyecto, debido a que solo se contaba con los módulos por separado por falta de ideas de como integrarlos. Otro problema fue el hardware, ya que no teníamos en mente que el Arduino Uno solo puede realizar una conexión serial por Hardware (o con el servidor o con el dispositivo móvil). 

Además pienso que se debió elegir un líder desde el inicio, ya que al parecer la gente asumió que uno de nostotros era el líder y esperaba en todo momento órdenes para empezar, en vez de realizar lo que se asignó y simplemente informar a los demás cuando estuviera listo.

lunes, 20 de mayo de 2013

Plan de Negocios: Autobuses Wi-Fi + Paradas Inteligentes

Para esta tarea de laboratorio se pidió realizar un plan de negocio de algún proyecto interesante con aplicaciones en el área de cómputo ubicuo. Yo elegí la idea de dar uso a los autobuses con Internet, para poder informar a las paradas de camión su posición y de esa forma calcular un aproximado del tiempo de llegada de tal forma que los usuarios de la ruta que estén esperando el camión puedan saber el tiempo que falta para que lleguen.

Plan de Negocios

Definición

El proyecto consistiría en módulos inteligentes localizados en paradas de camiones. Éstos módulos estarían conectados a Internet, y con acceso a una base de datos de las rutas que pasan por su parada correspondiente. La base de datos contendría información sobre la cantidad de camiones en ruta, la posición actual de los camiones, su dirección, y más. Con ello sería posible calcular cuanto tiempo falta para que un camión de una determinada ruta llegue a la parada.

Tipo de Organización Propuesta

Debido a que principalmente el objetivo es dar un servicio público a las personas que utilizan el transporte urbano, no parece ser lo mejor que una empresa privada realice tal proyecto (pensando en los beneficios). Sin embargo esto no cambia que el beneficio a los ciudadanos es grande, evitando pérdida de tiempo innecesaria. Por ello veo posible que algún organismo de Gobierno pudiera adoptar el proyecto, pensando en el desarrollo tecnológico del País y en los beneficios al público.

Bases de Crecimiento

La idea principal del proyecto es informar sobre el tiempo restante para que una determinada ruta llegue a la parada de camión. Inicialmente esto podría ser aplicable para rutas importantes o centrales de autobuses, donde los retrasos son importantes y hay que conocerlos. El crecimiento entonces sería expandir esto a las rutas de camiones públicas para cubrir una mayor cantidad de usuarios. 

Lo anterior en cuanto a crecimiento en cantidad de usuarios, en cuanto a crecimiento tecnológico sería posible incrementar la información que el módulo puede dar a los usuarios, agregando datos como la cantidad de camiones que actualmente están circulando por cada ruta, precios de las rutas (en algunos casos son diferentes), mostrar el mapa de cada ruta para conocer sus paradas, etc.

El proyecto crecería entorno a las necesidades de los usuarios.

Justificación

El origen de la idea surgió a raíz de los camiones con conexión Wi-Fi. Si bien hoy en día son pocos, el hecho es que en un futuro estos camiones serán mucho más frecuentes y aprovechar este tipo de tecnología puede beneficiar a los mismos usuarios de las rutas de camiones. Inicialmente según mi parecer, la conexión Wi-Fi de los camiones está pensada para permitir a los usuarios navegar por Internet en el tiempo en el que hacen su recorrido en el camión, lo cual es bastante bueno. Pero hay que pensar en como utilizar estas tecnologías por más que simple comodidad durante el viaje.

Objetivo

El objetivo sería ayudar a los usuarios a informarse acerca del estado de la ruta de camiones que están esperando. Esto involucra lo siguiente:
  • Conocer la distancia aproximada desde el módulo a la que se encuentra el camión.
  • Conocer el tiempo esperado restante para que el camión llegue a la parada.
Los dos puntos anteriores son fundamentales, y el resultado sería de ayuda en la toma de decisión de los usuarios, para que puedan decidir si esperarán el camión o tomarán un taxi. También sería útil para usuarios que cuentan con una ruta primaria y una ruta secundaria a tomar (la primaria lo lleva más cerca a su destino que la secundaria), donde podrían elegir tomar la ruta secundaria al conocer que la ruta primaria está a una distancia considerable.

Análisis FODA

Fortalezas
  • Innovación Tecnológica: El proyecto sería de gran innovación tecnológica de ser implementado físicamente.
  • Altamente viable (tecnológica y socialmente): El proyecto no solo es posible, sino que muchas personas aprobarían su implementación
  • Alta retroalimentación de los usuarios: La cantidad de usuarios de las rutas urbanas ayudaría a obtener retroalimentación para mejorar el sistema

Oportunidades
  • Oportunidad de crecimiento: El proyecto puede crecer para ofrecer más funcionalidades.
  • Beneficios a los Usuarios: Los usuarios serían los más beneficiados por el servicio.
  • Uso de recursos existentes(parcialmente): Tentativamente se haría uso de camiones con conexión Wi-FI, de los cuales algunas rutas ya manejan.
Debilidades
  • Posible alto costo de desarrollo/implementación: Naturalmente sería imposible pensar en colocar un módulo por parada, y aún sin eso el costo de desarrollo de cada módulo podría ser alto.
  • Falta de aceptación por usuarios: Usuarios sin interés por la tecnología podrían no prestar atención o desaprobar el proyecto.
  • No es viable para empresas: Sería difícil contar con apoyo de empresas si no se promete un gran beneficio económico.
Amenazas
  • Falta de apoyo: Al ser un proyecto pensado en el beneficio de los usuarios y no tanto económico, podría ser difícil obtener apoyo de tanto gobierno como empresas.
  • Incremento de cuotas de camiones: Desconozco del asunto, pero asumiendo que el gobierno apoyará el proyecto, sería viable que para sustentarlo se incrementen las cuotas de los camiones, afectando a los usuarios.
  • Conectividad: Las redes inalámbricas no son lo más confiable del mundo y podrían existir fallas en la conexión, y por lo tanto errores en la información de los módulos.
Mercadotecnia

Como he mencionado, la idea del proyecto es dar un servicio (preferentemente gratuito) a los usuarios del transporte urbano. Pero como esto sería poco viable con solo eso, se debe pensar en alguna estrategia de mercadotecnia.

Una gran posibilidad de mercadotecnia de este proyecto es pensando  en las tarjetas de pre-pago para camiones, que se utilizan para pagar el viaje en la rutas de camiones de algunos países. Estas tarjetas normalmente son proporcionadas por empresas a un cierto precio (que solo se debe hacer una vez, lo demás es solo recargar dinero para pagar los camiones con ella).

Si combinamos esta idea con el proyecto existiría una gran posibilidad  de simplemente incrementar el precio de la tarjeta ligeramente por el servicio proporcionado. Esto no sería muy grave para los usuarios quienes podrían aceptar el ligero incremento a favor de los beneficios otorgados.

Posible desarrollo futuro

Existen muchos tipos de mejoras que el proyecto podría tener (y estas incrementarían a como surgen nuevas tecnologías). El hecho de ser un proyecto hacia los ciudadanos ayuda bastante a obtener retroalimentación de ellos por lo que sería posible mejorar aún más conociendo sus críticas.

Pensando más a futuro, aunque no tan lejano, estaría también la posibilidad de aplicaciones móviles gratuitas (o con costo vaya, es lo de menos) que tengan acceso a la información de las rutas al igual que los módulos. Esto no es tan viable ahora mismo porque un mayor porcentaje de los usuarios de transporte urbano no cuenta con teléfonos inteligentes.

Otra idea no mencionada por ser diferente al enfoque del proyecto es un tipo de botón de pánico en el módulo mismo. Como se podría fácilmente conocer la posición GPS de un módulo como estos, la policía, ambulancia, etc podría saber llegar de forma más fácil al lugar (teóricamente).

Referencia:

miércoles, 15 de mayo de 2013

Laboratorio 10: Detección de Movimiento

Para la tarea, se nos pidió realizar una detección de movimiento en una serie de frames, utilizando métodos propios sin ayuda de librerías de visión en los procesamientos. Lo que realicé fue lo siguiente.

Las herramientas usadas fueron:
  • PIL: Para leer los frames, dibujar en ellos y guardar los resultados.
  • Numpy: Para realizar cálculos rápidos y eficientes a las matrices de las imágenes.
  • Pygame: Para mostrar en tiempo real la animación y la detección del movimiento del programa.
Generar animaciones. 

Utilizando principalmente PIL para su creación, generé aleatoriamente coordenadas dentro de un tamaño definido de una imagen, y programé rutinas sencillas para mover un rectángulo de una a otra siguiendo los ejes principales. Cada movimiento se almacena como un frame por separado en una carpeta ("output_frame_%d.png", donde %d es el número del frame en cuestión). 

Nota: Inicialmente, esto se convertía en un video, pero para eliminar la necesidad de utilizar OpenCV u otra librería para leer los frames del video, utilicé directamente las imágenes anteriores como frames para procesar. 

El resultado de ver las imágenes una tras otra es una sencilla animación de un cuadrado en movimiento por la pantalla:


Código usado:



Detección de Movimiento


Para detectar movimiento lo primero que hice fue obtener los cambios que ocurrían en cada dos frames, calculando la diferencia entre ellos posición por posición (valor absoluto) y binarizando los resultados. Normalmente en aplicaciones reales existiría ruido aún después de realizar esto, por lo que habría que hacer un blur/smooth para eliminarlo, pero en el caso de las animaciones sencillas usadas no hubo problema.

Lo siguiente es la parte importante. Con el procedimiento anterior, se obtiene una imagen totalmente negra donde no hubo cambios y blanca donde lo hubo. Originalmente lo que se hace aquí es buscar bordes, y obtener las bounding box de los mismos. Eso lo realicé en mi proyecto, por lo que esta vez quisé intentar algo diferente. 

Cree una especie de grid o rejilla cuadriculada en toda la imagen (de un tamaño definido, modificable).

Rejilla de 5 pixeles

Rejilla de 15 pixeles

Rejilla de 20 pixeles


Con esta rejilla, es posible dividir los pixeles de la imagen en cuadrantes más grandes. Utilizando la imagen binarizada (matriz de la imagen) se buscan aquellos cuadrantes que contienen algún pixel blanco en dicha imagen (por ahora con que uno solo toque basta, pero es modificable). 

Sí por lo menos un pixel blanco está dentro del cuadrante, el cuadrante se pinta de verde, indicando que algún objeto pasó por ahí. Naturalmente, cuando un objeto es de un cierto tamaño, puede estar contenido en más de un cuadrante.

Dirección de Movimiento


La dirección del movimiento es otra cosa posible de determinar. Conociendo dos posiciones (anterior y actual, o actual y siguiente) de un objeto es posible calcular el ángulo hacia donde se movió, y por lo tanto a partir de el la dirección de movimiento (izquierda, derecha, arriba, abajo). El programa se limita a esas 4, pero cambiando los rangos de los ángulos es posible agregar más direcciones, mientras sean en dos dimensiones (x o y,  dirección en z no está implementado).

El programa coloca una flecha (ascii art) apuntando hacia la dirección del movimiento en el centro del objeto e imprime en la terminal su dirección y angulo.


Ejemplo de funcionamiento:






Código:


martes, 14 de mayo de 2013

Sugerencias de Privacidad a Proyectos

Alarma Inteligente


La parte bluetooth del sistema es similar al nuestro, por lo que es entendible que no busquen enviar información importante por un canal como Bluetooth que no es del todo seguro y se conocen vulerabilidades. Hablan de la parte GPS, y de como dejar la privacidad de su uso al usuario, y esto puede ser lo correcto desde un punto de vista, pero no todos los usuarios conocen el funcionamiento del sistema, y es probable que de no conocer las consecuencias, dejen encendido el GPS todo el tiempo. Me parece que como el sistema GPS del proyecto está enfocado en seguridad en caso de robo, solo deberia ser activado en dicho caso (se supone que tiene una alarma el sistema para caso de robo, en ese momento podría encenderse el GPS).

Computadora Inteligente


Los datos del usuario que usan son su correo y fotos de su rostro, que se utilizan localmente por lo que no en verdad existe riesgo de privacidad si no se ocupa subir a ningún servidor la imagen.

Oficina Inteligente

Como el objetivo es la personalización de la oficina para cada persona individual, me parece que es un poco ineficiente o inadecuado mostrar todos los datos recopilados por el sistema a cualquier persona, ya que aunque datos como el nivel de iluminación y temperatura pueden ser no reveladores, la hora de llegada de las personas es un poco más personal, además de que en general no es necesario conocer los datos de personalización de los demás.

Alarma de Dispositivos Inteligente

Esta bien mencionar que los datos están seguros normalmente (por la encriptación y la forma de funcionar de Android)  y es correcto hacer mención de los límites en los que se puede hacer responsable la "compañía" de pérdida de información. Sin embargo en ningún momento dentro de el aviso de privacidad se menciona que tipo de datos utiliza el sistema lo cual es muy importante especificar.

Galería Inteligente

Según mi parecer, los verdaderos usuarios del sistema serían las personas que visitan el museo/galería, y el sistema no utiliza ningún tipo de información de ellos, masque su mera presencia o no frente a una obra, para reproducir los datos de la misma. No se especifica que tipo de datos requiere el Login para los administradores del sistema, pero como mencioné, en sí ellos no son los usuarios finales.

Casa Inteligente

No habían mencionado antes la forma de localizar la posición del usuario, y como sugerencia a ello me parece que no deberían de usar un sistema de coordenadas como proponen (GPS), a menos que se refiera a uno muy simple como coordenadas x para cuartos diferentes del mismo piso, variando y dependiendo del piso. Cada sensor indicaría el par de coordenadas que está.
En cuanto a privacidad me parece muy bueno que manejen niveles de seguridad con diferentes comportamientos, pero me parece innecesario que graben las coordenadas en las cuales estuvo el usuario, siendo información no útil.

Car NXP

Mencionan algo importante que su proyecto incorpora, adaptación a redes sociales. Frecuentemente personas comparten todo tipo de información en estas redes, y ellos manejan muy bien la opción de poder compartir o no la información de sus rutas y lugares visitados (en este caso en Facebook y Foursquare).
Además ponen en claro el hecho de que no se hacen responsables por lo que el usuario comparta en dichas redes y pueda afectarlos, cosa que es importante tomar en cuenta hoy en día.

Alarma Inteligente (Cama)

Tener un registro de las alarmas en línea, y depender de ello me parece poco fiable. No tanto por la situación en la que el servidor no este disponible (manejan copias locales), sino entra el detalle de la seguridad, que alguien con diferentes motivos (aquí probablemente bromas) cambie las alarmas de las personas, o en un peor caso utilice esa información para conocer cuando duerme la persona (muy poco común).

Por ello me parece que hicieron bien en considerar mecanismos de encriptación para la base de datos, manteniendo los datos lo suficientemente seguros para que cualquiera que por una broma desee hacerlo no se moleste en intentarlo.


lunes, 13 de mayo de 2013

Reporte de Proyecto: Detección de Movimiento

Link al Proyecto en Github: https://github.com/synnick/cvision-project/

Presentación:




Propósito 

El propósito del proyecto es la detección de objetos en movimiento en base a técnicas de visión computacional. Dichos objetos son grabados por una cámara, de la cual se extraen frames consecutivos para poder realizar las operaciones.

Justificación

La justificación del proyecto son sus aplicaciones.

La mayoría de ellas relacionadas con seguridad, ya que al poder detectar el movimiento de algun objeto sospechoso, una cámara de seguridad puede hacer acercamientos y tomar/almacenar fotografías, o en cambio puede utilizar dicho movimiento para cambiar su posición, y permitir cubrir un área mayor.

IPS Analytics (2012) IPS Motion Detection. [imagen en línea]
Disponible en: http://www.ips-analytics.com/uploads/media/ips_activity_detection_05.j
pg
También existen aplicaciones en el área de entretenimiento. Una forma más avanzada de simple detección de movimiento para esto, sería el poder seguir los movimientos de un objeto conocido, como las manos o piernas, para poder con ello realizar algún procesamiento en un videojuego como es el caso del dispositivo Kinect de Microsoft.



Kinect Hacks (2011) Kinect BVH Motion Capture. [imagen en líinea] 

Disponible en: http://cdn.kinecthacks.com/wp-content/uploads/2011/09/appscreen1.jpg.


Otra aplicación interesante en el área de cómputo ubicuo y automóviles inteligentes es un dispositivo que permite al automóvil conducirse por si mismo. Esto es posible gracias a una combinación de sensores y cámaras, y por lo menos una de ellas es usada para detectar el movimiento de peatones y objetos diversos para poder además predecir sus desplazamientos y tomar una decisión sobre que hacer (frenar, girar, acelerar, etc).



Vinoth Ragunathan (2011) A look inside Google's "Driverless Car". [video en línea] 

Disponible en: http://www.youtube.com/watch?v=J17Qgc4a8xY.


Descripción Textual


Básicamente, lo que el programa hace es detectar objetos en movimiento en una secuencia de imágenes (video). De estos objetos conoceríamos su posición actual, y anterior (o actual y siguiente, no realmente importa) y en base a ellos, obtener la dirección de movimiento. A continuación se presenta un diagrama para explicar de forma más sencilla el funcionamiento del programa:


Se obtienen dos frames (imágenes) de un video. Estos se usarán para tanto la detección de áreas de movimiento como para el tracking de todo lo que se movió de uno a otro. Primero para la detección de movimiento se hace un pre-procesamiento para eliminar ruido (más información en la siguiente sección). Después se obtiene una diferencia entre esos frames para encontrar los objetos que se movieron, obtenemos sus contornos y a partir de ellos sacamos el área del objeto (zonas de movimiento).

Además con los dos frames se hará el tracking, buscando en el primero características importantes de la imagen (esquinas) y buscando esas mismas características en el segundo frame. De esta forma podemos saber la posición actual y anterior del objeto, y podemos trazar flechas y obtener la dirección de movimiento. Utilizando las zonas de movimiento localizadas anteriormente eliminamos aquellas posiciones obtenidas que no se encuentran dentro de alguna zona de movimiento.

Diseño del Software

El diseño del software es como sigue. El proceso está separado en dos partes principales que es la detección de movimiento y el tracking o rastreo del mismo. Lo demás es procesamiento y tratamiento de los frames para obtener solo lo necesario, que se mencionará dentro de las partes principales. Para cuestiones de ejemplo, se usarán las siguientes dos imágenes (el mismo principio aplica para video):

 
  • Detección de Movimiento

    La parte fundamental del proyecto consiste en detectar movimiento, que en sí cuando pensamos en imágenes es el cambio en los pixeles. Por ejemplo, cuando se tiene una imagen con un fondo constante obtenida de una cámara, y en el siguiente frame se agrega un elemento externo como una manzana sobre ese fondo, nosotros sabemos que hubo un cambio, y la forma de obtener este es substraer la imagen del fondo de la imagen que contiene el objeto. Esto nos dara una mancha de pixeles en las posiciones donde hubo cambio, que naturalmente serán las que cubren al objeto externo que fue introducido en el fondo.

    Esta es la forma más básica, pero cuando pensamos en hacer esto en más de dos frames (es decir un video) las cosas se comienzan a complicar. Para obtener el movimiento en los frames consecutivos de un video es posible realizar lo anterior, PERO existe una gran cantidad de ruido en las cámaras, lo cual causaría que al sustraer la imagen de fondo menos la más actual, haga creer que hubo pequeños movimientos en todos lados de la imagen.

    Afortunadamente ruido de este tipo es gaussiano, lo que hace posible que sea eliminado mediante  un smooth o blur simple. Y para mejorar esto, se hace dicho smoothing no a la imagen de fondo, sino a un promedio obtenido de multiples frames consecutivos para obtener mejores resultados. De esta forma el ruido es mínimo, y podemos trabajar con las manchas mayores que corresponden a los movimientos reales.

    Resultado de la Diferencia

    El siguiente paso es convertir el problema en un problema de decisión: para cada pixel determinar si hubo movimiento o no. Para conseguir esto, teniendo a la imagen anterior primero se le aplica un filtrado a escala de grises, para poder binarizaar más fácilmente

    Resultado de filtro de escala de grises

    Después se aplica un umbral de binarizado para convertir los pixeles de un tono de grises a blancos y todo lo demás a negro, basados en un umbral. Así ahora tendremos manchas totalmente blancas donde hubo movimiento.

    Resultado de la binarización

    Aunque en la imagen anterior no es el caso, regularmente puede haber ruido aun en la imagen binarizada, por lo que se aplica de nuevo un filtro smooth y otro binarizado para eliminar tal ruido.


    Izquierda, aplicacion de smooth, derecha segundo binarizado. Se puede notar que desaparece el pequeño ruido en la esquina inferior derecha.

    Las manchas de los movimientos normalmente no son polígonos ni ninguna figura en específico, sino simple manchas. Para obtener una forma un poco más definida, se obtienen los contornos de TODAS las manchas detectadas anteriormente.

    Contorno de la mancha de movimiento

    Estos contornos corresponden simplemente a sus bordes, y ayudarán a definir un bounding box para cada mancha.

    Esto causa un nuevo problema: un mismo movimiento puede causar pequeñas manchas consecutivas cercanas en vez de una gran mancha definida. Para esto mismo se utilizan las bounding box anteriores. Buscando colisiones en ellas (cuando se sobreponen unas a otras) podemos suponer que fueron causadas por un mismo movimiento, para lo cual se juntan todas las bounding box que tienen colisiones y se hace una combinada, disminuyendo la cantidad de movimientos.

    Imagen final con movimiento localizado

    De esta forma ya podemos detectar todos los movimientos que ocurren en la pantalla, pero no hacia donde se hicieron (dirección orientación). Para ello se utilizan técnicas de rastreo.
  • Rastreo de Movimiento

    Con rastreo de movimiento, me refiero a seguir un objeto que en el paso anterior se detecto en movimiento. Esta técnica requiere mucho menos procesamiento de imágenes, pero debido al algoritmo usado requiere que exista suficiente iluminación en los videos.

    Con un par de frames del video, buscamos en el primero características importantes con la función GoodFeaturesToTrack, y después se buscan estas mismas características en el segundo frame utilizando el algoritmo Lucas Kanade[1], obteniendo las nuevas posiciones y por lo tanto el flujo óptico del movimiento.

    En base a la posición previa y la obtenida con el algoritmo, es posible calcular la dirección del movimiento y de esta forma colocar algún indicador como una flecha hacia donde se está moviendo el objeto.

    He aquí algunas capturas donde se detecta el movimiento de automóviles y motocicletas:



    Nota: Los cuadros blancos, el tag con el tipo de vehículo, y el bounding box blanco no forman parte de mi algoritmo, ya se encontraban en el video que usé (referencias más abajo).

    Como se puede observar, las flechas apuntan en la dirección del movimiento del vehículo, además de que con el método anterior de detección de movimiento se detecta el automóvil.
Librerías

La librería utilizada para el proyecto fue OpenCV para Python por su alta versatilidad y optimización para la manipulación de imágenes y videos. Contiene una gran cantidad de funciones para aplicar diferentes filtros sencillos y algoritmos complejos a las imágenes es como es el caso de:
  • Smooth: Función normalmente ue a diferencia de la primera trabaja con arreglos de numpy).usada para reducir el ruido en las imágenes. Existen diferentes tipos de smoothing con diferentes efectos, pero en este proyecto se usa el Gaussiano.
  • Running Average: Función usada para obtener un promedio de un número determinado de frames, también ayuda a reducir ruido causado por las cámaras.
  • CvtColor: Para pasar una imagen RGB a escala de grises, nada más.
  • Threshold: Función para obtener una imagen binarizada a partir de un umbral.
  • FindContours: Función usada para encontrar los contornos de una imagen binarizada.
  • GoodFeaturesToTrack: Función usada para encontrar características importantes de una imagen(esquinas) para después buscarlas en otra.
  • CalcOpticalFlowPyrLK: Función usada para calcular la nueva posición de características determinadas en una imagen utilizando el algoritmo Lucas Kanade para el flujo óptico.
Se realizó utilizando su primera versión cv (existe la versión cv2 que contiene sintaxis diferente en sus funciones, y trabaja con arreglos numpy).

Evaluación de Desempeño


Todo tipo de aplicación para algún sistema que trabaja con técnicas de visión computacional suele depender de una cosa: tiempo. Un programa de visión computacional que funciona de manera excelente puede ser inservible si en cuestiones de tiempo toma una eternidad en funcionar, en cambio un programa que se desempeña de forma correcta con pocos errores, pero es rápido puede ser una mucho mejor opción.

En el caso del proyecto, se realizaron pruebas, calculando el tiempo aproximado que se tarda el programa en realizar los cálculos de detección de movimiento en diferentes videos con diferentes resoluciones.

Las pruebas se realizaron en una notebook con las siguientes especificaciones:

Procesador: AMD Dual-Core Processor C-50 @ 1.0 Ghz
RAM: 1 GB DDR3
Tarjeta de Video: AMD Radeon HD 6250

El video usado fue:





(2012) Vehicle classification through multiple neural networks. [video en línea] 

Disponible en: http://www.youtube.com/watch?v=IsNLzhu_BKM 
[Fecha de acceso: 13 de Mayo de 2013].

Prueba de Grabado:

Una forma posible de mejorar el desempeño puede ser no mostrar el programa corriendo en vivo, es decir solo realizar los cálculos con los frames y guardar los resultados en un video de salida, sin mostrar las imágenes una por una. Los resultados fueron:

Sin mostrar resultados:
Promedio: 0.148833380858

Mostrando resultados:
Promedio: 0.151357673303


Los desempeños son similares, pero naturalmente el desempeño es mejor cuando no se muestra nada de los procesamientos en tiempo real.

Prueba de Threads

Debido a que los dos bloques principales del programa (Detección de Movimiento, Rastreo de Movimiento) son independientes uno de otro, es decir los calculos de uno no dependen directamente de los cálculos del otro (el orden si importa, debe calcularse la detección de áreas primero) me pareció posible crear un thread para alguno de los dos procedimientos para correr simultaneamente mientras se procesan otros datos.

En este caso, la detección de movimiento corre en una función de forma simultánea al flujo principal del programa. He aquí una comparativa en los tiempos de ejecucion total en cada frame procesado del video.


Promedio: 0.126680270547


Promedio: 0.138897460478


En conclusión, el uso de threads no mejoró el desempeño del programa, emporandolo ligeramente.

Trabajo a Futuro

Ahora mismo, no tengo intención de continuar con el proyecto en ninguna forma, a no ser que en el futuro surja la necesidad de hacerlo. Pensando en esa posibilidad, las futuras mejoras e ideas de que se puede hacer con este proyecto incluyen lo siguiente.
  • Adaptación a cv2. Debido a que cv2 de Python esta mucho menos documentado que cv, decidí realizar el proyecto en éste último. Pero aparentemente, en múltiples comparaciones hechas entre ambos, cv2 es mucho más eficiente que cv, principalmente debido a que trabaja con arreglos de numpy.

    Por lo tanto una posible adaptación a cv2 (probablemente no muy difícil con documentación apropiada)  podría ayudar a mejorar el rendimiento y sería una gran mejora al proyecto.
  • Adaptación con hardware. Me parece posible utilizar este proyecto en conjunto con proyectos que trabajen con cámaras para poder realizar algún procesamiento con el video que graban. Personalmente no me interesa esto por mi poca experiencia en electrónica, pero es una buena área para cualquiera interesado.
  • Aplicaciones de seguridad. Como mencioné al inicio del post, este tipo de proyectos tiene aplicaciones de seguridad. Combinado con una cámara con buena resolución bien colocada, y algún tipo de detección de rostros, debería ser posible hacer zoom al área donde se detecta movimiento y detectar rostros, en caso de que se desea tener una alta seguridad en un área determinada.
  • Aplicaciones científicas: Una aplicación interesante que encontré de este tipo de proyectos de detección de movimientos es el monitoreo de animales. En un experimento, se inyectaban roedores con neurotoxinas, y con una cámara se grababa y almacenaban todos los movimientos que realizaban dentro de su jaula, para buscar patrones o algo en concreto. Otra persona hizo algo similar, pero para monitorear roedores en diferentes iluminaciones. Este tipo de aplicaciones científicas pueden ser un buen acercamiento al uso del proyecto.
Referencias:

viernes, 10 de mayo de 2013

Tarea 6: Geolocalización

Para esta semana se pidió utilizar el algoritmo de geolocalización por triangulación para encontrar la localización de un punto receptor entre tres transmisores.

Esto lo realicé mediante una simulación gráfica, en Python. En la simulación, los receptores suponen ser 3 antenas fijas con posición conocida, y del receptor solo se conoce la señal que obtiene de dichos transmisores, que está medida en función de su distancia a los transmisores. 

Pero para simular el desplazamiento de la señal, esta distancia no se calcula directamente con la fórmula para distancias entre dos puntos, sino que se expande el área del círculo hasta detectar un receptor, es decir cuando la circunferencia toque el punto.

La arquitectura de la simulación se ve así:



En este caso, todas las posiciones se miden en referencia a pixeles de la ventana, por lo cual los transmisores están localizados como sigue:
  •     Rojo: 263, 485
  •     Verde = 708, 393
  •     Azul = 512, 81
En base a estas coordenadas, al dar click en una parte de la pantalla, se busca calcular la posición en la cual se dio click, utilizando el algoritmo básico de trilateración.

Éste algoritmo calcula tres coordenadas $x, y, z$ de un punto que es la intersección entre tres círculos, que en este caso son las señales de los transmisores. Cabe destacar que dependiendo de la posición donde se de click, y dependiendo de las señales máximas de las antenas, es posible que un punto no pueda ser calculado de forma exacta, porque solo dos transmisores están al alcance.

Si solo un transmisor esta a alcance, la posición no se puede calcular correctamente.

Aquí algunos ejemplos:


Al alcance de tres transmisores:



En este caso el receptor se encuentra cerca de la mitad de la ventana, por lo que está en buen alcance con los tres transmisores. Calculando con 3 transmisores los resultados son exactos, proporcionando las mismas coordenadas donde se coloco el receptor.

Al alcance de dos transmisores:



Como se puede observar, el receptor (con el icono del smartphone) esta fuera de alcance del transmisor número 2 (verde). Por lo tanto solo se puede calcular su posición usando el transmisor 1 y 3, lo cual es hecho con un ligero error. La captura de la terminal muestra que el verdadero punto fue 198, 180, mientras que el detectado usando dos transmisores fue: 191.99999619, 216.99999619.

Al alcance de uno o ningún transmisor



Al alcance de un receptor como se puede observar aquí, estando el receptor localizado al pie de un transmisor y por lo tanto fuera del alcance de los otros dos, es imposible calcular el punto, por lo cual el programa imprime que no existe una solución para determinar la posición de ese receptor.




En este caso el receptor está en una esquina, opuesta a los otros 3 transmisores, por lo que no existen suficientes datos para poder calcular su posición.

Ejemplo de animación:


Código:

Referencias: