Sistema Estadístico de Localización Indoor

P r i me r
D e s a f o T e c n o l g i c o D T S TC
d e l
MEMORIA DE PROYECTO (v1.)
Grupo I4
Ivn Fernndez Bermejo Ivn Lpez Espejo Jonathan Prados Garzn Mark Rowsell
Grupo I4
Memoria de Proyecto (v1.)
Sumario
1. 2.
Introduccin ......................................................................................... 3 Teora de la Solucin ............................................................................ 5 2.1 Teora del Reconocimiento de la Localizacin................................. 5 Formulacin de los HMMs discretos ......................................... 7 Los tres problemas bsicos ......................................................10 Solucin al problema de evaluacin ...................................11 Solucin al problema de decodificacin..............................15 Solucin al problema de estimacin ...................................18
2.1.1 2.1.2
2.1.2.1 2.1.2.2 2.1.2.3 2.1.3 2.2 3.
Aplicacin de HMMs al reconocimiento de la localizacin .......22
Teora de la Comunicacin ............................................................25
Estado del Prototipo ...........................................................................30 3.1 3.2 3.3 Preparacin de los datos ................................................................42 Entrenamiento del sistema ............................................................48 Evaluacin.....................................................................................60
4. 5.
Test y Resultados ................................................................................62 Conclusiones y Lnea de Trabajo Futuro .............................................69 5.1 5.2 5.3 Puntos Fuertes ..............................................................................69 Puntos Dbiles y Soluciones ..........................................................72 Trabajo Futuro .............................................................................75
Grupo I4
1.
Introduccin
Este texto recoge la primera versin de memoria sobre el estado actual del prototipo de localizacin mvil en la
ETSIIT.
Recordando lo expues-
to en el documento de propuesta de proyecto, debemos hacer constar en primer lugar que la solucin finalmente llevada a la prctica es la consistente en el empleo del modelado estadstico que ofrecen los modelos ocultos de Mrkov (HMMs de ahora en adelante) por simple inaccin sobre la otra propuesta basada en la clsica solucin de triangulacin.
Tal y como se adelant en el anterior documento presentado, el prototipo finalmente implementado es puramente software (programado en el lenguaje orientado a objetos ciones utilizadas como
API: JAVA),
asentndose este sobre un set de aplica-
la herramienta netsh de Windows para la medi-
da de la potencia de la seal recibida de cada uno de los APs con cobertura y el conjunto de aplicaciones para la manipulacin de los HMMs,
HTK.
Por
tanto, actualmente es funcional bajo cualquier sistema que haga uso del SO Windows. Tambin es importante notar que en este punto ya se ha procedido a disgregar parte de la funcionalidad en tres mdulos diferenciados: cliente del equipo localizable, cliente del equipo localizador y servidor. No obstante, el primero de ellos an alberga al mdulo entrenador y la capacidad de procesamiento para la deteccin de su localizacin; capacidad que se desea trasladar en un futuro al lado del servidor con el fin de liberar de cantidad de cmputo al dispositivo que emplea el usuario. Por tanto, el servidor, actualmente, nicamente se encarga de gestionar la comunicacin entre dos usuarios, posibilitando que cualquier cliente fijo conozca la posicin instantnea de cualquier otro mvil conectado al sistema. 3
Grupo I4
Los siguientes apartados recogen una descripcin suficiente para comprender el funcionamiento del sistema as como un anlisis del mismo en vistas a evaluar, primordialmente, su precisin con el fin de establecer una lnea de trabajo futuro. Particularmente, el punto segundo expone brevemente el fundamento terico de la tecnologa empleada diferenciando dos cuestiones importantes: la tarea del reconocimiento de la localizacin y la gestin de la comunicacin. Durante el desarrollo de la primera cuestin sern presentados una breve puesta en contexto, la formulacin de los HMMs, los tres problemas bsicos cuya resolucin prctica es necesaria para la tarea del reconocimiento (abordando brevemente los algoritmos de Viterbi, Forward-Backward y de Baum-Welch) y la aplicacin de todo lo anterior en el reconocimiento de la localizacin. A continuacin, en el tercer punto, es mostrado el estado del prototipo hasta la fecha, explicando su funcionamiento tanto interno como a nivel de usuario para, posteriormente, ser evaluado en un entorno prctico de reconocimiento en la escuela. Tanto las condiciones de testeo como los resultados obtenidos y conclusiones breves al respecto son recogidos en el cuarto punto, analizndose en el ltimo de ellos las ventajas y desventajas del sistema, haciendo hincapi en las potenciales correcciones y mejoras. Enlazado con esto ltimo, se incluye la lnea de trabajo futuro justificada por la potencial efectividad que puede ofrecer esta tecnologa si se contina investigando.
Grupo I4
2.
Teora de la Solucin
Este segundo punto expone la teora sobre la cual se fundamenta la
construccin del prototipo. El primer subapartado recoge la teora de localizacin, realizando en primer lugar una aproximacin al reconocimiento mediante HMMs para, seguidamente, desarrollar su formulacin, exponer los tres problemas bsicos cuya resolucin es necesaria para la aplicacin de la tecnologa a un problema prctico (abordando brevemente los algoritmos de Viterbi, Forward-Backward y Baum-Welch) y explicar cmo se pueden emplear los HMMs, particularmente, para la tarea del posicionamiento. El segundo subapartado trata de sentar las bases para la posterior implementacin de la gestin de la comunicacin entre los mdulos clientes y servidor.
2.1
Teora del Reconocimiento de la Localizacin
La figura 2.1 recoge un abstracto diagrama de bloques, basado en la solucin tpica al problema del reconocimiento, particularizado a nuestro contexto de estimacin de la localizacin mediante la utilizacin de los modelos ocultos de Mrkov (HMMs).
Figura 2.1. Sistema de localizacin basado en HMMs.
Grupo I4
La implementacin del anterior diagrama pasa por la construccin de un front-end, cuya misin es la de realizar mediciones de la potencia de seal percibida de parte de todos y cada uno de los puntos de acceso (APs) a una determinada red con cobertura sobre el dispositivo cuya localizacin se desea estimar para posteriormente ser manipuladas y presentadas al reconocedor estadstico. El front-end en el prototipo final est basado, fundamentalmente, en la llamada al proceso netsh incluido en el SO Windows con el fin de realizar la anterior medicin. A partir del tratamiento y agrupamiento oportuno de los datos obtenidos, es posible configurar una estructura de caractersticas diferencial lo suficientemente decorrelada y reducida como para poder servir de identificador de una determinada localizacin con el fin de entrenar un HMM asociado o bien estimar la localizacin actual del dispositivo. El funcionamiento del front-end ser pertinentemente detallado en el punto tercero. El otro proceso del diagrama implementa la funcin del reconocimiento en s, basada en la aproximacin estadstica de los HMMs. En l, el set de caractersticas extrado del front-end es comparado con un conjunto de patrones de referencia constituyentes de las unidades de reconocimiento (localizaciones). Cada una de estas unidades est representada por un HMM. La salida de esta etapa y, por ende, del sistema, es el mejor candidato (localizacin reconocida) que explica el conjunto de parmetros observados.
Los HMMs fueron descritos por primera vez en una serie de artculos de ndole estadstica y publicados por Leonard E. Baum y sus colegas durante la segunda mitad de la dcada de los 60. Una de las primeras aplicaciones de esta tecnologa fue el reconocimiento del habla a partir de la mitad de la dcada de los 70, aunque tambin se ha exportado su utilizacin
Grupo I4
al reconocimiento general de patrones desde la segunda mitad de la dcada de los 80. En este tipo de aproximacin, los patrones, a diferencia de en el paradigma de reconocimiento de patrones, no se encuentran almacenados en memoria, sino que aparecen representados por un modelo de produccin. Dichos modelos de produccin son estimados a partir de una fase previa de entrenamiento, en la cual se le introduce al generador de los mismos una cantidad suficiente de versiones de los patrones susceptibles de ser clasificados. 2.1.1 Formulacin de los HMMs discretos
Un HMM es un autmata de estados finitos, basado en un proceso de Mrkov, que posee la capacidad de emitir una secuencia de smbolos observables a su salida. Este modelo est formado por estados que se encuentran interconectados, y a cuyos arcos de conexin se les asigna una determinada probabilidad. Cada uno de estos estados tiene asociada una distribucin de probabilidad de generacin de smbolo, de tal forma que, cada vez que el modelo se encuentra en un determinado estado, en funcin de dicha distribucin ser emitida una observacin. Un HMM se conforma por dos procesos estocsticos, de los cuales, la secuencia acontecida de estados queda oculta (pues slo es observable la generacin de smbolos), configurndose as el nombre de este tipo de autmata como modelo oculto de Mrkov. Un HMM queda caracterizado por los siguientes cinco elementos:
1. El nmero de estados del modelo,
. Generalmente, dichos estados se
encuentran interconectados de tal forma que cada uno de ellos es accesible desde cualquier otro. Denotamos al estado en el cual se en-
Grupo I4
Memoria de Proyecto (v1.) al conjunto
cuentra el modelo en el instante de tiempo , as como con los estados, de la forma, ={ , ,, }.
2. El nmero de smbolos de observacin distintos por estado,
. Estos
smbolos de observacin se corresponden con la salida fsica del sistema que est siendo modelado. Denotamos los smbolos individuales como ={ , ,, }, as como al smbolo generado por el mo-
delo en el instante de tiempo .
3. La matriz de probabilidades de transicin entre estados, donde
={
},
1 ,
(2.1)
y donde estas probabilidades verifican la siguiente condicin de normalizacin:
= 1,
1,2, ,
(2.2)
4. La matriz de probabilidades de generacin de smbolos en cada uno de los estados, ={ ( ( )}, donde )= = | = , (2.3) = 1,2, , ; = 1,2, , ,
Grupo I4
) = 1,
1,2, ,
(2.4)
5. La matriz de estados iniciales, = { }, donde = = , 1,2, , ,
(2.5)
= 1,
1,2, ,
(2.6)
La especificacin completa de un HMM requiere, por tanto, del nmero de estados y de smbolos observables, y , de los smbolos de , y . Por conve-
observacin y de las tres matrices de probabilidades, niencia, se hace uso de la notacin compacta conjunto completo de parmetros del modelo.
= ( , , ), para indicar el
Dados unos valores apropiados a los parmetros mencionados en el anterior prrafo, el HMM asociado puede proporcionar una secuencia de observaciones, =( , ,, ), donde cada observacin, , siendo , se correspon-
de con uno de los smbolos del conjunto
el nmero total de ob-
servaciones contenidas en la secuencia, y cuya generacin procede del siguiente modo: 9
Grupo I4
1. Seleccin de un estado inicial, estados iniciales, . 2. Se establece el instante de tiempo 3. Seleccin de la observacin =
, de acuerdo con la matriz de
= 1. de acuerdo a la distribucin de
probabilidad de generacin de smbolos para el estado i-simo, ( ). = , segn la distribucin de pro.
4. Transicin a un nuevo estado,
babilidad de transicin a un nuevo estado para el actual, 5. Se establece el instante de tiempo al paso 3 si <
= + 1. A continuacin se vuelve
o, en caso contrario, finaliza el procedimiento.
Notar que la secuencia de estados por los que el modelo pasa segn el anterior mtodo, bles caminos, =( , ,, ), es desconocida. Cada uno de estos posi| ,
, tiene asociada una probabilidad de ocurrencia dados el .
modelo y la secuencia de observables,
2.1.2
Los tres problemas bsicos
Los tres problemas bsicos de inters que han de ser resueltos para la utilidad prctica del modelo son los siguientes:
Problema 1: Dada la secuencia de observaciones,
, y el modelo ,
calcular de forma eficiente la probabilidad de la secuencia de observaciones dado el modelo, es decir, | .
10
Grupo I4
Memoria de Proyecto (v1.) Problema 2: Dada la secuencia de observaciones, encontrar la secuencia de estados (camino), las observaciones. , y el modelo ,
, que mejor explique
Problema 3: Dada la secuencia de observaciones,
, encontrar el
conjunto de parmetros , que mejor se ajuste a dicha secuencia.
El primer problema es el conocido como problema de evaluacin, cuya solucin nos proporciona el modelo que mejor se ajusta a las observaciones. Cada uno de estos modelos, , representa a cada una de las clases en las que un objeto es susceptible de ser catalogado, de tal modo que se pretende encontrar la clase tal que la probabilidad | sea mxima, corres-
pondindose la secuencia de observaciones a dicha clase. El segundo de ellos es el conocido como problema de decodificacin, el cual plantea la recuperacin de la secuencia de estados acontecida en el modelo, , mediante un
criterio de optimizacin. Por ltimo, el tercer problema es el denominado problema de estimacin, el cual est referido a la estimacin de los parmetros de los modelos que componen el sistema de reconocimiento, a partir de las secuencias de entrenamiento. A continuacin se detallan las soluciones extendidas para estos tres problemas.
2.1.2.1 Solucin al problema de evaluacin
Como ya hemos introducido, se desea calcular la probabilidad de la secuencia de observaciones, =( , ,, ), dado el modelo , es decir,
| . El modo directo de hacerlo parte de la consideracin de todas y cada una de las posibles secuencias de estados de longitud 11 (el nmero de
Grupo I4
Memoria de Proyecto (v1.) secuencias de estados distintas. Consi=( , ,, ), donde
observaciones). En total, existen
deremos a partir de ahora una fija cualquiera,
se corresponde al estado inicial. La probabilidad de la secuencia de observaciones, , dada la anterior secuencia de estados es
| ,
| ,
(2.7a)
donde se asume la independencia estadstica de las observaciones. De esta forma tenemos que
| ,
).
(2.7b)
La probabilidad de dicho camino se computa como
(2.8)
La probabilidad conjunta de
es sencillamente el producto de los dos
trminos de arriba. La probabilidad del vector de observaciones se calcula a partir de la suma de todas las probabilidades conjuntas definidas por todas y cada una de las secuencias de estados:
, |
| ,
= (2.9)
).
12
Grupo I4
La interpretacin del clculo en la ecuacin (2.9) es la siguiente. Inicialmente (en un tiempo dad = 1) nos encontramos en el estado con probabili( ).
, generndose el smbolo
en este estado con probabilidad
Posteriormente, se lleva a cabo una transicin desde el estado actual al estado en un instante de tiempo = 2 con una probabilidad ( , ge-
nerndose el smbolo
con una probabilidad
). El proceso contina
de esta forma hasta que se realiza la ltima transicin en un instante de tiempo da ( ). = desde el estado al estado con una probabilidad asocia, con una probabilidad
y generndose el ltimo smbolo,
Con un pequeo razonamiento se puede llegar a que el clculo de involucra del orden de 2 operaciones. Por tanto, incluso para un = 100 y = 5, existen
reducido nmero de observaciones y estados como del orden de 10
operaciones! Por suerte, existe un algoritmo conocido co-
mo Forward-Backward (Adelante-Atrs), el cual simplifica considerablemente el clculo. ( ) de-
Para el procedimiento hacia adelante considrese la variable finida como ( )= , = | .
(2.10)
Dicha variable representa la probabilidad de observacin de la secuencia parcial hasta el instante , , y el estado en dicho instante de
tiempo, dado el modelo . La ejecucin del procedimiento es como sigue:
13
Grupo I4 1. Inicializacin:
()= 2. Recursin:
),
(2.11)
( )= 1 3. Finalizacin:
()
( .
), (2.12)
1; 1
( ).
(2.13)
dida. Ahora se requiere del orden de 2 operaciones para de tan slo 5000. = 100 y
( ), con 1
Observando el nmero de operaciones involucrado en el clculo de y 1 , vemos que este se ha reducido en gran meclculos. Si antes el nmero de
= 5 era del orden de 10 , ahora resulta serlo
Tambin es posible resolver el problema mediante la aplicacin de un procedimiento hacia atrs. De manera similar, podemos considerar una variable hacia atrs, ( ), definida como ()=
(2.14)
14
Grupo I4
Dicha variable representa la probabilidad de observacin de la secuencia parcial desde el instante hasta el final, , dados el estado en
el instante de tiempo , y el modelo como sigue:
. La ejecucin del procedimiento es
1. Inicializacin: ( ) = 1, 2. Recursin: 1 .
(2.15)
( )= 1 3. Finalizacin: ; =
( 1,
( ), (2.16) 2, ,1.
) ( ).
(2.17)
Donde el coste computacional es similar al del procedimiento hacia adelante.
2.1.2.2 Solucin al problema de decodificacin
A diferencia de para el primer problema, para este segundo existen diversas formas de resolucin. La idea es encontrar la secuencia de estados 15
Grupo I4
ptima asociada a la secuencia de observaciones dada. La dificultad reside en la definicin de secuencia ptima de estados, pues existen varios criterios posibles de optimalidad. As, por ejemplo, una opcin puede ser la seleccin del estado tal que individualmente sea el ms probable en cada instante
de tiempo . Este criterio de optimizacin maximiza el nmero esperado de estados individuales correctos. Para implementar esta solucin al problema de decodificacin definimos la siguiente variable de probabilidad a posteriori: ()= = | , .
(2.18)
Dicha variable representa la probabilidad de estar en el estado tante de tiempo que , = | ( ) ( ), podemos reescribir () () . () ()
en el ins-
dados el modelo y la secuencia de observaciones. Puesto es igual a ( ) como
( )=
(2.19)
Usando la anterior probabilidad a posteriori podemos conocer el estado ms probable en el instante , de la forma,
= argmax
() ,
1 .
(2.20)
El problema de este criterio de optimalidad es que encuentra la probabilidad mxima de estar en un determinado estado para cada instante sin
preocuparse de si la secuencia global resultante es ptima o, sencillamente, posible. Una opcin para solventar este problema es modificar el criterio de optimizacin. El ms ampliamente utilizado se basa en encontrar el cami16
Grupo I4 no,
Memoria de Proyecto (v1.) | , , equivalente a maximizar la
, que maximiza la probabilidad , | ; es decir,
probabilidad
= argmax
, |
(2.21)
Una tcnica formal, basada en mtodos de programacin dinmica, para el clculo del camino ptimo, es el algoritmo de Viterbi. Para comenzar, se define la siguiente variable,
( )=
max
| ,
(2.22)
representando el camino de mxima probabilidad seguible hasta el instante . Por recursin tenemos que
( ) = max
()
).
(2.23)
Con el fin de recuperar la secuencia de estados, necesitamos realizar un seguimiento del argumento que maximiza la anterior ecuacin para cada . Esto se consigue mediante la utilizacin del array es como sigue: y
( ). El procedimiento
1. Inicializacin:
( )=
), ( ) = 0.
(2.24a)
(2.24b)
17
Grupo I4 2. Recursin:
( ) = max
()
( ), ; (2.25a) , (2.25b)
( ) = argmax
2 ; 1
()
2 ; 1 3. Finalizacin:
= argmax
= max
(),
().
(2.26a) (2.26b)
4. Rastreo hacia atrs del camino:
),
1,
2, ,1.
(2.27)
Notar cmo el algoritmo de Viterbi es similar (a excepcin del paso de rastreo hacia atrs) en implementacin al mtodo Adelante-Atrs.
2.1.2.3 Solucin al problema de estimacin
El ltimo y ms complicado de los problemas trata del ajuste de los parmetros, = ( , , ), del HMM, con la premisa de optimizar algn cri-
terio. No existe ningn mtodo analtico conocido para la obtencin del conjunto de parmetros que maximice la probabilidad de la secuencia de 18
Grupo I4 observaciones, cionar un
Memoria de Proyecto (v1.) | , de una forma cerrada. Podemos, sin embargo, selec| sea mxima localmente mediante
tal que la probabilidad
la aplicacin de un procedimiento iterativo como el de Baum-Welch; tambin podran ser usadas tcnicas de gradiente. A continuacin se muestra el procedimiento iterativo basado en el trabajo de Baum.
Con el fin de describir el procedimiento para la reestimacin (actualizacin iterativa y mejora) de los parmetros del HMM, hemos de definir la variable estado ciones, ( , ) (probabilidad de estar en el estado en el instante ), de la forma, + 1, dados el modelo en el instante y en el
y la secuencia de observa-
(, )=
(2.28)
A partir de las definiciones de variables dadas durante la explicacin del algoritmo Adelante-Atrs, podemos reescribir () () ) ( , ) como ( ) ()
(, )= =
, | ( ( )
= ) (
()
| .
= (2.29)
()
Ahora podemos relacionar la variable especificada en (2.18), ( , ), de la forma,
( ), con
( )=
( , ).
(2.30)
19
Grupo I4 Si sumamos
( ) sobre el ndice temporal, , obtenemos una cantidad que ( , ) sobre el ndice temporal, ,
puede ser interpretada como el nmero esperado de transiciones desde el estado . De forma similar, la suma de
puede ser interpretada como el nmero esperado de transiciones desde el estado al , esto es,
( )=
(2.31a)
(, )=
(2.31b)
Haciendo uso de (2.30) y (2.31a)-(2.31b), podemos ofrecer un mtodo para la reestimacin de los parmetros de un HMM. Un conjunto razonable de frmulas de reestimacin para , A y B, es el siguiente: = = ( )= . =
( = 1) = = ()
( ), (, ) , () ()
,
(2.32a)
(2.32b)
(2.32c)
Si definimos el modelo actual como
= ( , , ), siendo utilizado en
el cmputo del miembro derecho de las ecuaciones (2.32a)-(2.32c), y definimos el modelo reestimado como = ( , , ), correspondiente al miembro
izquierdo de las mismas, Baum y sus colegas probaron que, bien el modelo
20
Grupo I4 inicial = , o bien >
Memoria de Proyecto (v1.) define un punto crtico de la funcin de probabilidad, en cuyo caso es ms probable que el modelo en el sentido de que a partir
| . Esto significa que se ha encontrado un modelo
del cual la secuencia de observaciones es ms probable que se haya generado.
Basado en el procedimiento anterior, si usamos iterativamente lugar de
en
y repetimos el clculo de la reestimacin, podemos mejorar la
probabilidad de que la secuencia observada haya sido generada por el modelo hasta un determinado lmite. El resultado final de este procedimiento de reestimacin es una estimacin de mxima semejanza (ML) del HMM. Las frmulas de reestimacin propuestas en (2.32a)-(2.32c), pueden derivarse directamente de la maximizacin sobre de la funcin auxiliar de Baum,
, |
log
, | .
(2.33)
Puesto que
( , )
| ,
(2.34)
podemos maximizar (2.33) para mejorar probabilidad
en el sentido de incrementar la
| . Eventualmente, la funcin de probabilidad converge a
un punto crtico si iteramos el procedimiento.
Se puede demostrar que el conjunto de frmulas para la reestimacin de los parmetros del modelo derivado de la variable las probabilidades adelante y atrs, viene dado por 21 , , en funcin de
Grupo I4
Memoria de Proyecto (v1.) = = () () () = () () ( ), (, ) , () () ()

,
(2.35a)
( ) () = () () ) =
(2.35b)
( )=
() () ( , () ()
(2.35c)
2.1.3
Aplicacin de HMMs al reconocimiento de la localizacin
Los HMMs en el contexto del reconocimiento de la localizacin se destinan al modelado de potencias de seal de APs de las unidades de reconocimiento, en nuestro caso, localizaciones. As, por ejemplo, el conjunto de = lugares registrados en una base de datos podra designarse como , ,, . Puesto que se decide entrenar un HMM, , por cada una
de las localizaciones,
, en nuestra base de datos, el reconocimiento de una
determinada posicin representada mediante un conjunto de vectores de caractersticas u observaciones, , se reduce a la identificacin del HMM, | . Mediante el uso de
, que hace mximo el valor de la probabilidad
la regla de decisin basada en MAP (maximum a posteriori), se obtiene la localizacin reconocida a partir de calcular
( ) = argmax
(2.36)
donde
se puede obtener segn el teorema de Bayes de la forma,
22
Grupo I4
Memoria de Proyecto (v1.) | = | . (2.37)
Dado que la probabilidad a priori de la secuencia de caractersticas,
es constante durante el proceso de reconocimiento, puede ser obviada su contribucin. Esto hace que el problema de la seleccin de un modelo se reduzca al clculo de ( ) = argmax Por otro lado, APs, mientras que | | .
(2.38)
viene dada por el modelo de potencias de seal de lo hace por el modelo de localizaciones. Este mode-
lo de localizaciones se formula como una distribucin de probabilidades que refleja la frecuencia de aparicin de la localizacin en el corpus de entre-
namiento. La figura 2.2 muestra de forma abstracta el funcionamiento del sistema de posicionamiento (reconocimiento de la localizacin).
La topologa ergdica (figura 2.3) de un modelo HMM es la ms general, la cual asegura una probabilidad de transicin no nula desde uno a otro estado cualesquiera del mismo. Por otra parte, para nuestro propsito vamos a emplear la conocida con el nombre de izquierda a derecha o de Bakis (figura 2.4), pues la idea se basa en reconocer cada lugar a partir de la potencia medida de cada AP del entorno de localizacin, segn un orden predefinido, con una estructura secuencial, tal y como se ver con mayor detalle en el punto tercero.
Cada sitio queda definido por un conjunto de estados igual al nmero de APs considerados durante el entrenamiento de un determinado entorno 23
Grupo I4
de localizacin (esto tambin ser abordado con mayor detalle en el punto tercero) ms dos. Estos ltimos dos estados mencionados son de tipo nulo y se denominan inicial y final, pues no emiten observacin alguna ni consumen ninguna unidad temporal, sino slo sirven de marcadores del inicio y el fin del listado de APs y sus potencias asociadas de un determinado lugar.
Figura 2.2. Diagrama de bloques del sistema reconocedor.
Figura 2.3. Ejemplo de modelo ergdico de tres estados.
24
Grupo I4
Figura 2.4. Ejemplo de modelo de Bakis o de izquierda a derecha de cuatro estados.
2.2
Teora de la Comunicacin
La figura 2.5 muestra un diagrama de la red utilizada por el sistema para la comunicacin. Observamos que existen tres tipos de equipos diferentes: equipos fijos (o mviles) localizadores, equipos localizables y un servidor central. Estos equipos se encuentran conectados entre s mediante conexin TCP, llevada a cabo de forma prctica en el prototipo con ayuda de la clase Socket de
JAVA.
Figura 2.5. Entorno de red empleado en la interconexin de los elementos del prototipo.
Servidor central: Es el mdulo encargado de conectar los otros

dos tipos de sistema a travs de Internet. Este mdulo est pen-
25
Grupo I4
Memoria de Proyecto (v1.) sado para ser instalado en un equipo con una IP pblica. Con esto podremos conseguir que, si los dos equipos cliente tienen conexin a Internet, el equipo localizador pueda localizar al equipo localizable desde cualquier lugar del planeta (siempre y cuando el equipo localizable est en el entorno apropiado de posicionamiento, por ejemplo, dentro de la escuela). Este servidor est implementado mediante threads en
JAVA,
por lo que podremos conectar
tantos equipos localizadores y localizables como sea necesario. Podemos observar en la figura 2.6 un pequeo resumen de la implementacin bsica de dicho servidor.
Figura 2.6. Diagrama reducido del funcionamiento del servidor central.
Localizador: Dicho equipo presenta dos conexiones TCP con el

servidor central: una es la conexin de datos y la otra es una conexin de control, la cual evita que los servicios queden bloquea-
26
Grupo I4
Memoria de Proyecto (v1.) dos por sufrir una prdida de conexin, as como tambin da informacin al servidor central de desconexiones de usuarios inesperadas. Realizamos dicha tarea haciendo una comprobacin de respuesta; si en cierto tiempo no se genera una respuesta de parte del cliente localizable, consideramos al cliente cado. Podemos observar en la figura 2.7 un pequeo resumen de la implementacin bsica de la funcionalidad del lado del equipo localizador en relacin a la comunicacin.
Figura 2.7. Diagrama reducido del funcionamiento del mdulo localizador en trminos de la comunicacin.
Localizable: En el prototipo actual este es el equipo que por

ahora implementa la funcionalidad de localizacin en s, por lo que la carga computacional de este es mayor que la de ningn otro dado que cada vez que recibe una peticin de localizacin debe calcular su propia posicin. En el futuro, este clculo recaer 27
Grupo I4
Memoria de Proyecto (v1.) sobre el servidor central. Este equipo presenta una conexin TCP de control de la conexin igual que la del equipo localizador. Dado que es ms sensible a posibles cadas de la conexin por potenciales cambios de punto de acceso a la red por desplazamiento del equipo mvil o por posibles cadas del AP actual, mediante un socket especial implementado en el puerto 50001 se realiza un sencillo test de conectividad para detectar posibles desconexiones no deseadas.
Figura 2.8. Diagrama reducido del funcionamiento del mdulo localizable en trminos de la comunicacin.
Si este equipo se desplaza una cantidad suficiente, perder la conexin con el punto de acceso. Si queremos conseguir un seguimiento del usuario localizable sin que este tenga que reconectarse manualmente al punto de acceso ms cercano segn su posicin una vez desplazado, nuestro entorno de localizacin, en este caso la
ETSIIT,
deber de implementar algn protocolo como WDS, el
cual nos permitira no perder la conexin en ningn punto, puesto 28
Grupo I4
Memoria de Proyecto (v1.) que este protocolo se encargara de reconectarnos a la red a travs del punto de acceso a la misma ms cercano. Podemos observar en la figura 2.8 un pequeo resumen de la implementacin bsica de la funcionalidad del equipo localizable en relacin a la comunicacin.
29
Grupo I4
3.
Estado del Prototipo

Este es el apartado central de la memoria, donde abordamos el esta-
do del prototipo en el momento de su presentacin. Se debe hacer hincapi en que el proyecto dista en gran medida de considerarse finalizado. Ms bien, por el contrario, la aplicacin programada hasta la fecha no es ms que una pequea introduccin que muestra su potencial efectividad. Continuando en una lnea de investigacin, complecin y mejoras bien definida, cuyas pautas se exponen en el ltimo punto de esta memoria, creemos que es posible alcanzar una gran precisin de reconocimiento con una resolucin aceptable sin que se deterioren las ventajas de este sistema que lo hacen especialmente atractivo gracias a su sencillez y coste adicional nulo frente a otras tecnologas.
Como se ha mencionado ya en diversas ocasiones, la solucin al problema de localizacin es exclusivamente software. La aplicacin final prototipo se conoce con el nombre de I4WLoc, cuyo smbolo es la cmara del ordenador HAL 9000 de 2001: Una Odisea en el Espacio.
Figura 3.1. Smbolo de I4WLoc.
I4WLoc consta de tres mdulos: cliente localizable, cliente localizador y servidor. Actualmente, del lado del cliente localizable se sitan las funcionalidades de front-end (extraccin y adaptacin de caractersticas basadas en la potencia de las seales WiFi del entorno en el que se site el dispositivo sobre el cual corra la aplicacin), de reconocimiento de la locali30
Grupo I4
zacin a partir del ambiente estadstico entrenado y de entrenamiento. Por otro lado, el mdulo servidor (el cual es susceptible de ser alojado en un servidor en Internet de acceso pblico), se encarga de conectar a los clientes del sistema con el fin de que los localizadores puedan realizar peticiones de localizacin de los usuarios localizables.
Todo el software se encuentra programado en el lenguaje orientado a objetos

JAVA.
La eleccin de este lenguaje radica, en buena parte, en la me-
jora de la portabilidad, pues los bytes de cdigo fuente pueden ser interpretados en cualquier mquina que posea una versin adecuada de la
JVM
(Ja-
va Virtual Machine). Sin embargo, actualmente, I4WLoc (nombre por el cual nos referiremos por defecto, de ahora en adelante, a la aplicacin del cliente localizable) slo puede ser ejecutado bajo un dispositivo con SO Windows debido al empleo de las pulacin de HMMs (netsh y
HTK, APIs
de medicin de potencia y de mani-
respectivamente), las cuales son llamadas
como procesos en un segundo plano a partir de sus ejecutables para Windows en este primer prototipo.
Figura 3.2. Dependencias de I4WLoc.
31
Grupo I4
El paso siguiente y necesario resulta de la integracin de las funcionalidades (y no necesariamente de las aplicaciones que las cubren actualmente) que estas herramientas cumplen en el propio cdigo de I4WLoc, llevndose al lado del servidor la capacidad de reconocimiento en s a partir de que este ltimo almacene el modelado estadstico del entorno de posicionamiento oportuno.
Una vez abrimos la aplicacin del cliente localizable podemos observar la ventana de la figura 3.3. En primer lugar se distingue en ella tres pestaas: Localizador, Entrenador y Conectar. Seleccionada la primera se tiene acceso a la interfaz para la estimacin de la localizacin actual del dispositivo sobre el cual corre la aplicacin cliente. No obstante, dicha estimacin deber de hacerse, como es lgico, en base a algn ambiente estadstico que modele el entorno de reconocimiento. Supuesto que ya se posee el entorno entrenado (por ejemplo, la
ETSIIT),
este puede ser cargado sin
ms que pulsar el botn situado en la esquina inferior derecha llamado Importar Entorno. Para poder importar un entorno de localizacin es preciso haberlo exportado previamente tras su entrenamiento como a continuacin especificaremos.
Figura 3.3. Ventana del programa tras ser iniciado.
32
Grupo I4
Actualmente slo es posible, sin intervencin manual, grabar y cargar un nico entorno de localizacin, aunque su generalizacin para hacerlo de forma automtica es inmediata, pudiendo tenerse distintos ambientes de posicionamiento intercambiables segn dnde nos encontremos. Puntualizar en este sentido que las opciones del men de la barra de herramientas se encuentran en este momento deshabilitadas. Tras ser importado el entorno de localizacin, el botn Obtener Posicin se habilita, permitiendo estimar la posicin actual del dispositivo sobre el cual corre el cliente. La otra forma de habilitar dicho botn es tras la finalizacin del entrenamiento de un determinado entorno de localizacin. Con el fin de llevar a cabo esta tarea, deberemos pulsar sobre la pestaa Entrenador. La figura 3.4 recoge una captura de la interfaz de usuario habilitada para el entrenamiento de un ambiente de posicionamiento.
Figura 3.4. Ventana del entrenador tras iniciar el programa.
Secuencialmente, tras posicionarnos en cada uno de los lugares que queramos que participen del entorno de localizacin, pulsaremos el botn Aadir Localizacin tras escribir un nombre identificativo para cada lugar. Esto puede hacerse para todos los sitios que deseemos y cuantas veces deseemos por un mismo sitio. De hecho, una buena variedad de caracterizaciones de 33
Grupo I4
un mismo lugar con factores variables (diferentes horarios, condiciones meteorolgicas, etc) potenciar la precisin en el posterior reconocimiento del sitio. Tras haber aadido todas las caracterizaciones de todas y cada una de las localizaciones del ambiente de posicionamiento, slo habr de pulsarse el botn Entrenar con el fin de generar el modelado estadstico del entorno de localizacin. El espacio inferior de la ventana de la aplicacin se destina a la muestra de informacin textual durante el proceso de entrenamiento. Tras finalizar este, el cuadro de informacin recoge el xito o precisin del modelo, dato que indica si los patrones introducidos para la generacin del ambiente estadstico se han clasificado correctamente segn el sitio al que realmente pertenezcan. Por limitaciones de programacin, actualmente es necesario introducir etiquetas escritas completamente en maysculas para cada localizacin y, al menos, estas han de ser introducidas en orden alfabtico durante la primera toma de datos.
Figura 3.5. Diagrama de estados del cliente de I4WLoc.
34
Grupo I4
Posterior a la inclusin de todos los lugares que compondrn la regin de localizacin ya s pueden incluirse nuevas caracterizaciones tanto en nmero como en el orden deseado. A partir de entonces, tambin se abre la opcin de exportar el ambiente de posicionamiento sin ms que pulsar sobre el botn Exportar Entorno. Dicha exportacin consiste en el almacenaje en un fichero de texto de todos los APs considerados en el entorno de localizacin en un orden particular tal que se fija la estructura posterior del fichero de caractersticas que construir para la estimacin de la posicin. Por tanto, al importar el entorno, lo nico que se hace es leer dicho archivo con el fin de saber cmo mapear sobre los ficheros de caractersticas los datos recin medidos para la recuperacin de la localizacin actual.
Sin tener en cuenta la relacin con el mdulo servidor, la figura 3.5 muestra el diagrama de estados de la aplicacin cliente de I4WLoc segn el punto en el que se encuentra el prototipo en la actualidad.
En cuanto al servidor, es importante notar que dicho mdulo no tiene una interfaz de usuario dado que no es necesario. La aplicacin servidora se instala en un servidor con IP pblica, siendo transparente al usuario. Los mensajes procedentes de la misma y mostrados en la consola del panel propio asociado a la pestaa Conectar nos permiten monitorizar el funcionamiento de la conexin as como conocer las peticiones sobre nuestra situacin por parte de otros usuarios localizadores. La figura 3.6 muestra el resultado de una conexin llevada a cabo con xito.
35
Grupo I4
Figura 3.6. Mensajes mostrados por el servidor central.
De otra parte tambin se ha generado un pequeo mdulo destinado nicamente a la tarea de la obtencin de la posicin de otros usuarios mviles. Este pequeo mdulo es susceptible de ser ejecutado en un equipo fijo de tal modo que tras conectarse a la direccin IP pblica y puerto (50000 por defecto) del servidor, se tiene acceso a una interfaz donde se lista a los usuarios que estn haciendo uso del sistema en tiempo real y que son susceptibles de ser localizados. La figura 3.7 recoge una captura de la ventana que se le muestra al usuario tras ejecutar la aplicacin cliente localizadora.
Figura 3.7. Ventana tras ejecutar el mdulo cliente localizador.
La figura 3.8 recoge la ventana que se le muestra al usuario tras conectarse al servidor satisfactoriamente. La parte izquierda recoge el listado de clientes localizables que estn usando el sistema. Haciendo doble clic sobre alguno de ellos es posible observar inmediatamente a la derecha la localizacin estimada tras el envo de la peticin de localizacin al servidor desde
36
Grupo I4
este mdulo, la cual a su vez es reenviada al cliente mvil cuya posicin se desconoce (el cual estima su posicionamiento).
Figura 3.8. Ventana del mdulo cliente localizador tras conectarse al servidor.
En la parte derecha de la anterior ventana es posible monitorizar visualmente los procesos de comunicacin.
Figura 3.9. Mdulo de conexin en la aplicacin cliente del usuario localizable.
Finalmente, tras pinchar en la pestaa Conectar de la aplicacin cliente del usuario localizable (figura 3.9), es posible conectarse al sistema y monitorizar visualmente la secuencia de procesos de comunicacin llevada a cabo.
37
Grupo I4
Figura 3.10. Diagrama de estados de la aplicacin cliente a nivel de comunicacin.
Figura 3.11. Diagrama de estados del mdulo cliente localizador.
Las figuras 3.10 y 3.11 recogen respectivamente los diagramas de estados de la aplicacin cliente del usuario localizable a nivel de comunica38
Grupo I4
cin (a nivel de funcionamiento interno ya se expone en la figura 3.5) y del mdulo cliente localizador.
Sumergindonos en mayor medida mientras abandonamos la descripcin a nivel de usuario, debemos especificar que la aplicacin central cliente (la que emplea un equipo localizable) consta de cuatro clases: I4WLoc, Localiza, Entrena y Sitio. La primera de ellas implementa la interfaz de usuario y gestiona las acciones que deben ser realizadas a partir de la interaccin de la persona que emplee el mdulo cliente. La segunda de ellas incluye mtodos para el testeo de la localizacin dado un entorno de reconocimiento, para el cmputo de coeficientes derivados de orden sucesivo (empleado para el clculo de coeficientes delta y aceleracin en los trminos que a continuacin se especifican), para la generacin de la estructura de fichero de caractersticas, para la generacin de ficheros de caractersticas, para el clculo de la media de una secuencia o de su varianza, etc. La clase Entrena alberga mtodos para la adicin de localizaciones de entrenamiento as como para ejecutar secuencialmente las sentencias que nos llevan a obtener un ambiente de localizacin a travs de
HTK.
Finalmente, Sitio nos
ayuda a definir unos mnimos para la generacin de objetos genricos que alberguen de forma temporal, previo al entrenamiento, los datos asociados a cada una de las caracterizaciones de cada uno de los lugares propios del ambiente de reconocimiento. Esta ltima clase junto con algunos mtodos propios de Localiza es lo que compone el front-end.
Para finalizar el captulo, se va a relacionar todo lo anterior con el proceso pormenorizado de reconocimiento de principio a fin. Distinguimos
39
Grupo I4
tres acciones principales: preparacin de los datos (cometido que cumple el front-end), entrenamiento del sistema y evaluacin.
Los principios bsicos del reconocimiento basado en HMMs fueron expuestos en el captulo segundo. A partir de ellos explicamos en los tres subapartados siguientes la secuencia metdica de pasos llevada a cabo para la generacin del entorno de reconocimiento de la localizacin as como para la evaluacin apoyada sobre el mismo. Sin embargo, es preciso hacer el inciso de que no se har uso de HMMs discretos (que fue la teora desarrollada), sino de HMMs continuos donde la probabilidad de emisin de una determinada observacin por estado se modela segn una distribucin gaussiana. En cualquier caso, toda la teora expuesta es vlida, siendo este caso particular extrapolable a partir de ella.
Figura 3.12. Tipo y topologa de un HMM.
Como se esboz al final del captulo segundo, una vez conocidos todos los APs que participan de la definicin de un entorno de localizacin, para cada lugar se genera un HMM cuyo nmero de estados es igual a dicho nmero de APs ms dos (los estados inicial y final). Como ahora se explica a continuacin, por cada caracterizacin se lleva a cabo una rfaga de medidas de la potencia de seal WiFi percibida de cada uno de los pun40
Grupo I4
tos de acceso. Esta rfaga consiste por defecto en la ejecucin de cinco medidas consecutivas. Supngase ahora que, por sencillez, un entorno de localizacin est definido por tres puntos de acceso: AP1, AP2 y AP3. Y considrese que en un instante y lugar dados, se obtienen las siguientes medidas que caracterizan el sitio en cuestin teniendo en cuenta que se llevar a cabo una rfaga de cinco medidas consecutivas:
AP AP11 AP12 AP13 AP14 AP15 AP21 AP22 AP23 AP24 AP25 AP31 AP32 AP33 AP34 AP35
Potencia percibida 70% 71% 70% 71% 70% 38% 38% 39% 39% 38% 55% 56% 55% 55% 56%
Tabla 3.1. Ejemplo de niveles de potencia percibidos en un lugar e instante dados.
La justificacin del nmero de estados empleado para la caracterizacin de la localizacin se asienta en la tabla 3.1 y la figura de ejemplo 3.6 da una nocin grfica de ello que facilita su comprensin. Dado que el entrenamiento incluye una etapa de alineamiento forzado en la que el algoritmo de Viterbi agrupa subconjuntos de vectores de caractersticas (los cuales, como 41
Grupo I4
ahora veremos, se componen de un coeficiente de potencia, otro delta y otro aceleracin) en estados para constituir una gaussiana que explique la probabilidad de generacin de smbolo por cada uno de dichos estados, al igualar el nmero de estos ltimos al de APs del entorno de localizacin estaremos asegurando que, aproximadamente, por las caractersticas del algoritmo de Viterbi, cada gaussiana constituida para cada estado vendr definida aproximadamente por la media de la rfaga de medidas de cada AP y la varianza constituida a partir de las desviaciones respecto de la media segn la contribucin de ms ficheros de caractersticas que representen la misma localizacin. Es decir, cada estado del HMM de cada localizacin centrar su emisin en la potencia media percibida de un determinado AP en un lugar concreto, y su varianza responder segn vare la potencia percibida de ese mismo AP y en ese mismo lugar pero en otras condiciones distintas (repeticin de la caracterizacin a un horario distinto, con condiciones meteorolgicas distintas, etc). De esta forma ganamos una gran precisin respecto de si ussemos nicamente una gaussiana para todo el bloque de medidas, lo cual puede llevar a equvocos y a un entrenamiento y reconocimiento nefastos por una potencial similitud de los modelos finales. El resto de la lectura del captulo facilitar la comprensin de esta idea, pudindose comprobar lo expuesto a partir de la observacin del fichero de definiciones de HMMs generado al finalizar el entrenamiento, hmmdefs.
3.1
Preparacin de los datos
De esta primera etapa se encarga el front-end, el cual, como hemos dicho, se encuentra distribuido entre la clase Sitio y algunos mtodos de la clase Localiza. Tras situarnos en cada una de las localizaciones para carac42
Grupo I4
terizar los APs que nos iluminan y pulsar el botn de Aadir Localizacin, se desencadena un proceso consistente en una rfaga de, por defecto, cinco mediciones de la potencia de las diferentes seales WiFi percibidas por la interfaz de red inalmbrica de la tarjeta del dispositivo llamando en un segundo plano al ejecutable netsh de la forma,
netsh wlan show networks mode = bssid > Lecturax.txt,
donde x va del 1 al 5 y representa la posicin ocupada en la rfaga de medidas. De esta forma exportamos las cinco mediciones a cinco ficheros de texto que podremos manipular a continuacin cmodamente. Estos ficheros son ledos secuencialmente, de donde se extraen las BSSIDs (direcciones fsicas de los puntos de acceso) y sus niveles de potencia asociados, los cuales representa netsh del 0% al 100%. Con esta informacin se crea un nuevo objeto de la clase Sitio que alberga temporalmente esta caracterizacin del lugar. Una vez realizadas todas las caracterizaciones de todos los sitios el nmero oportuno de veces, se pulsar el botn Entrenar pero, previo al proceso de entrenamiento en s, habremos de cerrar la fase de preparacin de los datos, por lo que se lleva a cabo una ejecucin secuencial de mtodos que se encargan de ello. El primer paso es estudiar cules son todos los APs que participan del entorno de localizacin. Para ello, en primer lugar, se elimina la contribucin de aquellos puntos de acceso que no aparezcan, dado un sitio concreto, en todas las mediciones, pues suelen llevar a problemas durante el posterior reconocimiento por apariciones espurias que dificultan la estimacin. Sin embargo, en el punto quinto de esta memoria se considera que una medida interesante que evaluar en la lnea de trabajo futuro es relajar este umbral para permitir el paso de puntos de acceso que, aunque no aparezcan siempre durante el entrenamiento de un mismo lugar, 43
Grupo I4
lo hagan de forma frecuente. Este tipo de puntos de acceso suele detectarse de forma irregular por baja potencia de seal, pudiendo contribuir en diferentes localizaciones y cuya aparicin o desaparicin produce un incremento de estimaciones errneas. Una vez seleccionados todos los APs de la regin de posicionamiento en base a la anterior consideracin, se procede a ordenarlos en una lista para establecer una estructura de fichero de caractersticas de modo que todas las localizaciones posean una distribucin de datos comparable. A continuacin se genera un vector modelo inicializado con ceros cuya dimensin es igual al nmero de medidas por rfaga (cinco por defecto) por el nmero de APs total del entorno de localizacin. Por cada caracterizacin de cada localizacin, la cual se encuentra plasmada en un objeto de la clase Sitio, se procede al relleno del anterior vector con los datos de potencia anteriormente ledos. De esta forma hemos generado por cada medida un vector de potencias representante de cada localizacin, donde a los APs de la regin de posicionamiento que no dan cobertura al dispositivo en un determinado lugar, se les asocia un nivel de potencia 0 gracias a la inicializacin del vector modelo.
Tras la obtencin de la caracterstica de potencia por cada una de las localizaciones, se procede, a partir de ella, al clculo de los coeficientes delta y aceleracin segn < ,
( 2
>
(3.1)
donde es el tamao de la ventana (el cual toma por defecto el valor 2) y es la muestra del vector de potencias primitivo acontecida en el instante 44
Grupo I4
. De esta forma obtendremos tres secuencias de datos, cada uno de ellas de longitud , de la forma: =( , , , ), , ),
(3.2a)
= = ( , ,
(3.2b)
= = ( ) = ( ), ( ), ( ) , ( ) , donde
(3.2c)
es igual al nmero de medidas por rfaga (cinco por defecto) por el
nmero de APs total del entorno de localizacin. De este modo, podemos confeccionar la siguiente matriz de caractersticas, o conjunto de vectores de observaciones, por cada una de las localizaciones: =( donde = ( ), ( ), ( ) , 1,2, , . , ,, ),
(3.3)
(3.4)
Debemos de almacenar en archivos con un formato adecuado las anteriores observaciones con el fin de que
HTK
pueda manipularlas durante el
entrenamiento de un entorno estadstico o durante su evaluacin. El formato de fichero seleccionado es el conocido con el nombre homnimo,
HTK.
Este consiste en el almacenaje del vector de observaciones precedido de una
45
Grupo I4
cabecera. Cada una de las muestras es un vector de nmeros en punto flotante de 4 bytes. La cabecera es de 12 bytes de longitud y contiene los datos referenciados en la tabla 3.2.
Parmetro Nmero de muestras Perodo de muestreo (x100ns) Bytes por muestra Id. del tipo de muestra
Id. nSamples sampPeriod sampSize parmKind
Longitud Entero 4 bytes Entero 4 bytes Entero 2 bytes Entero 2 bytes
Por defecto
400000 12 777
Tabla 3.2. Formato de cabecera de un fichero HTK.
El nmero de muestras se corresponde con el valor
. Este parmetro es
almacenado como un entero de 4 bytes. Seguidamente se debe de guardar el perodo de muestro en unidades de 100ns. Dado que esto no tiene ninguna importancia en nuestro entorno de reconocimiento, se graba la cifra simblica 400000 por defecto en este campo como un entero de 4 bytes. El nmero de bytes por muestra tambin es constante; como tenemos 3 muestras de caractersticas distintas por cada observacin del vector de caractersticas, y dado que cada una de estas se almacena, como ya hemos mencionado, como un nmero en punto flotante de 4 bytes, el nmero de bytes por muestra se corresponde con 12. Finalmente, el identificador de tipo de muestra apunta a qu tipo de caractersticas se encuentran almacenadas en la matriz. Esta cifra tambin es constante puesto que siempre estamos almacenando potencia de seal WiFi y sus coeficientes delta y aceleracin asociados. Este valor se extrae de la suma 9+256+512, donde 9 indica que el parmetro ha sido definido por el usuario (la potencia extrada del frontend en nuestro caso), 256 se refiere a los coeficientes delta y 512 a los aceleracin. Las tablas 3.3 y 3.4 recogen las listas de los parmetros bsicos y 46
Grupo I4

HTK.
derivados junto a los identificadores conocidos por
Los primeros se
codifican con 6 bits mientras que los segundos hacen lo propio con 10 bits.
Id. Numrico 0 1 2 3 4 5 6 7 8 9 10
Id. Textual WAVEFORM LPC LPREFC LPCEPSTRA LPDELCEP IREFC MFCC FBANK MELSPEC USER DISCRETE
Descripcin Forma de onda Coeficientes LPC Coeficientes LPC de reflexin Coeficientes cepstrales LPC Coeficientes cepstrales LPC ms delta Coeficientes LPREF como enteros de 16 bits Coeficientes MFCC Banco de filtros Mel logartmico Banco de filtros Mel lineal Definidos por el usuario Vector de datos cuantizados
Tabla 3.3. Identificadores de cabecera de los parmetros bsicos.
Id. Textual _E _N _D _A _C _Z _K _O
Id. Octal 000100 000200 000400 001000 002000 004000 010000 020000
Id. Decimal 64 128 256 512 1024 2048 4096 8192
Descripcin Energa Energa absoluta suprimida Coeficientes delta Coeficientes aceleracin Datos comprimidos Coeficiente esttico de media cero Comprobacin CRC Primer coeficiente cepstral
Tabla 3.4. Identificadores de cabecera de parmetros derivados y otros.
La estructura de mapeo o layout del fichero
HTK
se puede observar
en la figura 3.13, aunque esta ya se dedujo de (3.4). En primer lugar se almacenan los parmetros bsicos para, posteriormente, agregar el coeficiente 47
Grupo I4
de energa si lo hubiese (no siendo nuestro caso). Finalmente, en el caso de definirse, se sitan a la cola, respectivamente, los coeficientes delta y aceleracin de los parmetros bsicos y de la energa.
Figura 3.13. Layout del vector de parmetros en el formato de fichero HTK.
Una vez se dispone de todo el conjunto necesario de ficheros
HTK
ca-
racterizando las diferentes localizaciones oportunas, se puede proceder con la evaluacin en base a un entorno estadstico ya existente con la ayuda del algoritmo de Viterbi implementado en el mdulo HVITE de
HTK
(botn Ob-
tener Localizacin), en el caso de querer llevar a cabo el reconocimiento, o continuar con la preparacin del entrenamiento del sistema (continuacin del proceso tras haber presionado el botn Entrenar).
3.2
Entrenamiento del sistema
Para el entrenamiento con
HTK
partimos de la posesin de todos los
ficheros de caractersticas necesarios segn el fundamento del subapartado anterior. Estos almacenan los parmetros de todas y cada una de las localizaciones con los que se entrenar cada uno de los modelos. Cada uno de estos ltimos ser representante de un determinado lugar, contribuyendo a
48
Grupo I4
su entrenamiento varias caracterizaciones de dicho sitio en diferentes circunstancias ambientales.
A continuacin ha de definirse un fichero en el que se patenta la estructura del reconocimiento de la posicin. Este presenta una topologa muy sencilla:
$loc = LUGAR1 | LUGAR2 | LUGAR3; ( SENT-START ( $loc ) SENT-END )
Como se puede observar, consiste en la definicin de la variable loc a partir del conjunto de localizaciones que el reconocedor ser de capaz de recuperar (LUGAR1, LUGAR2 y LUGAR3). La segunda lnea establece la descripcin de la estructura del reconocimiento, consistente, simplemente, en la averiguacin de la posicin a partir de la estructura de potencias de seal WiFi delimitada entre un inicio y un final (SENT-START y SENT-END, respectivamente).
La anterior representacin de alto nivel es permitida por
HTK
para
facilitarle el trabajo al desarrollador. Sin embargo, esta herramienta requiere que sea definida una red, en este caso, de localizaciones, haciendo uso de una notacin de bajo nivel conocida con el apelativo de
HTK
Standard Lat-
tice Format (SLF). En ella, cada instancia de posicionamiento es listada explcitamente. Esta red puede crearse automticamente a partir del anterior fichero mediante la utilizacin de la herramienta HPARSE.
49
Grupo I4
Figura 3.14. Ejemplo de estructura de reconocimiento.
A continuacin se crea un archivo de texto con las distintas localizaciones susceptibles de ser reconocidas, incluyendo as mismo las referencias
SENT-START
y SENT-END. Tambin se genera otro fichero de texto conteniendo
la misma lista que el anterior pero agregando dos columnas a su derecha de la forma
LUGAR1 LUGAR2 LUGAR3 SENT-END SENT-START
[Title1] [Title2] [Title3] [] []
lugar1 lugar2 lugar3 sil sil
Su significado es que, por ejemplo, la localizacin LUGAR1 se corresponder con un futuro HMM apuntado por el nombre lugar1. La cadena de texto situada entre corchetes, Title1, especifica la salida que le ser mostrada al usuario en el caso de reconocer LUGAR1. Si esta cadena se omite, al usuario se le muestra directamente, por ejemplo, LUGAR1. Las entradas SENT-START y
SENT-END
referencian al futuro HMM sil, un estado simblico cuya inclu-
sin es necesaria y tiene su sentido en aplicaciones de reconocimiento del habla. No obstante, su reconocimiento no produce ningn smbolo de salida, por lo que no supone ningn obstculo. 50
Grupo I4
Una vez se poseen los dos ficheros anteriores se ejecuta una llamada al mdulo HDMAN con el fin de generar otro archivo de texto conteniendo la correspondencia entre el texto referenciante de cada una de las localizaciones y el nombre que apuntar posteriormente a su HMM, tal y como se muestra a continuacin
LUGAR1 LUGAR2 LUGAR3 SENT-END SENT-START
lugar1 lugar2 lugar3 sil sil
Con el fin de entrenar un conjunto de HMMs, a cada fichero de caractersticas se le ha de asociar la transcripcin correspondiente a la localizacin que representa. Segn esta premisa, se ha de generar un archivo con el set completo de transcripciones con la siguiente estructura
#!MLF!# */l1.lab LUGAR1 . */l2.lab LUGAR1 .
()
*/l10.lab LUGAR1 . */l11.lab LUGAR2 .
()
51
Grupo I4
La primera lnea del archivo lo identifica como un Master Label File (MLF). En el anterior ejemplo se ha supuesto que existe una serie de ficheros de caractersticas en formato
HTK,
nombrados como l1, l2, , l30, don-
de los diez primeros se han generado a partir de diez caracterizaciones diferentes de LUGAR1, los diez siguientes a partir de otras diez caracterizaciones de LUGAR2 y los diez ltimos a partir de otras diez caracterizaciones de LUGAR3.
Con ayuda de HLED se crea un fichero, a partir del anterior de tipo MLF, en el que cada transcripcin de cada localizacin es sustituida por la secuencia de referencias a futuros HMMs segn la estructura de reconocimiento explcita en el primer archivo generado. Este fichero resultante es de la forma
#!MLF!# */l1.lab sil lugar1 sil . */l2.lab sil lugar1 sil .
()
*/l10.lab sil lugar1 sil . */l11.lab sil lugar2
52
Grupo I4
sil .
()
Para generar lo anterior, HLED utiliza un script conteniendo los siguientes comandos
EX IS sil sil DE sp
El comando de expansin, EX, reemplaza cada localizacin del fichero de transcripciones por el correspondiente nombre del futuro HMM asociado. De otra parte, el comando IS inserta sendos modelos sil al inicio y al final de cada una de las repeticiones para entrenamiento. DE elimina el futuro modelo sp de las definiciones textuales previas (modelo necesario cuya razn de ser se encuentra en un entorno de reconocimiento del habla, aunque no obstaculiza a nuestro propsito, siendo completamente inocuo).
Seguidamente ha de crearse un script que liste todos los ficheros de caractersticas participantes del entrenamiento. Continuando en la lnea del ejemplo seguido, este archivo tendra la siguiente estructura
l1 l2
()
l30
Una vez realizado todo lo anterior, podemos comenzar con la creacin de un conjunto bien entrenado de HMMs segn distribuciones gaussia53
Grupo I4
nas simples, como ya se introdujo. El punto de comienzo es el conjunto de HMMs idnticos (siendo cada uno de ellos un futuro representante de una localizacin distinta) definido a partir de valores de media y varianza iguales. Posteriormente, estos modelos iniciales son reentrenados en distintas ocasiones (los parmetros definitorios de las distribuciones gaussianas de cada estado son reestimados en base al algoritmo de Baum-Welch) y manipulados (por ejemplo, al llevarse a cabo en cierto punto el alineamiento forzado de los datos de entrenamiento mediante la aplicacin del algoritmo de Viterbi) hasta obtener el conjunto final usable para el proceso de evaluacin.
Para comenzar se define un HMM prototipo. Los parmetros del mismo no son importantes, siendo su propsito la definicin de su topologa. Esta es, como se coment, de izquierda a derecha y tambin, como sabemos, el nmero de estados de cada uno de ellos es igual al nmero de APs considerado para caracterizar el entorno de localizacin. Por tanto, este fichero prototipo ha de generarse de forma dinmica durante el entrenamiento en funcin del anterior parmetro. Un ejemplo de modelo prototipo de 5 estados para el cumplimiento de nuestro cometido es el siguiente
~o <Vecsize> 3 <USER_D_A> ~h "prototipo" <BeginHMM> <NumStates> 5 <State> 2 <Mean> 3 0.0 0.0 0.0 <Variance> 3 1.0 1.0 1.0 <State> 3 <Mean> 3
54
Grupo I4

0.0 0.0 0.0 <Variance> 3 1.0 1.0 1.0
<State> 4 <Mean> 3 0.0 0.0 0.0 <Variance> 3 1.0 1.0 1.0 <TransP> 5 0.0 1.0 0.0 0.0 0.0 0.0 0.6 0.4 0.0 0.0 0.0 0.0 0.6 0.4 0.0 0.0 0.0 0.0 0.6 0.4 0.0 0.0 0.0 0.0 0.0 <EndHMM>
De la primera lnea se observa que la longitud de cada una de las observaciones es de 3 muestras, correspondientes a los 3 parmetros ya conocidos y explicitados tambin a continuacin mediante el cdigo <USER_D_A> (datos definidos por el usuario (potencia de seal WiFi), coeficientes delta y aceleracin).
Con la herramienta HCOMPV se recorre todo el conjunto de ficheros de caractersticas con el fin de computar su media y varianza globales y generar as un nuevo modelo prototipo con estos valores recin calculados. Simultneamente el mdulo genera una macro conocida con el nombre de
vFloors
en la que se almacena una cota inferior de la varianza global (con-
cretamente de 0.01 veces el valor de este ltimo parmetro). Dicha macro es un vector de valores que sern usados con el fin de imponer una cota inferior para las varianzas estimadas en subsiguientes pasos.
55
Grupo I4
A partir del nuevo prototipo generado, se crea un fichero de tipo Master Macro File (MMF) llamado tpicamente hmmdefs, conteniendo una definicin primitiva de HMM por cada una de las localizaciones diferentes que entrenan el sistema ms sil de la forma
~h lugar1 <BeginHMM>
()
<EndHMM> ~h lugar2 <BeginHMM>
()
<EndHMM>
()
El formato de un MMF es similar al de un MLF, manteniendo el propsito de evitar tener un gran nmero de ficheros individuales para la definicin de los distintos HMMs del entorno estadstico. El modelo sil se redefine a partir del prototipo tomando un total de tres estados de otro modelo cualquiera, pues este se define tri-estado (tres que emiten observacin ms los dos extremales que no lo hacen). Debido a la forma de programar en el prototipo la construccin del modelo sil, es imposible entrenar un entorno estadstico con menos de tres puntos de acceso. Aunque esto es inmediatamente corregible de forma trivial, por sencillez, y dado que un entorno de dichas caractersticas (con tan pocos puntos de acceso) no tendra ninguna validez, se ha preferido no modificar a priori.
Previo a la primera reestimacin de los parmetros de los diferentes modelos, es necesario tambin generar un fichero denominado macros. Este
56
Grupo I4
contiene una macro de opciones globales (definiendo el tipo de parmetros ms la longitud del vector observable) ms la cota inferior de la varianza del fichero vFloors, de la forma
~o <VecSize> 3 <USER_D_A> ~v varFloor1 <Variance> 3 3.988e-004 8.172e-002...
Ahora ya es posible reestimar, mediante la ayuda del mdulo HEREST, los parmetros de los HMMs en hmmdefs. De importancia resulta la fijacin de los umbrales de poda durante el entrenamiento. Estos lmites definen el rango de alineamientos de cada estado que el algoritmo Adelante-Atrs incluye en su cmputo. Durante todos los entrenamientos posteriores se hace uso de los valores por defecto; el umbral se fija inicialmente en 250.0, pero, en caso de que falle la reestimacin para cualquiera de los ficheros de caractersticas, este primer valor se incrementa en 150.0 y se repiten los clculos. Este proceso se rehace hasta que el fichero de caractersticas causante del contratiempo sea procesado o se exceda el lmite superior prefijado en 1000.0. En este ltimo caso, se presupone que debe de existir un serio problema con el archivo de entrenamiento, por lo que este queda descartado.
Seguidamente, la reestimacin con HEREST se ejecuta dos veces ms.
El siguiente paso consiste en la adicin de transiciones extra desde los estados 2 al 4 y desde los estados 4 al 2 en el modelo sil. La idea aqu
57
Grupo I4
es hacerlo ms robusto mediante la permisin a los estados individuales para que absorban los diversos ruidos impulsivos presentes en los datos de entrenamiento.
En este punto tambin es preciso generar un modelo sp que, aunque como se observa y ya se ha comentado, no se incluye ni se incluir puesto que no tiene sentido alguno en el contexto del reconocimiento de la localizacin, es imprescindible, como mero mecanismo, para la mejora mencionada de la robustez del modelo sil. El HMM sp se incluye en el ltimo fichero reestimado de definicin de los HMMs mediante la copia del estado central del modelo sil, de tal forma que el HMM sp es monoestado. Tambin es necesario modificar consecuentemente su matriz de transiciones.
A continuacin se crea un script con el siguiente contenido
AT 2 4 0.2 {sil.transP} AT 4 2 0.2 {sil.transP} AT 1 3 0.3 {sp.transP} TI silst {sil.state[3],sp.state[2]}
El comando AT agrega transiciones a las matrices dadas, mientras que el comando TI crea el estado enlazado silst. Los parmetros de este estado enlazado se almacenan en el fichero de definiciones de los HMMs.
Para hacer efectivas las rdenes del anterior script en el sentido explicado en el anterior prrafo, se hace uso del mdulo HHED.
58
Grupo I4
Finalmente, otro par de pasos de reestimacin de los parmetros de los modelos con HEREST son llevados a cabo a partir del fichero de definiciones modificado.
Con el fin de realinear los datos de entrenamiento se puede hacer uso de la herramienta de reconocimiento HVITE, la cual implementa el algoritmo de Viterbi. Este mdulo restablecer, de forma similar a como ya hizo HLED antes de ejecutar ninguna reestimacin de parmetros de los diferentes HMMs, la asociacin, para cada fichero de caractersticas, entre las observaciones y los estados dentro del modelo siguiendo un criterio de optimizacin. En este punto se consigue que cada gaussiana en cada estado represente la probabilidad de emisin de smbolo centrada en la potencia media percibida del punto de acceso que el estado represente para un HMM o, equivalentemente, una localizacin dada.
Para terminar el entrenamiento del entorno estadstico, se repiten dos nuevas reestimaciones de los HMMs con el mdulo HEREST. El ltimo fichero de definiciones ser el utilizado para el reconocimiento durante la etapa de evaluacin.
Principalmente el mtodo de entrenamiento de la clase Entrena es el que lleva a cabo todo el anterior proceso paso a paso. Sin embargo, parte del mismo se adelanta durante la adicin de una nueva localizacin para posterior entrenamiento, reduciendo as el tiempo de cmputo posterior.
59
Grupo I4 3.3 Evaluacin
Una vez el ambiente de reconocimiento ha sido creado, se puede proceder a evaluar si este es til para el posterior trabajo mediante la realizacin de un test cerrado que nos indica cmo se clasifican los datos de entrenamiento en los distintos modelos generados. Ello se lleva a cabo con la ayuda del mdulo HRESULTS. Sin embargo, previamente hemos de ejecutar la herramienta HVITE para llevar a cabo el reconocimiento a partir del script con todos los ficheros de caractersticas que han participado en el entrenamiento as como del ltimo archivo hmmdefs. La salida de la ejecucin del anterior mdulo ser un Master Label File del que hace uso HRESULTS,
junto con otro MLF que contiene la transcripcin de cada fichero de
caractersticas, para mostrar por pantalla los resultados del test cerrado, tal y como se ejemplifica en la figura 3.15. Esta informacin es mostrada en la consola de entrenamiento del mdulo entrenador tras finalizar el proceso.
Figura 3.15. Ejemplo de salida de HRESULTS para un test cerrado. En ella se observa una precisin del 100% en el reconocimiento de los datos de entrenamiento, por lo que el entorno estadstico, a priori, es til para ser empleado.
Para testear futuras localizaciones representadas por ficheros de caractersticas en formato

HTK
generados tras pulsar el botn Obtener Locali-
zacin en los trminos explicados en el punto de preparacin de los datos, el procedimiento es anlogo a lo presentado en el anterior prrafo, con la diferencia de que no es necesario emplear el mdulo HRESULTS as como 60
Grupo I4
que es preciso generar previamente el script que contenga el nombre o la lista de ficheros de caractersticas que se desea reconocer, el cual, por defecto, ya se encuentra preparado.
61
Grupo I4
4.
Test y Resultados
Tras la dejacin del prototipo en el estado expuesto en el anterior
punto, se procedi a evaluar su precisin y rendimiento en un entorno reducido enmarcado en la

ETSIIT.
Con dicho fin, se seleccionaron nueve locaACCESO,
lizaciones al azar, cuyos identificadores son, por orden alfabtico:
AULARIO0, AULARIO1, AULARIO2, AULARIO3, BIBLIOTECA, CAFETERIA, DESPACHO
HALL.
Estos nueve puntos de posicionamiento en el interior de la
escuela se encuentran situados sobre los mapas proporcionados con la situacin de los APs para una mayor representatividad en la figura 4.1.
El entrenamiento consisti en capturar un total de cinco ficheros de caractersticas por cada localizacin en distintos instantes de tiempo a lo largo de una maana nublada y en un perodo de, aproximadamente, dos horas. Se observ un problema asociado a la lentitud de la estabilizacin de la respuesta para cualquier sitio al que recin se llega. Es decir, dado un traslado de posicin hacia un nuevo lugar, a travs de la herramienta de medicin de potencia WiFi (netsh), se puede observar un cambio progresivo y excesivamente lento hasta medir correctamente las condiciones del nuevo entorno (nuevos puntos de acceso y sus potencias de seal asociadas). Desconocemos cul es el motivo por el que este hecho acontece pero, sin duda, es el principal problema y reto que se plantea para la mejora sustancial del sistema. Teniendo esto en cuenta, se hubo de esperar, al llegar a un nuevo lugar para su caracterizacin, un tiempo aleatorio suficientemente amplio como para poder observar correctamente las nuevas condiciones del sitio.
62
Grupo I4
Figura 4.1. Situacin de los nueve puntos de test en la escuela. Los planos se corresponden, de izquierda a derecha y de arriba a abajo, con planta stano, planta baja, planta primera, segunda y tercera.
63
Grupo I4
Como se ha dicho, dado que se recogieron un total de cinco caracterizaciones en diferentes instantes temporales por una misma localizacin, y puesto que se entrenaron nueve localizaciones en el entorno de la escuela, se hubo de generar cuarenta y cinco ficheros de caractersticas. El tamao de este conjunto de entrenamiento result ser de 227kB, siendo desechable una vez constituido el modelado estadstico del entorno. La figura 4.2 muestra cmo la consola de informacin del mdulo entrenador presenta una precisin (clasificacin correcta de los patrones introducidos) del 100% por lo que, a priori, el ambiente estadstico generado es perfectamente til para su utilizacin.
Figura 4.2. Resultado del entrenamiento del modelo de testeo en la ETSIIT.
Excluyendo los ficheros de caractersticas, para este entorno, el programa gener 10.5MB de datos, de los cuales slo son tiles para el posterior reconocimiento 1.03MB, por lo que una mejora inmediata del sistema puede ser el borrado automtico de los datos innecesarios para su posterior empleo, reduciendo as el consumo prescindible de recursos.
A continuacin se export el entorno, con el fin de que pudiera ser empleado posteriormente, y se llev a cabo un test consistente en el recono64
Grupo I4
cimiento de cada localizacin del ambiente hasta en un total de tres ocasiones (veintisiete estimaciones en total) y en un orden aleatorio sin intentar estimar un mismo lugar dos o ms veces consecutivas. Dado el problema mencionado con la lentitud de la respuesta de medicin de las condiciones del entorno (puntos de acceso y sus potencias de seal percibidas), para cada una de las localizaciones se realiz un test a los diez segundos de llegar al lugar que reconocer, al minuto, a los dos minutos y a los tres minutos. Conforme el tiempo estable en un lugar aumenta, la precisin, a causa de la lenta actualizacin de los datos recogidos a travs de la interfaz wireless de la tarjeta de red, tiende al 100%, tal y como se observa en la tabla 4.1.
Tiempo Estable Transcurrido 10 segundos 1 minuto 2 minutos 3 minutos
Aciertos 9/27 20/27 25/27 26/27
Precisin 33.33% 74.07% 92.59% 96.30%
Tabla 4.1. Precisin en el posicionamiento respecto del tiempo de estabilizacin.
La figura 4.3 recoge una grfica con los anteriores datos de la anterior tabla. En ella se observa claramente la tendencia al 100% de precisin en el reconocimiento conforme aumenta el tiempo estable que el usuario permanece en un determinado lugar. Esta idea queda reforzada por el dato de que el 75% de los errores cometidos en la estimacin se corresponde con la emisin del ltimo sitio visitado estable o ltimo lugar del que se provena y en el que se permaneci durante un largo tiempo. Sin duda este es el principal problema que el sistema posee actualmente y se desconoce exactamente de dnde procede; si de la tarjeta de red, del SO, de la aplicacin 65
Grupo I4
de medida de seal WiFi, etc. No obstante, se debe hacer hincapi en que esta es una dificultad ajena a nuestra teora de solucin que, como se puede comprobar, potencialmente puede llegar a tener una excelente precisin. Por tanto, como ya se ha mencionado, el siguiente paso en la direccin de mejora del sistema radica en dar una explicacin a por qu ocurre este fenmeno y en encontrar un mtodo suplementario integrable en el prototipo que solucione el problema. Notar tambin que cualquier solucin basada en la medida de potencia en estas circunstancias (por ejemplo, triangulacin) fallara estrepitosamente.
Precisin de Reconocimiento Frente al Tiempo de Estabilizacin

120
Precisin de Reconocimiento (%)
100 80 60 40 20 0 10 60 120 180 Precisin
Tiempo de Estabilizacin (s)
Figura 4.3. Precisin de reconocimiento frente al tiempo de estabilizacin.
Otras caractersticas deseables de este tipo de sistemas no fueron evaluadas como tal pero, por ejemplo, los lugares de reconocimiento
RIO2 AULA-
AULARIO3
se encontraban en la misma vertical, diferencindose ni-
camente en una planta por lo que, al menos, a priori parece que es posible 66
Grupo I4
garantizar una resolucin equivalente a la altura de una planta (pocos metros).
Figura 4.4. Ejemplo de reconocimiento del AULARIO0.
La comunicacin entre dos clientes haciendo uso del mdulo servidor alojado en un servidor en Internet de acceso pblico fue comprobada mediante un pequeo experimento consistente en la situacin de un usuario fijo con un PC porttil en la biblioteca de la
ETSIIT
y con la aplicacin
cliente corriendo sobre l conectada al servidor. El otro usuario conmutaba secuencialmente su posicionamiento a alguno de los lugares entrenados portando otro PC porttil con la aplicacin cliente corriendo sobre l conectada tambin al servidor. Una vez conocido el cambio de posicin del usuario mvil, desde el PC porttil fijo en la biblioteca se enva una peticin de localizacin del mismo, devolvindose correctamente la estimacin efectuada de la posicin del usuario remoto de su lado. El nico problema que es preciso solucionar a continuacin se encuentra relacionado con la prdida de la conexin del usuario mvil al realizar traspasos de conexin a la red por cambio de punto de acceso.
67
Grupo I4
Todas las conclusiones derivadas tanto del estado del prototipo como de este captulo de test (ventajas, inconvenientes, soluciones y trabajo futuro) se recogen en el siguiente punto a continuacin.
68
Grupo I4
5.
Conclusiones y Lnea de Trabajo Futuro

Este ltimo punto recoge todas las conclusiones recopiladas a lo largo
de das de trabajo y derivadas de todos los problemas encontrados durante la construccin del prototipo as como de su rendimiento. En primer lugar se tratan y justifican los puntos fuertes del sistema que lo hacen especialmente atractivo frente a otras soluciones de localizacin indoor. A continuacin se recogen los principales puntos dbiles que deben ser inmediatamente solventados para lograr una mejora sustancial del rendimiento y precisin del sistema, aportndose as mismo un compendio de soluciones y avances que cubran dichas debilidades. En ltimo lugar se exponen las lneas de actuacin inmediata y trabajo futuro con el fin de extraer todo el potencial que, a nuestro juicio, esta tecnologa puede ofrecer.
5.1
Puntos Fuertes
Los puntos fuertes de esta propuesta son mltiples, haciendo que sea realmente atractiva frente a otras soluciones de localizacin indoor, principalmente debido a su coste monetario adicional nulo. Algunas de estas ventajas se listan a continuacin:
Coste de la solucin: El coste derivado de la implementacin de

este sistema es variable en funcin de los medios aplicados para ello. Sin embargo, a priori, es posible que sea nulo, pues los nicos requisitos imprescindibles son poseer un dispositivo mvil con capacidad de conexin a una red inalmbrica y encontrarse en un entorno fsico que oferte este tipo de acceso a una red. Cumplidos estos, es suficien-
69
Grupo I4
te con instalar una aplicacin puramente software en el dispositivo y que exista un modelado estadstico del entorno en cuestin para el reconocimiento de la posicin. De este modo se ahorra el despliegue hardware realmente caro que algunas soluciones de posicionamiento indoor requieren (uso de balizas basadas en infrarrojos, ultrasonidos, etc). La variabilidad del coste puede proceder ms bien del sistema elegido para la elaboracin del modelado estadstico del ambiente de posicionamiento. Ello se puede hacer manualmente gracias a un operador que vaya caracterizando el entorno con algn tipo de dispositivo porttil. De hecho puede mejorarse la aplicacin entrenadora para que este entrenamiento se lleve a cabo de un modo automatizado tal que baste con caminar de forma continuada por la regin de localizacin. Otro modo podra ser incorporar el entrenador mejorado a algn tipo de robot que barra la zona en cuestin de un modo autmata o teledirigido. En el primero de los casos el coste es nulo, y puede conseguirse a travs de simple programacin software.
Portabilidad: Derivado del coste nulo o muy reducido de implementacin, surge el concepto de portabilidad. Dado que slo precisamos de un dispositivo mvil con conexin inalmbrica a algn tipo de red, de forma que se aprovecha la infraestructura ya instalada en la regin de potencial localizacin, es posible expandir el sistema sin ms que caracterizar el ambiente de posicionamiento estadsticamente. Adems, dicha caracterizacin, a diferencia de en otras soluciones, se puede llevar a cabo completamente a ciegas, es decir, no es necesario conocer absolutamente ningn dato a priori de la infraestructura de acceso. Por tanto, es suficiente con delimitar un entorno de lo70
Grupo I4
calizacin, entrenar segn el mtodo expuesto y comenzar a utilizar el sistema.
Robustez en el reconocimiento: El posicionamiento en interiores

sigue siendo a da de hoy un reto sin una solucin plenamente satisfactoria debido, principalmente, a dos motivos: el alto coste de las soluciones robustas y precisas y las dificultades tcnicas asociadas al entorno de localizacin. Como ya hemos esbozado, esta propuesta solventa el primer dilema mientras que, potencialmente, tambin puede hacerlo con el segundo. Los acusados efectos de difraccin, atenuacin y multipath especialmente, entre otros, complican enormemente la localizacin en interiores debido a la topologa fsica compleja y cambiante del entorno. En estas condiciones, la seleccin de un buen modelo de propagacin es compleja como para emplear sin ms la solucin por triangulacin, pues seran precisos modelos muy complejos con coeficientes posiblemente adaptativos que respondiesen a la volubilidad del ambiente o el empleo de caracterizaciones a partir de mtodos numricos como el mtodo de las diferencias finitas en el dominio del tiempo, cuyo coste computacional es importante. La nica forma de solventar estas dificultades es emplear costosos sistemas de posicionamiento. La localizacin basada en un modelado estadstico del ambiente permite amortiguar las variabilidades del entorno (variabilidad en la densidad y trnsito de personas, distribucin cambiante de los objetos en el entorno, afeccin de las condiciones meteorolgicas, cambios en la topologa de la infraestructura de acceso a la red, etc) y emitir una correcta estimacin de la posicin sin importarnos la posicin absoluta de los puntos de acceso sino slo lo que observamos en un lugar particular. Por ello es impor71
Grupo I4
tante realizar una caracterizacin apropiada del ambiente de localizacin recogiendo datos del mismo en distintas circunstancias para constituir as un buen modelado estadstico del entorno.
Usabilidad: Aunque actualmente slo se posee un primer estado de

prototipo, ya se observa su amplia usabilidad. La aplicacin cliente I4WLoc tan slo tiene un tamao de 2MB y alberga, como ya hemos visto, la capacidad de entrenar un entorno de localizacin y reconocer una posicin. Las
APIs
auxiliares tan slo tienen un peso total de
6.2MB, pensndose para un futuro prximo la integracin de su funcionalidad en la propia aplicacin. Tambin, como hemos visto, una regin de posicionamiento con nueve localizaciones y cinco caracterizaciones de cada una de ellas genera datos por un tamao de, aproximadamente, 1MB. De esta forma, cualquier persona sin apenas conocimientos puede ser capaz de descargar esta ligera aplicacin en su casa y montar su propio entorno de localizacin en la misma u otros lugares (interiores o exteriores) sin ningn coste adicional.
5.2
Puntos Dbiles y Soluciones
Por otro lado, es preciso ser realistas y explicar que esta solucin tampoco es la panacea, primordialmente por todo el trabajo que an queda por realizar. Algunos inconvenientes de esta tecnologa y sus posibles soluciones son los siguientes:
Posibilidad de poca resolucin: Este punto dbil ni siquiera se

encuentra contrastado de forma experimental pero se presupone su
72
Grupo I4
existencia a causa de la poca madurez del sistema. La posible baja resolucin, que habr de estudiarse mediante un conjunto adecuado de tests, puede derivarse del empleo de un set de caractersticas lo no suficientemente diferencial, del empleo de modelos estadsticos que no se ajusten de forma ptima al problema, etc. Sin embargo, como ya se vio en el punto cuarto, al menos parece que puede comenzar a garantizarse una resolucin de unos pocos metros. En cualquier caso, se vuelve a hacer hincapi en que este supuesto problema resulta de la falta de experimentacin en este terreno con el prototipo, por lo que su estudio se deja como lnea de trabajo futuro. En caso de baja resolucin, es posible experimentar con la inclusin de otras caractersticas, modificacin de la estructura de las mismas, testeo de diferentes topologas de modelado estadstico de las localizaciones, etc. En caso de comprobar que no existe tal problema, puede derivarse otro por alta carga computacional, ya que cada localizacin ha de poseer su propio modelo estadstico. Este problema se menciona a continuacin.
Lenta capacidad de refresco y falsas estimaciones: En el punto cuarto ya se explic el problema asociado a la lentitud de adaptacin de la medida a las nuevas condiciones de contorno en caso de cambio de ubicacin. Se habr de diagnosticar el origen del mismo y encontrar una solucin suplementaria integrable en la aplicacin prototipo (por ejemplo, el empleo de otra
API
para la medida de la po-
tencia de seal WiFi). Actualmente, este problema causa una baja precisin en la estimacin de la localizacin para bajos tiempos de estancia en ella, por lo que la funcionalidad de seguimiento de un usua73
Grupo I4
rio es impracticable en estas condiciones. Adems, un entorno de reconocimiento con un reducido nmero de puntos de acceso (cuatro o menos) tambin contribuye de forma importante a la emisin de estimaciones errneas.
Posibilidad de alta carga computacional: En un entorno de localizacin interior reducido la carga computacional no es un problema, pues el modelado estadstico no ser especialmente voluminoso. Sin embargo, en regiones ms amplias de localizacin donde se desea una buena resolucin, esto puede comenzar a ser un escollo importante. La solucin a este hecho es doble; de un lado, an se debe continuar con la disgregacin de la funcionalidad de la estimacin de la posicin en el cliente, de tal forma que se ponga del lado del servidor, el cual se espera con capacidad suficiente (algo absolutamente factible). De otra parte, se puede llevar a cabo una segunda estimacin con el fin de relajar el nmero de HMMs del ambiente de reconocimiento. Esta segunda estimacin puede estar basada en la interpolacin probabilstica segn el ajuste de las observaciones a los distintos modelos. Segn esta idea, es posible entrenar con una menor resolucin, de tal forma que, tras computar la probabilidad de que la localizacin reconocida sea una de las tantas existentes en la base de datos, en base a algn modelo de interpolacin de posicin con probabilidades por determinar, estimar con mayor resolucin la situacin del dispositivo mvil.
74
Grupo I4 5.3
Memoria de Proyecto (v1.) Trabajo Futuro
A lo largo del texto, conforme ha sido necesario, se han ido mencionando las diferentes lneas de trabajo futuro y mejoras derivados de las carencias y de los problemas actuales. En este subapartado listamos todas estas ideas y algunas ms:
Diagnstico y suplantacin del sistema de medida de potencia de seal WiFi por otro con mayor convergencia para la mejora del entrenamiento del ambiente estadstico, mejora de la precisin en el reconocimiento y posibilidad de la inclusin de la funcionalidad de seguimiento. Experimentacin con diferentes tipos de HMM con el fin de optimizar el modelado y el reconocimiento. Actualmente slo se hace uso de un modelado continuo con una gaussiana simple como funcin densidad de probabilidad para definicin de la probabilidad de emisin de smbolo. Es posible, por ejemplo, experimentar con mezcla de gaussianas o con un mayor nmero de caracterizaciones por localizacin aunque, en principio, esta es una medida secundaria ya que, como se ha visto en el punto cuarto, la precisin tras finalizar el entrenamiento fue del 100%. Incluir un mtodo de interpolacin basado en probabilidades para, a la vez que se aumenta la resolucin espacial, se reduzca la carga computacional derivada de la existencia de un cuantioso conjunto de HMMs (uno por cada localizacin). Mover la funcionalidad de reconocimiento al lado del servidor para liberar de cmputo al cliente, manteniendo nicamente en este lti75
Grupo I4
mo la captura de los datos ambientales de potencia de seal WiFi para que el servidor pueda estimar su posicin a partir de ellos. Disgregar el mdulo de entrenamiento y almacenar su resultado al lado del servidor. Integrar las funcionalidades de las
APIs
actualmente empleadas en la
aplicacin prototipo con el fin de hacer 100% efectiva la portabilidad a cualquier dispositivo con
JVM.
Extender la capacidad del entrenador para automatizar el proceso de tal forma que un usuario humano o robot pueda caracterizar una regin de posicionamiento con slo pasear por ella. Eliminar restricciones temporales del prototipo (introduccin de localizaciones por orden alfabtico y en mayscula, etc) e incluir un sistema grfico de posicionamiento basado en mapa ms cmodo, eliminando la etiqueta textual de la localizacin. Extender la posibilidad de conmutar entre distintos entornos de reconocimiento desde la misma aplicacin cliente. Experimentar con distintos umbrales de inclusin de APs en funcin de su aparicin a la estructura final y observar su influencia en el entrenamiento y en el posicionamiento. Solucionar la prdida de la conexin al sistema de un usuario mvil cuando realiza un traspaso de punto de acceso. Se ha optado en esta ocasin por no incluir mtodo de normalizacin alguno con el fin de amortiguar las heterogeneidades en la medicin derivadas de los distintos modelos de tarjetas de red. Su inclusin es inmediata, pues est programada, y est basada en una simple normalizacin de los coeficientes.
76
Grupo I4
Actualmente no es posible interrumpir el entrenamiento de un entorno de localizacin para continuar ms tarde. La inclusin de esta opcin es imprescindible y sencilla. Se puede experimentar con la agregacin de nuevas caractersticas para reforzar la precisin en el reconocimiento de la localizacin. Un parmetro posiblemente interesante es el RTT (Round-Trip Time) que acontece desde el dispositivo mvil a cada uno de los APs que nos ilumina. Es posible que una determinada localizacin en la que estemos situados no est caracterizada en el entorno estadstico. Con el fin de no emitir decisin alguna en dicho caso, ya que sera errnea, es inmediata la inclusin de un umbral probabilstico que descarte aquellas decisiones de baja probabilidad que seguramente estn originadas por encontrarse el dispositivo mvil fuera de la regin de posicionamiento.
Como se observa, an queda un gran trabajo por delante que realizar. No obstante, muchas de las medidas aqu referenciadas no dejan de ser pequeos detalles sencillos de llevar a cabo. En cualquier caso, se cree que tras cumplir adecuadamente con los anteriores puntos, se puede llegar a obtener un robusto sistema de posicionamiento, especialmente indicado para interiores, de muy bajo coste.
77
P r i me r
D e s a f o T e c n o l g i c o D T S TC
d e l
MEMORIA DE PROYECTO (v2.)
Grupo I4
Ivn Fernndez Bermejo Ivn Lpez Espejo Jonathan Prados Garzn Mark Rowsell
Grupo I4
Sumario
1. 2.
Introduccin ......................................................................................... 3 Evolucin del Proyecto ......................................................................... 5 2.1 Problemas y soluciones ................................................................... 5 Mtodo de interpolacin espacial .............................................. 9
2.1.1 2.2 3. 4.
Solucin final .................................................................................11
Estado del Prototipo ...........................................................................14 Conclusiones y Lnea de Trabajo Futuro .............................................17
Grupo I4
1.
Introduccin
El presente documento recoge la memoria acerca del estado del prototipo en el instante de su presentacin. Para comprender correctamente el proyecto final es importante tener presente lo expuesto en el documento Memoria de Proyecto (v1.), pues este texto nicamente pretende ser una ampliacin del anterior que exponga la evolucin acontecida en el trabajo hasta alcanzar la meta actual.
El esquema de red permanece prcticamente intacto respecto del presentado en la anterior etapa, por lo que apenas volver a ser referido en el presente documento. Sin embargo, la metodologa de reconocimiento de la posicin s ha sufrido un cambio drstico a causa de los dos principales objetivos impuestos para esta ltima fase: incrementar la precisin de localizacin y reducir el coste computacional. No obstante hay que notar que contina sustentndose la solucin sobre un planteamiento estadstico, si bien ya no son usados modelos ocultos de Mrkov (HMMs). Toda la problemtica asociada ser detalladamente expuesta cronolgicamente en los puntos que continan.
Finalmente, al igual que en el documento previo, se recoge una sencilla descripcin del prototipo final relacionando cada cuestin con su base terica para, por ltimo, comentar en pocas lneas las ventajas e inconvenientes observados hasta la fecha, as como mencionar posibles lneas de trabajo futuro. Por desgracia, por falta de tiempo, en esta ocasin, a diferencia de en la anterior, no se recoge un testeo del sistema en el ambiente de localizacin que es la
ETSIIT,
por lo que el apartado de conclusin est 3
Grupo I4
ms bien basado en la percepcin subjetiva actual del rendimiento del sistema y en si se han o no atacado las vicisitudes expuestas en el anterior documento.
Grupo I4
2.
Evolucin del Proyecto

Todo el trabajo llevado a cabo hasta el momento actual parte al
completo del primer prototipo presentado. Los dos objetivos bsicos priorizados para esta ltima fase han sido incrementar la precisin (aumento de resolucin espacial y reduccin de falsos positivos) y disminuir el coste computacional, habiendo girado todos los cambios ejecutados en torno a estas dos cuestiones.
2.1
Problemas y soluciones
El primer tema abordado fue el aumento de la resolucin espacial de reconocimiento sin incrementar por ello el nmero de modelos del sistema. Una vez logrado, la intencin fue revisar las bases del empleo de HMMs con el fin de redefinir el modelado con dos objetivos bsicos: mejorar la estimacin de la localizacin y reducir la cantidad de cmputo. En relacin a esta ltima cuestin, resultaba imprescindible incrementar la resolucin espacial, como se ha dicho, sin aumentar la cantidad de modelos en el sistema (recordemos que cada modelo representaba una localizacin), ya que por cada modelo o lugar segn el estado de la solucin, el algoritmo de Viterbi deba de realizar un total de, aproximadamente, 2 longitud de la rfaga de medida y operaciones, donde es la
el nmero de puntos de acceso en el
entorno de localizacin. De esta forma, si suponemos un entorno de posicionamiento como es la = 50 puntos de acceso diferentes, y recordando que la longitud de rfaga = 5, por cada modelo de localizacin enETSIIT
donde pueden contribuir al sistema unos
de medidas por defecto era de
trenado se deba de llevar a cabo durante la etapa de reconocimiento en
Grupo I4
torno a 1.250.000 operaciones! Independientemente de que se replantease posteriormente la forma de emplear los HMMs, resulta claro que es imprescindible tratar de aadir el menor nmero de modelos posibles al sistema, ya que el coste computacional puede llegar a ser prohibitivo tanto para el dispositivo del usuario como incluso para un servidor que lleve a cabo la resolucin de peticiones de localizacin.
La estrategia planteada en un principio fue la de entrenar por habitculo una mnima cantidad de puntos representativos del mismo para, en funcin del score (medida logartmica de semejanza por cada modelo que ofrece el algoritmo de Viterbi) por cada uno de los modelos, tratar de determinar mediante algn tipo de algoritmo una posicin ms refinada. En un primer lugar se pens en el empleo de redes neuronales para tal fin, pero pronto fueron sustituidas por una solucin ms sencilla basada en la estimacin de pesos ptimos a partir de la definicin de un conjunto de ecuaciones lineales. La definicin y demostracin de dicho mtodo se expone en el punto 2.1.1, en lo que se ha venido a denominar mtodo de interpolacin espacial.
Figura 2.1. Empleo de scores para incrementar la resolucin espacial de reconocimiento.
Grupo I4
La figura 2.1 muestra grficamente el planteamiento intuitivo de la idea. Supngase que los puntos rojos indican posiciones dentro de una sala que han entrenado unos modelos asociados y que el punto gris es una persona cuya localizacin se desea estimar. Aplicando reconocimiento N-Best, donde N es la totalidad de posiciones del entorno entrenado, podemos conocer el score o medida de semejanza de la caracterizacin del lugar que quiere reconocerse frente a todos los modelos de localizaciones. Una aproximacin de distribucin de probabilidad de localizacin puede ser obtenida a partir de la exponenciacin de los scores para la posterior normalizacin del conjunto de ellos. De esta forma obtenemos, aproximadamente, la probabilidad de ser de cada localizacin dada la posicin que se desea reconocer (nmeros en la figura 2.1). A partir del empleo del mtodo de interpolacin espacial, donde los datos de entrada son estas pseudoprobabilidades, y habindose estimado previamente en una fase de entrenamiento un conjunto de pesos ptimos, debe ser posible obtener las coordenadas de situacin deseadas (punto gris de la figura 2.1). Diferentes experimentos se realizaron, empleando como datos de entrada, aparte de las pseudo-probabilidades, los propios scores e, incluso, niveles de potencia. Tambin se experiment con diferentes formatos de coordenadas de salida. No obstante, en ningn caso se obtuvo un resultado aceptable, partiendo incluso de un error medio de entrenamiento excesivamente elevado en algunos de los planteamientos.
A causa de lo anterior, se apost por revisar la forma de empleo de los HMMs con el fin de mejorar el sistema de reconocimiento en trminos de precisin y coste computacional, pudiendo llegar as a eliminar la necesidad de recurrir a un algoritmo de interpolacin espacial y entrenar localiza-
Grupo I4
ciones ms densamente. Adems, ello se pensaba combinar con una estrategia de divisin de reconocimiento. Esta consiste en reconocer primero en qu habitculo se encuentra el usuario que se quiere localizar a partir de una base de datos con pocos puntos de entrenamiento para, una hez hecho, ejecutar un segundo reconocimiento sobre la base de datos de patrones estadsticos del habitculo reconocido con el fin de dar un posicionamiento ms preciso. Supngase que esto se lleva a cabo para el sistema presentado en la segunda fase, donde por cada localizacin en la etapa de reconocimiento se requiere del cmputo de unas 2 operaciones segn el algorit-
mo de Viterbi. Si se lleva a cabo un entrenamiento denso del entorno de localizacin, durante la fase de reconocimiento se realizarn unas 2
operaciones, donde cionamiento y
es el nmero total de habitculos del entorno de posi-
es la cantidad de posiciones promedio dentro del habitcu-
lo que se pueden reconocer. Si primero localizamos en qu habitculo se encuentra el usuario y luego refinamos su posicin, estaremos llevando a 2 cabo 2( + ) , > 1. operaciones, donde es claro que 2( + )
Sin embargo, tras valorar distintas formas de empleo de los HMMs, se opt por el modelado de las potencias de seal WiFi para cada una de las localizaciones mediante funciones densidad de probabilidad gaussianas. En este nuevo marco se hace evidente la desaparicin del concepto de estado y, por tanto, de modelo oculto de Mrkov. La solucin finalmente implementada basada en esta idea se recoge en el punto 2.2.
Grupo I4 2.1.1
Memoria de Proyecto (v2.) Mtodo de interpolacin espacial
Considrese el siguiente sistema de ecuaciones: = + + + ++
mos el sistema y { namiento y
donde {
} es el conjunto de datos de entrenamiento con el que alimenta=
++
+ +
(2.1)
coeficientes de entrenamiento. Sea
} es el conjunto de valores de salida deseados para los
el nmero de aportaciones al entre, ten>
el nmero de variables de entrada en juego, si
dremos un sistema de ecuaciones lineales determinado siempre y cuando no existan ecuaciones linealmente dependientes en l. Sin embargo, si ,
el sistema estara sobredeterminado, pero no en el mbito de procesos aleatorios, donde es necesario encontrar el conjunto de coeficientes o pesos, { }, tal que sea ptimo en funcin de algn criterio. El criterio seguido en
el presente mtodo es la minimizacin del error cuadrtico. Es interesante que , es decir, que exista una suficiente cantidad de datos de entre-
namiento, si bien este aspecto es crtico (as como los valores de entrada y salida para una ecuacin entrenamiento concreta, ya que aqu no se hace uso de funciones de transferencia como s lo puede hacer una red neuronal) y complicado de gestionar, al igual que en una red neuronal. A continuacin calculamos el conjunto de pesos { } tal que es pti-
mo en el sentido de que minimiza el error cuadrtico. Defnase el error acaecido de estimacin para la ecuacin de entrenamiento m-sima como: 9
Grupo I4
Memoria de Proyecto (v2.) ( )= = . (2.2)
En consecuencia, el error cuadrtico se expresa como:
( )=
(2.3)
Minimizamos el error cuadrtico para obtener el conjunto de pesos ptimo haciendo: = 0. De lo cual resulta:
(2.4)
=0
(2.5)
Si disponemos el anterior resultado en formato matricial, este puede resultar de gran utilidad a la hora de calcular los coeficientes ptimos computacionalmente:
(2.6)
10
Grupo I4
Resolviendo el anterior sistema de ecuaciones llegamos a la solucin deseada, pudiendo emplear el conjunto de pesos ptimos para nuevas estimaciones a partir de nuevos datos de entrada.
2.2
Solucin final
La solucin finalmente implementada en el prototipo se basa en el modelado estadstico de la potencia de seal WiFi percibida de cada punto de acceso y por cada una de las localizaciones que son susceptibles de reconocerse. A partir de una fase de entrenamiento donde la medicin de datos de potencia se lleva a cabo en trminos anlogos a los ya mostrados para el anterior prototipo, se calculan las medias y varianzas de los distintos niveles de potencia medidos a lo largo del tiempo por cada punto de acceso y por cada localizacin para definir as una funcin densidad de probabilidad gaussiana que expresa la probabilidad de que en dicha localizacin se obtenga de dicho punto de acceso un nivel concreto de potencia. Recurriendo a una definicin ms formal, supngase la contribucin de ceso al entorno de localizacin y sea puntos de ac-
el nmero total de localizaciones sus-
ceptibles de ser reconocidas en el entorno. Si en la localizacin l-sima capturamos a lo largo del tiempo muestras de nivel de potencia del punto de acceso = n-simo, , ,, podemos constituir el vector de muestras
. Podemos asociarle a la anterior variable aleatoria
una distribucin de probabilidad gaussiana sin ms que calcular su media y varianza (haciendo uso del estimador sin sesgo), respectivamente, como: 1
(2.7)
11
Grupo I4
Memoria de Proyecto (v2.) = 1 1 ( ) . (2.8)
A partir de ambos valores, la funcin densidad de probabilidad puede expresarse como ( )= 1

( )
(2.9)
Por cada localizacin se almacenan la varianza y la media estimados a partir de los valores de potencia percibidos en dicha localizacin de cada uno de los puntos de acceso del sistema, pudiendo constituir as por cada lugar susceptible de reconocerse un vector de gaussianas, de la forma , ,, =
. A la hora de llevarse a cabo el reconocimiento, nicamente , de la localizacin que se
se ha de computar un parmetro de semejanza,
desea reconocer al modelo. Dicho parmetro de semejanza se reduce a la suma de las funciones densidad de probabilidad evaluadas en las potencias percibidas de los puntos de acceso correspondientes y por cada localizacin, es decir: ( ).
(2.10)
De tal modo constituimos un vector de valores de semejanza de la localizacin a los modelos, de la forma = , ,, . Sin ms que conocer con
qu sitio se corresponde el valor de semejanza mximo (modelo de localizacin ms probable), habremos reconocido la posicin actual del usuario, es decir: 12
Grupo I4
Memoria de Proyecto (v2.) = argmax ( ). (2.11)
La figura 2.2 muestra grficamente una imagen intuitiva de cmo se caracteriza cada uno de los lugares del entorno de localizacin.
Figura 2.2. Caracterizacin del entorno de localizacin.
13
Grupo I4
3.
Estado del Prototipo

La implementacin software del sistema ha sufrido las modificaciones
oportunas en funcin de la nueva teora de reconocimiento expuesta en el punto anterior. Fuera de ello, las diferencias son mnimas respecto al sistema ya mostrado en la anterior fase. Las dos principales novedades radican en la inclusin de los mapas de la
ETSIIT
y en la disgregacin en dos mdu-
los standalone del entrenador y el cliente de localizacin.
Figura 3.1. Aplicacin entrenadora.
La nueva interfaz grfica permite el aadido de lugares reconocibles al entorno de localizacin sin necesidad de emplear etiquetas, como antes ocurra. Es suficiente con marcar un punto en el plano para, a partir de sus coordenadas, serle asociado el conjunto de mediciones de potencia WiFi correspondiente. Tambin es posible cerrar la aplicacin entrenadora sin haber concluido el entrenamiento, pudiendo retomarlo en cualquier momento posterior. Una vez consideremos que hemos capturado los datos oportu-
14
Grupo I4
nos y suficientes, podremos entrenar sin ms que pulsar sobre el botn habilitado a tal efecto. En caso de querer, a posteriori, aportar ms datos al entorno de localizacin para actualizarlo o mejorarlo, es posible sin ms que aadir nuevas mediciones y reentrenar. Debido a que ahora el entrenamiento consiste en el cmputo de medias y varianzas de diferentes vectores de muestras de potencia, este concluye de forma casi instantnea para el usuario entrenador.
Figura 3.2. Aplicacin del cliente de localizacin.
Una vez el entorno de localizacin haya sido entrenado, el objeto serializado en un fichero con el resultado del entrenamiento le es pasado al cliente de localizacin, que no tiene ms que cargarlo a travs de su aplicacin. De esta forma, una misma instalacin del cliente de localizacin puede disponer de diferentes entornos de posicionamiento, habilitada la conmutacin entre ellos segn el lugar en el que se encuentre. Tras ello ser suficiente con pulsar sobre el botn Conectar para conectarse al servidor del sistema, pudiendo ver el resto de usuarios conectados en ese mismo instan-
15
Grupo I4
te, de tal forma que es posible lanzar peticiones de localizacin sobre ellos que resolvern sus aplicaciones cliente, siendo enviadas a travs del servidor a nuestro programa para pintar un punto rojo en el plano con sus situaciones.
En esencia, los conceptos e implementacin del apartado de red son idnticos a los expuestos en la anterior memoria.
Notar que tanto la obtencin de las medidas de potencia con netsh como la estructuracin de dicha caracterstica no han cambiado, salvo por la eliminacin de la captura de datos en forma de rfaga cada vez que se realiza una medicin (nicamente ahora se captura un valor de potencia por punto de acceso y por localizacin cada vez que presionamos el botn de aadido durante la etapa de entrenamiento).
16
Grupo I4
4.
Conclusiones y Lnea de Trabajo Futuro

Si bien es cierto que ha sufrido cierta transformacin el sistema hasta
llegar a esta fase, las bases sobre las que se sustenta permanecen inmutables, por lo que todos los puntos fuertes mencionados en el documento Memoria de Proyecto (v1.) se mantienen. Sin embargo, gracias a los cambios realizados, los puntos dbiles se han mejorado. Veamos una pequea discusin acerca de estos tres puntos mencionados en el anterior texto:
Posibilidad de poca resolucin: Puesto que, como se ha dicho, en

esta ocasin no ha podido llevarse a cabo ningn test formal, no podemos concluir nada al respecto. No obstante s se realiz una sencilla prueba consistente en el entrenamiento de dos puntos distantes entre s 1 metro, reconocindose con total acierto ambas posiciones para todos los intentos. No obstante este dato no es relevante, pues existen numerosas variables que no han sido tenidas en cuenta, como la cantidad de puntos de entrenamiento o la variabilidad dependiendo de la estructura y configuracin WiFi del entorno. Sin embargo, cualitativamente parece que puede llegar a ofrecer buenos resultados, habindose solucionado el asunto de la alta carga computacional.
Lenta capacidad de refresco y falsas estimaciones: Un bajo

nmero de puntos de acceso vuelve a contribuir de forma importante a la emisin de estimaciones errneas. El asunto de la lenta capacidad de refresco an no ha sido solucionado debido a que, como se ha comentado, el procedimiento de medicin de potencia no ha variado. Actualmente creemos que representa el principal escollo que posee el
17
Grupo I4
sistema, debiendo ser el inmediato que solucionar. Unido ello a la dudosa calidad de medida de baja precisin que realiza, supone un gran inconveniente a la hora de evaluar de forma prctica la idea, pues dificulta el entrenamiento, el cual no se desarrolla en buenas condiciones, pudiendo contribuir conjuntos de datos no muy buenos, con su inmediata repercusin en el reconocimiento, al cual se le vuelven a aadir ambos problemas.
Posibilidad de alta carga computacional: Siempre y cuando la

solucin dada en este documento ofrezca buenos resultados, este problema ha quedado completamente solventado. Aunque actualmente la estimacin de la localizacin sigue del lado del cliente, el nmero de operaciones que debe este realizar para obtener su posicin es del orden de 2 , cuando anteriormente era de 2 , es decir, la canti, lo que supone
ETSIIT.
dad de operaciones se ha reducido en un factor del orden de un factor de 10 en el entorno de la
En general se han abordado algunas de las cuestiones presentadas como trabajo futuro en el anterior documento, quedando otras, como el principal problema actualmente: la necesidad de diagnosticar y suplantar el sistema de medida de potencia de seal WiFi por otro con mayor convergencia para la mejora del entrenamiento del ambiente estadstico, mejora de la precisin en el reconocimiento y posibilitar la inclusin de la funcionalidad de seguimiento. Otras cuestiones importantes, aunque secundarias, son la extensin de la capacidad del entrenador para automatizar el proceso de tal forma que un usuario humano o robot pueda caracterizar una regin de posicionamiento con slo pasear por ella, la experimentacin con distin18
Grupo I4
tos umbrales de inclusin de APs en funcin de su aparicin en la estructura final y observar su influencia en el entrenamiento y en el posicionamiento, la experimentacin con otras caractersticas, etc. Previamente a definir correctamente las lneas de trabajo futuro se hace preciso la realizacin de un compendio representativo de tests como paso inmediato.
19

Sistema Estadístico de Localización Indoor

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sistema Estadístico de Localización Indoor

Uploaded by

Copyright:

Available Formats

P r i me r

MEMORIA DE PROYECTO (v1.)

Memoria de Proyecto (v1.)

2.1.2.1 2.1.2.2 2.1.2.3 2.1.3 2.2 3.

Aplicacin de HMMs al reconocimiento de la localizacin .......22

Teora de la Comunicacin ............................................................25

Memoria de Proyecto (v1.)

asentndose este sobre un set de aplica-

la herramienta netsh de Windows para la medi-

Memoria de Proyecto (v1.)

Memoria de Proyecto (v1.)

Teora del Reconocimiento de la Localizacin

Figura 2.1. Sistema de localizacin basado en HMMs.

Memoria de Proyecto (v1.)

Memoria de Proyecto (v1.)

1. El nmero de estados del modelo,

. Generalmente, dichos estados se

Memoria de Proyecto (v1.) al conjunto

cuentra el modelo en el instante de tiempo , as como con los estados, de la forma, ={ , ,, }.

2. El nmero de smbolos de observacin distintos por estado,

delo en el instante de tiempo .

3. La matriz de probabilidades de transicin entre estados, donde

y donde estas probabilidades verifican la siguiente condicin de normalizacin:

Memoria de Proyecto (v1.)

y donde estas probabilidades verifican la siguiente condicin de normalizacin:

5. La matriz de estados iniciales, = { }, donde = = , 1,2, , ,

y donde estas probabilidades verifican la siguiente condicin de normalizacin:

de con uno de los smbolos del conjunto

el nmero total de ob-

servaciones contenidas en la secuencia, y cuya generacin procede del siguiente modo: 9

Memoria de Proyecto (v1.)

, de acuerdo con la matriz de

probabilidad de generacin de smbolos para el estado i-simo, ( ). = , segn la distribucin de pro.

4. Transicin a un nuevo estado,

o, en caso contrario, finaliza el procedimiento.

, tiene asociada una probabilidad de ocurrencia dados el .

modelo y la secuencia de observables,

Los tres problemas bsicos

Problema 1: Dada la secuencia de observaciones,

calcular de forma eficiente la probabilidad de la secuencia de observaciones dado el modelo, es decir, | .

, que mejor explique

Problema 3: Dada la secuencia de observaciones,

conjunto de parmetros , que mejor se ajuste a dicha secuencia.

2.1.2.1 Solucin al problema de evaluacin

Memoria de Proyecto (v1.) secuencias de estados distintas. Consi=( , ,, ), donde

observaciones). En total, existen

deremos a partir de ahora una fija cualquiera,

La probabilidad de dicho camino se computa como

es sencillamente el producto de los dos

Memoria de Proyecto (v1.)

en este estado con probabilidad

con una probabilidad

y generndose el ltimo smbolo,

reducido nmero de observaciones y estados como del orden de 10

operaciones! Por suerte, existe un algoritmo conocido co-

mo Forward-Backward (Adelante-Atrs), el cual simplifica considerablemente el clculo. ( ) de-

Para el procedimiento hacia adelante considrese la variable finida como ( )= , = | .

tiempo, dado el modelo . La ejecucin del procedimiento es como sigue:

Memoria de Proyecto (v1.)

= 5 era del orden de 10 , ahora resulta serlo

Memoria de Proyecto (v1.)

el instante de tiempo , y el modelo como sigue:

. La ejecucin del procedimiento es

Donde el coste computacional es similar al del procedimiento hacia adelante.