Faculdade de Ciˆencias
Departamento de Inform´atica
ARQUITECTURA WORMHOLE APLICADA A
ROB ˆ
OS M ´
OVEIS
Gonc¸alo Manuel Cardoso Cruchinho
MESTRADO EM ENGENHARIA INFORM ´
ATICA
Especializac¸˜ao em Arquitectura, Sistemas e Redes de Computadores
Faculdade de Ciˆencias
Departamento de Inform´atica
ARQUITECTURA WORMHOLE APLICADA A
ROB ˆ
OS M ´
OVEIS
Gonc¸alo Manuel Cardoso Cruchinho
PROJECTO
Projecto orientado pelo Prof. Doutor M´ario Jo˜ao Barata Calha
MESTRADO EM ENGENHARIA INFORM ´
ATICA
Especializac¸˜ao em Arquitectura, Sistemas e Redes de Computadores
Comec¸o por agradecer `a minha fam´ılia, ao meu pai, `a minha m˜ae, ao meu irm˜ao, pelo apoio incondicional ao longo dos anos que me permitiu chegar a este momento. Agradec¸o aos amigos, colegas, conhecidos que me fizeram acreditar que era capaz de chegar t˜ao longe. Finalmente agradec¸o ao meu orientador e professor M´ario Calha por todo o suporte na realizac¸˜ao do projecto.
A utilizac¸˜ao de robˆos ´e cada vez mais generalizada, incidindo mais sobre as ´areas de explorac¸˜ao, seguranc¸a e entretenimento. Com a introduc¸˜ao de equipas, os robˆos conse-guem apresentar um aumento na produtividade das suas tarefas, conseguindo fazer mais em menos tempo, embora com essa adic¸˜ao, alguns problemas possam surgir. Esses pro-blemas advˆem da introduc¸˜ao da componente comunicacional necess´aria `a equipa, que pode causar atrasos nas tarefas que o robˆo efectua, devido `a necessidade que o robˆo passa a ter de valores externos fornecidos por outros robˆos e existir uma demora incontrol´avel na obtenc¸˜ao desses valores.
Para mitigar o problema indicado acima, foi criado anteriormente um middleware que garante o controlo atempado de robˆos virtuais. Esse middleware foi criado utilizando a ar-quitectura wormhole, que define dois componentes, um simples e outro complexo, ambos capazes de controlar o robˆo. O componente simples garante a propriedade de execuc¸˜ao s´ıncrona que pode ser utilizada pelo componente complexo. O componente complexo tenta sempre que poss´ıvel controlar o robˆo enquanto o componente simples apenas o tenta controlar quando o complexo n˜ao o consegue.
Este projecto incide sobre o middleware identificado anteriormente, tendo como ob-jectivo melhorar os m´odulos que o comp˜oem, preparando-o para o porte para um robˆo f´ısico e validar a soluc¸˜ao resultante de forma a verificar se a mesma garante o controlo do robˆo dentro de um tempo conhecido ap´os falha de um dos componentes. Com esse porte espera-se verificar que esta arquitectura serve correctamente o prop´osito de controlo de equipas de robˆos. Os resultados permitem-nos concluir que a arquitectura wormhole quando aplicada a um robˆo mitiga os efeitos da introduc¸˜ao de comunicac¸˜ao nos robˆos visto que caso existam atrasos no controlo ´e poss´ıvel ao componente simples manter o controlo tempor´ario do robˆo. Esta mitigac¸˜ao de atrasos aplica-se tamb´em a atrasos cau-sados por interrupc¸˜oes ass´ıncronas que afectam o componente mais complexo.
Palavras-chave: middleware, arquitectura wormhole, comunicac¸˜ao, equipas de robˆos, execuc¸˜ao s´ıncrona
The use of robots is becoming more widespread, focusing more on the areas of ex-ploration, security and entertainment. With the introduction of team, the robots show an increase of productivity in their tasks, enabling them to do more in less time, although with that addition, some problems may occur. Those problems are due to the introduction of the communicational component necessary to the team, which can cause delay in the tasks that the robot performs, due to the necessity of external values provided by other robots and due to the unbounded delay that exists when getting those values.
To mitigate the problem indicated above, a middleware was created that guaranties the timely control of virtual robots. That middleware was created using the wormhole architecture, which defines two components, one simple and another complex, both capa-ble of controlling the robot. The simple component guaranties the synchronous execution property, which can be used by the complex component. The complex component tries, when possible, to control the robot while the simple component only tries to control it when the complex component can?t.
This project makes use of the middleware identified previously, having the objective of improving the middleware?s modules, getting it ready to port to the physical robot and validating the resulting solution in order to check if it can control the robot within a known interval of time after the failure of one components. With this port we want to verify that this architecture serves correctly the purpose of controlling a robot. The results enable us to conclude that the wormhole architecture, when applied to a robot, mitigates the effects of the introduction of communication in the robot, due to the fact that if there is delay in the control it is possible to the simple component to maintain the temporary control of the robot. This delay mitigation applies itself to other type of delay like asynchronous interruptions that affect the complex component.
Keywords: middleware, wormhole architecture, communication, teams of robots, synchronous execution
Lista de Figuras xvi
Lista de Tabelas xix
1 Introduc¸˜ao 1 1.1 Motivac¸˜ao . . . 1 1.2 Objectivos . . . 2 1.3 Contribuic¸˜oes . . . 3 1.4 Ambito . . . .ˆ 3 1.5 Plano de Trabalho . . . 3 1.6 Estrutura do documento . . . 4 2 Trabalho Relacionado 7 2.1 Middleware . . . 8 2.1.1 Motivac¸˜ao . . . 8 2.1.2 Desenho . . . 9 2.1.3 Implementac¸˜ao . . . 11
3 Contexto e enquadramento tecnol´ogico 17 3.1 Linguagens . . . 17 3.1.1 Basic . . . 17 3.1.2 Assembler, C e C++ . . . 18 3.1.3 Java . . . 18 3.1.4 VHDL . . . 18 3.2 Aplicac¸˜oes . . . 19
3.2.1 Micro Basic Studio . . . 19
3.2.2 Eclipse . . . 19
3.2.3 Helix . . . 20
3.2.4 Xilinx ISE Design Suite . . . 21
3.2.5 Simbad Robot Simulator . . . 22
3.2.6 U-Boot . . . 23
3.2.7 Busybox . . . 23 xi
4 Planeamento 33
4.1 Requisitos Funcionais . . . 33
4.2 Requisitos n˜ao Funcionais . . . 34
4.3 Casos de Uso . . . 35
4.3.1 Controlo do robˆo pelo componente wormhole . . . 35
4.3.2 Controlo do tempo do componente payload . . . 37
4.3.3 Gerir posic¸˜ao atrav´es dos sensores locais . . . 38
4.3.4 Movimento pelo mundo f´ısico . . . 39
4.3.5 Detectar Intruso . . . 40 4.4 Metodologia de desenvolvimento . . . 41 5 Arquitectura do Sistema 45 5.1 Payload . . . 45 5.1.1 Mensagens . . . 47 5.2 Wormhole Bridge . . . 47 5.2.1 M´odulos . . . 48 5.2.2 Mensagens . . . 49 5.3 Wormhole . . . 49 5.3.1 M´odulos . . . 50 5.3.2 Mensagens . . . 53 5.3.3 Sensor Layer . . . 55 6 Implementac¸˜ao 61 6.1 1ª Iterac¸˜ao . . . 62 6.1.1 Hardware . . . 62 6.1.2 Preparac¸˜ao do hardware . . . 64
6.1.3 Implementac¸˜ao da camada de sensores . . . 67
6.1.4 Interface com a camada de sensores . . . 68
6.1.5 Safety Task . . . 71
6.1.6 Mapeamento dos Componente no Hardware . . . 72
6.2 2ª Iterac¸˜ao . . . 73
6.2.1 Wormhole . . . 73
6.2.2 Mapeamento dos Componentes no Hardware . . . 75
6.3 3ª Iterac¸˜ao . . . 76
6.3.1 TTFD Task . . . 77
6.3.2 Mapeamento dos Componentes no Hardware . . . 79
6.4 Algoritmos de navegac¸˜ao e ajuste . . . 80 xii
7.1.1 Payload Listener . . . 85 7.1.2 Position Updater . . . 87 7.1.3 Obstacle Updater . . . 88 7.1.4 Position Sender . . . 90 7.1.5 TTFD Task Listener . . . 91 7.1.6 Safety Task . . . 92 7.1.7 Velocity Observer . . . 93 7.1.8 Orientation Observer . . . 94 7.1.9 Resultados Finais . . . 95 7.2 Mensagens . . . 96
8 Conclus˜oes e Trabalho Futuro 101 A 103 A.1 Modelo de Gantt . . . 103
B 115 B.1 Manual for the use of H6090 board . . . 115
B.1.1 Uboot Setup . . . 115
B.1.2 Image Setup . . . 116
B.1.3 Setting up the TFTP Server . . . 117
B.1.4 Running the middleware . . . 118
C 119 C.1 Manual for the wireless configuration of the D-Link G730ap . . . 119
C.1.1 Wireless card set up . . . 119
C.1.2 Pc configuration . . . 119
D 125 D.1 FPGA configuration manual . . . 125
D.1.1 Programmer connection to the PC and card . . . 125
D.1.2 Create the configuration file for the PROM . . . 125
Abreviaturas 135
Bibliografia 138
2.1 Modelo completo da arquitectura do middleware . . . 9
2.2 Estrutura interna do payload . . . 10
2.3 Exemplo de propagac¸˜ao de eventos . . . 14
2.4 Exemplo de execuc¸˜ao do algoritmo de navegac¸˜ao . . . 16
3.1 Ambiente de trabalho da aplicac¸˜ao Basic Micro Studio . . . 20
3.2 Arquitectura da distribuic¸˜ao Helix . . . 21
3.3 Ambiente de trabalho da aplicac¸˜ao ISE Project Navigator . . . 23
3.4 A4WD1 v1 . . . 24
3.5 Motor GHM-01 . . . 25
3.6 Placa controladora Sabertooth 2x12 . . . 25
3.7 Sensor ultra-s´onico SRF05 . . . 26
3.8 Caracter´ısticas da dispers˜ao da onda criada pelo sensor SFR05 . . . 27
3.9 Bot Board II . . . 27
3.10 Atom Pro 28-M . . . 28
3.11 H4090 . . . 28
3.12 H6042 . . . 29
3.13 Placa D-Link G730ap . . . 29
3.14 baterias de 6 Volts . . . 30
3.15 Esquema do circuito el´ectrico . . . 30
4.1 Ambiente de trabalho da aplicac¸˜ao ISE Project Navigator . . . 36
4.2 Metodologia de desenvolvimento iterativo e incremental . . . 42
5.1 Arquitectura final do sistema. . . 46
5.2 Arquitectura do componente wormhole bridge. . . 48
5.3 Ciclo de controlo do componente wormhole. . . 50
5.4 Fluxograma do processo de decis˜ao do novo passo do m´odulo “safety task”. 52 5.5 Cen´ario t´ıpico de comunicac¸˜ao aquando o envio da mensagem do tipo promessa pelo componente payload. . . 54
5.6 Arquitectura do componente “sensor layer”. . . 56
5.7 Arquitectura do m´odulo “wormhole listener”. . . 58
5.8 Arquitectura do m´odulo sensor layer listener. . . 59 xv
6.1 ADXL335 e LISY300AL . . . 63
6.2 Mapeamento dos componentes do middleware no hardware ap´os a pri-meira iterac¸˜ao . . . 72
6.3 Mapeamento dos componentes do middleware no hardware ap´os a se-gunda iterac¸˜ao . . . 76
6.4 Mapeamento dos componentes do middleware no hardware ap´os a ter-ceira iterac¸˜ao . . . 80
7.1 Linha temporal entre a falha do payload e o controlo do robˆo por parte do wormhole. . . 84
7.2 O robˆo utilizado para testes . . . 99
C.1 D-Link G730 Web configuration interface . . . 120
C.2 Wireless network configuration page . . . 120
C.3 The network connection in the windows XP OS . . . 121
C.4 Wireless connection properties . . . 121
C.5 Internet Protocol (TCP/IP) properties . . . 122
C.6 Wireless networks tab . . . 122
C.7 Setting a new wireless network . . . 123
D.1 Cable connection pins . . . 126
D.2 Cable connection colors . . . 127
D.3 Impact Main Window . . . 128
D.4 PROM File Formatter Window . . . 129
D.5 Select configuration file 1 . . . 129
D.6 Select configuration file 2 . . . 130
D.7 Prompt for new configuration file addition . . . 130
D.8 PROM Configuration file creation 1 . . . 131
D.9 PROM Configuration file creation 2 . . . 132
6.1 An´alise de aceler´ometros com base nas suas caracter´ısticas principais . . 63
6.2 An´alise de oscilosc´opios com base nas suas caracter´ısticas principais . . . 63
7.1 Informac¸˜oes gerais para o m´odulo payload listener. . . 85
7.2 Tempos para o m´odulo payload listener. . . 86
7.3 Informac¸˜oes gerais para o m´odulo position updater. . . 88
7.4 Tempos para o m´odulo position updater. . . 88
7.5 Informac¸˜oes gerais para o m´odulo “obstacle updater”. . . 89
7.6 Tempos para o m´odulo “obstacle updater”. . . 89
7.7 Informac¸˜oes gerais para o m´odulo position sender. . . 90
7.8 Tempos para o m´odulo position sender. . . 90
7.9 Informac¸˜oes gerais para o m´odulo “FPGA listener”. . . 91
7.10 Tempos para o m´odulo FPGA listener. . . 91
7.11 Informac¸˜oes gerais para o m´odulo “safety task”. . . 92
7.12 Tempos para o m´odulo safety task. . . 92
7.13 Informac¸˜oes gerais para o m´odulo “velocity observer”. . . 93
7.14 Tempos para o m´odulo “velocity observer”. . . 94
7.15 Informac¸˜oes gerais para o m´odulo “orientation observer”. . . 95
7.16 Tempos para o m´odulo “orientation observer”. . . 95
7.17 Tempos para o ciclo de controlo do componente wormhole. . . 96
7.18 Tamanho m´aximo para cada tipo de mensagem. . . 97
7.19 Total de tr´afego gerado pela totalidade das mensagens. . . 98
D.1 Cable/Pin correspondence . . . 125
Introduc¸˜ao
Este cap´ıtulo apresenta a motivac¸˜ao e objectivos do trabalho realizado, contribuic¸˜oes que o mesmo oferece, ˆambito do projecto e a organizac¸˜ao deste documento.
1.1
Motivac¸˜ao
Robˆos tˆem sido utilizados `a j´a algum tempo em ´areas como explorac¸˜ao, entretenimento e seguranc¸a. Esses robˆos, aut´onomos ou controlados por humanos, ajudam a alcanc¸ar os objectivos efectuando tarefas repetitivas, perigosas ou que requerem precis˜ao. Desses robˆos, alguns s˜ao m´oveis o que significa que eles n˜ao est˜ao fixos a um local e podem efec-tuar tarefas em ´areas diferentes. Isso pode aumentar a probabilidade de algo acontecer ao robˆo porque este vai interagir com um ambiente dinˆamico.
Algumas das tarefas referidas anteriormente requerem cooperac¸˜ao entre os m´ultiplos robˆos de forma a serem concretizadas. De forma a alcanc¸ar os objectivos dessas tarefas, os robˆos necessitam de cooperar, seja enviando informac¸˜ao sobre o ambiente em seu re-dor, seja criando estrat´egias que maximizam os resultados do trabalho em equipa.
Para cooperarem, os robˆos precisam de comunicar entre si, normalmente utilizando um dispositivo de comunicac¸˜ao sem fios. Durante o processo de cooperac¸˜ao podem existir alguns atrasos na actuac¸˜ao do robˆo, por causa de demoras incontrol´aveis na comunicac¸˜ao com outros robˆos. Esses atrasos podem dever-se a v´arios factores como: interferˆencia no canal de comunicac¸˜ao, partic¸˜oes tempor´arias na rede e falhas de outros robˆos. Esses atrasos podem ter impacto na tarefa de controlo. Se esta tarefa sofrer atrasos pode n˜ao conseguir evitar algum perigo imediato.
Um passo importante na mitigac¸˜ao destes problemas que resultam de oscilac¸˜oes no tempo necess´ario para a comunicac¸˜ao, foi tomado com o desenvolvimento de um
mid-dlewarebaseado na arquitectura wormhole[1] para plataformas Linux. Este middleware
foi desenvolvido com o intuito de suportar robˆos virtuais na patrulha de ´areas conhecidas. Os componentes do middleware trabalham em conjunto para garantir a execuc¸˜ao s´ıncrona de tarefas cr´ıticas.
A arquitectura wormhole[2] ´e uma abstracc¸˜ao que define dois subsistemas: o wormhole e o payload. O wormhole ´e um simples e pequeno subsistema que pode garantir proprie-dades que s˜ao dif´ıceis de alcanc¸ar em sistemas grandes. Uma propriedade que ´e relevante para este trabalho ´e a execuc¸˜ao s´ıncrona de tarefas cr´ıticas. O payload ´e um complexo sub-sistema onde a aplicac¸˜ao principal, que pode conter algoritmos consumidores de tempo, ´e executada. A execuc¸˜ao atempada desta aplicac¸˜ao ´e verificada por um componente do
wormholeque ´e o Timely Timing Failure Detector (TTFD).
O que ´e pretendido com este trabalho ´e transportar o middleware j´a criado para um conjunto de hardwares de forma permitir o controlo de um robˆo f´ısico. Durante o processo de porte da aplicac¸˜ao pretende-se refinar os aspectos de gest˜ao de tempo disponibilizados pelo componente wormhole.
1.2
Objectivos
Os objectivos deste trabalho s˜ao:
• Melhorar os algoritmos do middleware mencionado anteriormente;
• Criar uma camada de sensores e motores que permita a interacc¸˜ao com o wormhole; • Adaptar o middleware para um robˆo m´ovel;
• Validar a propriedade de execuc¸˜ao s´ıncrona do wormhole.
Este robˆo deve ser parte de uma equipa de outros robˆos iguais que patrulham uma ´area conhecida.
A plataforma de hardware alvo dos robˆos m´oveis ´e principalmente constitu´ıda por um microcontrolador simples que ´e apropriado para executar a tarefa de controlo e uma placa mais sofisticada que ´e apropriada para executar o payload (num processador ARM) e para executar a TTFD task (numa FPGA independente). Quando o trabalho se iniciou esta plataforma de hardware j´a se encontrava dispon´ıvel.
1.3
Contribuic¸˜oes
O middleware foi implementado nesta plataforma de hardware e a propriedade de execuc¸˜ao s´ıncrona foi validada. Adicionalmente, o m´odulo Safety task, que ´e um componente se-cund´ario do middleware, foi melhorado.
As contribuic¸˜oes deste trabalho aplicam-se a duas ´areas principais. Essas ´areas s˜ao: Rob´otica e Sistemas de tempo real. Na ´area da rob´otica foi criado um robˆo que conhe-cendo o mapa consegue percorrer o mesmo em busca de poss´ıveis intrusos. Na ´area de sis-temas de tempo real foi implementada uma arquitectura wormhole em robˆos. Esta arqui-tectura permite que existam dois subsistemas capazes de controlar o robˆo, um com mais capacidades mas menos confi´avel e outro com menos capacidades mas mais confi´avel. Caso o subsistema com mais capacidades n˜ao esteja a conseguir controlar o robˆo o sis-tema mais confi´avel toma o controlo at´e o outro subsissis-tema conseguir controlar o robˆo de novo.
Em paralelo ao projecto foi escrito um artigo para publicac¸˜ao em breve.
1.4
Ambito
ˆ
Este projecto foi realizado no ˆambito da disciplina de Projecto de Engenharia Inform´atica do Mestrado em Engenharia Inform´atica, da faculdade de Ciˆencias da Universidade de Lisboa. Este projecto est´a inserido numa das linhas de investigac¸˜ao, que ´e a Timeliness and Adaptation in Dependable Systems, de um dos grupos de investigac¸˜ao desta facul-dade, que s˜ao os Navigators, distributed systems research team.
1.5
Plano de Trabalho
O plano de trabalho para 9 meses foi o seguinte:
• Familiarizac¸˜ao com os diferentes m´odulos de hardware e software do robˆo e com o
middlewaredispon´ıvel;
• Melhoria dos componentes existentes do middleware;
• Criac¸˜ao da camada de sensores e interface para comunicac¸˜ao no wormhole; • Portar o wormhole para um microcontrolador;
• Recolha do estado da arte.
• Escrita de artigos cient´ıficos e de relat´orio final.
1.6
Estrutura do documento
Este relat´orio encontra-se organizado da seguinte forma:
• No segundo cap´ıtulo ´e apresentado todo o trabalho relacionado, inclu´ıdo os traba-lhos directamente relacionados com o projecto e trabatraba-lhos que forneceram informac¸˜oes importantes para melhoramento do middleware.
• No terceiro cap´ıtulo ´e apresentado o contexto e o enquadramento tecnol´ogico, onde s˜ao presentadas todas as tecnologias apresentadas no ˆambito deste trabalho assim como as aplicac¸˜oes que s˜ao usadas e hardware.
• No quarto cap´ıtulo ´e apresentado o planeamento. Nesta secc¸˜ao s˜ao apresentados os requisitos do projecto assim como a metodologia de desenvolvimento utilizada. • No quinto cap´ıtulo ´e apresentada a arquitectura de sistemas onde s˜ao apresentadas
todas as decis˜oes tomadas, como m´odulos criados e mensagens que os m´odulos trocam entre si.
• No sexto cap´ıtulo s˜ao apresentados os detalhes da implementac¸˜ao divididos nas v´arias fases de desenvolvimento.
• No s´etimo cap´ıtulo s˜ao apresentados os testes e respectivos resultados.
• No oitavo cap´ıtulo s˜ao apresentadas as conclus˜oes ap´os realizac¸˜ao deste trabalho e trabalho futuro.
Trabalho Relacionado
O desenvolvimento de aplicac¸˜oes cr´ıticas levou `a criac¸˜ao de v´arias soluc¸˜oes de sistema que s˜ao tolerantes a faltas. Uma dessas soluc¸˜oes ´e apresentada em [3], que consiste num subsistema h´ıbrido, chamado TTCB, que adiciona tolerˆancia a intrus˜oes a aplicac¸˜oes existentes. Este componente ´e capaz de executar tarefas cr´ıticas e fornece a capaci-dade de execuc¸˜ao s´ıncrona ao sistema. Este componente adicionalmente possibilita a comunicac¸˜ao com outros TTCB atrav´es de um canal de comunicac¸˜ao seguro de forma a fornecer servic¸os adicionais como consenso. Outra soluc¸˜ao [4] apresenta um sistema h´ıbrido que permite adicionar garantias a ambientes que utilizam comunicac¸˜ao por wi-reless. Esta soluc¸˜ao incide sobre pelot˜oes de ve´ıculos e utiliza a arquitectura wormhole. Num contexto simular a esta ´ultima soluc¸˜ao, o trabalho apresentado em [5] apresenta uma soluc¸˜ao para pelot˜oes de ve´ıculos baseada na arquitectura wormhole. Neste trabalho ´e implementado uma camada confi´avel onde servic¸os de controlo de tempo correm. S˜ao apresentadas soluc¸˜oes para diversos problemas como incerteza no processo comunicacio-nal e inconsistˆencias temporais. O livro [6] fornece v´arios algoritmo, cada um garantindo certas propriedades, que podem ser utilizados na comunicac¸˜ao entre componentes ou en-tre robˆos. Esses algoritmos s˜ao `uteis para a reescrita de protocolos se necess´ario garantir uma ou mais propriedades como ordem de entrega, ou detecc¸˜ao de faltas por parte de um componente ou robˆo. Todos estes trabalhos fornecem informac¸˜oes sobre a implementac¸˜ao de sistemas de tempo real o que permite tirar lic¸˜oes que s˜ao ´uteis para o desenvolvimento deste projecto.
Navegac¸˜ao utilizando um mapa ´e um importante componente para qualquer robˆo m´ovel. Planeamento de caminhos utilizando um mapa foi desenvolvido em geral com o intuito de levar uma entidade de um ponto a outro do mapa na distˆancia m´ınima poss´ıvel. O trabalho em [7] apresenta uma soluc¸˜ao de planeamento de caminhos que planeia o ca-minho baseando-se n˜ao na necessidade de encontrar o caca-minho mais curto, mas sim na necessidade de examinar objectos ou locais no mapa. S˜ao apresentadas soluc¸˜oes para navegac¸˜ao baseada em parˆametros como maximizar a informac¸˜ao obtida dos objectos a examinar no mapa. Esta soluc¸˜ao ´e muito ´util para o desenvolvimento deste projecto
porque a navegac¸˜ao no caso de vigilˆancia deve ter em conta a maximizac¸˜ao do espac¸o vigiado.
O trabalho em [8] apresenta uma Framework de seguimento de objectos que garante que um objecto ´e seguido por pelo menos um robˆo, sendo perfeito para equipas de robˆos m´oveis. Esta soluc¸˜ao ´e muito interessante para tarefas de vigilˆancia visto que ´e necess´ario interceptar um poss´ıvel intruso. Uma soluc¸˜ao de localizac¸˜ao e construc¸˜ao de mapa ´e apre-sentado em [9]. Esta soluc¸˜ao utiliza algoritmos complexos baseado no filtro de Kalman que possibilita a criac¸˜ao de um mapa completo e ao mesmo tempo a localizac¸˜ao dentro do mesmo. Os detalhes de localizac¸˜ao deste trabalho s˜ao interessantes pois os mesmos utilizam sensores locais para desenho e localizac¸˜ao no mapa. Os documentos em [10] e [11] apresentam o filtro de Kalman e explicam a sua utilidade enquanto o documento em [12] apresenta este filtro aplicado a aceler´ometros, o que ´e ´util para o desenvolvimento dos algoritmos de navegac¸˜ao de forma a mitigar o impacto de poss´ıveis leituras com ru´ıdo dos sensores.
O trabalho em [13] apresenta um middleware com o prop´osito de oferecer um motor tolerante a faltas e cooperativo para equipas de robˆos virtuais num contexto de vigilˆancia de ´areas conhecidas. O trabalho deste projecto incidiu sobre esta soluc¸˜ao pelo facto do c´odigo fonte para a mesma estar dispon´ıveis e por ser a ´unica soluc¸˜ao que utiliza a ar-quitectura wormhole. O middleware foi melhorado e aplicado a robˆos m´oveis f´ısicos no ˆambito deste projecto. O middleware ´e apresentado na pr´oxima subsecc¸˜ao.
2.1
Middleware
Nesta secc¸˜ao e respectivas subsecc¸˜oes ´e apresentado todo o trabalho efectuado no ˆambito do middleware para tarefas de vigilˆancia. Inicialmente ´e apresentada a motivac¸˜ao do tra-balho, seguido das decis˜oes de desenho e finalmente de algum detalhe da implementac¸˜ao. A figura 2.1 apresenta um modelo completo do middleware com todos os seus m´odulos.
2.1.1
Motivac¸˜ao
Este middleware [13] pretende garantir o controlo atempado do robˆo independentemente dos poss´ıveis atrasos causados pelo a comunicac¸˜ao entre robˆos. O cen´ario de aplicac¸˜ao do trabalho anterior ´e a vigilˆancia de uma ´area conhecida e a identificac¸˜ao de intrusos. Um intruso ´e algo que ´e encontrado no caminho do robˆo mas n˜ao est´a no mapa. Quando um intruso ´e encontrado, o robˆo deve adoptar uma estrat´egia de bloqueio f´ısico de forma a cortar poss´ıveis caminhos de fuga. Para uma ´area ser conhecida, um mapa tem que ser fornecido antes do middleware iniciar. Este projecto foi desenvolvido sobre o trabalho apresentado em [13] com o intuito de criar um middleware que possa ser aplicado a robˆos
Figura 2.1: Modelo completo da arquitectura do middleware
f´ısicos. Este trabalho foi escolhido devido ao facto de ser a ´unica soluc¸˜ao at´e ao momento a utilizar a arquitectura wormhole e ser uma das restric¸˜oes deste trabalho. Adicionalmente o c´odigo fonte est´a dispon´ıvel o que permite observar a implementac¸˜ao e serve como base para eventuais melhorias.
2.1.2
Desenho
Na figura 2.2 ´e poss´ıvel visualizar a estrutura interna do middleware e o fluxo de dados entre os v´arios componentes.
O middleware tem como objectivo criar uma ponte entre o programador e a camada de sensores mais abaixo, o que permite controlar um robˆo, inserido numa equipa de robˆos, que efectua tarefas de vigilˆancia de uma localizac¸˜ao. Essa ponte adicionalmente permite ao programador tolerˆancia a inconsistˆencias no tempo que o payload demora a completar a tarefa de controlo.
Dentro do contexto de vigilˆancia de uma ´area conhecida, um middleware foi criado que utiliza a arquitectura wormhole. O desenho define uma camada de controlo com-posta por dois componentes, um s´ıncrono e o outro ass´ıncrono, que permitem a execuc¸˜ao atempada da tarefa de controlo do robˆo. O componente s´ıncrono, ou wormhole, neces-sita de controlar o tempo que o componente ass´ıncrono, ou payload, demora a produzir um resultado. O resultado neste contexto ´e um conjunto de valores que s˜ao utilizados
Figura 2.2: Estrutura interna do payload
no controlo do robˆo. Adicionalmente `as capacidades de controlo de tempo mencionadas anteriormente, o wormhole deve ser capaz de controlar o robˆo quando necess´ario e ac-tuar como um filtro entre a camada de sensores e motores e o payload para que toda a informac¸˜ao passe primeiro pelo wormhole, sendo necess´ario aprovac¸˜ao do mesmo antes de chegar ao destino. Um destes componente, wormhole ou payload, controla o robˆo a cada momento. Ter o controlo do robˆo implica enviar comandos de velocidade e direcc¸˜ao para o hardware.
De forma ao componente payload utilizar a capacidade de execuc¸˜ao atempada de tarefas do componente wormhole, foi criada uma estrutura de dados que ´e enviada pelo
pay-loadpara o wormhole. A estrutura chama-se promessa e cont´em valores de velocidade,
direcc¸˜ao e destino para controlo do robˆo e o prazo para a chegada da pr´oxima promessa para que o wormhole possa monitorizar o tempo que o payload demora. Os valores rece-bidos na promessa s˜ao depois enviados para a camada de sensores para serem aplicados aos motores.
O componente wormhole ´e dividido em trˆes m´odulos:
• Timely Timing Failure Detector, ou TTFD task, ´e o m´odulo que monitoriza o tempo que o payload demora para gerar uma promessa;
tempo estipulado ou caso o payload n˜ao envie promessas durante muito tempo; • Control task que recebe a promessa do payload e decide se os valores devem ser
reencaminhados para os sensores e motores.
Quando o componente payload n˜ao cumpre um prazo para enviar a promessa, o m´odulo TTFD Task pode temporariamente mudar o controlo para o wormhole at´e o
pay-load conseguir de novo cumprir a promessa. Se isso acontecer o componente payload
recebe uma informac¸˜ao em conforme foi desactivado e deve cumprir a pr´oxima promessa de forma a conseguir obter o controlo de novo. Se o payload n˜ao cumprir a promessa um n´umero pr´e-definido de vezes, ou se n˜ao enviar a promessa durante um intervalo de tempo pr´e-definido, o wormhole pode reiniciar o payload.
O componente payload foi constru´ıdo segundo uma estrutura de ´arvore de eventos. A ´arvore de eventos define que um m´odulo pode ser instalado em qualquer parte da ´arvore tendo que ter pelo menos um m´odulo pai. Cada vez que um evento ´e gerado o mesmo passa por todos os m´odulos que est˜ao abaixo do m´odulo que o gerou. Existem trˆes tipos de eventos:
• os hard events que s˜ao os eventos gerados pelo hardware do robˆo, como obst´aculos perto do robˆo, e s˜ao sempre enviados localmente para todos os m´odulos a partir da raiz da ´arvore;
• os soft events que s˜ao eventos que podem ser gerados por m´odulos na ´arvore e s˜ao enviados localmente para todos os m´odulos abaixo do m´odulo que o gerou;
• os remote soft events que s˜ao eventos que podem ser gerados pelos m´odulos na ´arvore e s˜ao enviados para o m´odulo na mesma localizac¸˜ao da ´arvore noutros robˆos e transmitidos para todos os m´odulos abaixo desse.
Na pr´oxima subsecc¸˜ao vamos detalhar o comportamento do wormhole e payload im-plementado no middleware.
2.1.3
Implementac¸˜ao
O middleware foi criado para gest˜ao de equipas de robˆos que trabalha concorrentemente para garantir a vigilˆancia de um local. No ˆambito do middleware uma equipa ´e um con-junto de robˆos que se encontram ao alcance de pelo menos outro robˆo o que permite que comuniquem entre eles, sendo poss´ıvel existirem v´arios grupos num dado cen´ario. O ca-nal de comunicac¸˜ao ´e utilizado pela equipa para indicar as posic¸˜oes de cada robˆo, para indicar a posic¸˜ao de poss´ıveis obst´aculos e intrusos. O canal de comunicac¸˜ao tamb´em ´e utilizado para tarefas de manutenc¸˜ao do grupo como por exemplo, a entrada de novos
robˆos num grupo que ocorre quando dois grupos passam a estar no alcance um do outro, sendo necess´ario cruzar informac¸˜oes de forma a sincronizar a vista que cada robˆo tem do ambiente.
Para a operac¸˜ao correcta do middleware, o mapa da ´area que o robˆo estar´a a efectuar acc¸˜oes de vigilˆancia tem que ser fornecido quando o robˆo ´e activado. O mapa em quest˜ao ´e representado atrav´es de c´elulas o que permite uma representac¸˜ao simples de qualquer ambiente. O tamanho das c´elulas `e configur´avel e permite que a largura sejam diferente do comprimento. Em relac¸˜ao `a codificac¸˜ao do mapa, existe um car´acter que representa as paredes e um outro que representa o caminho o que permite a criac¸˜ao de um mapa com relativa facilidade. No entanto para ser poss´ıvel utilizar este mapa, algumas convers˜oes s˜ao necess´arias visto existirem infinitas posic¸˜oes reais dentro de uma c´elula virtual.
De forma a simular a interacc¸˜ao entre v´arios robˆos, o simulador de robˆos Simbad foi usado. Este simulador pode simular ambientes permitindo que robots virtuais, que tamb´em s˜ao simulados pelo mesmo, interajam com o ambiente.
O middleware est´a disponibilizado em duas vers˜oes: a Simulator que permite a criac¸˜ao de simulac¸˜ao de equipas de robˆos virtuais e estac¸˜oes fixas; a Mobile que consiste na vers˜ao que n˜ao tem nenhuma ligac¸˜ao com o simulador Simbad.
O middleware foi criado utilizando a linguagem de programac¸˜ao C tendo sido depois ligada em Simbad atrav´es de JNI porque o Simbad foi desenvolvido utilizando a lingua-gem de programac¸˜ao JAVA . A raz˜ao do middleware ter sido criado em C ´e porque C est´a dispon´ıvel para mais plataformas que o Java especialmente plataformas com baixo n´ıvel de recursos (CPU e mem´oria).
Wormhole
A implementac¸˜ao do componente wormhole segue a ideia base do modelo, ou seja, um componente simples que garante uma ou v´arias propriedades dif´ıceis de obter num com-ponente complexo. O wormhole implementa um subsistema que garante a execuc¸˜ao s´ıncrona do componente payload e controla o acesso a alguns recursos cr´ıticos do sistema. Para isso ser poss´ıvel esta implementac¸˜ao disponibiliza um protocolo de comunicac¸˜ao en-tre o payload e o wormhole. O protocolo utiliza uma estrutura denominada de promessa que ´e utilizada pelo payload para indicar o tempo que estima demorar no processamento de uma tarefa. O wormhole recebe, analisa e guarda esta promessa de forma a poder posteriormente monitorizar o processo que a enviou. O objectivo desta observac¸˜ao ´e de-terminar se o payload completa a tarefa dentro do tempo que o mesmo estipulou. Se isso ocorrer os dados enviados pelo payload s˜ao encaminhados pelo wormhole para a camada de sensores, sen˜ao o wormhole adquire o controlo do robˆo e controla-o at´e o componente
payloadvoltar a cumprir uma promessa. Adicionalmente o wormhole tem a possibilidade de reiniciar o payload se o mesmo n˜ao efectuar nenhuma tentativa de contacto durante um extenso per´ıodo de tempo ou falhar o cumprimento da promessa v´arias vezes.
O wormhole implementado tem 3 m´odulos:
• Safety task, que ´e utilizado cada vez que o payload perde controlo, seja por inactivi-dade seja por demora na entrega de promessas. Este m´odulo utiliza as coordenadas de destino enviadas pelo payload para o saber para onde o robˆo se deve dirigir. • TTFD task, que consiste num processo que armazena e verifica prazo, notifica o
payload sempre que o mesmo falha a entrega e activa a safety task sempre que
necess´ario;
• Control task, que recebe os dados do payload e envia-os para os sensores de acordo com o estado do payload.
Estes trˆes m´odulos trabalham para permitirem ao componente payload a capacidade de execuc¸˜ao atempada do controlo do robˆo. Todos os m´odulos apresentados trabalham sobre estado do payload guardado pelo wormhole. Este estado ´e partilhado entre todos os m´odulos do wormhole e pode ter um de trˆes estados perante o wormhole que s˜ao:
• Desactivado, em que o wormhole controla o robˆo. Este estado ´e alcanc¸ado depois do payload n˜ao ter cumprido pelo menos uma promessa ou caso deixe de responder por um per´ıodo de tempo predefinido. Neste estado, se o payload continuar a n˜ao cumprir as promessas que envia, o mesmo ´e reiniciado.
• Em testes, em que o wormhole controla o robˆo. Este estado ´e alcanc¸ado depois do payload ter estado desactivado e ter enviado posteriormente uma promessa. O conte´udo dessa promessa ´e ignorado mas serve para assinalar ao wormhole que o
payloadesta a tentar de novo a tentar cumprir as promessas.
• Activo, em que o payload controla o robˆo. Este ´e o estado preferencial do sis-tema visto que o payload tem uma capacidade maior de cumprir objectivos que o wormhole. Este estado indica tamb´em que o payload cumpriu a ´ultima promessa que entregou. O robˆo alcanc¸a este estado se anteriormente estava em testes e se cumpriu a ´ultima promessa.
Payload
O payload ´e um componente ass´ıncrono que comporta todos os processos complexos e n˜ao deterministas. O payload utiliza o wormhole sempre que pretende usufruir da sua
Figura 2.3: Exemplo de propagac¸˜ao de eventos
propriedade, que neste caso ´e a propriedade de execuc¸˜ao s´ıncrona. Como indicado an-teriormente, para o payload poder manter o controlo do sistema e efectuar trabalho ´e necess´ario o mesmo sinalizar a intenc¸˜ao de o fazer ao wormhole, atrav´es da estrutura pro-messa. O payload dever´a manter sempre o controlo do sistema visto o algoritmo utilizado pelo mesmo ser mais complexo, logo deveremos esperar um melhor resultado do que com o algoritmo que est´a presente no wormhole.
O payload implementa um sistema de navegac¸˜ao com base num mapa de duas di-mens˜oes simples, um sistema de comunicac¸˜ao que permite comunicac¸˜ao entre outros robˆos e um sistema de eventos sobre o qual podem ser gerados m´odulos. Estes com-ponentes s˜ao detalhados nas pr´oximas subsecc¸˜oes.
A vers˜ao do payload presente neste middleware foi constru´ıda com base numa ´arvore de eventos para facilitar a criac¸˜ao e interacc¸˜ao entre m´odulos. Os m´odulos criados podem ser grupos ou folhas. Os grupos est˜ao dispon´ıveis para permitir a organizac¸˜ao da ´arvore e n˜ao efectuam qualquer computac¸˜ao enquanto nas folhas ´e feita toda a computac¸˜ao necess´aria. Qualquer evento gerado ´e emitido por um m´odulo na ´arvore, seguindo depois para todos os sub-m´odulos e cada sub-m´odulo emite esse evento para os seus sub-m´odulos at´e ser consumido. Os m´odulos s˜ao organizados em grupos e os grupos de m´odulos podem ter v´arios m´odulos pais. Os eventos que s˜ao gerados pelo hardware do robˆo (hard events) s˜ao enviados para a raiz da ´arvore enquanto os eventos dos m´odulos s˜ao enviados para todos os sub-m´odulos (local soft events) ou pela interface de rede (remote soft events) para o m´odulo na mesma posic¸˜ao da ´arvore nos outros robˆos. Esta ´ultima capacidade permite que eventos como detecc¸˜ao de intrusos sigam directamente para outros robˆos. Um exem-plo de propagac¸˜ao de um evento pode ser observado na figura 2.3.
Um exemplo de um m´odulo que foi implementado ´e o m´odulo Freshness detector que verifica periodicamente se os valores de posic¸˜ao e orientac¸˜ao que o payload tem s˜ao
re-centes e se n˜ao forem avisa o wormhole desse facto.
O algoritmo de sincronizac¸˜ao de vista criado permite manter uma vis˜ao partilhada do estado de cada robˆo. Para que isso seja poss´ıvel ´e necess´ario que os robˆos estejam ao alcance uns dos outros para que seja poss´ıvel interagirem entre si. Se isso n˜ao acontecer ´e poss´ıvel que existem v´arios grupos de robˆos separados a moverem-se pelo mesmo mapa. Se dois grupos se encontrarem os mesmos iniciam o processo de junc¸˜ao que une os dois grupos.
Para ser poss´ıvel a procura de caminhos, foi implementado um algoritmo baseado no
Wave front algorithm que ´e utilizado para calcular o melhor caminho de um ponto do
mapa at´e outro e funciona correctamente com o tipo de mapa utilizado. O algoritmo tenta calcular a distˆancia at´e ao objectivo avanc¸ando em todas as direcc¸˜oes at´e encontrar um caminho. A cada iterac¸˜ao o algoritmo avanc¸a uma c´elula em cada sentido poss´ıvel guar-dando o custo do caminho actual, o que resulta no caminho mais curto ser encontrado primeiro. Adicionalmente o algoritmo permite que dois robˆos com sentidos opostos se cruzem no caso do caminho que utilizam apenas permitir a passagem de um robˆo.
Como podemos observar a figura 2.4 apresenta os passos dados pelo algoritmo de navegac¸˜ao de forma a descobrir qual o melhor caminho do ponto inicial (assinalado com um S) at´e ao ponto final (assinalado com D). Os c´ırculos a amarelo representam os passos e a ordem como os mesmos s˜ao gerados, os c´ırculos a vermelho representam os robˆos e os c´ırculos a preto representam o ponto inicial e final. Como podemos verificar o algo-ritmo toma em considerac¸˜ao a orientac¸˜ao dos robˆos no mapa de forma a evitar entrar em caminho que apenas passa um robˆo (caso do R1 e R3). No caso do robˆo R2 com o mesmo est´a a avanc¸ar na mesma direcc¸˜ao que o movimento o algoritmo sabe que pode aceitar esse caminho como poss´ıvel via para chegar ao objectivo.
Contexto e enquadramento tecnol´ogico
Este cap´ıtulo enquadra o trabalho realizado e descreve as tecnologias utilizadas na sua realizac¸˜ao.
3.1
Linguagens
Nas pr´oximas secc¸˜oes s˜ao apresentadas todas as linguagens que de alguma forma foram analisadas ou utilizadas durante o projecto.
3.1.1
Basic
O Basic ´e uma linguagem de alto n´ıvel com o objectivo de ser f´acil de utilizar. Esta lin-guagem, inicialmente n˜ao estruturada, tem vindo a evoluir para suportar caracter´ısticas de linguagens mais recentes como o C ou o Java. Actualmente esta linguagem continua a ser bastante utilizada tanto para desenvolvimento de aplicac¸˜ao para correr nos sistemas operativos como na Internet.
A vers˜ao de Basic a ser utilizada ´e uma vers˜ao pr´opria para ser executada em mi-crocontroladores porque permite operac¸˜oes que n˜ao est˜ao dispon´ıveis na vers˜ao de Basic dispon´ıvel para computadores. Essas operac¸˜oes lidam com as portas do microcontrolador permitindo ao programador interagir directamente com outros componentes via as mes-mas. Adicionalmente existe algumas func¸˜oes para gest˜ao de energia que permite ao pro-gramador colocar o microcontrolador num estado de baixo consumo de energia quando o mesmo n˜ao ´e necess´ario. Esta linguagem foi analisada no ˆambito das linguagens dis-pon´ıveis para programac¸˜ao do microcontrolador.
Neste projecto esta linguagem ´e utilizada na programac¸˜ao do microcontrolador.
3.1.2
Assembler, C e C++
O Assembler ´e uma linguagem de baixo n´ıvel que permite a programac¸˜ao de um
hard-wareespec´ıfico. O c´odigo ´e baseado em mnem´onicas que simbolizam instruc¸˜oes, registo
do processado e localizac¸˜oes na mem´oria. Esta linguagem foi analisada no ˆambito das linguagens dispon´ıveis para programac¸˜ao do microcontrolador.
O C ´e uma linguagem estruturada de baixo n´ıvel com o objectivo de ser utilizada para programar em v´arias plataformas. Esta linguagem permite um acesso de baixo n´ıvel aos componentes do computador de forma a possibilitar a maximizar o controlo e possibili-dades que o programador tem sobre a m´aquina mas tamb´em facilitando a programac¸˜ao face a outras linguagens de baixo n´ıvel como o Assembler. Esta linguagem ´e utilizada no middleware e em todos os seus m´odulos porque C, ´e uma linguagem que permite progra-mar para v´arias plataformas e esta foi a linguagem escolhida inicialmente para prograprogra-mar o middleware.
O C++ ´e uma linguagem estruturada orientada a objectos que comec¸ou por ser uma extens˜ao do C. Esta linguagem permite a utilizac¸˜ao de uma grande parte das funcionali-dades do C em adic¸˜ao `a capacidade de criac¸˜ao de classes. Esta linguagem foi analisada no ˆambito das linguagens poss´ıveis para programar o microcontrolador.
3.1.3
Java
O Java ´e uma linguagem estruturada de alto n´ıvel com o objectivo de ser permitir o uso do c´odigo produzido em m´ultiplas plataformas sem a necessidade de o adaptar. O Java ´e uma linguagem orientada a objecto que permite uma programac¸˜ao mais f´acil. Esta lin-guagem ´e utilizada na camada de sensores original e em todo o c´odigo que interage com a aplicac¸˜ao Simbad.
3.1.4
VHDL
A linguagem VHDL ´e uma HDL(hardware description language) utilizada para desenhar sistemas digitais. Esta linguagem descreve como o hardware se deve comportar face a um determinado valor de entrada. Nos sites [14], [15], [16], [17] pode ser encontrada informac¸˜ao geral sobre regras de programac¸˜ao para esta linguagem assim como erros b´asicos que ocorrem durante a programac¸˜ao. Esta linguagem ´e muito diferente das lin-guagens convencionais e tem regras estruturais que n˜ao se aplicam a outras linguagem com C ou Java. Esta linguagem ´e utilizada para programar a FPGA.
3.2
Aplicac¸˜oes
Nas pr´oximas subsecc¸˜oes ´e apresentado todo o software utilizados durante o desenvol-vimento do projecto. Esse software pode ser aplicac¸˜oes que auxiliem ou permitam a programac¸˜ao para um determinado hardware ou pacotes de software que facilitam a utilizac¸˜ao do hardware.
3.2.1
Micro Basic Studio
O Basic Micro Studio ´e um IDE que permite desenvolver aplicac¸˜oes para o microcontro-lador. Esta aplicac¸˜ao permite a gest˜ao de um ou mais projectos, relacionados com v´arios microcontroladores da mesma fabricante. Esta aplicac¸˜ao permite a programac¸˜ao em Ba-sic, C++ ou Assembler embora o C++ tenha sido introduzido apenas recentemente logo ainda n˜ao existe muitos exemplos sobre o mesmo. Para a programac¸˜ao em Basic existe um manual detalhado que especifica todas as func¸˜oes dispon´ıveis. Aplicac¸˜ao permite a programac¸˜ao do microcontrolador atrav´es de cabo s´erie ou USB tanto para programar a aplicac¸˜ao completa ou para depurar.
A figura 3.1 demonstra o ambiente de trabalho do IDE Basic Micro Studio. Nesta imagem podemos identificar 4 ´areas importantes. A primeira ´area no topo cont´em os ata-lhos e menus que s˜ao comuns a qualquer aplicac¸˜ao (Novo, Abrir, Guardar, etc..) assim como alguns bot˜oes espec´ıficos deste IDE que s˜ao o Build, o Program e o Debug. A se-gunda ´area encontra-se `a esquerda e nesta ´e apresentada a ´area de trabalho com todos os projectos abertos no momento. O projecto actual est´a marcado com uma formatac¸˜ao de letra diferente (negrito). A terceira ´area que pode ser encontrada ´a direita da segunda ´area cont´em o c´odigo de cada um dos projectos. Como podemos verificar o c´odigo cont´em cores diferentes em que cada cor denota um tipo de texto diferente (vari´aveis, modifica-dores, n´umeros, etc..). A quarta ´area situa-se por baixo da terceira ´area e esta apresenta uma consola onde s˜ao reportadas as estat´ısticas do c´odigo. Adicionalmente as estat´ısticas esta ´area pode ser utilizada para comunicar directamente com o microcontrolador via con-sola.
3.2.2
Eclipse
O Eclipse ´e um IDE que permite desenvolver aplicac¸˜oes para m´ultiplas linguagens permi-tindo a gest˜ao de v´arios projectos. Este IDE permite um r´apido desenvolvimento devido as funcionalidade que o mesmo implementa. Das funcionalidades dispon´ıveis destaca-se as seguintes:
Figura 3.1: Ambiente de trabalho da aplicac¸˜ao Basic Micro Studio
• Completar autom´atico de palavras, que permite que o utilizador apenas escreva parte da palavra para que seja sugerido poss´ıveis palavras.
• Compilac¸˜ao imediata, que permite ao utilizador observar poss´ıveis erros conforme o mesmo programa na mesma janela do c´odigo.
• Cores para o c´odigo de acordo com o contexto, que permite ao programador iden-tificar rapidamente elementos diferentes no c´odigo.
Esta aplicac¸˜ao ´e utilizada para programac¸˜ao em JAVA e C atrav´es da funcionalidade JNI dispon´ıvel no JAVA. Esta aplicac¸˜ao ´e utilizada no ˆambito do projecto para programar m´odulos para o componente wormhole e payload.
3.2.3
Helix
Helix ´e uma distribuic¸˜ao de Linux e uma toolchain optimizada para sistema com pouco recursos. Esta distribuic¸˜ao de Linux corre na placa com o ARM de forma a trazer a placa para um estado operacional. Uma toolchain ´e um conjunto de ferramentas que podem ser utilizadas em sequˆencia para efectuar uma tarefa complexa como compilar uma aplicac¸˜ao para ser corrida numa arquitectura de processador diferente daquela em que a aplicac¸˜ao est´a a ser compilada. A toolchain dispon´ıvel permite compilar programas e o kernel para a distribuic¸˜ao Linux com o mesmo nome. Adicionalmente a toolchain tem alguns pacotes
Figura 3.2: Arquitectura da distribuic¸˜ao Helix
de software pr´e-compilados que podem ser utilizados na construc¸˜ao da imagem do sis-tema de ficheiros.
Como podemos observar na figura 3.2 o sistema Linux para este dispositivo ´e cons-titu´ıdo por um kernel Linux por uma biblioteca de C e v´arias outras bibliotecas e aplicac¸˜oes complementares. No topo destes componentes fica a aplicac¸˜ao que pretendemos executar enquanto por baixo destes componentes fica o hardware.
O pacote Helix ´e constitu´ıdo pelos componentes indicados anteriormente e adicional-mente tem utilit´arios que permitem a construc¸˜ao de imagens do sistema operativo.
O manual em [18] apresentada comandos, configurac¸˜oes e formas de compilar os kernel e sistema de ficheiros.
3.2.4
Xilinx ISE Design Suite
O Xilinx ISE Design Suite ´e um IDE que permite desenvolver aplicac¸˜oes para a FPGA. Esta aplicac¸˜ao permite a gest˜ao de um ou mais projecto, relacionados com v´arias FPGAs da mesma fabricante (Xilinx). Este IDE permite a criac¸˜ao de projectos atrav´es de c´odigo HDL, de esquemas el´ectricos ou importando um ficheiro no formato EDIF (formato de esquema open source). Esta aplicac¸˜ao permite programar em duas linguagens: Verilog e VHDL. O processo que transforma o c´odigo criado numa configurac¸˜ao v´alida para a FPGA tem os seguintes passos:
• Criac¸˜ao do c´odigo/esquema, neste passo ´e criado o c´odigo numa das linguagens indicadas anteriormente, ou um esquema a representar o que a configurac¸˜ao deve
fazer. Este passo est´a a cargo do utilizador.
• Behavioral Simulation, neste passo ´e simulado o c´odigo/esquema criado no passo anterior. O utilizador pode gerar configurar valores de entrada e observar os valores de sa´ıda atrav´es do interface gr´afico dispon´ıvel. Este passo ´e facultativo.
• Design Synthesis, neste passo a sintaxe do c´odigo e a hierarquia do projecto s˜ao verificados, o c´odigo ´e analisado sendo feito um levantamento de todos os com-ponentes (mem´oria, portas l´ogicas, buffers) necess´arios pelo design e optimiza o design removendo l´ogica redundante.
• Design Implementation, neste passo o c´odigo ´e traduzido e mapeado para o disposi-tivo em que vai ser instalado. Adicionalmente depois de mapeados os componentes, estes s˜ao ligados de acordo com o desenho.
• Generate Programming File, neste passo um ficheiro de configurac¸˜ao ´e gerado. Este ficheiro pode ser instalado directamente na FPGA. Se for necess´ario configurar uma EEPROM ´e necess´ario converter este ficheiro para um formato espec´ıfico para a EEPROM.
A imagem 3.3 demonstra o ambiente de trabalho do IDE ISE Project Navigator. Nesta imagem podemos identificar 5 ´areas importantes. A primeira ´area no topo cont´em os atalhos e menus que s˜ao comuns a qualquer aplicac¸˜ao (Novo, Abrir, Guardar, etc..). A segunda ´area encontra-se directamente por baixo da primeira ´a esquerda e nesta ´e apre-sentada a ´area de trabalho como o projecto actual e todos os seus componentes. A terceira ´area encontra-se ´a direita da segunda ´area e cont´em o c´odigo do ficheiro actualmente aberto. Como ´e poss´ıvel observar o c´odigo tem cores que auxiliam na identificac¸˜ao de certo tipo de texto (vari´aveis, palavras reservadas, arrays). A quarta ´area localiza-se por baixo da segunda ´area e `a esquerda da terceira e cont´em v´arios atalhos para ferramen-tas. O resultado de executar essas ferramentas ´e apresentado por um visto branco, um triˆangulo com um ponto de exclamac¸˜ao ou uma cruz respectivamente para os casos em que correu tudo bem, existiram pequenos erros ou avisos e a operac¸˜ao n˜ao foi conclu´ıda. A quinta ´area encontra-se por baixo da terceira e quarta ´area e pode apresentar erros, avi-sos ou uma consola com o resultado detalhado do uso das ferramentas.
3.2.5
Simbad Robot Simulator
O Simbad Robot Simulator ´e um simulador que permite a criac¸˜ao de um ambiente onde robˆos virtuais, tamb´em criados com este simulador, podem interagir. Os robˆos virtu-ais criados permitem a instalac¸˜ao de v´arios tipos de sensores, que permitem ao robˆo ter
Figura 3.3: Ambiente de trabalho da aplicac¸˜ao ISE Project Navigator
percepc¸˜ao do que est´a `a sua volta. Este simulador permite visualizar graficamente o am-biente criado, os robˆos que o utilizam e os valores dos sensores de cada robˆo.
3.2.6
U-Boot
O U-boot ´e um bootloader que permite ao utilizador carregar imagens para dispositivos como computadores. Um bootloader permite carregar um sistema operativo para um dis-positivo que inicialmente n˜ao tem mais nada instalado. No ˆambito deste projecto esse sistema operativo ´e o Linux, constitu´ıdo por um kernel e um sistema de ficheiros. O bootloader tem como caracter´ıstica ser pequeno e simples e permitir o carregamento de imagens por v´arios meios. No caso do U-boot os meios dispon´ıveis s˜ao atrav´es de TFTP. O manual em [19] apresenta as configurac¸˜oes poss´ıveis para este tipo de bootloader. O U-boot vem instalado por predefinic¸˜ao na placa com o ARM.
3.2.7
Busybox
A BusyBox fornece vers˜oes simplificadas de alguns comandos b´asicos de Linux a partir de um execut´avel apenas. As vers˜oes dos comandos presentes na busybox tem menos fun-cionalidades mas s˜ao mais pequenas e utilizam menos mem´oria que as vers˜oes originais. Este pacote de utilit´arios foi constru´ıdo a pensar em dispositivos com poucos recursos
Figura 3.4: A4WD1 v1
(mem´oria, poder de processamento). A Busybox ´e instalada na imagem do sistema de ficheiros para fornece as ferramentas necess´arias para interagir com a interface de rede e servidor TFTP.
3.3
Hardware
A totalidade do hardware existente antes do projecto iniciar ´e apresentado nas pr´oximas subsecc¸˜oes. De todo o hardware existente actualmente, uma grande parte estava dis-pon´ıvel antes do projecto iniciar. Este facto significa que esse hardware ´e uma restric¸˜ao ao projecto pois n˜ao foi poss´ıvel escolher ou alterar.
Chassis do Robˆo
Para construir o robot, o chassis A4WD1 v1 (figura 3.4) est´a dispon´ıvel. O chassis tem bastante espac¸o e consegue-se facilmente colocar duas pequenas placas, m´ultiplos senso-res e baterias. Este chassis vem equipado com quatro rodas e senso-respectivos motosenso-res e est´a organizado em duas plataformas, a inferior ´e onde a placa controladora dos motores e as baterias para a alimentar s˜ao instaladas e a superior onde podem ser instaladas, placas e sensores. Este chassis consegue suportar 2.2 Quilogramas de equipamento sendo este valor apenas limitado pelos motores utilizados. Adicionalmente ´e poss´ıvel instalar decks adicionais para acomodar mais material.
Figura 3.5: Motor GHM-01
Figura 3.6: Placa controladora Sabertooth 2x12
Motores e placa controladora
Os motores utilizados s˜ao quatro GHM-01 (figura 3.5). Estes motores necessitam de 12 Volt, conseguem efectuar 200 rotac¸˜oes por minuto e suportam um peso de 620 gramas que ´e suficiente para conseguir levar a totalidade das baterias, placas e sensores.
A placa controladora dos motores ´e uma Sabertooth 2x12 (figura 3.6) que permite o controlo dos motores atrav´es de v´arios m´etodos. Os m´etodos de controlo dispon´ıveis s˜ao os seguintes:
• Controlo anal´ogico, em que a placa aguarda por uma tens˜ao de 0 a 5 Volts e de acordo com o que receber multiplica esse valor e aplica-o aos motores (os motores usam de 0 a 12 Volts);
• Controlo R/C ou digital, em que a placa aguarda por um valor digital que pode ser enviado por um receptor R/C ou por um microcontrolador;
• Controlo atrav´es do padr˜ao TTL, em que a placa aguarda por informac¸˜ao enviada pela interface s´erie para depois transmitir esses comandos ao motor.
O objectivo principal desta placa ´e fazer uma ponte entre os motores e um micro-controlador. Esta ponte ´e necess´aria porque o microcontrolador n˜ao consegue debitar
Figura 3.7: Sensor ultra-s´onico SRF05
intensidade de corrente necess´aria para fazer com que os motores respondam.
Sensores de distˆancia
De forma a obter os obst´aculos na proximidade do robˆo sensores de distˆancia s˜ao ne-cess´arios. Os sensores dispon´ıveis s˜ao os SRF05 ultra-sonic sensors (figura 3.7) que medem a distˆancia utilizando impulsos e aguardando pelo eco. Estes sensores s˜ao di-gitais e podem ser ligados directamente a um microcontrolador. Os sensores requerem cinco volts permanentes, necessitam de um impulso de dez microssegundos para inicia-rem uma leitura e demoram no m´aximo 30 milissegundos a retornar uma leitura. Estes sensores foram soldados de acordo com o modo de configurac¸˜ao dois que define que a porta que ´e utilizada para enviar o impulso para iniciar a leitura ´e tamb´em utilizada para obter a leitura da distˆancia. Os valores de leitura da distˆancia ap´os recebidos necessitam ser transformados em cent´ımetros dividindo o valor obtido pelo n´umero 116.136. Este valor deriva do valor fornecido pelo manual e significa que cada 116 unidades retornadas pelo microcontrolador (58 nanossegundos) s˜ao iguais a um cent´ımetro.
Existem alguns cuidados a ter com o posicionamento destes sensores. Estes sensores enviam um impulso na direcc¸˜ao em que os mesmos est˜ao apontados mas a onda n˜ao se dispersa apenas nessa direcc¸˜ao. Como podemos observar na FIGURA 3.8, a onda dis-persa essencialmente dentro de um ˆangulo de 60 graus em volta do sensor.
Placas
De forma a permitir a separac¸˜ao requerida dos componentes do middleware, duas placas est˜ao dispon´ıveis: a Bot Board II com um microcontrolador Atom Pro 28-M; a H4090 com a H6042, ambas da Hectronic.
A Bot Board II(figura 3.9) actua como uma placa m˜ae onde podem ser ligados sensores e motores, contendo uma ranhura para ser instalado um microcontrolador que neste caso ´e o Atom Pro 28-M. Adicionalmente esta placa cont´em uma porta s´erie que ser´a utilizada
Figura 3.8: Caracter´ısticas da dispers˜ao da onda criada pelo sensor SFR05
Figura 3.9: Bot Board II
para comunicac¸˜oes. Esta placa ir´a conter parte do wormhole e a camada de sensores.
A placa Bot Board II cont´em 16 pinos directamente ligados ao microcontrolador que podem ser utilizado para ligar sensores ou motores. A placa cont´em tamb´em 4 bot˜oes e 4 leds, 3 dos quais podem ser programados para executar func¸˜oes como ordens directas ao robˆo ou indicar o estado do robˆo (no caso dos leds).
Em termos de energia, a placa Bot Board II necessita de pelo menos uma bateria de 6 volts mas pode levar duas para um maior tempo de utilizac¸˜ao. Esta placa fornece m´ultiplos pinos a 5 V DC que podem ser utilizado para alimentar sensores e pequenos motores.
Figura 3.10: Atom Pro 28-M
Figura 3.11: H4090
O processador Atom Pro 28-M(figura 3.10) permite a utilizac¸˜ao de 32 Kilobytes para c´odigo e constantes, 2 Kilobytes para vari´aveis, 3 temporizador por hardware, interrupc¸˜oes pelo hardware, 8 portas capazes de convers˜ao de anal´ogico para digital (10 bits), n´umeros de v´ırgula flutuante de 32bits e n´umeros inteiros at´e 32bits.
A placa H4090(figura 3.11) actua como uma motherboard e cont´em alguns controla-dores na placa como USB, Ethernet, s´erie e leitor de cart˜oes SD e a H6042 actua como uma placa de expans˜ao obrigat´oria que cont´em o processador e uma FPGA. O processador tratar´a do sistema operativo e dos componentes payload e wormhole bridge, enquanto a FPGA ir´a tratar do m´odulo TTFD Task do wormhole. O sistema operativo a ser instalado ´e Linux logo os programas instalados nesta placa podem ser interrompidos assincronamente por outros programas a correr no sistema. A placa H4090, em adic¸˜ao aos controladores indicados anteriormente, cont´em m´ultiplos pinos que permite a comunicac¸˜ao directa para o CPU ou FPGA. Isso permite que um outro hardware comunique directamente com o processador ou FPGA sem latˆencias adicionais.
Figura 3.12: H6042
Figura 3.13: Placa D-Link G730ap
Xilink Spartan 3E 500. Adicionalmente cont´em 32 Megabytes de RAM que pode ser uti-lizado para guardar informac¸˜ao das aplicac¸˜oes instaladas e 16 Megabytes de flash que podem ser utilizados para guardar o kernel e sistema de ficheiro quando o desenvolvi-mento do robˆo terminar.
Componentes adicionais
Adicionalmente as placas referidas anteriormente est´a dispon´ıvel outra placa, a D-Link G730ap(figura 3.13). Esta placa ´e necess´aria porque a placa H4090 n˜ao tem um contro-lador sem fios.
Para alimentar todos estes componentes s˜ao necess´arias pelo menos cinco baterias de 6 Volts(figura 3.14) cada (vinte cinco pilhas de 1.2 Volts ligadas em s´erie em grupos de cinco). A distribuic¸˜ao das baterias ´e feita da seguinte forma: Uma bateria para alimentar o microcontrolador, duas baterias para alimentar a placa H4090 e mais duas para alimentar a placa controladora dos motores e motores.
Alguns componentes, neste caso o aceler´ometro e girosc´opio, necessitam de 3.3V DC em vez de 5V DC. Para ser poss´ıvel converter os 5.0V DC em 3,3V DC, um regulador foi adquirido. Um regulador de tens˜ao permite a tens˜ao pretendida e permite alimentar v´arios sensores.
Figura 3.14: baterias de 6 Volts
Figura 3.15: Esquema do circuito el´ectrico
Para mitigar a desorganizac¸˜ao resultante de ligar v´arios sensores a uma placa foram adicionados ligadores de forma a centrar todas as ligac¸˜oes de um certo tipo (terra, 5Volts, 3,3Volts). Uma imagem representativa do circuito est´a dispon´ıvel na figura 3.15.
Na imagem podemos verificar que a partir da fonte de 5V fornecida pela placa Bot Board II ´e gerado 3,3V atrav´es do regulador de tens˜ao. Ligados a cada ligador est˜ao os elementos que necessitam daquele tipo de alimentac¸˜ao (5V DC,3.3V DC ou terra).
Planeamento
Como indicado anteriormente os objectivos deste trabalho s˜ao:
• Melhorar os algoritmos do middleware mencionado anteriormente;
• Criar uma camada de sensores e motores que permita a interacc¸˜ao com o wormhole; • Adaptar o middleware para um robˆo m´ovel;
• Validar a propriedade de execuc¸˜ao s´ıncrona do wormhole.
Destes objectivos e do contexto em que o robˆo ser´a utilizado ´e poss´ıvel obter um con-junto de requisitos necess´arios para que estes objectivos sejam alcanc¸ados. Esses requi-sitos s˜ao divididos em dois grupos: funcionais e n˜ao funcionais. Os requirequi-sitos funcionais s˜ao requisitos que definem a func¸˜ao principal do projecto que neste caso ´e criar um robˆo que consegue fazer tarefas de vigilˆancia sobre espac¸os conhecidos. Os requisitos n˜ao fun-cionais s˜ao requisitos que definem a arquitectura do sistema mas n˜ao o funcionamento do mesmo. Estes requisitos normalmente est˜ao englobados nas ´areas de performance e seguranc¸a.
4.1
Requisitos Funcionais
Os requisitos funcionais deste projecto s˜ao os seguintes: • Gerir pr´opria posic¸˜ao e posic¸˜ao de obst´aculos; • Navegar por um mapa conhecido;
• Comunicar com outros robˆos; • Reconhecer poss´ıveis intrusos;
O robˆo tem que inicialmente conseguir gerir a sua posic¸˜ao atrav´es de sensores locais e gerindo a sua posic¸˜ao deve conseguir saber qual a posic¸˜ao dos obst´aculos espalhados pelo mapa. Isto ´e necess´ario para que seja poss´ıvel a realizac¸˜ao de tarefas mais complexas como navegac¸˜ao. Para satisfazer estes requisitos s˜ao necess´arios sensores que indiquem ou que permitam o c´alculo da posic¸˜ao e orientac¸˜ao do robˆo, como aceler´ometros ou gi-rosc´opios, e sensores que mec¸am a distˆancia do robˆo a um objecto situado na sua proximi-dade. Com o primeiro requisito indicado pretende-se que o robˆo seja capaz de, ap´os pelo menos um movimento, saber quanto ´e que o mesmo avanc¸ou e qual a orientac¸˜ao actual.
Navegar por um mapa conhecido ´e poss´ıvel atrav´es da utilizac¸˜ao de um sistema de po-sicionamento. A navegac¸˜ao num mapa pressup˜oe que o robˆo sabe interpretar esse mapa e que consegue eficientemente encontrar rotas para os pontos que lhe s˜ao indicados. Para satisfazer esse requisito ´e necess´aria uma unidade de processamento, que fica respons´avel pelo processamento do mapa e c´alculo de rotas, em adic¸˜ao aos sensores indicados no re-quisito anterior.
A comunicac¸˜ao com outros robˆos permite entre outras possibilidades, saber as suas posic¸˜oes, velocidades e direcc¸˜oes e criar estrat´egias que permitam `a equipa ser mais efi-ciente. Para que isso seja poss´ıvel ´e necess´aria uma forma de comunicac¸˜ao, com ou sem fios.
A possibilidade de reconhecer intrusos ´e uma tarefa necess´aria no contexto de vi-gilˆancia de uma ´area. Para que isso seja poss´ıveis s˜ao necess´arios que existam sensores de forma a conseguir identificar o intruso. Uma vez encontrado um intruso o robˆo pode comunicar a sua posic¸˜ao a outros robˆos. Os sensores de distˆancia com ajuda do mapa podem detectar poss´ıveis intrusos. O intruso no contexto do middleware ´e um objecto que ´e detectado por um robˆo mas n˜ao est´a no mapa.
4.2
Requisitos n˜ao Funcionais
Os requisitos n˜ao funcionais deste projecto s˜ao os seguintes:
• Garantir controlo do robˆo dentro de um per´ıodo de tempo conhecido; • Cada componente principal deve esta num hardware independente; • Minimizar o tamanho ocupado em mem´oria pelo wormhole
O wormhole deve ser capaz de garantir o controlo do robˆo dentro de um per´ıodo de tempo conhecido, ou seja, entre a falta do componente payload e o controlo por parte
do wormhole deve um n´umero m´aximo de segundos ao fim dos quais sabemos que o
wormholecontrola o robˆo.
Os dois componentes principais, wormhole e payload, devem estar instalados em
hardwaresdiferentes para que a execuc¸˜ao de um n˜ao interfira na execuc¸˜ao do outro. Se
poss´ıvel o wormhole dever´a estar instalado num hardware dedicado no qual n˜ao existam interrupc¸˜oes ass´ıncronas que possam causar atrasos inesperados.
O wormhole ´e o componente mais confi´avel deste sistema, logo deve estar presente no
hardwaremais fi´avel que existe dispon´ıvel. Apesar da fiabilidade do hardware, existem
outras limitac¸˜oes que fazem com que este hardware n˜ao possa ser utilizado para qualquer tarefa. Uma dessas limitac¸˜oes ´e a mem´oria e o poder computacional dispon´ıvel. Para permitir que o wormhole possa ser instalado no microcontrolador ´e necess´ario simplificar o c´odigo existente de forma a coincidir com os recursos dispon´ıveis.
4.3
Casos de Uso
Com os casos de uso tencionamos apresentar o que esperamos que o sistema oferec¸a em termos comportamentais. Na figura 4.1 podemos observar o diagrama de casos de uso para este projecto. No diagrama s˜ao presentadas todas as tarefas principais de cada um dos componentes.
Nas subsecc¸˜oes seguintes s˜ao apresentados alguns casos de uso de componente foram criados ou alterados no ˆambito deste projecto.
4.3.1
Controlo do robˆo pelo componente wormhole
Nome do caso de uso:
• Controlo do robˆo pelo componente wormhole. Actores:
• Componente wormhole. Condic¸˜ao para iniciac¸˜ao:
• Execuc¸˜ao peri´odica. Pr´e-condic¸˜oes:
Figura 4.1: Ambiente de trabalho da aplicac¸˜ao ISE Project Navigator
• O componente payload est´a num estado operacional, recebeu pelo menos uma vez as coordenadas do robˆo, o estado do componente payload ´e desactivado e existe um destino definido no componente wormhole.
P´os-condic¸˜oes:
• O componente camada de sensores recebeu as novas ordens enviadas pelo compo-nente wormhole.
Caso esperado:
1. O componente wormhole calcula a posic¸˜ao no mapa com base nas coordenadas dispon´ıveis.
2. O componente wormhole marca a posic¸˜ao calculada num mapa e considera-a ex-plorada.
3. O componente wormhole procura a melhor direcc¸˜ao para alcanc¸ar o destino. 4. O componente wormhole calcula orientac¸˜ao e escolhe velocidade para movimento. 5. O componente wormhole envia a nova ordem criada para o componente camada de
6. O componente camada de sensores recebe a nova ordem e processa-a. 7. O caso de uso termina.
Casos complementares:
3A: O componente wormhole n˜ao consegue encontrar a melhor direcc¸˜ao porque est´a num caminho sem sa´ıda e j´a explorou as posic¸˜oes que o levaram a este caminho.
1. O componente wormhole procura a ´ultima localizac¸˜ao em que o robˆo esteve. 2. O componente wormhole calcula a orientac¸˜ao e escolhe a velocidade para
movi-mento.
3. O componente wormhole envia a nova ordem criada para o componente camada de sensores.
4. O componente camada de sensores recebe a nova ordem e processa-a. 5. O caso de uso termina.
4.3.2
Controlo do tempo do componente payload
Nome do caso de uso:
• Controlo do tempo do componente payload. Actores:
• Componente wormhole. Condic¸˜ao para iniciac¸˜ao:
• Execuc¸˜ao peri´odica. Pr´e-condic¸˜oes:
• O componente wormhole est´a num estado operacional. P´os-condic¸˜oes:
• O componente verifica que o payload est´a a cumprir as promessas enviadas pelo pr´oprio.
Caso esperado:
1. O componente wormhole verifica se o componente payload ainda est´a a tempo de cumprir o prazo de entrega da promessa.
3. O caso de uso termina. Casos complementares:
1A: O componente wormhole verifica que o componente payload j´a devia ter entregado a nova promessa. Est´a ´e a primeira vez que isto ocorre desde o in´ıcio do sistema.
1. O componente wormhole muda o estado do payload para desactivado. 2. O componente wormhole guarda que o payload falhou uma vez a entrega.
3. O componente wormhole envia uma mensagem para o componente payload a indi-car que perdeu o controlo.
4. O caso de uso termina.
1B: O componente wormhole verifica que o componente payload j´a devia ter entregado a nova promessa. Esta ´e a quarta vez que isto ocorre desde o in´ıcio do sistema.
1. O componente wormhole muda o estado do payload para desactivo.
2. O componente wormhole guarda que o payload falhou quatro vezes a entrega. 3. O componente wormhole verificando que ´e a quarta vez que a falha na entrega
ocorre, reinicia o componente payload.
4. O componente wormhole guarda que o payload ainda n˜ao falhou nenhuma vez a entrega.
5. O caso de uso termina.
4.3.3
Gerir posic¸˜ao atrav´es dos sensores locais
Nome do caso de uso:
• Gerir posic¸˜ao atrav´es dos sensores locais. Actores:
• Componente camada de sensores. Condic¸˜ao para iniciac¸˜ao:
• Execuc¸˜ao peri´odica. Pr´e-condic¸˜oes:
