From PublicWiki

Conteúdo 1 Grupo α2: Infraestrutura do IPS 1.1 Plano de Trabalho 1.2 Protocolo IPS 1.2.1 Especificação 1.2.2 Implementação 1.2.3 Testes 1.2.3.1 Teste de 6 de julho de 2007 1.2.3.2 Teste de 11 de julho de 2007 1.2.3.3 Teste de 15 de julho de 2007 1.2.3.4 Teste de 16 de julho de 2007 1.2.3.5 Teste de 17 de julho de 2007 1.3 Integração 1.3.1 Passo-a-passo 1.3.2 Calibragem 1.3.3 Binários (Nova versão)

Grupo α2: Infraestrutura do IPS

A infraestrutura do IPS é formada por 4 balizas de posição previamente conhecida. Essas balizas têm a responsabilidade de informar a presença de alguma espaçonave não autorizada ao sistema de defesa da polícia espacial. O sistema de defesa usará as informações enviadas pelas balizas para encontrar a posição exata da espaçonave invasora e disparar um canhão fotônico contra a mesma. A espaçonave Klingom também se usará das balizas para informar à Enterprise sua localização e assim poder teletransportar Kirk e Spock.

Este grupo têm a tarefa de construir as 4 balizas necessárias para os algoritmos de triangulação do sistema de defesa e da nave Klingom. Para tal, é necessário implementar a detecção da espaçonave invasora e o envio das informações necessárias à localização da mesma para o sistema de defesa e para a nave Klingom. Apesar deste grupo fazer parte do time α, as informações geradas pelas balizas serão usadas por ambos os times, devendo haver um acordo quanto ao protocolo usado.

Plano de Trabalho

Atividade	Descrição	Recursos	Cronograma	Status
Estudo da plataforma	Operação no Mica 2, compilação, sistema de comunicação do EPOS	2 Mica 2, cross-compiler, EPOS, exemplos (demos)	1110-0000-0000-0000	Concluído
Protocolo IPS	Especificação e calibragem das balizas.		1111-1111-1100-0000	Iniciado
Implementação	Implementação do protocolo IPS	Compilador do Mica 2, depurador	0111-1111-1100-0000	Iniciado
Testes	Execução de testes de sistema para procurar falhas no protocolo	6 Mica 2	0011-1111-1110-0000	Iniciado
Integração	Integrar o protocolo aos sistemas de localização da Enterprise e do canhão	4 Mica 2	0000-0000-0111-1100
Jogo	Jogar...	4 Mica 2	0000-0000-0000-0011

Protocolo IPS

Especificação

O protocolo do IPS é definido pelo PDU emitido pelas balizas, e pela máquina de estados que especifica o comportamento daquele.

Informações do PDU

Qualquer pacote emitido pelas balizas segue a estrutura apresentada abaixo.

typedef struct PDU {
	unsigned short beacon_rssi[4];
	unsigned short target_rssi;
	unsigned int pdu_type;
	unsigned char source;
};

A tabela a seguir especifica os campos:

Campo	Definição	Valor
beacon_rssi[4]	Define o rssi de cada baliza em relação a baliza que emitiu o pacote.	Para a baliza emissora: 0xFFFF, para as outras três: rssi da baliza.
target_rssi	Define o rssi do alvo em relação a baliza que emitiu o pacote.	rssi do alvo caso ele tenha sido percebido desde a última vez que essa baliza emitiu um PDU. Zero caso contrário.
pdu_type	Define o tipo do PDU emitido. Pacotes funcionais são do tipo DATA, para controle tem-se os tipos ACK e RETRANS.	DATA=0, ACK=1, RETRANS=2
source	Define o endereço de origem do pacote - criado para evitar conflitos dentro do espaço de endereços do MAC.	[0-3] para as balizas.

Comportamento

Inicialmente o protocolo foi modelado levando em consideração a possibilidade de contagem de tempo de forma global - o tempo se passaria da mesma forma para todas as balizas. Imaginava-se: "Se a baliza0 emitiu seu PDU em t0 então a baliza1 emitiria seu PDU em (t0 + tempo de espera) e a baliza2 em (t0 + 2*(tempo de espera)) e assim por diante". Abaixo, tem-se a máquina de estados que ilustra essa idéia - suportando uma sincronização inicial e eventuais ressincronizações. Um esboço de sua implementação pode ser encontrada em old_ips.cc

