martes, 30 de abril de 2013

Tarea 9 - (LAB)Redes - Energia eficiente en las redes inalambricas de sensores


An Energy Efficient Hierarchical Clustering 
Algorithm for Wireless Sensor Networks


--------------
Autores: Seema Bandyopadhyay and Edward J. Coyle
School of Electrical and Computer Engineering
Purdue University

-------------


Introducción

Los recientes avances en las comunicaciones inalámbricas y sistemas microelectromecánicos tienen la motivación el desarrollo de sensores muy pequeños y de bajo costo que poseen detección, procesamiento de señales y de comunicación inalámbrica capacidades. 
Estos sensores se pueden implementar a un costo mucho más bajo que los sistemas de sensores cableados tradicionales.

Organizar los sensores tales que abarquen el mejor rango posible, es un ahorro de energia siginificativo.
Muchos algoritmos de agrupamiento en diversos contextos han sido propuesto. Estos algoritmos son en su mayoría de naturalueza heurística y el objetivo de generar el número mínimo de agrupaciones de tal manera que cualquier nodo en cualquier grupo es como máximo de saltos de distancia desde el Clusterhead. 

La mayoría de estos algoritmos tienen un tiempo complejidad de O(n), donde n es el número total de nodos. 
Muchos de ellos también exigen sincronización de tiempo entre los nodos, lo que hace que sean adecuadas sólo para redes con un pequeño número de sensores. 

Para las redes de sensores inalámbricas con un gran número de sensores de energía limitada, es muy importante diseñar un algoritmo rápido para organizar en grupos de sensores para reducir al mínimo la la energía utilizada para comunicar información desde todos los nodos al centro de procesamiento. 

Algoritmo

Cada sensor en la red se convierte en una Clusterhead (CH) con probabilidad p y anuncia como un Clusterhead a los sensores dentro de su radio de alcance. Llamamos a estos clusterheads los clusterheads voluntarios. Este anuncio se reenvía a todos los sensores que no son más que k saltos de distancia del Clusterhead. Cualquier sensor que recibe este tipo de etiqueta y no forma parte de un  Clusterhead se une al clúster del Clusterhead más cercano. Cualquier sensor que no es ni un Clusterhead y no tiene unido a ningún grupo en sí se convierte en un Clusterhead, llamamos a estos clusterheads los clusterheads forzadas .

La energía utilizada en la red para obtener la información recogida por los sensores para llegar al centro de procesamiento se dependerá de los parámetros p y k de nuestro algoritmo. Puesto que el objetivo de nuestro trabajo es organizar los sensores en grupos para minimizar el consumo de energía, tenemos que encontrar los valores de los parámetros p y k de nuestro algoritmo para que garantice minimización del consumo de energía.

Los parámetros óptimos para el algoritmo

Para determinar los parámetros óptimos para el algoritmo descrito anteriormente, hacemos los siguientes supuestos:
a) Los sensores de la red de sensores inalámbricos son distribuido como por una homogénea espacial de Poisson proceso de intensidad λ en el espacio de 2 dimensiones.
b) Todos los sensores transmiten al mismo nivel de potencia y por lo tanto tienen el mismo alcance de radio r.
c) Los datos intercambiados entre dos sensores se comunican no dentro del alcance de radio de los demás se remite por otros sensores
d) Una distancia de d entre cualquier sensor y su Clusterhead es equivalente a [d/r]
e) Cada sensor utiliza 1 unidad de energía para transmitir o recibir 1 unidad de datos.
f) Una infraestructura de enrutamiento esta en su lugar, por lo que, cuando un sensor se comunica datos a los otros sensores, sólo el sensor en la direccionde ruteo puede recibir la información.
g) El medio de comunicación es la conexión y libre de errores, por lo que los sensores no tienen que retransmitir cualquier datos.


La idea básica de la derivación de los valores de los parámetros óptimos es definir una función de la energía utilizada en la red para comunicar la información al centro de procesamiento de información y a continuación, encontrar los valores de los parámetros que se reduzcan al mínimo.

Cálculo de la probabilidad óptima de convertirse en un Clusterhead


De acuerdo con nuestras suposiciones, los sensores se distribuyen según un proceso de Poisson espacial homogénea y, por tanto, el número de sensores en una zona cuadrada de lado 2 es una variable aleatoria de Poisson.

Concluciones

La forma en que estén acomodados los sensores y los receptores es una buena forma de quitar sensores innecesarios, y quitando esos sensores extras nos ahorrariamos energía. 
El algoritmo que ellos nos muestran es heurístico y se actualiza con los nodos(sensores) que tengamos, me recuerda a una tarea de unos compañeros en donde tenia que acomodar los "modems" para que abarcara todo el rango posible con el menor números de aparatos basándose en el rango que cubría cada uno.

Los senosres inalambricos es mucho mas eficaz y en algunos casos mas baratos que tener sensores conectados directamente.

