6.4 Algoritmos de navegac¸˜ao e ajuste
7.1.1 Payload Listener
O m´odulo payload listener ´e o m´odulo respons´avel por receber informac¸˜ao proveniente do payload. Essa informac¸˜ao ´e uma mensagem do tipo promessa. Este componente implementa um protocolo de duas fases. Na primeira fase ´e negociada qual o tipo de mensagem a ser enviada e na segunda fase ´e enviado o conte´udo da mensagem. Isto ´e necess´ario visto o microcontrolador n˜ao ter capacidade de converter entre tipos de dados diferentes e n˜ao ter capacidade para efectuar uma cache dos dados recebidos, ou seja, o microcontrolador tem que saber ´a priori o que vai receber e quando vai receber. Para isso o m´odulo comec¸a por esperar por uma mensagem RTS respondendo ´a mesma com uma mensagem CTS. Ap´os o envio da mensagem, o m´odulo aguarda uma segunda men- sagem que dever´a conter o tipo da mensagem. Esse tipo ´e constitu´ıdo por trˆes caracteres. Ap´os a recepc¸˜ao desta ´ultima mensagem termina a primeira fase do protocolo e d´a-se inicio ´a segunda fase. A segunda fase comec¸a com a recepc¸˜ao de uma mensagem do tipo RTS e envio da respectiva resposta CTS. Depois disso o payload pode iniciar o envio do conte´udo da mensagem. Todas estas interacc¸˜oes s˜ao limitadas por um valor de tempo predefinido que ´e 20 milissegundos.
O m´odulo payload listener, como indicado anteriormente, implementa um protocolo de duas fases. Para ser poss´ıvel calcular o melhor tempo ´e necess´ario que o tamanho dos dados recebidos pela interface s´erie sejam o m´ınimo poss´ıvel mas n˜ao pode ser zero visto que, se n˜ao forem recebidos dados a func¸˜ao de recepc¸˜ao espera at´e que o tempo de time- out indicado passe e isso demora muito mais que receber uma mensagem.
A tabela 7.1 apresenta um resumo das informac¸˜oes gerais para os testes efectuados ao m´odulo payload listener e os tempos obtidos para este m´odulo s˜ao apresentados na tabela 7.2.
Nome do m´odulo Tempo m´ınimo Tempo m´edio Tempo m´aximo
Payload Listener 0,761 24,9044 63,582
Tabela 7.2: Tempos para o m´odulo payload listener.
inv´alida. Esta mensagem pode ser ru´ıdo no meio que ´e utilizado (interface s´erie) e consi- deramos que a mesma tem apenas 1 byte e esse byte tem o valor 13. A recepc¸˜ao do valor 13 ´e uma das condic¸˜oes de sa´ıda para a func¸˜ao que lˆe do meio utilizado. Esta situac¸˜ao pode ocorrer se existir alguma interferˆencia no meio de comunicac¸˜ao e ocorre raramente. O tempo m´edio para este m´odulo ´e um pouco dif´ıcil de quantificar. Isto porque o caso esperado depende do n´umero de vezes que o payload envia uma promessa por segundo e o n´umero de vezes que o ciclo que cont´em todos os m´odulos itera (o tempo que o wormhole demora a iterar). Se o m´odulo executa e recebe as mensagens correctamente este demora no m´aximo 44,522 milissegundos mas se ele n˜ao receber nada demora 20 milissegundos que ´e o tempo do timeout da func¸˜ao de leitura. No caso actual o payload envia duas pro- messas por segundo, logo podemos concluir que existiram mais timeouts do que entregas correctas. Se considerarmos que o ciclo de controlo executa 10 vezes, podemos calcular e obter 24,9044 milissegundos (8 vezes sem receber e 2 recebendo mensagens).
Para o tempo m´edio foi criado um ambiente em que o m´odulo apenas recebe men- sagens v´alidas e processa m´ultiplas mensagens uma das quais do tipo promessa. Este ambiente representa o caso esperado de execuc¸˜ao. As mensagens trocadas neste ambiente s˜ao:
• Duas mensagens RTS; • Duas mensagens CTS; • Uma mensagem de tipo;
• Uma mensagem do tipo promessa.
Na primeira fase do protocolo, o wormhole bridge comec¸a por enviar uma mensa- gem RTS, o wormhole recebe esta mensagem e envia uma mensagem CTS, o wormhole
bridgerecebe e envia o tipo da mensagem que vai enviar na segunda fase. A segunda
fase comec¸a pelo envio de uma mensagem RTS por parte do wormhole bridge, sendo de- pois enviada uma mensagem CTS por parte do wormhole e finalmente o wormhole bridge pode comec¸ar a enviar a mensagem do tipo promessa.
Para o tempo m´aximo foi criado um ambiente em que o m´odulo recebe as todas as mensagens esperadas excepto a ´ultima. Todas as mensagens recebidas s˜ao recebidas no
´ultimo momento poss´ıvel antes do timeout de forma `a operac¸˜ao demorar o m´aximo de tempo poss´ıvel. A ´ultima operac¸˜ao de recepc¸˜ao termina com timeout. As mensagens trocadas neste ambiente s˜ao:
• Duas mensagens RTS; • Duas mensagens CTS; • Uma mensagem de tipo.
Na primeira fase do protocolo, o wormhole bridge comec¸a por enviar uma mensa- gem RTS, o wormhole recebe esta mensagem e envia uma mensagem CTS, o wormhole bridge recebe e envia o tipo da mensagem que vai enviar na segunda fase. A segunda fase comec¸a pelo envio de uma mensagem RTS por parte do wormhole bridge, sendo depois enviada uma mensagem CTS por parte do wormhole. A ´ultima mensagem n˜ao ´e enviada de forma a obrigar a func¸˜ao que lˆe da porta s´erie a sair por timeout.
7.1.2
Position Updater
O m´odulo position updater ´e respons´avel pela actualizac¸˜ao da posic¸˜ao do robˆo utilizando o aceler´ometro e girosc´opio que existem no robˆo. O aceler´ometro como indicado ante- riormente permite a leitura de acelerac¸˜oes que o mesmo sofre ao longo do tempo. O gi- rosc´opio permite a leitura de valores de velocidade angular. Com estes valores ´e poss´ıvel calcular respectivamente a posic¸˜ao do robˆo e orientac¸˜ao do mesmo. O algoritmo deste m´odulo obt´em os valores dos sensores de acordo com o tipo de movimento actual. Se o movimento for rectil´ıneo, o m´odulo obt´em o valor de posic¸˜ao. Se o movimento for curvil´ıneo, o m´odulo obt´em o valor da orientac¸˜ao. Isso ´e feito para evitar leituras com valores incorrectos quando o robˆo efectua movimentos que n˜ao correspondem ao tipo de leitura, ou seja, no caso do movimento curvil´ıneo consideramos que o mesmo n˜ao altera a posic¸˜ao do robˆo, apenas a orientac¸˜ao e no caso do movimento rectil´ıneo consideramos que o mesmo n˜ao altera a orientac¸˜ao do robˆo.
A tabela 7.3 apresenta um resumo das informac¸˜oes gerais para os testes efectuados ao m´odulo position update e os tempos obtidos para este m´odulo s˜ao apresentados na tabela 7.4.
Para o tempo m´ınimo foi criado um ambiente em que o robˆo est´a parado. Com isso o m´odulo sabe que n˜ao precisa de executar e retorna imediatamente.
Para o tempo m´edio foi criado um ambiente em que o robˆo est´a a efectuar um movi- mento rectil´ıneo e posteriormente efectua um movimento curvil´ıneo. Com o movimento
Nome do m´odulo Position Updater
Descric¸˜ao do m´odulo M´odulo respons´avel pela actualizac¸˜ao da
posic¸˜ao e orientac¸˜ao atrav´es de sensores locais (aceler´ometro e girosc´opio).
Descric¸˜ao do teste Pretende-se testar os tempos para este
m´odulo sabendo que os mesmos depen- dem do tipo de movimento que o robˆo est´a a efectuar nesse momento.
Aguarda por entrada de dados (Tempo m´aximo/N˜ao)
N˜ao
Tabela 7.3: Informac¸˜oes gerais para o m´odulo position updater.
Nome do m´odulo Tempo m´ınimo Tempo m´edio Tempo m´aximo
Position Updater 0,064 1,856 2,304
Tabela 7.4: Tempos para o m´odulo position updater.
rectil´ıneo foi obtido o tempo que o m´odulo demora a processar a posic¸˜ao. Com o movi- mento curvil´ıneo foi obtido o tempo que o m´odulo demora a processar a orientac¸˜ao. O valor final ´e a m´edia dos dois tempos.
Para o tempo m´aximo foi criado um ambiente em que o robˆo est´a a efectuar um movi- mento curvil´ıneo. O m´odulo efectua o c´alculo da nova orientac¸˜ao do robˆo. A orientac¸˜ao demora mais a ser calculada porque no c´odigo de c´alculo da orientac¸˜ao existe tamb´em o c´alculo das func¸˜oes seno e co-seno para o novo valor de orientac¸˜ao.
7.1.3
Obstacle Updater
O m´odulo obstacle updater ´e respons´avel pela detecc¸˜ao e envio da posic¸˜ao dos obst´aculos. Estes obst´aculos s˜ao detectados pelos sensores de distˆancia instalados no robˆo. Cada vez que um obst´aculo ´e detectado, se o mesmo estiver perto do robˆo, uma mensagem ´e envi- ada para o payload a indicar as coordenadas do mesmo. Visto que os sensores s˜ao digitais existe um tempo adicional para a interpretac¸˜ao do valor e como a operac¸˜ao ´e bloqueante ´e necess´ario existir um timeout para limitar o tempo que a func¸˜ao de leitura espera para ler o valor. Se um sensor for desligado ou se nenhum obst´aculo for detectado um timeout ocorre. O robˆo tem instalado 3 sensores de distˆancia, um posicionado na frente, outro na esquerda e outro na direita. A posic¸˜ao do obst´aculo no mapa s´o ´e enviada se o mesmo estiver a menos de 50 cent´ımetros do robˆo.
Nome do m´odulo Obstacle Updater
Descric¸˜ao do m´odulo M´odulo respons´avel pela detecc¸˜ao de
obst´aculos atrav´es dos sensores locais (sensores ultra-s´onicos) e envio das coor- denadas para o payload.
Descric¸˜ao do teste Pretende-se testar os tempos para este
m´odulo sabendo que os mesmos depen- dem da distˆancia a que os obst´aculos est˜ao do sensor.
Aguarda por entrada de dados (Tempo m´aximo/N˜ao)
30000.
Tabela 7.5: Informac¸˜oes gerais para o m´odulo “obstacle updater”.
Nome do m´odulo Tempo m´ınimo Tempo m´edio Tempo m´aximo
Obstacle Updater 0,175 32,064 90,112
Tabela 7.6: Tempos para o m´odulo “obstacle updater”.
A tabela 7.5 apresenta um resumo das informac¸˜oes gerais para os testes efectuados ao m´odulo obstacle update e os tempos obtidos para este m´odulo s˜ao apresentados na tabela 7.6.
Para o tempo m´ınimo foi criado um ambiente em que um obst´aculo est´a encostado a cada um dos sensores de forma as respectivas func¸˜oes de leitura retornarem o mais rapi- damente poss´ıvel. O m´odulo comec¸a por verificar o primeiro sensor e assim que obt´em o valor de distancia, verifica se o mesmo esta dentro dos limites. Com est´a a posic¸˜ao no mapa ´e calculada e as coordenadas s˜ao enviadas. Este processo ´e repetido mais duas vezes para os restantes sensores.
Para o tempo m´edio foi criado um ambiente em que um obst´aculo ´e detectado a 2 me- tros. A distˆancia m´axima obtida pelos sensores ´e 4 metros. Como os obst´aculos podem estar a qualquer distˆancia do robˆo, utilizamos a distˆancia m´edia. O m´odulo comec¸a por verificar o primeiro sensor e assim que obt´em o valor de distancia, verifica se o mesmo esta dentro dos limites. Com n˜ao est´a o m´odulo segue para o pr´oximo sensor.
Para o tempo m´aximo foi criado um ambiente em que todas as leituras terminam por timeout. Isto pode ser conseguido facilmente desligando todos os sensores ligados ao robˆo. O valor de timeout ´e 20 milissegundos.
Nome do m´odulo Position Sender
Descric¸˜ao do m´odulo M´odulo respons´avel pelo envio dos dados
de posic¸˜ao para o wormhole.
Descric¸˜ao do teste Pretende-se testar os tempos para este
m´odulo sabendo que os mesmos depen- dem dos dados enviados.
Aguarda por entrada de dados (Tempo m´aximo/N˜ao)
N˜ao
Tabela 7.7: Informac¸˜oes gerais para o m´odulo position sender.
Nome do m´odulo Tempo m´ınimo Tempo m´edio Tempo m´aximo
Position Sender 16,64 16,896 17,536
Tabela 7.8: Tempos para o m´odulo position sender.
7.1.4
Position Sender
O m´odulo position sender ´e respons´avel pelo envio da posic¸˜ao, orientac¸˜ao e velocidade para o payload. A posic¸˜ao ´e constitu´ıda por dois campos: posic¸˜ao em X e posic¸˜ao em Y. Este envio ´e feito depois da actualizac¸˜ao dos valores pelo m´odulo position updater. Este m´odulo corre apenas uma vez por ciclo de controlo. No processo de envio, n´umeros que sejam negativos necessitam de um byte adicional para o sinal negativo. Neste envio ´e importante indicar que no estado actual do projecto a posic¸˜ao n˜ao deve ser menor que 0, embora o valor seja poss´ıvel caso existam erros nas leituras dos sensores, a velocidade ´e sempre positiva (velocidade escalar) e a orientac¸˜ao pode ser negativa. O envio de um byte adicional aumenta o tempo que o m´odulo demora a terminar. Os testes e os valores obtidos dos testes reflectem as observac¸˜oes anteriores.
A tabela 7.7 apresenta um resumo das informac¸˜oes gerais para os testes efectuados ao m´odulo position sender e os tempos obtidos para este m´odulo s˜ao apresentados na tabela 7.8.
Para o tempo m´ınimo foi criado um ambiente em que os valores de posic¸˜ao, velocidade e orientac¸˜ao s˜ao positivos. Os valores inteiros (posic¸˜ao e velocidade) s˜ao na ordem das dezenas e quando a orientac¸˜ao tem 9 casas decimais.
Para o tempo m´edio foi criado um ambiente em os valores da velocidade e posic¸˜ao s˜ao positivos e a orientac¸˜ao alterna entre positiva e negativa. As mesmas opc¸˜oes do ambi- ente criado para medir o tempo m´ınimo aplicam-se mas o facto de um valor ser negativo aumenta o n´umero de bytes a enviar em um.
Nome do m´odulo TTFD Task Listener
Descric¸˜ao do m´odulo M´odulo respons´avel pela aplicac¸˜ao de pe-
nalidades caso o componente payload fa- lhe o cumprimento de prazos.
Descric¸˜ao do teste Pretende-se testar os tempos para este
m´odulo sabendo que os mesmos depen- dem do cumprimento das promessas por parte do componente payload.
Aguarda por entrada de dados (Tempo m´aximo/N˜ao)
N˜ao
Tabela 7.9: Informac¸˜oes gerais para o m´odulo “FPGA listener”.
Nome do m´odulo Tempo m´ınimo Tempo m´edio Tempo m´aximo
TTFD Task Listener 0,064 0,128 4,224
Tabela 7.10: Tempos para o m´odulo FPGA listener.
s˜ao negativos e a velocidade ´e positiva. As mesmas opc¸˜oes do ambiente criado para medir o tempo m´ınimo aplicam-se mas o facto de trˆes valores(a posic¸˜ao tem dois valores) serem negativos aumenta o n´umero de bytes a enviar em trˆes.
7.1.5
TTFD Task Listener
O m´odulo TTFD task listener ´e respons´avel pela aplicac¸˜ao de penalidades ao payload caso o mesmo n˜ao cumpra as promessas que entrega. O tempo ´e actualmente monito- rizado pela FPGA e esta ´e capaz de indicar ao wormhole quem ´e que det´em o controlo sendo depois da responsabilidade do wormhole a aplicac¸˜ao de penalidades ao wormhole. Estas penalidades s˜ao perder o controlo do robˆo e reiniciar o componente payload. Este m´odulo apenas executa quando o robˆo encontra-se num estado activo (depois de receber o mapa e a primeira promessa).
A tabela 7.9 apresenta um resumo das informac¸˜oes gerais para os testes efectuados ao m´odulo FPGA listener e os tempos obtidos para este m´odulo s˜ao apresentados na tabela 7.10.
Para o tempo m´ınimo foi criado um ambiente em que o robˆo apenas recebeu o mapa mas ainda n˜ao recebeu a primeira promessa logo este m´odulo sai sem efectuar nenhuma verificac¸˜ao ao prazo.
Nome do m´odulo Safety Task
Descric¸˜ao do m´odulo M´odulo respons´avel pelo controlo do
robˆo caso o componente payload falhe o cumprimento de prazos.
Descric¸˜ao do teste Pretende-se testar os tempos para este
m´odulo sabendo que os mesmos depen- dem do cumprimento das promessas por parte do componente payload.
Aguarda por entrada de dados (Tempo m´aximo/N˜ao)
N˜ao
Tabela 7.11: Informac¸˜oes gerais para o m´odulo “safety task”.
Nome do m´odulo Tempo m´ınimo Tempo m´edio Tempo m´aximo
Safety Task 0,064 0,064 7,424
Tabela 7.12: Tempos para o m´odulo safety task.
payload est´a a cumprir os prazos das promessas. Neste caso o wormhole verifica se o
payloadest´a a cumprir as promessas e termina visto este estar a cumprir. Este ´e o caso
mais comum e ideal porque o payload tem uma capacidade maior de efectuar um melhor controlo do robˆo.
Para o tempo m´aximo foi criado um ambiente em que o robˆo j´a se encontra activo, o payloadn˜ao cumpriu o ´ultimo prazo e j´a falhou trˆes outros prazos. Neste caso o wormhole verifica que o payload n˜ao est´a a cumprir prazos, transita o controlo para o wormhole e verifica que j´a falhou quatro vezes reiniciando o payload. Para transitar o controlo ´e en- viada uma mensagem para transitar o controlo e ´e enviada outra mensagem para reiniciar o payload.
7.1.6
Safety Task
O m´odulo “safety task” ´e respons´avel pelo controlo do robˆo caso o payload n˜ao cumpra as promessas que envia. Este m´odulo cont´em um algoritmo de controlo simples que utiliza as coordenadas de destino enviadas pelo payload para saber para onde se deve deslocar.
A tabela 7.11 apresenta um resumo das informac¸˜oes gerais para os testes efectuados ao m´odulo Safety Task e os tempos obtidos para este m´odulo s˜ao apresentados na tabela 7.12.
Nome do m´odulo Velocity Observer
Descric¸˜ao do m´odulo M´odulo respons´avel pelo controlo da ve-
locidade do robˆo.
Descric¸˜ao do teste Pretende-se testar os tempos para este
m´odulo sabendo que os mesmos depen- dem da velocidade actual estar correcta e demora de transmiss˜ao de novos dados aos motores.
Aguarda por entrada de dados (Tempo m´aximo/N˜ao)
N˜ao
Tabela 7.13: Informac¸˜oes gerais para o m´odulo “velocity observer”.
prir as promessas, logo o m´odulo n˜ao ´e necess´ario e termina. Este ´e o caso mais comum e o ideal porque o payload tem uma maior capacidade de efectuar um melhor controlo do robˆo.
Para o tempo m´aximo foi criado um ambiente em que o payload n˜ao esta a cumprir as promessas e existem coordenadas validas de destino. Adicionalmente o robˆo est´a co- locado num beco sem sa´ıda no qual n˜ao de avanc¸ar mais para a frente. Isso permite ao m´odulo executar o algoritmo de procura de caminhos e adicionalmente obriga o robˆo a retroceder. O retrocesso demora ligeiramente mais visto que o wormhole tˆem que obter o ´ultimo valor da lista de passos e calcular a direcc¸˜ao.
7.1.7
Velocity Observer
Este m´odulo ´e respons´avel pela monitorizac¸˜ao da velocidade. Como n˜ao podemos indicar aos motores a velocidade que queremos, utilizamos o aceler´ometro de forma a calcular a velocidade e a fazer pequenos ajustes para que o robˆo prossiga `a velocidade indicada. Este m´odulo apenas est´a activo quando o robˆo avanc¸a para a frente ou tr´as. Como indicado anteriormente os motores recebem novas ordens com base num impulso enviado para os mesmos. Dependendo do comprimento do impulso enviado, o tempo que este m´odulo demora a terminar varia.
A tabela 7.13 apresenta um resumo das informac¸˜oes gerais para os testes efectuados ao m´odulo Velocity Observer e os tempos obtidos para este m´odulo s˜ao apresentados na tabela 7.14.
Para o tempo m´ınimo foi criado um ambiente em que o robˆo est´a a efectuar um mo- vimento curvil´ıneo, logo este m´odulo n˜ao precisa de ser executado e o mesmo termina imediatamente.
Nome do m´odulo Tempo m´ınimo Tempo m´edio Tempo m´aximo
Velocity Observer 0,064 3,328 3,712
Tabela 7.14: Tempos para o m´odulo “velocity observer”.
Para o tempo m´edio foi criado um ambiente em a velocidade do robˆo ´e menor que a requerida e o pr´oximo incremento dos motores colocar´a os motores a metade da capaci- dade m´axima (metade do comprimento do impulso enviado, metade do tempo necess´ario). Nesse caso o m´odulo envia nova informac¸˜ao para os motores para que os mesmos rodem mais r´apido. O caso mais comum ´e aquele em que a velocidade necessita de ajustes `a velocidade visto que o robˆo comec¸a parado e este ajuste e necess´ario uma quantidade consider´avel de vezes antes que o mesmo chegue a velocidade requerida.
Para o tempo m´aximo foi criado um ambiente em a velocidade do robˆo ´e menor que a requerida e o pr´oximo incremento dos motores colocar´a os motores na m´axima capaci- dade. Nesse caso o m´odulo envia nova informac¸˜ao para os motores rodem mais r´apido.
7.1.8
Orientation Observer
Este m´odulo ´e respons´avel pela monitorizac¸˜ao da orientac¸˜ao. Como n˜ao podemos indicar aos motores a orientac¸˜ao que queremos, ´e utilizado o girosc´opio de forma a calcular a orientac¸˜ao e saber quando parar a rotac¸˜ao e prosseguir com o movimento anterior. Este m´odulo ´e activo apenas quando o robˆo necessita de mudar de orientac¸˜ao.
A tabela 7.15 apresenta um resumo das informac¸˜oes gerais para os testes efectuados ao m´odulo Orientation Observer e os tempos obtidos para este m´odulo s˜ao apresentados na tabela 7.16.
Para o tempo m´ınimo foi criado um ambiente em que o robˆo est´a a efectuar um movi- mento rectil´ıneo, logo este m´odulo n˜ao precisa de ser executado e termina imediatamente. Para o tempo m´edio foi criado um ambiente em que o robˆo est´a a virar e ainda n˜ao alcanc¸ou a orientac¸˜ao correcta. O m´odulo comec¸a por verificar para que lado o robˆo esta