Entretanto, devido a limitações de hardware, chegou-se a conclusão de re-modelar o protocolo de forma a ser independente de uma contagem de tempo global. O controle do tempo, portanto, passa a ocorrer localmente, onde apenas uma das balizas faz controle do tempo por vez, e esse controle é passado de baliza para baliza na seqüência. Para isso, no entanto, é necessário que o protocolo seja confirmado, ou o IPS poderá parar graças a uma perda de pacote.

A máquina de estados que modela o protocolo é apresentada abaixo, seguida da explicação da mesma.

Em suma, a ativação e funcionamento das balizas dar-se-á da seguinte forma:

1. As balizas serão posicionadas nos 4 cantos da área de jogo, sendo que a baliza i é a i-ésima baliza em sentido horário, iniciando pela da esquerda do topo.

2. As balizas [1-3] serão ativadas, e entrarão em estado de espera (WAITING_PREV), cada uma aguardando a baliza anterior a ela emitir o PDU - a baliza 1 aguarda a 0, a 2 aguarda a 1, e assim por diante.

3. Enfim, será ativada a baliza 0, que dará início ao processo. Ao ser ativada, ela emitirá o PDU pela qual a baliza 1 esperava, e esperará a confirmação do recebimento do pacote (WAITING_ACK).

4. A baliza 1, ao ouvir o PDU esperado, confirma seu recebimento (send_ack), fazendo a baliza 0 transitar do estado WAITING_ACK para WAITING_PREV, e entra no estado de espera para enviar (WAITING_SEND), ao expirar o fair_timeout, a baliza finalmente emite seu PDU. O processo então se repete infinitamente.

Caso, após emitir seu PDU, uma dada baliza não receba a confirmação de recebimento da baliza seguinte (seja pela segunda ter perdido o pacote DATA, ou pela primeira ter perdido o pacote ACK), essa passa a retransmitir seu pacote (re_send_data), periodicamente (ack_timeout), até receber confirmação da baliza seguinte, ou ouvir a baliza anterior emitido PDU - dando indícios de que ouve apenas perda de ACK por parte dela.

Implementação

A implementação atual já é funcional e implementa as especificações feitas acima. Pode ser encontrada em: ips.cc. As condições em que suas funcionalidades foram comprovadas podem ser acompanhadas na seção Testes.

Testes

Já foram relizados testes envolvendo as quatro balizas mais outros dois Micas: um para simular uma comunicação fora do protocolo IPS (detecção de comunicação) e outro, conectado serialmente ao PC, ouvindo toda a comunicação.

Antes do teste principal, foram realizados alguns outros testes menores, verificando padrões dos LEDs, conteúdo dos pacotes (PDUs), detecção de comunicação, etc.

Teste de 6 de julho de 2007

Local: LISHA
Distância entre as balizas: < 1m
Infra-estrutura: Listener.cc (embarcado num Mica 2), aplicação desenvolvida por nós para examinar qualquer pacote emitido pelas balizas; e o target.cc (embarcado num Mica 2) aplicação que emite pacotes de forma periódica, simboliza a nave Klingom do jogo. Ao todo 6 Mica 2, 4 deles com a aplicação ips.cc embarcada - formando o IPS.

Caso de Teste	Descrição	Execução	Status
Volta no circuito sem perdas de pacote	Checar se o comportamento do protocolo segue como esperado sem a perda de pacotes.	As 4 balizas foram ativadas, a sequência de emissão foi averiguada através dos padrões de piscagem dos LEDs de cada uma, e por meio das mensagens examinadas pelo minicom vindas do Listener.cc (Mica 2 conectado em porta serial).	Passou
Volta no circuito com perdas de pacote	Checar se o comportamento do protocolo segue como esperado caso haja perda de pacotes	As 4 balizas foram ativadas, a sequência de emissão foi averiguada através dos padrões de piscagem dos LEDs de cada uma, e por meio das mensagens examinadas pelo minicom vindas do Listener.cc (Mica 2 conectado em porta serial). Durante o decorrer do teste algumas balizas foram momentaneamente desativadas (inclusive para troca de pilhas =P). Tais ações levaram a ocorrência de restransmissões.	Passou
Percepção de um alvo	Checar se as balizas atualizam o campo pdu->target_rssi na presença de um outro Mica 2 emitindo pacotes fora do padrão das balizas.	As 4 balizas foram ativadas, a sequência de emissão e deteção do alvo foi averiguada através dos padrões de piscagem dos LEDs de cada uma, e por meio das mensagens examinadas pelo minicom vindas do Listener.cc (Mica 2 conectado em porta serial). Foi igualmente ativado o Mica 2 com o target.cc embarcado, o qual emitia pacotes periodicamente fora do padrão das balizas.	Passou
Longa execução	Checar se o comportamento do protocolo segue como esperado no decorrer de um período de tempo razoável, ocorrendo perdas de pacotes, retransmissões, etc. Interessante também para detecção de casos de memory starvation.	As 4 balizas foram ativadas, a sequência de emissão foi averiguada através dos padrões de piscagem dos LEDs de cada uma, e por meio das mensagens examinadas pelo minicom vindas do Listener.cc (Mica 2 conectado em porta serial). Analisou-se o funcionamento das balizas por 5 minutos, com o fair_timeout e o ack_timeout, aproximadamente iguais a 5 e 2 segundos respectivamente.	Passou