Referencias
Autores:
Seema Bandyopadhyay and Edward J. Coyle.


Tarea #5 - Clase - Control de Trafico: Congestión

Para esta entrada tenemos que controlar en trafico en una red.

Cuando la banda ancha se satura una de las soluciones es aumentarla o disminuir los paquetes y los tiempos que se envían, (como hace youtube al momento de cargar videos demasiados pesados).

Primero calculamas la banda ancha con la sig. formula:

Formula tomada del tutorial
Con la banda ancha calculada, hice un FOR que se encarga de estar incrementandola cada cierto tiempo y un IF que en caso de que la sobrepase, la disminuya:




Tambien existe el caso en que si la BA esta "bien" osea, no esta enviando tanto pequetes y los que envia si lo puede sorportar, encontes podemos incrementarla hasta llegar al limite.


Codigo de la función



Referencias
http://www.isi.edu/nsnam/ns/tutorial/

lunes, 29 de abril de 2013

Ubicuo #8(LAB) - Critica constructiva

Se nos dio a la tarea de hacer pequeñas criticas a los demás proyectos de nuestro compañeros, esta semana el tema es la usabilidad.

Alarma inteligente

Liga a la entrada: http://ubicomputo.blogspot.mx/2013/04/evaluaciones-de-usabilidad.html

Mencionan que se dio una platica acerca del funcionamiento del sistema, cuales serian los pasos para activarla. Hubiera estado excelente que les comentaran en donde ellos se sentirían cómodos con la posición del vehículo, que fuera como un pedal mas(a lado del clutch)  para que no se den cuenta cuando se activa o desactiva.

Una parte importante y siento yo que es algo a lo que se le deba dedicar tiempo, es al programa que mencionan de control por internet; los productos se venden por sus pantallas no tanto por su funcionamiento, y tener un buen diseño de esta podría traer resultados excelentes.

Computara inteligente

Liga a la entrada: http://aveoctavo.blogspot.mx/2013/04/blog-post.html

Un bloqueo por rostro es interesante para cualquier persona, pero obviamente este tiene que ser muy, pero muy amigable con el sistema.

Una comparación sobre el funcionamiento de sistema, es windows voice recognition, donde lo único que haces directamente es activarlo y desactivarlo, todo lo demás trabaja en un background, eso si, te esta retroalimentando a cada segundo.

Y cada vez que estos sistemas se conviertan en algo popular, ya no tendrá que ver tutoriales. Estos vendrán por default con las computadoras y hasta reconocerán en animo en el que te encuentras y pondrán canciones "especiales" con las pulsaciones de la teclas, sera asombroso cuando lleguemos a esos tiempos.

En esta parte ahí que tener mucho cuidado ya que tendrán demasiado ruido cuando estén... por ejemplo a las 11 de la noche y la luz no sea un factor a favor, también el que pueda detectar diferentes posiciones porque seria molesto siempre estar en la misma posición durante se usa la PC.

Recordatorio inteligente

Liga a la entrada: http://gtdsoftwa.blogspot.mx/2013/04/presentacion-usabilidad-computo-ubicuo.html

Este proyecto tiene todas las medidas tomadas, no hay mucho que decir. El unico conveniente que tendrán es instarle el bluetooth a cada dispositivo que quieren encontrar, eso si sera un problema.

Galeria inteligente 

Liga a la entrada: http://ultimo-sem.blogspot.mx/2013/04/entrega-4.html

La parte de auto-exploramiento me gusto mucho, ahi es donde te das cuenta que estas haciendo bien o mal, y te da una excelente retroalimentación.

Para la parte de usabilidad estaria bien si tuviera algo para controlar a la multitud, seria molesto que cada vez que se detecte empiece hacer la reproducción.

En este proyecto la usabilidad principal, por asi decirlo, sera la forma en que muestren el audio cuando detecten a alguien "nuevo", porque tendria demasiado pero demasiado ruido, si unicamente se limitan a detectar personas.

Despertador inteligente

Liga a la entrada: http://3-its.blogspot.mx/2013/04/pruebas-de-usabilidad.html

Sin duda este en un proyecto complicado por el hecho que tiene que validar muchos eventos. Pero se han tomado en cuenta muchos aspectos. Que limitan la critica a esta entrada.

De lo que les puedo comentar es intentar hacer pruebas del "stop de alarma" cuando realmente la alarma deja de sonar, eso es algo en lo que se debe enfocar porque el usuario siempre buscara la forma de que el sistema no funcione y se salga con la suya.

Estaria con ganas que el sistema reconociera tuviera una opción que diga "Si llegas tarde te perderas la explicación de Elisa" así ya le pegarias a la "conciencia" del usuario y se despertaria "totalemente".

Casa inteligente: Seguridad

Liga a la entrada: http://3puntosteam.blogspot.mx/2013/04/pruebas-de-usabilidad.html

