A interface FindAP permite ao smartphone, no modo não cooperativo, estimar a loca- lização de um AP dentro do alcance rádio. Na figura 4.16 pode-se observar a pasta da interface gráfica desta interface. As coordenadas na parte superior representam a loca- lização do AP selecionado (Xt, Yt) e as coordenadas na parte inferior indicam a posição
atual do utilizador (Xc, Yc) (proveniente do nó de Odometria).
Utilizando o ângulo de orientação actual θado dispositivo e as coordenadas mencio- nadas, a orientação do utilizador para o AP é dada por,
Figura 4.16: Interface da aplicação quando se tenta localizar um AP.
θa− arctan2(Yt− Yc, Xt− Xc) , (4.51)
onde arctan2(Yt− Yc, Xt− Xc) representa arctan(XYtt−Y−Xcc) com todas as proteções associadas
(i.e o denominador ou numerador ser NaN, zero, infinito entre outras) e devolvendo o resultado nos 4 quadrantes. A equação (4.51) é usada para mudar a orientação da seta apresentada na interface da aplicação, sendo atualizada sempre que existe um valor novo de coordenadas.
A figura 4.17 evidencia os principais módulos usados na implementação da interface FindAP. Resumidamente, utiliza a classe Odom que realiza a Odometria do dispositivo, a classe LatLonProvider, que utiliza a API Location da Google para obter as coordenadas de latitude e longitude, recebe eventos do scan WiFi e com esta informação estima a posição do AP.
A classe FindApFragment é o fragmento que contém as TextViews e ImageViews necessárias para a exibição gráfica. Esta classe implementa a interface UpdateNotifier, o que significa que implementa o método update que é invocado sempre que é gerado um scan WiFi. Este método pede ao odómetro as coordenadas relativas do utilizador e gera um PositionPoint com estas coordenadas e com a leitura WiFi. Em seguida, adiciona este novo ponto à sua instância da classe PositionData. Caso já exista uma estimação (tipicamente existe quando se obtêm 3 ou mais PositionPoints), actualiza as coordenadas da posição do AP, bem como o ângulo da ImageView (seta) conforme explicado anteriormente. No final actualiza sempre as coordenadas atuais do utilizador. Esta classe ainda permite que o utilizador reinicie o processo e troque de receptor para emissor, ficando em modo de
HotSpot.
A classe PositionData é responsável pela estimação do emissor. Sempre que é inserido um PositionPoint, esta tenta realizar a estimação no modo selecionado pelo utilizador.
Para isso, é utilizada a classe TrilaterationSolver ou a classe MultilaterarionSolver. No modo de trilateração foi implementado o algoritmo de trilateração selectiva, estudado anteriormente neste capítulo, enquanto na classe MultilaterationSolver utilizou-se a bibli- oteca de org.apache.commons.math3.fitting.leastsquares.Levenberg MarquardtOptimizer, com um número máximo de iterações Kmax= 1000. Em ambos os algoritmos são utilizados um número máximo de pontos, que nos testes realizados se considerou max_stored = 35.
Caso se pretenda estimar a localização de todos os APs presentes na leitura WiFiData, basta iterar a List<WiFiDetail> no PositionData, criando uma estimativa para cada AP.
C
a
p
í
t
u
5
Cooperação entre dispositivos
Este capítulo analisa diversos métodos cooperativos para estimar a localização. Para além dos ganhos a nível de precisão com poucas medições, estes sistemas permitem reduzir o tempo de estimação e transformar as coordenadas relativas estimadas em coordenadas absolutas utilizando um mecanismo de referenciação.
São apresentados dois métodos de distribuição de informação que foram implemen- tados. Embora os algoritmos de cooperação tenham sido testados em MatLab, a sua im- plementação na aplicação/servidor juntamente com os mecanismos de distribuição e respectivos testes em tempo real foram deixados para trabalho futuro.
O sistema de cooperação assemelha-se a três esquemas apresentados no capítulo 2: Centaur, ZCL e Social-Loc. Contudo, o Centaur e o ZCL utilizam hardware que não é característico dos smartphones no mercado e o Social-LC não apresenta nenhuma solução para a junção de informação de diferentes dispositivos.
A estimação cooperativa requer a existência de uma rede, composta por um grupo de
smartphones, um número de alvos e um servidor. Na rede cada smartphone pode comunicar
com qualquer outro smartphone ou AP dentro do seu alcance rádio, e todos os alvos podem ser localizados simultaneamente.
A cooperação apresenta as seguintes vantagens :
• Velocidade de convergência: Os algoritmos cooperativos conseguem convergir mais rapidamente pois obtêm várias medições em simultâneo, conseguindo obter mais pontos de medição do que um smarphone isolado. Caso um utilizador entre num grupo que já se encontra em operação há algum tempo, consegue estimar os elemen- tos em seu redor utilizando a informação dos vizinhos.
pelos dispositivos ou ser corrido num servidor. Desta forma, os dispositivos ne- cessitam de correr os algoritmos menos vezes, o que se reflete numa poupança de bateria.
Contudo, para se implementar um esquema cooperativo são necessárias mais infor- mações. Podem ser descritas como desvantagens:
• Referenciação: As coordenadas relativas estimadas por smartphones têm como ponto inicial o momento em que o utilizador inicializou a aplicação. Para que os dispositi- vos possam utilizar as medições uns dos outros, é necessário que estas coordenadas sejam representáveis no mesmo referencial, ou seja, que sejam transformadas em coordenadas absolutas.
• Cálculo do ganho de recepção Gr: Cada dispositivo utiliza uma antena diferente. As antenas presentes nos smartphones, dependendo do modelo, são diferentes a nível de hardware. Desta forma, existe a necessidade de se estimar este parâmetro para partilhar a informação. Caso Grseja mal estimado, a precisão é directamente afectada. Este efeito dos ganhos das antenas foi previamente observado no gráfico 4.1, para os dois terminais usados nos testes.
• Arquitetura de comunicação: Para realizar a troca de informação, é necessário que seja implementado um protocolo de partilha de coordenadas centralizado ou distri- buído.
Os pontos enumerados são abordados nas subsecções seguintes, sendo apresentadas soluções para os mesmos.
5.1 Cálculo do ganho de recepção
O ganho de recepção Gre ganho de transmissão Gtque muitas vezes é considerado como parte da potência de transmissão Pt, tem uma grande influência na potência do sinal recebido.
Tendo em conta que muitas das fontes são totalmente desconhecidas, não é possível assumir que se sabe Gt e Pt. Contudo podemos tentar estimar o Gr do smartphone para minimizar as variações e para ser mais fácil juntar informações de diversos dispositivos. Visto que o número de variáveis é bastante superior ao número de valores conhecidos, não é possível calcular este valor de uma forma direta, mesmo num esquema de crowd-
sourcing. Uma das soluções é seguir uma abordagem semelhante à usada no algoritmo
de Pedro-Tomic, onde se transforma num problema convexo e se estima este valor. Esta abordagem tem a desvantagem de ser pesada a nível computacional. Outra abordagem é considerar um emissor com Pt conhecida no ponto de entrada de um edifício, e cada vez que um utilizador entrar, estimar Gr e guardar este valor. Corrigindo os valores de
RSS usados nos algoritmos com o desvio medido, é possível combinar medidas de vários terminais.