Teste de 11 de julho de 2007

Local: Laboratório 2 do INE
Distância entre as balizas: < 1m, 2m, 3m
Infra-estrutura: Listener.cc (embarcado num Mica 2), aplicação desenvolvida por nós para examinar qualquer pacote emitido pelas balizas; Ao todo 5 Mica 2, 4 deles com a aplicação ips.cc embarcada - formando o IPS.
Observações: Não foi possível executar testes com o alvo por falta de Micas (existia um, mas estava sem solda nos fios). Também não foi possível levar os Micas a maiores distâncias, pois, provavelmente, as pilhas estavam com pouca carga, falhando em transmissões mais distantes.

Caso de Teste	Descrição	Execução	Status
Volta no circuito sem perdas de pacote	Checar se o comportamento do protocolo segue como esperado sem a perda de pacotes.	As 4 balizas foram ativadas, a sequência de emissão foi averiguada através dos padrões de piscagem dos LEDs de cada uma, e por meio das mensagens examinadas pelo minicom vindas do Listener.cc (Mica 2 conectado em porta serial).	Passou
Volta no circuito com perdas de pacote	Checar se o comportamento do protocolo segue como esperado caso haja perda de pacotes	As 4 balizas foram ativadas, a sequência de emissão foi averiguada através dos padrões de piscagem dos LEDs de cada uma, e por meio das mensagens examinadas pelo minicom vindas do Listener.cc (Mica 2 conectado em porta serial). Durante o decorrer do teste algumas balizas foram momentaneamente desativadas. Tais ações levaram a ocorrência de restransmissões.	Passou
Percepção de um alvo	Checar se as balizas atualizam o campo pdu->target_rssi na presença de um outro Mica 2 emitindo pacotes fora do padrão das balizas.		Não executado
Longa execução	Checar se o comportamento do protocolo segue como esperado no decorrer de um período de tempo razoável, ocorrendo perdas de pacotes, retransmissões, etc. Interessante também para detecção de casos de memory starvation.	As 4 balizas foram ativadas, a sequência de emissão foi averiguada através dos padrões de piscagem dos LEDs de cada uma, e por meio das mensagens examinadas pelo minicom vindas do Listener.cc (Mica 2 conectado em porta serial). Analisou-se o funcionamento das balizas por 5 minutos, com o fair_timeout e o ack_timeout, aproximadamente iguais a 1s e 200ms respectivamente.	Passou

Teste de 15 de julho de 2007

Local: LRG
Distância entre as balizas: < 1m, 2m, 3m
Infra-estrutura: Listener (embarcado num Mica 2), aplicação desenvolvida pelo grupo alfa3 para examinar pacotes emitidos pelas balizas; Ao todo 5 Mica 2, 4 deles com a aplicação ips.cc embarcada - formando o IPS.
Observações: Não foi possível levar os Micas a maiores distâncias, pois, provavelmente, as pilhas estavam com pouca carga, falhando em transmissões mais distantes.