La pruebas están bien hechas y bien fundamentadas, pero estaria mucho mejor si todas la acciones que mencionan se hagan sin botones, ya que eso es el corazón de la aplicación y de la materia. El control de luces y unicamente debe ser utilizado para ver el sistema. Porque si depende totalmente de ellos no es un sistema inteligente.

Para las pruebas de estos tipos de sistemas, lo que se hace es checar los sensores que esten funcionando según su proposito, como en los proyectos anteriores asegurarse de que se elimine todo el ruido posible.








jueves, 25 de abril de 2013

Tarea#7 Vision(LAB) - Histogramas de una imagen - Python

Que tal para esta entrada se nos encargado detectar los histogramas de una imagen tomada por nosotros esto para poder detectar posibles agujeros en la misma.

Procedimiento

1 .- Se recorre toda la imagen y se suman sus filas como sus columnas y esta sumatoria de guarda para después calcular los mínimos.



2.- Con las sumatorias ya hechas procedemos a calcular los mínimos locales. Aquí hacemos uso de un umbral que es el promedio de los pixeles vecinos este umbral lo puedes calcular a prueba y error pero para imagenes donde no existe mucha claridad en la imagen se recomiendo usar uno entre 30-60 esto para eliminar los cruces donde no se encuentre nada.
Y siempre comparando que la sumatoria actual sea menor a la anterior y menor a la que sigue. Si cumplen con estas condiciones se marca como mínimo local.



Mínimos locales de la imagen,



Se hace lo mismo para calcular columnas como filas.

4.- Guardamos las lineas y columnas; buscamos en donde se cruzan y guardamos el pixel en donde cruzan.




5.- Ya cuando tenemos los pixeles en donde cruzan basta con hacer un BFS sobre cada pixel, buscando posibles agujeros. En esta parte apliquen filtros para mejorar la imagen y tendrán una detección de imagen demasiado sencilla.


Código

Les incluyo el código completo para esta tarea.





Referencias

http://elisa.dyndns-web.com/~elisa/teaching/comp/vision/agujeros.pdf
http://4imedio.blogspot.mx/2013/04/tarea-7-deteccion-de-agujeros.html#comments

Tarea #4 - Codigo Adaptativo

Para esta semana se nos encargo un método de compresión que se adaptara según la entrada.

La idea es que el programa lea una cadena en paquetes y cuando el paquete llegue a cierto limite el python sea capaz de comprimirlo y enviarlo. La variante es que se tiene que estar adaptando según el paquete de entrada.

La idea que yo tengo/tenia era tomar la frecuencia de las letras del alfabeto español y con el primer paquete que le llegue al python hacer lo siguiente:

1.- Identificábamos las letras únicas del paquete y las ordenábamos por frecuencias de apariciones.
2.- Sustituíamos o creábamos otra lista(conservando el orden) pero ahora con el agregábamos el  valor de la probabilidad del que la letra apareciera en el alfabeto español.
3.- Escogíamos un umbral que fuera el promedio de la suma de frecuencias del alfabeto
4.- Por cada paquete se aseguraba que la letra no estuviera ya anteriormente en el grafo, esto para eliminar el ruido de que haya repetidos.
5.- El nodo "padre" tenia un nombre único que fuera incapaz de confundirse y agregábamos los nodos con la siguiente regla.... "Si el valor el MAYOR al valor del nodo actual se agrega en la DERECHA; si es MENOR en la IZQUIERDA.
6.- Esto produciría un árbol que crece según la entrada y se acomoda según la frecuencia de las letras que aparecen en el pedazo de mensaje.
7 .- Con el árbol ya creado, lo único que faltaría seria recorrerlo para obtener el código para comprimir y lo mismo pero al revés para descomprimirlo.

Pero al intentar codificar esto tuve varios errores con lógica porque mis neuronas necesitan recargarse, pero bueno, se hizo un intento y se logro un avance parcial.
Estas son los fragmentos parciales mas importantes del programa.





martes, 23 de abril de 2013

Tarea 8 - (LAB)Redes - Mecanismos de control de congestión de TCP


Fairness and Stability of  Congestion Control Mechanisms of TCP
(La equidad y la estabilidad de los mecanismos de control de congestión de TCP)

-----------

Autores: Hasegawa, Masayuki Murata, and Hideo Miyahara
Department of Infomatics and Mathematical Science Graduate School of Engineering Science

-----------


En el pdf nos habla de tres versiones de TCP: Tahoe, Reno y Vegas. De las cuales las 2 primeras son ampliamente utilizadas en internet.

En TCP, el tamaño de la ventana para la conexión, llamada tamaño de ventana de congestión (cwnd), se cambia de acuerdo con la indicación de congestión de la red. El cambio del tamaño de la ventana tiene un impacto significativo sobre el comportamiento de TCP. Para ello, lo primero que resumimos son los algoritmos para actualizar cwnd (t) en las tres versiones de TCP.

Version TCP Tahoe


