U NIVERSIDADE DE L ISBOA
Faculdade de Ciências
Departamento de Informática
ARQUITECTURA WORMHOLE APLICADA A
ROBÔS MÓVEIS
Gonçalo Manuel Cardoso Cruchinho
MESTRADO EM ENGENHARIA INFORMÁTICA
Especialização em Arquitectura, Sistemas e Redes de Computadores
2011
U NIVERSIDADE DE L ISBOA
Faculdade de Ciências
Departamento de Informática
ARQUITECTURA WORMHOLE APLICADA A
ROBÔS MÓVEIS
Gonçalo Manuel Cardoso Cruchinho
PROJECTO
Projecto orientado pelo Prof. Doutor Mário João Barata Calha
MESTRADO EM ENGENHARIA INFORMÁTICA
Especialização em Arquitectura, Sistemas e Redes de Computadores
2011
Agradecimentos
Começo por agradecer à minha famı́lia, ao meu pai, à minha mãe, ao meu irmão,
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 tão longe. Finalmente agradeço ao meu orientador e professor Mário Calha por
todo o suporte na realização do projecto.
iii
à ideia de um mundo melhor...
Resumo
A utilização de robôs é cada vez mais generalizada, incidindo mais sobre as áreas de
exploração, segurança e entretenimento. Com a introdução de equipas, os robôs conseguem apresentar um aumento na produtividade das suas tarefas, conseguindo fazer mais
em menos tempo, embora com essa adição, alguns problemas possam surgir. Esses problemas advêm da introdução da componente comunicacional necessária à equipa, que
pode causar atrasos nas tarefas que o robô efectua, devido à necessidade que o robô passa
a ter de valores externos fornecidos por outros robôs e existir uma demora incontrolável
na obtenção desses valores.
Para mitigar o problema indicado acima, foi criado anteriormente um middleware que
garante o controlo atempado de robôs virtuais. Esse middleware foi criado utilizando a arquitectura wormhole, que define dois componentes, um simples e outro complexo, ambos
capazes de controlar o robô. O componente simples garante a propriedade de execução
sı́ncrona que pode ser utilizada pelo componente complexo. O componente complexo
tenta sempre que possı́vel controlar o robô enquanto o componente simples apenas o
tenta controlar quando o complexo não o consegue.
Este projecto incide sobre o middleware identificado anteriormente, tendo como objectivo melhorar os módulos que o compõem, preparando-o para o porte para um robô
fı́sico e validar a solução resultante de forma a verificar se a mesma garante o controlo
do robô dentro de um tempo conhecido após falha de um dos componentes. Com esse
porte espera-se verificar que esta arquitectura serve correctamente o propósito de controlo
de equipas de robôs. Os resultados permitem-nos concluir que a arquitectura wormhole
quando aplicada a um robô mitiga os efeitos da introdução de comunicação nos robôs
visto que caso existam atrasos no controlo é possı́vel ao componente simples manter o
controlo temporário do robô. Esta mitigação de atrasos aplica-se também a atrasos causados por interrupções assı́ncronas que afectam o componente mais complexo.
Palavras-chave: middleware, arquitectura wormhole, comunicação, equipas de robôs,
execução sı́ncrona
vii
Abstract
The use of robots is becoming more widespread, focusing more on the areas of exploration, 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 capable 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
ix
Conteúdo
Lista de Figuras
xvi
Lista de Tabelas
xix
1
2
3
Introdução
1.1 Motivação . . . . . . .
1.2 Objectivos . . . . . . .
1.3 Contribuições . . . . .
1.4 Âmbito . . . . . . . .
1.5 Plano de Trabalho . . .
1.6 Estrutura do documento
Trabalho Relacionado
2.1 Middleware . . . . . .
2.1.1 Motivação . . .
2.1.2 Desenho . . . .
2.1.3 Implementação
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Contexto e enquadramento tecnológico
3.1 Linguagens . . . . . . . . . . . . .
3.1.1 Basic . . . . . . . . . . . .
3.1.2 Assembler, C e C++ . . . .
3.1.3 Java . . . . . . . . . . . . .
3.1.4 VHDL . . . . . . . . . . .
3.2 Aplicações . . . . . . . . . . . . . .
3.2.1 Micro Basic Studio . . . . .
3.2.2 Eclipse . . . . . . . . . . .
3.2.3 Helix . . . . . . . . . . . .
3.2.4 Xilinx ISE Design Suite . .
3.2.5 Simbad Robot Simulator . .
3.2.6 U-Boot . . . . . . . . . . .
3.2.7 Busybox . . . . . . . . . .
xi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
3
3
3
4
.
.
.
.
7
8
8
9
11
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
17
18
18
18
19
19
19
20
21
22
23
23
3.3
4
5
6
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planeamento
4.1 Requisitos Funcionais . . . . . . . . . . . . . . . . .
4.2 Requisitos não Funcionais . . . . . . . . . . . . . .
4.3 Casos de Uso . . . . . . . . . . . . . . . . . . . . .
4.3.1 Controlo do robô pelo componente wormhole
4.3.2 Controlo do tempo do componente payload .
4.3.3 Gerir posição através dos sensores locais . .
4.3.4 Movimento pelo mundo fı́sico . . . . . . . .
4.3.5 Detectar Intruso . . . . . . . . . . . . . . . .
4.4 Metodologia de desenvolvimento . . . . . . . . . . .
Arquitectura do Sistema
5.1 Payload . . . . . . .
5.1.1 Mensagens .
5.2 Wormhole Bridge . .
5.2.1 Módulos . .
5.2.2 Mensagens .
5.3 Wormhole . . . . . .
5.3.1 Módulos . .
5.3.2 Mensagens .
5.3.3 Sensor Layer
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Implementação
6.1 1ª Iteração . . . . . . . . . . . . . . . . . . . . . . .
6.1.1 Hardware . . . . . . . . . . . . . . . . . . .
6.1.2 Preparação do hardware . . . . . . . . . . .
6.1.3 Implementação da camada de sensores . . . .
6.1.4 Interface com a camada de sensores . . . . .
6.1.5 Safety Task . . . . . . . . . . . . . . . . . .
6.1.6 Mapeamento dos Componente no Hardware .
6.2 2ª Iteração . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Wormhole . . . . . . . . . . . . . . . . . . .
6.2.2 Mapeamento dos Componentes no Hardware
6.3 3ª Iteração . . . . . . . . . . . . . . . . . . . . . . .
6.3.1 TTFD Task . . . . . . . . . . . . . . . . . .
6.3.2 Mapeamento dos Componentes no Hardware
6.4 Algoritmos de navegação e ajuste . . . . . . . . . . .
xii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
.
.
.
.
.
.
.
.
.
33
33
34
35
35
37
38
39
40
41
.
.
.
.
.
.
.
.
.
45
45
47
47
48
49
49
50
53
55
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
62
62
64
67
68
71
72
73
73
75
76
77
79
80
7
Testes e Resultados
7.1 Módulos . . . . . . . . . . .
7.1.1 Payload Listener . .
7.1.2 Position Updater . .
7.1.3 Obstacle Updater . .
7.1.4 Position Sender . . .
7.1.5 TTFD Task Listener
7.1.6 Safety Task . . . . .
7.1.7 Velocity Observer . .
7.1.8 Orientation Observer
7.1.9 Resultados Finais . .
7.2 Mensagens . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
83
84
85
87
88
90
91
92
93
94
95
96
8
Conclusões e Trabalho Futuro
101
A
103
A.1 Modelo de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
B
115
115
115
116
117
118
B.1 Manual for the use of H6090 board .
B.1.1 Uboot Setup . . . . . . . .
B.1.2 Image Setup . . . . . . . .
B.1.3 Setting up the TFTP Server .
B.1.4 Running the middleware . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
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
xiii
Lista de Figuras
2.1
2.2
2.3
2.4
Modelo completo da arquitectura do middleware
Estrutura interna do payload . . . . . . . . . . .
Exemplo de propagação de eventos . . . . . . . .
Exemplo de execução do algoritmo de navegação
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
10
14
16
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
Ambiente de trabalho da aplicação Basic Micro Studio . . . .
Arquitectura da distribuição Helix . . . . . . . . . . . . . . .
Ambiente de trabalho da aplicação ISE Project Navigator . . .
A4WD1 v1 . . . . . . . . . . . . . . . . . . . . . . . . . . .
Motor GHM-01 . . . . . . . . . . . . . . . . . . . . . . . . .
Placa controladora Sabertooth 2x12 . . . . . . . . . . . . . .
Sensor ultra-sónico SRF05 . . . . . . . . . . . . . . . . . . .
Caracterı́sticas da dispersão da onda criada pelo sensor SFR05
Bot Board II . . . . . . . . . . . . . . . . . . . . . . . . . . .
Atom Pro 28-M . . . . . . . . . . . . . . . . . . . . . . . . .
H4090 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H6042 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Placa D-Link G730ap . . . . . . . . . . . . . . . . . . . . . .
baterias de 6 Volts . . . . . . . . . . . . . . . . . . . . . . . .
Esquema do circuito eléctrico . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
21
23
24
25
25
26
27
27
28
28
29
29
30
30
4.1
4.2
Ambiente de trabalho da aplicação ISE Project Navigator . . . . . . . . .
Metodologia de desenvolvimento iterativo e incremental . . . . . . . . .
36
42
5.1
5.2
5.3
5.4
5.5
Arquitectura final do sistema. . . . . . . . . . . . . . . . . . . . . . . . .
Arquitectura do componente wormhole bridge. . . . . . . . . . . . . . .
Ciclo de controlo do componente wormhole. . . . . . . . . . . . . . . . .
Fluxograma do processo de decisão do novo passo do módulo “safety task”.
Cenário tı́pico de comunicação aquando o envio da mensagem do tipo
promessa pelo componente payload. . . . . . . . . . . . . . . . . . . . .
Arquitectura do componente “sensor layer”. . . . . . . . . . . . . . . . .
Arquitectura do módulo “wormhole listener”. . . . . . . . . . . . . . . .
Arquitectura do módulo sensor layer listener. . . . . . . . . . . . . . . .
46
48
50
52
5.6
5.7
5.8
xv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
54
56
58
59
5.9
Sequência de eventos aquando o envio da mensagem promessa. . . . . . .
60
6.1
6.2
ADXL335 e LISY300AL . . . . . . . . . . . . . . . . . . . . . . . . . .
Mapeamento dos componentes do middleware no hardware após a primeira iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mapeamento dos componentes do middleware no hardware após a segunda iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mapeamento dos componentes do middleware no hardware após a terceira iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
6.3
6.4
7.1
72
76
80
7.2
Linha temporal entre a falha do payload e o controlo do robô por parte do
wormhole. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
O robô utilizado para testes . . . . . . . . . . . . . . . . . . . . . . . . .
C.1
C.2
C.3
C.4
C.5
C.6
C.7
D-Link G730 Web configuration interface . . .
Wireless network configuration page . . . . . .
The network connection in the windows XP OS
Wireless connection properties . . . . . . . . .
Internet Protocol (TCP/IP) properties . . . . . .
Wireless networks tab . . . . . . . . . . . . . .
Setting a new wireless network . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
120
120
121
121
122
122
123
D.1
D.2
D.3
D.4
D.5
D.6
D.7
D.8
D.9
Cable connection pins . . . . . . . . . . .
Cable connection colors . . . . . . . . . .
Impact Main Window . . . . . . . . . . .
PROM File Formatter Window . . . . . .
Select configuration file 1 . . . . . . . . .
Select configuration file 2 . . . . . . . . .
Prompt for new configuration file addition
PROM Configuration file creation 1 . . .
PROM Configuration file creation 2 . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
126
127
128
129
129
130
130
131
132
xvi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
84
99
xviii
Lista de Tabelas
6.1
6.2
Análise de acelerómetros com base nas suas caracterı́sticas principais . .
Análise de osciloscópios com base nas suas caracterı́sticas principais . . .
63
63
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
7.10
7.11
7.12
7.13
7.14
7.15
7.16
7.17
7.18
7.19
Informações gerais para o módulo payload listener. . . . .
Tempos para o módulo payload listener. . . . . . . . . . .
Informações gerais para o módulo position updater. . . . .
Tempos para o módulo position updater. . . . . . . . . . .
Informações gerais para o módulo “obstacle updater”. . . .
Tempos para o módulo “obstacle updater”. . . . . . . . . .
Informações gerais para o módulo position sender. . . . .
Tempos para o módulo position sender. . . . . . . . . . .
Informações gerais para o módulo “FPGA listener”. . . . .
Tempos para o módulo FPGA listener. . . . . . . . . . . .
Informações gerais para o módulo “safety task”. . . . . . .
Tempos para o módulo safety task. . . . . . . . . . . . . .
Informações gerais para o módulo “velocity observer”. . .
Tempos para o módulo “velocity observer”. . . . . . . . .
Informações gerais para o módulo “orientation observer”. .
Tempos para o módulo “orientation observer”. . . . . . . .
Tempos para o ciclo de controlo do componente wormhole.
Tamanho máximo para cada tipo de mensagem. . . . . . .
Total de tráfego gerado pela totalidade das mensagens. . .
85
86
88
88
89
89
90
90
91
91
92
92
93
94
95
95
96
97
98
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
D.1 Cable/Pin correspondence . . . . . . . . . . . . . . . . . . . . . . . . . 125
xix
Capı́tulo 1
Introdução
Este capı́tulo apresenta a motivação e objectivos do trabalho realizado, contribuições que
o mesmo oferece, âmbito do projecto e a organização deste documento.
1.1
Motivação
Robôs têm sido utilizados à já algum tempo em áreas como exploração, entretenimento
e segurança. Esses robôs, autónomos ou controlados por humanos, ajudam a alcançar
os objectivos efectuando tarefas repetitivas, perigosas ou que requerem precisão. Desses
robôs, alguns são móveis o que significa que eles não estão fixos a um local e podem efectuar tarefas em áreas diferentes. Isso pode aumentar a probabilidade de algo acontecer ao
robô porque este vai interagir com um ambiente dinâmico.
Algumas das tarefas referidas anteriormente requerem cooperação entre os múltiplos
robôs de forma a serem concretizadas. De forma a alcançar os objectivos dessas tarefas,
os robôs necessitam de cooperar, seja enviando informação sobre o ambiente em seu redor, seja criando estratégias que maximizam os resultados do trabalho em equipa.
Para cooperarem, os robôs precisam de comunicar entre si, normalmente utilizando
um dispositivo de comunicação sem fios. Durante o processo de cooperação podem existir
alguns atrasos na actuação do robô, por causa de demoras incontroláveis na comunicação
com outros robôs. Esses atrasos podem dever-se a vários factores como: interferência
no canal de comunicação, partições temporárias na rede e falhas de outros robôs. Esses
atrasos podem ter impacto na tarefa de controlo. Se esta tarefa sofrer atrasos pode não
conseguir evitar algum perigo imediato.
Um passo importante na mitigação destes problemas que resultam de oscilações no
tempo necessário para a comunicação, foi tomado com o desenvolvimento de um middleware baseado na arquitectura wormhole[1] para plataformas Linux. Este middleware
1
Capı́tulo 1. Introdução
2
foi desenvolvido com o intuito de suportar robôs virtuais na patrulha de áreas conhecidas.
Os componentes do middleware trabalham em conjunto para garantir a execução sı́ncrona
de tarefas crı́ticas.
A arquitectura wormhole[2] é uma abstracção que define dois subsistemas: o wormhole
e o payload. O wormhole é um simples e pequeno subsistema que pode garantir propriedades que são difı́ceis de alcançar em sistemas grandes. Uma propriedade que é relevante
para este trabalho é a execução sı́ncrona de tarefas crı́ticas. O payload é um complexo subsistema onde a aplicação principal, que pode conter algoritmos consumidores de tempo,
é executada. A execução atempada desta aplicação é verificada por um componente do
wormhole que é o Timely Timing Failure Detector (TTFD).
O que é pretendido com este trabalho é transportar o middleware já criado para um
conjunto de hardwares de forma permitir o controlo de um robô fı́sico. Durante o processo
de porte da aplicação pretende-se refinar os aspectos de gestão de tempo disponibilizados
pelo componente wormhole.
1.2
Objectivos
Os objectivos deste trabalho são:
• Melhorar os algoritmos do middleware mencionado anteriormente;
• Criar uma camada de sensores e motores que permita a interacção com o wormhole;
• Adaptar o middleware para um robô móvel;
• Validar a propriedade de execução sı́ncrona do wormhole.
Este robô deve ser parte de uma equipa de outros robôs iguais que patrulham uma área
conhecida.
A plataforma de hardware alvo dos robôs móveis 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 já se encontrava disponı́vel.
Capı́tulo 1. Introdução
1.3
3
Contribuições
O middleware foi implementado nesta plataforma de hardware e a propriedade de execução
sı́ncrona foi validada. Adicionalmente, o módulo Safety task, que é um componente secundário do middleware, foi melhorado.
As contribuições deste trabalho aplicam-se a duas áreas principais. Essas áreas são:
Robótica e Sistemas de tempo real. Na área da robótica foi criado um robô que conhecendo o mapa consegue percorrer o mesmo em busca de possı́veis intrusos. Na área de sistemas de tempo real foi implementada uma arquitectura wormhole em robôs. Esta arquitectura permite que existam dois subsistemas capazes de controlar o robô, um com mais
capacidades mas menos confiável e outro com menos capacidades mas mais confiável.
Caso o subsistema com mais capacidades não esteja a conseguir controlar o robô o sistema mais confiável toma o controlo até o outro subsistema conseguir controlar o robô de
novo.
Em paralelo ao projecto foi escrito um artigo para publicação em breve.
1.4
Âmbito
Este projecto foi realizado no âmbito da disciplina de Projecto de Engenharia Informática
do Mestrado em Engenharia Informática, da faculdade de Ciências da Universidade de
Lisboa. Este projecto está inserido numa das linhas de investigação, que é a Timeliness
and Adaptation in Dependable Systems, de um dos grupos de investigação desta faculdade, que são os Navigators, distributed systems research team.
1.5
Plano de Trabalho
O plano de trabalho para 9 meses foi o seguinte:
• Familiarização com os diferentes módulos de hardware e software do robô e com o
middleware disponı́vel;
• Melhoria dos componentes existentes do middleware;
• Criação da camada de sensores e interface para comunicação no wormhole;
• Portar o wormhole para um microcontrolador;
• Portar a TTFD task para a FPGA;
Capı́tulo 1. Introdução
4
• Recolha do estado da arte.
• Escrita de artigos cientı́ficos e de relatório final.
1.6
Estrutura do documento
Este relatório encontra-se organizado da seguinte forma:
• No segundo capı́tulo é apresentado todo o trabalho relacionado, incluı́do os trabalhos directamente relacionados com o projecto e trabalhos que forneceram informações
importantes para melhoramento do middleware.
• No terceiro capı́tulo é apresentado o contexto e o enquadramento tecnológico, onde
são presentadas todas as tecnologias apresentadas no âmbito deste trabalho assim
como as aplicações que são usadas e hardware.
• No quarto capı́tulo é apresentado o planeamento. Nesta secção são apresentados os
requisitos do projecto assim como a metodologia de desenvolvimento utilizada.
• No quinto capı́tulo é apresentada a arquitectura de sistemas onde são apresentadas
todas as decisões tomadas, como módulos criados e mensagens que os módulos
trocam entre si.
• No sexto capı́tulo são apresentados os detalhes da implementação divididos nas
várias fases de desenvolvimento.
• No sétimo capı́tulo são apresentados os testes e respectivos resultados.
• No oitavo capı́tulo são apresentadas as conclusões após realização deste trabalho e
trabalho futuro.
Capı́tulo 2
Trabalho Relacionado
O desenvolvimento de aplicações crı́ticas levou à criação de várias soluções de sistema
que são tolerantes a faltas. Uma dessas soluções é apresentada em [3], que consiste num
subsistema hı́brido, chamado TTCB, que adiciona tolerância a intrusões a aplicações
existentes. Este componente é capaz de executar tarefas crı́ticas e fornece a capacidade de execução sı́ncrona ao sistema. Este componente adicionalmente possibilita a
comunicação com outros TTCB através de um canal de comunicação seguro de forma
a fornecer serviços adicionais como consenso. Outra solução [4] apresenta um sistema
hı́brido que permite adicionar garantias a ambientes que utilizam comunicação por wireless. Esta solução incide sobre pelotões de veı́culos e utiliza a arquitectura wormhole.
Num contexto simular a esta última solução, o trabalho apresentado em [5] apresenta
uma solução para pelotões de veı́culos baseada na arquitectura wormhole. Neste trabalho
é implementado uma camada confiável onde serviços de controlo de tempo correm. São
apresentadas soluções para diversos problemas como incerteza no processo comunicacional e inconsistências temporais. O livro [6] fornece vários algoritmo, cada um garantindo
certas propriedades, que podem ser utilizados na comunicação entre componentes ou entre robôs. Esses algoritmos são ùteis para a reescrita de protocolos se necessário garantir
uma ou mais propriedades como ordem de entrega, ou detecção de faltas por parte de um
componente ou robô. Todos estes trabalhos fornecem informações sobre a implementação
de sistemas de tempo real o que permite tirar lições que são úteis para o desenvolvimento
deste projecto.
Navegação utilizando um mapa é um importante componente para qualquer robô móvel.
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 distância mı́nima possı́vel. O
trabalho em [7] apresenta uma solução de planeamento de caminhos que planeia o caminho baseando-se não na necessidade de encontrar o caminho mais curto, mas sim na
necessidade de examinar objectos ou locais no mapa. São apresentadas soluções para
navegação baseada em parâmetros como maximizar a informação obtida dos objectos
a examinar no mapa. Esta solução é muito útil para o desenvolvimento deste projecto
5
Capı́tulo 2. Trabalho Relacionado
6
porque a navegação no caso de vigilância deve ter em conta a maximização 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 robô, sendo perfeito para equipas de robôs
móveis. Esta solução é muito interessante para tarefas de vigilância visto que é necessário
interceptar um possı́vel intruso. Uma solução de localização e construção de mapa é apresentado em [9]. Esta solução utiliza algoritmos complexos baseado no filtro de Kalman
que possibilita a criação de um mapa completo e ao mesmo tempo a localização dentro
do mesmo. Os detalhes de localização deste trabalho são interessantes pois os mesmos
utilizam sensores locais para desenho e localização 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 acelerómetros, o que é útil para o desenvolvimento
dos algoritmos de navegação de forma a mitigar o impacto de possı́veis leituras com ruı́do
dos sensores.
O trabalho em [13] apresenta um middleware com o propósito de oferecer um motor
tolerante a faltas e cooperativo para equipas de robôs virtuais num contexto de vigilância
de áreas conhecidas. O trabalho deste projecto incidiu sobre esta solução pelo facto do
código fonte para a mesma estar disponı́veis e por ser a única solução que utiliza a arquitectura wormhole. O middleware foi melhorado e aplicado a robôs móveis fı́sicos no
âmbito deste projecto. O middleware é apresentado na próxima subsecção.
2.1
Middleware
Nesta secção e respectivas subsecções é apresentado todo o trabalho efectuado no âmbito
do middleware para tarefas de vigilância. Inicialmente é apresentada a motivação do trabalho, seguido das decisões de desenho e finalmente de algum detalhe da implementação.
A figura 2.1 apresenta um modelo completo do middleware com todos os seus módulos.
2.1.1
Motivação
Este middleware [13] pretende garantir o controlo atempado do robô independentemente
dos possı́veis atrasos causados pelo a comunicação entre robôs. O cenário de aplicação
do trabalho anterior é a vigilância de uma área conhecida e a identificação de intrusos.
Um intruso é algo que é encontrado no caminho do robô mas não está no mapa. Quando
um intruso é encontrado, o robô deve adoptar uma estratégia de bloqueio fı́sico de forma
a cortar possı́veis caminhos de fuga. Para uma área 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 robôs
Capı́tulo 2. Trabalho Relacionado
7
Figura 2.1: Modelo completo da arquitectura do middleware
fı́sicos. Este trabalho foi escolhido devido ao facto de ser a única solução até ao momento
a utilizar a arquitectura wormhole e ser uma das restrições deste trabalho. Adicionalmente
o código fonte está disponı́vel o que permite observar a implementação 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 vários componentes.
O middleware tem como objectivo criar uma ponte entre o programador e a camada de
sensores mais abaixo, o que permite controlar um robô, inserido numa equipa de robôs,
que efectua tarefas de vigilância de uma localização. Essa ponte adicionalmente permite
ao programador tolerância a inconsistências no tempo que o payload demora a completar
a tarefa de controlo.
Dentro do contexto de vigilância de uma área conhecida, um middleware foi criado
que utiliza a arquitectura wormhole. O desenho define uma camada de controlo composta por dois componentes, um sı́ncrono e o outro assı́ncrono, que permitem a execução
atempada da tarefa de controlo do robô. O componente sı́ncrono, ou wormhole, necessita 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 são utilizados
Capı́tulo 2. Trabalho Relacionado
8
Figura 2.2: Estrutura interna do payload
no controlo do robô. Adicionalmente às capacidades de controlo de tempo mencionadas
anteriormente, o wormhole deve ser capaz de controlar o robô quando necessário e actuar como um filtro entre a camada de sensores e motores e o payload para que toda a
informação passe primeiro pelo wormhole, sendo necessário aprovação do mesmo antes
de chegar ao destino. Um destes componente, wormhole ou payload, controla o robô a
cada momento. Ter o controlo do robô implica enviar comandos de velocidade e direcção
para o hardware.
De forma ao componente payload utilizar a capacidade de execução atempada de tarefas
do componente wormhole, foi criada uma estrutura de dados que é enviada pelo payload para o wormhole. A estrutura chama-se promessa e contém valores de velocidade,
direcção e destino para controlo do robô e o prazo para a chegada da próxima promessa
para que o wormhole possa monitorizar o tempo que o payload demora. Os valores recebidos na promessa são depois enviados para a camada de sensores para serem aplicados
aos motores.
O componente wormhole é dividido em três módulos:
• Timely Timing Failure Detector, ou TTFD task, é o módulo que monitoriza o tempo
que o payload demora para gerar uma promessa;
• Safety task que controla o robô quando o payload não envia a promessa dentro do
Capı́tulo 2. Trabalho Relacionado
9
tempo estipulado ou caso o payload não 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 não cumpre um prazo para enviar a promessa, o
módulo TTFD Task pode temporariamente mudar o controlo para o wormhole até o payload conseguir de novo cumprir a promessa. Se isso acontecer o componente payload
recebe uma informação em conforme foi desactivado e deve cumprir a próxima promessa
de forma a conseguir obter o controlo de novo. Se o payload não cumprir a promessa um
número pré-definido de vezes, ou se não enviar a promessa durante um intervalo de tempo
pré-definido, o wormhole pode reiniciar o payload.
O componente payload foi construı́do segundo uma estrutura de árvore de eventos. A
árvore de eventos define que um módulo pode ser instalado em qualquer parte da árvore
tendo que ter pelo menos um módulo pai. Cada vez que um evento é gerado o mesmo
passa por todos os módulos que estão abaixo do módulo que o gerou. Existem três tipos
de eventos:
• os hard events que são os eventos gerados pelo hardware do robô, como obstáculos
perto do robô, e são sempre enviados localmente para todos os módulos a partir da
raiz da árvore;
• os soft events que são eventos que podem ser gerados por módulos na árvore e são
enviados localmente para todos os módulos abaixo do módulo que o gerou;
• os remote soft events que são eventos que podem ser gerados pelos módulos na
árvore e são enviados para o módulo na mesma localização da árvore noutros robôs
e transmitidos para todos os módulos abaixo desse.
Na próxima subsecção vamos detalhar o comportamento do wormhole e payload implementado no middleware.
2.1.3
Implementação
O middleware foi criado para gestão de equipas de robôs que trabalha concorrentemente
para garantir a vigilância de um local. No âmbito do middleware uma equipa é um conjunto de robôs que se encontram ao alcance de pelo menos outro robô o que permite que
comuniquem entre eles, sendo possı́vel existirem vários grupos num dado cenário. O canal de comunicação é utilizado pela equipa para indicar as posições de cada robô, para
indicar a posição de possı́veis obstáculos e intrusos. O canal de comunicação também
é utilizado para tarefas de manutenção do grupo como por exemplo, a entrada de novos
Capı́tulo 2. Trabalho Relacionado
10
robôs num grupo que ocorre quando dois grupos passam a estar no alcance um do outro,
sendo necessário cruzar informações de forma a sincronizar a vista que cada robô tem do
ambiente.
Para a operação correcta do middleware, o mapa da área que o robô estará a efectuar
acções de vigilância tem que ser fornecido quando o robô é activado. O mapa em questão
é representado através de células o que permite uma representação simples de qualquer
ambiente. O tamanho das células è configurável e permite que a largura sejam diferente
do comprimento. Em relação à codificação do mapa, existe um carácter que representa as
paredes e um outro que representa o caminho o que permite a criação de um mapa com
relativa facilidade. No entanto para ser possı́vel utilizar este mapa, algumas conversões
são necessárias visto existirem infinitas posições reais dentro de uma célula virtual.
De forma a simular a interacção entre vários robôs, o simulador de robôs Simbad
foi usado. Este simulador pode simular ambientes permitindo que robots virtuais, que
também são simulados pelo mesmo, interajam com o ambiente.
O middleware está disponibilizado em duas versões: a Simulator que permite a criação
de simulação de equipas de robôs virtuais e estações fixas; a Mobile que consiste na versão
que não tem nenhuma ligação com o simulador Simbad.
O middleware foi criado utilizando a linguagem de programação C tendo sido depois
ligada em Simbad através de JNI porque o Simbad foi desenvolvido utilizando a linguagem de programação JAVA . A razão do middleware ter sido criado em C é porque C está
disponı́vel para mais plataformas que o Java especialmente plataformas com baixo nı́vel
de recursos (CPU e memória).
Wormhole
A implementação do componente wormhole segue a ideia base do modelo, ou seja, um
componente simples que garante uma ou várias propriedades difı́ceis de obter num componente complexo. O wormhole implementa um subsistema que garante a execução
sı́ncrona do componente payload e controla o acesso a alguns recursos crı́ticos do sistema.
Para isso ser possı́vel esta implementação disponibiliza um protocolo de comunicação entre 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̧ão é determinar se o payload completa a tarefa dentro do tempo que o mesmo estipulou. Se isso
ocorrer os dados enviados pelo payload são encaminhados pelo wormhole para a camada
de sensores, senão o wormhole adquire o controlo do robô e controla-o até o componente
Capı́tulo 2. Trabalho Relacionado
11
payload voltar a cumprir uma promessa. Adicionalmente o wormhole tem a possibilidade
de reiniciar o payload se o mesmo não efectuar nenhuma tentativa de contacto durante
um extenso perı́odo de tempo ou falhar o cumprimento da promessa várias vezes.
O wormhole implementado tem 3 módulos:
• Safety task, que é utilizado cada vez que o payload perde controlo, seja por inactividade seja por demora na entrega de promessas. Este módulo utiliza as coordenadas
de destino enviadas pelo payload para o saber para onde o robô 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
necessário;
• Control task, que recebe os dados do payload e envia-os para os sensores de acordo
com o estado do payload.
Estes três módulos trabalham para permitirem ao componente payload a capacidade
de execução atempada do controlo do robô. Todos os módulos apresentados trabalham
sobre estado do payload guardado pelo wormhole. Este estado é partilhado entre todos os
módulos do wormhole e pode ter um de três estados perante o wormhole que são:
• Desactivado, em que o wormhole controla o robô. Este estado é alcançado depois
do payload não 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 não
cumprir as promessas que envia, o mesmo é reiniciado.
• Em testes, em que o wormhole controla o robô. Este estado é alcançado depois
do payload ter estado desactivado e ter enviado posteriormente uma promessa. O
conteúdo dessa promessa é ignorado mas serve para assinalar ao wormhole que o
payload esta a tentar de novo a tentar cumprir as promessas.
• Activo, em que o payload controla o robô. Este é o estado preferencial do sistema visto que o payload tem uma capacidade maior de cumprir objectivos que o
wormhole. Este estado indica também que o payload cumpriu a última promessa
que entregou. O robô alcança este estado se anteriormente estava em testes e se
cumpriu a última promessa.
Payload
O payload é um componente assı́ncrono que comporta todos os processos complexos e
não deterministas. O payload utiliza o wormhole sempre que pretende usufruir da sua
Capı́tulo 2. Trabalho Relacionado
12
Figura 2.3: Exemplo de propagação de eventos
propriedade, que neste caso é a propriedade de execução sı́ncrona. Como indicado anteriormente, para o payload poder manter o controlo do sistema e efectuar trabalho é
necessário o mesmo sinalizar a intenção de o fazer ao wormhole, através da estrutura promessa. O payload deverá 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 está presente no wormhole.
O payload implementa um sistema de navegação com base num mapa de duas dimensões simples, um sistema de comunicação que permite comunicação entre outros
robôs e um sistema de eventos sobre o qual podem ser gerados módulos. Estes componentes são detalhados nas próximas subsecções.
A versão do payload presente neste middleware foi construı́da com base numa árvore de
eventos para facilitar a criação e interacção entre módulos. Os módulos criados podem ser
grupos ou folhas. Os grupos estão disponı́veis para permitir a organização da árvore e não
efectuam qualquer computação enquanto nas folhas é feita toda a computação necessária.
Qualquer evento gerado é emitido por um módulo na árvore, seguindo depois para todos
os sub-módulos e cada sub-módulo emite esse evento para os seus sub-módulos até ser
consumido. Os módulos são organizados em grupos e os grupos de módulos podem ter
vários módulos pais. Os eventos que são gerados pelo hardware do robô (hard events) são
enviados para a raiz da árvore enquanto os eventos dos módulos são enviados para todos
os sub-módulos (local soft events) ou pela interface de rede (remote soft events) para o
módulo na mesma posição da árvore nos outros robôs. Esta última capacidade permite
que eventos como detecção de intrusos sigam directamente para outros robôs. Um exemplo de propagação de um evento pode ser observado na figura 2.3.
Um exemplo de um módulo que foi implementado é o módulo Freshness detector que
verifica periodicamente se os valores de posição e orientação que o payload tem são re-
Capı́tulo 2. Trabalho Relacionado
13
centes e se não forem avisa o wormhole desse facto.
O algoritmo de sincronização de vista criado permite manter uma visão partilhada do
estado de cada robô. Para que isso seja possı́vel é necessário que os robôs estejam ao
alcance uns dos outros para que seja possı́vel interagirem entre si. Se isso não acontecer é
possı́vel que existem vários grupos de robôs separados a moverem-se pelo mesmo mapa.
Se dois grupos se encontrarem os mesmos iniciam o processo de junção 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 até outro e funciona correctamente com o tipo de mapa utilizado. O algoritmo tenta
calcular a distância até ao objectivo avançando em todas as direcções até encontrar um
caminho. A cada iteração o algoritmo avança uma célula em cada sentido possı́vel guardando o custo do caminho actual, o que resulta no caminho mais curto ser encontrado
primeiro. Adicionalmente o algoritmo permite que dois robôs com sentidos opostos se
cruzem no caso do caminho que utilizam apenas permitir a passagem de um robô.
Como podemos observar a figura 2.4 apresenta os passos dados pelo algoritmo de
navegação de forma a descobrir qual o melhor caminho do ponto inicial (assinalado com
um S) até ao ponto final (assinalado com D). Os cı́rculos a amarelo representam os passos
e a ordem como os mesmos são gerados, os cı́rculos a vermelho representam os robôs e
os cı́rculos a preto representam o ponto inicial e final. Como podemos verificar o algoritmo toma em consideração a orientação dos robôs no mapa de forma a evitar entrar em
caminho que apenas passa um robô (caso do R1 e R3). No caso do robô R2 com o mesmo
está a avançar na mesma direcção que o movimento o algoritmo sabe que pode aceitar
esse caminho como possı́vel via para chegar ao objectivo.
Figura 2.4: Exemplo de execução do algoritmo de navegação
Capı́tulo 3
Contexto e enquadramento tecnológico
Este capı́tulo enquadra o trabalho realizado e descreve as tecnologias utilizadas na sua
realização.
3.1
Linguagens
Nas próximas secções são 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 fácil de utilizar. Esta linguagem, inicialmente não 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̧ão para correr nos sistemas
operativos como na Internet.
A versão de Basic a ser utilizada é uma versão própria para ser executada em microcontroladores porque permite operações que não estão disponı́veis na versão de Basic
disponı́vel para computadores. Essas operações lidam com as portas do microcontrolador
permitindo ao programador interagir directamente com outros componentes via as mesmas. Adicionalmente existe algumas funções para gestão de energia que permite ao programador colocar o microcontrolador num estado de baixo consumo de energia quando
o mesmo não é necessário. Esta linguagem foi analisada no âmbito das linguagens disponı́veis para programação do microcontrolador.
Neste projecto esta linguagem é utilizada na programação do microcontrolador.
15
Capı́tulo 3. Contexto e enquadramento tecnológico
3.1.2
16
Assembler, C e C++
O Assembler é uma linguagem de baixo nı́vel que permite a programação de um hardware especı́fico. O código é baseado em mnemónicas que simbolizam instruções, registo
do processado e localizações na memória. Esta linguagem foi analisada no âmbito das
linguagens disponı́veis para programação do microcontrolador.
O C é uma linguagem estruturada de baixo nı́vel com o objectivo de ser utilizada para
programar em várias plataformas. Esta linguagem permite um acesso de baixo nı́vel aos
componentes do computador de forma a possibilitar a maximizar o controlo e possibilidades que o programador tem sobre a máquina mas também facilitando a programação
face a outras linguagens de baixo nı́vel como o Assembler. Esta linguagem é utilizada no
middleware e em todos os seus módulos porque C, é uma linguagem que permite programar para várias plataformas e esta foi a linguagem escolhida inicialmente para programar
o middleware.
O C++ é uma linguagem estruturada orientada a objectos que começou por ser uma
extensão do C. Esta linguagem permite a utilização de uma grande parte das funcionalidades do C em adição à capacidade de criação de classes. Esta linguagem foi analisada
no âmbito 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 código produzido em múltiplas plataformas sem a necessidade de o adaptar. O Java
é uma linguagem orientada a objecto que permite uma programação mais fácil. Esta linguagem é utilizada na camada de sensores original e em todo o código que interage com
a aplicação 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̧ão geral sobre regras de programação para esta linguagem assim como erros
básicos que ocorrem durante a programação. Esta linguagem é muito diferente das linguagens convencionais e tem regras estruturais que não se aplicam a outras linguagem
com C ou Java. Esta linguagem é utilizada para programar a FPGA.
Capı́tulo 3. Contexto e enquadramento tecnológico
3.2
17
Aplicações
Nas próximas subsecções é apresentado todo o software utilizados durante o desenvolvimento do projecto. Esse software pode ser aplicações que auxiliem ou permitam a
programação para um determinado hardware ou pacotes de software que facilitam a
utilização do hardware.
3.2.1
Micro Basic Studio
O Basic Micro Studio é um IDE que permite desenvolver aplicações para o microcontrolador. Esta aplicação permite a gestão de um ou mais projectos, relacionados com vários
microcontroladores da mesma fabricante. Esta aplicação permite a programação em Basic, C++ ou Assembler embora o C++ tenha sido introduzido apenas recentemente logo
ainda não existe muitos exemplos sobre o mesmo. Para a programação em Basic existe
um manual detalhado que especifica todas as funções disponı́veis. Aplicação permite a
programação do microcontrolador através de cabo série ou USB tanto para programar a
aplicação completa ou para depurar.
A figura 3.1 demonstra o ambiente de trabalho do IDE Basic Micro Studio. Nesta
imagem podemos identificar 4 áreas importantes. A primeira área no topo contém os atalhos e menus que são comuns a qualquer aplicação (Novo, Abrir, Guardar, etc..) assim
como alguns botões especı́ficos deste IDE que são o Build, o Program e o Debug. A segunda área encontra-se à esquerda e nesta é apresentada a área de trabalho com todos os
projectos abertos no momento. O projecto actual está marcado com uma formatação de
letra diferente (negrito). A terceira área que pode ser encontrada á direita da segunda área
contém o código de cada um dos projectos. Como podemos verificar o código contém
cores diferentes em que cada cor denota um tipo de texto diferente (variáveis, modificadores, números, etc..). A quarta área situa-se por baixo da terceira área e esta apresenta
uma consola onde são reportadas as estatı́sticas do código. Adicionalmente as estatı́sticas
esta área pode ser utilizada para comunicar directamente com o microcontrolador via consola.
3.2.2
Eclipse
O Eclipse é um IDE que permite desenvolver aplicações para múltiplas linguagens permitindo a gestão de vários projectos. Este IDE permite um rápido desenvolvimento devido
as funcionalidade que o mesmo implementa. Das funcionalidades disponı́veis destaca-se
as seguintes:
Capı́tulo 3. Contexto e enquadramento tecnológico
18
Figura 3.1: Ambiente de trabalho da aplicação Basic Micro Studio
• Completar automático de palavras, que permite que o utilizador apenas escreva
parte da palavra para que seja sugerido possı́veis palavras.
• Compilação imediata, que permite ao utilizador observar possı́veis erros conforme
o mesmo programa na mesma janela do código.
• Cores para o código de acordo com o contexto, que permite ao programador identificar rapidamente elementos diferentes no código.
Esta aplicação é utilizada para programação em JAVA e C através da funcionalidade
JNI disponı́vel no JAVA. Esta aplicação é utilizada no âmbito do projecto para programar
módulos para o componente wormhole e payload.
3.2.3
Helix
Helix é uma distribuição de Linux e uma toolchain optimizada para sistema com pouco
recursos. Esta distribuição 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 sequência para efectuar uma tarefa complexa como compilar uma aplicação
para ser corrida numa arquitectura de processador diferente daquela em que a aplicação
está a ser compilada. A toolchain disponı́vel permite compilar programas e o kernel para
a distribuição Linux com o mesmo nome. Adicionalmente a toolchain tem alguns pacotes
Capı́tulo 3. Contexto e enquadramento tecnológico
19
Figura 3.2: Arquitectura da distribuição Helix
de software pré-compilados que podem ser utilizados na construção da imagem do sistema de ficheiros.
Como podemos observar na figura 3.2 o sistema Linux para este dispositivo é constituı́do por um kernel Linux por uma biblioteca de C e várias outras bibliotecas e aplicações
complementares. No topo destes componentes fica a aplicação que pretendemos executar
enquanto por baixo destes componentes fica o hardware.
O pacote Helix é constituı́do pelos componentes indicados anteriormente e adicionalmente tem utilitários que permitem a construção de imagens do sistema operativo.
O manual em [18] apresentada comandos, configurações 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̧ões para a FPGA.
Esta aplicação permite a gestão de um ou mais projecto, relacionados com várias FPGAs
da mesma fabricante (Xilinx). Este IDE permite a criação de projectos através de código
HDL, de esquemas eléctricos ou importando um ficheiro no formato EDIF (formato de
esquema open source). Esta aplicação permite programar em duas linguagens: Verilog
e VHDL. O processo que transforma o código criado numa configuração válida para a
FPGA tem os seguintes passos:
• Criação do código/esquema, neste passo é criado o código numa das linguagens
indicadas anteriormente, ou um esquema a representar o que a configuração deve
Capı́tulo 3. Contexto e enquadramento tecnológico
20
fazer. Este passo está a cargo do utilizador.
• Behavioral Simulation, neste passo é simulado o código/esquema criado no passo
anterior. O utilizador pode gerar configurar valores de entrada e observar os valores
de saı́da através do interface gráfico disponı́vel. Este passo é facultativo.
• Design Synthesis, neste passo a sintaxe do código e a hierarquia do projecto são
verificados, o código é analisado sendo feito um levantamento de todos os componentes (memória, portas lógicas, buffers) necessários pelo design e optimiza o
design removendo lógica redundante.
• Design Implementation, neste passo o código é traduzido e mapeado para o dispositivo em que vai ser instalado. Adicionalmente depois de mapeados os componentes,
estes são ligados de acordo com o desenho.
• Generate Programming File, neste passo um ficheiro de configuração é gerado. Este
ficheiro pode ser instalado directamente na FPGA. Se for necessário configurar uma
EEPROM é necessário 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 áreas importantes. A primeira área no topo contém
os atalhos e menus que são comuns a qualquer aplicação (Novo, Abrir, Guardar, etc..). A
segunda área encontra-se directamente por baixo da primeira á esquerda e nesta é apresentada a área de trabalho como o projecto actual e todos os seus componentes. A terceira
área encontra-se á direita da segunda área e contém o código do ficheiro actualmente
aberto. Como é possı́vel observar o código tem cores que auxiliam na identificação de
certo tipo de texto (variáveis, palavras reservadas, arrays). A quarta área localiza-se por
baixo da segunda área e à esquerda da terceira e contém vários atalhos para ferramentas. O resultado de executar essas ferramentas é apresentado por um visto branco, um
triângulo com um ponto de exclamação ou uma cruz respectivamente para os casos em
que correu tudo bem, existiram pequenos erros ou avisos e a operação não foi concluı́da.
A quinta área encontra-se por baixo da terceira e quarta área e pode apresentar erros, avisos 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̧ão de um ambiente onde
robôs virtuais, também criados com este simulador, podem interagir. Os robôs virtuais criados permitem a instalação de vários tipos de sensores, que permitem ao robô ter
Capı́tulo 3. Contexto e enquadramento tecnológico
21
Figura 3.3: Ambiente de trabalho da aplicação ISE Project Navigator
percepção do que está à sua volta. Este simulador permite visualizar graficamente o ambiente criado, os robôs que o utilizam e os valores dos sensores de cada robô.
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 dispositivo que inicialmente não tem mais nada instalado. No âmbito 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 vários meios. No caso do U-boot os meios disponı́veis são através de TFTP.
O manual em [19] apresenta as configurações possı́veis para este tipo de bootloader.
O U-boot vem instalado por predefinição na placa com o ARM.
3.2.7
Busybox
A BusyBox fornece versões simplificadas de alguns comandos básicos de Linux a partir
de um executável apenas. As versões dos comandos presentes na busybox tem menos funcionalidades mas são mais pequenas e utilizam menos memória que as versões originais.
Este pacote de utilitários foi construı́do a pensar em dispositivos com poucos recursos
Capı́tulo 3. Contexto e enquadramento tecnológico
22
Figura 3.4: A4WD1 v1
(memória, poder de processamento). A Busybox é instalada na imagem do sistema de
ficheiros para fornece as ferramentas necessárias 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 próximas
subsecções. De todo o hardware existente actualmente, uma grande parte estava disponı́vel antes do projecto iniciar. Este facto significa que esse hardware é uma restrição
ao projecto pois não foi possı́vel escolher ou alterar.
Chassis do Robô
Para construir o robot, o chassis A4WD1 v1 (figura 3.4) está disponı́vel. O chassis tem
bastante espaço e consegue-se facilmente colocar duas pequenas placas, múltiplos sensores e baterias. Este chassis vem equipado com quatro rodas e respectivos motores e está
organizado em duas plataformas, a inferior é onde a placa controladora dos motores e as
baterias para a alimentar são 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.
Capı́tulo 3. Contexto e enquadramento tecnológico
23
Figura 3.5: Motor GHM-01
Figura 3.6: Placa controladora Sabertooth 2x12
Motores e placa controladora
Os motores utilizados são quatro GHM-01 (figura 3.5). Estes motores necessitam de 12
Volt, conseguem efectuar 200 rotações 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 através de vários métodos. Os métodos de controlo disponı́veis são
os seguintes:
• Controlo analógico, em que a placa aguarda por uma tensão 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 através do padrão TTL, em que a placa aguarda por informação enviada
pela interface série para depois transmitir esses comandos ao motor.
O objectivo principal desta placa é fazer uma ponte entre os motores e um microcontrolador. Esta ponte é necessária porque o microcontrolador não consegue debitar
Capı́tulo 3. Contexto e enquadramento tecnológico
24
Figura 3.7: Sensor ultra-sónico SRF05
intensidade de corrente necessária para fazer com que os motores respondam.
Sensores de distância
De forma a obter os obstáculos na proximidade do robô sensores de distância são necessários. Os sensores disponı́veis são os SRF05 ultra-sonic sensors (figura 3.7) que
medem a distância utilizando impulsos e aguardando pelo eco. Estes sensores são digitais e podem ser ligados directamente a um microcontrolador. Os sensores requerem
cinco volts permanentes, necessitam de um impulso de dez microssegundos para iniciarem uma leitura e demoram no máximo 30 milissegundos a retornar uma leitura. Estes
sensores foram soldados de acordo com o modo de configuração dois que define que a
porta que é utilizada para enviar o impulso para iniciar a leitura é também utilizada para
obter a leitura da distância. Os valores de leitura da distância após recebidos necessitam
ser transformados em centı́metros dividindo o valor obtido pelo número 116.136. Este
valor deriva do valor fornecido pelo manual e significa que cada 116 unidades retornadas
pelo microcontrolador (58 nanossegundos) são iguais a um centı́metro.
Existem alguns cuidados a ter com o posicionamento destes sensores. Estes sensores
enviam um impulso na direcção em que os mesmos estão apontados mas a onda não se
dispersa apenas nessa direcção. Como podemos observar na FIGURA 3.8, a onda dispersa essencialmente dentro de um ângulo de 60 graus em volta do sensor.
Placas
De forma a permitir a separação requerida dos componentes do middleware, duas placas
estão 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 mãe 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 contém uma porta série que será utilizada
Capı́tulo 3. Contexto e enquadramento tecnológico
25
Figura 3.8: Caracterı́sticas da dispersão da onda criada pelo sensor SFR05
Figura 3.9: Bot Board II
para comunicações. Esta placa irá conter parte do wormhole e a camada de sensores.
A placa Bot Board II contém 16 pinos directamente ligados ao microcontrolador que
podem ser utilizado para ligar sensores ou motores. A placa contém também 4 botões e 4
leds, 3 dos quais podem ser programados para executar funções como ordens directas ao
robô ou indicar o estado do robô (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̧ão. Esta placa fornece
múltiplos pinos a 5 V DC que podem ser utilizado para alimentar sensores e pequenos
motores.
Capı́tulo 3. Contexto e enquadramento tecnológico
26
Figura 3.10: Atom Pro 28-M
Figura 3.11: H4090
O processador Atom Pro 28-M(figura 3.10) permite a utilização de 32 Kilobytes para
código e constantes, 2 Kilobytes para variáveis, 3 temporizador por hardware, interrupções
pelo hardware, 8 portas capazes de conversão de analógico para digital (10 bits), números
de vı́rgula flutuante de 32bits e números inteiros até 32bits.
A placa H4090(figura 3.11) actua como uma motherboard e contém alguns controladores na placa como USB, Ethernet, série e leitor de cartões SD e a H6042 actua como
uma placa de expansão obrigatória que contém o processador e uma FPGA. O processador
tratará do sistema operativo e dos componentes payload e wormhole bridge, enquanto a
FPGA irá tratar do módulo 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̧ão aos controladores
indicados anteriormente, contém múltiplos pinos que permite a comunicação directa para
o CPU ou FPGA. Isso permite que um outro hardware comunique directamente com o
processador ou FPGA sem latências adicionais.
A placa H6042(figura 3.12) contém um processador Arm AT91RM9200 e uma FPGA
Capı́tulo 3. Contexto e enquadramento tecnológico
27
Figura 3.12: H6042
Figura 3.13: Placa D-Link G730ap
Xilink Spartan 3E 500. Adicionalmente contém 32 Megabytes de RAM que pode ser utilizado para guardar informação das aplicações instaladas e 16 Megabytes de flash que
podem ser utilizados para guardar o kernel e sistema de ficheiro quando o desenvolvimento do robô terminar.
Componentes adicionais
Adicionalmente as placas referidas anteriormente está disponı́vel outra placa, a D-Link
G730ap(figura 3.13). Esta placa é necessária porque a placa H4090 não tem um controlador sem fios.
Para alimentar todos estes componentes são necessárias pelo menos cinco baterias de
6 Volts(figura 3.14) cada (vinte cinco pilhas de 1.2 Volts ligadas em série em grupos de
cinco). A distribuição 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 acelerómetro e giroscópio, 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 tensão permite a tensão pretendida e permite alimentar
vários sensores.
Capı́tulo 3. Contexto e enquadramento tecnológico
28
Figura 3.14: baterias de 6 Volts
Figura 3.15: Esquema do circuito eléctrico
Para mitigar a desorganização resultante de ligar vários sensores a uma placa foram
adicionados ligadores de forma a centrar todas as ligações de um certo tipo (terra, 5Volts,
3,3Volts). Uma imagem representativa do circuito está 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 através do regulador de tensão. Ligados a cada ligador estão os
elementos que necessitam daquele tipo de alimentação (5V DC,3.3V DC ou terra).
Capı́tulo 4
Planeamento
Como indicado anteriormente os objectivos deste trabalho são:
• Melhorar os algoritmos do middleware mencionado anteriormente;
• Criar uma camada de sensores e motores que permita a interacção com o wormhole;
• Adaptar o middleware para um robô móvel;
• Validar a propriedade de execução sı́ncrona do wormhole.
Destes objectivos e do contexto em que o robô será utilizado é possı́vel obter um conjunto de requisitos necessários para que estes objectivos sejam alcançados. Esses requisitos são divididos em dois grupos: funcionais e não funcionais. Os requisitos funcionais
são requisitos que definem a função principal do projecto que neste caso é criar um robô
que consegue fazer tarefas de vigilância sobre espaços conhecidos. Os requisitos não funcionais são requisitos que definem a arquitectura do sistema mas não o funcionamento
do mesmo. Estes requisitos normalmente estão englobados nas áreas de performance e
segurança.
4.1
Requisitos Funcionais
Os requisitos funcionais deste projecto são os seguintes:
• Gerir própria posição e posição de obstáculos;
• Navegar por um mapa conhecido;
• Comunicar com outros robôs;
• Reconhecer possı́veis intrusos;
29
Capı́tulo 4. Planeamento
30
O robô tem que inicialmente conseguir gerir a sua posição através de sensores locais
e gerindo a sua posição deve conseguir saber qual a posição dos obstáculos espalhados
pelo mapa. Isto é necessário para que seja possı́vel a realização de tarefas mais complexas
como navegação. Para satisfazer estes requisitos são necessários sensores que indiquem
ou que permitam o cálculo da posição e orientação do robô, como acelerómetros ou giroscópios, e sensores que meçam a distância do robô a um objecto situado na sua proximidade. Com o primeiro requisito indicado pretende-se que o robô seja capaz de, após pelo
menos um movimento, saber quanto é que o mesmo avançou e qual a orientação actual.
Navegar por um mapa conhecido é possı́vel através da utilização de um sistema de posicionamento. A navegação num mapa pressupõe que o robô sabe interpretar esse mapa
e que consegue eficientemente encontrar rotas para os pontos que lhe são indicados. Para
satisfazer esse requisito é necessária uma unidade de processamento, que fica responsável
pelo processamento do mapa e cálculo de rotas, em adição aos sensores indicados no requisito anterior.
A comunicação com outros robôs permite entre outras possibilidades, saber as suas
posições, velocidades e direcções e criar estratégias que permitam à equipa ser mais eficiente. Para que isso seja possı́vel é necessária uma forma de comunicação, com ou sem
fios.
A possibilidade de reconhecer intrusos é uma tarefa necessária no contexto de vigilância de uma área. Para que isso seja possı́veis são necessários que existam sensores
de forma a conseguir identificar o intruso. Uma vez encontrado um intruso o robô pode
comunicar a sua posição a outros robôs. Os sensores de distância com ajuda do mapa
podem detectar possı́veis intrusos. O intruso no contexto do middleware é um objecto
que é detectado por um robô mas não está no mapa.
4.2
Requisitos não Funcionais
Os requisitos não funcionais deste projecto são os seguintes:
• Garantir controlo do robô dentro de um perı́odo de tempo conhecido;
• Cada componente principal deve esta num hardware independente;
• Minimizar o tamanho ocupado em memória pelo wormhole
O wormhole deve ser capaz de garantir o controlo do robô dentro de um perı́odo de
tempo conhecido, ou seja, entre a falta do componente payload e o controlo por parte
Capı́tulo 4. Planeamento
31
do wormhole deve um número máximo de segundos ao fim dos quais sabemos que o
wormhole controla o robô.
Os dois componentes principais, wormhole e payload, devem estar instalados em
hardwares diferentes para que a execução de um não interfira na execução do outro. Se
possı́vel o wormhole deverá estar instalado num hardware dedicado no qual não existam
interrupções assı́ncronas que possam causar atrasos inesperados.
O wormhole é o componente mais confiável deste sistema, logo deve estar presente no
hardware mais fiável que existe disponı́vel. Apesar da fiabilidade do hardware, existem
outras limitações que fazem com que este hardware não possa ser utilizado para qualquer
tarefa. Uma dessas limitações é a memória e o poder computacional disponı́vel. Para
permitir que o wormhole possa ser instalado no microcontrolador é necessário simplificar
o código 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 são presentadas todas as tarefas principais de cada um
dos componentes.
Nas subsecções seguintes são apresentados alguns casos de uso de componente foram
criados ou alterados no âmbito deste projecto.
4.3.1
Controlo do robô pelo componente wormhole
Nome do caso de uso:
• Controlo do robô pelo componente wormhole.
Actores:
• Componente wormhole.
Condição para iniciação:
• Execução periódica.
Pré-condições:
Capı́tulo 4. Planeamento
32
Figura 4.1: Ambiente de trabalho da aplicação ISE Project Navigator
• O componente payload está num estado operacional, recebeu pelo menos uma vez
as coordenadas do robô, o estado do componente payload é desactivado e existe um
destino definido no componente wormhole.
Pós-condições:
• O componente camada de sensores recebeu as novas ordens enviadas pelo componente wormhole.
Caso esperado:
1. O componente wormhole calcula a posição no mapa com base nas coordenadas
disponı́veis.
2. O componente wormhole marca a posição calculada num mapa e considera-a explorada.
3. O componente wormhole procura a melhor direcção para alcançar o destino.
4. O componente wormhole calcula orientação e escolhe velocidade para movimento.
5. O componente wormhole envia a nova ordem criada para o componente camada de
sensores.
Capı́tulo 4. Planeamento
33
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 não consegue encontrar a melhor direcção porque está num
caminho sem saı́da e já explorou as posições que o levaram a este caminho.
1. O componente wormhole procura a última localização em que o robô esteve.
2. O componente wormhole calcula a orientação e escolhe a velocidade para movimento.
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̧ão para iniciação:
• Execução periódica.
Pré-condições:
• O componente wormhole está num estado operacional.
Pós-condições:
• O componente verifica que o payload está a cumprir as promessas enviadas pelo
próprio.
Caso esperado:
1. O componente wormhole verifica se o componente payload ainda está a tempo de
cumprir o prazo de entrega da promessa.
2. O componente payload está a cumprir os prazos.
Capı́tulo 4. Planeamento
34
3. O caso de uso termina.
Casos complementares:
1A: O componente wormhole verifica que o componente payload já devia ter entregado a
nova promessa. Está 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 indicar que perdeu o controlo.
4. O caso de uso termina.
1B: O componente wormhole verifica que o componente payload já 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 não falhou nenhuma vez a
entrega.
5. O caso de uso termina.
4.3.3
Gerir posição através dos sensores locais
Nome do caso de uso:
• Gerir posição através dos sensores locais.
Actores:
• Componente camada de sensores.
Condição para iniciação:
• Execução periódica.
Pré-condições:
• O componente camada de sensores está num estado operacional.
Capı́tulo 4. Planeamento
35
Pós-Condições:
• O componente payload obtém informações sobre a posição, velocidade e orientação
do robô.
Caso esperado:
1. O componente camada de sensores lê os sensores de forma a calcular quanto avançou
desde a última execução.
2. O componente camada de sensores calcula a posição actual, velocidade e orientação
com base nas leituras dos sensores.
3. O componente camada de sensores guarda o valor da posição actual, velocidade e
orientação.
4. O componente wormhole efectua o pedido para obter os valores de posição actual,
velocidade e orientação.
5. O componente camada de sensores envia os valores de posição actual, velocidade e
orientação.
6. O componente wormhole encaminha todos os valores obtido para o payload.
7. O componente payload recebe os valores de posição actual, velocidade e orientação
e processa-os.
8. O caso de uso termina.
4.3.4
Movimento pelo mundo fı́sico
Nome do caso de uso:
• Movimento pelo mundo fı́sico.
Actores:
• Componente camada de sensores.
Condição para iniciação:
• O componente camada de sensores recebeu uma ordem do componente wormhole
para troca de velocidade ou orientação.
Pré-condições:
• A camada de sensores está num estado operacional.
Capı́tulo 4. Planeamento
36
Pós-condições:
• A camada de sensores aplicação sobre os motores a ordem pretendidas.
Caso esperado:
1. A camada de sensores valida os novos valores presentes na ordem enviada.
2. A camada de sensores aplica a ordem enviada.
3. O caso de uso termina.
4.3.5
Detectar Intruso
Nome do caso de uso:
• Detectar Intruso.
Actores:
• Camada de Sensores.
Condição para iniciação:
• Execução periódica.
Pré-condições:
• A camada de sensores está num estado operacional e o robô recebeu informação
num dos sensores disponı́veis que se encontra um objecto nas imediações do robô.
Pós-condições:
• O payload obtém informação dos obstáculos nas imediações do robô.
Caso esperado:
1. O componente camada de sensores obtém o valor de distância do sensor.
2. O componente camada de sensores calcula a posição no mapa do objecto através da
posição actual do robô e orientação.
3. O componente camada de sensores aguarda o valor da posição do obstáculo no
mapa e aguarda que o componente wormhole solicite este valor.
4. O componente wormhole efectua o pedido para obter os obstáculos entretanto detectados.
5. O componente camada de sensores envia os obstáculos detectados.
Capı́tulo 4. Planeamento
37
6. O componente wormhole encaminha a informação dos obstáculos directamente
para o payload.
7. O payload recebe a informação dos obstáculos e processa-a.
8. O caso de uso termina.
4.4
Metodologia de desenvolvimento
A metodologia utilizada para o desenvolvimento deste projecto foi o modelo incremental.
Este método permite o desenvolvimento do projecto em fases em que cada fase é testada
antes de passar para a próxima. A cada iteração é adicionada novas funcionalidades confirme a indicação do cliente e corrigidos erros encontrados nas fases anteriores. Neste
caso o cliente é o orientador e este define a progressão do projecto. Este projecto foi composto por três fases em que a primeira foi uma fase de estudo e preparação do projecto
e cada uma das fases seguintes foi construı́da sobre a anterior. Conforme o projecto vai
avançando novo objectivos secundários tornam-se evidentes e este modelo tem flexibilidade suficiente para permitir alcançá-los.
Na imagem 4.2 podemos observar os vários processos que são necessários para este
modelo. O processo “requisitos” é um processo em que o planeamento é feito. Nesta
fase os requisitos do projecto são levantados. O processo “desenho” é o processo onde
a arquitectura do sistema vai ser definida e todos os artefactos em relação ao projecto
são criados. O processo “implementação” é o processo onde a escrita de código é feita.
O processo “verificação” é o processo onde a depuração do código é feita, assim como
correcção de erros e testes. O processo ”manutenção”é um processo em que ser recebe o
feedback do cliente efectua-se pequenas correcções se necessário.
Como podemos verificar os processos podem ser repetidos até obter a solução pretendida.
Na primeira iteração deste projecto os objectivos eram passar o middleware para o hardware disponı́vel, efectuando as melhorias necessárias e implementar uma interface entre
o middleware existente e os sensores fı́sicos no robô. Para que isso fosse possı́vel é necessário encontrar os requisitos para essa implementação. Um dos requisitos é que o
hardware disponı́vel tem que ser analisado para verificar como o mesmo funciona e ponderar o mapeamento deste novo componente no hardware. Após este passo foi necessário
desenhar módulos que permitissem a comunicação entre o middleware e sensores e definir as mensagens que os mesmos necessitam para comunicar. Apenas depois de definir
módulos e mensagens necessárias é que foi possı́vel implementar os módulos. Quando
a implementação estiver concluı́da é necessário testar os módulos de forma a encontrar
Capı́tulo 4. Planeamento
Figura 4.2: Metodologia de desenvolvimento iterativo e incremental
38
Capı́tulo 4. Planeamento
39
erros. No processo de avaliação é avaliado se os objectivos são cumpridos. Com esta
iteração foi criada o componente camada de sensores (Sensor Layer) e as respectivas
interfaces necessárias para que o middleware pudesse comunicar com este novo componente.
Na segunda iteração o objectivo era portar um dos componentes do middleware para
um hardware separado. Para que isso fosse possı́vel um levantamento da memória e
espaço utilizado pelo código era necessário. Após este passo foi necessário analisar os
módulos a serem portados de forma a verificar alterações necessárias para que os mesmos
pudessem funcionar correctamente no novo hardware, incluı́do alterações as mensagens
trocadas pelos módulos. Na implementação foi portado todo o código do componente
para o novo hardware. Após esta fase é necessário testar os módulos de forma a verificar se o funcionamento do middleware não tinha sido comprometido com esta alteração.
Nesta iteração avaliamos o comportamento da solução fase a solução criada na primeira
iteração. Com esta iteração foi portado o componente wormhole para o hardware Atom
pro 28 e criado um novo componente de ligação wormhole bridge que permite a transparência na comunicação entre os componente wormhole e payload em hardwares diferentes.
Na terceira iteração o objectivo era portar um dos módulos do wormhole para um
hardware separado. Para que isso fosse possı́vel um levantamento da memória e espaço
utilizado pelo código era necessário. Após este passo foi necessário analisar o módulo a
ser portado e as alterações necessárias nos módulos dependentes deste. Adicionalmente
as mensagens passadas entre os módulos foram revistas. A implementação foi efectuada
no hardware como planeado. Na fase de testes foi testada a precisão do temporizador,
assim como erros no código. Na fase de avaliação foi verificado o tempo que o wormhole
demora a iterar. Com esta iteração foi portado o módulo TTFD Task do wormhole para o
hardware FPGA Spartan disponı́vel e foram criadas novas mensagens para possibilitar a
comunicação entre wormhole e este módulo.
Capı́tulo 5
Arquitectura do Sistema
A figura 5.1 apresenta a arquitectura final do sistema. Este sistema é composto pelo
middleware adaptado para um robô móvel fı́sico.
Como é possı́vel observar, o middleware está dividido em três componentes principais:
o payload, o wormhole bridge e o wormhole. Estes três componentes estão mapeados em
hardwares diferentes: o ARMv6 e o Atom pro 28. Adicionalmente existe um módulo que
se destaca, TTFD task, que está instalado numa FPGA Spartan 3E.
Esta figura também apresenta os tipos de interface utilizados entre os vários componentes e módulos. Como é possı́vel verificar, o payload e o wormhole bridge comunicam
entre si através de interface socket, enquanto o wormhole bridge e wormhole comunicam através de interface série. O módulo TTFD Task comunica com o wormhole bridge
através de memória partilhada e com o wormhole através de pinos (ligação directa).
Os componentes e respectivos módulos criados ou alterados no contexto do projecto
são apresentados nas próximas secções.
5.1
Payload
O payload tem como objectivo principal o controlo do robô e pode comunicar com outros
robôs de forma a obter informação sobre a posição e possı́veis intrusos.
Este componente é executado pelo wormhole bridge e recebe o mapa da localização e
respectivos parâmetros, os endereços de todos os outros robôs móveis. Os parâmetros do
mapa são tamanho das células e tamanho do mapa. Assim que o payload inicia começa a
tentar controlar o robô.
O hardware em que este componente está instalado, Armv6, é o hardware existente
mais poderoso ao dispor deste projecto, logo o componente que requer mais poder de
41
Capı́tulo 5. Arquitectura do Sistema
Figura 5.1: Arquitectura final do sistema.
42
Capı́tulo 5. Arquitectura do Sistema
43
processamento e memória deve ser alocado a este hardware. Para utilizar este hardware
foi necessário instalar um sistema operativo. O sistema operativo permite a facilidade de
execução paralela o que permite a execução de várias aplicações em simultâneo embora
devido a esse facto qualquer processo, incluindo o componente payload, pode ser interrompido assincronamente não sendo possı́vel dar garantias temporais fidedignas.
Este componente não será melhorado neste projecto visto os algoritmos do qual é
composto desempenharem as respectivas funções a um nı́vel satisfatório.
Na próxima subsecção são apresentadas as mensagens que este componente gera e
que são utilizadas no contexto deste projecto.
5.1.1
Mensagens
Este componente é responsável pelo envio de mensagens do tipo “promessa”. Esta mensagem, como indicado anteriormente, é utilizada para comunicar ao wormhole a nova
velocidade, orientação e destino do robô. Adicionalmente a mensagem contém um prazo
para entrega da próxima mensagem do tipo “promessa”. Esse prazo é gerado pelo payload e deve ter em consideração o tempo que o mesmo demora a gerar uma resposta.
Este componente pode a qualquer altura tentar controlar o robô enviando uma mensagem do tipo promessa para o wormhole. Regularmente este componente recebe do
wormhole, mensagens que indicam qual a posição, orientação e velocidade actual do robô.
Através destes dados o payload constrói a próxima mensagem do tipo promessa.
5.2
Wormhole Bridge
O wormhole bridge tem como objectivo principal encaminhar mensagens que vêm de
hardwares diferentes e permitir que o wormhole continue a controlar o payload apesar
que estar num hardware diferente. O controlo do payload por parte do wormhole resumese à aplicação de penalidades quando o payload não cumpre a promessa, o que inclui o
reiniciar do componente payload. Essa função deixa de ser possı́vel directamente com a
alteração do hardware pelo wormhole, logo o componente wormhole bridge passa a reiniciar o payload quando o wormhole pedir (via mensagem).
Este componente foi criado aquando o porte do wormhole para um hardware diferente do componente payload de forma a permitir que os dois componentes continuassem
a comunicar e que as funções do componente wormhole não fossem comprometidas pela
Capı́tulo 5. Arquitectura do Sistema
44
Figura 5.2: Arquitectura do componente wormhole bridge.
alteração de hardware. Todas as mensagens enviadas pelo wormhole são recebidas pelo
wormhole bridge que as encaminha para o payload e todas as mensagens enviadas pelo
payload são recebidas pelo wormhole bridge e encaminhadas para o wormhole.
O wormhole bridge é o primeiro componente do sistema a ser executado recebendo
o mapa da localização e respectivos parâmetros, os endereços de todos os outros robôs
móveis. Após estar iniciado, este componente inicia o wormhole, enviando uma cópia
do mapa e dos seus parâmetros (tamanho, tamanho das células), a posição e orientação
inicial. Depois de iniciar o wormhole este componente inicia o payload enviando uma
cópia do mapa e dos seus parâmetros. No fim dos dois componentes (wormhole e payload) estarem iniciados, o wormhole fica à espera de mensagens.
O wormhole bridge foi instalado no hardware “H6042” de forma a permitir a continuação
do controlo do componente payload pelo componente wormhole e permitir que a transição
de mensagens entre as diferentes interfaces seja transparente tanto para o wormhole como
para o payload.
Nas próximas subsecções são apresentados os módulos que compõem este componente e as mensagens trocadas pelo mesmo.
5.2.1
Módulos
A figura 5.2 apresenta a arquitectura do componente wormhole bridge.
Como é possı́vel observar, os módulos que integram este componente são:
• Payload Listener, que tem como objectivo receber as mensagens do payload e
Capı́tulo 5. Arquitectura do Sistema
45
envia-las para o wormhole e tem a responsabilidade de reiniciar o componente payload quando o mesmo é pedido pelo wormhole;
• Wormhole Listener, que tem como objectivo receber as mensagens do wormhole e
envia-las para o payload e encaminhar o prazo da promessa para o módulo TTFD
Task.
O módulo payload listener é um módulo existente que apenas recebe a mensagem do
tipo promessa. Este módulo sofreu pequenas alterações para permitir o encaminhamento
de mensagens, vindas de interface socket, para interface série e para permitir comunicação
com o módulo TTFD task no hardware H6042.
O módulo wormhole listener é um módulo criado que encaminha todas as mensagens
enviadas pelo wormhole.
5.2.2
Mensagens
Este módulo utiliza as todas mensagens apresentadas no payload e wormhole com adição
de uma outra que é utilizada para comunicar com o módulo TTFD task o novo prazo na
promessa enviada pelo payload.
5.3
Wormhole
O wormhole tem como objectivo principal o controlo do cumprimento de promessas por
parte do payload e pode controlar o robô quando necessário. Adicionalmente o wormhole
gere a posição do robô e detecta intrusos utilizando sensores locais (sensores de distância,
acelerómetro e giroscópio).
Devido ao componente inicialmente ser construı́do em linguagem C, o mesmo foi
inicialmente instalado no hardware H6042. Devido ao requisito que indicava a necessidade dos componentes principais, wormhole e payload, terem que passar para hardwares
diferentes, o wormhole passou para o hardware ”Atom pro 28”. Com este porte foi necessário criar o componente wormhole bridge para existir continuação de comunicação
entre as duas componentes, wormhole e payload, apesar de estarem em hardwares diferentes.
O wormhole é executado pelo wormhole bridge recebendo o mapa e respectivos parâmetros
(tamanho do mapa e das células que o compõem), a posição e orientação inicial. Após
iniciar, este componente aguarda por uma mensagem do tipo promessa para dar inı́cio ao
Capı́tulo 5. Arquitectura do Sistema
46
Figura 5.3: Ciclo de controlo do componente wormhole.
ciclo de controlo que permitirá o controlo do tempo do componente payload, gestão de
posição e detecção de intrusos utilizando sensores locais.
Nas próximas subsecções são apresentados componentes, módulos e mensagens que
foram criadas no porte deste componente para o novo hardware.
5.3.1
Módulos
Após a migração do wormhole para o microcontrolador, um novo ciclo de controlo foi
criado. A imagem 5.3 apresenta o ciclo de controlo final criado após a junção do componente wormhole com a camada de sensores.
Como é possı́vel observar, o ciclo de controlo é constituı́do por vários módulos, cada
um com uma função necessária para o robô. Os módulos são os seguintes:
• módulo sensor calibration, que é apenas executado quando o sistema é iniciado e
depois de executado o ciclo de controlo começa;
• módulo payload listener, que recebe as mensagens do payload e processa-as se
necessário. O módulo position updater actualiza a posição, velocidade e orientação
actual utilizando os sensores locais.
• módulo obstacle updater, que verifica se existe algum obstáculo nas proximidades
do robô e se existir reporta esse facto ao payload.
• módulo TTFD task listener, recebe mensagens do módulo TTFD task de forma a
verificar se o payload está a cumprir as promessas.
Capı́tulo 5. Arquitectura do Sistema
47
• módulo status sender, envia o estado do robô para o payload. Esse estado é composto por posição, velocidade e orientação.
• módulo safety task controla o robô caso o payload não cumpra com a promessa.
• módulos velocity observer e orientation observer monitorizam a velocidade e orientação
para verificar se o robô está a deslocar-se à velocidade correcta e se a orientação é
a correcta. Estes módulos efectuam também pequenos ajustes para garantir que o
robô esta a movimentar-se correctamente.
Como o wormhole passou para o microcontrolador, ele perdeu a capacidade de reiniciar o componente payload que ficou num hardware diferente. Para ser possı́vel manter
esta funcionalidade foi necessário criar um novo componente no mesmo hardware em
que está o componente payload. Esse novo componente, wormhole bridge, tem como
objectivo permitir ao componente wormhole o reinı́cio do componente payload e tratar de
todo o trabalho de adaptação das mensagens de um hardware para outro.
Adicionalmente para ser possı́vel passar o módulo TTFD task para a FPGA, algumas
alterações tiveram que ser feitas ao wormhole. O wormhole deixou de ter o componente
de controlo de tempo da TTFD task e passa a ter apenas a aplicação de penalidades ao
payload por incumprimento de prazos. O módulo TTFD task na FPGA deve ser capaz de
indicar ao wormhole quem tem, num determinado momento, controlo sobre o robô.
Safety Task
Anteriormente foi identificado que seriam necessários melhoramentos para aumentar a
eficiência do robô no ambiente fı́sico. O algoritmo a ser melhorado é o algoritmo do
módulo safety task, que é um módulo do componente wormhole.
O módulo safety task é responsável pelo controlo do robô quando o payload demora
demasiado tempo a cumprir a promessa. Este módulo tem que ser simples, rápido e determinı́stico por causa dos requisitos temporais do wormhole. Esses requisitos temporais
determinam que o wormhole deve ter um tempo máximo conhecido de iteração para que
seja possı́vel garantir que dentro desse valor de tempo, o wormhole garantirá o controlo do
robô. O módulo safety task requer um mapa de forma a aplicar o algoritmo de procura de
caminho. O mapa utilizado é um array bidimensional composto por células. Cada célula
pode representar uma parede ou um possı́vel caminho. A implementação original definia
que o robô se deslocaria na direcção que permitisse ficar mais perto do destino. Com
esta definição é possı́vel resolver mapas simples mas mapas mais complexos que contém
caminhos sem saı́da podem fazer com que o robô não consiga chegar ao destino. Para
melhorar este algoritmo tivemos que adicionar memória do caminho utilizado pelo robô
para que em caso de encontrar um beco sem saı́da o robô possa retroceder pelo caminho
que utilizou e escolher outro. Para isso foi necessário criar um novo tipo de célula, que é
Capı́tulo 5. Arquitectura do Sistema
48
Figura 5.4: Fluxograma do processo de decisão do novo passo do módulo “safety task”.
a célula explorada, para evitar que o robô visite as células que já explorou.
A figura 5.4 apresenta o processo de procura de caminhos após a introdução da
memória dos caminhos utilizados.
Este fluxograma apresenta os passos efectuados pelo algoritmo quando é necessário
calcular um novo passo. Um passo é uma localização intermédia no mapa que leva o robô
para mais perto do destino. O algoritmo começa por localizar o robô no mapa, calculando
a posição no mapa através da posição no mundo e das dimensões da célula. Após obter
a localização no mapa, essa posição é marcada como explorada. A partir deste último
passo é possı́vel começar à procura da melhor direcção para continuar. A melhor direcção
Capı́tulo 5. Arquitectura do Sistema
49
é calculada simulando o movimento de uma unidade no mapa para cada uma das posições
principais (cima, esquerda, direita, baixo) e verificando qual destes movimentos é o que
leva o robô mais perto do destino. Adicionalmente é preciso que a posição testada não
tenha sido explorada. Caso não seja encontrada a melhor direcção, o robô chegou a um
beco sem saı́da. Caso seja encontrada a melhor direcção é calculada a distância até ao
destino e se o robô estiver perto do mesmo, o robô pára. Caso o robô não esteja perto do
destino, as novas ordem são enviadas para os motores.
TTFD Task
O módulo TTFD task tem como principal função o controlo do cumprimento dos prazos
por parte do payload. Se o payload continuadamente cumprir os prazos, o mesmo poderá efectuar o controlo do robô mas se não for esse o caso o robô passa a ser controlado
pelo wormhole enquanto o payload não conseguir cumprir promessas podendo ocorrer
situações em que o wormhole reinicie o componente wormhole por um número de falhas
elevadas ou por não comunicar durante um espaço predefinido de tempo.
Este módulo faz parte do wormhole e está instalado na FPGA. O hardware ”FPGA
Spartan 3e”foi escolhido para suportar este módulo devido ao facto de o mesmo ser dedicado, ou seja, apenas executa a configuração criada e não tem outras aplicações/serviços
a serem executados concorrentemente. Adicionalmente este hardware tem um poder de
processamento superior e permite uma unidade de tempo menos significante do que a permitida pelo Atom pro 28.
5.3.2
Mensagens
Para que o componente wormhole possa comunicar com os vários componentes e módulos
disponı́veis, são necessárias mensagens para envio de valores que o wormhole gera ou
adquire e para recepção de valores necessários para o funcionamento do wormhole. O
wormhole é capaz de funcionar correctamente sem o payload mas apenas garante serviços
básicos de navegação sendo necessário receber informações do payload para que ter um
navegação eficiente.
A lista seguinte apresenta todas as mensagens necessárias ao sistema:
• Uma mensagem enviada pelo payload para o wormhole com destino, velocidade,
orientação e prazo para próxima entrega (tipo promessa);
• Uma mensagem enviada pelo wormhole para o payload com localização de um
obstáculo (tipo obstáculo);
Capı́tulo 5. Arquitectura do Sistema
50
Figura 5.5: Cenário tı́pico de comunicação aquando o envio da mensagem do tipo promessa pelo componente payload.
• Uma mensagem enviada pelo wormhole para o payload com localização do robô,
velocidade e orientação (tipo estado);
• Uma mensagem enviada pelo wormhole para o payload a informar uma troca no
controlo do robô (tipo controlo);
• Uma mensagem enviada pelo wormhole para o wormhole bridge para pedir o reinı́cio
do componente payload (tipo reiniciar);
• Uma mensagem enviada pelo wormhole bridge para a TTFD task com o prazo da
próxima entrega (tipo novo prazo);
• Uma mensagem enviada da TTFD Task para o wormhole a indicar quem tem o
controlo (tipo controlo FPGA).
A Figura 5.5 apresenta um tı́pico cenário de comunicação e mostra como a informação
e mensagens fluem entre os componentes e módulos. Os números representam a ordem
das mensagens ou dados.
Neste cenário o payload começa por enviar uma promessa para o wormhole bridge.
Depois de chegar ao wormhole bridge uma mensagem com o novo prazo é enviada para
a TTFD task.
Se a mensagem chegar antes de terminar o prazo anterior, então o TTFD task envia informação para o wormhole a indicar que o controlo continua a ser do payload.
Senão a mensagem enviada indica que o wormhole ganhou controlo. Se o controlo for do
wormhole e o payload conseguir cumprir uma promessa, a mensagem enviada indica que
Capı́tulo 5. Arquitectura do Sistema
51
o payload ganhou o controlo.
Entretanto os restantes valores de posição, velocidade e orientação são enviados para o
wormhole. Se existiu alguma troca de estado o wormhole deve enviar uma mensagem para
o wormhole bridge a indicar que o componente responsável pelo controlo do robô mudou
e o wormhole bridge deve depois encaminha-la para o payload. Senão esta interacção
termina. Podemos concluir que as mensagens 5 e 6 apenas existem se existir uma troca
de controlo durante esta interacção.
5.3.3
Sensor Layer
O componente sensor layer (camada de sensores) interage com os sensores e motores de
forma a permitir que os outros componentes (wormhole e payload) possam controlar o
robô. A implementação da camada de sensores no microcontrolador pretende substituir
a camada de sensores assegurada pelo Simbad. Este componente foi implementado no
hardware Atom pro 28 porque todos os sensores e motores estão ligados a este hardware.
Para alcançar este objectivo é necessário fazer um levantamento do material que está
disponı́vel, decidir que material é necessário adquirir e finalmente efectuar o desenho da
camada de sensores e motores. Os materiais disponı́veis são sensores de distância que permitem medir a distância ao objecto mais próximo. O material indisponı́vel e necessário
de adquirir é um acelerómetro e um giroscópio. O acelerómetro deverá permitir calcular a
posição através da aceleração que fornece enquanto o giroscópio deverá permitir calcular
a direcção a partir da velocidade angular que fornece. A camada de sensores deve ser
capaz de comunicar com outros componentes, neste caso o wormhole, de forma a receber
ordens para os motores e enviar leituras dos sensores.
Nas subsecções seguintes são apresentados nos módulos criados para estes componentes e as mensagens criadas para comunicação entre a camada de sensores e o wormhole
(que ainda estava no mesmo hardware que o payload).
Módulos
A FIGURA 5.6 apresenta o conjunto de módulos que constituem a arquitectura do componente camada de sensores e define o ciclo da camada de sensores através das setas que
representam a sequência de execução dos módulos.
O módulo sensor calibration é executado apenas uma vez no inı́cio da execução e
é responsável por encontrar o zero dos sensores. O zero dos sensores é o valor que os
Capı́tulo 5. Arquitectura do Sistema
52
Figura 5.6: Arquitectura do componente “sensor layer”.
mesmos têm quando o robô está parado.
O módulo wormhole listener tem como objectivo receber os pedidos do wormhole,
processa-los e enviar respectivas respostas. Pretende-se que este módulo apenas efectue
trabalho quando receber algo do wormhole, ou seja, utilizar uma metodologia reactiva.
O módulo velocity observer tem como objectivo observar e corrigir a velocidade se
necessário. Este módulo deve ser apenas executado se o robô estiver a efectuar um movimento rectilı́neo.
O módulo orientation observer tem como objectivo observar a orientação actual do
robô e parar quando o robô chegar a orientação desejada. Este módulo deve ser apenas
executado se o robô estiver a efectuar um movimento de rotação.
Adicionalmente aos módulos que foram criados na camada de sensores, o wormhole
tem que receber um novo módulo que permita a comunicação com a camada de sensores.
Esse módulo chama-se sensor layer interface e deverá permitir a comunicação sem atrasos do wormhole.
Posteriormente estes módulos passaram para o wormhole sendo que três (sensor calibration, velocity observer, orientation observer) passaram intocados para o wormhole
enquanto o wormhole listener foi dividido em vários módulos (payload updater, position
updater, obstacle updater e position sender).
Mensagens
Como a camada de sensores tem que conseguir interagir com o wormhole, é necessário
definir mensagens que os dois componentes trocam entre si. As mensagens que são ne-
Capı́tulo 5. Arquitectura do Sistema
53
cessárias para a interacção são as seguintes:
• Mensagem para o componente wormhole indicar o novo valor de velocidade;
• Mensagem para o componente wormhole indicar o novo valor de orientação;
• Mensagem para o componente wormhole pedir obstáculos nas imediações;
• Mensagem para o componente wormhole pedir o estado do robô (posição, orientação,
velocidade);
• Mensagem para o componente sensor layer indicar os obstáculos que encontrou;
• Mensagem para o componente sensor layer de sensores indicar o estado do robô.
Com estas mensagens é possı́vel controlar o robô e obter informações dos sensores.
Para controlo de posições, a camada de sensores tem que ter disponı́vel uma forma de
controlar o tempo para proceder aos cálculos de distância, orientação e velocidade.
Visto a implementação do controlo da interface série ser por software, o microcontrolador
não consegue fazer outras tarefas enquanto esta a enviar ou receber através da interface
série. Logo cada vez que é enviada alguma informação, o microcontrolador tem que ficar
à escuta na porta série senão essa informação é perdida. Para promover um ambiente multitarefa foi adicionado ao protocolo as mensagens RTS/CTS. Estas mensagens permitem
a negociação do envio de mensagens do wormhole para a camada de sensores, enviando
primeiro uma mensagem do tipo RTS, depois aguardando receber uma mensagem do tipo
CTS antes de enviar a mensagem pretendida. Isto permite que exista menos desperdı́cio
de dados porque esta a ser enviada uma pequena mensagem para sinalizar o envio em vez
de enviar a mensagem pretendida que supostamente é muito maior e não existe garantia
que a mesma seja recebida.
O microcontrolador para receber informação pela interface série necessita de saber
exactamente o que vai receber visto não existir métodos que possibilitem a conversão
entre os diferentes tipos de dados disponibilizados pelo microcontrolador. Para isso foi
criado 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 conteúdo da mensagem.
A figura 5.7 apresenta o fluxograma que representa o funcionamento do módulo wormhole
listener criado no componente camada de sensores.
Como podemos observar este processo começa por ler dados da porta série, procurando uma mensagem RTS. Quanto este obtém essa mensagem, o mesmo envia imediatamente uma mensagem do tipo CTS e aguarda a mensagem que vai indicar qual o tipo de
mensagem que se pretende enviar. A partir desse passo o conteúdo de cada pedido pode
Capı́tulo 5. Arquitectura do Sistema
Figura 5.7: Arquitectura do módulo “wormhole listener”.
54
Capı́tulo 5. Arquitectura do Sistema
55
Figura 5.8: Arquitectura do módulo sensor layer listener.
ser enviado utilizando de novo o mecanismo RTS e CTS.
Para ser possı́vel comunicar com o novo componente camada de sensores foi necessário criar um módulo do lado do componente wormhole. Esse módulo tem com objectivo permitir a comunicação com o componente camada de sensores assim como mitigar
o possı́vel atraso adicional resultante do processo de negociação. A figura 5.8 apresenta
o algoritmo utilizado na implementação do módulo para comunicar com o componente
camada de sensores.
Podemos observar que o algoritmo começa por configurar a porta série, para depois
passar para o ciclo principal. No ciclo principal, é primeiro verificado se existem mensagens na lista de mensagens para envio e se existir é primeiro enviado uma mensagem RTS
e só depois de receber uma mensagem do tipo CTS é que a mensagem obtida da lista é
enviada. Depois desse processo é removida a mensagem enviada da lista. Posteriormente
ou se não existirem mensagens na lista a enviar, o módulo tenta verificar a existência
de novas mensagens a receber e todo o processo descrito anteriormente repete-se com
excepção da configuração da interface série.
Capı́tulo 5. Arquitectura do Sistema
56
Figura 5.9: Sequência de eventos aquando o envio da mensagem promessa.
A figura 5.9 apresenta a sequência de eventos aquando o envio, por parte do payload, de
uma mensagem do tipo promessa.
Como podemos verificar a mensagem é primeiro enviada pelo payload para o wormhole.
A mensagem é recebida e tratada pelo payload interface e depois segue para o novo
módulo, sensor layer interface, para ser convertida a enviada para o componente camada
de sensores.
Capı́tulo 6
Implementação
Nas próximas subsecções é apresentado todo o trabalho de implementação. A implementação
da solução foi feita em três iterações, cada uma construı́da sobre a iteração anterior. Em
cada uma das iterações são desenvolvidas determinadas tarefas que permitem o avanço
do projecto em direcção ao objectivo final apresentado no capı́tulo “Arquitectura do Sistema”.
Na fase de implementação as seguintes tarefas foram efectuadas:
• 1ª Iteração
– Levantamento do hardware disponı́vel e estudo do hardware necessário;
– Preparar o hardware, que passa por soldar sensores e instalar software;
– Melhorar o módulo safety task;
– Portar o middleware para a placa com o ARM;
– Implementar a camada de sensores e a interface entre camada de sensores e
wormhole.
• 2ª Iteração
– Implementar o wormhole no microcontrolador;
– Implementar o wormhole bridge na placa H6042.
• 3ª Iteração
– Implementar a TTFD task na FPGA.
No final de cada iteração existe uma secção onde o mapeamento dos componentes no
hardware após essa iteração é apresentado e conclusões são tiradas.
57
Capı́tulo 6. Implementação
6.1
58
1ª Iteração
Na primeira iteração pretende-se analisar todo o hardware necessário que ainda não foi
adquirido. Depois disso é necessário preparar todo o hardware para as funções que o
mesmo vai efectuar. Finalmente pretende-se melhorar o algoritmo mencionado anteriormente assim com implementar a camada de sensores e o interface no wormhole com a
mesma. Nas subsecções seguintes são apresentados os seguintes tópicos:
• Hardware, nesta subsecção é apresentado o hardware que foi adquirido desde o
inı́cio do projecto;
• Preparação do Hardware, nesta subsecção é apresentado o trabalho necessário para
instalação de sistemas operativos, IDEs e configuração de placas;
• Implementação da camada de sensores, nesta subsecção são apresentados os detalhes da implementação feita para a camada de sensores;
• Implementação da interface com a camada de sensores, nesta subsecção é apresentado o módulo criado no wormhole que permite a interacção entre o último e a
camada de sensores.
6.1.1
Hardware
O hardware adquirido posteriormente ao inı́cio do projecto é apresentado nas próximas
subsecções. De todo o hardware actualmente existente, apenas uma pequena foi adquirida
posterior ao inı́cio do projecto e para esse hardware é apresentado um pequeno estudo de
soluções disponı́veis.
Acelerómetro e Giroscópio
Visto existir necessidade de gerir a posição com sensores locais, foi necessário adquirir
um acelerómetro e um giroscópio. Os dois equipamentos necessitam de fornecer apenas
uma dimensão de medidas, ou seja, pretendemos saber a aceleração num eixo e a velocidade angular do robot segundo o plano xy. Os acelerómetros ponderados foram os
seguintes: IDG500; ADXL335; ADXL345. As principais caracterı́sticas são apresentadas na tabela 6.1. Os preços apresentados são uma média de três lojas que os vendiam
(LusoRobótica, Sparkfun e Robotshop).
Quanto aos giroscópios, foram ponderados os seguintes: LPR530AL, LISY300AL,
IDG-500. Novamente as principais caracterı́sticas são apresentadas na tabela 6.2. Os
59
Capı́tulo 6. Implementação
Nome do chip Intensidade de corrente Medida máxima Preço médio
ADXL335
350uA
+-3G
23,23C
MMA7260Q
500uA
+-6G
15,23C
ADXL345
40uA
+-16G
28,18C
Tabela 6.1: Análise de acelerómetros com base nas suas caracterı́sticas principais
Nome do chip Intensidade de corrente Medida Máxima
LPR530AL
6.8mA
300º/s
LISY300AL
4.8mA
300º/s
IDG-500
100uA
300º/s
Eixos
Preço médio
pitch,roll
28,87C
yaw
22,01C
x,y
37,46C
Tabela 6.2: Análise de osciloscópios com base nas suas caracterı́sticas principais
preços apresentados são uma média de três lojas que os vendiam (LusoRobótica, Sparkfun e Robotshop).
Os requisitos definidos para o acelerómetro é de ter pelo menos um eixo e ser capaz
de medir pelo menos 1g. Os requisitos definidos para o giroscópio são de conseguir medir
pelo menos 180º/s.
Para cada um dos sensores necessário foi procurado o chip que efectua a função do
sensor e depois disso verificou-se a oferta disponı́vel. Dessa oferta disponı́vel adquirimos o acelerómetro ADXL335 e o giroscópio LISY300AL(figura 6.1) por estar dentro
dos requisitos que necessitávamos e por existir uma placa com os dois sensores. O preço
também foi um importante factor.
Tanto o acelerómetro como o giroscópio são ambos analógicos, ou seja, os valores que
os mesmos retornam compreendem-se num intervalo de tensão conhecido. Para que esse
intervalo de tensão possa ser interpretado, este valor tem que ser lido de uma forma que
o microcontrolador consiga interpretar. Para isso o microcontrolador disponibiliza alguns
conversores de sinal analógico para digital, que permitem converter uma tensão de 0 a 5
Volts para valores entre 0 e 1023, em que 0 é igual a 0 Volts e 1023 é igual a 5 volts. Com
isto podemos calcular que a resolução mı́nima possı́vel é 4,883 milivolts. Adicionalmente
Figura 6.1: ADXL335 e LISY300AL
Capı́tulo 6. Implementação
60
os próprios sensores podem produzir leituras incorrectas. Para mitigar estas situações, o
cálculo de média foi adicionado de forma a mitigar a degradação dos valores de posição e
velocidade através de leitura incorrectas de aceleração. Adicionalmente foi utilizada uma
técnica para mitigar ainda mais este problema, chamada zero velocity update, que consiste
na paragem propositada do robô de forma a colocar o valor de velocidade a zero e mitigar
ainda mais a acumulação de erros no valor de posição.
6.1.2
Preparação do hardware
Nas próximas subsecções são apresentados todos os passos necessários para ser possı́vel
utilizar os diferentes hardwares disponı́veis. Apenas num dos hardwares apresentados anteriormente é necessário instalar um sistema operativo para que o mesmo fique num estado
operacional. O restante hardware apenas necessita de ser configurado. Esta configuração
em alguns casos pode ser feita directamente ou pode necessitar que uma aplicação seja
instalada num PC.
H6042
De forma a utilizar a placa H6042, um sistema operativo tem que ser instalado. Para isso
um kernel de Linux foi compilado e um sistema de ficheiros foi construı́do de forma a levar a placa para um estado operacional. O sistema de ficheiros inicial contém uma versão
de busybox, que é constituı́da por versões optimizadas para dispositivos com pouco recursos dos utilitários básicos de Linux como o ls e ps. Para que seja possı́vel carregar
um sistema operativo, a placa H6042 tem pré-instalado um bootloader que permite ao
utilizador o carregamento do kernel e sistema de ficheiros de diferentes formas. Neste
caso foi configurado um servidor TFTP numa máquina em Linux com o ficheiro do kernel e do sistema de ficheiros. O H6042 foi configurado no bootloader para efectuar o
descarregamento dos dois ficheiros e carregá-los para a memória executando de seguida
o kernel. Com isto a placa inicia o Linux e fica num estado operacional. A partir deste
passo é possı́vel ligar a um servidor de SSH que vem com a imagem do sistema de ficheiros e descarregar os ficheiros do middleware que entretanto foram colocados no servidor
TFTP. A placa H6042 tem uma flash de 16 Megabytes que contém inicialmente o Uboot
e pode ser utilizada para guardar permanentemente o kernel e sistema de ficheiros. Devido ao facto de durante os testes a imagem do sistema de ficheiros estar sempre a ser
alterada para acomodar novas programas/scripts e de forma a optimizar e automatizar o
procedimento indicado anteriormente, foi configurado o bootloader para automaticamente
ao ser carregado, tentar o acesso ao servidor TFTP configurado num IP especı́fico, efectuar o descarregamento do kernel e sistema de ficheiros carregando-os para a memória
Capı́tulo 6. Implementação
61
e finalmente executando-os. A nı́vel do sistema operativo, o mesmo também foi optimizado de forma a permitir a automatização do descarregamento, mudança de permissões e
execução dos ficheiros necessário para o middleware. Para isso foram criados scripts que
efectuam essas tarefas automaticamente através da utilização dos comandos tftp e chmod.
O script que automatiza este processo é executado automaticamente pelo sistema operativo a quando o carregamento do mesmo.
Os manuais em [20] e [21] apresentam configurações informações sobre as placas que
auxiliaram na preparação deste hardware.
Atom Pro 28-M
De forma a utilizar o Atom Pro 28-M, o mesmo tem que ser programado directamente
por um programa. O programa é o Basic Micro Studio e permite a programação em três
linguagens (Basic, C++, ou Assembler ).
Para ser possı́vel escolher uma linguagem foi necessário analisar documentação disponı́vel, exemplos disponı́veis e fóruns de discussão. Para cada uma das linguagens foi
verificada toda a informação disponı́vel sobre a mesma e chegou-se as seguintes conclusões:
• Basic, é a linguagem mais simples de usar, sobre a qual existem mais exemplos
mas é também a que menos funcionalidades tem. As funcionalidades em falta em
relação às outras linguagens são gestão dinâmica de memória, threads e algumas
funções matemáticas.
• C++, é a linguagem relativamente fácil de se usar e é orientada a objectos mas sobre
a mesma não existe documentação disponı́vel nem existem exemplos da utilização.
• Assembler, é a linguagem mais difı́cil de utilizar deste conjunto mas é também que
oferece um menor overhead já que as outras duas linguagens são convertidas para
assembler antes de passarem para o microcontrolador. Esta linguagem tem poucos
exemplos e operações simples têm tendência a demorar muito a serem programadas
para além de existir uma probabilidade maior de ocorrência de erros.
A linguagem escolhida para a implementação dos vários módulos foi Basic visto existir vários exemplos ([22]) e manuais [23] que explicam em detalhe cada uma das funções
em Basic.
Capı́tulo 6. Implementação
62
Spartan FPGA
Para programar a FPGA é necessário o programa Xilinx ISE Design Suite. Este programa
permite a programação em duas linguagens (Verilog e VHDL). A linguagem escolhida
para a implementação do módulo TTFD task foi VHDL por existirem alguns exemplos
fornecidos pela Hectronics. Este programa efectua um conjunto extenso de validações,
incluindo tempos que o código demora a ser executado, passando por validação dos recursos usados fase aos existentes e validação dos mapeamentos das portas utilizadas.
D-Link G730ap
Quanto á placa D-Link G730AP, esta apenas necessita de estar ligada ao USB para alimentação
e à porta Ethernet para dados. Esta placa permite a utilização de três modos diferentes,
cada um com a sua configuração. Esses modos são:
• Client, que permite configurar a placa como cliente de um ponto de acesso ou como
rede P2P;
• AP, que permite configurar a placa como um ponto de acesso ao qual outros clientes
podem ligar;
• Router, que permite configurar a placa como ponto de acesso ao qual outros clientes
podem ligar e permite adicionalmente ligar esses clientes a outras redes.
O modo utilizado foi o modo Client porque o mesmo permite que a criação de uma
rede ponto a ponto que em ambientes de incerteza a nı́vel das comunicações é mais eficiente do que o modelo cliente servidor que é disponibilizado pelos modos AP e Router. Isso porque cada nó comunica pode comunicar directamente com o nó final e não
existe um ponto central por onde toda a informação tem que passar. Para configurar é
necessário ligá-la primeiro ao computador e aceder à página de configuração da placa. Na
configuração é apenas necessário ter as seguintes preocupações:
• o nome tem que ser igual em todos os dispositivos configurados, para ser possı́vel
comunicação entre os vários dispositivos;
• o algoritmo de segurança e a chave têm que ser iguais em todos os dispositivos
configurados, caso se opte por utilizar um, que é o caso.
Os passos para efectuar a configuração, tanto da placa como do computador, estão
disponı́veis no Apêndice C.
Capı́tulo 6. Implementação
6.1.3
63
Implementação da camada de sensores
A camada de sensores segue a arquitectura indicada anteriormente (figura 5.6) e é implementada no microcontrolador. Os módulos implementados são (ver figura 5.6):
• Sensor calibration;
• Wormhole interface;
• Velocity observer;
• Orientation observer.
O módulo sensor calibration permite que os sensores analógicos sejam calibrados de
forma a tomar em conta pequenas oscilações no posicionamento do sensor desde a última
execução. Este módulo começa por parar o robô, aguarda que os sensores estejam num
estado operacional e efectua medidas. Este módulo efectua 64 leituras aos sensores e depois efectua uma média para obter o zero dos sensores. O zero dos sensores é o valor que
os mesmos reportam quando o robô está parado.
O módulo wormhole listener recebe e processa mensagens enviadas pela porta série.
Este módulo é o mais importante da camada de sensores pois todas as medidas são feitas
neste módulo usando uma abordagem “a pedido”, ou seja, a camada de sensores só faz
medidas e actualiza o seu estado conforme o wormhole efectua pedidos, isto porque uma
vez que o robô começa a movimentar-se com uma determinada velocidade assume-se que
o mesmo vai continuar até o wormhole indicar o contrário. O mesmo é valido para os
obstáculos logo a camada de sensores apenas tem que enviar resultados quando os mesmos são pedidos. Como explicado anteriormente, este módulo esta preparado para duas
fases de comunicação devido ao facto do microcontrolador ter que saber o que vai receber
antes de receber os dados. Na primeira fase é verificado se o tipo de mensagem é um
tipo esperado. O tipo da mensagem é constituı́do por 3 caracteres seguido de um quarto
carácter que indica que a mensagem terminou. Na segunda fase é recebida a mensagem
cujo tipo foi enviado anteriormente.
Os módulos velocity observer e orientation observer são utilizados para controlar
a orientação e velocidade do robô. Isto é necessário porque ao longo da utilização do
robô, a carga das baterias vai diminuir causando que os comandos para os motores não
respondam com o mesmo comportamento, existindo tendência para que o robô abrande
para o mesmo valor enviado aos motores conforme as baterias descarregam. Adicionalmente estes módulos são necessários porque o microcontrolador apenas consegue executar um módulo de cada vez, sendo necessário verificar periodicamente se o robô chega à
orientação correcta. O algoritmo velocity observer define que se o robô estiver a avançar
Capı́tulo 6. Implementação
64
mais devagar que o ordenado, este acelera e se estiver a avançar demasiado depressa este
desacelera. Este algoritmo tenta garantir uma velocidade constante independente do estado das baterias. O algoritmo orientation observer define que se o robô ainda não estiver
na orientação correcta, este continua o movimento curvilı́neo, se estiver o mesmo para e
continua o movimento rectilı́neo anterior.
Visto o acelerómetro apenas fornecer os valores aceleração e ser necessário ter valores de posição, os últimos têm que ser deduzidos dos valores de aceleração. De forma a
ser possı́vel fazer essa operação, é necessário o tempo em que essa aceleração foi aplicada, logo é recolhida a cada iteração o tempo actual de forma a obter o intervalo. Como
velocidade num determinado intervalo de tempo é igual a aceleração multiplicada pelo
intervalo de tempo em que esta foi aplicada, é possı́vel obter a velocidade de um certo
intervalo de tempo. Para ser possı́vel saber a velocidade actual e não apenas a velocidade
de um perı́odo de tempo é necessário guardar a velocidade de todos os passos anteriores
e somar à velocidade do último passo. O mesmo deve ser aplicado à posição. A distância
percorrida num intervalo de tempo é igual á velocidade multiplicada pelo tempo que a
mesma afectou o robô mais a aceleração multiplicada pelo tempo ao quadrado a dividir
por dois. Com estas fórmulas é possı́vel calcular posição a partir de aceleração.
Quanto ao giroscópio, este fornece a velocidade angular do robô mas interessa apenas o
ângulo actual. O ângulo é igual é velocidade angular a multiplicar pelo tempo em que a
velocidade angular se fez sentir no robô. De forma a calcular o ângulo actual é necessário
guardar os ângulos dos passos anteriores e somar o ângulo do último passo.
Existe uma limitação nas funções de cálculo de seno e co-seno disponı́veis no Basic
Micro Studio. Estas funções são necessárias para o cálculo da aceleração, velocidade e
posição num eixo. Essas funções apenas garantem o cálculo de valores entre -0.5PI e
0.5PI radianos embora exista necessidade de cálculo de valores fora deste intervalo. Para
isso é necessário obtermos o resto de divisão por 0.5PI do valor original, efectuarmos a
operação de seno ou co-seno e depois a partir do valor original aplicar o sinal correspondente. Outra limitação é que a operação de resto de divisão apenas pode ser realizada
em números inteiros e sabendo que os números que mantém a orientação são números de
vı́rgula flutuante, é necessário mais duas operações adicionais de conversão.
6.1.4
Interface com a camada de sensores
Nas próximas subsecções são apresentados os detalhes da configuração das interfaces
série, formato de mensagens e detalhes das implementações dos dois módulos criados.
Capı́tulo 6. Implementação
65
Configuração das interfaces séries
O interface com a camada de sensores foi implementado em C criando mais um módulo
para o wormhole. Este módulo tem a responsabilidade de passar as mensagens que são
enviadas pelo payload e aceites pelo wormhole, para a camada de sensores. Para que isso
seja possı́vel, uma conversão simples entre interface socket e série é necessária.
Para que seja possı́vel comunicar por interface série, é necessário configurar a última
para que o emissor e receptor tenham as mesmas definições. O microcontrolador Atom
Pro 28 necessita adicionalmente de um cuidado adicional visto o mesmo não ter buffer
de recepção, ou seja, se o microcontrolador receber dados enquanto o mesmo está a efectuar outra tarefa sem ser escutar a interface série, os dados são descartados. No caso da
placa H4090 não é necessário existir cuidados porque a placa tem múltiplos USARTS. Os
USARTS são unidades de hardware capazes de receber/enviar sem que seja necessária
intervenção intensiva do CPU. Para isso existe um pequeno buffer que pode ser usado
para guardar os dados para enviar ou os dados recebidos. Cada vez que o USART recebe
e o buffer enche, o CPU é interrompido para que esses dados possam ser obtidos. O microcontrolador também tem disponı́vel uma USART mas o USART comunica utilizando
o padrão TTL e não o RS232 que é utilizado pela placa H4090, logo esta não é utilizada.
O padrão TTL define o envio e recepção de dados através de 2 condutores, um para
envio e outro para recepção. Este padrão está disponı́vel na única USART da Bot Board II. O padrão RS232 define o envio e recepção de dados através de 9 condutores. Este
padrão está disponı́vel na placa H4090 e Bot Board II embora a última apenas implemente
parte do padrão utilizando apenas 4 conectores, sendo um para envio, um para recepção,
uma para pedir o envio (RTS) e uma para indicar que pode receber dados (CTS). Como
a porta série é controlada pelo microcontrolador existe uma limitação adicional que é a
impossibilidade de enviar e receber em simultâneo, ou seja, a porta na Bot Board II é
“half-duplex”.
De forma a permitir a comunicação das interfaces séries nas duas placas (Bot Board II e
H4090) é necessário que a configuração seja igual nas duas interfaces, isso inclui velocidade de transmissão e recepção, inclusão de bits de paridade e controlo de fluxo.
Formatação de Mensagens
Quanto á formatação das mensagens existem algumas considerações a tomar devido as
limitações do microcontrolador. Visto o microcontrolador não conseguir converter directamente texto em números é necessário receber os números directamente como números.
Para cada número enviado é necessário saber o tamanho exacto do número em casas ou
delimitar o número com um carácter que não seja número de forma ao microcontrolador
detectar que o número acabou. Para isso o carácter ”,”é utilizado.
Capı́tulo 6. Implementação
66
Adicionalmente existe um bug numa das funções de comunicação via porta série que
previne que números de vı́rgula flutuante sejam recebidos. Um número de vı́rgula flutuante no âmbito deste projecto é um número que contém uma parte inteira e uma parte
fraccionária. Para ultrapassar este problema os dois módulos que permite a interacção têm
que ser adaptados. A adaptação passa por converter todos os números de vı́rgula flutuante em número inteiros. Para isso o número de vı́rgula flutuante é primeiro multiplicado
por um milhão e depois convertido para inteiro, sendo posteriormente enviado para o microcontrolador onde o número sobre o processo inverso. O processo inverso é constituı́do
pela conversão de número inteiro para vı́rgula flutuante e posterior divisão por um milhão.
Módulo Sensor Layer Interface
Este módulo foi criado no wormhole para permitir a comunicação entre o último e a camada de sensores. Inicialmente o módulo control task instalado no wormhole recebia as
mensagens do payload do tipo promessa e efectuava o envio para a camada de sensores.
Este módulo era responsável pela recepção das mensagens vindas da camada de sensores.
Isto criava atrasos na actuação do wormhole. Adicionalmente existia a questão identificada na secção anterior em que foi verificado que o wormhole não tinha capacidade de
receber dados se estivesse a fazer outras tarefas sem ser a escuta activada da interface
série. Para isso, como indicado anteriormente, foram criados dois tipos de mensagens,
RTS e CTS, para negociar com a camada de sensores o envio de dados. Isto cria ligeiros
atrasos que não podem ser suportados pelo wormhole. Por estes factos o módulo sensor
layer interface foi criado, que é responsável para recepção e envio de mensagens pela
porta série. Este módulo inclui uma lista de mensagens para que os módulos interessados
(control task) possam colocar as mensagens a enviar sem perder tempo com o envio. Com
este último facto é possı́vel concluir que as operações de colocar e remover uma mensagens na lista podem serem executadas concorrentemente, e por isso foram adicionadas
zonas de exclusão mútua. Estas zonas apenas permitem a entrada de um fio de execução
o que previne perdas de mensagens.
Durante o desenvolvimento foi verificado que a maior parte da largura de banda era
utilizada para enviar mensagens de depuração, chegando a entupir o canal de comunicação
série. Visto ser importante a disponibilidade de mensagens para depuração e visto esta
ocuparem a maior parte da largura de banda disponı́vel, foi aumentada a velocidade da
interface série de 9600 Bits por segundo para 38400 Bits por segundo.
Capı́tulo 6. Implementação
67
Módulo Wormhole Listener
O módulo wormhole listener recebe e processa mensagens enviadas pela porta série. Este
módulo é o mais importante da camada de sensores pois todas as medidas são feitas neste
módulo usando uma abordagem “a pedido”, ou seja, a camada de sensores só faz medidas
e actualiza o seu estado conforme o wormhole efectua pedidos. Isto porque uma vez que o
robô começa a movimentar-se com uma determinada velocidade assume-se que o mesmo
vai continuar até o wormhole indicar o contrário. O mesmo é valido para os obstáculos,
como é o wormhole ou payload que controla o robô, a camada de sensores apenas tem
que enviar resultados quando os mesmos são pedidos.
Um temporizador teve que ser criado para permitir o controlo de tempo de forma a permitir o cálculo de posição com base na aceleração. Esse temporizador é constituı́do por
um contador de 8 bits que é iterado a cada X clocks, onde X é um valor que pode ser
definido no espaço de configuração do temporizador (outros 8 bits). A cada X clocks, o
contador é incrementado até chegar ao valor máximo que é 255. Assim que o contador
chegar ao valor máximo o mesmo volta a 0 e o microcontrolador pode ser configurado
para interromper a execução normal do programa para executar uma rotina de serviço.
Esta solução foi testada utilizando a interrupção para incrementar uma variável, com o
intuito de se ter um controlo de tempo na placa, mas esta solução foi abandonada porque
a interrupção afecta todos os processos com requisitos de tempo (envio/recepção de dados
por porta série, envio de informação para os motores) visto que o processo é interrompido
para ser executada a rotina de serviço. Em vez da solução anterior foi utilizado directamente o contador do temporizador indicado anteriormente sendo este configurado para
o maior intervalo de incremento possı́vel. O processador funciona a 16MHZ e o maior
intervalo de incremento configurável é 8192 clocks por isso a unidade de tempo é 512
microssegundos ou cerca de 0.5 milissegundos. Como 8 bits permitem guardar 256 estados diferentes, logo este contador atinge o seu valor máximo em 131,072 milissegundos.
6.1.5
Safety Task
O módulo safety task é utilizado para controlar o robô no caso que o payload falhe no
cumprimento da promessa. O algoritmo deve ser simples e determinı́stico de forma a enviar os novos valores para os motores assim que possı́vel. O algoritmo original trabalhava
correctamente com várias situações com excepção da resolução de becos sem saı́da, os
quais não conseguia resolver. De forma a resolver esta situação foi introduzida uma estrutura onde são gravados todos os caminhos que o robô utiliza para chegar à localização
actual. Adicionalmente uma cópia do mapa é necessária para gravar as posições que o
robô explorou de forma a evitar que ele volte para os becos ou zonas que não permite
chegar ao destino. Para isso ser possı́vel um novo tipo de célula foi criado. Essa célula
Capı́tulo 6. Implementação
68
Figura 6.2: Mapeamento dos componentes do middleware no hardware após a primeira
iteração
simboliza uma posição explorada. Caso o robô encontre um beco sem saı́da o mesmo
pode retroceder utilizando a estrutura criada para o efeito até encontrar um caminho diferente que lhe permita continuar.
6.1.6
Mapeamento dos Componente no Hardware
Nesta secção é apresentada o mapeamento dos componentes no hardware disponı́vel
aquando o final da primeira iteração e são tiradas algumas conclusões sobre o mapeamento actual. A figura 6.2 apresenta o mapeamento dos componentes no hardware.
Como é possı́vel observar o payload e wormhole estão instalados no ARM quando
que a camada de sensores está instalada no microcontrolador. Nesta fase o componente payload não foi modificado, o wormhole recebeu um novo módulo que permite
a comunicação com a camada de sensores e a camada de sensores foi criada. O payload
comunica com o wormhole via sockets, o wormhole comunica com a camada de sensores
via interface série e os sensores e motores comunicam via ligação directa por pinos.
Com este mapeamento é verificado que, devido ao facto da porta série ser controlada
pelo microcontrolador e não por um hardware dedicado, existe uma certa demora no envio de informação via série do wormhole para a camada de sensores (demora na actuação
Capı́tulo 6. Implementação
69
após o envio da mensagem). Adicionalmente por cada promessa recebida pelo wormhole
são geradas 6 mensagens entre o wormhole e a camada de sensores.
Uma evolução lógica a este mapeamento é passar o wormhole para mais perto da cada
de sensores de forma a ser necessário um menor número de interacções, condensar as
mensagens utilizadas e aumentar a velocidade da interface série.
6.2
2ª Iteração
Na segunda iteração pretendemos transportar a totalidade dos módulos do wormhole para
o microcontrolador. Esta tarefa necessitará de alguns cuidados por causa dos limites de
recursos existentes no microcontrolador. Com a tarefa de portar o wormhole para o microcontrolador, verificamos que seria necessário criar um componente novo que permita ao
wormhole, a utilização das funções que não podem ser portadas para o microcontrolador,
como a função que permite o reiniciar do payload. As seguintes subsecções detalham o
trabalho feito em cada um dos passos indicados anteriormente.
6.2.1
Wormhole
Como indicado anteriormente um dos objectivos deste projecto é portar um dos componentes do middleware para um hardware diferente. Neste caso é o wormhole que é
portado para outro hardware (Atom pro 28). Este porte permite uma melhoria significativa nos tempos de resposta, pois o wormhole passa para o mesmo hardware que a camada
de sensores. Com esta alteração é possı́vel garantir que uma resposta é dada dentro de um
valor de tempo, o que antes não era possı́vel devido ao facto de o processo wormhole poder ser interrompido assincronamente por outros processos que trabalham paralelamente
e competem pelo tempo do CPU.
O desenho inicial do wormhole continha várias componentes que funcionavam paralelamente para completar os objectivos. Visto a facilidade de execução paralela não estar
presente no microcontrolador, foi necessário serializar os componentes tendo sido removido todo o código relativo á execução em paralelo.
Com a transição do wormhole para o microcontrolador o valor disponı́vel no temporizador tornou-se insuficiente porque este componente tem a necessidade de controlar tempos
de outro componente, o payload, que lhe irá enviar seguramente intervalos de tempo
superiores ao valor indicado anteriormente (131,072 milissegundos). Para resolver esta
situação o valor do contador é somado a cada iteração a um contador com maior capacidade. Assim é possı́vel ao wormhole, controlar intervalos até 25,452 dias.
Capı́tulo 6. Implementação
70
O microcontrolador Atom pro 28 como indicado anteriormente contém apenas 2048
bytes de memória para variáveis, o que apenas permite carregar um mapa relativamente
pequeno. Sabendo que as variáveis da camada de sensores e do wormhole sem contar
com o mapa ocupam 386 bytes, o mapa apenas pode ter um tamanho de 40 por 40 células
ou 1600 células totais, visto que uma célula ocupa 1 byte de memória. Isto não é eficiente visto que no mapa estamos apenas a apresentar 3 estados na pior das hipóteses.
Por isso foi criado um mapa de bits em vez de um mapa de bytes em que cada célula
ocupa apenas 1 bit. Isto permite apresentar dois estados (obstáculo estático, caminho livre) sendo necessário um outro mapa para apresentar mais um estado (célula explorada).
Mesmo com a existência de dois mapas o consumo de memória é 75% menor. Com este
melhoramento é possı́vel carregar mapas de 80 por 80 células ou 6400 células. Com
este melhoramento o tamanho do mapa continua a ser relativamente pequeno para permitir o detalhe de um grande edifı́cio. Uma possı́vel solução é permitir carregar um mapa
mais pequeno mas detalhado da zona onde o robô está de forma a permitir uma melhor
navegação. Esta aproximação traz depois outros problemas, como o problema de navegar
num mapa global utilizando um mapa local e o problema de transferência do mapa local
para o microcontrolador sem atrasar o processo de controlo. Para este melhoramento ser
possı́vel foi necessário alterar a forma como o wormhole bridge envia o mapa. Agora é
necessário que o wormhole bridge passe o mapa para bits antes de o enviar. Para o enviar,
cada byte do mapa original é convertido para 0s e 1s sendo 0 caminho livre e 1 obstáculo.
O segundo mapa é gerado pelo wormhole com base no primeiro.
Para portar o wormhole para o microcontrolador foi necessário juntar o código da camada de sensores ao do wormhole. Com isso um novo ciclo de controlo foi criado que
pode ser observado na figura 5.3 apresentada anteriormente.
Na placa H4090 foi criado um componente novo, o wormhole bridge. Este componente
foi criado para permitir o controlo sobre o payload que continua instalado nesta placa
pelo wormhole. Esse controlo traduz-se na possibilidade de terminar e voltar a iniciar o
payload caso o mesmo não cumpra várias promessas ou fique muito tempo sem responder. Adicionalmente o código da interface com o wormhole teve que ser reescrita para
permitir a passagem das novas mensagens. Este componente tem o objectivo secundário
de ser transparente para o payload, ou seja, o payload continua a pensar que está a comunicar directamente com o wormhole.
A execução do wormhole é iniciada recebendo um ficheiro de configuração que contêm
vários dados necessário como tamanho do mapa e células, o mapa, o interface série que vai
utilizar, a posição e orientação inicial a ser comunicada ao microcontrolador. O wormhole
começa por enviar estes dados para o microcontrolador, iniciando posteriormente o pay-
Capı́tulo 6. Implementação
71
load. Depois de receber a mensagem o robô fica num estado pré-activo o qual passa para
activo assim que o payload enviar a primeira promessa. No estado pré activo o robô apenas fica à espera de mensagens via porta série visto ainda não ter qualquer informação de
onde se deve dirigir.
Para garantir que as funções bloqueantes tivessem um tempo de resposta limitado,
foi necessário criar um timeout para cada tipo de interacção. Para a primeira interacção
por série que faz activar o robô é necessário algum tempo pois existe a transferência de
muita informação entre a placa H6042 e o microcontrolador por isso o timeout definido
para essa função é de 1 segundo. Para as restantes interacções por série é utilizado um
timeout de 20 milissegundos. Para interacções com os sensores de distância o limite é 30
milissegundos, pois esse é o tempo máximo que o sensor pode demorar a responder. Para
as restantes interacções não é necessário limite pois as mesmas são apenas de envio de
informações e o tempo demorado é conhecido.
6.2.2
Mapeamento dos Componentes no Hardware
Nesta secção é apresentada o mapeamento dos componentes no hardware disponı́vel
aquando o final da segunda iteração e são tiradas algumas conclusões sobre o mapeamento actual. A figura 6.3 apresenta o mapeamento dos componentes no hardware.
Como é possı́vel observar o payload continua instalado no ARM não tendo recebido
qualquer alteração nesta iteração, o wormhole passou para o microcontrolador com todos os seus módulos e foi junto com a camada de sensores formando um wormhole com
mais controlo sobre os recursos. Adicionalmente isto permite uma actuação mais rápida
e permite que um menor número de mensagens sejam trocadas via interface série. Um
novo componente, o wormhole bridge, foi criado de forma a permitir ao wormhole, que
agora está num outro hardware, a possibilidade de reiniciar o payload cada vez que é
necessário. Com este mapeamento, o payload e wormhole bridge agora comunicam via
socket e o wormhole bridge e o wormhole comunicam através da interface série.
No final desta iteração é possı́vel verificar o seguinte:
• Se a placa H4090 falhar o robô contı́nua operacional e o controlo é assegurado pelo
wormhole;
• O trafego através da porta série é menor devido à condensação de várias mensagens
numa só. Neste caso a mensagem promessa indica a orientação, velocidade, destino
e prazo limite para a entrega da próxima mensagem do tipo promessa;
Capı́tulo 6. Implementação
72
Figura 6.3: Mapeamento dos componentes do middleware no hardware após a segunda
iteração
• Assim que uma mensagem do tipo promessa chega ao wormhole as acções de
definir nova velocidade e definir nova orientação são executadas não sendo necessário envio de novas mensagens como no mapeamento anterior. Isto resulta
numa actuação mais rápida.
Com esta iteração temos uma solução bastante forte que resolve os problemas da
versão anterior.
Uma evolução possı́vel é passarmos o módulo TTFD Task, que é o um dos módulos
mais importantes do middleware, para a FPGA. A FPGA fornece uma maior resolução
de tempo do que aquela que é possı́vel pela microcontrolador o que permite uma precisão
maior.
6.3
3ª Iteração
Na terceira iteração pretende-se trazer um dos módulos do wormhole para a FPGA. Esse
módulo é a TTFD task e a razão para esta mudança que este é um componente de elevada
importância para esta implementação da arquitectura wormhole. Com esta alteração o
wormhole e wormhole bridge tiveram que ser alterados.
Capı́tulo 6. Implementação
6.3.1
73
TTFD Task
A TTFD task é uma tarefa responsável pelo controlo do tempo do payload. Visto ser
um componente importante, foi decidido que o mesmo deveria ser implementado num
hardware dedicado, neste caso a FPGA. Como indicado anteriormente a FPGA não tem
qualquer sistema operativo logo a mesma não pode ser interrompida assincronamente.
Para implementar a TTFD task, um temporizador foi criado que é capaz de interagir com
o CPU permitindo comunicação nos dois sentidos. Como indicado anteriormente o CPU
executa o sistema operativo, o payload e o wormhole bridge. A TTFD task deve receber o
tempo limite da próxima promessa e conseguir indicar a qualquer momento o componente
que está a controlar o robô. Para isso o componente wormhole bridge passa a entregar o
tempo da promessa directamente a TTFD task na FPGA em vez de a enviar para o microcontrolador. Depois disso a TTFD Task deve aguardar o tempo indicado na promessa e
assim que o mesmo terminar mudar o controlo para o wormhole.
Para que a comunicação entre FPGA e CPU seja possı́vel existe uma drive já implementada para Linux e uma configuração para a FPGA que permitem a interacção do
CPU com a FPGA através de o interface paralelo partilhado entre os dois. Este interface
paralelo é constituı́do por várias portas que estão partilhadas entre ambos os hardwares.
Ambos os componentes trabalham em conjunto de forma a transferirem informação do
CPU para a FPGA e da FPGA para o CPU.
A configuração para a FPGA define um conjunto de portas que são utilizadas. Essas
portas correspondem aos pinos na FPGA que vão ser utilizados na configuração. Cada
pino pode transportar um bit de cada vez. Desses pinos existem 35 que são partilhados
entre CPU e FPGA, dos quais 16 que são para conter endereços de memória que o processador utiliza para controlar o acesso à memória de dispositivos externos (neste caso é
a FPGA), 16 bits para envio de dados e 3 bits para flags. Adicionalmente existem 32 bits
que correspondem a contactos do tipo GPIO que podem ser utilizados para receber/enviar
informação directamente entre dispositivos.
Esta configuração aguarda pela indicação por parte do CPU de que tipo de operação
quer fazer, escrita ou leitura, e pelo endereço onde essa operação irá ocorrer. Uma vez
obtida esta informação, a FPGA lê ou escreve dados via os 16 bits de dados partilhados
entre o CPU e a FPGA.
A memória utilizada por esta configuração é de 96 bits, divididas em zonas de 16 bits.
Os primeiros 32 bits representam a assinatura do dispositivo e versão de 16 bits cada. Os
32 seguintes representam os bits de controlo para os 32 bits de memória seguintes. Estes
bits de controlo indicam se a porta está configurada para entrada ou saı́da. Os 32 bits
Capı́tulo 6. Implementação
74
finais são dados que podem ser a qualquer altura lidos ou escritos por esta configuração.
Estes 32 bits de dados estão mapeados directamente para os pinos GPIO indicados anteriormente.
A implementação faz uso de 32 pinos de GPIO em que cada um tem uma função
especı́fica:
• porta 1-30 prazo em microssegundos.
• porta 31 novo prazo disponı́vel para leitura.
• Porta 32 controlo.
Os pinos 1 a 30 são pinos de entrada onde o CPU pode escrever o novo intervalo de
tempo a ser observado. Estes 30 bits permitem intervalos de 1073741824 microssegundos que cumprem os requisitos actuais. Os requisitos actuais definem que o payload
demora no sempre 0,5 segundos a iterar. O pino 31 indica que um novo valor de tempo
está disponı́vel para leitura nos pinos 1 a 30. O pino 32 indica quem tem o controlo
do robô. A implementação deste módulo corre a 60 MHZ embora a unidade de tempo
enviada seja microssegundos. Isto quer dizer que a FPGA itera mais rápido do que é realmente necessário sendo que cada iteração está completa em 16,66 nanossegundos. Para
ser possı́vel monitorizar o tempo microssegundos foi necessário criar um contador para
contar as iterações da FPGA e outro que contém o intervalo enviado anteriormente. O
primeiro contador é incrementado cada vez que a FPGA itera. Com a FPGA itera garantidamente em 16,66 nanossegundos a cada 60 iterações podemos considerar que passou
um microssegundo e decrementar o segundo contador. O segundo contador contém o
intervalo a monitorizar e è decrementado de acordo com a condição indicada em cima.
Quando o contador chega a 0, o wormhole é informado que agora deve controlar o robô.
A informação de controlo é enviada pelo pino 32 colocando a porta num estado baixo
(0 Volts) caso o wormhole esteja em controlo ou num estado alto (3,3 Volts) caso o payload esteja em controlo do robô. Se o payload falhar uma entrega o controlo passa para
o wormhole sendo necessário que o payload consiga cumprir um prazo para voltar a ficar
com o controlo do robô.
A mensagem do tipo promessa usada entre o wormhole e wormhole bridge foi alterada
como consequência deste melhoramento para deixar de levar o próximo prazo. Este prazo
agora é enviado directamente para a TTFD task na FPGA por isso deixa de ser necessário
ao microcontrolador ter conhecimento do prazo.
Capı́tulo 6. Implementação
75
No wormhole foi removido o código de gestão de tempo embora o wormhole mantém
as funcionalidades que permitem aplicar as penalidades ao payload por incumprimento
da promessa. O wormhole agora verifica a cada iteração do ciclo de controlo se existe um
timeout. Se existir um atraso aplica a penalidade correspondente, senão continua.
O wormhole bridge teve que ser adaptado para ao receber a promessa vinda do payload, retirar o prazo da promessa e envia-lo para a TTFD task na FPGA e enviar o resto
da mensagem para o wormhole no microcontrolador. O prazo da promessa tem que ser
agora adaptado para ser enviado para a TTFD task. A TTFD task apenas consegue receber
o número em formato binário, logo o mesmo tem que ser convertido binário, e depois o
estado de cada uma das portas da FPGA tem que ser individualmente definida. Ao receber
este número a FPGA começa a contar para baixo até chegar a 0. Quando chegar a 0 indica
que existiu o prazo não foi cumprido.
Exactamente como na última alteração efectuada ao sistema, esta alteração é transparente ao payload, logo o mesmo não tem que ser alterado para usufruir desta funcionalidade adicional.
6.3.2
Mapeamento dos Componentes no Hardware
Nesta secção é apresentada o mapeamento dos componentes no hardware disponı́vel
aquando o final da terceira iteração e são tiradas algumas conclusões sobre o mapeamento actual. A figura 6.4 apresenta o mapeamento dos componentes no hardware.
Como é possı́vel observar o payload continua instalado no ARM não tendo recebido qualquer alteração nesta iteração, a TTFD task passou para outro hardware mas o
wormhole continua a consultar este módulo para obter quem tem o controlo do robô num
dado momento. Adicionalmente a mensagem promessa que é trocada entre wormhole
bridge e wormhole foi alterada para remover o prazo da próxima entrega. A TTFD task
foi adaptada na FPGA de forma a permitir o controlo de um prazo que é agora indicado
pelo wormhole bridge. O wormhole bridge recebeu algumas alterações de forma a agora
não enviar o novo prazo para o wormhole e envia-lo para o módulo TTFD task instalado
na FPGA. O payload e wormhole bridge continuam a comunicar através de sockets. O
wormhole bridge e o wormhole continuam a comunicar através de série. O wormhole
bridge e o módulo TTFD task comunicam agora através de um bus de memória partilhado. O módulo TTFD task comunica com o wormhole através de pinos.
No final desta iteração é possı́vel verificar o seguinte:
• Se a placa H4090 falhar o robô contı́nua operacional e o controlo é assegurado pelo
wormhole.
Capı́tulo 6. Implementação
76
Figura 6.4: Mapeamento dos componentes do middleware no hardware após a terceira
iteração
• A carga do Atom pro 28 é ligeiramente diminuı́da com esta alteração não sendo
necessário ao microcontrolador controlar os prazos do payload.
• A FPGA permite uma melhor resolução de tempo do que o microcontrolador, visto
que a FPGA trabalha com clocks mais altos e isso permite mais iterações por segundo.
• O wormhole pode funcionar correctamente sem o módulo ttfd task. O wormhole
apenas assume que o componente payload não respondeu a tempo (ocorre quando
a placa H4090+H6042 se desliga por bateria fraca).
6.4
Algoritmos de navegação e ajuste
Em adição aos objectivos decidimos criar alguns algoritmos para auxiliarem na navegação
do robô. Estes algoritmos aplicam pequenos ajustes à velocidade dos motores de forma
a obrigar o robô a manter-se no centro da sala quando avança, e a medir a velocidade e
posição com ajuda dos sensores de distância.
O algoritmo que mantém o robô no centro do local actual consegue-o através dos dois
sensores posicionados em cada um dos lados. O microcontrolador retira as medidas dos
sensores de tempo em tempo de forma a verificar se o robô está no centro da sala. Se
Capı́tulo 6. Implementação
77
estiver no centro ou perto ele mantém a rota, senão ele efectua o ajuste para o lado do
qual esta mais longe.
O algoritmo que permite o posicionamento com ajuda dos sensores foi um algoritmo
desenvolvido visto existirem algumas discrepâncias nas medidas do acelerómetro. Este
algoritmo utiliza um sensor de distância montado na frente do robô para permitir saber a
distância à parede mais próxima. Este algoritmo utiliza o mapa e giroscópio para calcular
a posição, logo é necessário que o mapa seja um mapa perfeito da localização pois qualquer irregularidade faz com o mesmo retorne valores incorrectos.
Capı́tulo 7
Testes e Resultados
Um dos objectivos descritos anteriormente é validar a propriedade de execução sı́ncrona
do wormhole. De forma a validar essa propriedade é necessário certificamo-nos que o
tempo que wormhole demora a completar o ciclo de controlo no pior caso é constante,
isto é, se todos os módulos têm tempos de execução constantes ou limitados. Para fazer
esta análise é necessário medir o tempo para cada um dos módulos que fazem parte do
wormhole. Para isso é utilizado o temporizador existente no microcontrolador e é feita a
diferença entre o tempo em que o método termina e inicia. Para cada módulo é calculado
o tempo que o mesmo demora a terminar para a melhor e pior situação assim como para
o caso esperado. Os tempos mı́nimos são calculados utilizando o tempo que o microcontrolador demora a computar a lógica somado com ao tempo mı́nimo utilizado para receber/enviar o mı́nimo de valores de entrada/saı́da. Este processo de envio/recepção pode
ser de dados através da interface série ou envio de dados para os motores. Os tempos
máximos são calculados utilizando o tempo que o microcontrolador demora a computar
a lógica somado ao tempo máximo utilizado para receber/enviar o máximo de valores de
entrada/saı́da ou fazendo disparar algum método de timeout.
A figura 7.1 apresenta uma linha temporal referente à falha do componente payload e
ao que ocorre depois desse evento.
Como é possı́vel observar após o payload falhar, a mensagem promessa enviada
pelo payload ainda é processada pelo wormhole bridge e finalmente encaminhada para
o wormhole que a aplica dependendo do estado anterior do payload. Algures no tempo
(depende do prazo enviado na promessa), o módulo ttfd task detecta que o payload não
cumpriu o prazo e disponibiliza essa informação ao wormhole. O wormhole aquando a
execução do módulo TTFD task listener obtém essa informação e pára o robô. De seguida
o mesmo inicia o controlo do robô.
Nas subsecções seguintes são apresentadas todos os testes para validar a propriedade
de execução sı́ncrona do wormhole. Inicialmente é detalhado como são testados todos os
módulos do wormhole o que inclui detalhes sobre o funcionamento e decisões sobre como
efectuar os testes e finalmente é verificado se o wormhole tem capacidade para receber as
79
Capı́tulo 7. Testes e Resultados
80
Figura 7.1: Linha temporal entre a falha do payload e o controlo do robô por parte do
wormhole.
mensagens que lhe são enviadas sem atrasos.
7.1
Módulos
Os módulos foram testados de forma a verificar o tempo que os mesmos demoraram a
executar em determinadas situações. Os tempos obtidos para cada um dos módulos são
referentes aos mı́nimos, médios e máximos possı́veis. Para que os módulos pudessem ser
testados, ambientes especı́ficos tiveram que ser criados de forma ao tempos de processamento de cada módulo poderem ser capturados.
Cada um dos testes é efectuado mil vezes e é obtido o maior tempo demorado. Com
esse valor é construı́da uma tabela onde se pode visualizar os tempos mı́nimos, médio e
máximo esperados para o wormhole. O facto de estes tempos serem os esperados quer
indicar que não testamos condições impossı́veis.
Para cada uma das tabelas apresentadas o primeiro valor numérico corresponde ao
tempo que o módulo demora a terminar no melhor caso, o segundo valor numérico corresponde ao tempo que o módulo demora a terminar no caso esperado ou na média dos
casos e o terceiro valor numérico corresponde ao tempo que o módulo demora a terminar
para o pior caso de execução.
81
Capı́tulo 7. Testes e Resultados
Nome do módulo
Descrição do módulo
Descrição do teste
Aguarda por entrada de dados (Tempo
máximo/Não)
Payload Listener
Módulo responsável para recepção de
mensagens enviadas pelo payload através
da interface série.
Pretende-se testar os tempos para este
módulo sabendo que os mesmos dependem da quantidade e tamanho das mensagens recebidas.
20000.
Tabela 7.1: Informações gerais para o módulo payload listener.
7.1.1
Payload Listener
O módulo payload listener é o módulo responsável por receber informação proveniente
do payload. Essa informação 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 conteúdo da mensagem. Isto é
necessário visto o microcontrolador não ter capacidade de converter entre tipos de dados
diferentes e não 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 módulo começa por esperar por uma mensagem RTS respondendo á mesma com
uma mensagem CTS. Após o envio da mensagem, o módulo aguarda uma segunda mensagem que deverá conter o tipo da mensagem. Esse tipo é constituı́do por três caracteres.
Após a recepção desta última mensagem termina a primeira fase do protocolo e dá-se
inicio á segunda fase. A segunda fase começa com a recepção de uma mensagem do tipo
RTS e envio da respectiva resposta CTS. Depois disso o payload pode iniciar o envio do
conteúdo da mensagem. Todas estas interacções são limitadas por um valor de tempo
predefinido que é 20 milissegundos.
O módulo payload listener, como indicado anteriormente, implementa um protocolo
de duas fases. Para ser possı́vel calcular o melhor tempo é necessário que o tamanho dos
dados recebidos pela interface série sejam o mı́nimo possı́vel mas não pode ser zero visto
que, se não forem recebidos dados a função de recepção espera até que o tempo de timeout indicado passe e isso demora muito mais que receber uma mensagem.
A tabela 7.1 apresenta um resumo das informações gerais para os testes efectuados ao
módulo payload listener e os tempos obtidos para este módulo são apresentados na tabela
7.2.
Para o tempo mı́nimo foi criado um ambiente em que a função recebe uma mensagem
Capı́tulo 7. Testes e Resultados
82
Nome do módulo Tempo mı́nimo Tempo médio Tempo máximo
Payload Listener
0,761
24,9044
63,582
Tabela 7.2: Tempos para o módulo payload listener.
inválida. Esta mensagem pode ser ruı́do no meio que é utilizado (interface série) e consideramos que a mesma tem apenas 1 byte e esse byte tem o valor 13. A recepção do valor
13 é uma das condições de saı́da para a função que lê do meio utilizado. Esta situação
pode ocorrer se existir alguma interferência no meio de comunicação e ocorre raramente.
O tempo médio para este módulo é um pouco difı́cil de quantificar. Isto porque o caso
esperado depende do número de vezes que o payload envia uma promessa por segundo e o
número de vezes que o ciclo que contém todos os módulos itera (o tempo que o wormhole
demora a iterar). Se o módulo executa e recebe as mensagens correctamente este demora
no máximo 44,522 milissegundos mas se ele não receber nada demora 20 milissegundos
que é o tempo do timeout da função de leitura. No caso actual o payload envia duas promessas 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 médio foi criado um ambiente em que o módulo apenas recebe mensagens válidas e processa múltiplas mensagens uma das quais do tipo promessa. Este
ambiente representa o caso esperado de execução. As mensagens trocadas neste ambiente
são:
• 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 mensagem 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 e finalmente o wormhole bridge
pode começar a enviar a mensagem do tipo promessa.
Para o tempo máximo foi criado um ambiente em que o módulo recebe as todas as
mensagens esperadas excepto a última. Todas as mensagens recebidas são recebidas no
Capı́tulo 7. Testes e Resultados
83
último momento possı́vel antes do timeout de forma à operação demorar o máximo de
tempo possı́vel. A última operação de recepção termina com timeout. As mensagens
trocadas neste ambiente são:
• Duas mensagens RTS;
• Duas mensagens CTS;
• Uma mensagem de tipo.
Na primeira fase do protocolo, o wormhole bridge começa por enviar uma mensagem 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 última mensagem não é enviada
de forma a obrigar a função que lê da porta série a sair por timeout.
7.1.2
Position Updater
O módulo position updater é responsável pela actualização da posição do robô utilizando
o acelerómetro e giroscópio que existem no robô. O acelerómetro como indicado anteriormente permite a leitura de acelerações que o mesmo sofre ao longo do tempo. O giroscópio permite a leitura de valores de velocidade angular. Com estes valores é possı́vel
calcular respectivamente a posição do robô e orientação do mesmo. O algoritmo deste
módulo obtém os valores dos sensores de acordo com o tipo de movimento actual. Se
o movimento for rectilı́neo, o módulo obtém o valor de posição. Se o movimento for
curvilı́neo, o módulo obtém o valor da orientação. Isso é feito para evitar leituras com
valores incorrectos quando o robô efectua movimentos que não correspondem ao tipo de
leitura, ou seja, no caso do movimento curvilı́neo consideramos que o mesmo não altera
a posição do robô, apenas a orientação e no caso do movimento rectilı́neo consideramos
que o mesmo não altera a orientação do robô.
A tabela 7.3 apresenta um resumo das informações gerais para os testes efectuados ao
módulo position update e os tempos obtidos para este módulo são apresentados na tabela
7.4.
Para o tempo mı́nimo foi criado um ambiente em que o robô está parado. Com isso o
módulo sabe que não precisa de executar e retorna imediatamente.
Para o tempo médio foi criado um ambiente em que o robô está a efectuar um movimento rectilı́neo e posteriormente efectua um movimento curvilı́neo. Com o movimento
84
Capı́tulo 7. Testes e Resultados
Nome do módulo
Descrição do módulo
Descrição do teste
Aguarda por entrada de dados (Tempo
máximo/Não)
Position Updater
Módulo responsável pela actualização da
posição e orientação através de sensores
locais (acelerómetro e giroscópio).
Pretende-se testar os tempos para este
módulo sabendo que os mesmos dependem do tipo de movimento que o robô
está a efectuar nesse momento.
Não
Tabela 7.3: Informações gerais para o módulo position updater.
Nome do módulo Tempo mı́nimo Tempo médio Tempo máximo
Position Updater
0,064
1,856
2,304
Tabela 7.4: Tempos para o módulo position updater.
rectilı́neo foi obtido o tempo que o módulo demora a processar a posição. Com o movimento curvilı́neo foi obtido o tempo que o módulo demora a processar a orientação. O
valor final é a média dos dois tempos.
Para o tempo máximo foi criado um ambiente em que o robô está a efectuar um movimento curvilı́neo. O módulo efectua o cálculo da nova orientação do robô. A orientação
demora mais a ser calculada porque no código de cálculo da orientação existe também o
cálculo das funções seno e co-seno para o novo valor de orientação.
7.1.3
Obstacle Updater
O módulo obstacle updater é responsável pela detecção e envio da posição dos obstáculos.
Estes obstáculos são detectados pelos sensores de distância instalados no robô. Cada vez
que um obstáculo é detectado, se o mesmo estiver perto do robô, uma mensagem é enviada para o payload a indicar as coordenadas do mesmo. Visto que os sensores são digitais
existe um tempo adicional para a interpretação do valor e como a operação é bloqueante
é necessário existir um timeout para limitar o tempo que a função de leitura espera para
ler o valor. Se um sensor for desligado ou se nenhum obstáculo for detectado um timeout
ocorre. O robô tem instalado 3 sensores de distância, um posicionado na frente, outro na
esquerda e outro na direita. A posição do obstáculo no mapa só é enviada se o mesmo
estiver a menos de 50 centı́metros do robô.
85
Capı́tulo 7. Testes e Resultados
Nome do módulo
Descrição do módulo
Descrição do teste
Aguarda por entrada de dados (Tempo
máximo/Não)
Obstacle Updater
Módulo responsável pela detecção de
obstáculos através dos sensores locais
(sensores ultra-sónicos) e envio das coordenadas para o payload.
Pretende-se testar os tempos para este
módulo sabendo que os mesmos dependem da distância a que os obstáculos
estão do sensor.
30000.
Tabela 7.5: Informações gerais para o módulo “obstacle updater”.
Nome do módulo Tempo mı́nimo Tempo médio Tempo máximo
Obstacle Updater
0,175
32,064
90,112
Tabela 7.6: Tempos para o módulo “obstacle updater”.
A tabela 7.5 apresenta um resumo das informações gerais para os testes efectuados ao
módulo obstacle update e os tempos obtidos para este módulo são apresentados na tabela
7.6.
Para o tempo mı́nimo foi criado um ambiente em que um obstáculo está encostado a
cada um dos sensores de forma as respectivas funções de leitura retornarem o mais rapidamente possı́vel. O módulo começa por verificar o primeiro sensor e assim que obtém
o valor de distancia, verifica se o mesmo esta dentro dos limites. Com está a posição
no mapa é calculada e as coordenadas são enviadas. Este processo é repetido mais duas
vezes para os restantes sensores.
Para o tempo médio foi criado um ambiente em que um obstáculo é detectado a 2 metros. A distância máxima obtida pelos sensores é 4 metros. Como os obstáculos podem
estar a qualquer distância do robô, utilizamos a distância média. O módulo começa por
verificar o primeiro sensor e assim que obtém o valor de distancia, verifica se o mesmo
esta dentro dos limites. Com não está o módulo segue para o próximo sensor.
Para o tempo máximo foi criado um ambiente em que todas as leituras terminam por
timeout. Isto pode ser conseguido facilmente desligando todos os sensores ligados ao
robô. O valor de timeout é 20 milissegundos.
86
Capı́tulo 7. Testes e Resultados
Nome do módulo
Descrição do módulo
Descrição do teste
Aguarda por entrada de dados (Tempo
máximo/Não)
Position Sender
Módulo responsável pelo envio dos dados
de posição para o wormhole.
Pretende-se testar os tempos para este
módulo sabendo que os mesmos dependem dos dados enviados.
Não
Tabela 7.7: Informações gerais para o módulo position sender.
Nome do módulo Tempo mı́nimo Tempo médio Tempo máximo
Position Sender
16,64
16,896
17,536
Tabela 7.8: Tempos para o módulo position sender.
7.1.4
Position Sender
O módulo position sender é responsável pelo envio da posição, orientação e velocidade
para o payload. A posição é constituı́da por dois campos: posição em X e posição em
Y. Este envio é feito depois da actualização dos valores pelo módulo position updater.
Este módulo corre apenas uma vez por ciclo de controlo. No processo de envio, números
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̧ão não 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̧ão pode ser negativa. O envio de um
byte adicional aumenta o tempo que o módulo demora a terminar. Os testes e os valores
obtidos dos testes reflectem as observações anteriores.
A tabela 7.7 apresenta um resumo das informações gerais para os testes efectuados ao
módulo position sender e os tempos obtidos para este módulo são apresentados na tabela
7.8.
Para o tempo mı́nimo foi criado um ambiente em que os valores de posição, velocidade
e orientação são positivos. Os valores inteiros (posição e velocidade) são na ordem das
dezenas e quando a orientação tem 9 casas decimais.
Para o tempo médio foi criado um ambiente em os valores da velocidade e posição
são positivos e a orientação alterna entre positiva e negativa. As mesmas opções do ambiente criado para medir o tempo mı́nimo aplicam-se mas o facto de um valor ser negativo
aumenta o número de bytes a enviar em um.
Para o tempo máximo foi criado um ambiente em que os valores de posição e orientação
87
Capı́tulo 7. Testes e Resultados
Nome do módulo
Descrição do módulo
Descrição do teste
Aguarda por entrada de dados (Tempo
máximo/Não)
TTFD Task Listener
Módulo responsável pela aplicação de penalidades caso o componente payload falhe o cumprimento de prazos.
Pretende-se testar os tempos para este
módulo sabendo que os mesmos dependem do cumprimento das promessas por
parte do componente payload.
Não
Tabela 7.9: Informações gerais para o módulo “FPGA listener”.
Nome do módulo
Tempo mı́nimo Tempo médio Tempo máximo
TTFD Task Listener
0,064
0,128
4,224
Tabela 7.10: Tempos para o módulo FPGA listener.
são negativos e a velocidade é positiva. As mesmas opções do ambiente criado para medir
o tempo mı́nimo aplicam-se mas o facto de três valores(a posição tem dois valores) serem
negativos aumenta o número de bytes a enviar em três.
7.1.5
TTFD Task Listener
O módulo TTFD task listener é responsável pela aplicação de penalidades ao payload
caso o mesmo não cumpra as promessas que entrega. O tempo é actualmente monitorizado pela FPGA e esta é capaz de indicar ao wormhole quem é que detém o controlo
sendo depois da responsabilidade do wormhole a aplicação de penalidades ao wormhole.
Estas penalidades são perder o controlo do robô e reiniciar o componente payload. Este
módulo apenas executa quando o robô encontra-se num estado activo (depois de receber
o mapa e a primeira promessa).
A tabela 7.9 apresenta um resumo das informações gerais para os testes efectuados ao
módulo FPGA listener e os tempos obtidos para este módulo são apresentados na tabela
7.10.
Para o tempo mı́nimo foi criado um ambiente em que o robô apenas recebeu o mapa
mas ainda não recebeu a primeira promessa logo este módulo sai sem efectuar nenhuma
verificação ao prazo.
Para o tempo médio foi criado um ambiente em que o robô já se encontra activo e o
88
Capı́tulo 7. Testes e Resultados
Nome do módulo
Descrição do módulo
Descrição do teste
Aguarda por entrada de dados (Tempo
máximo/Não)
Safety Task
Módulo responsável pelo controlo do
robô caso o componente payload falhe o
cumprimento de prazos.
Pretende-se testar os tempos para este
módulo sabendo que os mesmos dependem do cumprimento das promessas por
parte do componente payload.
Não
Tabela 7.11: Informações gerais para o módulo “safety task”.
Nome do módulo Tempo mı́nimo Tempo médio Tempo máximo
Safety Task
0,064
0,064
7,424
Tabela 7.12: Tempos para o módulo safety task.
payload está a cumprir os prazos das promessas. Neste caso o wormhole verifica se o
payload está 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 robô.
Para o tempo máximo foi criado um ambiente em que o robô já se encontra activo, o
payload não cumpriu o último prazo e já falhou três outros prazos. Neste caso o wormhole
verifica que o payload não está a cumprir prazos, transita o controlo para o wormhole e
verifica que já falhou quatro vezes reiniciando o payload. Para transitar o controlo é enviada uma mensagem para transitar o controlo e é enviada outra mensagem para reiniciar
o payload.
7.1.6
Safety Task
O módulo “safety task” é responsável pelo controlo do robô caso o payload não cumpra as
promessas que envia. Este módulo contém 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̧ões gerais para os testes efectuados
ao módulo Safety Task e os tempos obtidos para este módulo são apresentados na tabela
7.12.
Para o tempo mı́nimo e médio foi criado um ambiente em que o payload esta a cum-
89
Capı́tulo 7. Testes e Resultados
Nome do módulo
Descrição do módulo
Descrição do teste
Aguarda por entrada de dados (Tempo
máximo/Não)
Velocity Observer
Módulo responsável pelo controlo da velocidade do robô.
Pretende-se testar os tempos para este
módulo sabendo que os mesmos dependem da velocidade actual estar correcta
e demora de transmissão de novos dados
aos motores.
Não
Tabela 7.13: Informações gerais para o módulo “velocity observer”.
prir as promessas, logo o módulo não é necessário e termina. Este é o caso mais comum
e o ideal porque o payload tem uma maior capacidade de efectuar um melhor controlo do
robô.
Para o tempo máximo foi criado um ambiente em que o payload não esta a cumprir
as promessas e existem coordenadas validas de destino. Adicionalmente o robô está colocado num beco sem saı́da no qual não de avançar mais para a frente. Isso permite ao
módulo executar o algoritmo de procura de caminhos e adicionalmente obriga o robô a
retroceder. O retrocesso demora ligeiramente mais visto que o wormhole têm que obter o
último valor da lista de passos e calcular a direcção.
7.1.7
Velocity Observer
Este módulo é responsável pela monitorização da velocidade. Como não podemos indicar
aos motores a velocidade que queremos, utilizamos o acelerómetro de forma a calcular a
velocidade e a fazer pequenos ajustes para que o robô prossiga à velocidade indicada. Este
módulo apenas está activo quando o robô avança para a frente ou trás. 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 módulo
demora a terminar varia.
A tabela 7.13 apresenta um resumo das informações gerais para os testes efectuados
ao módulo Velocity Observer e os tempos obtidos para este módulo são apresentados na
tabela 7.14.
Para o tempo mı́nimo foi criado um ambiente em que o robô está a efectuar um movimento curvilı́neo, logo este módulo não precisa de ser executado e o mesmo termina
imediatamente.
Capı́tulo 7. Testes e Resultados
90
Nome do módulo Tempo mı́nimo Tempo médio Tempo máximo
Velocity Observer
0,064
3,328
3,712
Tabela 7.14: Tempos para o módulo “velocity observer”.
Para o tempo médio foi criado um ambiente em a velocidade do robô é menor que a
requerida e o próximo incremento dos motores colocará os motores a metade da capacidade máxima (metade do comprimento do impulso enviado, metade do tempo necessário).
Nesse caso o módulo envia nova informação para os motores para que os mesmos rodem
mais rápido. O caso mais comum é aquele em que a velocidade necessita de ajustes à
velocidade visto que o robô começa parado e este ajuste e necessário uma quantidade
considerável de vezes antes que o mesmo chegue a velocidade requerida.
Para o tempo máximo foi criado um ambiente em a velocidade do robô é menor que
a requerida e o próximo incremento dos motores colocará os motores na máxima capacidade. Nesse caso o módulo envia nova informação para os motores rodem mais rápido.
7.1.8
Orientation Observer
Este módulo é responsável pela monitorização da orientação. Como não podemos indicar
aos motores a orientação que queremos, é utilizado o giroscópio de forma a calcular a
orientação e saber quando parar a rotação e prosseguir com o movimento anterior. Este
módulo é activo apenas quando o robô necessita de mudar de orientação.
A tabela 7.15 apresenta um resumo das informações gerais para os testes efectuados
ao módulo Orientation Observer e os tempos obtidos para este módulo são apresentados
na tabela 7.16.
Para o tempo mı́nimo foi criado um ambiente em que o robô está a efectuar um movimento rectilı́neo, logo este módulo não precisa de ser executado e termina imediatamente.
Para o tempo médio foi criado um ambiente em que o robô está a virar e ainda não
alcançou a orientação correcta. O módulo começa por verificar para que lado o robô esta
a virar para depois verificar se já passou o ponto em que deveria parar. Como neste caso
ele ainda não chegou à orientação correcta, o módulo envia ordens aos motores para continuar o movimento actual.
Para o tempo máximo foi criado um ambiente em que o robô está a virar e mas acabou
de alcançar a orientação correcta. O módulo começa por verificar para que lado o robô
91
Capı́tulo 7. Testes e Resultados
Nome do módulo
Descrição do módulo
Descrição do teste
Aguarda por entrada de dados (Tempo
máximo/Não)
Velocity Observer
Módulo responsável pelo controlo da
orientação do robô.
Pretende-se testar os tempos para este
módulo sabendo que os mesmos dependem do tipo de movimento, orientação actual do robô e tempo que se demora a enviar ordens aos motores.
Não
Tabela 7.15: Informações gerais para o módulo “orientation observer”.
Nome do módulo
Tempo mı́nimo Tempo médio Tempo máximo
Orientation Observer
0,064
3,201
4,608
Tabela 7.16: Tempos para o módulo “orientation observer”.
esta a virar para depois verificar se já passou o ponto em que deveria parar. Como neste
caso ele já está na orientação em que deveria parar, o módulo envia ordens para o robô
parar e depois aplica uma velocidade base que faz com que o robô avance para a frente.
7.1.9
Resultados Finais
A tabela 7.17 apresenta os valores de forma acumulativa para facilitar a visualização
do tempo que o ciclo de controlo demora a executar, módulo a módulo. Nesta tabela
podemos observar que o valor máximo de execução do ciclo de controlo é 193,502 milissegundos, o que significa que, todos os módulos são executados no pior caso em 193,502
milissegundos. No caso de o payload falhar uma entrega sabemos que no máximo o robô
terá o controlo garantido em 193,502 milissegundos. Visto que o microcontrolador não é
interrompido assincronamente sabemos que este valor é garantido.
Como é possı́vel observar na tabela 7.17 existem alguns módulos com tempos máximos
de execução muito reduzidos enquanto existem outros que têm tempos que chegam a ser
40 vezes maiores os módulos que têm tempos de execução reduzidos. Isso ocorre porque
os módulos que têm tempos de execução reduzidos (menores que 10 milissegundos) são
módulos que apenas efectuam cálculos ou utilizam funções cujo tempo de execução é
constante e não estão dependentes de valores ou recursos externos. Quanto aos módulos
com tempos de execução elevados efectuam leituras de sensores ou recebem informações
da interface série, logo esses módulos têm que esperar pela informação. Nestes casos
Capı́tulo 7. Testes e Resultados
92
Nome do módulo
Tempo mı́nimo Tempo médio Tempo máximo
Payload Listener
0,761
24,9044
63,582
Position Updater
0,064
1,856
2,304
Obstacle Updater
0,175
32,064
90,112
Status Sender
16,64
16,896
17,536
TTFD Task Listener
0,064
0,128
4,224
Safety Task
0,064
0,064
7,424
Velocity Observer
0,064
3,328
3,712
Orientation Observer
0,064
3,2
4,608
Total
17,896
82,4404
193,502
Tabela 7.17: Tempos para o ciclo de controlo do componente wormhole.
todas as funções de leitura estão limitadas em termos de tempo que esperam por um valor
de entrada.
7.2
Mensagens
Adicionalmente a verificar o tempo que o ciclo de controlo demora a executar é também
necessário verificar se a interface série consegue suportar o volume expectável de dados
actual e qual o limite de promessas que o wormhole pode receber por segundo, mantendo
o tempo de resposta médio observável na tabela 7.17. O tempo máximo não será utilizado para estes cálculos visto que o mesmo pressupõe que em alguns casos não sejam
recebidas mensagens. Para estes cálculos vamos considerar que o robô consegue iterar
20 vez por segundo o ciclo de controlo, logo cada módulo é executado garantidamente 20
vezes por segundo.
Como verificamos no módulo payload listener, o número de mensagens necessárias
para receber a mensagem do tipo promessa são 6 incluindo a mensagem do tipo promessa.
O payload envia duas promessas a cada segundo logo esperamos que sejam recebidas 12
mensagens. O módulo position sender envia uma mensagem por iteração e como consideramos que o módulo executa 20 vezes por segundo, então são enviadas 20 mensagens
por segundo. O módulo obstacle updater envia uma mensagem por cada obstáculo que
detecta e se considerarmos que é detectado um objecto por sensor, então são enviadas 60
mensagens. O módulo TTFD task listener pode também enviar mensagens de controlo e
reinı́cio. Como o módulo está limitado a enviar apenas uma mensagem de reinı́cio a cada
1 segundo, podemos considerar que são enviadas 8 mensagens, 7 transições de controlo e
uma de reinı́cio. A lista de mensagens para este caso é a seguinte:
• 4 mensagens RTS
• 4 mensagens CTS
Capı́tulo 7. Testes e Resultados
93
Tipo de mensagem Tamanho
CTS
4
RTS
4
Type
4
Promise
24
Status
56
Obstacle
29
Control
4
Restart
4
Total
129
Tabela 7.18: Tamanho máximo para cada tipo de mensagem.
• 2 mensagens de tipo
• 2 mensagens do tipo promessa
• 20 mensagens de estado
• 60 mensagens de obstáculos
• 7 mensagens de controlo
• 1 mensagem de reinicio
Cada mensagem do tipo RTS, CTS, tipo, controlo e reinı́cio são 4 bytes, 3 para o tipo
de mensagem e 1 para o byte que simboliza o fim da mensagem (byte com o valor 13).
Cada mensagem do tipo promessa tem 24 bytes, 1 byte para destino em x, 1 byte para
destino em y, 9 bytes para nova orientação, 9 bytes para nova velocidade e 4 bytes para
delimitadores e byte final. Cada mensagem do tipo estado ocupa 56 bytes, 3 bytes para
tipo, 12 bytes para posição em x, 12 bytes para posição em y, 13 bytes para orientação, 12
bytes para velocidade escalar e 4 bytes para delimitadores e byte final. Cada mensagem
do tipo obstáculo tem 29 bytes, 3 bytes para tipo, 12 bytes para posição do obstáculo em
x, 12 bytes para posição do obstáculo em y e 2 bytes para delimitador e byte final. O
tamanho de cada mensagem é apresentado na tabela 7.18.
A tabela 7.19 apresenta o tamanho das mensagens por segundo para cada tipo de
mensagem e o seu total. Como é possı́vel verificar as mensagens que utilizam mais largura
de banda são as mensagens de estado.
Sabendo que a largura de banda actualmente configurada para a interface de série
38400 bits por segundo. Sabendo que um byte é constituı́do por oito bits, que cada
carácter é enviado como um byte e que antes e depois de cada de cada carácter são colocados dois bits a indicar o inı́cio e o fim de cada carácter, podemos calcular o número de
Capı́tulo 7. Testes e Resultados
94
Tipo de mensagem Tamanho (bytes) Número de envios por segundo Tamanho total (bytes)
CTS
4
4
16
RTS
4
4
16
Type
4
2
8
Promise
24
2
48
Status
56
20
1120
Obstacle
29
60
1740
Control
4
7
28
Restart
4
1
4
Total
129
100
2980
Tabela 7.19: Total de tráfego gerado pela totalidade das mensagens.
caracteres que podem ser enviados por segundo que neste caso são 3840 caracteres.
Como podemos verificar a taxa de utilização da largura de banda disponı́vel é 0,776.
Logo concluı́mos que a largura de banda é suficiente para o tráfego actual e ainda capacidade adicional de 860 por segundo.
Na prática são esperadas menos mensagens do que para este teste. Podemos observar
que se é possı́vel para o pior dos casos enviar 100 mensagens por segundo então é possı́vel
enviar menos.
Na figura 7.2 podemos observar a unidade de testes que foi criada aplicando o hardware indicado anteriormente.
Capı́tulo 7. Testes e Resultados
Figura 7.2: O robô utilizado para testes
95
Capı́tulo 7. Testes e Resultados
96
Capı́tulo 8
Conclusões e Trabalho Futuro
A solução apresentada utiliza o modelo wormhole para garantir a execução atempada
de tarefas. Neste caso a tarefa é o controlo do robô por parte do componente payload.
Para garantir a execução atempada de tarefas, o módulo responsavel pela monitorização,
TTFD task, foi instalado num hardware dedicado de forma a permitir uma maior rapidez
na detecção de uma eventual falha do payload e para diminuir a carga do wormhole.
Os restantes módulos pretencentes ao wormhole foram também instalados em hardware
dedicado de forma a garantir que não existem flutuações no tempo que o mesmo demora.
Com a configuração descrita acima, foram efectuados testes de forma a medir o tempo
que o wormhole demora a completar todos os calculos que definem o seu ciclo de controlo. Com esta aproximação pode-se verificar que é garantido o controlo dentro de 194
milissegundos desde a detecção da falha. Este valor serve as necessidade do robô porque
permite pelo menos 5 ordens por minuto. Com base nos resultados obtidos pode-se verificar que esta aproximação se enquadra perfeitamente no contexto de controlo de um robô
fı́sico porque é garantido o controlo e este é garantido dentro de um tempo conhecido.
Adicionalmente foi testada a interface serı́e de forma a verificar qual a taxa de ocupação
da a mesma face ao trafego actual. Verificamos que a capacidade da porta serie é superior a 20 iteração por segundo, sendo muito superior à media esperada de 12 iterações
por segundo. Isto permite concluir que existe espaço para melhoras nesta solução pois è
possivel utilizar a largura de banda disponivel para melhorar, por exemplo, a resolução do
mapa a ser enviado.
A separação dos componentes em hardwares distintos é uma mais-valia visto que
adiciona um novo nı́vel de tolerância a faltas porque o wormhole, que é o componente
mais fiavel, está num hardware mais fiavel enquanto o payload está num hardware mais
poderoso mas que não executa apenas o payload mas também drivers, serviços e outras
aplicações. Visto permite tolerar falhas no hardware em que o payload está instalado,
como a falta de bateria.
Com base nos testes é possivel verificar que ainda existe espaço para melhoramento
97
Capı́tulo 8. Conclusões e Trabalho Futuro
98
pois ainda existe capacidade adicional para envio/recepção de mensagens e capacidade de
processamento através de melhor aproveitamento da FPGA.
Quanto ao trabalho futuro, existem varias vias de melhoramento, visto existir agora
um robô fı́sico que consegue executar tarefas de vigilância sobre uma área conhecida. Um
dos possı́veis melhoramentos que pode resultar em trabalho futuro é introduzir métodos
de posicionamento complementares ao posicionamento fornecido pelos sensores locais
de forma a ter regularmente uma actualização à posição do robô confiável visto que os
sensores locais tem tendência a acomodar erros fazendo com que o posicionamento não
seja confiável.
Outra via de melhoramento é a adição de novas vias de comunicação que possam ver
utilizadas em diferentes ocasiões seja como alternativa, caso a placa primária não consiga
comunicar por qualquer razão, seja por pouca bateria disponı́vel. Esta adição poderia aumentar o tempo de utilização de uma bateria ou adicionar um nı́vel de tolerância a faltas
na área de comunicação sem fios.
Outro melhoramento seria a introdução de câmaras ou outros sensores que permitissem distinguir possı́veis intrusos de obstáculos no caminho. Com câmaras seria possı́vel
ao robô ter uma melhor percepção do ambiente em seu redor embora a mesma adição
necessite de ser estuda porque o processamento de imagem é uma tarefa pesada.
Outro melhoramento seria melhorar a forma como o mapa é gerido criando um mapa
detalhado da área em vez de um mapa total. Isso permitiria que podessem ser processados mapas muito maiores que a memoria do robô permite. Outro melhoramento seria na
área de segurança. Os protocolos actuais, entre o wormhole e wormhole bridge, wormhole
bridge e payload e comunicação entre robôs, não têm qualquer tipo de protecção que evite
que um atacante descubra o protocolo e altere o comportamento dos robôs a seu favor.
Outro melhoramento seria na área de navegação. O objectivo deste middleware é permitir que o robô procure intrusos e corte o caminho aos mesmos. Um melhoramento podia
ser optimizar os robôs de forma a serem capazes de seguir o intrusos quando o mesmo
tentasse a fuga.
Apêndice A
A.1
ID
Modelo de Gantt
Task
Mode
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Task Name
Duration
Start
Finish
26 Jul '10
T
Projecto
Primeira Iteração
Planeamento
Introdução ao
projecto
Recolha de
informação sobre
arquitectura
wormhole
259 days
109 days
38 days
5 days
Fri 01-10-10
Fri 01-10-10
Fri 01-10-10
Fri 01-10-10
Wed 28-09-11
Wed 02-03-11
Tue 23-11-10
Thu 07-10-10
9 days
Fri 08-10-10
Wed
20-10-10
Análise do
13 days
middleware
Análise do
11 days
hardware
disponivel
Fim do Planeamento 0 days
Thu 21-10-10 Mon
08-11-10
Tue 09-11-10 Tue 23-11-10
Design
Safety Task
Camada de
sensores
Fim do Design
Implementação
Preparação do
hardware
Instalação de
software
0 days
48 days
24 days
Wed 24-11-10 Wed 08-12-10
Wed 24-11-10 Fri 26-11-10
Mon
Wed
29-11-10
08-12-10
Wed 08-12-10 Wed 08-12-10
Thu 09-12-10 Mon 14-02-11
Thu 09-12-10 Tue 11-01-11
11 days
Thu 09-12-10 Thu 23-12-10
Project: Modelo de Gantt.mpp
Date: Thu 29-09-11
11 days
3 days
8 days
13 Sep '10
W
T
01 Nov '10
F
S
20 Dec '10
M
23-11
Tue 23-11-10 Tue 23-11-10
08-12
Task
External Milestone
Manual Summary Rollup
Split
Inactive Task
Manual Summary
Milestone
Inactive Milestone
Start-only
Summary
Inactive Summary
Finish-only
Project Summary
Manual Task
Deadline
External Tasks
Duration-only
Progress
Page 1
S
ID
Task
Mode
Task Name
Instalação de 2 days
IDEs
Configuração da 1 day
placa sem fios
17
18
Soldadura de 4 days
sensores
Instalação de 6 days
sensores,
ligadores e
conversores de
tensão
Fim da Preparação 0 days
do hardware
19
20
21
22
23
24
25
Duration
Start
Finish
26 Jul '10
T
16
Melhoramento do 5 days
módulo safety
task
Criação
da
11 days
camada de
sensores
Implementação da 8 days
interface com a
camada de
sensores
Fim da
0 days
Implementação
Testes e Avaliação 12 days
Project: Modelo de Gantt.mpp
Date: Thu 29-09-11
13 Sep '10
W
T
01 Nov '10
F
S
S
20 Dec '10
M
Fri 24-12-10
Mon
27-12-10
Tue 28-12-10 Tue 28-12-10
Wed
Mon
29-12-10
03-01-11
Tue 04-01-11 Tue 11-01-11
11-01
Tue 11-01-11 Tue 11-01-11
Wed
12-01-11
Wed
19-01-11
Tue 18-01-11
Wed
02-02-11
Thu 03-02-11 Mon
14-02-11
14-
Mon
Mon
14-02-11
14-02-11
Tue 15-02-11 Wed 02-03-11
Task
External Milestone
Manual Summary Rollup
Split
Inactive Task
Manual Summary
Milestone
Inactive Milestone
Start-only
Summary
Inactive Summary
Finish-only
Project Summary
Manual Task
Deadline
External Tasks
Duration-only
Progress
Page 2
ID
Task
Mode
26
27
28
29
30
31
32
33
34
35
36
Task Name
Duration
Start
Finish
26 Jul '10
T
Fim dos Testes e
Avaliação
Fim da Primeira
Iteração
Segunda Iteração
Planeamento
Análise do estado
do projecto
Definição do novo
passo
Anásile de
soluções de
navegação
Análise do
wormhole
Fim do Planeamento
0 days
0 days
48 days
19 days
1 day
1 day
3 days
0 days
Tue 29-03-11 Tue 29-03-11
38
39
Fim do Design
Implementação
Project: Modelo de Gantt.mpp
Date: Thu 29-09-11
0 days
15 days
01 Nov '10
F
S
Mon
Mon
07-03-11
07-03-11
Thu 10-03-11 Mon
14-03-11
Thu 24-03-11 Tue 29-03-11
37
T
Wed
Wed
02-03-11
02-03-11
Wed
Wed
02-03-11
02-03-11
Wed 02-03-11 Mon 09-05-11
Wed 02-03-11 Tue 29-03-11
Wed
Thu 03-03-11
02-03-11
4 days
Design
8 days
Wormhole e
3 days
camada de
sensores
Wormhole Bridge 5 days
13 Sep '10
W
Wed 30-03-11 Fri 08-04-11
Wed
Fri 01-04-11
30-03-11
Mon
Fri 08-04-11
04-04-11
Fri 08-04-11 Fri 08-04-11
Mon 11-04-11 Fri 29-04-11
Task
External Milestone
Manual Summary Rollup
Split
Inactive Task
Manual Summary
Milestone
Inactive Milestone
Start-only
Summary
Inactive Summary
Finish-only
Project Summary
Manual Task
Deadline
External Tasks
Duration-only
Progress
Page 3
S
20 Dec '10
M
ID
Task
Mode
40
41
42
43
44
45
46
47
48
49
50
51
52
53
Task Name
Duration
Start
Finish
26 Jul '10
T
Porte do
wormhole para o
novo hardware
Junção do
wormhole com a
camada de
sensores
Implementação
do componente
wormhole bridge
Fim da
Implementação
Testes e Avaliação
Fim dos Testes e
Avaliação
Fim de Segunda
Iteração
Terceira Iteração
Planeamento
Análise do estado
do projecto
Definição do novo
passo
Análise da TTFD
Task
Fim do Planeamento
Design
Project: Modelo de Gantt.mpp
Date: Thu 29-09-11
9 days
Mon
11-04-11
Thu 21-04-11
3 days
Fri 22-04-11
Tue 26-04-11
3 days
Wed
27-04-11
Fri 29-04-11
0 days
Fri 29-04-11
Fri 29-04-11
6 days
0 days
Mon 02-05-11 Mon 09-05-11
Mon
Mon
09-05-11
09-05-11
Mon
Mon
09-05-11
09-05-11
Tue 10-05-11 Mon 15-08-11
Tue 10-05-11 Thu 26-05-11
Tue 10-05-11 Wed
11-05-11
Mon
Mon
16-05-11
16-05-11
Wed
Thu 26-05-11
18-05-11
Thu 26-05-11 Thu 26-05-11
Fri 27-05-11 Wed 08-06-11
0 days
69 days
12 days
1 day
1 day
7 days
0 days
9 days
13 Sep '10
W
T
01 Nov '10
F
S
Task
External Milestone
Manual Summary Rollup
Split
Inactive Task
Manual Summary
Milestone
Inactive Milestone
Start-only
Summary
Inactive Summary
Finish-only
Project Summary
Manual Task
Deadline
External Tasks
Duration-only
Progress
Page 4
S
20 Dec '10
M
ID
Task
Mode
54
55
56
57
58
59
60
61
62
63
64
65
Task Name
Duration
Start
Finish
26 Jul '10
T
TTFD Task
Fim do Design
Implementação
Porte do módulo
TTFD task para a
FPGA
Adaptação do
componente
wormhole bridge
Adaptação do
componente
wormhole
Fim da
Implementação
Testes e Avaliação
Avaliação do
tempo demorado
pelo wormhole
Avaliação da
utilização da
interface série
Fim dos Testes e
Avaliação
Fim da Terceira
Iteração
Project: Modelo de Gantt.mpp
Date: Thu 29-09-11
9 days
0 days
27 days
15 days
Fri 27-05-11 Wed 08-06-11
Wed 08-06-11 Wed 08-06-11
Thu 09-06-11 Fri 15-07-11
Thu 09-06-11 Wed
29-06-11
7 days
Thu 30-06-11 Fri 08-07-11
5 days
Mon
11-07-11
Fri 15-07-11
0 days
Fri 15-07-11
Fri 15-07-11
21 days
10 days
Mon 18-07-11 Mon 15-08-11
Mon
Fri 29-07-11
18-07-11
11 days
Mon
01-08-11
Mon
15-08-11
0 days
Mon
15-08-11
Mon
15-08-11
Mon
15-08-11
Mon
15-08-11
0 days
13 Sep '10
W
T
01 Nov '10
F
S
Task
External Milestone
Manual Summary Rollup
Split
Inactive Task
Manual Summary
Milestone
Inactive Milestone
Start-only
Summary
Inactive Summary
Finish-only
Project Summary
Manual Task
Deadline
External Tasks
Duration-only
Progress
Page 5
S
20 Dec '10
M
ID
Task
Mode
66
67
68
Task Name
Duration
Start
Finish
26 Jul '10
T
Escrita do relatório
preliminar
Escrita do relatório
final
Fim do Projecto
Project: Modelo de Gantt.mpp
Date: Thu 29-09-11
19 days
102 days
1 day
13 Sep '10
W
T
01 Nov '10
F
S
Wed
Mon
24-11-10
20-12-10
Tue 10-05-11 Wed
28-09-11
Thu 29-09-11 Thu 29-09-11
Task
External Milestone
Manual Summary Rollup
Split
Inactive Task
Manual Summary
Milestone
Inactive Milestone
Start-only
Summary
Inactive Summary
Finish-only
Project Summary
Manual Task
Deadline
External Tasks
Duration-only
Progress
Page 6
S
20 Dec '10
M
01 Nov '10
S
20 Dec '10
M
T
07 Feb '11
W
T
28 Mar '11
F
16 May '11
S
M
S
04 Jul '11
T
W
T
22 Aug '11
F
02-03
23-11
08-12
Project: Modelo de Gantt.mpp
Date: Thu 29-09-11
Task
External Milestone
Manual Summary Rollup
Split
Inactive Task
Manual Summary
Milestone
Inactive Milestone
Start-only
Summary
Inactive Summary
Finish-only
Project Summary
Manual Task
Deadline
External Tasks
Duration-only
Progress
Page 7
S
S
01 Nov '10
S
20 Dec '10
M
T
07 Feb '11
W
T
28 Mar '11
F
16 May '11
S
M
S
04 Jul '11
T
W
T
22 Aug '11
F
11-01
14-02
Project: Modelo de Gantt.mpp
Date: Thu 29-09-11
Task
External Milestone
Manual Summary Rollup
Split
Inactive Task
Manual Summary
Milestone
Inactive Milestone
Start-only
Summary
Inactive Summary
Finish-only
Project Summary
Manual Task
Deadline
External Tasks
Duration-only
Progress
Page 8
S
S
01 Nov '10
S
20 Dec '10
M
T
07 Feb '11
W
T
02-03
28 Mar '11
F
16 May '11
S
M
S
04 Jul '11
T
W
T
22 Aug '11
F
02-03
29-03
08-04
Project: Modelo de Gantt.mpp
Date: Thu 29-09-11
Task
External Milestone
Manual Summary Rollup
Split
Inactive Task
Manual Summary
Milestone
Inactive Milestone
Start-only
Summary
Inactive Summary
Finish-only
Project Summary
Manual Task
Deadline
External Tasks
Duration-only
Progress
Page 9
S
S
01 Nov '10
S
20 Dec '10
M
T
07 Feb '11
W
T
28 Mar '11
F
16 May '11
S
M
S
04 Jul '11
T
W
T
22 Aug '11
F
29-04
09-05
09-05
26-05
Project: Modelo de Gantt.mpp
Date: Thu 29-09-11
Task
External Milestone
Manual Summary Rollup
Split
Inactive Task
Manual Summary
Milestone
Inactive Milestone
Start-only
Summary
Inactive Summary
Finish-only
Project Summary
Manual Task
Deadline
External Tasks
Duration-only
Progress
Page 10
S
S
01 Nov '10
S
20 Dec '10
M
T
07 Feb '11
W
T
28 Mar '11
F
16 May '11
S
M
S
04 Jul '11
T
W
22 Aug '11
F
T
08-06
15-07
15-08
15-08
Project: Modelo de Gantt.mpp
Date: Thu 29-09-11
Task
External Milestone
Manual Summary Rollup
Split
Inactive Task
Manual Summary
Milestone
Inactive Milestone
Start-only
Summary
Inactive Summary
Finish-only
Project Summary
Manual Task
Deadline
External Tasks
Duration-only
Progress
Page 11
S
S
01 Nov '10
S
20 Dec '10
M
T
Project: Modelo de Gantt.mpp
Date: Thu 29-09-11
07 Feb '11
W
T
28 Mar '11
F
16 May '11
S
M
S
04 Jul '11
T
W
T
22 Aug '11
F
Task
External Milestone
Manual Summary Rollup
Split
Inactive Task
Manual Summary
Milestone
Inactive Milestone
Start-only
Summary
Inactive Summary
Finish-only
Project Summary
Manual Task
Deadline
External Tasks
Duration-only
Progress
Page 12
S
S
Apêndice B
B.1
Manual for the use of H6090 board
Last Update: 23-08-2011.
This manual is for the Linux operating system and more specifically for the Ubuntu
distribution. The package names may differ depending on the distribution. Additionally
some alternatives are presented for the Windows operating system.
B.1.1
Uboot Setup
This configuration is needed if the board losses all flash data. If that is not the case skip
this section.
Before setting up the card you need to connect a serial cable form the computer you
are using to the card. The port that enables you to do this is the debug port (the only
female DB9 port available).
In order to access the Uboot configuration, the serial interface must be setup. Install
the following packages and all there dependencies:
setserial
minicom
Then run the following commands(the order is important): setserial /dev/ttyS0
minicom -s
Note: the first command targets the serial port, which is /dev/ttyS0. That part of the command may need to be changed depending on the system and port used.
The application minicom should launch and enable you to setup the following values:
Serial Device /dev/ttyS0
Bps/Par/Bits 115200,8,N,1
111
Apêndice B.
112
H/W,S/W Flow Control Off
After that, exit the application and it will try to connect with the board. If it’s successful, it will start printing numbers until you reset the board.
Reset the board and you should be able to see a count down on screen. Interrupt that
countdown by pressing any key to access to the Uboot menu. From there type the following:
setenv ipaddr 192.168.10.1
setenv serverip 192.168.10.2
setenv bootargs tftp 0x20008000 /uImage.bin\; tftp 0x20500000
/cramfs hello.img\; bootm 0x20008000;
saveenv
The last commands enable you to fully setup the uboot software. The IPs represent
the IP from the board’s Ethernet interface and the IP from the TFTP server. The file names of the third command represent the name of the kernel file and file-system image.
This configuration works well of testing but to make the changes permanent, consult the
H6042 manual for the memory address.
After the previous commands you may restart the board and it should be ready to
download the files.
For the Windows operating system you can use the hyper-terminal application or the
Basic Micro Studio to access the uboot configuration UI.
B.1.2
Image Setup
In order to install the Helix software, build the kernel and filesystem image, you first need
to install the following packages:
libgtk1.2
libc6-dev
fakeroot
This packages allow you to use the setup UI available with the Helix software.
Now install the Helix software by running the script at ”<Helix Dir>/install.sh”. If
you receive any error you probably didn’t install some of the packages mentioned above
(the version is important).
Apêndice B.
113
The script will install the software on ”/opt/hectronic/”by default and you need to install all the packages. If you need to install the software elsewhere be aware that you will
need to change the path on some scripts in order for them to work.
Now change to ”opt/hectronic/h6042”and run the following command:
make sample
The make sample command will build the kernel and filesystem images. You can
change the resulting image by editing the file ”hello.config”in the ”hello”directory (you
may add new packages from the available at the packages folder ”opt/hectronic/helixpackages/gcc-4.1.2-glibc-2.6.1/arm-920tsoftfloat-linuxgnueabi”) or the ”hello/fs/”directory
to add, edit or remove files. The current image should be available on the project’s files.
That image already sets up a ssh server, the network interfaces (192.168.10.1 and loopback) and automatically downloads the middleware files(if on the TFTP server folder)
and executes them.
B.1.3
Setting up the TFTP Server
In order to setup and TFTP Server you need to install the following packages:
tftpd
xinetd
Create the file /etc/xinetd.d/tftp and write the following: service tftp {
protocol = udp
port = 69
socket type = dgram
wait = yes
user = nobody
server = /usr/sbin/in.tftpd
server args = /tftpboot
disable = no
}
Make /tftpboot directory and change permissions so you don’t need root permissions
when copying files:
mkdir /tftpboot
chmod -R 777 /tftpboot
chown -R nobody /tftpbootStart tftpd
Apêndice B.
114
Start the TFTP Server through xinetd:
/etc/init.d/xinetd start
Note: you may need to use ”/etc/init.d/xinetd restart”the first time.
You now need to move the images to the TFTP folder and set up the network interface
to be on the same range as the board’s Ethernet card. Use the following command:
ifconfig eth0 192.168.10.2 netmask 255.255.255.0 up
Reset the board. It should be able to download the images and boot to Linux. If it
does you may remove the serial cable and connect the Ethernet cable. The user name and
password are ”root”.
For windows, there is an application that can also provide the TFTP server functionality in addiction to many other servers. The application is called TFTPD32 and is easy to
install and use.
B.1.4
Running the middleware
After logging in on the card you should be at the home directory for the root user which is
/root/. From there the middleware can be executed by typing the command: ”./wormhole
<ID> <configuration file>”. There are some configuration file samples available that
can be changed to serve the needs of the environment.
Apêndice C
C.1
Manual for the wireless configuration of the D-Link
G730ap
In the next sections, instruction on how to set up a ad-hoc wireless network are given.
Some of those instructions are only available for the Windows XP operating system.
C.1.1
Wireless card set up
The configuration gui(figure C.1) is available through the 192.168.10.10 (the default page
IP is 192.168.0.30). A username, ”admin”, and a password, <blank>, will be requested.
From the index page you should press the wireless option. On the wireless configuration page (figure C.2) you must enter a name for the network(SSID) and set the wireless
mode to ad-hoc. The other parameters are optional. The current configuration uses the
WEP security algorithm with the key “1234567890”.
C.1.2
Pc configuration
In order to set up the connection on Windows XP, you must access the wireless connection settings in the network connections window(figure C.3).
From there enter the Internet Protocol (TCP/IP) properties(figure C.4) and set the IP
address of this connection(figure C.5).For the current configuration type 192.168.10.2 on
the IP address field and 255.255.255.0 on the subnet mask.
After that switch to the wireless networks tab and press ”Add..”button(figure C.6).
On the wireless network properties window you should be able to enter the network
name(SSID), change the network to ad-hoc, and enter the network key (figure C.7).
115
116
Apêndice C.
Figura C.1: D-Link G730 Web configuration interface
Figura C.2: Wireless network configuration page
117
Apêndice C.
Figura C.3: The network connection in the windows XP OS
Figura C.4: Wireless connection properties
118
Apêndice C.
Figura C.5: Internet Protocol (TCP/IP) properties
Figura C.6: Wireless networks tab
119
Apêndice C.
Figura C.7: Setting a new wireless network
Apêndice C.
120
Apêndice D
D.1
FPGA configuration manual
This manual will help the user to create configurations and program the fpga.
D.1.1
Programmer connection to the PC and card
This manual will help the user to connect the programmer to the fpga and PC.
The programmer comes with six cables that need to be connected to the H6042 board.
Those cables must be connected to the pins available in the H4090 board. The cable/pin
correspondence can be observed in table D.1. All pin are in the J13 IO Header(figure
D.1 and D.2).
D.1.2
Create the configuration file for the PROM
This manual will help the user to create the configuration of the PROM available on the
H6042 card. This PROM contains the configuration that will be loaded by the FPGA
when the system is starting.
To create the PROM configuration file you need to first create the configuration file
form FPGA. After that and using the same program, Impact, you must select the ”Create
Cable Name
POW
TMS
TDI
TDO
TCK
GRN
Pin to be connected
37
38
39
40
41
42
Tabela D.1: Cable/Pin correspondence
121
122
Apêndice D.
Figura D.1: Cable connection pins
123
Apêndice D.
Figura D.2: Cable connection colors
124
Apêndice D.
Figura D.3: Impact Main Window
PROM File”option which is available on iMPACT Flow internal frame (figure D.3) or by
using the wizard.
On the PROM File formatter window(figure D.4) select the option Xilinx/Flash PROM
in the step 1 list and press the first right arrow. For the PROM family option select <Plataform Flash>, for Device(bits) option select <xcf04s[4M]> and press the second right
arrow. On the last step there is no need to change the default settings.
After pressing OK(figure D.5) the application will prompt for the configuration file
(figure D.6).
After selecting the file, the application will ask you if you want to add more files (figure D.7). Select the no option.
An image will be shown indicating how much space the configuration file will take on
the PROM. From this point you can generate the file by pressing >Generate File> (figure
D.8).
125
Apêndice D.
Figura D.4: PROM File Formatter Window
Figura D.5: Select configuration file 1
126
Apêndice D.
Figura D.6: Select configuration file 2
Figura D.7: Prompt for new configuration file addition
127
Apêndice D.
Figura D.8: PROM Configuration file creation 1
128
Apêndice D.
Figura D.9: PROM Configuration file creation 2
If the creating process is successful an indication will appear on the right of the window(figure D.9).
Apêndice D.
130
Abreviaturas
CPU
CTS
Central Processing Unit
Clear To Send
FPGA Field-Programmable Gate Array
GPS
Global Positioning System
HDL
Hardware Description Language
IDE
Integrated Development Environment
JNI
Java Native Interface
PC
Personal Computer
RTS
Request To Send
TTFD
Timely Timing Failure Detector
131
Bibliografia
[1] Eric Emmanuel Pascal Vial. Resilient middleware for a multi-robot team. Master’s
thesis, Faculdade de Ciências da Faculdade de Lisboa, 2010.
[2] Paulo Verissimo. Travelling through wormholes: a new look at distributed systems
models. SIGACT News, 37(1):66–81, 2006.
[3] M. Correia, P. Verı́ssimo, and N. F. Neves. The design of a COTS real-time distributed security kernel. In Proc. of the Fourth European Dependable Computing
Conference, Toulouse, France, October 2002.
[4] A. Casimiro, J. Rufino, L. Marques, M. Calha, and P. Verı́ssimo. Applying architectural hybridization in networked embedded systems. In Proceedings of the 7th IFIP
WG 10.2 International Workshop (SEUS 2009), Software Technologies for Embedded and Ubiquitous Systems, 2009.
[5] L. Marques, A. Casimiro, and M. Calha. Design and development of a proof-ofconcept platooning application using the hidenets architecture. In Proceedings of
the 2009 IEEE/IFIP Conference on Dependable Systems and Networks, pages 223–
228, Estoril, Lisboa, Portugal, June 2009.
[6] Rachid Guerraoui and Luis Rodrigues. Introduction to Reliable Distributed Programming. Springer, 2006.
[7] S. Ferrari G. Zhang and M. Qian. An information roadmap method for robotic sensor
path planning. JOURNAL OF INTELLIGENT & ROBOTIC SYSTEMS, 56:69–98,
2009.
[8] John Spletzer Jason Derenick and Ani Hsieh. An optimal approach to collaborative target tracking with performance guarantees. JOURNAL OF INTELLIGENT &
ROBOTIC SYSTEMS, 56:47–67, 2009.
[9] M. W. M. Gamini Dissanayake, Paul Newman, Steven Clark, Hugh F. Durrantwhyte, and M. Csorba. A solution to the simultaneous localization and map building
(slam) problem. IEEE Transactions on Robotics and Automation, 17:229–241, 2001.
133
Bibliografia
134
[10] Greg Welc and Gary Bisho. An introduction to the kalman filter. http://clubs.enscachan.fr/krobot/old/data/positionnement/kalman.pdf, 2009.
[11] Roger Du Plessis. Poor Man’s Explanation of Kalman Filtering: Or How I Stopped
Worrying & Learned to Love Matrix Inversion. Taygeta Scientific Inc, 1997.
[12] Filtering sensor data with a kalman filter.
http://interactivematter.eu/2009/12/filtering-sensor-data-with-a-kalman-filter/, 2009.
[13] Eric Vial and M. Calha. Resilient middleware for a multi-robot team. In InForum
2010, 2010.
[14] Drivers for the virtex fpga. http://www.linuxhq.com/kernel/v2.4/20/arch/cris/drivers/,
2011.
[15] Process sensitivity list vs synthesis-ability. http://vhdlguru.blogspot.com/2010/04/processsensitivity-list-vs-synthesis.html, 2011.
[16] Synthesis
error
signal
is
connected
to
multiple
drivers.
http://vhdlguru.blogspot.com/2010/03/synthesis-error-signal-is-connected-to.html,
2011.
[17] fpga4fun. http://www.fpga4fun.com/, 2011.
[18] Erik Jansson. HA001 Manual. Hectronic, 2009.
[19] Jonas Antoni. U-boot Manual. Hectronic, 2011.
[20] Daniel Skaborn. H6042 Manual. Hectronic, 2009.
[21] Daniel Skaborn. H4090 Manual. Hectronic, 2009.
[22] Mohit Hotwani. Project report for the bot board ii and h6042 cards. Project Report,
2010.
[23] Basicmicro.com. Basic Micro Studio Syntax Manual. Basic Micro, 2011.
Índice
Árvore de eventos, 9, 12
Java, 16
A4WD1, 22
Acelerómetro, 51, 58, 59, 64
Assembler, 16, 61
Atom Pro 28, 26, 41, 61, 65, 69
Micro Basic Studio, 17
Middleware, 6, 7, 9, 37
Middlware, 41
modelo incremental, 37
Basic, 15, 61
Baterias, 27
Bot Board II, 24, 28, 65
Busybox, 21
Navegação, 5, 13, 47
Objectivos, 2, 29, 37
Payload, 7, 11, 33, 41, 79
Payload Listener, 44
Promessa, 8, 43, 56, 79
C, 16
C++, 16, 61
Camada de Sensores, 34–36, 51, 53, 63, 67 Requisitos, 29, 30
RTS/CTS, 53, 55, 65
Módulos, 51, 63
Mensagens, 53, 65
Sabertooth 2x12, 23
Safety Task, 8, 47, 67
D-Link G730AP
Simbad, 10
Modos, 62
Simbad Robot Simulator, 20
D-Link G730ap, 27
Sincronização de vista, 12
Eclipse, 17
SRF05, 24
Estados do payload, 11
TTFD Task, 8, 41, 44, 47, 49, 50, 73, 75, 79
FPGA, 26, 41, 47, 62, 73, 75
U-Boot, 21
Gestão de tempo, 67, 69, 74
GHM-01, 23
Giroscópio, 51, 58, 59, 64
H4090, 26, 65, 70
H6042, 26, 60
Helix, 18
Wormhole, 2, 5, 7, 10, 31, 33, 41, 45, 49,
69
Módulos, 46, 80
Mensagens, 49
Wormhole Bridge, 41, 43, 50
Wormhole Listener, 44, 53, 67
Interface serı́e, 65
Xilinx ISE Design Suite, 19
136