Caso de Teste	Descrição	Execução	Status
Volta no circuito sem perdas de pacote	Checar se o comportamento do protocolo segue como esperado sem a perda de pacotes.	As 4 balizas foram ativadas, a sequência de emissão foi averiguada através dos padrões de piscagem dos LEDs de cada uma, e por meio das mensagens vindas do Listener (Mica 2 conectado em porta serial).	Passou
Volta no circuito com perdas de pacote	Checar se o comportamento do protocolo segue como esperado caso haja perda de pacotes	As 4 balizas foram ativadas, a sequência de emissão foi averiguada através dos padrões de piscagem dos LEDs de cada uma, e por meio das mensagens vindas do Listener (Mica 2 conectado em porta serial). Durante o decorrer do teste algumas balizas foram momentaneamente desativadas. Tais ações levaram a ocorrência de restransmissões.	Passou
Percepção de um alvo	Checar se as balizas atualizam o campo pdu->target_rssi na presença de um outro Mica 2 emitindo pacotes fora do padrão das balizas.	As 4 balizas foram ativadas, a sequência de emissão foi averiguada através dos padrões de piscagem dos LEDs de cada uma, e por meio das mensagens vindas do Listener (Mica 2 conectado em porta serial). A aplicação Listener foi modificada para enviar rajadas de pacotes de tempos em tempos.	Não passou para o caso em que muitos pacotes são enviados em seqüência. O tempo que o método NIC::receive leva para desistir, quando não capta nenhum pacote, é cerca de 10 a 20 vezes maior que o tempo de recepção de um pacote. Se há muitos pacotes sendo transmitidos em seqüência, a temporização, baseada no número de "receives" dados, fica muito mais rápida. Além disso, a diferença entre o timeout para transmissão e o timeout para retransmissão se torna desprezível, fazendo com que o sistema perca a sincronização. Esta linha do tempo ilustra uma situação em que apenas 2 perdas de pacotes são suficientes para acabar com o sincronismo do sistema.
Longa execução	Checar se o comportamento do protocolo segue como esperado no decorrer de um período de tempo razoável, ocorrendo perdas de pacotes, retransmissões, etc. Interessante também para detecção de casos de memory starvation.	As 4 balizas foram ativadas, a sequência de emissão foi averiguada através dos padrões de piscagem dos LEDs de cada uma, e por meio das mensagens vindas do Listener (Mica 2 conectado em porta serial). Analisou-se o funcionamento das balizas por 5 minutos, com o fair_timeout e o ack_timeout, aproximadamente iguais a 1s e 200ms respectivamente.	Passou

Teste de 16 de julho de 2007

Local: LTIC
Distância entre as balizas: < 1m, 2m, 3m
Infra-estrutura: Listener.cc (embarcado num Mica 2), aplicação desenvolvida para examinar pacotes emitidos pelas balizas; Target (embarcado num Mica 2) para enviar rajadas de pacotes. Ao todo 6 Mica 2, 4 deles com a aplicação ips.cc embarcada - formando o IPS.
Observações: Não foi possível levar os Micas a maiores distâncias, pois, provavelmente, as pilhas estavam com pouca carga, falhando em transmissões mais distantes.

Caso de Teste	Descrição	Execução	Status
Volta no circuito sem perdas de pacote	Checar se o comportamento do protocolo segue como esperado sem a perda de pacotes.	As 4 balizas foram ativadas, a sequência de emissão foi averiguada através dos padrões de piscagem dos LEDs de cada uma, e por meio das mensagens vindas do Listener (Mica 2 conectado em porta serial).	Passou
Volta no circuito com perdas de pacote	Checar se o comportamento do protocolo segue como esperado caso haja perda de pacotes	As 4 balizas foram ativadas, a sequência de emissão foi averiguada através dos padrões de piscagem dos LEDs de cada uma, e por meio das mensagens vindas do Listener (Mica 2 conectado em porta serial). Durante o decorrer do teste algumas balizas foram momentaneamente desativadas. Tais ações levaram a ocorrência de restransmissões.	Passou
Percepção de um alvo	Checar se as balizas atualizam o campo pdu->target_rssi na presença de um outro Mica 2 emitindo pacotes fora do padrão das balizas.	As 4 balizas foram ativadas, a sequência de emissão foi averiguada através dos padrões de piscagem dos LEDs de cada uma, e por meio das mensagens vindas do Listener (Mica 2 conectado em porta serial). A aplicação Listener foi modificada para enviar rajadas de pacotes de tempos em tempos.	Passou. O problema foi resolvido pelo uso de uma proporção entre os tempos de desistência do receive e de recebimento de pacote (atualmente 10 para 1). Foi adicionado também um número serial ao protocolo para contornar o problema de sucessivas perdas de pacote.
Longa execução	Checar se o comportamento do protocolo segue como esperado no decorrer de um período de tempo razoável, ocorrendo perdas de pacotes, retransmissões, etc. Interessante também para detecção de casos de memory starvation.	As 4 balizas foram ativadas, a sequência de emissão foi averiguada através dos padrões de piscagem dos LEDs de cada uma, e por meio das mensagens vindas do Listener (Mica 2 conectado em porta serial). Analisou-se o funcionamento das balizas por 5 minutos, com o fair_timeout e o ack_timeout, aproximadamente iguais a 1s e 200ms respectivamente.	Passou

Teste de 17 de julho de 2007