En TCP Tahoe, el tamaño de la ventana de cwnd se cambia cíclicamente. Cwnd continúa aumentando hasta que se produzca la pérdida del segmento. Cuando esto ocurre, TCP determina que la red está congestionada, y los aceleradores cwnd bajan el tamaño de un segmento. TCP Tahoe tiene dos fases en el aumento de cwnd fase de inicio lento y fase de evitar la congestión.




Es decir, TCP Tahoe entra de nuevo en fase de inicio lento cuando se produce la pérdida de segmento. Por lo tanto, la dinámica de la TCP Tahoe en un caso más simple es, Slow Fase Start + Congestión evitación Fase + pérdida del segmento + lenta fase de inicio  = ...

Version TCP Reno

TCP Reno es similar a TCP Tahoe, pero utiliza otro algoritmo cuando se produce pérdida del segmento. En fase de inicio lento y Congestion Avoidance Phase, Reno TCP siempre usa la ecuación de abajo para actualizar el tamaño de la ventana, pero cuando la pérdida de segmento se detecta por el algoritmo de retransmisión rápida, el tamaño de la ventana de cwnd (t) se reduce a la mitad. Es decir,


TCP Reno entra entonces en la fase de recuperación rápida.
En esta fase, el tamaño de la ventana se incrementa en un segmento cuando se recibe un segmento ACK duplicado, y cwnd (t) se restaura a SSTH cuando el segmento ACK no duplicados corres-pondiente al segmento retransmitido se recibida. 

Version TCP vegas

En TCP Tahoe y Reno, el tamaño de la ventana, cwnd se incrementa hasta pérdida del segmento se produce debido a la congestión. Entonces, el tamaño de la ventana es estrangulado, lo que conduce a la degradación de rendimiento de la conexión. Sin embargo, no se puede evitar debido a una naturaleza esencial del mecanismo de control de congestión de TCP adoptado en Tahoe y Reno. 

Es capaz de detectar información de congestión de red sólo por la pérdida del segmento. Sin embargo, se convierte en un problema, ya que el segmento se puede perder cuando la conexión TCP en sí hace que la congestión debido a su tamaño demasiado grande ventana. Si cwnd es apropiadamente controlado de tal manera que la pérdida del segmento no se produce en la red, la degradación del rendimiento debido a la ventana estrangulado se puede evitar. Esta es la razón por la que TCP Vegas se introdujo.

TCP Vegas emplea otro mecanismo para la detección de la congestión de la red. Se controla cwnd observando los cambios de RTT (Round Trip Time) de los segmentos que la conexión ha enviado antes. Si los RTT observados se hacen grandes, TCP Vegas reconoce que la red empieza a ser congestionada y bajo los aceleradores cwnd.

Si RTT se vuelven pequeñas, TCP Vegas determina que la red se alivia de la congestión, y aumenta cwnd.

Análisis

Version TCP Tahoe

En TCP Tahoe, el cambio del tamaño de la ventana es cíclica.



Cuando la única conexión utiliza el enlace. También es cierto cuando dos conexiones con retardos de propagación idénticos comparten el enlace desde segmentos de dos conexiones se pierde al final del ciclo. Se trata de explicarse de la siguiente manera. 
Supongamos dos remitentes, ambos TCP abren la ventana a la misma velocidad en la fase de evitar la congestión. Cada incrementos de conexión de su tamaño de la ventana por un segmento de forma simultánea, e inyecta un nuevo segmento en la red. Por último, la suma de los tamaños de las ventanas de ambas conexiones es igual a W, la suma de los productos de ancho de banda de retardo del enlace (W) y el tamaño del búfer en el interruptor (B).
Entonces nuevos segmentos de ambas conexiones son probabilidades de ser desechadas en el inicio de interruptor porque la suma de los tamaños de ventana excede la capacidad de la red por dos segmentos. Es cierto que tratamos un caso especial para la configuración de la red, pero el problema descrito en lo anterior es inherente en TCP Tahoe.


Version TCP Reno


Como se describe anteriormente, el mecanismo de control de gestión es similar al de TCP Tahoe, excepto que TCP Reno tiene una fase de recuperación que es capaz de reaccionar a la perdida de segmentos rápidamente. 

Es decir, en la fase de recuperación rápida, el tamaño de la ventana se infla temporalmente hasta que se recibe ACK no duplicados, y se restaura a SSTH. Después de eso, la fase de evitar la congestión comienza como en TCP Tahoe. Por lo tanto, si ignoramos la inflación temporal del tamaño de la ventana en rápida fase de recuperación, Reno TCP controla el tamaño de la ventana como si la fase inicial se eliminara a partir del cambio del tamaño de la ventana de TCP Tahoe.

Version TCP Vegas

Hay otra razón por la TCP Vegas no puede lograr la equidad entre las conexiones. Esto es causado por la diferencia de basertt de de dos conexiones, incluso en el caso homogéneo con retardos de propagación idénticos.

