Embed Size (px)
Citation preview
Regata - Tempo para a Linha de Largada
Regatta Management I
Sérgio Machado Morais de Oliveira
Dissertação para obtenção do Grau de Mestre em
Engenharia Electrotécnica e de Computadores
Júri
Presidente: Professor Fernando Duarte Nunes Orientador: Professor António Simão de Carvalho Fernandes Co-orientador: Professor Rui Manuel Rodrigues Rocha Arguente: Professor Nuno Filipe Valentim Roma
Novembro de 2012
2
3
Resumo
Este trabalho apresenta o projecto de desenvolvimento de uma aplicação para smartphones
Android de utilidade em regatas de barcos à vela. A aplicação disponibiliza informação nos
minutos anteriores ao início da regata sobre a contagem decrescente para cruzar a linha de
largada e os tempos para o barco chegar a essa linha ou às bóias que a delimitam. Depois do
início da regata a aplicação regista o percurso e permite fazer o seu upload para uma análise
posterior das opções tomadas durante a regata. A interface foi especificamente desenhada
para apresentar exclusivamente a informação necessária, de leitura simples e clara, com uma
componente visual que discrimina diferentes situações e outra auditiva complementar.
A aplicação utiliza o GPS do smartphone para receber as coordenadas geográficas da posição
corrente. Foi desenhada uma arquitectura modular com uma separação por grupo de
funcionalidades. Esta arquitectura foi depois adaptada à plataforma escolhida para a
implementação: Android. O funcionamento dos módulos é assíncrono e existem mecanismos
de comunicação e acesso a dados para fazer a sincronização.
Para as velocidades normais de uma regata, 3 a 9 kn, o erro apresentado pelo GPS impede
que sejam feitos cálculos utilizando apenas dois pontos consecutivos, por ser da mesma ordem
de grandeza. Para um período de amostragem de um segundo (o normal em smartphones
Android) e para as velocidades apresentadas acima, entre duas leituras a deslocação do barco
encontra-se entre 1,5m e 4,5m, o que é um valor dentro da zona de erro do GPS. Foi por isso
necessário encontrar uma forma de minorar esse erro até se obter valores utilizáveis para as
estimativas necessárias. Foi escolhido recolher vários pontos consecutivos e efectuar uma
regressão linear com os mesmos pontos, sendo o resultado dessa regressão utilizado para as
estimativas. Verificou-se que para percursos de rumo e velocidade constante os valores
obtidos com este método tinham um erro menor e dentro de valores que tornaram possível
informar o utilizador das previsões de tempo à linha. O valor absoluto do erro mantém-se mas o
valor relativo reduz-se porque agora o percurso é de entre 7,5m e 22,5m e o erro do GPS é
igual.
Durante e no final do desenvolvimento foram efectuados testes que permitiram corrigir enganos
e efectuar melhorias. A aplicação foi desenvolvida a pensar em utilizadores amadores e
profissionais e com o objectivo de vir a ser comercializada no mercado Android. Os resultados
obtidos confirmaram os objectivos iniciais e mostram que a tecnologia actual dos smartphones
pode ser usada neste tipo de aplicações (regatas) e que seria interessante desenvolver mais
funcionalidades no sentido de evoluir para uma gestão completa de regatas.
Palavras-Chave: GPS, Smartphone, Android, Regata, Regressão linear.
4
5
Abstract
This report presents the developing project of an Android smartphone application for use in sail
regattas. In the previsous minutes before the start of the regatta the application presents a
countdown timer to cross the start line and the time for the boat reach that line or the buoys that
mark it. After the regatta starts the application stores the path and allows its upload for a later
analysis of the options taken during the regatta. The interface was specially designed do
present exclusively the information needed, of very simple reading, with a visual component that
discriminates the different situations and a complementary audio component.
This application uses the smartphone GPS to receive the geographic coordinates of the current
position. A modular architecture was designed with a separation by group of functionalities. This
architecture was then adapted to the chosen platform for the implementation: Android. The work
of the modules is asynchronous and there are mechanisms of communication and data access
to make the synchronization.
For the regular regatta speeds, 3 to 9 kn, the error given by the GPS doesn’t allow to be made
calculations using just two consecutive points, because it has the same order of magnitude. For
a sampling period of one second (the regular in smartphones Android) and for the speeds
presented above, between two readings the displacement of the boat is between 1,5m and
4,5m, wich is a value inside the area zone of the GPS. Therefore, it was necessary to find a way
of reducing those errors so that valid values for estimation were obtained. It was chosen to
gather several consecutive points and do a linear regression with those points, using the result
for the estimations calculations. For paths with a constant course and speed the values
obtained with this method had a lower error and inside values that allowed the possibility to
inform the user of the predictions of time to the line. The absolute value of the erros is the same
but it’s relative value is reduced because now the path is between 7,5m and 22,5m with the
same GPS error.
During and in the end of the developing phase tests were realized that allowed correcting errors
and developing improvements. The application was developed for amateur and professional
users with the objective of being commercialized in the Android market. The initial objectives
were confirmed by the results obtained, that show that the current technology of smartphones
can be used in this regatta type applications and that it would be interesting to develop more
functionalities evolving to a full regatta management.
Keywords: GPS, Smartphone, Android, Regatta, Linear regression.
6
7
Agradecimentos
Ao meu orientador, professor António Carvalho Fernandes, pelo enorme apoio e orientação me
deu nesta dissertação. Pelo entusiasmo que me transmitiu e pelo método de trabalho que
cultivou, mantendo um ritmo constante, essencial para que conseguisse chegar ao fim.
Também pela forma como me transmitiu críticas ou observações, se uma forma sempre
positiva que me fez sair sempre incentivado e motivado para melhorar o trabalho.
Ao meu co-orientador, professor Rui Rocha, pelo questionamento das opções tomadas, com
observações e críticas pertinentes e sempre construtivas, que permitiram que a parte do
desenvolvimento da aplicação fosse realizada dentro das práticas aconselhadas.
Aos meus amigos e colegas, pelo apoio que me deram e pelo interesse demonstrado neste
projecto.
Finalmente, à minha família e à Isabel, pelo apoio incondicional e pela paciência infinita que
tiveram comigo.
8
9
Índice
Resumo ......................................................................................................................................... 3
Abstract ......................................................................................................................................... 5
Agradecimentos............................................................................................................................. 7
Índice ............................................................................................................................................. 9
Lista de Figuras ........................................................................................................................... 12
Lista de Tabelas .......................................................................................................................... 15
Lista de Abreviaturas ................................................................................................................... 16
1 Apresentação ....................................................................................................................... 17
1.1 Contextualização do ambiente da aplicação ............................................................... 17
1.2 Questão central ........................................................................................................... 18
1.3 Objectivos .................................................................................................................... 18
1.4 Estrutura da dissertação ............................................................................................. 19
2 Estado da arte ...................................................................................................................... 20
2.1 Sistemas de navegação por satélite ........................................................................... 20
2.2 GPS ............................................................................................................................. 20
2.2.1 Cálculo de coordenadas .......................................................................................... 21
2.2.2 Transformação de coordenadas ............................................................................. 22
2.2.3 Precisão ................................................................................................................... 24
2.2.4 Técnicas de aumento da precisão .......................................................................... 25
2.2.5 Cálculo de coordenadas locais ............................................................................... 27
2.3 Sistemas concorrentes ................................................................................................ 28
2.3.1 Prostart .................................................................................................................... 28
2.3.2 Sailclever ................................................................................................................. 28
2.3.3 iRegatta ................................................................................................................... 29
2.3.4 Sail Racing .............................................................................................................. 30
2.3.5 Regatta Tactic Compass ......................................................................................... 30
2.3.6 RockBox A.M.P.D. ................................................................................................... 31
2.3.7 Nauteek SC200 ....................................................................................................... 31
2.3.8 Análise comparativa ................................................................................................ 32
10
3 Arquitectura do sistema ....................................................................................................... 34
3.1 Requisitos .................................................................................................................... 34
3.1.1 Principais ................................................................................................................. 34
3.1.2 Secundários ............................................................................................................. 35
3.2 Arquitectura global....................................................................................................... 35
3.3 Menu ............................................................................................................................ 36
3.4 Posição ........................................................................................................................ 38
3.5 Estimativa .................................................................................................................... 39
3.6 Time to Line (TTL) ...................................................................................................... 41
3.6.1 Correcção devida às correntes ............................................................................... 43
3.6.2 Time to Buoy (TTB) ................................................................................................. 43
3.7 Regatta ........................................................................................................................ 43
3.8 Base de dados ............................................................................................................. 43
4 Implementação na plataforma Android ................................................................................ 45
4.1 Arquitectura da plataforma .......................................................................................... 45
4.2 Concretização da arquitectura funcional ..................................................................... 46
4.3 Menu ............................................................................................................................ 47
4.4 Posição ........................................................................................................................ 48
4.5 Estimativa .................................................................................................................... 49
4.6 Time to Line (TTL) ....................................................................................................... 49
4.6.1 Correcção devida às correntes ............................................................................... 50
4.7 Regatta ........................................................................................................................ 50
4.8 Upload do trajecto ....................................................................................................... 50
4.9 Base de dados ............................................................................................................. 51
4.10 Interface ....................................................................................................................... 53
4.11 Compatibilidade ........................................................................................................... 57
4.12 Desempenho ............................................................................................................... 58
4.13 Validações ................................................................................................................... 58
5 Conclusões e trabalho futuro ............................................................................................... 60
6 Bibliografia............................................................................................................................ 62
7 Anexos ................................................................................................................................. 64
11
7.1 Cálculo Time to Line .................................................................................................... 64
7.1.1 Algoritmo de implementação ................................................................................... 73
7.1.2 Correcção devida às correntes ............................................................................... 74
7.2 Regressão Linear ........................................................................................................ 78
7.3 Testes .......................................................................................................................... 79
7.3.1 17 de Fevereiro de 2012 ......................................................................................... 79
7.3.2 18 de Fevereiro de 2012 ......................................................................................... 80
7.3.3 15 de Abril de 2012 ................................................................................................. 81
7.3.4 6 de Maio de 2012 ................................................................................................... 85
7.3.5 7 de Junho de 2012 ................................................................................................. 89
7.4 Manual da aplicação.................................................................................................... 93
12
Lista de Figuras
Figura 1 – Largada de uma regata .............................................................................................. 18
Figura 2 – Trilateração (LANGLEY, 1991) .................................................................................. 21
Figura 3 – Modelo elipsoidal da terra (Kaplan, et al., 2006) ....................................................... 23
Figura 4 – D-GPS (Kaplan, et al., 2006) ..................................................................................... 26
Figura 5 – Distância corda e perímetro ....................................................................................... 27
Figura 6 – Velocitek ProStart (Velocitek) .................................................................................... 28
Figura 7 – Sailclever (SailClever) ................................................................................................ 29
Figura 8 – iRegatta (Let's Create) ............................................................................................... 30
Figura 9 – Sail Racing (Pepette.com) ......................................................................................... 30
Figura 10 – Regatta Tactic Compass (Embedia) ........................................................................ 31
Figura 11 – ROCKBOX (RockCityMarine) .................................................................................. 31
Figura 12 – Nauteek SC200 (Nauteek) ....................................................................................... 32
Figura 13 – Módulos .................................................................................................................... 35
Figura 14 – Diagrama de sequência para o modo TTL .............................................................. 36
Figura 15 – Módulo Menu ........................................................................................................... 37
Figura 16 – Marcação da bóia de bombordo .............................................................................. 38
Figura 17 – Módulo Posição ........................................................................................................ 39
Figura 18 – Módulo Estimativa .................................................................................................... 40
Figura 19 – Módulo TTL .............................................................................................................. 42
Figura 20 – Base de Dados ......................................................................................................... 44
Figura 21 – Arquitectura Android ................................................................................................ 45
Figura 22 – Arquitectura da implementação em Android ............................................................ 47
Figura 23 – Ecrã do Menu ........................................................................................................... 48
Figura 24 – TTL, situação verde ................................................................................................. 49
Figura 25 – Modo Regatta ........................................................................................................... 50
Figura 26 – Vista no Google Earth do trajecto no modo Regatta ............................................... 51
Figura 27 – Exemplo de tabela Posição ..................................................................................... 52
Figura 28 – Menu ........................................................................................................................ 53
Figura 29 – Configuration ............................................................................................................ 53
Figura 30 – Definição da corrente ............................................................................................... 54
Figura 31 – Definição da bóia de bombordo ............................................................................... 54
Figura 32 – Distance to Buoy ...................................................................................................... 55
Figura 33 – Master Countdown ................................................................................................... 55
Figura 34 – Possíveis ecrãs no modo TTL ................................................................................. 56
Figura 35 – Exemplo do ecrã TTL com a indicação Time to Buoy ............................................. 57
Figura 36 – Modo Regatta ........................................................................................................... 57
Figura 37 – Recta de largada ...................................................................................................... 65
13
Figura 38 – Intersecção ............................................................................................................... 67
Figura 39 – Distância à intersecção ............................................................................................ 67
Figura 40 – Tipos de intersecção ................................................................................................ 68
Figura 41 – Posições da linha de largada ................................................................................... 69
Figura 42 – Relações entre a linha de largada e a tangente do seu rumo ................................. 70
Figura 43 – Comparação do rumo do barco com o rumo da linha ............................................. 71
Figura 44 – Comparação do rumo do barco com o rumo da linha (2) ........................................ 72
Figura 45 – Corrente contra ........................................................................................................ 75
Figura 46 – Corrente a favor ....................................................................................................... 75
Figura 47 – Intersecção com a linha de largada ......................................................................... 75
Figura 48 – Efeito da corrente ..................................................................................................... 76
Figura 49 – Trajectória corrigida com corrente contra ................................................................ 77
Figura 50 – Trajectória corrigida com corrente a favor ............................................................... 77
Figura 51 – Translação da última estimativa .............................................................................. 78
Figura 52 – Regressão linear ...................................................................................................... 78
Figura 53 – Zona do teste de 15 de Abril de 2012 ...................................................................... 81
Figura 54 – Distance to buoy ...................................................................................................... 84
Figura 55 – Zona do teste e bóias .............................................................................................. 85
Figura 56 - Aproximações directas.............................................................................................. 86
Figura 57 - Aproximações com viragem de bordo a 5m da linha ............................................... 87
Figura 58 - Aproximações com viragem de bordo a 10m da linha ............................................. 87
Figura 59 - Aproximações com viragem de bordo a 20m da linha ............................................. 88
Figura 60 – Cálculo Distance to Buoy ......................................................................................... 89
Figura 61 - Percursos em linha recta .......................................................................................... 90
Figura 62 – Percursos em linha recta ......................................................................................... 90
Figura 63 - Percursos curva larga ............................................................................................... 91
Figura 64 – Percursos curva larga .............................................................................................. 91
Figura 65 - Percursos curva apertada ......................................................................................... 92
Figura 66 – Percursos curva apertada ........................................................................................ 92
14
15
Lista de Tabelas
Tabela 1 – Método iterativo de Bowring para determinar a latitude e a altitude ......................... 24
Tabela 2 – Comparação de sistemas relacionados .................................................................... 33
Tabela 3 – Tabela resumo dos testes ......................................................................................... 59
Tabela 4 - Análise comparativa final ........................................................................................... 61
Tabela 5 – Exemplos de ângulos da linha de largada ................................................................ 71
Tabela 6 – Características dos smartphones utilizados no teste ................................................ 81
Tabela 7 – Resultados TTL ......................................................................................................... 83
Tabela 8 - Características do smartphone .................................................................................. 85
Tabela 9 – Aproximações directas .............................................................................................. 87
Tabela 10 – Aproximações com viragem de bordo a 5m da linha .............................................. 87
Tabela 11 – Aproximações com viragem de bordo a 10m da linha ............................................ 87
Tabela 12 – Aproximações com viragem de bordo a 20m da linha ............................................ 88
Tabela 13 – Percursos em linha recta ........................................................................................ 90
Tabela 14 – Percursos curva larga ............................................................................................. 91
Tabela 15 – Percursos curva apertada ....................................................................................... 92
16
Lista de Abreviaturas
BD: Base de Dados 44
D-GPS: GPS Diferencial 23
ECEF: Earth-centered Earth-fixed system, Sistema fixo centrado na Terra 20
EGNOS: European Geostationary Navigation Overlay Service, Sistema Europeu Complementar
Geoestacionário 24
ETRS89: European Terrestrial Reference System 89, Sistema Europeu de referência terrestre
1989 22
GALILEU: Sistema global de navegação por satélite europeu 18
GLONASS: Globalnaya Navigatsionnaya Sputnikovaya Sistema, Sistema global de navegação
por satélite 18
GPS: Global Positioning System, Sistema de Posicionamento Global 15
GPS: Navstar Global Positioning System, Sistema de posicionamento global 18
ITRS: International Terrestrial Reference System, Sistema internacional de referência terrestre 22
NMEA: protocolo de comunicação de dados de dispositivos electrónicos de navegação
marítima 27
PPP: Precise Positioning Service 18
SBAS: Satellite-based augmentation system 24
SO: Sistema Operativo 32
SPS: Standard Positioning Service 18
TTB: Time to Buoy, Tempo para a bóia 41
TTL: Time to Line, tempo para a linha 32
TTS: Time To Start, tempo para a largada 32
WGS 84; World Geodetic System 84, Sistema geodético mundial 1984 20
17
1 Apresentação
Nos últimos anos assistiu-se a uma grande proliferação de smartphones: telemóveis com
sistemas operativos semelhantes a computadores pessoais, embora adaptados. Estes
dispositivos vêm normalmente com diversos sensores, destacando-se o GPS: Global
Positioning System, Sistema de Posicionamento Global. Estando este hardware muito
acessível, começaram a surgir aplicações para o aproveitar, porque a inovação é facilitada por
não obrigar ao desenvolvimento de equipamento físico, o que coloca normalmente dificuldades,
nomeadamente de investimento monetário.
Uma regata de barcos à vela é um ambiente desafiante e por isso há sempre tentativas de
incorporar ajudas tecnológicas para apoiar a tomada de decisões com vista a melhorar os
resultados.
O objectivo deste trabalho foi criar uma ajuda para o skipper, o comandante da embarcação,
num momento crucial da competição, a largada, além de fazer também o registo de toda a
regata.
1.1 Contextualização do ambiente da aplicação
Para se perceber como se pode melhorar uma largada numa regata é necessário primeiro
perceber quais as suas regras de funcionamento. O júri da regata coloca duas bóias a indicar
os extremos da linha de largada, sendo uma a bóia de bombordo e a outra a de estibordo.
Cada barco terá de cruzar a linha entre as bóias num sentido em que tenha a bóia de
bombordo a bombordo da sua embarcação e a bóia de estibordo no seu estibordo. Não é
obrigatório que os extremos da linha sejam bóias, podendo estes extremos serem marcados
por o barco do júri ou até ser um ponto fixo em terra.
O júri define qual o tempo da Master Countdown, o tempo inicial da contagem decrescente
para o início da regata. O júri inicia e anuncia esta contagem decrescente e os barcos
manobram de forma a passarem a linha não antes da contagem chegar a zero, caso contrário
sofrem uma penalização.
Uma boa largada é aquela em que a linha é cruzada num tempo mínimo depois de a contagem
chegar a zero e com o barco na máxima velocidade. Na Figura 1 apresenta-se
esquematicamente uma situação típica de largada.
18
Figura 1 – Largada de uma regata
No contexto anunciado acima, considerou-se que se podia tirar partido de um smartphone com
GPS incorporado de forma saber se o percurso corrente de um barco é favorável ou
desfavorável a uma boa largada, uma vez que o GPS permite ler as posições ao longo do
tempo, marcar coordenadas e a partir delas efectuar cálculos por forma a estimar as posições
nos instantes futuros.
Existem outros factores que influenciam uma boa largada mas que não são considerados neste
trabalho, a saber: A posição relativa dos outros barcos é muito importante e pode anular a
melhor estratégia delineada antecipadamente; a direcção do vento, que em teoria devia ser
perpendicular à linha de largada mas que frequentemente o não é; a posição da bóia de
sotavento também pode ter como consequência que exista um lado privilegiado da linha para
se largar. As correntes também influenciam a largada e são tidas em contas nessa estratégia
Apesar de não contemplar estes factores, uma vez que se escolha um rumo e uma zona da
linha para largar o sistema que se desenvolveu será útil ao determinar o adiantamento ou
atraso do barco face à contagem decrescente da regata e permitir assim acções correctivas.
Apenas numa situação com muitos barcos em rumos que se intersectam e em que a regra
máxima é evitar as colisões é que o sistema não terá utilidade, pois haverá preocupações
superiores.
1.2 Questão central
Numa largada, como apresentar ao skipper uma previsão do tempo do percurso escolhido, por
forma a conseguir as melhores condições de rumo e velocidade?
1.3 Objectivos
Desenvolver uma aplicação para smartphones Android tendo como principais funcionalidades:
Previsão do tempo de cruzamento da linha de largada;
Registo do percurso efectuado durante a regata;
Interface especialmente cuidada para ser útil e legível num ambiente de regata.
A aplicação deve ainda:
19
Consumir um mínimo de energia;
Ter um custo mínimo de desenvolvimento e manutenção de modo a ter um preço de
venda ao público abaixo dos 10 Euros.
1.4 Estrutura da dissertação
Esta dissertação encontra-se dividida em cinco capítulos.
No primeiro capítulo é apresentada a contextualização deste trabalho, a questão central e
objectivos e a sua organização e estrutura.
No segundo capítulo é apresentado o estado da arte da tecnologia disponível, descrevendo-a e
analisando as suas capacidades e limitações. São também avaliados sistemas concorrentes ao
sistema desenvolvido.
O terceiro capítulo descreve a concepção da arquitectura do sistema, ainda
independentemente da plataforma escolhida. São apresentados os requisitos e descritos os
cálculos a efectuar por cada módulo.
O quarto capítulo contém os detalhes de implementação para a plataforma Android,
apresentando as opções tomadas para cada módulo. É também analisada a aplicação
desenvolvida e é avaliado o desempenho em termos de peso de cálculo e consumo de bateria.
Contém ainda a descrição dos testes e validações efectuados ao longo do desenvolvimento e a
determinação dos erros médios que o sistema inerentemente apresenta.
Finalmente, no quinto capítulo, apresenta-se as conclusões da dissertação.
20
2 Estado da arte
Neste capítulo são apresentadas as características dos sistemas de navegação por satélite. É
feita uma apresentação do sistema GPS, explicado o processo de obtenção das coordenadas e
dos erros existentes e também de métodos para diminuição dos mesmos. É apresentada e
justificada uma simplificação para o cálculo de coordenadas locais utilizada neste trabalho. É
também feita uma análise aos sistemas concorrentes, sistemas que partilham funcionalidades
ou objectivos com os do sistema descrito nesta dissertação.
2.1 Sistemas de navegação por satélite
Os sistemas de navegação por satélite são sistemas que utilizam uma constelação de satélites
artificiais em redor da Terra os quais enviam sinais para receptores, com vista à determinação
da sua posição geográfica em qualquer ponto do globo terrestre. O sistema percursor, o GPS,
provocou uma revolução em relação aos métodos de posicionamento anteriores por
acompanhar a posição em situações muito dinâmicas em termos de velocidade e posição; por
ter maior precisão e menor tempo de resposta; e por os receptores poderem ter uma dimensão
reduzida.
Actualmente estão disponíveis os sistemas GPS, desenvolvido na secção 2.2, e GLONASS:
Globalnaya Navigatsionnaya Sputnikovaya Sistema, Sistema global de navegação por satélite1,
operado pelo governo da Federação Russa.
Estão previstos novos sistemas, entre os quais o sistema europeu GALILEU: Sistema global de
navegação por satélite europeu2. O universo de utilização do GPS é muito abrangente e está
presente na maior parte dos smartphones, por isso foi o sistema escolhido para este trabalho.
O sistema russo GLONASS ainda é pouco utilizado no geral e por muito poucos modelos de
telemóveis (é utilizado na versão 4S do iPhone3).
2.2 GPS
O GPS: Navstar Global Positioning System, Sistema de posicionamento global (Department of
Defense - United States of America, 2008) é um sistema espacial de radionavegação
propriedade do governo dos Estados Unidos da América e mantido pela sua força aérea,
através do 2nd Space Operations Squadron. O sistema contém dois modos de funcionamento,
um preciso para fins militares, o PPP: Precise Positioning Service, e um menos preciso para
uso geral, o SPS: Standard Positioning Service, que é o utilizado em todos os dispositivos
correntes incluindo os smartphones utilizados neste trabalho. O SPS é transmitido na
frequência GPS L1, 1,57542 GHz e o PPP na frequência GPS L2, 1,2276 GHz.
1 http://www.glonass-ianc.rsa.ru/
2 http://www.esa.int/esaNA/galileo.html
3 http://www.apple.com/iphone/specs.html
21
O sistema está dividido em três segmentos: o espacial, o de controlo e o de utilização. O
segmento espacial é composto pela constelação de satélites e está disposto em 24 secções
geometricamente espaçadas em seis planos orbitais, com cada zona a conter pelo menos um
satélite.
O segmento de controlo faz a manutenção e a monitorização dos satélites. Existe uma estação
central de controlo, uma estação central de controlo de reserva, quatro antenas terrestres para
comunicação com os satélites e estações de monitorização distribuídas globalmente. O
segmento de controlo monitoriza os satélites e efectua operações de manutenção, como sejam
fazer o sincronismo diários dos relógios atómicos dos satélites ou identificar um satélite
avariado e identificar esse facto de forma acessível aos receptores para que estes não
considerem a sua informação.
Finalmente, o conjunto de receptores civis e militares constitui o segmento de utilização
(Department of Defense - United States of America, 2008).
2.2.1 Cálculo de coordenadas
Para determinar a posição é utilizada a técnica de trilateração. Através da diferença do tempo
entre a emissão do sinal e a sua recepção, e conhecendo a velocidade de propagação em
espaço livre (praticamente igual à velocidade da luz), é possível saber a distância do satélite ao
receptor. O receptor encontra-se numa esfera em redor do satélite. Ao ser acrescentado outro
satélite, podem intersectar-se as duas esferas e reduzir a incerteza a uma circunferência. Com
um terceiro satélite já se obtêm dois pontos, em que só um faz sentido por estar sobre o globo
terrestre.
Figura 2 – Trilateração (LANGLEY, 1991)
Se os relógios dos três satélites e do receptor estivessem sincronizados, a posição seria
determinada com exactidão. Na realidade, existem erros pequenos nos relógios dos satélites e
um erro maior no receptor, porque normalmente não dispõe de um relógio rigoroso. Como o
erro do relógio no receptor afecta o cálculo do raio de todas as esferas, é necessário calcular
esse erro. Um quarto satélite fornece essa informação temporal. A constelação de satélites
22
está disposta para que em cada ponto da Terra exista sempre a informação de quatro satélites
visíveis, desde que não haja obstruções no terreno. Para fazer estes cálculos também é
necessário saber em que posição cada satélite se encontra. Essa informação é fornecida pela
efeméride, que vai sendo continuamente enviada por cada satélite e que contém a sua órbitra
precisa. O GPS usa um sistema de coordenadas cartesianas tridimensional, com origem no
centro do globo terrestre, que gira com a Terra para facilitar os cálculos, o ECEF: Earth-
centered Earth-fixed system, Sistema fixo centrado na Terra . É neste sistema que são
efectuados os cálculos antes de serem convertidos para latitude, longitude e altitude.
Como a distância medida no receptor é influenciada pelo erro no relógio do receptor, é
chamada de pseudo-distância. Pode ser definida por
(1)
sendo a velocidade da luz no vazio e o atraso do sinal medido no receptor com o erro
do relógio no receptor destacado na componente . Tendo as pseudo-distâncias dos quatro
satélites e tendo quatro incógnitas, três da posição e o erro temporal do receptor, podemos ter
um sistema de equações:
√
(2)
√
(3)
√
(4)
√
(5)
sendo as posições do satélite que neste caso pode tomar os valores 1, 2, 3 e 4. Este
sistema é não linear e pode ser resolvido de diversas formas, obtendo-se no final a posição
no sistema ECEF, além do erro de tempo no receptor (Kaplan, et al., 2006).
2.2.2 Transformação de coordenadas
Para converter as coordenadas calculadas para latitude, longitude e altitude é necessário ter
um modelo físico do globo terrestre, que não é esférico mas pode ser aproximado a um
elipsóide. O GPS usa o WGS 84; World Geodetic System 84, Sistema geodésico mundial 1984,
representado em corte na Figura 3, juntamente com um ponto de observação.
23
Figura 3 – Modelo elipsoidal da terra (Kaplan, et al., 2006)
O raio equatorial é representado por e representa o raio polar, sendo o centro do
elipsóide. é o ponto de observação, a altitude face à superfície da terra e a sua latitude (a
longitude não está representada na figura por se tratar de um corte no plano equatorial). N é
o ponto da elipsóide mais perto do ponto de observação e o vector entre os dois pontos cuja
intersecção no plano equatorial é representada por . é o vector do centro da terra ao ponto
de observação e e o vector entre o centro da terra e o ponto N.
A longitude ( ), não representada na figura é o ângulo entre o vector e o eixo dos , medido
no plano
{
(
)
(
)
(
)
Para a latitude é necessário prolongar a normal do ponto de observação e medir o ângulo
com o plano equatorial ( ). A altitude é calculada medindo a distância . Estas duas
componentes não resultam de uma solução directa, como acontece com a longitude, é
necessário utilizar métodos numéricos. Um dos métodos mas utilizados é o método de
Bowring, descrito na Tabela 1 (Kaplan, et al., 2006). Nesta tabela é a excentricidade do
elipsíode da terra.
√
(
) (
)
Ciclo de iteração
24
(
)
até que convirja, então
√
caso contrário
Tabela 1 – Método iterativo de Bowring para determinar a latitude e a altitude
Quando se pretende utilizar as coordenadas fornecidas pelo GPS sobre uma carta topográfica,
é necessário ter em conta qual o sistema de referência utilizado na carta e se é necessário
fazer alguma conversão para se poderem utilizar as coordenadas fornecidas pelo GPS. Na
Europa utiliza-se actualmente o ETRS89: European Terrestrial Reference System 89, Sistema
Europeu de referência terrestre 1989, muito próximo do WGS 84 mas que se vai afastando
todos os anos. No ETRS89 a placa da Eurásia é considerada estática, para que as
coordenadas nessa região não se alterem com os desvios das placas tectónicas, que no caso
da Eurásia se desloca 2,5 cm por ano. O WGS84 é baseado no ITRS: International Terrestrial
Reference System, Sistema internacional de referência terrestre que tem como origem o centro
de massa da terra. Existem fórmulas de conversão entre os dois sistemas, assim como entre
outros sistemas de coordenadas globais, de modo a poder-se fazer a medição num sistema de
coordenadas mas consegui-la representar num sistema diferente (Kaplan, et al., 2006).
2.2.3 Precisão
A precisão da posição calculada é afectada por inúmeros factores, correspondendo a diversas
fontes de erro, incluindo diferenças entre a órbita real e a indicada na efeméride, erros no
relógio do satélite, efeitos relativísticos, efeitos atmosféricos, ruído na recepção, interferências
e efeitos multi-caminho. A seguir detalham-se as suas características individuais e qual o
desvio padrão na pseudo-distância, segundo (Kaplan, et al., 2006).
Os erros de relógio dos satélites são os erros dos relógios atómicos que equipam os satélites e
que são corrigidos uma vez por dia pela estação de controlo em terra. O seu desvio padrão é
de 1,1 m
Os erros de efeméride são devidos à diferença entre a órbita real dos satélites e a indicada na
efeméride transmitida. O seu desvio padrão é de 0,8 m.
Os erros troposféricos são provocados principalmente pela troposfera mas também pelas
camadas superiores e contém uma componente “seca”, função da pressão e da temperatura e
uma componente “molhada” que é função da distribuição do vapor de água. O seu desvio
padrão é de 0,2 m.
25
Os erros de multi-caminho acontecem quando há reflexões ou difracções do sinal noutros
objectos e o receptor recebe essas réplicas, juntamente com o sinal original. O seu desvio
padrão é de 0,2 m.
Os erros de ionosfera são causados por atrasos no sinal no momento em que atravessa a
ionosfera, cuja carga é alterada pela exposição à radiação solar. O seu desvio padrão é de
mas mas como estão fortemente correlacionados entre satélites a sua influência para o erro de
posição é inferior a este valor e dependente da geometria dos satélites utilizados para os
cálculos, segundo (Kaplan, et al., 2006).
O ruído na recepção é causado pelas condições específicas de recepção e equipamento
utilizado. O seu desvio padrão é de 0,1 m..
Os erros relativísticos afectam a recepção do relógio do satélite mas a sua frequência é
ajustada para que o receptor não tenha de efectuar cálculos de correcção e “veja” a frequência
“correcta”. Outro efeito relativista está relacionado com a rotação da terra durante a
transmissão do sinal, Sagnac effect, que é possível de corrigir no receptor, estando disponíveis
vários métodos para esse efeito.
A precisão normalmente anunciada de 30 metros é para uma situação desfavorável, numa
localização desfavorável e com um ou dois satélites não operacionais de entre o total da
constelação, que tem no mínimo 24 satélites. É útil para se conhecer a precisão garantida a
95%, mas é um valor demasiado afastado das precisões correntes caso queiramos considerar
uma situação normal. Para um dispositivo receptor é possível calcular a precisão das
coordenadas obtidas, porque o valor decorre directamente dos cálculos que o receptor é
forçado a efectuar. O número mínimo de satélites para se obter a posição é quatro, mas como
a distribuição espacial dos satélites também afecta a precisão, é vantajoso ter o máximo de
satélites disponíveis para serem seleccionados os mais vantajosos para um cálculo preciso
(Department of Defense - United States of America, 2008).
2.2.4 Técnicas de aumento da precisão
Para algumas aplicações, a precisão fornecida pelo GPS (métrica) é insuficiente (ex:
cartografia). Nessas situações é necessário recorrer a outras técnicas para se obter uma
precisão superior.
O D-GPS: GPS Diferencial utiliza uma ou mais estações de referência equipadas com um
receptor GPS que fazem a comparação entre os sinais recebidos, a posição estimada e a
posição real, que é conhecida. Comparando os valores é possível calcular as correcções dos
dados não tratados recebidos para se obter a posição correcta: informação da pseudo-
distância, relógio dos satélites ou efeméride. A estação de referência envia a correcção a
efectuar aos dados, ou os dados que recebeu a um receptor móvel nas proximidades para este
poder efectuar a correcção da posição, conforme esquematizado na Figura 4.
26
Figura 4 – D-GPS (Kaplan, et al., 2006)
A razão para o funcionamento do D-GPS aumentar a precisão é que se o receptor estiver nas
proximidades da estação de referência o seu sinal de GPS recebido terá praticamente as
mesmas componentes de erro que a estação de referência, tão mais idênticas quando a
proximidade da referida estação. Como a estação de referência está numa posição conhecida
e precisa consegue determinar o erro do sinal recebido pela diferença entre a sua posição real
e a indicada pelo GPS. Uma vez determinado esse erro é necessário transmiti-lo ao receptor.
Essa transmissão é normalmente efectuada via rádio numa frequência específica. O receptor
recebe os valores de correcção do sinal e introduz essa correcção no momento de calcular a
posição, obtendo no final a posição corrigida. Esta técnica permite aumentar a precisão até ao
decímetro, desde que existam estações de referência suficientes e é utilizada para cartografia.
Outra utilização é para a navegação marítima, para aumentar a fiabilidade, no caso de algum
satélite da constelação estar avariado isso poderia dar origem a um erro de posição grave num
navio perto da costa. Nesse caso o sistema consegue detectar essa avaria e dar indicação ao
receptor para não considerar esse satélite nos cálculos da posição.
Os sistemas de SBAS: Satellite-based augmentation system contêm a parte de D-GPS, mas a
correcção do sinal é enviada por um grupo de satélites em órbita geoestacionária. Existem
vários sistemas, entre os quais um europeu, o EGNOS: European Geostationary Navigation
Overlay Service, Sistema Europeu Complementar Geoestacionário (Kaplan, et al., 2006).
Os valores dos erros, nas suas diversas componentes, da versão corrente do GPS, desde que
foi desligada a Selective Availabilty em 2000, variam lentamente com o tempo. Para o uso do
D-GPS as correcções fornecidas ainda são válidas vários minutos depois de serem calculadas.
Por exemplo, os resultados de uma experiência em (Monteiro, 2005) confirmam que 4 minutos
depois das correcções o erro cresceu muito pouco. Este facto é relevante para este trabalho
porque os cálculos são feitos em posições relativas entre si e num curto intervalo de tempo,
especialmente os cálculos mais importantes de rumo e velocidade, que são os que afectam
mais os resultados, e que decorrem num intervalo de cinco segundos.
27
2.2.5 Cálculo de coordenadas locais
Para cálculos de distâncias e rumos locais, é possível fazer duas simplificações para tornar os
cálculos mais simples e menos pesados computacionalmente, por ser esta também uma
preocupação deste trabalho, visto ser desenhado para dispositivos de características diversas.
Na primeira simplificação consideramos a terra esférica, o que torna mais rápida a
determinação de distâncias e ângulos entre duas coordenadas locais. Como o elipsóide tem
um achatamento nos pólos de cerca de 21 km (Kaplan, et al., 2006) e os cálculos são feitos
entre coordenadas locais, esta aproximação é válida, excepto nas imediações dos pólos. Na
segunda simplificação utilizamos um sistema cartesiano bidimensional para serem evitados
problemas de projecções. De notar que, por ser esta uma aplicação para regatas, a informação
da altitude nunca é necessária. Para fazer esta segunda aproximação, necessitamos de utilizar
os cálculos da corda entre dois pontos, em vez de considerar a distância pelo perímetro da
circunferência, conforme representado na Figura 5. A distância percorrida pelo perímetro é
para um ângulo em radianos e raio . Para o mesmo ângulo, a distância da
corda é
. Para um ângulo de 0,001 graus, a que corresponde uma distância de
perímetro de 1014,4928 m, o desvio entre as duas fórmulas é de 1mm ou 0,00000011%, por
isso esta é uma aproximação válida para distâncias reduzidas, quer para o modo largada em
que a linha de partida é reduzida em relação a estes valores, quer para cálculos durante o
modo regata em que os pontos para os quais são feitos os cálculos são ainda mais próximos.
Figura 5 – Distância corda e perímetro
𝑑𝑝
𝑑𝑐
28
2.3 Sistemas concorrentes
Foi feita uma pesquisa sobre sistemas existentes no mercado que anunciam algumas
funcionalidades semelhantes ao sistema realizado neste trabalho. Aqueles que tinham algumas
das características pretendidas são desenvolvidos nas secções seguintes.
Quando se designa um sistema por dispositivo autónomo isso significa que se trata de uma
aplicação que corre num equipamento físico desenvolvido especificamente para esse sistema .
2.3.1 Prostart
O Prostart (Velocitek) é um dispositivo autónomo que, através de um GPS integrado, calcula a
distância perpendicular à linha de largada e o tempo restante até ao início da regata. A posição
daquela linha é definida levando o barco (o dispositivo) a uma e a outra das suas
extremidades. Com este aparelho é simples conhecer a distância perpendicular à linha e
conjugar essa informação com o tempo restante para optimizar a partida. Contudo, não é feita
nenhuma predição de velocidade nem uma estimativa do momento em que a linha de largada
será cruzada.
Depois da partida, o sistema regista e apresenta a direcção, a velocidade e alterações de
vento.
É anunciada uma precisão de velocidade de 0,2 nós. O chipset do GPS instalado é o u-blox
LEA-5M. A precisão do chipset é de 2,5m sem SBAS e 2m com SBAS (UBlox) (Velocitek).
O sistema não considera a corrente no mar e não inclui D-GPS nem correcção da distância até
à proa. É vendido por 599 dólares.
Figura 6 – Velocitek ProStart (Velocitek)
2.3.2 Sailclever
O Sailclever (SailClever) é uma aplicação para Windows Mobile que pode ser executada em
smartphones ou PDAs. Os extremos da linha de largada podem ser definidos inserindo as suas
coordenadas ou indo directamente aos locais e dando indicação ao dispositivo, premindo um
botão nos locais das bóias. Apresenta a contagem decrescente da regata e estima o tempo de
passagem do barco à linha. É possível introduzir a declinação magnética, o comprimento do
barco e o vento. Antes da regata podemos inserir o percurso a efectuar.
29
Existem seis modos disponíveis para estimar o tempo à linha: cinco usando o vento e as
polares para pontos diferentes da linha e um através do cálculo directo com o rumo e
velocidades actuais (dead reckoning).
Existe uma versão para dispositivos com GPS (86 dólares) e outra para Bluetooth com ligação
aos instrumentos do barco (527 dólares). A primeira utiliza o GPS do smartphone para efectuar
os cálculos e a segunda recebe informação dos instrumentos do barco (posição, rumo,
velocidade e vento), desde que tenham saídas NMEA: protocolo de comunicação de dados de
dispositivos electrónicos de navegação marítima (SailClever).
Figura 7 – Sailclever (SailClever)
2.3.3 iRegatta
O iRegatta (Let's Create) é uma aplicação para táctica de regatas para iPhone e iPad. Pode
utilizar o GPS do dispositivo ou de instrumentação externa através de uma ligação NMEA.
Possui uma funcionalidade para o início da regata. As coordenadas da linha são marcadas indo
a ambos os extremos e marcando as posições. Depois do timer (contagem decrescente da
regata) activado, é apresentado o tempo para a linha, o tempo do timer, e a distância à linha.
Se for inserida a direcção do vento, é apresentada uma indicação de qual o extremo mais
favorável para a partida. Não é considerada a corrente nem a distância entre o dispositivo e a
proa e não utiliza GPS diferencial. Depois da partida é apresentada a direcção, o vento, a
velocidade e a velocidade útil. Esta aplicação é vendida por 9,99 dólares (Let's Create).
30
Figura 8 – iRegatta (Let's Create)
2.3.4 Sail Racing
O Sail Racing (Pepette.com) é uma aplicação para iPhone que calcula a distância à linha de
largada. A linha é marcada indo com o barco a ambos os extremos. É apresentada a distância
à linha e calculado o tempo até a mesma ser cruzada. A estimativa do tempo à linha é
efectuada recorrendo à velocidade e à distância à linha e é possível calcular marcando apenas
um dos pontos da linha. No entanto, não é explicado se é feito o cálculo até esse ponto ou se
existe alguma ajuda direccional sobre a linha de partida. É possível definir um offset, por
exemplo para a distância entre o dispositivo e a proa. Não é considerada a corrente e não é
utilizado GPS diferencial. É vendido por 7,99 dólares (Pepette.com).
Figura 9 – Sail Racing (Pepette.com)
2.3.5 Regatta Tactic Compass
O Regatta Tactic Compass (Embedia) é uma aplicação para Android que dispõe de um modo
de linha de largada com cálculo do tempo restante do timer, tempo até cruzar a linha e
distância aos dois extremos da linha. Os extremos da linha podem ser marcados indo aos
pontos ou sobre um mapa do Google Maps. Também é possível marcar pontos, para pontos da
regata ou extremos da linha, usando um cruzamento de direcções.
Depois da partida apresenta e regista a posição, direcção e velocidade. A direcção pode ser
determinada recorrendo à bússola do smartphone ou ser retirada do GPS, caso a velocidade
31
seja superior a cinco quilómetros/hora. Não existe informação sobre a corrente e não é
utilizado GPS diferencial. Existe uma versão limitada gratuita e outra completa por 5 euros
(Embedia).
Figura 10 – Regatta Tactic Compass (Embedia)
2.3.6 RockBox A.M.P.D.
O RockBox A.M.P.D. (Advance Mobile Performance Device) é um dispositivo autónomo que
contém um GPS e que disponibiliza diversas funcionalidades, entre elas a «Time to the line»,
que estima o tempo restante para a linha de largada ser cruzada a partir da velocidade actual e
da posição, a distância e o tempo até à largada. Os pontos da linha são marcados com o barco
sobre os mesmos, sendo possível posteriormente fazer correcções. Segundo o fabricante,
trata-se de uma funcionalidade em fase experimental. O dispositivo dispõe de Wide Area
Augmentation System (disponível na América do Norte e no Havai) para melhorar a precisão
do GPS. É vendido por 600 dólares (RockCityMarine) (Rock City Marine, 2009).
Figura 11 – ROCKBOX (RockCityMarine)
2.3.7 Nauteek SC200
O Nauteek SC200 (Nauteek) é um dispositivo autónomo com GPS com uma funcionalidade
Start Line para calcular a distância perpendicular à linha de partida. Os extremos da linha são
marcados atingindo as posições individualmente e é necessário um comprimento mínimo da
linha de 30 metros. É possível definir a direcção do vento e com essa indicação é sugerido o
32
extremo da linha mais favorável para a largada. Não é feita uma previsão sobre o instante em
que a linha será cruzada. É vendido ao preço de 550 euros (Nauteek).
Figura 12 – Nauteek SC200 (Nauteek)
2.3.8 Análise comparativa
Para a pesquisa e comparação dos sistemas relacionados foram definidas quais as
características consideradas relevantes. Os principais objectivos deste trabalho estão
relacionados com o tempo imediatamente antecedendo a largada, por isso a característica
mais importante é o modo Time to Line. Como a precisão das coordenadas obtidas pelo GPS
influencia os cálculos, a existência de D-GPS também foi considerada. O cálculo das correntes
e a correcção à proa também foram considerados A clareza da informação disponibilizada,
nomeadamente a facilidade de leitura e ajudas visuais e auditivas, também foi comparada.
Finalmente o preço e a plataforma também são importantes por questões de acessibilidade ao
máximo de utilizadores. Esta comparação é apresentada na Tabela 2.
Sistema Tipo TTL D-GPS Corrente Proa Visual Áudio Preço
Prostart Dispositivo
autónomo
Não Não Não Não Bom Não 599 US$
Sailclever Aplicação
Windows
Mobile
Sim Não Não Sim Complicado Não 86 US$
iRegatta Aplicação
iPhone
Sim Não Não Não Demasiada
informação
Não 9,99 US$
Sail Racing Aplicação
iPhone
Sim Não Não Sim Razoável Não 7,99 US$
Regatta
Tactic
Compass
Aplicação
Android
Sim Não Não Não Complicado Não Gratuito
RockBox Dispositivo Sim Não Não Não Bom Não 600 US$
33
Sistema Tipo TTL D-GPS Corrente Proa Visual Áudio Preço
A.M.P.D. autónomo
Nauteek
SC200
Dispositivo
autónomo
Não Não Não Não Bom Não 550 €
Tabela 2 – Comparação de sistemas relacionados
Na primeira coluna da tabela é indicado o nome do sistema e na segunda qual o seu tipo. A
coluna TTL indica se o sistema dá indicação de Time to Line. A utilização de GPS diferencial é
indicada na coluna D-GPS. A correcção das correntes é apresentada na coluna Corrente e a
correcção da distância à proa na coluna Proa. A coluna Visual faz uma avaliação qualitativa da
informação visual apresentada em termos de clareza e simplicidade para o utilizador,
considerando eventuais ajudas visuais disponíveis, para o modo TTL. A coluna Áudio indica se
existe ajuda áudio para o modo TTL. O preço é indicado na última coluna.
Nesta tabela pode observar-se que nenhum dos sistemas tem D-GPS nem cálculo de
correntes. Só dois apresentam correcção à proa e não têm cálculo Time to Line. Alguns têm
uma boa apresentação visual mas nenhum tem informação clara e apoiada em cores como
gostaríamos. Nenhum tem ajudas auditivas para o modo TTL. Todos os dispositivos
autónomos são dispendiosos mas os restantes sistemas necessitam de considerar o custo de
hardware para as suas aplicações serem utilizadas, embora essas plataformas móveis sejam
de utilização generalizada, com diferenças consoante o caso específico.
Desta análise concluímos que há lugar para um sistema de baixo custo que contenha todas as
características aqui analisadas e que esse sistema pode ser útil para apoio ao processo de
decisão para a largada de uma regata e ainda incluir outras funcionalidades úteis.
34
3 Arquitectura do sistema
Neste capítulo descreve-se a arquitectura do sistema a desenvolver, quais as opções tomadas
e a sua razão. Em primeiro lugar são apresentados os requisitos. Seguidamente descreve-se a
arquitectura geral do sistema e os módulos que a compõem, além de se apresentar uma
sequência de eventos para exemplificar a relação entre as diversas componentes. Depois
descreve-se em detalhe cada um dos módulos. Neste capítulo chama-se módulo a cada
componente porque estamos na fase de concepção do sistema. No capítulo 4, em que se
descreve a implementação, cada módulo é depois transposto para o tipo de componente
existente no sistema em que se está a fazer a implementação.
3.1 Requisitos
O objectivo do trabalho é desenvolver a primeira parte de um sistema de gestão de regatas
com duas macro funcionalidades: 1- Efectuar a estimativa do tempo de passagem do barco na
linha de largada; e 2- registar para posterior upload o percurso efectuado.
3.1.1 Principais
Implementação para smartphones com SO: Sistema Operativo Android;
Apresentar o TTS: Time To Start, tempo para a largada, com fácil leitura. Possibilidade
de o utilizador definir o valor inicial desta contagem decrescente;
Marcar as coordenadas das extremidades da linha de largada (que também podemos
designar por bóias) via: a) Carregar num botão da aplicação quando o utilizador se
encontra fisicamente junto da mesma extremidade; B) Indicação indirecta das
coordenadas a partir do outro ponto previamente marcado e do rumo e distância até ao
ponto a marcar;
Leitura pela aplicação das coordenadas em cada instante, acedendo ao GPS do
smartphone;
Determinar a velocidade sobre o solo, e o rumo, recorrendo à posição actual e ao
histórico recente de posições;
Determinar o rigor dos cálculos que deram origem à velocidade e ao rumo para poder
informar o utilizador de forma evidente, utilizando a cor cinzenta, caso o rigor esteja
abaixo de um limiar a definir analisando os resultados experimentais de percursos
realizados;
Apresentar o TTL: Time to Line, tempo para a linha, tempo restante até ao barco cruzar
a linha de partida, sempre que for possível determinar o seu valor. O valor tem de ser
apresentado com fácil leitura e acompanhado de uma sinalização sonora e da cor de
fundo do ecrã que indica a sua comparação com o TTS (superior ou inferior) e se o
cruzamento da linha será efectuado na direcção correcta e entre as bóias definidas;
Registar o percurso durante a regata e construir um ficheiro para ser visualizado sobre
a aplicação Google Earth utilizando as funcionalidades de partilha de ficheiros do
smartphone.
35
3.1.2 Secundários
Utilizar nos cálculos a distância entre a proa e o receptor, valor inserido pelo utilizador;
Efectuar a correcção do TTL considerando o efeito das correntes, quando tal
informação (rumo e velocidade da corrente) é introduzida pelo utilizador.
3.2 Arquitectura global
Os módulos funcionais apresentados na Figura 13 e descritos nas secções seguintes
correspondem a uma segmentação por áreas das tarefas que a aplicação necessita executar.
Também permite criar um isolamento entre os diversos módulos de forma a permitir
futuramente desenvolver componentes novas sem afectar o resto do sistema. Por exemplo, a
posição fornece as coordenadas actuais recorrendo ao GPS. Posteriormente podem ser
acrescentados blocos funcionais invocados pela posição para calcular as correcções por SBAS
ou outras sem ser necessário efectuar alterações em outros pontos da aplicação.
Posição
Base de dados
Estimativa
Menu
TTL Regatta
GPS
Figura 13 – Módulos
Nas secções seguintes são apresentados em pormenor cada um destes blocos mas, para se
perceber melhor o fluxo global é apresentado na Figura 14, num diagrama de sequência UML
para o modo TTL. De realçar que o funcionamento é totalmente assíncrono, pelo que são
possíveis todas as combinações de intercalações entre os processos. Para o modo Regatta o
diagrama é idêntico, à excepção da última coluna, que corresponde à Regatta, substituindo o
TTL.
36
Posição Estimativa TTLTabela Posição Última Estimativa
Escreve Posição
Ler últimas posições
Últimas posições
Escreve estimativaLer estimativa
Estimativa
Escreve Posição
Escreve Posição
Escreve Posição
Escreve Posição
Escreve Posição
Escreve Posição
Escreve Posição
Escreve Posição
Ler últimas posições
Últimas posições
Escreve estimativa
Ler últimas posições
Últimas posições
Escreve estimativa
Ler estimativa
Estimativa
Ler estimativa
Estimativa
Ler estimativa
Estimativa
Ler estimativa
Estimativa
Ler estimativa
Estimativa
Ler estimativa
Estimativa
Ler últimas posições
Últimas posições
Ler últimas posições
Últimas posições
Ler últimas posições
Últimas posições
Ler últimas posições
Últimas posições
Escreve estimativa
Escreve estimativa
Escreve estimativa
Figura 14 – Diagrama de sequência para o modo TTL
3.3 Menu
O módulo Menu é o menu da aplicação. Ao ser iniciado, inicia também os módulos Posição e
Estimativa. Contém vários botões de configuração: nome da regata, corrente (rumo e
velocidade), marcação das coordenadas da bóia e o barco do júri, marcação de um dos
extremos com direcção e distância e definição do tempo da Master Countdown. No final,
existem dois botões para iniciarem os modos TTL e Regatta. Ao ser iniciado um destes modos,
os respectivos módulos substituem o módulo Menu, que só continua quando esses módulos
são terminados. Também existe uma opção de configurações gerais da aplicação.
Na Figura 15 é apresentado o diagrama UML do fluxo do módulo Menu.
37
EstimativaBase de DadosMenu TTLPosição Regata
Sair
Botão Regata
Botão TTL
Botão Countdown
Cancela-se Posição
Inicia-se Posição
Cria-se BD
Aguarda-se comando
Botão Name
Botão Current
Botão Buoy P
Botão Buoy SB
Botão Dist.Bouy
Configurar Nome
Configurar Corrente
Marcar posição Bóia BB
Marcar posição Bóia ES
Marcar posição Bóia
Configurar TPP
BD criada
Posição iniciada
Fim Posição
Iniciar TTL
Iniciar Regata
TTL Regata
Inicia-se Estimativa Estimativa iniciada
Cancela-se Estimativa Fim Estimativa
Configuration Configurar Countdown
Figura 15 – Módulo Menu
Os botões para marcar os extremos da linha de partida necessitam ler a posição no momento
em que se passa com a embarcação junto à bóia e junto ao barco do júri. Como o módulo
Posição está activo a ler posições, podemos recorrer à última posição lida como
correspondendo à posição actual, confirmando que é muito próxima (menor que o intervalo de
tempo de leitura do GPS) do instante em que se pretende marcar o ponto. Também é possível
introduzir manualmente as coordenadas dos extremos da linha de largada. Na Figura 16
apresenta-se o diagrama UML da caixa de diálogo onde é feita essa definição. Corresponde
aos botões do menu Buoy P (Port) e Buoy SB (Starboard). Este processo inicia-se no momento
em que se prime os botões Bouy P e Buoy SB e quando termina regressa ao Menu.
38
Última PosiçãoMenu
Apresentam-se coordenadas memorizadas
Aguarda-se comando
Botão Mark with GPS Lê-se Posição mais recente
Calcula-se atraso
Escreve-se posição no controlo
Mensagem de erro
Botão OK Guardar coordenadas
[<= Intervalo amostragem]
[Outros casos]
Botão Swap P <-> SB Trocar coordenadas
Figura 16 – Marcação da bóia de bombordo
3.4 Posição
O módulo Posição é executado em paralelo e obtém e guarda a posição actual utilizando o
GPS do dispositivo. Na Figura 17 apresenta-se o seu diagrama UML de fluxo. É o módulo
Menu quem inicia o módulo posição e este fica em execução até a aplicação sair (não
representado no diagrama). O módulo está em ciclo a receber posições e depois de receber
uma posição actualiza a Última Posição. Se a aplicação estiver no modo TTL ou Regatta é
acrescentada uma entrada na tabela de posição e invocada a Estimativa para esse módulo ir
fazer os cálculos para obter a estimativa.
39
Última Posição EstimativaMenu Posição Tabela Posição
Inicia-se GPS
Aguarda-se nova posição
Escreve-se posição
Inicia-se Posição
Calcula Estimativa
Escreve Última Posição
[Modo TTL ou Regatta] [Outros modos]
Figura 17 – Módulo Posição
3.5 Estimativa
O módulo Estimativa efectua os cálculos da posição, velocidade e rumo do barco consultando
o histórico recente de valores obtidos pelo Módulo Posição e guardados na tabela Posição da
Base de dados. É aplicado um algoritmo de regressão linear com o método dos mínimos
quadrados para tentar suavizar os erros de posição. Este serviço é iniciado e terminado pelo
módulo Menu e o cálculo é activado pelo módulo Posição após ter sido escrita uma nova
posição na tabela de posições. Na Figura 18 é apresentado o diagrama UML do fluxo deste
módulo e das suas relações.
40
Posição Última EstimativaEstimativa Tabela PosiçãoMenu
Inicia-se Estimativa
Aguardar chamada
Ler últimas posições
Regressão linear
Escreve estimativa fiável
Escreve estimativa não fiável
Chamada a Estimativa
[R2 > limiar fiabilidade]
[R2 <= limiar fiabilidade]
Figura 18 – Módulo Estimativa
Este módulo tem a função de obter a estimativa da posição, rumo e velocidade da embarcação.
O objectivo é fornecer essa informação ao módulo TTL, que irá fazer os cálculos de
intersecção à linha de partida, e ao módulo Regata, para apresentação no ecrã e gravação em
ficheiro interno para upload do percurso no fim da regata.
Como a velocidade antes da partida é relativamente reduzida (normalmente menos de cinco
nós), o erro da posição do Módulo Posição é relevante (alguns metros) para um ritmo de
amostragem de cerca de um segundo. De forma a serem obtidos valores mais fiáveis, é
necessário considerar um período de tempo maior (o que permitirá um menor erro de posição)
e utilizar uma técnica de suavização de valores e predição do rumo e velocidade.
Nesse sentido, optou-se por usar uma regressão linear com últimas posições obtidas pelo
Módulo Posição, utilizando o método dos mínimos quadrados. Este método devolve-nos uma
recta, de onde retiramos o rumo. A partir dos pontos nas extremidades transpostos para a
recta, obtemos a distância percorrida, permitindo-nos retirar a velocidade, dado que
conhecemos o intervalo de tempo. A posição que a estimativa considera corresponde à última
posição transposta para a recta devolvida pela regressão. No anexo Regressão Linear estão
descritos os detalhes dos cálculos da regressão linear.
No final do cálculo da regressão está disponível a informação sobre o coeficiente de
determinação ( ), que é tanto maior quanto maior for a aproximação dos pontos ao modelo de
regressão estimado. É definido um valor limiar de , abaixo do qual se prosseguem os
cálculos mas dando um aviso ao utilizador de que os dados não são fiáveis, por os valores da
41
regressão estarem longe dos dados reais, sendo essa informação passada juntamente com o
valor da estimativa para o módulo TTL utilizar uma interface específica para esse caso.
3.6 Time to Line (TTL)
Este módulo calcula o ponto de intersecção do rumo calculado com a linha de largada,
estimando, com o conhecimento da velocidade, o tempo previsto em que será cruzada a linha,
e apresenta esse tempo, a que se tem chamado Time to Line (TTL) na metade inferior do ecrã.
Se for iniciada a opção TTS, o respectivo relógio decrescente é apresentado na metade
superior do ecrã, independentemente dos processos descritos a seguir. O módulo TTL lê na
variável partilhada Última Estimativa a posição, velocidade, rumo e instante em que se
encontra a embarcação e calcula se vai haver intersecção com a linha de partida (no sentido
correcto ou não). Se o TTS estiver inactivo o ecrã tem fundo preto e não existem avisos
sonoros. Se estiver activo são apresentadas cores de fundo e avisos sonoros conforme
descrito a seguir.
Se não houver intersecção, apresenta o ecrã a azul sem estimativa de tempo. Se houver
intersecção mas fora do segmento de recta da partida, o ecrã também fica a azul mas é
apresentada a estimativa de tempo para o ponto de intersecção. Se houver intersecção, é
estimado o tempo restante para a mesma e apresentado no ecrã. Se o sentido for incorrecto, o
ecrã fica a azul. Se for correcto, mas num instante anterior ao momento da partida, o ecrã
passa a vermelho e é acompanhado de um aviso sonoro agudo e de ritmo rápido e, no caso de
ser num momento posterior à partida, o ecrã tem cor verde e o som é mais grave e com um
ritmo de metade da situação a vermelho. Se o modo TTS estiver activo quando o tempo chegar
a zero, a aplicação comuta automaticamente para o modo Regatta, terminando este módulo.
Na Figura 19 é apresentado o fluxo deste módulo. O Timer é um relógio que invoca os cálculos
uma vez por segundo, para ir actualizando a interface a esse ritmo. Não está representada a
transição para o modo Regata nem a saída para o módulo Menu. Também não está
representada o início do TTS que é provocado por um botão nas opções ou no ecrã e que
activa a condição na zona inferior do fluxo. Os cálculos do TTL estão descritos em pormenor no
anexo 7.1.
42
Última EstimativaTTLMenu
Inicia-se Timer
Esperar Timer
Lê-se estimativa
Cálculo Intersecção
Cálculo TTL
Fundo azul[Não intersecção]
[Intersecção]
Fundo azul[Sentido errado]
[Sentido correcto]
[TTL < TTS]
[TTL >= TTS]
Fundo verde
Fundo vermelho
Apresenta TTL
Calcula TTS
Apresenta TTS
[TTS activo]
[TTS inactivo]
Inicia-se TTL
Som grave
Som agudo
Figura 19 – Módulo TTL
43
3.6.1 Correcção devida às correntes
Antes da largada é por vezes conhecida informação sobre a corrente no mar nessa zona.
Como existe um certo ângulo entre o rumo do barco e a direcção da sua linha longitudinal,
dada a existência de uma corrente na água, é útil corrigir em conformidade o valor fornecido
pelo cálculo de TTL. Considerando uma direcção e uma velocidade da corrente da água e uma
distância do dispositivo à proa do barco é possível efectuar o cálculo para compensar o
momento em que a proa atinge a linha de largada, conforme descrito no anexo 7.1.2.
3.6.2 Time to Buoy (TTB)
Quando um barco se dirige à linha de largada num rumo quase paralelo a essa linha, a
indicação do TTL é pouco útil porque qualquer variação de rumo altera muito a distância
calculada e assim o ponto de intersecção do rumo do barco com a linha de largada se desloca
rapidamente. Situação semelhante também acontece quando se faz uma aproximação à linha
de largada navegando paralelamente a essa linha e esperando o momento e o lugar oportunos
para se dirigir à linha. Para esses casos, que são frequentes, existe o modo TTB: Time to
Buoy, Tempo para a bóia, que faz um cálculo simplificado do tempo até ambas as bóias
considerando a distância e a velocidade do barco e ignorando o seu rumo. Representa por isso
o tempo restante assumindo que o barco se dirige até a uma das bóias com a velocidade
actual.
3.7 Regatta
O módulo de Regatta regista o percurso efectuado durante a regata, apresentando ao utilizador
a estimativa do rumo e da velocidade. Também tem um relógio com a duração da regata.
O modo Regatta pode ser iniciado directamente no menu da aplicação, tendo nesse caso o
utilizador de indicar no botão de opções o momento de início do relógio. Caso se esteja no
modo TTL e o TTS chegue ao fim, a aplicação automaticamente termina o módulo TTL e inicia
o modo Regatta e o seu relógio.
No final da regata o utilizador deve parar o relógio no botão de opções e posteriormente pode
fazer upload do percurso, o qual foi sendo registado enquanto o relógio esteve activo.
Os valores apresentados no ecrã do modo Regatta são o rumo, a velocidade e a duração da
regata, os quais são fornecidos pelo módulo Estimativa.
3.8 Base de dados
Como é necessário guardar um histórico de coordenadas com muitas entradas optou-se por
utilizar uma Base de Dados para arquivo, por ser um modo eficiente de lidar com muita
informação. É também útil para guardar de um modo persistente informação de cálculos
intermédios para permitir analisar eventuais problemas. Na Figura 20 apresenta-se o diagrama
da base de dados.
44
Posição
IDTempoTempo sistemaLatitudeLongitudeDuração
Estimativa
IDID2ID1NumRumoVelocidadeTempoLatitudeLongitudeR2CinzentoDuração
TTL
IDNumTempoIntersectaTTLDuraçãoCinzento
Bóias
IDTempoLatitude PLongitude PLatitude SBLongitude SB
Evento
IDTempoDescrição
Figura 20 – Base de Dados
A tabela Posição guarda as posições (coordenadas) e o seu instante recebidas do módulo
Posição, quer sejam lidas em ambiente real ou com dados simulados. É a única tabela
necessária para o funcionamento da aplicação, sendo as restantes descritas a seguir apenas
utilizadas quando se pretende guardar informação para despiste de erro ou análise de
desempenho.
A tabela Estimativa guarda o intervalo de registos da tabela Posição utilizado para o cálculo da
estimativa e o seu resultado (rumo, velocidade, latitude, longitude, instante de tempo e duração
dos cálculos), que é escrito na variável partilhada Última Estimativa.
A tabela TTL tem a referência do registo da tabela Estimativa utilizado para os cálculos e
guarda informação sobre o resultado do cálculo do TTL: se há intersecção, tempo até à
intersecção, cor a apresentar no ecrã e duração dos cálculos.
A tabela Bóias guarda a posição das bóias marcadas, as suas coordenadas, o instante de
tempo e de que bóia se trata (bombordo ou estibordo).
A tabela Evento armazena alguns eventos e o seu instante, início do TTS, fim do TTS, início da
regata e fim da regata.
Todos os registos de todas as tabelas são apagados quando se define um nome para a regata
diferente do anterior. A opção entre guardar apenas o essencial (tabela Posição) ou toda a
informação é efectuada no botão Options no menu da aplicação, opção Trace DB.
45
4 Implementação na plataforma Android
A arquitectura descrita no capítulo anterior poderia ser implementada em várias plataformas. O
processo de selecção restringiu-se a duas plataformas: iOS (iPhone OS) e Android, por serem
as mais utilizadas em smartphones. De entre estas duas optou-se por Android por:
Existirem mais fontes de informação sobre os detalhes da plataforma e muitos fóruns
de debate sobre desenvolvimento;
Ter neste momento mais utilizadores e estar instalada em equipamentos de várias
gamas de preços, tendo por isso um maior número de potenciais utilizadores.
4.1 Arquitectura da plataforma
O Android é um sistema operativo para smartphones cujo desenho é baseado numa
arquitectura Unix4. As aplicações para esta plataforma são desenvolvidas em Java. As
aplicações por omissão correm num processo próprio em ambiente protegido numa máquina
virtual. É implementada uma lógica de menor privilégio em que cada aplicação corre apenas
com as permissões para realizar as suas tarefas, com o objectivo de criar um ambiente seguro.
Figura 21 – Arquitectura Android5
Na Figura 21 é apresentada a arquitectura do SO. Existem as seguintes camadas:
4 http://developer.android.com/about/index.html
5 http://developer.android.com/images/system-architecture.jpg
46
Aplicações (linguagem Java e executadas na máquina virtual Dalvik);
Bibliotecas e serviços da framework (linguagem Java);
Bibliotecas e serviços nativos (linguagem C ou C++);
Kernel do SO (inclui controladores de dispositivos, acesso à rede, sistema de ficheiros
e comunicação inter-processos.
As aplicações têm quatro tipos de componentes (Android Developers, 2012):
Actividade (ecrã com user interface);
Serviço (corre em background, normalmente para realizar operações demoradas e
não prejudicar a resposta da interface);
Content provider (dados, file system, BD: Base de Dados SQLite, etc.);
Broadcast receiver ("anúncios").
4.2 Concretização da arquitectura funcional
A arquitectura descrita no capítulo 3 foi implementada nesta plataforma. Para isso foi
necessário identificar os tipos de módulos existentes e definir quais seriam os recursos em
Android a utilizar para cada um. A um nível macroscópico existem três tipos de módulos:
módulos com interface para o utilizador, módulos que são executados em background e
conteúdos de dados. Para a primeira situação utilizaram-se actividades, para a segunda
serviços e para a terceira uma base de dados e variáveis partilhadas. Na Figura 22 é
apresentado um modelo da implementação global e nas secções seguintes é feita a descrição
de cada módulo e é indicado de que forma foi implementado. Na Figura 22 as setas a negrito
representam o fluxo de dados, as setas em traço normal invocações e a que está a tracejado
uma invocação diferida de um serviço.
47
Actividades Content Providers Serviços
BD
Menu
Regatta
Última Estimativa
Regressão linear
Location Manager
Estimativa
Posição
Cálculo TTL
TTL
Última Posição
Figura 22 – Arquitectura da implementação em Android
Foi necessário proteger com semáforos os conteúdos partilhados para evitar problemas de
concorrência. Assim, cada variável partilhada está protegida por um semáforo, bem como o
acesso à base de dados. Uma explicação mais detalhada é apresentada nas secções
respectivas, 4.4 e 4.5.
O Software Development Kit não é muito robusto e algumas componentes não funcionam. Por
exemplo existe um emulador para o sensor de GPS, que seria muito útil durante o
desenvolvimento mas infelizmente tem erros e provoca o encerramento forçado de todo o
ambiente de desenvolvimento. Por isso foi necessário construir um mini simulador embebido no
código para simular posições utilizando timers e uma função para ir construindo um percurso.
O ambiente de desenvolvimento utilizado foi o Eclipse, versão 3.7.16.
4.3 Menu
O menu da aplicação é uma actividade que permite várias configurações e lançar o módulo
TTL e Regatta, além de iniciar o módulo Posição.
Quando o utilizador faz back no menu a aplicação deixa de ser visível mas na realidade não é
terminada, continua a ser executada. Este é o funcionamento recomendado para aplicações
Android (Android Developers, 2012). No entanto se não fosse efectuado mais nada os serviços
continuavam a correr desnecessariamente e a consumir recursos, incluindo o GPS. Por isso,
quando o utilizador faz back a aplicação memoriza essa situação em variáveis de estado, para
6 http://www.eclipse.org/
48
que quando os serviços voltem a ser executados deixem de fazer as chamadas ao sistema que
os mantêm activos de forma a deixarem de correr e de consumir recursos.
Para conveniência do utilizador todas as configurações são guardadas no momento que sai da
aplicação e carregadas novamente na próxima chamada à aplicação. De salientar que caso o
utilizador prima a tecla home a aplicação continua a ser executada em background, o que é
também recomendado para a plataforma.
Figura 23 – Ecrã do Menu
4.4 Posição
O módulo Posição é implementado como um Serviço para ser executado em paralelo com a
actividade em curso de modo a não bloquear a interface, caso seja de resposta demorada.
Para a aplicação ler as coordenadas da posição, é utilizado o Location Manager, um recurso do
sistema operativo Android. O Location Manager pode utilizar várias fontes para estabelecer a
posição: Wi-Fi, rede GSM e GPS. Para esta aplicação só o GPS fornece uma precisão
suficiente, por isso é a fonte utilizada. No arranque da aplicação inicia-se automaticamente o
Location Manager e configura-se o tipo (GPS), o ritmo e as condições das actualizações de
posição, através do método Request Location Updates. É possível definir uma distância
mínima e um tempo mínimo para receber as actualizações. Como para este trabalho, mesmo
quando o barco está parado, é importante uma actualização das posições, para alimentar
correctamente o cálculo da estimativa, apenas é configurado o tempo mínimo e não a distância
mínima. No SO Android, é recomendado que não sejam recebidas actualizações a um ritmo
superior a 1 Hz e, de facto, muitos dispositivos não asseguram um ritmo superior evitando
grandes consumos de bateria. Neste trabalho o tempo definido foi de um segundo.
O serviço Posição é executado de cada vez que é recebida uma actualização das coordenadas
GPS. Essas coordenadas são lidas e escritas na tabela Posição na base de dados e na
variável partilhada Última Posição, para a situação em que se está a marcar os pontos da linha
49
de largada e ainda não se guardam as posições na base de dados por não ser necessário
(Android Developers, 2012).
Também existe um modo de simulação, configurável nas opções, em que são produzidas
coordenadas a partir de uma posição fixa, com direcção constante e velocidade crescente,
para ser possível testar o funcionamento da aplicação no ambiente de desenvolvimento. Para
isso é lançado um timer com o ritmo definido que activa este serviço para depois serem criadas
novas coordenadas e serem armazenadas na Base de Dados ou na variável partilhada.
4.5 Estimativa
A Estimativa é um Serviço que vai ler as últimas entradas na tabela Posição. Com o conjunto
de valores lido é feita uma regressão linear pelo método dos mínimos quadrados e colocado o
resultado na variável partilhada Última Estimativa para ser lida pelo módulo TTL ou Regatta.
Caso os últimos valores lidos não sejam recentes (5 segundos) ou o coeficiente de
determinação7 (R
2) devolvido pela regressão linear seja baixo (menor ou igual a 0,3) a
estimativa é considerada não fiável.
4.6 Time to Line (TTL)
O Time to Line (TTL) é uma Actividade que se inicia quando o utilizador prime o botão TTL no
menu da aplicação. Efectua os cálculos para a linha de partida e apresenta-os aos utilizadores,
incluindo uma contagem decrescente, o Time to Start (TTS), que pode ser iniciado, reiniciado e
parado nesta actividade. O algoritmo está descrito na secção 3.6 e os cálculos no anexo 7.1.
Em termos de implementação foi necessário ter algum tipo de timer com ritmo de um segundo,
o ritmo a que se pretende que sejam apresentados valores no ecrã. Inicialmente utilizou-se um
recurso que criava um timer permanente (TimerTask) mas mais tarde optou-se por utilizar um
Handler, que permite enviar uma mensagem ao fim de um tempo definido ao processo. Tomou-
se esta opção por consumir menos recursos do SO e não ser necessário efectuar o seu
cancelamento como acontecia com o timer inicialmente escolhido.
Figura 24 – TTL, situação verde
7 Medida da aproximação do modelo à realidade dos dados. Varia entre zero e um e quanto
maior for melhor é o modelo.
50
4.6.1 Correcção devida às correntes
Para ser mais eficiente, o cálculo das correntes é efectuado antes do cálculo do TTL,
efectuando uma translação da posição actual. Depois é invocado o cálculo do TTL
normalmente com esta nova posição. Os cálculos desta correcção podem ser encontrados no
anexo 7.1.2.
4.7 Regatta
O módulo Regatta foi implementado como uma Actividade e apresenta os valores de rumo,
velocidade e tempo da regata, este último apenas se a regata estiver iniciada. Quando se inicia
a regata, vai sendo construído o ficheiro do percurso com uma fracção periódica (1 em cada 5)
dos pontos registados pelo módulo Posição.
O modo Regatta pode ser iniciado de duas formas, manualmente premindo o botão Regatta no
menu ou automaticamente no modo TTL quando o countdown (TTS) chega a zero.
Figura 25 – Modo Regatta
4.8 Upload do trajecto
Enquanto a regata está a decorrer, i.e., enquanto a aplicação está no modo Regatta com o
timer activo, vai sendo construído o ficheiro do percurso realizado para posterior upload e
visualização na aplicação Google Earth. Inicialmente implementou-se a escrita do ficheiro
apenas no instante em que o utilizador pretendia efectuar o upload do mesmo, mas verificou-se
ser um processo muito demorado (vários minutos) transmitindo uma má experiência de
utilização. Por isso reformulou-se o processo para o ficheiro ser escrito ao longo do percurso,
distribuindo esta tarefa e tendo-se o ficheiro completo quando o utilizador seleccionar o botão
de upload. Nesse momento, o ficheiro é enviado para a partilha e o utilizador dispõe das
opções de partilha que estiverem disponíveis no seu telefone, tipicamente correio electrónico,
Bluetooth, dropbox, etc. Para que o ficheiro não seja demasiado grande, só é acrescentado um
ponto de 5 em 5 segundos, o que ainda permite uma leitura do percurso com grande detalhe,
como se pode ver na Figura 26. Posteriormente, incluiu-se neste ficheiro as posições das bóias
que delimitam a linha de largada. Ainda em relação à figura 26, a confusão de trajectórias
51
anteriores ao início do TTS que se vêm junto a linha de largada foi eliminada de modo a obter
uma descrição mais limpa da regata.
Figura 26 – Vista no Google Earth do trajecto no modo Regatta
4.9 Base de dados
É usado o gestor de base de dados SQLite por ser suportado nativamente em ambiente
Android. O modelo implementado foi o da Figura 20 do capítulo da Arquitectura do sistema.
Excepto quando se está a guardar informação para análise, activando o modo Trace DB, a
aplicação apenas preenche a tabela Posição. Isto acontece para melhorar o desempenho,
porque acrescentar uma entrada numa tabela consome recursos do sistema operativo.
No modo de análise, com a opção Trace DB activa, são criadas entradas nas tabelas,
Estimativa, TTL, Bóias e Eventos, conforme explicado na secção 3.8.
Como o SQLite não garante a concorrência em ambientes multi-thread, é necessário proteger
os acessos à BD com semáforos nas situações em que podem ocorrer problemas de
concorrência. No caso de estar a serem inseridos dados é necessário acesso exclusivo ao
ficheiro (SQLite). Na aplicação existe um acesso de leitura, na Estimativa, um de escrita na
Posição e em modo Trace DB acessos de escrita na Estimativa, TTL e ao marcar bóias e a
efectuar alguns eventos. A implementação normal seria aplicar um algoritmo Leitores-
Escritores (Downey, 2008) para esta situação mas como só há um acesso de leitura não existe
vantagem em utilizar um algoritmo mais complexo. Por esta razão implementou-se um
esquema de acesso exclusivo com semáforos para cada pedido.
52
Os semáforos são uma forma de controlar o acesso a recursos partilhados e controlar o
número de acessos. Cada pedido de acesso é validado pela existência das unidades
necessárias no semáforo, sendo impedido o acesso se não estiverem disponíveis unidades
suficientes, ficando o pedido em espera. Ao serem efectuadas as tarefas sobre o recurso
partilhado são devolvidas as unidades anteriormente pedidas para que outro acesso
subsequente consiga aceder ao recurso. Assim, todos os acessos à leitura ou escrita nas
tabelas da base de dados são efectuados com recurso a um semáforo de controlo.
É ainda feita uma gestão de versões que permite que sejam introduzidas alterações
futuramente e que os dispositivos clientes façam a actualização das tabelas ao instalarem
novas versões. Na Figura 27 apresenta-se um exemplo dos dados armazenados na tabela
Posição.
Figura 27 – Exemplo de tabela Posição
53
4.10 Interface
Figura 28 – Menu
O menu da aplicação, que surge quando a mesma é iniciada é apresentado na Figura 28. Na
opção Configuration do menu da aplicação existem definições para a distância à proa,
declinação magnética do local e escolha da forma de apresentação dos rumos: em graus
magnéticos ou geográficos, conforme apresentado na Figura 29.
Figura 29 – Configuration
No botão Name definimos o nome da regata. Esta operação é o momento em que a informação
anterior é apagada: os dados da base de dados, o ficheiro de percurso, as posições das bóias
e a informação da corrente. Este processo ocorre apenas quando o nome é diferente do que
estava definido. Não é apagada a informação sobre a distância à proa, a declinação magnética
e a definição da Master Countdown.
54
Em Current definimos a direcção e intensidade da corrente, conforme apresentado na Figura
30. Esta informação é depois considerada nos cálculos do TTL, caso tenham sido introduzidos
valores.
Figura 30 – Definição da corrente
Nos botões Buoy P e Buoy SB damos indicação para marcar os pontos das bóias da linha de
largada (também com a opção de inserir directamente as coordenadas). É possível também
trocar as bóias de bombordo com a de estibordo (Swap P <-> SB).
Figura 31 – Definição da bóia de bombordo
O botão Dist.Buoy permite definir um extremo da linha utilizando o outro extremo e uma
direcção e rumo. No ecrã, apresentado na Figura 32 são apresentadas as coordenadas de
ambas as bóias. A bóia mais recente tem os botões bloqueados e a mais antiga tem os botões
activos, desde que a bóia mais recente tenha uma posição marcada há menos de uma hora. O
utilizador insere o rumo e a distância, da bóia conhecida para a bóia a calcular, nos campos
Course e Distance e carrega no botão para ser calculada a posição: Calc P Buoy ou Calc SB
Buoy para serem calculadas as coordenadas para a bóia por marcar. Após esta operação as
coordenadas são apresentadas e o utilizador deve premir o botão de OK respectivo para gravar
as novas coordenadas e sair do ecrã.
55
Figura 32 – Distance to Buoy
Em Countdown define-se o tempo inicial da contagem decrescente desde o sinal do júri até ao
momento da largada, ecrã apresentado na Figura 33.
Figura 33 – Master Countdown
O modo TTL é utilizado nos momentos anteriores à largada, em que os barcos são
manobrados de forma a conseguir uma posição o mais favorável possível para a largada.
Nesse sentido as indicações estão reduzidas ao essencial para que sejam de rápida e fácil
percepção. De acordo com a Figura 34, a cor de fundo representa a situação do barco face à
linha de largada e ao momento em que o sistema prevê que a cruzará. Se o TTS não estiver
iniciado a cor é preta. A cor verde é utilizada para quando o barco cruzar a linha depois do
momento da largada na direcção correcta. Se o barco cruzar a linha adiantado, aparece um
fundo vermelho. Finalmente, se o barco não estiver num rumo que o faça passar pela linha
56
(paralelo à linha ou afastando-se dela), ou num rumo para a linha mas no sentido contrário, o
fundo é azul. Na parte de cima do ecrã é apresentado o TTS e na parte de baixo o TTL. Quanto
a avisos sonoros, existe um som grave (frequência fundamental de 167Hz) de ritmo baixo
(período de 1,5 segundos) para o cenário da cor verde e outro agudo (frequência fundamental
de 781Hz) e mais rápido (período de 0,64 segundos) para o cenário vermelho. A indicação do
tempo TTS só aparece caso tenha sido seleccionada essa opção num botão de opções deste
ecrã. Caso o barco cruze a linha de partida mas no sentido errado é calculado a apresentado o
tempo restante para a intersecção mas com fundo azul. Caso os valores a apresentar não
sejam considerados fiáveis o fundo é cinzento.
Figura 34 – Possíveis ecrãs no modo TTL
Dentro do ecrã TTL é possível activar simultaneamente o cálculo Time to Buoy (TTB) utilizando
o botões de opções e seleccionando Start TTB. Este é apresentado no topo do ecrã com os
tempos para as bóias de bombordo e de estibordo, respectivamente, como se apresenta na
Figura 35.
57
Figura 35 – Exemplo do ecrã TTL com a indicação Time to Buoy
No modo Regatta é apresentado o rumo do barco, a velocidade em relação ao solo e o tempo
desde o início da regata. Existem dois botões no menu de opções para iniciar e reiniciar (Start /
Re-start) e terminar (Stop) o relógio da regata. A situação de reiniciar reinicia a contagem
imediatamente caso já tenha sido iniciada, sem necessidade de fazer primeiro Stop.
Figura 36 – Modo Regatta
4.11 Compatibilidade
A plataforma Android tem inúmeros dispositivos e várias versões do sistema operativo a serem
utilizadas simultaneamente, ao contrário do que sucede com outras plataformas para
smartphones, como por exemplo o iPhone. Isto coloca problemas de compatibilidade difíceis de
resolver para o que seria necessário ter acesso a dispositivos com todas as versões e realizar
um número muito elevado de testes.
A abordagem seguida foi a de seguir os conselhos de desenvolvimento (Android Developers,
2012) no que respeita à compatibilidade para a plataforma e testar exaustivamente a aplicação
58
em dois smartphones diferentes na fase de desenvolvimento. Posteriormente forneceu-se a
aplicação a utilizadores seleccionados de modo a recolher a sua experiência de utilização e
identificar e resolver eventuais problemas.
A versão mínima do sistema operativo definida foi a 2.1, por versões anteriores serem já
antigas e pouco utilizadas por smartphones recentes. As versões testadas foram a 2.1 e a
2.3.3. Os telemóveis utilizados foram o tmn a5 e o Samsung Galaxy SII.
4.12 Desempenho
O desempenho da aplicação foi avaliado a dois níveis, rapidez de execução e consumo da
bateria. No desenvolvimento do projecto foram seguidas as recomendações (Android
Developers, 2012) para optimizar as operações e foi armazenada informação sobre a duração
dos cálculos. A informação recolhida das colunas de tempo de cálculo das tabelas
armazenadas em modo Trace apresentou valores de 1 milissegundo para o cálculo de cada
módulo, pelo que podemos considerar o desempenho rápido. Em termos de experiência de
utilização, a sensação sentida pelo utilizador, é também muito rápida, não se notando atrasos
na resposta aos comandos inseridos nem nas actualizações da aplicação. Uma excepção foi a
criação do ficheiro do percurso efectuado, que para percursos de algumas horas se tornava
muito demorada (cerca de 15 minutos) e bloqueava a aplicação ao não dar resposta aos
comandos do utilizador. Esta funcionalidade foi por isso replaneada para ser feita
incrementalmente ao longo da regata, em vez de totalmente no momento do upload. Depois de
implementadas as alterações, este problema de lentidão deixou de se verificar.
O consumo de bateria relevou-se elevado, em média 25% da carga total dos dois telemóveis
utilizados por cada hora e meia de utilização. Tal é atribuível à utilização do GPS que tem um
consumo elevado nestes smartphones, esgotando a sua carga rapidamente, com o mesmo
ritmo que observámos nesta aplicação. Pela necessidade da sua utilização este problema é
incontornável, apesar de não ter uma importância excessiva e de permitir a realização de
regatas de até seis horas, dependendo do smartphone utilizado, podendo-se utilizar
alimentação externa para durações superiores.
4.13 Validações
Foram efectuados muitos testes no terreno ao longo do desenrolar do projecto. Os mais
relevantes estão detalhados no anexo 7.3. Os testes permitiram validar as funcionalidades da
aplicação e foram importantes para serem efectuadas alterações que a corrigiram e
melhoraram. Estes testes mostram que as premissas iniciais se verificaram e que foi possível
desenvolver uma aplicação para atingir os requisitos propostos inicialmente.
A metodologia seguida para a generalidade dos testes foi a seguinte:
Estabelecer uma zona para a realização do teste;
59
Estabelecer uma linha de partida, sinalizando os seus extremos de bombordo e
estibordo;
Um elemento do júri junto à linha;
Sincronização do TTS da aplicação com um relógio com contagem decrescente
disponível pelo júri;
Estabelecimento e realização de percursos cruzando a linha de largada;
Registo dos instantes de passagem da linha;
Avaliação qualitativa da interface;
Análise dos resultados.
Na Tabela 3 é apresentado um resumo dos testes realizados. O primeiro teste foi realizado
com o objectivo de verificar o funcionamento básico da aplicação. Os testes seguintes foram
validando mais funcionalidades até testar o funcionamento total da aplicação. Entre os testes a
aplicação foi melhorada de acordo com os resultados obtidos. Depois dos testes de 17 e 18 de
Fevereiro a interface foi bastante redesenhada com vista a melhorar o uso. Depois do teste de
15 de Abril decidiu-se que o Serviço Estimativa deixaria de correr num timer próprio e passaria
a ser invocado pelo Serviço Posição, com vista a diminuir o atraso da apresentação dos
resultados ao utilizador. O valor da redução desse atraso era variável, porque os timers eram
assíncronos mas na hipótese de timers mais desfavorável essa redução era de um segundo.
Depois da versão de 6 de Maio foi corrigida a funcionalidade Distance to Buoy e feitas
alterações às cores dos ecrãs e aos sons. O teste de 7 de Junho teve como objectivo
determinar o valor a seleccionar para o coeficiente de determinação, por isso depois do mesmo
a aplicação foi alterada para passar a utilizar esse valor. O erro médio do TTL para os testes
realizados com a versão final do cálculo TTL é de um segundo.
Teste Objectivo Funcionamento Interface Erro
médio
TTL
17/2/2012 Funcionalidades básicas. 100% Bom
18/2/2012 Funcionalidades principais. 100% Insuficiente
15/4/2012 Todas as funcionalidades
excepto upload do trajecto.
Utilização de dois smartphones.
100% Bom 0,91s
6/5/2012 Todas as funcionalidades. 91% (Distance to
Buoy não
funcionou
correctamente).
Bom 1,02s
7/6/2012 Estudar o comportamento do
coeficiente de determinação .
Teste ao upload do trajecto.
100% Bom
Tabela 3 – Tabela resumo dos testes
60
5 Conclusões e trabalho futuro
O objectivo desta dissertação era o desenvolvimento de uma aplicação para smartphones para
efectuar o cálculo do tempo restante para a linha de largada, o tempo para cada bóia e o
registo e upload do trajecto efectuado durante a regata. Também era necessário que a
interface fornecesse a informação da forma mais intuitiva, simples e rápida de aperceber pelo
utilizador. Finalmente, que a aplicação consumisse um mínimo de bateria e tivesse um preço
baixo de venda ao público.
Foi desenhada uma arquitectura de implementação do sistema. Foi escolhida uma plataforma,
Android, e adaptada a arquitectura para as especificidades desta plataforma. Foi efectuada a
implementação do sistema, de acordo com os requisitos definidos.
Uma das componentes mais importantes foi a estimativa da velocidade e rumo para a
estimativa do tempo para a linha (TTL). Utilizando apenas dois pontos consecutivos recebidos
pelo GPS não era possível obter valores com erros que permitissem uma estimativa com um
erro reduzido, devido ao erro de posição do GPS que tinha a mesma ordem de grandeza das
diferenças de posição que ocorrem para as velocidades normais de uma situação pré-regata.
Por isso foi necessário incluir mais pontos nos cálculos e utilizar um método para extrair a
informação pretendida, rumo e velocidade. Foi escolhido fazer uma regressão linear utilizando
o método dos mínimos quadrados, por ser adequando na situação em que se pretende fazer a
estimativa, rumo e velocidades aproximadamente constantes e erro do GPS aleatório.
A aplicação foi testada em várias situações para aferir do seu correcto funcionamento e
hipóteses de melhorias, que foram depois também implementadas. O erro médio do TTL foi de
um segundo.
A aplicação concluída responde aos objectivos inicialmente traçados, demonstrando-se por
isso que com a tecnologia actual dos smartphones é possível criar uma aplicação deste tipo
que seja útil ao ambiente exigente de uma regata, incluindo uma interface verdadeiramente útil
para o skipper por se concentrar no essencial.
Na Tabela 4 volta-se a apresentar a tabela comparativa (Tabela 2) incluindo também na última
linha a aplicação desenvolvida neste projecto, que tem o nome Regatta TTL.
Sistema Tipo TTL D-GPS Corrente Proa Visual Áudio Preço
Prostart Dispositivo
autónomo
Não Não Não Não Bom Não 599 US$
Sailclever Aplicação
Windows
Mobile
Sim Não Não Sim Complicado Não 86 US$
61
Sistema Tipo TTL D-GPS Corrente Proa Visual Áudio Preço
iRegatta Aplicação
iPhone
Sim Não Não Não Demasiada
informação
Não 9,99 US$
Sail Racing Aplicação
iPhone
Sim Não Não Sim Razoável Não 7,99 US$
Regatta
Tactic
Compass
Aplicação
Android
Sim Não Não Não Complicado Não Gratuito
RockBox
A.M.P.D.
Dispositivo
autónomo
Sim Não Não Não Bom Não 600 US$
Nauteek
SC200
Dispositivo
autónomo
Não Não Não Não Bom Não 550 €
Regatta
TTL
Aplicação
Android
Sim Não Sim Proa Bom Sim <10 €
Tabela 4 - Análise comparativa final
Não foi possível utilizar neste trabalho técnicas de aumento da precisão do GPS, que
aumentariam a precisão da estimativa da posição, rumo e velocidade podendo melhorar os
resultados obtidos. Trata-se um possível trabalho futuro que seria interessante realizar.
Salienta-se no entanto que a precisão obtida é compatível com a capacidade de alterar
eficazmente o rumo e a velocidade de um barco na situação de largada.
Também seria interessante aproveitar a recolha da informação da posição para a enviar em
tempo real para um servidor disponível para a regata. Esse servidor poderia permitir fazer o
controlo da regata e também disponibilizar informação sobre a situação actual da prova para o
público em terra, que muitas vezes tem dificuldade em perceber o que se está a passar.
62
6 Bibliografia
Android Developers. 2012. Activities. Android Developers. [Online] 2012. [Citação: 20 de 3 de
2012.] http://developer.android.com/guide/topics/fundamentals/activities.html.
—. 2012. Android Compatibility. Android Developers. [Online] Android Developers, 26 de 7 de
2012. [Citação: 31 de 7 de 2012.]
http://developer.android.com/guide/practices/compatibility.html.
—. 2012. Application Fundamentals. Android Developers. [Online] 8 de 3 de 2012. [Citação: 21
de 3 de 2012.] http://developer.android.com/guide/topics/fundamentals.html.
—. 2012. Designing for Performance. Android Developers. [Online] Android Developers, 26 de
7 de 2012. [Citação: 31 de 7 de 2012.]
http://developer.android.com/guide/practices/performance.html.
—. 2012. Obtaining User Location. Android Developers. [Online] 2012. [Citação: 21 de 2 de
2012.] http://developer.android.com/guide/topics/location/obtaining-user-location.html.
Chapra, Steven C. e Canale, Raymond P. 2006. Numerical Methods for Engineers, fifth
edition. New York : Mc Graw Hill, International Edition, 2006. ISBN 007-124429-8.
Department of Defense - United States of America. 2008. Global Positioning System
Standart Positioning Service Performance Standart. 2008. 4th edition.
Downey, Allen B. 2008. The Little Book of Semaphores, Second Edition. s.l. : CreateSpace
Independent Publishing Platform, 2008.
Embedia. Regatta Tactic Compass User Manual ver. 5.0. [Online] [Citação: 8 de 10 de 2011.]
http://www.embedia.it/files/regatta/man_en_5_0.pdf.
Kaplan, Elliot D. e Hegarty, Christopher J. 2006. Understanding GPS: Principles and
Applications. Boston : Artech House, 2006.
LANGLEY, Richard B. 1991. The Mathematics of GPS. GPS World Magazine, Advanstar
Communications. July–August, 1991.
Let's Create. iregatta iphone/ipad. Let's Create. [Online] [Citação: 8 de 10 de 2011.]
www.letscreate.dk/letscreate/?q=node/1.
Monteiro, Luís Nuno Sardinha. 2005. The Portuguese DGPS network. Lisboa : Academia de
Marinha, 2005. ISBN 972-781-090-X.
Nauteek. Nauteek SC200. Nauteek. [Online] [Citação: 9 de 10 de 2011.]
www.nauteek.com/EN/index.php?page=3&prod=2.
63
—. User Guide NAUTEEK SC200. [Online] [Citação: 9 de 10 de 2011.]
www.nauteek.com/doc/docsc200/en/UGSC200_4en.pdf.
Pepette.com. Sail Racing. iTunes. [Online] [Citação: 8 de 10 de 2011.]
itunes.apple.com/app/sail-racing/id336538405?mt=8.
Rock City Marine. 2009. RockBox A.M.P.D. Operation Instructions. [Online] 2009. [Citação: 9
de 10 de 2011.] www.rockcitymarine.com/Downloads/RBampd007-009-000-
D/RockBox%20AMPD%20Instructions%20rev3-0.pdf.
RockCityMarine. RockBox. [Online] [Citação: 9 de 10 de 2011.] www.rockcitymarine.com.
SailClever. User Manual 3.0. [Online] [Citação: 5 de 10 de 2011.]
SQLite. File Locking And Concurrency In SQLite Version 3. SQLite. [Online] [Citação: 27 de 8
de 2012.] http://www.sqlite.org/lockingv3.html.
ttt3. 2009. dfdfd. dfd : dfd, 2009. dfdfd.
UBlox. LEA-5 module series u-blox 5 GPS and GALILEO receivers. [Online] [Citação: 5 de 10
de 2011.] www.u-blox.com/images/downloads/Product_Docs/LEA-
5_Prod_Summary%28GPS.G5-MS5-07071%29.pdf.
Velocitek. PROSTART. Technical Specifications. [Online] [Citação: 5 de 10 de 2011.]
www.velocitek.com/prostart/tech-specs.
64
7 Anexos
7.1 Cálculo Time to Line
Descreve-se os cálculos necessários e as condições para efectuar a previsão do Time to Line -
TTL e definir a cor de fundo do ecrã.
Os parâmetros de entrada para este cálculo são dois conjuntos, como se segue:
1 - As coordenadas dos extremos da linha de largada, em função da latitude e da longitude
O ponto A corresponde ao limite da linha de largada que fica a bombordo do barco quando este
está apontado para largar no sentido correcto. O ponto B é o outro extremo da linha de largada
(a entrada destes dados na interface assinala qual é qual e permite, com um botão, trocá-los):
(6)
(7)
Estes pontos A e B, o primeiro a bombordo e o segundo a estibordo, serão marcados a
encarnado e verde respectivamente. Esta orientação privilegiada permite encarar esta linha
não só como uma recta de equação y=m x, como veremos à frente, mas também como um
rumo, o qual tem a direcção da recta e o sentido de A para B. Este rumo da linha de largada
será dado em graus, sendo a direcção Norte geográfico igual a 0 ou 360º.
2 - A última estimativa obtida. Esta é composta pelas coordenadas da posição , rumo
do barco rb, velocidade do barco vb e instante de tempo t.
1. Cálculo das posições em coordenadas locais (rectangulares)
Como as distâncias são reduzidas, é possível fazer uma aproximação a um plano (x,y). Uma
das extremidades da linha é considerada a origem de coordenadas. Para os outros pontos as
diferenças de coordenadas, em graus, serão transformadas em distâncias, em metros. Ver
Figura 37.
Os extremos da linha são e
Sendo o ponto A a origem de coordenadas temos .
Para fazer a conversão de diferenças de graus em metros, vamos considerar a terra esférica
com um raio r = 6 371 008,7714 m8, aproximação correcta para pequenas distâncias. Neste
modelo todos os meios círculos máximos têm o mesmo comprimento: .
8 MORITZ, H., «Geodetic reference system 1980» in Journal of Geodesy, vol. 74. Number 1,
1980, p.131.
65
Assim sendo, a diferença de latitude do segundo extremo da linha em relação ao primeiro,
convertida em metros, é
(8)
Para a longitude, temos de considerar que o raio dos paralelos diminui à medida que nos
afastamos do equador em função do co-seno do ângulo de latitude. Assim, podemos calcular a
distância em metros correspondente à diferença em graus de longitude entre os dois pontos
pela seguinte expressão, considerando a latitude do ponto médio:
(
)
(9)
O segundo extremo da linha é descrito no plano, em metros, por:
, com e calculados acima.
A equação da recta da linha de partida, que passa pela origem do sistema de coordenadas, é
(10)
com
(11)
Desta forma, o sistema de coordenadas rectangulares (x,y) fica com o eixo dos yy apontado ao
Norte geográfico e o eixo dos xx apontado a Este, tal com mostra a Figura 37.
Figura 37 – Recta de largada
2. Cálculo da intersecção da direcção do movimento do barco com a direcção da linha de
largada
66
De acordo com a Figura 38, para a posição do barco no instante t, , é feita a
mesma conversão para metros, obtendo-se :
(
)
(12)
(13)
A partir do conhecimento do rumo do barco rb (entre 0 e 360), estabelece-se a equação da
direcção do movimento do barco:
Em que e
Note-se que rb pode vir em qualquer dos quatro quadrantes e que a tangente dá valores iguais
para o primeiro e terceiro quadrantes e para o segundo e quarto quadrantes. Este facto, para
já, não é importante mas sê-lo-á para os cálculos das intersecções.
Em seguida, será determinado o ponto de intersecção Pi(xi ,yi) entre as duas rectas, resolvendo
o sistema de duas equações a duas incógnitas (ponto que só não existe se as rectas forem
paralelas – m=mr):
(14)
(15)
A solução para o ponto de intersecção Pi(xi ,yi) dá:
e
67
Figura 38 – Intersecção
3. Cálculo da distância entre a posição do barco, no instante t e com o rumo do barco rb,
e o ponto de intersecção com a equação da linha de largada
Este cálculo faz-se com toda a generalidade, na sequência do conhecimento da posição do
barco no instante t,
(16)
e a posição da intersecção calculada atrás: Pi(xi ,yi), tal como se vê na Figura 39:
e
Figura 39 – Distância à intersecção
68
Essa distância pode ser calculada, em metros, pela seguinte expressão:
√
(17)
4. Cálculo do tempo a percorrer entre a posição do barco, no instante t, no rumo do
barco rb e com a velocidade do barco vb, e o ponto de intersecção com a equação da
linha de largada
Conhecida a distância dbi e a velocidade do barco vb, este tempo entre o barco e a intersecção
tbi calcula-se pela expressão:
em segundos
É este tempo que dará origem a uma sequência decrescente de contagem de tempo, desde tbi
até zero a que se chama TTL. Esta sequência é reiniciada sempre que qualquer dos seus
parâmetros (vb, rb) mude mais do que incrementos a definir.
É esta sequência TTL que se mostrará no ecrã em confronto com a contagem decrescente
TTS.
Este cálculo é válido em qualquer situação e poderá fazer-se continuamente, no modo TTL. De
facto, há quatro situações em que este resultado tem de ser discriminado (ver Figura 40),
dando origem a sequências futuras diferentes:
Figura 40 – Tipos de intersecção
1- O rumo do barco aponta para uma intersecção na linha de largada, entre bóias, e cortando a
linha no sentido correcto.
69
2- O rumo do barco aponta para uma intersecção na linha de largada, fora das bóias, e
cortando a linha no sentido correcto.
3- O rumo do barco aponta para uma intersecção na linha de largada, entre bóias, mas
cortando a linha no sentido errado.
4- O rumo do barco aponta para uma intersecção na linha de largada, fora das bóias, e
cortando a linha no sentido errado.
Descartam-se as situações em que não há intersecção porque o rumo do barco é paralelo à
linha de largada ou porque o barco aponta para um sentido oposto ao da linha de largada.
Para continuar com os cálculos que discriminem as quatro situações, é necessário primeiro um
outro cálculo, que veremos a seguir.
5. Como passar da equação da linha de largada para o rumo da linha de largada
Esta passagem é importante para discriminar entre as situações em que o barco cruza a linha
de largada no sentido correcto ou no sentido errado. Como se disse atrás, o sentido correcto
implica que o barco tenha a bóia A a bombordo e a bóia B a estibordo (apenas uma destas
condições é necessária).
Assim vamos atribuir à equação da linha de largada uma outra dimensão, isto é, vamos dar-lhe
um sentido privilegiado, ou seja, um rumo, a que chamamos o rumo da linha de largada, .
Vamos ver como relacionar o rumo da linha de largada, , com a inclinação da equação da
mesma linha: .
Conhecendo , calculado em (11), como se calcula ?
A Figura 41 mostra as quatro posições possíveis para a linha de largada (para os quatro
quadrantes).
Figura 41 – Posições da linha de largada
70
Na Figura 42 encontram-se as quatro situações com a relação entre o valor de e o
valor do rumo da linha de largada :
Figura 42 – Relações entre a linha de largada e a tangente do seu rumo
Em resumo, conhecida a inclinação da linha de largada m, calcula-se o rumo ru da linha de
largada pelas igualdades listadas em baixo, de acordo com as condições dos valores de x2 e
de y2, ou seja, do quadrante em que está a linha. Considerando os quadrantes em que os
algoritmos das funções trigonométricas são normalmente calculados, temos as seguintes
conclusões:
1º Quadrante – x2> 0 e y2> 0 ru=tg-1
(1/m) rad
2º Quadrante – x2> 0 e y2 <0 ru=tg-1
(1/m)+π rad
3º Quadrante – x2 <0 e y2 <0 ru=tg-1
(1/m)+π rad
4º Quadrante – x2 <0 e y2> 0 ru=tg-1
(1/m)+2*π rad
Note-se que este cálculo apenas se faz uma vez, quando se entra com as coordenadas de A e
de B. Fica assim definido o quadrante em que está a linha de largada. Os exemplos que se
apresentam na Tabela 5 ilustram estas condições:
71
Tabela 5 – Exemplos de ângulos da linha de largada
6. Identificação dos quatro tipos de intersecção da direcção do movimento do barco com
a direcção da linha de largada, e as cores do fundo do ecrã
Na Figura 43 verifica-se que um barco está a largar no sentido correcto, esteja a linha de
largada em qualquer quadrante, se o seu rumo for menor que o rumo da linha de largada ru
ou maior que .
Figura 43 – Comparação do rumo do barco com o rumo da linha
Assim, as situações 1 e 2, listadas no ponto 4, correspondentes às largadas em sentido
correcto, identificam-se pela relação:
(18)
As situações 3 e 4, correspondentes às largadas em sentido errado, identificam-se pela
relação:
(19)
Note-se que, quando (ru+180)> 360, é necessário subtrair 360 a (ru+180).
Quadrante a(graus) m=tga ru (rad) ru (graus)
1 30 0.58 1.05 60
1 60 1.73 0.52 30
2 -30 -0.58 2.09 120
2 -60 -1.73 2.62 150
3 60 1.73 3.67 210
3 30 0.58 4.19 240
4 -30 -0.58 5.24 300
4 -60 -1.73 5.76 330
72
Qualquer destas quatro situações, em princípio, dá origem aos cálculos da TTL mas implicam
uma cor diferente do fundo do ecrã para algumas delas, como se segue:
- 1 e 2 (sentido correcto): fundo verde, vermelho ou azul (a discriminar em seguida);
- 3 e 4 (sentido errado): fundo azul.
Para as situações 3 e 4, o cálculo termina neste ponto por não haver intersecção no sentido
correcto.
Temos então de separar a condição 1 da condição 2, ou seja, quando o barco está apontado
para cortar a linha de largada entre bóias ou fora das bóias. Para esta separação, pode-se
verificar se o ponto de intersecção Pi(xi ,yi), já calculado, coincide com um ponto da linha de
largada, Sim ou Não.
Verificando na Figura 44, para o caso da linha no primeiro quadrante, conclui-se que será Sim
quando as seguintes condições se verificarem simultaneamente:
| | | | | | | |
No caso de uma ou das duas não se verificarem, a resposta é Não.
Para as situações da linha nos outros quadrantes, aplica-se a mesma lógica e as condições
verifica-se serem também as mesmas.
Figura 44 – Comparação do rumo do barco com o rumo da linha (2)
Em conclusão:
No caso Não, o fundo fica a azul, porque a intersecção é feita fora das bóias.
No caso Sim, o fundo do ecrã fica verde ou vermelho, dependendo do TTS.
73
A condição de decisão é:
| | | | | | | |
-> Sim (verde ou vermelho);
Não -> azul.
7.1.1 Algoritmo de implementação
Descreve-se de seguida o algoritmo de implementação dos cálculos descritos anteriormente.
Os parâmetros de entrada são as coordenadas dos extremos da linha de largada e a última
estimativa obtida. Esta é composta por coordenadas da posição, rumo, velocidade e instante
de tempo.
Os extremos da linha são e .
Sendo o primeiro ponto a origem de coordenadas, temos .
A latitude em metros do ponto B é
e a longitude
A equação da recta da linha de partida é com
.
Com os mesmos cálculos obtemos a posição do barco no instante t: .
O rumo do barco em graus ( ) é conhecido.
A recta descrita pelo rumo do barco é com
e .
O ponto de intersecção das duas rectas, obtém-se calculando
e .
(20)
A intersecção pode existir, mas não se encontrar entre os pontos de partida ou ter o sentido
oposto. Para a primeira parte será calculada a distância da intersecção a ambos os pontos de
partida e validar se alguns dos valores são superiores ao comprimento da própria linha.
O comprimento é calculado com as regras do triângulo rectângulo: √
. As
distâncias da posição a cada extremo da linha são calculadas da mesma forma:
√
e √
.
Se ou , não existe intersecção e o cálculo termina neste ponto com esse
resultado.
74
Para calcular se a intersecção acontece no sentido da trajectória do barco, usa-se um vector
entre a posição e a intersecção ( ). Daqui retira-se o ângulo com a função
, uma extensão da função arco tangente que retorna o ângulo em radianos para dois
argumentos reais. O ângulo obtido, ( ( )), é depois comparado com o rumo.
Se for diferente (terá 180 graus de diferença), significa que o barco segue no sentido oposto à
linha de partida e que não vai existir intersecção.
Se houver intersecção, podemos determinar o instante em que tal acontece calculando a
distância a percorrer, √
, e usando a velocidade da estimativa,
.
Se houve intersecção, é necessário validar se ela ocorre no sentido permitido, isto é, com o
ponto A a bombordo e o ponto B a estibordo. Para isso, comparamos o ângulo da recta da
linha de partida com a recta do rumo do barco. Se ( ) , então o
barco cruza a linha no sentido correcto.
Como os processos são assíncronos, pode passar algum tempo entre o instante do cálculo da
estimativa e o instante actual, por isso é feita essa subtracção antes de ser apresentado o
resultado do cálculo no ecrã.
7.1.2 Correcção devida às correntes
Os dados da corrente eventualmente existente no mar na altura da largada são introduzidos
pelo utilizador com o valor da corrente c (em kn) e o rumo da corrente rc, em graus magnéticos
ou geográficos consoante a configuração da aplicação (0 a 360). Define-se assim o vector
velocidade da corrente c.
A correcção ao valor da TTL por efeito da corrente no mar só tem sentido ser feita se, além dos
dados da corrente, a distância à proa (entre o local onde o GPS mede a posição e a proa do
barco) for conhecida e introduzida no sistema.
Assim, admite-se que o utilizador também introduziu esta distância no sistema – bd (bow
distance).
Todo o algoritmo lida com velocidades e deslocações em relação ao solo e não em relação à
água, uma vez que são elas calculadas de acordo com posições dadas pelo sistema GPS.
Desta forma, a existência de correntes terá um efeito que está automaticamente considerado
no algoritmo. No entanto, há um efeito, de menor importância mas em certos casos
significativo, que corresponde ao não alinhamento da linha longitudinal de meio-barco com o
sentido da sua velocidade em relação ao solo (speed over ground). A Figura 45 e a Figura 46
ilustram este efeito em largadas com correntes contra e a favor.
Como se pode observar na Figura 47, num caso de corrente contra, o barco já chegou à linha
de largada e o TTL ainda está a contar de acordo com uma distância dc ainda a percorrer.
75
Figura 45 – Corrente contra
Figura 46 – Corrente a favor
Figura 47 – Intersecção com a linha de largada
É esta correcção da distância à linha que se pretende introduzir com este novo algoritmo.
76
c – vector velocidade da corrente (amplitude c e rumo rc) – são conhecidos.
vb – vector velocidade do barco (amplitude vb e rumo rb) – são conhecidos.
vab – vector velocidade aparente do barco (em relação à água) (amplitude vab e rumo rab) – é
necessário calcular.
Observando a figura seguinte, escrevemos então a igualdade vectorial: vab=vb-c
O ângulo entre os vectores vb e c será o qual pode ser calculado pela diferença dos rumos
do barco e da correnterb-rc. Este ângulo é positivo ou negativo conforme rb> rc ou rb <rc.
Com o valor deste ânguloconhecido, pode-se calcular pelas regras dos paralelogramos, a
amplitude da velocidade vab:
√
(21)
Para calcular o rumo correspondente a esta velocidade, ou seja o rab, temos de calcular
rab=rb-em que o ângulo entre os vectores vb e vab será Este ângulo é positivo ou
negativo conforme rb> rab ou rb <rab respectivamente.
Figura 48 – Efeito da corrente
Finalmente, para calcular , podemos observar que
vb=vab.cos +c.cos ou seja
Em resumo:
rb-rc
√
rab=rb-
77
É possível efectuar os cálculos com a trajectória corrigida, conhecendo e o comprimento da
embarcação. A nova trajectória é paralela à calculada sem a correcção das correntes, como é
apresentado nas figuras seguintes.
Figura 49 – Trajectória corrigida com corrente contra
Figura 50 – Trajectória corrigida com corrente a favor
Para efectuar os cálculos translada-se o ponto da última estimativa para um novo
ponto, de acordo com o ângulo β e o comprimento do barco . O novo ponto é
calculado da seguinte forma:
(22)
(23)
Esta operação de translação é ilustrada na Figura 51. Com o novo ponto efectuam-se os
cálculos normais para o TTL para se obter o ponto e a distância para a intersecção com a linha
de partida.
78
Figura 51 – Translação da última estimativa
7.2 Regressão Linear
Quando se efectua a estimativa do rumo e velocidade do barco assume-se que o mesmo está
num rumo constante, por isso a equação que descreveria o seu trajecto é uma recta. Devido
aos erros do GPS os pontos obtidos não se encontram sobre uma recta mas nas suas
proximidades. Para obter uma recta com esses pontos é necessário efectuar uma regressão
linear. Existem vários métodos disponíveis para efectuar esta regressão. Escolheu-se o método
dos mínimos quadrados (Chapra, et al., 2006) porque é um método adequado quando os erros
são aleatórios.
O objectivo deste método é a obtenção da equação da recta no formato em que
é o declive e a ordenada na origem.
Figura 52 – Regressão linear
O método consiste em minimizar a soma dos quadrados dos erros das amostras face à
estimativa. Com as amostras disponíveis ) calcula-se uma equação da recta
79
(24)
em que é o declive, a ordenada na origem e é o resíduo (erro) da amostra . A
abordagem deste método é a de minimizar o somatório do quadrado dos resíduos, ou seja,
minimizar ∑ . Existe uma e só uma recta com o mínimo deste valor. Desenvolvendo,
obtemos as expressões para os parâmetros da recta:
∑
∑
(25)
e .
Uma vez obtida a recta é importante avaliar a qualidade do modelo construído face às posições
originais, de forma a sabermos se temos uma boa estimativa, para caso não seja se informar o
utilizador desse facto. Situações em que o barco descreve curvas acentuadas são exemplos
em que a regressão linear não é adequada e que por isso não fornece um bom resultado.
Para se avaliar a qualidade da regressão calculada utiliza-se o coeficiente de determinação
( ). Este coeficiente quantifica a redução dos erros com a recta obtida por comparação com o
valor médio. Este coeficiente varia entre 0 e 1, sendo os dados da regressão mais aproximados
aos dados originais quanto maior for o seu valor. Define-se como
∑ ̂ ̅
∑ ̅
sendo ̂ o valor estimado de e ̅ a sua média.
7.3 Testes
A seguir descrevem-se os testes realizados no decorrer deste projecto.
7.3.1 17 de Fevereiro de 2012
Teste realizado à frente do IST – TagusPark. Foram marcados os dois extremos da linha:
Bombordo: Lat: 38,736977 e Lon: -9,202130. Estibordo: Lat: 38,737740 e Lon: -9,302677.
Um observador ficou colocado no extremo de estibordo alinhado com o outro extremo, de
forma a poder verificar o momento em que a linha era intersectada. Possuía também um
cronómetro com contagem regressiva, com início sincronizado com o telemóvel com que foi
realizado o teste, para validação do instante do cruzamento da linha e comparação com a
indicação fornecida pelo dispositivo a testar. Em todas as situações testadas, a «Master
Countdown» foi de cinco minutos.
O teste consistiu em efectuar movimentações a pé dos dois lados da linha com algumas
intersecções. Verificou-se que por ter sido utilizada a regressão linear com 5 pontos e amostras
de segundo a segundo, o sistema demorou alguns segundos a ter uma posição correcta
80
quando era alterada a direcção e a velocidade (esta de forma brusca). É um resultado normal,
tendo em conta as opções tomadas. Exceptuando este atraso, o sistema funcionou
correctamente, apresentando um Time to Line (TTL) que fazia sentido e mostrava as cores
correctas. Ao passar a linha, o momento em que a cor mudou para vermelho e o tempo para
zero não era exacto em relação ao sinalizado pelo observador, com desvios nos dois sentidos
entre 1 e 3 segundos. Esses desvios são atribuíveis ao erro do GPS e provavelmente ao facto
de não estar a ser compensado o tempo em que o cálculo é efectuado e o resultado é
apresentado no ecrã.
7.3.2 18 de Fevereiro de 2012
Este teste foi realizado durante duas regatas do torneio Ramada, realizadas no dia 18 de
Fevereiro no rio Tejo, entre o Padrão dos Descobrimentos e a Ponte 25 de Abril. Cerca de 10
minutos antes da partida foram marcados os extremos da linha numa bóia colocada perto da
margem e no barco do júri. Foram feitas algumas aproximações e atravessamentos da linha
com as cores e os valores correctos, salvo diferenças de 1 e 2 segundos.
Nos momentos anteriores à largada, foram feitas várias manobras para passar o tempo e
chegar à linha numa situação favorável de acordo com as indicações do Master countdown no
barco e do TTL e da cor do ecrã do telemóvel. No momento da buzina da largada, o TTL
estava a 7 segundos e o ecrã a verde. Consequentemente foi efectuada uma boa largada.
Infelizmente não era a largada da classe correcta e, por isso, não foi possível retirar vantagem
na competição. Na largada correcta da primeira regata, houve confusão com o tempo e por
isso não foi possível usar o TTL. Por essa razão, ao ser dada a largada mudou-se de imediato
para o modo regata e deu-se indicação de iniciar, sendo gravadas as coordenadas a cada
segundo e apresentados o rumo geográfico, a velocidade e o tempo desde o início da regata.
Foi confrontada a velocidade com a velocidade sobre o solo de um instrumento da embarcação
e os valores foram sempre muito aproximados. O valor do rumo tinha uma diferença de cerca
de 11 graus face ao rumo magnético indicado no instrumento da embarcação.
Antes da segunda regata verificou-se que a bóia de bombordo estava numa posição diferente
e, por isso, foi feita nova marcação indo junto da mesma e dando indicação de marcar. A
posição do barco do júri não foi remarcada e por isso foram utilizadas as coordenadas
memorizadas aquando da primeira regata, o que se iria revelar uma importante fonte de erro.
Entre o instante em que foi marcada a posição do barco do júri e o início da segunda regata
decorreram mais de duas horas e uma mudança de maré, por isso forçosamente a posição de
um barco ancorado ao leito do rio teve de se alterar. Foi utilizado o modo TTL, mas um pouco
antes da aproximação da linha houve indicação de passagem da mesma. Antes disso, houve
indicação de um adiantamento do TTL face ao TTS, o que fez com que o skipper atrasasse um
pouco o percurso. Verificou-se que o barco do júri se tinha deslocado e por isso os cálculos
tinham utilizado uma posição inválida, o que originou um erro na determinação do instante de
cruzamento da linha. É, pois, necessário sempre marcar ambos os pontos antes de cada
largada, para a sua posição ser tão rigorosa quanto possível.
81
Verificou-se que o amarelo não é uma cor indicada porque cria alguma confusão com o verde e
quando o sol incide no ecrã é difícil ver os algarismos. É necessário procurar uma combinação
melhor de cores para facilitar a leitura, embora com ecrãs de telemóvel nunca se tenha a
mesma leitura que com ecrãs desenhados para o ambiente de uma regata, como os que o
veleiro dispunha.
O consumo de bateria foi de cerca de 50% ao longo de mais de 3 horas, para o telemóvel
Samsung Galaxy S II.
7.3.3 15 de Abril de 2012
Condições experimentais
O teste foi realizado no rio Tejo, a bordo do veleiro Contrastes, no dia 15 de Abril de 2012.
Foram testados seis percursos de largada em duas direcções, entre um mastro de sinais em
terra e uma bóia na água. Na Figura 53 apresenta-se a zona onde o teste foi realizado.
Figura 53 – Zona do teste de 15 de Abril de 2012
Utilizaram-se dois telemóveis com a aplicação instalada, um Samsung Galaxy SII (SII) e um
TMN a5 (a5), ambos com a bateria totalmente carregada. Na Tabela 6 apresentam-se as suas
características principais.
Telemóvel Samsung Galaxy SII TMN a5
Processador 1,2 Ghz dual core 600 Mhz
Memória 1 GB RAM 512 MB RAM
Dimensão ecrã 4,3 polegadas 3,5 polegadas
Resolução ecrã 800 x 480 pixels 800 x 480 pixels
Sistema operativo Android 2.3 Android 2.1
Tabela 6 – Características dos smartphones utilizados no teste
Método e observações
82
No teste executaram-se os procedimentos seguintes, pela ordem indicada:
1. Marcação da posição da bóia de bombordo junto do mastro de sinais em ambos os
telemóveis, utilizando o botão “Buoy P” e a função “Mark with GPS”;
2. Marcação da posição da bóia de estibordo pela função correspondente, indo com o
barco junto à bóia e fazendo marcar. Depois deste passo, a linha de partida encontra-
se definida entre os dois pontos marcados;
3. Configuração do Master Countdown para 3 minutos;
4. Obtenção da indicação do rumo e velocidade da corrente através da instrumentação do
barco ou de indicação externa. Introdução dos valores obtidos;
5. Colocação junto ao mastro de sinais do observador com a função de júri, alinhado com
a bóia e munido de um rádio para comunicação com a tripulação do barco;
6. Início do Time to Start (TTS) num instante sincronizado via rádio para o relógio do júri e
ambos os telemóveis;
7. Movimentação do barco em direcção à linha e atravessamento na direcção Oeste ->
Este;
8. O momento em que a linha era cruzada foi indicado via rádio pelo júri e os tempos
registados por todos os observadores;
9. Repetição dos passos, 6, 7 e 8 até se obterem três trajectos;
10. Inversão da posição das bóias, utilizando a função “Swap P <-> SB”, tendo ficado a
bóia como bóia de bombordo e o mastro de sinais como bóia de estibordo. Desta
forma, a direcção correcta de passagem na linha de partida passou a ser Este ->
Oeste.
11. Realização de três trajectos de acordo com os passos 6 a 8, mas na direcção Este ->
Oeste;
12. Início do modo Time to Buoy e realização de um percurso até à bóia e de seguida até o
mais possível junto ao mastro de sinais;
13. Em terra repetição da marcação do mastro de sinais;
14. Determinação do rumo geográfico da bóia e da distância, recorrendo a instrumentos ou
informação da organização da regata;
15. Cálculo da posição da bóia, utilizando a função Distance to Buoy e os valores obtidos.
Informação introduzida no sistema
Foi introduzida a seguinte informação no sistema:
Distância à proa do ponto do barco onde se fizeram as observações: oito metros;
Foi introduzida uma corrente de 0,5 nós e rumo geográfico de 270° apenas para o
telemóvel a5, uma vez que no SII a janela de edição da velocidade não permitia a
introdução do ponto decimal, uma situação que terá de ser analisada;
Marcação das bóias com a função Mark with GPS para a bóia de bombordo e
estibordo;
Definição da Master Countdown para 3 minutos.
Resultados
Time to Line (TTL)
Na Tabela 7 são apresentados os resultados observados no momento da passagem da linha
de partida.
83
Percurso Telem. Direcção Cor ecrã TTL (s) TTS (s) Dif. (s) Vel. (nós) Dif. Dist. (m)
1 a5 O -> E Verde 6 3 3 3,50 5,40
1 SII O -> E Verde 7 3 4 3,50 7,20
2 a5 O -> E Amarelo -3 -8 5 3,50 9,00
2 SII O -> E Amarelo -5 -8 3 3,50 5,40
3 a5 O -> E Verde 2 0 2 3,50 3,60
3 SII O -> E Verde 2 0 2 3,50 3,60
4 a5 E -> O Verde 2 5 -3 3,50 -5,40
4 SII E -> O Verde - 5 - 3,50 -
5 a5 E -> O Verde 3 6 -3 3,50 -5,40
5 SII E -> O Verde 4 6 -2 3,50 -3,60
6 a5 E -> O Verde 1 3 -2 3,50 -3,60
6 SII E -> O Verde 4 3 1 3,50 1,80
Média 0,91 Média 1,64
Tabela 7 – Resultados TTL
Para cada linha é apresentado o número do percurso efectuado, o telemóvel observado, a
direcção de cruzamento da linha, a cor do ecrã no momento da passagem da linha, o TTL
apresentado nesse instante e o TTS observado pelo júri em terra. Nas duas situações em que
o TTL é negativo, a aplicação já tinha iniciado o modo regata e o tempo observado foi o tempo
de regata, porque o TTL já tinha chegado a zero. Nas últimas três colunas são apresentados
alguns cálculos com estes valores. A diferença de tempo entre o TTL e o TTS encontra-se na
primeira destas colunas. Na última coluna temos esta diferença convertida em distância,
considerando uma velocidade do barco de 3,5 nós, um valor médio da velocidade observada
no teste. Também são apresentadas as médias das diferenças em tempo e em distância.
Apesar das médias serem muito reduzidas, indicando bastante rigor no valor apresentado,
podemos observar que há diferenças significativas para ambas as direcções e que parece
observar-se um fenómeno de direcção no desvio dos valores
Time to Buoy (TTB)
Este cálculo foi testado aproximando o barco das bóias e observando que o tempo diminui à
medida que a distância diminui e que a direcção não é considerada.
Distance to Bouy
Optámos por marcar a bóia na água, de que se conhecia a posição. A posição do mastro de
sinais foi remarcada: 38,694176 N; 9,202340 W. De acordo com um rumo lido num smartphone
iPhone (165 graus geográficos) e a distância da linha de partida fornecida pela organização da
regata (150 metros) foram inseridos esses valores e feito o cálculo. Obtiveram-se as
coordenadas: 38,692872 N; 9,201892 W. A posição anteriormente marcada para a bóia tinha
as coordenadas 38,692022 N e 9,201477 W. A distância entre os dois pontos marcados é de
101 metros. Na Figura 54 está marcada a posição medida e a posição real. Pode verificar-se
que a distância fornecida tem um erro grosseiro de 101 metros, enquanto o rumo medido tem
um erro de apenas 2,35°.
84
Figura 54 – Distance to buoy
Comportamento dinâmico
Quanto ao comportamento dinâmico, verificou-se um período de instabilidade dos valores
apresentados quando existem mudanças bruscas na trajectória da embarcação, sendo
necessário aguardar cerca de cinco segundos para obter valores correctos. Isto resulta da
abordagem utilizada, que faz uma regressão linear dos últimos cinco valores lidos e que,
portanto, numa mudança de rumo ainda considera leituras antigas. No entanto, esta regressão
é necessária para suavizar as leituras do GPS. De outra forma, o erro é demasiado elevado
para todas as situações. Como os smartphones Android têm o ritmo máximo do GPS limitado a
1Hz, fazer várias leituras implica uma espera de alguns segundos. A configuração da
regressão linear foi feita com cinco pontos, valor que resultou das experiências anteriores e
que tenta equilibrar a diminuição do erro e o tempo de resposta. Poder-se-ia fazer uma
alteração ao cálculo da regressão para utilizar um número de pontos variável em função do
erro resultante do cálculo da mesma regressão. Contudo, o número de pontos nunca devia ser
inferior a 4 ou no limite 3, e devido à dinâmica do momento pré-largada também não devia ser
muito superior a 5 nos casos de baixo erro. Além disso, esta alteração iria exigir um cálculo
mais complexo e, portanto, mais exigente para o processador e a bateria.
Interface
Em termos de interface, houve dificuldade em fazer a distinção entre a cor verde e a cor
amarela. Os ecrãs dos smartphones não estão optimizados para o ambiente de uma regata,
com luz intensa e muitas movimentações. Ainda assim, é necessário encontrar cores mais
adequadas e experimentar a introdução de avisos sonoros associados às cores apresentadas.
Aspectos técnicos
O teste durou cerca de uma hora e meia e as baterias de ambos os telemóveis, inicialmente
completamente carregadas, apresentavam no final indicadores de 75% de carga restante.
85
As bases de dados de ambos os dispositivos foram descarregadas posteriormente através de
uma função existente na aplicação.
7.3.4 6 de Maio de 2012
Condições experimentais
Este teste foi realizado em terra num terreno plano e amplo na zona de Algés. Para simular as
bóias colocaram-se duas bandeiras numa zona central para permitir aproximações de vários
ângulos e facilitar o controlo do momento do cruzamento pelo elemento com a função de júri.
Na restante descrição do teste estas bandeiras serão referidas como bóias.
Para as velocidades reduzidas de 3 nós os percursos foram efectuados a pé e para as
velocidades superiores foi utilizado um automóvel. Foram testadas várias formas de
cruzamento da linha com várias velocidades e com alterações de rumo. Na Figura 55
apresenta-se a zona onde o teste foi realizado.
Figura 55 – Zona do teste e bóias
O telemóvel utilizado foi um Samsung Galaxy SII com a bateria completamente carregada, com
as características apresentadas na Tabela 8.
Telemóvel Samsung Galaxy SII
Processador 1,2 Ghz dual core
Memória 1 GB RAM
Dimensão ecrã 4,3 polegadas
Resolução ecrã 800 x 480 pixels
Sistema operativo Android 2.3.3
Tabela 8 - Características do smartphone
Método e observações
No teste executaram-se os procedimentos seguintes, pela ordem indicada:
1. Colocação de ambas as bóias;
2. Medição da distância entre as bóias;
3. Marcação de linhas paralelas à linha de partida à distância perpendicular de 5, 10 e 20
metros para serem utilizadas nos testes de viragem de bordo;
86
4. Marcação de ambas as bóias indo junto da sua localização e utilizando a função “Mark
with GPS”;
5. Configuração do Master Countdown para 1 minuto;
6. Configuração da bow distance para 2 metros para os percursos efectuados de carro e
de 0 para os percursos realizados a pé;
7. Não utilização do efeito das correntes;
8. Colocação do elemento do júri junto à bóia de bombordo alinhado com a outra bóia;
9. Colocação da aplicação no modo TTL;
10. Início síncrono do TTS e realização do percurso incluindo atravessamento da linha de
partida;
11. Júri fornece indicação do momento do cruzamento da linha e é observado e registado
qual o valor de TTL apresentado nesse instante;
12. Repetição dos passos 8 a 10 para os trajectos seguintes até serem realizados todos os
trajectos;
13. Remarcação da bóia de bombordo;
14. Determinação da direcção da outra bóia utilizando uma bússola;
15. Inserção do valor da declinação magnética na aplicação;
16. Cálculo e registo da posição da outra bóia utilizando a função “Distance to buoy” e
inserindo a distância medida inicialmente e o rumo determinado no passo 13;
17. Repetição dos passos 12 a 15 para a bóia de estibordo.
Informação introduzida no sistema
Foi introduzida a seguinte informação no sistema:
Distância à proa para medições de carro: 2 metros. Para medição a pé a distância
inserida foi zero;
Definição da Master Countdown para 1 minuto.
Resultados
Time to Line (TTL)
Nas figuras e tabelas seguintes são apresentados os resultados para os casos de teste
realizados.
Figura 56 - Aproximações directas
0
1
2
3
4
1 2 3 4 5 6 7 8 9 10
TTL
(s)
Observações
3kn
5kn
7kn
87
Velocidade TTL (s) Dist.(m)
3kn Média 1,00 1,54
Desvio padrão 0,82 1,26
5kn Média 1,6 4,12
Desvio padrão 1,35 3,47
7kn Média 0,90 3,24
Desvio padrão 0,74 2,66
Tabela 9 – Aproximações directas
Figura 57 - Aproximações com viragem de bordo a 5m da linha
Velocidade TTL (s) Dist.(m)
3kn Média 1,70 2,62
Desvio padrão 1,83 2,82
7kn Média 0,60 2,16
Desvio padrão 1,07 3,87
Tabela 10 – Aproximações com viragem de bordo a 5m da linha
Figura 58 - Aproximações com viragem de bordo a 10m da linha
Velocidade TTL (s) Dist.(m)
3kn Média 0,70 1,08
Desvio padrão 1,49 2,31
7kn Média 0,70 2,52
Desvio padrão 1,64 5,89
Tabela 11 – Aproximações com viragem de bordo a 10m da linha
-1
0
1
2
3
4
5
1 2 3 4 5 6 7 8 9 10
TTL
(s)
Observações
3kn
7kn
-2
-1
0
1
2
3
4
1 2 3 4 5 6 7 8 9 10
TTL
(s)
Observações
3kn
7kn
88
Figura 59 - Aproximações com viragem de bordo a 20m da linha
Velocidade TTL (s) Dist.(m)
3kn Média -0,20 -0,31
Desvio padrão 0,42 0,65
7kn Média 1,80 6,48
Desvio padrão 1,99 7,16
Tabela 12 – Aproximações com viragem de bordo a 20m da linha
Para cada linha é apresentada a velocidade, o número do teste, o valor de TTL observado
aquando da passagem pela linha de largada por indicação do júri e a mesma diferença
expressa em metros. No final de cada grupo de testes também é apresentada a média e o
desvio padrão do TTL e da diferença de distância. Quando o TTL indicado tem valor negativo
significa que o TTL apresentado foi (-:--) indicando neste caso que a linha já tinha sido cruzada,
sendo o tempo apresentado a diferença entre o zero e a indicação do cruzamento da linha pelo
júri.
Distance to Bouy
Foi remarcada a posição da bóia de bombordo (38,697425N e 9,236205W). No ecrã de
distance to buoy foi inserida a distância anteriormente medida (105,6m) e a direcção medida
com a bússola (307°). A posição da bóia de estibordo obtida foi (38,69804N e 9,23713W).
Depois foi remarcada a bóia de estibordo (38,697948N e 9,237231W) e posteriormente inserido
no ecrã distance to buoy a distância de 105,6m e o rumo medido com a bússola (134°). A
posição da bóia de bombordo obtida foi (38,697262N e 9,236383W). Na figura seguinte estão
representadas as posições originais e as calculadas pela função distance to buoy.
-2
0
2
4
6
8
1 2 3 4 5 6 7 8 9 10TT
L (s
) Observações
3kn
7kn
89
Figura 60 – Cálculo Distance to Buoy
Como se pode verificar os valores obtidos são muito diferentes do esperado. Como os dados
foram guardados foi depois reproduzida a situação em ambiente debug e verificou-se que
existia um erro de sinal nos cálculos que foi corrigido posteriormente.
Interface
Os avisos sonoros foram de grande utilidade e o som de ritmo elevado e agudo para o
vermelho e de ritmo lento e grave para o verde eram intuitivos.
Em termos dos ecrãs voltou a haver alguma dificuldade em ler as indicações, embora não
tivessem impedido as medições. O problema é a reflexão da luz no ecrã brilhante. Verificou-se
que o ecrã da regata, que tem apenas letras brancas sobre um fundo preto tinha melhor leitura.
É conveniente com este dado tentar encontrar uma apresentação que melhore a leitura dos
valores e cores.
Aspectos técnicos
O teste durou cerca de três horas e meia e a bateria do telemóvel tinha no final o indicador a
25% da carga, tendo-se iniciado o teste com a mesma totalmente carregada.
Foi descarregada a base de dados no final do teste.
7.3.5 7 de Junho de 2012
Condições experimentais
Este teste foi realizado no Parque das Nações, em Lisboa, no dia 7 de Junho de 2012. O
objectivo era testar a gama de valores do coeficiente de determinação ( ), calculado quando é
determinada a recta entre os vários pontos pelo método dos mínimos quadrados, para vários
tipos de percurso.
Foram idealizados três percursos, um rectilíneo, um com um grau de curvatura de cerca de 15
metros e um terceiro com uma viragem brusca entre dois percursos em linha recta. Cada teste
foi realizado três vezes. Os percursos foram feitos a pé a passo acelerado.
90
Resultados
Em seguida apresentam-se os resultados dos nove casos de teste realizados. As figuras
apresentam a evolução do valor de ao longo de cada percurso. A tabela apresenta os
valores da média e do desvio padrão do mesmo . Também são apresentados os percursos
realizados. As imagens foram recolhidas utilizando a funcionalidade de exportação do percurso
da aplicação para Google Earth.
Figura 61 - Percursos em linha recta
R2
Recta 1 Média 0,986979
DP 0,027218
Recta 2 Média 0,835275
DP 0,249001
Recta 3 Média 0,931337
DP 0,087315
Tabela 13 – Percursos em linha recta
Figura 62 – Percursos em linha recta
0
0,2
0,4
0,6
0,8
1R
2
Recta 1
Recta 2
Recta 3
91
Figura 63 - Percursos curva larga
R2
Curva larga 1 Média 0,898453
DP 0,209903
Curva larga 2 Média 0,866742
DP 0,213505
Curva larga 3 Média 0,895433
DP 0,216235
Tabela 14 – Percursos curva larga
Figura 64 – Percursos curva larga
0
0,2
0,4
0,6
0,8
1
R2
Curva larga1
Curva larga2
Curva larga3
92
Figura 65 - Percursos curva apertada
R2
Curva apertada 1 Média 0,733642
DP 0,297613
Curva apertada 2 Média 0,823406
DP 0,273229
Curva apertada 3 Média 0,795747
DP 0,251623
Tabela 15 – Percursos curva apertada
Figura 66 – Percursos curva apertada
Conclusões
Da análise dos resultados verifica-se que no percurso rectilíneo os valores de são sempre
muito elevados, como seria de esperar. Nos outros percursos reduzem-se de forma
relacionada com os momentos com mais variações de direcção.
Da análise de resultados decidiu-se escolher o valor de = 0,3 como valor limiar para
considerar a estimativa fiável.
0
0,2
0,4
0,6
0,8
1
R2
Curvaapertada 1
Curvaapertada 2
Curvaapertada 3
93
7.4 Manual da aplicação
Regatta TTL – Manual Equipamento: Smartphone Android com GPS
Versão mínima do sistema operativo: 2.1 (optimizado para as versões 2.1 e 2.3.3).
Esta aplicação calcula o tempo do barco à linha
de largada (e/ou a cada bóia desta linha).
Também guarda o percurso durante a regata
ou de um passeio para o poder rever sobre o
Google Earth.
Resumo
1- A largada é definida entre a bóia de bombordo (Buoy P, vermelha) e a bóia de estibordo
(Buoy SB, verde). As coordenadas destas bóias terão de ser introduzidas e podem ser
trocadas (Swap P <-> SB) se o júri decidir inverter o sentido da largada.
2- O início da contagem decrescente do júri terá de ser marcado, e a aplicação mostra a
sequência decrescente (Time to Start – TTS) até ao momento do início da regata TTS = 0:00.
3- No modo Time To Line (TTL), a aplicação mostra o tempo estimado para o barco cruzar a
linha. O confronto do TTL com o TTS indica se o barco está atrasado ou adiantado. Esta
informação é complementada com diferentes cores e sons.
Menu principal (quando se entra na aplicação)
Name – Nome da regata. Agrega todos os
dados da regata. É necessário para iniciar a
nova compilação de dados.
Current – Sentido e velocidade da corrente da
água (facultativo).
Buoy P – Coordenadas da bóia de bombordo.
Buoy SB – Coordenadas da bóia de estibordo.
Distance Buoy – Em alternativa a marcar as
duas bóias, pode marcar apenas uma e, a
partir dessa, introduzir o rumo e a distância à
segunda bóia.
94
Countdown – Introdução do período de tempo
da contagem decrescente (ex.: 5:00 min).
TTL (Time To Line) – Inicia o modo do cálculo
do TTL e o modo da contagem do TTS.
Regatta - Inicia o modo de registo dos
percursos do barco na regata.
Name - Escreva o nome da regata e prima OK.
Esta operação limpa os registos dos percursos
e as posições das bóias de largada das regatas
anteriores. Não limpa as configurações.
Current - Facultativamente pode inserir o rumo
(graus) e a velocidade (kn) da corrente na
água. Melhora um pouco a precisão do cálculo
do TTL.
Buoy P (Port Buoy) - O botão Mark with GPS
introduz automaticamente as coordenadas do
GPS da bóia. Leve o barco até esta bóia e
prima este botão quando a bóia estiver ao seu
lado.
É também possível introduzir manualmente as
coordenadas nas janelas de latitude e longitude
(graus e 6 casas decimais).
Pode trocar as duas bóias, caso o júri troque o
sentido da largada. Para isso, prima o botão
Swap P <-> SB.
Para gravar e sair deste ecrã prima OK.
95
Buoy SB (Starboard bouy) - O botão Mark
with GPS introduz automaticamente as
coordenadas do GPS da bóia. Leve o barco até
esta bóia e prima este botão quando a bóia
estiver ao seu lado.
É também possível introduzir manualmente as
coordenadas nas janelas de latitude e longitude
(graus e 6 casas decimais).
Pode trocar as duas bóias, caso o júri troque o
sentido da largada. Para isso, prima o botão
Swap P <-> SB.
Para gravar e sair deste ecrã prima OK.
Distance to Buoy - Caso haja apenas tempo
para ir a uma bóia, marque as coordenadas
dessa bóia, como indicado nos ecrãs
anteriores, e entre neste ecrã: Aqui introduza o
rumo (graus) desta para a outra bóia e a
distância (m) a que pensa que está.
Prima Calc Buoy. O cálculo é efectuado e as
coordenadas da outra bóia são apresentadas
em baixo.
Para gravar e sair prima OK.
96
Countdown (Master Countdown) - Introduza
o período de tempo da contagem decrescente
do júri para início da regata Time to Start (TTS).
Pode premir um dos 4 exemplos ou introduzir
um outro tempo.
Estes dados mantêm-se em memória.
Para gravar e sair prima OK.
Configurações - (premindo o botão de opções
do smartphone e seleccionando Configuration)
Bow distance - Insira a distância (m) entre a
proa e o ponto onde está o smartphone.
Declination - Insira a declinação magnética do
local, em graus e decimais, com sinal negativo
se for Oeste (Portugal 2012 vale -3.18 graus).
Degrees - Escolha usar graus magnéticos ou
geográficos.
Upload Path - No fim da regata, faz o upload do
percurso da regata para o Google Earth.
Pode enviar o ficheiro, conforme as
configurações do smartphone, por correio
electrónico ou Bluetooth, por exemplo.
Os dados mantêm-se em memória.
Para gravar e sair prima OK.
97
TTL (Time To Line) - Prima o botão Start TTS para a contagem decrescente quando o júri der
o sinal de preparação. Caso o TTS tenha sido já iniciado, é reiniciado. É também possível parar
a contagem no botão de menu Stop TTS.
Na metade superior fica a contagem decrescente para a largada (TTS). Na metade inferior está
o tempo estimado para o barco chegar à linha (TTL):
Fundo verde: o barco cruzará a linha depois do TTS=0:00. Sinal sonoro grave e lento.
Fundo vermelho: o barco cruzará a linha antes do início da regata. Sinal sonoro agudo e
rápido.
98
Fundo azul: o barco está apontado à linha mas fora das bóias. Se se estiver a afastar da
linha, o TTL não mostra valores. Se o barco se aproxima da linha mas em sentido contrário
ao da largada, o TTL dá os valores correctos mas com fundo azul.
Fundo negro: o TTS não foi iniciado.
Fundo cinzento: a estimativa do TTL é menos fiável.
Quando o TTS chega a 0:00, a regata inicia-se e a aplicação comuta automaticamente para o
modo Regatta.
TTB (Time to Buoy) - No modo TTL, para
saber o tempo que o barco leva a chegar a
qualquer uma das bóias prima Start TTB, no
botão de menu. Essa indicação é visualizada
no topo do ecrã.
Este cálculo considera apenas a velocidade
instantânea do barco.
Regatta - No modo Regatta a aplicação
apresenta o rumo, a velocidade e o tempo
desde o início da regata. São registadas todas
as posições do percurso para permitir fazer o
upload no final da regata. Depois de terminar a
regata prima Stop no menu de opções e prima
o botão Back para regressar ao menu inicial.
Nesta altura pode fazer upload do percurso
conforme descrito noutra secção deste manual.
Quando há uma segunda regata, deve fazer o
upload antes de marcar a nova informação da
segunda regata
99
Options – É um ecrã que existe nas opções do menu inicial. Contém parametrizações para
desenvolvimento e debug, pelo que não deve ser utilizado.
SEQUÊNCIA NORMAL DE OPERAÇÕES PARA O MODO TTL
1. Abrir aplicação – aparece o ecrã principal.
2. Configurations – Indique a distância à proa, a declinação e se
pretende usar graus magnéticos ou geográficos (Se voltar a
efectuar uma regata com o mesmo barco e na mesma zona não é necessário
voltar a alterar estes valores).
3. Name – escreva o nome da regata e OK.
4. Current - Se souber, introduza o rumo e velocidade da corrente.
5. Buoy P - Leve o barco à bóia de bombordo e marque a sua posição.
6. Buoy SB - Leve o barco à bóia de estibordo e marque a sua
posição.
7. Countdown – Verifique se o tempo da sequência do
Master Countdown é o indicado pelo júri (ex. 5 min).
8. TTL – Aparece o ecrã com fundo negro, em baixo o tempo
estimado para cruzar a linha e em cima um botão para
iniciar o TTS quando o júri der o sinal de preparação.
9. Start TTS - Ao sinal de preparação, prima o botão Start TTS,
iniciando-se a contagem decrescente (Master Countdown).
O ecrã ficará azul, verde, encarnado ou cinzento consoante a situação do barco, e mostrará simultaneamente a contagem decrescente do júri e a estimativa TTL.
10. Quando o TTS chega ao fim inicia-se automaticamente o modo Regatta e a
aplicação passa a registar o percurso do barco durante a regata.
11. Stop - No fim da regata, no ecrã do modo Regatta e no menu
de opções prima Stop. Para voltar ao menu inicial prima Back.
12. Upload - No menu de configurações faça Upload path para enviar o ficheiro
com o seu percurso, por exemplo por correio electrónico para a sua caixa
de correio. Aí, abrindo o anexo com esse ficheiro, poderá ver o seu percurso sobre o
Google Earth.
Outras informações:
- Durante o modo TTL:
- o ecrã não roda. - o brilho e o som estão no máximo. - o ecrã não se apaga.
100
SEQUÊNCIA NORMAL DE OPERAÇÕES PARA O MODO REGATTA OU CRUZEIRO
1. Abrir aplicação – aparece o ecrã principal.
2. Configurations – Indique a declinação e se pretende usar
graus magnéticos ou geográficos (Se voltar a efectuar uma
regata ou cruzeiro com o mesmo barco e na mesma zona não
é necessário voltar a alterar estes valores).
3. Name – escreva o nome da regata ou cruzeiro e OK.
4. Regatta – Entre no modo de Regatta.
5. Start – Carregue no botão de opções e prima Start no
momento em que se iniciar a regata ou quando inicia o
cruzeiro. A contagem de tempo inicia-se.
Stop - No fim da regata ou cruzeiro, no ecrã do modo Regatta e
no menu de opções prima Stop. Para voltar ao menu inicial prima
Back.
6. Upload - No menu de configurações faça Upload path para
enviar o ficheiro com o seu percurso, por exemplo por correio
electrónico para a sua caixa de correio. Aí, abrindo o anexo
com esse ficheiro, poderá ver o percurso da sua regata ou do
seu passeio sobre o Google Earth.