Local: CALICO
Distância entre as balizas: < 1m
Infra-estrutura: Listener (embarcado num Mica 2), aplicação desenvolvida pelo grupo alfa3 para examinar pacotes emitidos pelas balizas; Ao todo 5 Mica 2, 4 deles com a aplicação ips.cc embarcada - formando o IPS.
Observações: Não foi possível levar os Micas a maiores distâncias, pois, provavelmente, as pilhas estavam com pouca carga, falhando em transmissões mais distantes.

Caso de Teste	Descrição	Execução	Status
Volta no circuito sem perdas de pacote	Checar se o comportamento do protocolo segue como esperado sem a perda de pacotes.	As 4 balizas foram ativadas, a sequência de emissão foi averiguada através dos padrões de piscagem dos LEDs de cada uma, e por meio das mensagens vindas do Listener (Mica 2 conectado em porta serial).	Passou
Volta no circuito com perdas de pacote	Checar se o comportamento do protocolo segue como esperado caso haja perda de pacotes	As 4 balizas foram ativadas, a sequência de emissão foi averiguada através dos padrões de piscagem dos LEDs de cada uma, e por meio das mensagens vindas do Listener (Mica 2 conectado em porta serial). Durante o decorrer do teste algumas balizas foram momentaneamente desativadas. Tais ações levaram a ocorrência de restransmissões.	Passou
Percepção de um alvo	Checar se as balizas atualizam o campo pdu->target_rssi na presença de um outro Mica 2 emitindo pacotes fora do padrão das balizas.	As 4 balizas foram ativadas, a sequência de emissão foi averiguada através dos padrões de piscagem dos LEDs de cada uma, e por meio das mensagens vindas do Listener (Mica 2 conectado em porta serial). A aplicação Listener foi modificada para enviar rajadas de pacotes de tempos em tempos.	Passou
Longa execução	Checar se o comportamento do protocolo segue como esperado no decorrer de um período de tempo razoável, ocorrendo perdas de pacotes, retransmissões, etc. Interessante também para detecção de casos de memory starvation.	As 4 balizas foram ativadas, a sequência de emissão foi averiguada através dos padrões de piscagem dos LEDs de cada uma, e por meio das mensagens vindas do Listener (Mica 2 conectado em porta serial). Analisou-se o funcionamento das balizas por 5 minutos, com o fair_timeout e o ack_timeout, aproximadamente iguais a 1s e 200ms respectivamente.	Passou

Integração

As informações necessárias para uma correta interoperabilidade entre os sistemas é encontrada nessa seção.

Passo-a-passo

Um sistema interessado em ouvir as informações passadas pelas balizas, pode fazê-lo, com auxílio do EPOS, seguindo o esqueleto abaixo:

#include <nic.h>
const unsigned char DATA_PROTOCOL = 0xFF;

// Definição da PDU
typedef struct PDU
{
	unsigned int beacon_rssi[4];
	unsigned int target_rssi;
};
 
int main()
{
       // Definição de variáveis
       int status;
       unsigned char * addr;
       unsigned char * prot;
       NIC * nic;
       PDU * pdu;

        // Alocações de memória
	nic = new NIC();
	pdu = (PDU *) malloc(sizeof(PDU));
	addr = (unsigned char *) malloc(sizeof(char));
	prot = (unsigned char *) malloc(sizeof(char));

        // Loop infinito
	while(true)
        {
		status = nic->receive(addr, prot, pdu, NIC::MTU);
		if((status != 0) && (*prot == DATA_PROTOCOL))
                {  

			// código de tratamento

		}
	}
}

Dentro do contexto do IPS, é interessante notar que os sistemas em questão devem preocupar-se apenas com os pacotes cujo protocolo seja DATA_PROTOCOL, quaisquer outros devem ser ignorados, por tratarem-se de pacotes de controle.

Outro fator que merece atenção são os campos do pdu que realmente importam - pdu->beacon_rssi[i] e pdu->target_rssi. Os outros, igualmente, são de uso interno ao IPS.

Nota: A alocação dinâmica (malloc) foi utilizada pois um bug foi encontrado no cross-compiler do AVR.

Calibragem

Para uma partida justa, deve-se definir o valor de fair_timeout junto as equipes. Esse valor é referente ao tempo mínimo entre a emissão dos PDUs. Uma dada baliza ao perceber que a baliza anterior, no sentido horário, emitiu um PDU, aguarda esse tempo antes de emitir seu próprio pacote.

Binários (Nova versão)

Já que ambos os times dependem das informações dos beacons, estamos disponibilizando um pacote com as imagens das quatro balizas, calibradas com 1 segundo de fair timeout, e um script para fazer o upload das mesmas nos Micas. imagens.zip