Por otro lado, el tamaño de la ventana en el caso heterogéneo se convierte en casi proporcional al retardo de propagación de cada conexión. Por lo tanto, el rendimiento se define como (tamaño de la ventana) / (propagación retardo) pasa a ser igual, y podemos decir que la justicia ser mejor cuando en el caso heterogéneo. Sin embargo, el rendimiento obtuvieron tiene algún rango depende de los parámetros elegidos y Q, Ll en TCP Vegas, lo que provoca la falta de equidad entre las conexiones.

Referencias
Autores: Hasegawa, Masayuki Murata, and Hideo Miyahara
Universidad: Osaka University, Japan
PDF 





Tarea #7 - Deteccion de Agujeros

Para esta entrada se nos encargo hacer un python que detectara agujeros en una imagen.

Para esto lo primero que hacemos es sacar por medio de histogramas los mínimos locales cuando hay un cambio de color muy drástico.

Lo primero que se hizo fue sumar todas la filas y columnas y guardarlas para después graficarlas y guardarlas, ya teniendo las sumatorias(en "x" y en "y").




Con las listas de las sumatorias, lo siguiente que se hizo fue una rutina que sacara los locales mínimos de cada lista, para esto nos basamos en comparar contra el elemento anterior y elemento siguiente mas aparte si pasaba la condición de un umbral lo agregamos como mínimo local, esto para descartar posibles ruidos en la imagen.




Una vez que ya tenemos las lineas en donde ocurre un mínimo local tenemos que checar en donde se cruzaba y tomar esos pixeles como posibles centros a nuestros agujeros.
Se agrego una condición que solamente agarrara los mínimos locales mas chicos, obviamente este filtro funcionaria a la perfección en imagenes "perfectas" o "semi-perfectas"(sin ruido), porque si no se tomarían otros pixeles en donde el gris predominara y no necesariamente serian agujeros.




Cruces de mínimos locales
Se pueden apreciar puntos rojos en el centro de la agujero y la parte derecha de la imagen


Ya teniendo los pixeles donde se cruzaba, basta con algo de trigonometría para descartar áreas que fueran ruido.

Una vez pasado estos filtros lo unico que queda es pintar en la imagen original el posible agujero en la imagen con un color distinto y una etiqueta.



El código completo esta aquí, marcado como "agujeros"

Resultados

Imagen #1
Imagen original

Imagen resultante


Histograma de la imagen

porcentaje


Imagen #2

Imagen Original
Imagen Resultante

histograma

porcentajes


Recomendaciones

.- Trabajar con imagenes en escala a grises y buscar que no haya mucho contraste.
.- Meter todos los filtros posibles y rápidos(que no afecten el coste computacional) para que los único mínimos locales que encuentre sean los de los agujeros.
.- Descartar el fondo o el color mas abundante en la imagen



jueves, 18 de abril de 2013

Tarea #6 - Visión(LAB) - Rellenar elipses

Para este entrada se nos encargó detectar elipses y dibujar un elipse nuevo y sacar el porcentaje que ocupa este nueva elipse comparada con la original.

Sacamos primero los pixeles tipo borde y una vez teniéndolos, tomamos al azar 2 pixeles sacamos sus gradiente, después calculamos la pendiente de cada pixel y una vez teniendo esos datos calcular la pendiente es fácil porque simplemente despejas de la formula de la recta-tangente.
Se procede al metodo de votación para sacar el centro, y a partir de ahi dibujar la elipse con las coordenas obtenidas.


Código



Resultados

Imagen Original


Imagen Obtenida

El punto amarillo es el posible centro de la elipse, aun tiene problemas con la votación pero es algo que se puede arreglar porque la forma que hace la lineas es muy "sencilla".

Para obtener el area sola basta hacer BFS empezando del punto central del elipse, sumar pixeles y sacar promedio, pero esa parte no alcance a sacarla

Referencias
http://elisa.dyndns-web.com/~elisa/teaching/comp/vision/elipses.pdf

martes, 16 de abril de 2013

Tarea 7 - (LAB)Redes - Monitoreo de trafico por UDP

Que tal para esta entrada se nos encargo monitorear la sumilacion de trafico por UDP. Es algo parecido en una entrada anterior donde simulamos el protocolo con un python, ahora sera con un ".tcl".

Para este ejemplo partiremos del caso que tenemos un servidor de video y varias personas hacen peticion al mismo tiempo o a diferente tiempo, mientras este sigue enviando información a un usuario sin interrumpir el envio.

Se crearon 6 nodos receptores/transmisores para representar a casa persona y el servidor de video.

Codigo:



Monitoreo:

Latencia
Como tenemos 6 nodos y un nodo servidor, tenemos que tomar cada par de nodos como si fueran "unicos" esta para saber la perdida o ganancia de cada nodo.

Cogido awk



Graficas
Retardo de cada par de nodos(nodoX => servidor).
El eje X representa el tiempo transcurrido, mientras que el Y representa el tamaño de los paquetes.


nodo 3 => servidor

nodo1 => servidor

nodo2 => servidor

nodo4 => servidor

nodo 5 => servidor

nodo6 => servidor
En todos los casos, la espera siempre fue mayor cuando hacian un peticion, esto es porque simpre estaba con un nodo trasmitiendo un "mensaje".

Throughput

Codigo awk



Graficas
nodo 0 => servidor

nodo 1 => servidor

nodo 2 => servidor

nodo 4 => servidor

nodo 5 => servidor

nodo 6 => servidor




Video



Ubicuo #7(LAB) - Resumen, Localización en interiores y exteriores con servicios ubicuos


Towards Ubiquitous Indoor Location Based Services and Indoor Navigation
(Hacia servicios ubicuos basados en localización interior y navegación interior)

Los servicios basados en localización(LBS) y la navegación han sido impulsados por la evolución de los dispositivos móviles, la disponibilidad de GPS y últimamente de Internet móvil. Hoy en día, estos servicios son ampliamente utilizados en los sistemas de navegación al aire libre y las aplicaciones web móviles. El éxito de los sistemas de navegación al aire libre muestra la necesidad de los usuarios para la navegación y la información basada en la ubicación.

Sin embargo, hasta ahora, falta una tecnología estándar para localización en interiores. Las diferentes tecnologías y productos están disponibles, pero normalmente no trabajan juntos. 
En aire libre LBS se beneficia de una gran cantidad de contenido disponible en la Internet. Los datos del mapa y contenido están disponibles por proveedores como Google, OpenStreepMap1 o servicios de páginas amarillas.

Los datos de navegación en interiores / servicios basados ​​en localización (INLBS) se caracteriza por un contexto mucho más local y temporal. 

Las estructuras internas de edificios, tales como topologías de red, no siempre se conoce públicamente y probablemente son sujetos a cambios frecuentes. Los empleados se mueven a otras oficinas para buscar personas, jefes, un objeto olvidado y tienen que visitar cada puerta o incluso tocar e interrumpir una conversación, pero aun así toda esta información es a nivel local y, posiblemente con muchas restricciones de acceso y no deseable para compartir esta información publicamente en internet.

Esta es una imagen del proyecto de google, estas dentro de una libreria y te muestra sus secciones/habitaciones y en este caso en particular te dice como llegar a la sección "musica" con simplemente preguntarle a los lentes.
Google glass - localización en interiores.



Dos de los problemas mas comunes son:

- Un posicionamiento interior que sea capaz de proporcionar estimaciones de la posición con un cierto grado de precisión y exactitud.
- La comunicación inalámbrica con el fin de transferir datos entre la infraestructura y los dispositivos móviles.

Dos escenarios para el posicionamiento son concebibles:

- Posicionamiento sin asistencia: el dispositivo móvil puede determinar su localización por consumo de datos que se transmiten por diferentes estaciones de base de datos. Este escenario es
similar al GPS, donde los satélites GPS envían datos y el dispositivo calcula la posición. La información de ubicación se lleva a cabo en el interior del dispositivo y no es conocido por nadie más,
con el fin de utilizar los servicios basados ​​en la localización, el dispositivo tiene que enviar su posición.


-  El dispositivo móvil por sí mismo no es capaz de determinar su propia posición. Este podría ser el caso de bajo costo, dispositivos de baja potencia que carecen de hardware capaz de hacer cálculos de posicionamiento. Sin embargo, todavía puede ser posible estimar la posición con la incorporación de datos obtenidas de diferentes estaciones de base de datos colocados dentro del edificio.






Arquitectura en capas para servicios basados ​​en la localización en interiores.


1.- Aplicación
La capa superior es donde aplicaciones de localización residen.
Estas aplicaciones utilizan las funciones definidas en la API (5), la posición del dispositivo móvil proporcionado por la Corrección de capa (2).
Posibles ejemplos de dichas aplicaciones son:
- navegación
- Difusión Selectiva de la Información
- Páginas Amarillas
- Friend Finder
- congestión de detección

2.- Corrección
Las estimaciones de posición proporcionados por la capa de posicionamiento (3)
se espera que produzca posiciones defectuosas, resultados imprecisos, limitaciones físicas, etc.
El objetivo general de esta capa es limitar el error de los mecanismos de hardware y posicionamiento
y para aumentar la confianza en la estimación de localización pora corregir, filtrar y enriquecer los datos recogidos.

3.- Posicionamiento
La capa de posicionamiento proporciona la posición del dispositivo móvil de una manera dependiente del hardware. Los ejemplos mas comunes son Posicionamiento sin asistencia y posicionamiento Distribuido ambos descritos anteriormente.

4.- Hardware
Los dispositivos como Bluetooth, ZigBee o WiFi entre otros son el hardware del que cual se compone la capa. Los dispositivos proporcionan diferentes mediciones de hardware utilizadas para el posicionamiento. Dependiendo de las capacidades del hardware estos valores podrían ser de calidad en las intensidades de señal, hora de llegada o las mediciones de ángulo de llegada. Esta capa está inherentemente distribuida, ya que mide varios lugares.
La capa superior adquiere estas medidas para realizar el posicionamiento de un dispositivo móvil.

5.- API
Esta capa proporciona la funcionalidad básica que las aplicaciones basadas en ubicación utilizan con el fin de permitir el reconocimiento de ubicación.
La funcionalidad proporcionada cubre funciones como obtener el nombre de una habitación dada una coordenada (y un radio), la resolución de las coordenadas para un sitio dado un nombre, determinar si una entidad está dentro de una región geográfica coordenadas dadas y un diámetro y, más básicas, devolver la posición de una entidad.

6.- (Geo-) Proveedor de contenidos
Esta capa proporciona contenido de topología y datos adicionales y proporciona la funcionalidad para acceder a estos datos. La funcionalidad típica sería la de buscar habitaciones en una región geográfica o devolver el número de la habitación para una posición. Las propiedades adicionales, como las restricciones de acceso, información para las personas con discapacidad, alturas y anchos de las puertas de una fábrica, los límites de peso para los ascensores y la información de inventario, como impresoras, acceso de seguridad se almacenan o se hace referencia.

7.- Direccionamiento
Aparte de posicionamiento, comunicación con entes móviles es de importancia con el fin de enviar mensajes, la transferencia de las rutas de navegación o para otros fines. Cuatro sistemas básicos de comunicación son considerados en la capa de direccionamiento:

- Unicast: Los mensajes están destinados a exactamente una entidad móvil.
- Multicast: Los mensajes se envían a un grupo de entidades móviles.
- Difusión: Los mensajes están dirigidos a todas las entidades móviles.
- Geocast: los mensajes se dirigen a todas las entidades móviles en un área determinada.

8.- (Geo-) Enrutamiento
En general, las tecnologías para la estimación de la posición y de la comunicación no tiene que ser el mismo. Es posible soportar la comunicación diferente y muchos tipos de estimación de la posición de hardware durante el tiempo de transición hacia un estándar.
Para la comunicación con un dispositivo móvil la información de la tecnología a utilizar tiene que ser administrado.

Un dispositivo móvil del usuario se encuentra en un área específica y tiene conexiones con las estaciones de transceptor en esa área en particular. Es conveniente presentar mensajes selectivamente a aquellas estaciones transceptoras y no todos los posibles. Finalmente, en las estaciones de transceptor, la tecnología de la comunicación para el envío al dispositivo móvil se selecciona y se enviarán los datos.



Referencias

http://www.ti5.tuhh.de/publications/2010/WPNC10_Towards_Ubiquitous_Indoor_Location_Based_Services_and_Indoor_Navigation.pdf

jueves, 11 de abril de 2013

Tarea#3 - Codificación Huffman python

Que tal para esta entrada se nos encargo implementar el código Huffman en "x" lenguaje yo escogí python. A continuación una breve explicación y

Un poco de teoria:

El término se refiere al uso de una tabla de códigos de longitud variable para codificar un determinado símbolo (como puede ser un carácter en un archivo), donde la tabla ha sido rellenada de una manera específica basándose en la probabilidad estimada de aparición de cada posible valor de dicho símbolo. Fue desarrollado por David A. Huffman mientras era estudiante de doctorado en el MIT, y publicado en "A Method for the Construction of Minimum-Redundancy Codes".
El algoritmo de construcción del árbol puede resumirse así:
  1. Crear un nodo hoja para cada símbolo, asociando un peso según su frecuencia de aparición e insertarlo en la lista ordenada ascendentemente.
  2. Mientras haya mas de un nodo en la lista:
    1. Eliminar los dos nodos con menor probabilidad de la lista
    2. Crear un nuevo nodo interno que enlace a los nodos anteriores, asignándole como peso la suma de los pesos de los nodos hijos.
    3. Insertar el nuevo nodo en la lista, (en el lugar que le corresponda según el peso).
  3. El nodo que quede es el nodo raíz del árbol.






Imagen y texto tomados de: http://es.wikipedia.org/wiki/Codificaci%C3%B3n_Huffman

Implementación

Como podemos observar en la imagen, se tiene una lista con las letras únicas del mensaje y sus repeticiones en el mensaje y siempre están ordenada de menor a mayor.

Es importante recalcar que cuando se unen dos nodos(siempre son los dos mas chicos) ellos crean un nuevo nodo llamado dos y con valor 0||1. El valor depende de la posición en la lista en la que están ordenados. y este nuevo nodo se agrega a la lista y repetiremos los mismos pasos hasta que el nuevo  nodo ya no tenga con quien unirse.


Una vez que estén unidos, tenemos que obtener sus códigos... el cual es el valor binario que se forma desde el nodo inicio hasta el nodo final e ir guardando el valor de la arista por donde pasa.


Una ves teniendo los códigos de las letras, únicamente tenemos que recorrer la cadena original, e ir reemplazando por los códigos obtenidos anteriormente.

Para descomprimir se hace los mismo que comprimir pera al revés, empiezas con el nodo final y el objetivo es llegar a un nodo tipo string, siempre guiándote por la cadena binaria.


Captura de pantalla




El mejor de los casos...

...es cuando tengas un mensaje de tamaño "n" pero la mayoría de las letras son iguales. Esto porque el árbol no hace tanta iteraciones para llegar a entontrar el código de la palabra que mas se repite.


El peor de los casos...

Es cuando el mensaje cuenta con una longitud "x" pero la mayoría de sus letras son muy diferentes y no se repiten tanto. Esto porque tiene que recorrer muchos nodos antes de llegar al nodo inicial.




martes, 9 de abril de 2013

Tarea 6 - (LAB)Redes - Topologia mixta - ns2

Para esta entrada se nos encargo hacer una topoligia con enrutamiento. Trabaje con una topologia tipo mixta y el objetivo es bloquear una canal para que el enrutamiento busque otra ruta para enviar paquetes.

Topoligia mixta:
En esta topología mixta, si un ordenador falla, entonces es detectadopor el hub al que está conectado y simplemente lo aísla del resto de la red.Sin embargo, si uno de los hub falla, entonces los ordenadores que estánconectados a él en la red en estrella no podrán comunicarse y, además, elbus se partirá en dos partes que no pueden comunicarse entre ellas.

El codigo de la implementacion se los dejo aqui abajo.
Aqui un codigo de la implementación.




Ubicuo #6(LAB) - Retroalimentación a los equipos

Alarma inteligente 
liga a la entrada: http://ubicomputo.blogspot.mx/2013/03/avance-3-hardware-software.html

Ellos mencionan que su proyecto lo dividen en 2 partes, uno para la comunicación de carro-casa y el otro para el monitorireo del carro-via remoto.
Para la parte#1 - Ellos dicen que utilizaran bluetooth, pero en lo personal una comunicación zigbee es mejor.... hasta el wifi podría funcionar, porque con el bluetooth necesitas <<permisos>> para poder usar contacto con el aparato y esto es malo si lo que queremos es ahorrar tiempo. 
Para la parte#2 - La parte del GPS me gusto mucho, tal vez como recomendación seria buscar otros modulos mas baratos o usar un celular... estos modulos están como en 2,000. 

Computadora inteligente 
liga a la entrada: http://aveoctavo.blogspot.mx/2013/03/presentacion-para-clase.html 

Esta idea esta buena, lo que me entra ruido es que con Opencv limiten a estar siempre en una misma posición. 
Pueden usar SURF, es un metodo de opencv que detecta una misma imagen aun cuando este en diferente angulo, nos ahorraríamos tiempo al no tener que estar en una posición fija. 

Localización de cosas por bluetooth 
liga a la entrada: http://gtdsoftwa.blogspot.mx/2013/03/presentacion-requerimientos.html 

Es lo mismo que el problema de dar permisos pero este es un arma de 2 filos... siempre teníamos que dar permisos al objetos a buscar que seria lo mismo que buscarlo <<a la antigua>>.
Zigbee es el protocolo que yo les recomendatoria. Para la parte de la voz, tienen que enfocarse en eliminar ruido, porque una palabra semejante podría tomarla como buena. Tambien un consejo tener un comando para reiniciar la búsqueda, en caso de que en ligar de buscar tus llaves... quieras encontrar el control de la TV primero. 

Galeria inteligente 
liga a la entrada: http://ultimo-sem.blogspot.mx/2013/03/entrega-3.html 

Esta es una idea muy vaga porque si solo se limitan en usar sensores pues basicamente en 3 hrs estaria terminado. Lo interesante seria detectar personas con interes en leerla (usar patrones de psicologia) y activar el sonido. Esto eliminaria personas innecesarias que quieran arruinar al sistema.

Estaria tambien exelente agregarle comandos de voz para que en la descripción general solo te digo información del cuadro y por ejemplo te intereso el cuadro, tu podrías decir "autor" y el cuadro te reconozca esta palabra y te de la descripción de autor.

Cama inteligente 
liga a la entrada: http://3-its.blogspot.mx/2013/03/avance-4.html

Tienen todo abarcado, si tomaron en cuenta todo lo que le dijeron y sacaron provecho de ello. Yo quiero uno cuando este terminado !!!!!.

Seguridad en casa
liga a la entrada: http://3puntosteam.blogspot.mx/2013/03/reporte3-requerimientos-hardware.html

Para el sensor de presencia podrian usar un sensor que lo distribuye SPARFUN. Para la parte del acceso los pueden hacer con la tecnologia NFC o comprar algunas TAGS para hacerlo con RFID.

El objetivo es ahorrarnos el mayor tiempo posible y darle seguridad.