RACmotion - DEEC - Universidade de Coimbra

Transcrição

UNIVERSIDADE DE COIMBRA
FACULDADE DE CIÊNCIAS E TECNOLOGIA
DEPARTAMENTO DE ENGENHARIA ELECTROTÉCNICA E DE COMPUTADORES
RACmotion
Controlo da Trajectória de um Robô
Omnidireccional para a RoboCup SSL
Autores
João Rodrigues
Sérgio Brandão
Coimbra – Portugal
2005
UNIVERSIDADE DE COIMBRA
FACULDADE DE CIÊNCIAS E TECNOLOGIA
DEPARTAMENTO DE ENGENHARIA ELECTROTÉCNICA E DE COMPUTADORES
RACmotion
Controlo da Trajectória de um Robô
Omnidireccional para a RoboCup SSL
Autores
João Rodrigues
Sérgio Brandão
Orientadores
Eng.º Rui Rocha
Prof. Doutor Jorge Dias
Relatório de Projecto apresentado no âmbito
do curso de Licenciatura em Engenharia
Electrotécnica e de Computadores, ramo de
Automação e Robótica, no Departamento de
Engenharia Electrotécnica e de Computadores
da Faculdade de Ciências e Tecnologia da
Universidade de Coimbra.
Coimbra – Portugal
2005
“Tudo o que uma pessoa pode imaginar,
outras podem tornar real.”
(Júlio Verne, 1828 – 1905)
RACmotion – Robótica Académica de Coimbra
Página 1 de 119
Agradecimentos
Este espaço é dedicado àqueles que deram a sua contribuição para que este projecto fosse
realizado. A todos eles deixamos aqui o nosso sincero agradecimento.
Em primeiro lugar queremos agradecer ao Eng. Rui Rocha pela forma como orientou o nosso
projecto. As notas dominantes da sua orientação, a utilidade das suas recomendações e a cordialidade
com que sempre nos recebeu foram fundamentais para a realização deste projecto. Estamos gratos pela
sua ajuda e também pela liberdade de acção que nos permitiu, a qual foi decisiva para que o mesmo
contribuísse para o nosso desenvolvimento pessoal.
Em segundo lugar, queremos agradecer ao Prof. Doutor Jorge Dias pela disponibilidade
concedida, pelas dicas oportunas e por todo o incentivo prestado ao longo do desenvolvimento deste
projecto.
Gostaríamos ainda de agradecer ao Eng. Jorge Lobo, pela cooperação prestada e pela
orientação sempre fundamental concedida no laboratório, que se mostrou elementar para o progresso
do trabalho que nos propusemos a realizar.
Deixamos também aqui uma palavra de agradecimento aos elementos da RAC, pela forma
como nos ajudaram e por nos terem transmitido algum conhecimento e interesse pelo desenvolvimento
do nosso projecto.
São também dignos de uma nota de apreço os nossos colegas de curso que nos ajudaram na
força e no espírito de trabalho, que nos acompanharam sempre nos trabalhos da RAC. A todos eles o
nosso obrigado.
Página 2 de 119
Resumo
Este projecto tem como principal objectivo o desenvolvimento de um sistema de controlo para o
movimento de um robô omnidireccional. O controlador a desenvolver será utilizado nos robôs da
RAC – Robótica Académica de Coimbra (equipa de futebol robótico do DEEC) que irá participar em
competições oficiais da RoboCup SSL (Small Size League). Contudo, outros trabalhos foram
desenvolvidos e implementados de modo a melhorar e complementar os objectivos da RAC. O
RACmotion foi um projecto ambicioso no que diz respeito à inserção do Futebol Robótico no DEEC.
Para que este Projecto alcançasse os seus objectivos, foi necessário planear, implementar, desenvolver
e inovar!
Este relatório de projecto descreve toda a arquitectura da RAC ligada ao controlo do movimento
do robô. São abordados tópicos de inteligência artificial, visão computacional, robótica, simulação,
comunicação, processamento distribuído e engenharia de software. Este relatório de projecto introduz
ao leitor o mundo do Futebol Robótico, analisando o estado da arte e a situação em Portugal num
contexto mundial. Os problemas referentes ao futebol robótico são também introduzidos. É apresentada
a arquitectura do sistema, especificando todos os seus módulos e abordando as suas principais
características. A implementação e desenvolvimento de algumas aplicações são relatadas em detalhe,
inclusive com algumas descrições de algoritmos e fórmulas utilizadas. Este documento relata todas as
fases do Projecto RACmotion, desde o projecto de engenharia à implementação e construção do robô.
Os testes e resultados são também analisados permitindo assim tirar diversas conclusões e
perspectivas de desenvolvimento.
Página 3 de 119
Índice
AGRADECIMENTOS ....................................................................................................................................2
RESUMO ..................................................................................................................................................3
ÍNDICE .....................................................................................................................................................4
ÍNDICE DE FIGURAS....................................................................................................................................7
ÍNDICE DE TABELAS ...................................................................................................................................9
INTRODUÇÃO ..........................................................................................................................................10
1.
FUTEBOL R OBÓTICO .....................................................................................................................11
2.
PROBLEMAS EMERGENTES AO FUTEBOL ROBÓTICO .........................................................................18
3.
RACMOTION ................................................................................................................................24
4.
ARQUITECTURA DE CONTROLO DA RAC .........................................................................................27
5.
ESTRUTURA DO ROBÔ ...................................................................................................................32
6.
HARDWARE ..................................................................................................................................38
7.
MODELO CINEMÁTICO ...................................................................................................................43
8.
O SIMULADOR RACBOT ................................................................................................................47
9.
CALIBRAÇÃO ...............................................................................................................................57
10.
SISTEMA DE CONTROLO ................................................................................................................61
11.
TESTES E RESULTADOS ................................................................................................................94
CONCLUSÃO.........................................................................................................................................102
REFERÊNCIAS E BIBLIOGRAFIA ...............................................................................................................104
ANEXO 1 ..............................................................................................................................................106
DIÁRIO AS BEIRAS
21 MARÇO 2005.................................................................................................107
DIÁRIO AS BEIRAS
1 MAIO 2005 ......................................................................................................108
DIÁRIO DE COIMBRA
1 MAIO 2005....................................................................................................109
ANEXO 2 ..............................................................................................................................................110
ARTIGO ROBÓTICA2005
OMNIDIRECTIONAL DRIVE MODELLING AND R OBOT C ONSTRUCTION .................111
ANEXO 3 ..............................................................................................................................................117
CÓDIGO F ONTE DAS APLICAÇÕES DESENVOLVIDAS..................................................................................118
ANOTAÇÕES .........................................................................................................................................119
Página 4 de 119
Sumário
AGRADECIMENTOS ....................................................................................................................................2
RESUMO ..................................................................................................................................................3
ÍNDICE .....................................................................................................................................................4
ÍNDICE DE FIGURAS....................................................................................................................................7
ÍNDICE DE TABELAS ...................................................................................................................................9
INTRODUÇÃO ..........................................................................................................................................10
1.
FUTEBOL R OBÓTICO .....................................................................................................................11
1.1. Histórico sobre Futebol Robótico.............................................................................................11
1.2. Organizações Internacionais ...................................................................................................12
1.2.1. Fira..................................................................................................................................................... 12
1.2.2. RoboCup ............................................................................................................................................ 13
1.3.
1.4.
1.5.
1.6.
Ligas de Competição...............................................................................................................14
RAC – Robótica Académica de Coimbra .................................................................................15
Futebol Robótico em Portugal .................................................................................................16
Estado da Arte ........................................................................................................................16
2.
PROBLEMAS EMERGENTES AO FUTEBOL ROBÓTICO .........................................................................18
2.1. Inteligência Artificial ................................................................................................................19
2.2. Visão Computacional ..............................................................................................................19
2.2.1. Visão Global .......................................................................................................................................20
2.2.2. Visão Local......................................................................................................................................... 20
2.3.
2.4.
2.5.
3.
3.1.
3.2.
3.3.
4.
4.1.
4.2.
4.3.
4.4.
5.
5.1.
5.2.
5.3.
6.
6.1.
6.2.
6.3.
6.4.
7.
7.1.
7.2.
7.3.
7.4.
8.
8.1.
8.2.
8.3.
Tolerância a Falhas.................................................................................................................22
Engenharia de Software..........................................................................................................22
Processamento Distribuído .....................................................................................................23
RACMOTION ................................................................................................................................24
Objectivos...............................................................................................................................24
Motivação ...............................................................................................................................24
Promoção e Divulgação ..........................................................................................................25
ARQUITECTURA DE CONTROLO DA RAC .........................................................................................27
Descrição................................................................................................................................27
Aplicação em Robôs com Diferentes Níveis de Autonomia......................................................30
Ferramentas de Desenvolvimento ...........................................................................................30
Divisão de Tarefas de Desenvolvimento..................................................................................30
ESTRUTURA DO ROBÔ ...................................................................................................................32
Plataforma ..............................................................................................................................32
Evolução .................................................................................................................................33
Protótipo .................................................................................................................................36
HARDWARE ..................................................................................................................................38
PC/104....................................................................................................................................38
Comunicação ..........................................................................................................................41
Motores e Caixas de Desmultiplicação ....................................................................................41
Baterias ..................................................................................................................................42
MODELO CINEMÁTICO ...................................................................................................................43
Modelo Cinemático RACbot ....................................................................................................43
Cinemática Inversa .................................................................................................................45
Cinemática Directa..................................................................................................................45
Modelos alternativos ...............................................................................................................46
O SIMULADOR RACBOT ................................................................................................................47
Motivação ...............................................................................................................................47
MATLAB Simulink ...................................................................................................................47
Implementação .......................................................................................................................48
8.3.1. Diagrama de Controlo .........................................................................................................................48
8.3.2. Visualização ....................................................................................................................................... 50
8.3.3. Testes e Resultados ........................................................................................................................... 52
Página 5 de 119
8.3.4. Conclusões.........................................................................................................................................56
9.
CALIBRAÇÃO ...............................................................................................................................57
9.1. Motivação ...............................................................................................................................57
9.2. Assumpções ...........................................................................................................................57
9.3. Procedimento de Calibração ...................................................................................................57
9.4. Testes em Simulação..............................................................................................................59
9.5. Conclusões .............................................................................................................................60
10.
SISTEMA DE CONTROLO ................................................................................................................61
10.1.
Sistema Operativo ...............................................................................................................61
10.1.1. Características Pretendidas...............................................................................................................61
10.1.2. Analise de Candidatos....................................................................................................................... 62
10.1.3. Sistema Operativo de Desenvolvimento e Teste ................................................................................ 64
10.1.4. Sistema Operativo da Plataforma ......................................................................................................65
10.1.5. Processo de Arranque do Sistema..................................................................................................... 67
10.2.
Sistema de Comunicações ..................................................................................................67
10.2.1. Protocolo IEEE 802.11b .................................................................................................................... 69
10.2.2. Protocolo TCP/IP .............................................................................................................................. 72
10.2.3. Protocolo de Comunicação RACprotocol ........................................................................................... 74
10.2.4. Driver do Dispositivo Wireless ........................................................................................................... 80
10.2.5. Configuração da Rede Sem Fios ....................................................................................................... 81
10.3.
Funções de I/O na Placa MESA 4i65 ...................................................................................82
10.3.1. Características do Firmware softDMC................................................................................................82
10.3.2. Calibração do Controlador PID .......................................................................................................... 83
10.3.3. Implementação do softDMC Loader...................................................................................................84
10.4.
Controlador de Movimento...................................................................................................85
10.4.1. Arquitectura do Controlador............................................................................................................... 86
11.
TESTES E RESULTADOS ................................................................................................................94
11.1.
Competições e Eventos .......................................................................................................94
11.2.
Testes e Ensaios .................................................................................................................94
11.2.1. Arranque e Movimento do Robô ........................................................................................................ 95
11.2.2. Execução de Trajectórias .................................................................................................................. 98
11.2.3. Procedimento de Calibração............................................................................................................ 100
11.2.4. Controlo de Disparo e Carga do Kicker ............................................................................................ 100
11.2.5. Conclusões..................................................................................................................................... 100
11.3.
Perspectivas de Desenvolvimento Futuro ..........................................................................101
CONCLUSÃO.........................................................................................................................................102
REFERÊNCIAS E BIBLIOGRAFIA ...............................................................................................................104
ANEXO 1 ..............................................................................................................................................106
DIÁRIO AS BEIRAS
21 MARÇO 2005.................................................................................................107
DIÁRIO AS BEIRAS
1 MAIO 2005 ......................................................................................................108
DIÁRIO DE COIMBRA
1 MAIO 2005....................................................................................................109
ANEXO 2 ..............................................................................................................................................110
ARTIGO ROBÓTICA2005
OMNIDIRECTIONAL DRIVE MODELLING AND R OBOT C ONSTRUCTION .................111
ANEXO 3 ..............................................................................................................................................117
CÓDIGO F ONTE DAS APLICAÇÕES DESENVOLVIDAS..................................................................................118
ANOTAÇÕES .........................................................................................................................................119
Página 6 de 119
Índice de figuras
Figura 1.1.1 – RoboCup 2004 Lisboa. ......................................................................................................................................11
Figura 1.2.1.1 – FIRA Cup 2004 Corea. ...................................................................................................................................12
Figura 1.2.2.1 – ASIMO Honda, RoboCup 2003 Pádua. ............................................................................................................13
Figura 1.2.2.2 – RoboCup 2004 Lisboa. ...................................................................................................................................14
Figura 1.3.1 – Ligas de Competição, RoboCup 2004 Lisboa. .....................................................................................................15
Figura 1.4.1 – RAC - Robótica Académica de Coimbra. ............................................................................................................15
Figura 1.5.1 – Festival Nacional de Robótica 2005....................................................................................................................16
Figura 1.6.1 – RoboCup SSL (Small Size League). ...................................................................................................................17
Figura 2.1 – Robocup: Sony Legged Robot League e Humanoid League. ..................................................................................18
Figura 2.1.1 – Sistema computacional de IA utilizado na Robocup99 para SSL. .........................................................................19
Figura 2.2.1 – Marcações coloridas utilizadas pela RAC............................................................................................................19
Figura 2.2.1.2 – Sistema computacional de IA utilizado na Robocup99 para SSL........................................................................20
Figura 2.2.2.1 – Sistema de Visão Local utilizado em diversos robôs destinados ao Futebol Robótico. ........................................21
Figura 3.3.1 – Sessão de palestras do Atelier Robótica. ............................................................................................................25
Figura 3.3.2 – Atelier laboratorial, demonstração RAC. .............................................................................................................26
Figura 3.3.3 – Páginas WEB do Atelier e projecto RACmotion. ..................................................................................................26
Figura 4.1.1 – Diagrama global da arquitectura de controlo. ......................................................................................................27
Figura 4.1.2 – Diagrama de sequência para a actualização de WM............................................................................................28
Figura 4.1.3 – Diagrama da arquitectura do agente robótico......................................................................................................28
Figura 4.1.4 – Exemplo de diagrama de sequência para as acções ao nível táctico do robô ........................................................29
Figura 4.1.5 – Exemplo de diagrama de sequência para a execução de uma acção básica.........................................................29
Figura 4.1.6 – Exemplos de informação e de acções de controlo ...............................................................................................29
Figura 5.1.1 – Estrutura do RACbot. ........................................................................................................................................32
Figura 5.1.2 – Plataforma em alumínio do RACbot....................................................................................................................33
Figura 5.2.1 – Fixação do PC na plataforma base do RACbot....................................................................................................33
Figura 5.2.2 – Fixação do disco FUJITSU na plataforma base do RACbot..................................................................................33
Figura 5.2.3 – Chapa de apoio de ligações ao RACbot..............................................................................................................34
Figura 5.2.4 – Extensão de ligação à fonte de alimentação da bancada. ....................................................................................34
Figura 5.2.5 – Inserção das baterias no RACbot. ......................................................................................................................35
Figura 5.2.6 – Rodas omnidireccionais adoptadas no RACbot. ..................................................................................................35
Figura 5.2.7 – Roda plástica e roda acrílica. .............................................................................................................................35
Figura 5.2.8 – Montagem do protótipo da RAC. ........................................................................................................................36
Figura 5.3.1 – Protótipo RACbot. .............................................................................................................................................37
Figura 6.1.1 – Módulos do PC/104 no RACbot..........................................................................................................................38
Figura 6.1.2 – Placa M570 da SECO para PC/104. ...................................................................................................................39
Figura 6.1.3 – Placa de programação I/O 4I65 da MESA para PC/104. ......................................................................................39
Figura 6.1.4 – Placa H-Bridge de 4 canais para ligação à placa 4I65..........................................................................................40
Figura 6.1.5 – Fonte de Alimentação V104 da TRI-M para PC/104.............................................................................................40
Figura 6.1.6 – Adaptador Compact Flash IDE CFADPT-CS da MESA para PC/104. ...................................................................40
Figura 6.2.1 – Adaptador Wireless USB da Edimax EW-7117U. ................................................................................................41
Figura 6.3.1 – Micro-motor DC de 12V série SR da Faulhaber. ..................................................................................................41
Figura 6.3.2 – Caixa de desmultiplicação para motores série SR da Faulhaber...........................................................................42
Figura 6.4.1 – Packs de baterias utilizadas no protótipo RACbot................................................................................................42
Figura 7.1.1 – Modelo Cinemático do RACbot. .........................................................................................................................43
Figura 7.1.2 – Desfasamento da roda....................................................................................................................................44
Figura 7.4.1 – Diversos tipos de robôs utilizados em Futebol Robótico. ......................................................................................46
Figura 8.2.1 – MATLAB - Simulink. ..........................................................................................................................................47
Figura 8.3.1 – Fase de implementação do Simulador RACbot. ..................................................................................................48
Figura 8.3.1.2 – Diagrama de Controlo do Simulador RACbot....................................................................................................49
Figura 8.3.2.1 – Simulação da trajectória do robô, set-point [7 1 1 0.5, 10 3 1 0, 12 6 1 -0.5, 11 9 1 0, 9 10 1 0.5].........................50
Figura 8.3.2.2 – Velocidade dos três motores segundo o set-point anterior.................................................................................50
Figura 8.3.2.3 – Variação dos parâmetros vx, vy e segundo o set-point anterior. ......................................................................51
Figura 8.3.2.4 – Orientação do robô ao longo do tempo segundo o set-point anterior. .................................................................51
Figura 8.3.2.5 – Animação vectorial efectuada pelo Simulador RACbot......................................................................................52
Figura 8.3.2.6 – Animação efectuada ao Simulador RACbot. .....................................................................................................52
Figura 8.3.3.1 – Rotação do referencial do robô em . ..............................................................................................................53
Figura 8.3.3.2 – Rotação do referencial do robô em utilizada na simulação..............................................................................53
Figura 8.3.3.3 – Simulação do movimento do robô, set-point [10 10 1 0.05, 10 0 1 0, 20 0 1 -0.1, 20 10 1 0]. ...............................54
Figura 8.3.3.4 – Simulação do movimento do robô, set-point [7 1 1 0.5, 10 3 1 0, 12 6 1 -0.5, 11 9 1 0, 9 10 1 0.5]. ......................54
Figura 8.3.3.5 – Simulação do movimento do robô, set-point [0.6 0 1 0, 0.6 0.4 1 0, 0 0.4 1 0, 0 0.2 1 0]. .....................................55
Figura 8.3.3.6 – Variação dos parâmetros vx, vy e bem como a variação das velocidades dos três motores. .............................55
Figura 9.1.1 – Desfasamento da roda....................................................................................................................................57
Figura 9.3.1 – Dependência entre desfasamentos em relação a uma determinada trajectória. .....................................................58
Figura 9.4.1 – Alterações efectuadas no simulador para simular o processo de calibração. .........................................................59
Figura 9.4.2 – Procedimento de calibração utilizando o simulador RACbot. ................................................................................60
Figura 10.1.3.1 – Sistema de desenvolvimento e teste. .............................................................................................................65
Figura 10.2.1.1 – Router wireless 802.11b................................................................................................................................69
Figura 10.2.1.2 – Sobreposição de canais no protocolo 802.11b................................................................................................71
Figura 10.2.3.1 – Nível inferior da arquitectura de controlo da RAC...........................................................................................74
Figura 10.2.5.1 – Configuração da rede sem fios. .....................................................................................................................81
Figura 10.3.1 – MESA 4i65......................................................................................................................................................82
Figura 10.3.2.1 – Interface gráfica de calibração DMCtune. ....................................................................................................... 83
Figura 10.3.3.1 – Fase de arranque no sistem a de desenvolvimento..........................................................................................84
Figura 10.4.1.1 – Arquitectura geral da aplicação de controlo ....................................................................................................86
Figura 10.4.1.2 – Diagrama de actividade da aplicação global ...................................................................................................87
Página 7 de 119
Figura 10.4.1.3 – Diagrama de actividade do processo 1...........................................................................................................88
Figura 10.4.1.4 – Diagrama de actividade do processo 2...........................................................................................................90
Figura 10.4.1.5 – Diagrama de actividade do controlo por comandos de velocidade ...................................................................91
Figura 10.4.1.6 – Diagrama de actividade do sistema de polling dos dados da câmara ...............................................................91
Figura 10.4.1.7 – Diagrama de actividade do controlo de trajectórias .........................................................................................92
Figura 10.4.1.8 – Diagrama de actividade do controlador de rotação..........................................................................................93
Figura 10.4.1.9 – Diagrama de actividade do controlador de carga do kicker ..............................................................................93
Figura 11.1.1 – Robótica 2005. ................................................................................................................................................94
Figura 11.2.1.1 – Testes de movimento efectuados ao robô (varias direcções num raio de 1.2m). ...............................................95
Figura 11.2.1.2 – Posição final do robô após a introdução do set-point C [0.6 1.03923 0.1 0].......................................................96
Figura 11.2.1.3 – Testes de movimento efectuados ao robô para os set-points H e L (vmed=1m/s)................................................96
Figura 11.2.1.4 – Testes de movimento efectuados ao robô para os set-points B e C (vmed=1m/s). ..............................................97
Figura 11.2.1.5 – Frente de ataque do robô. .............................................................................................................................98
Figura 11.2.2.1 – Execução de trajectórias. ..............................................................................................................................98
Figura 11.2.2.2 – Execução de trajectórias. ..............................................................................................................................99
Figura 11.2.2.3 – Trajectória utilizada nos testes efectuados ao robô .........................................................................................99
Figura 11.2.2.4 – Trajectória efectuada pelo robô ...................................................................................................................100
Página 8 de 119
Índice de tabelas
Tabela 10.1.4.1 – Ferram entas de sistema presentes em initrd..................................................................................................66
Tabela 10.2.1 – Pilha protocolar da plataforma RAC. ................................................................................................................69
Tabela 10.2.1.1 – Canais 802.11 e a sua disponibilidade em vários países. ...............................................................................71
Tabela 10.2.2.1 – Cabeçalho de um pacote IPv4. .....................................................................................................................73
Tabela 10.2.2.2 – Cabeçalho de um pacote TCP. .....................................................................................................................73
Tabela 10.2.3.2.1 – Estrutura da mensagem. ...........................................................................................................................74
Tabela 10.2.3.2.1.1.1 – Mensagem OpenSess. ........................................................................................................................75
Tabela 10.2.3.2.1.2.1 – Mensagem SessQuit. ..........................................................................................................................75
Tabela 10.2.3.2.1.2.2 – Condições de erro da mensagem SessQuit...........................................................................................76
Tabela 10.2.3.2.2.1.1 – Mensagem GiveState. .........................................................................................................................76
Tabela 10.2.3.2.2.2.1 – Mensagem SetVelocity. .......................................................................................................................76
Tabela 10.2.3.2.2.3.1 – Mensagem KickBall. ............................................................................................................................77
Tabela 10.2.3.2.2.4.1 – Mensagem Setdribbling. ......................................................................................................................77
Tabela 10.2.3.2.2.5.1 – Mensagem Halt. ..................................................................................................................................77
Tabela 10.2.3.2.2.6.1 – Mensagem SetTrajectory. ....................................................................................................................78
Tabela 10.2.3.2.2.7.1 – Mensagem SetParms. .........................................................................................................................78
Tabela 10.2.3.2.2.8.1 – Mensagem Position. ............................................................................................................................79
Tabela 10.2.3.2.3.1.1 – Mensagem State. ................................................................................................................................79
Tabela 10.2.3.2.3.2.1 – Mensagem GivePosition. .....................................................................................................................80
Tabela 10.3.3.1 – Funções implementadas para o carregador Linux ..........................................................................................85
Tabela 10.4.1.1 – Classificação dos comandos de controlo ....................................................................................................... 89
Tabela 10.4.1.2 – Influencia dos comandos nos controladores ..................................................................................................89
Tabela 11.2.1.1 – Conjunto de pontos utilizados no ensaio do movimento do robô......................................................................95
Tabela 11.2.1.2 – Cálculo da média das distancias das varias amostras aos pontos B e C..........................................................97
Tabela 11.2.2.1 – Conjunto de pontos utilizados no ensaio de uma trajectória do robô. ...............................................................99
Página 9 de 119
Introdução
O Futebol Robótico é um desafio para a Inteligência Artificial e Robótica em geral. No mundo
inteiro, o Futebol Robótico exerce um fascínio inexplicável sobre as pessoas. Um jogo de Futebol
Robótico pode ser visto como uma plataforma para incentivar o desenvolvimento tecnológico e o
desenvolvimento de conceitos científicos de diversas áreas do conhecimento humano. Para que uma
equipa de robôs efectivamente realize uma partida de futebol, diversas tecnologias e áreas do saber
devem ser desenvolvidas e integradas, como a Robótica, Inteligência Artificial, Visão Computacional,
Sistema de Comunicação e Processamento em Tempo Real, entre outras. Assim, um jogo de Futebol
Robótico constitui uma tentativa de estimular o desenvolvimento da Robótica Inteligente, fornecendo um
sistema dinâmico complexo, onde uma ampla gama de tecnologias pode ser integrada e testada.
O presente Projecto é intitulado RACmotion, um Projecto que tem como principal objectivo o
controlo da trajectória do movimento de um robô omnidireccional. O controlador a desenvolver será
utilizado nos robôs da RAC - Robótica Académica de Coimbra (equipa de futebol robótico do
DEEC) - que irá participar em competições oficiais da RoboCup SSL (Small-Size League).
O capítulo 1 apresenta o Futebol Robótico, descreve-o como um problema padronizado e
analisa o Estado da Arte. No capítulo 2 é introduzido todo um conjunto de problemas emergentes ao
Futebol Robótico. O RACmotion é introduzido no capítulo 3, onde são definidos os seus objectivos, bem
como, as suas motivações, promoções e divulgações. A arquitectura do sistema é descrita no capítulo 4.
Segue-se o capítulo 5 que descreve a plataforma do robô adoptada pela equipa da RAC, explicando a
sua evolução e alguns detalhes do seu desenvolvimento. O capítulo 6 aborda questões de hardware,
bem como, alguns componentes usados no robô. O capítulo 7 introduz os modelos cinemáticos
adoptados. De seguida, é apresentado no capítulo 8 o desenvolvimento do Simulador RACbot,
explicando o seu funcionamento e alguns dos seus objectivos, alguns testes e conclusões também são
descritos. A questão da calibração do robô é abordada no capítulo 9. A implementação do Sistema de
Controlo é descrita no capítulo 10. Finalmente, o capítulo 11 apresenta testes feitos ao sistema,
relatando alguns resultados obtidos. O relatório é finalizado com a apresentação das conclusões. Os
anexos são ilustrados no final.
Página 10 de 119
1. Futebol Robótico
Esta secção introduz o universo do Futebol Robótico. Primeiro, é apresentado o histórico sobre
o tema. A seguir, são identificadas as principais entidades mundiais que o organizam e promovem.
Posteriormente, é feita uma análise sobre o Futebol Robótico em Portugal, identificando algumas das
principais equipas, universidades, organizações e eventos existentes no país. Finalmente, o capítulo
termina com uma análise do estado da arte.
1.1. Histórico sobre Futebol Robótico
A ideia de robôs jogarem futebol foi mencionada, pela primeira vez, num artigo de 1992,
intitulado “On Seeing Robots” [MACKWORTH, 1993]. Neste artigo, o investigador descreve o uso do
Futebol Robótico para testar um sistema de visão robótica e desenvolver algoritmos de planeamento de
trajectórias e controlo de movimento. Nos três anos seguintes, a ideia foi-se popularizando e
amadurecendo no meio académico.
Em 1995, um grupo de investigadores japoneses da Osaka University [OSAKA] e do Sony
Computer Science Lab [SONYCSLAB], propõem utilizar o futebol robótico como novo problema-padrão
para a pesquisa na Inteligência Artificial e na Robótica. O anúncio é feito num artigo, “RoboCup: The
Robot World Cup Initiative” [KITANO, 1995], publicado na International Joint Conference on Artificial
Intelligence (IJCAI) de 1995. A IJCAI [IJCAI] é uma das principais conferências internacionais para
investigadores de Inteligência Artificial, que tem vindo a ser realizada a cada dois anos desde 1969.
Simultaneamente, o professor coreano Jong-Hwan Kim, do Korea Advanced Institute of Science and
Technology (KAIST) [KAIST], propõe a realização do Micro-Robot World Cup Soccer Tournament.
Finalmente, em 1996, foram realizados os primeiros campeonatos internacionais, na Corea e no
Japão. Desde então, equipas de futebol robótico surgiram em inúmeras universidades e centros de
investigação em todo o mundo. Actualmente, existem duas grandes federações que organizam e
promovem o Futebol Robótico: The RoboCup Federation (RoboCup) [ROBOCUP] e Federation of
International Robot-Soccer Association (FIRA) [FIRA]. Os seus objectivos são promover a pesquisa e o
desenvolvimento da inteligência artificial, robótica, visão computacional e muitas outras áreas do
conhecimento humano através do Futebol Robótico.
Figura 1.1.1 – RoboCup 2004 Lisboa.
Para atingir esse objectivo, tanto a FIRA como a RoboCup promovem, anualmente, competições
internacionais. Cada federação possui as suas próprias regras e categorias. Os robôs podem variar em
número, tamanho e forma. Algumas categorias incluem também robôs humanóides bípedes. O campo
de jogo e a bola podem ter tamanhos diferentes. De um modo geral, um jogo de futebol robótico
funciona da seguinte forma: deve existir um sistema de inteligência artificial para controlar os robôs; a
equipa também precisa de um sistema de visão para percepcionar o que está a ocorrer durante o jogo;
finalmente, existem os robôs propriamente ditos, que executam as acções determinadas pelo
controlador.
Página 11 de 119
A forma como estas três tarefas básicas podem ser desenvolvidas abrange uma ampla gama de
tópicos de pesquisa. Por exemplo, a Inteligência Artificial pode ser implementada utilizando Algoritmos
Genéticos, Redes Neurais ou Agentes Inteligentes [RUSSEL, 1995]. O Processamento de Imagens, por
sua vez, pode ser realizado através de diferentes métodos [GONZALEZ, 2002], tanto num sistema de
visão global, com a câmara colocada sobre o campo, como num sistema local, onde cada robô possui a
sua própria câmara. Finalmente, a concepção e construção dos robôs [VELOSO, 2000] envolve um
conhecimento substancial de Electrónica e Mecânica. Uma equipa de futebol robótico avançada
desenvolve investigação em diversas áreas, além daquelas que temos vindo a mencionar,
nomeadamente no sistema eléctrico dos robôs. O futebol de robótico pode então ser visto como uma
plataforma de pesquisa e desenvolvimento em diversas áreas, especialmente pela comunidade
académica.
1.2. Organizações Internacionais
A RoboCup e a FIRA são as duas maiores organizações internacionais que promovem o Futebol
Robótico. Estas federações realizam anualmente campeonatos mundiais, acompanhados de congressos
com publicações de artigos técnicos. De seguida a FIRA e RoboCup são apresentadas, analisando os
seus objectivos e dando uma visão geral sobre as suas categorias e regras de competição.
1.2.1. Fira
FIRA é a sigla de Federation of International Robot-soccer Association. Esta organização foi
estabelecida em 5 de Junho de 1997. O seu objectivo é “levar o espírito da ciência e da tecnologia ao
público em geral e à nova geração através do jogo de futebol robótico”. Nas palavras do idealizador e
criador da FIRA, o professor Jong-Hwan Kim, o futebol robótico pode ser visto como uma competição de
tecnologia robótica avançada, dentro de um espaço restrito. Ela oferece uma área desafiante para a
nova geração e para investigadores que trabalham com sistemas de robôs móveis autónomos.
Espera-se que, através destes eventos, se possa compreender melhor os conceitos científicos e os
avanços tecnológicos envolvidos. Os resultados das pesquisas desenvolvidas, irão ajudar certamente a
humanidade de diversas formas.
Figura 1.2.1.1 – FIRA Cup 2004 Corea.
A FIRA possui seis categorias, descritas a seguir. Maiores detalhes sobre as regras de cada
categoria podem ser encontrados em [FIRA].
•
•
•
HuroSot: Humanoid Robot World Cup Soccer Tournament. Utiliza robôs humanóides com duas
pernas. O tamanho máximo dos robôs é de 150 cm, pesando até 30 Kg.
KheperaSot: o jogo é disputado por duas equipas com apenas 1 robô cada. O robô é
totalmente autónomo, com sistema de visão local. O robô utilizado nesta categoria é o Khepera
[KTEAM], produzido por uma empresa suíça. A bola utilizada no jogo é uma bola de ténis
amarela. O tamanho do campo é de 130 cm x 90 cm.
MiroSot: Micro Robot World Cup Soccer Tournament. Nesta categoria, a partida é disputada por
duas equipas, cada uma composta por três robôs, sendo que um deles pode ser o guarda-
Página 12 de 119
•
•
•
redes. É permitido o uso de apenas um computador para controlar os robôs de uma equipa. De
acordo com as regras, o volume ocupado pelo robô não pode exceder um cubo de aresta igual a
7,5 cm. A bola utilizada na partida é uma bola de golfe laranja. O tamanho do campo é de
150 cm x 130 cm para a Small League e de 220 cm x 180 cm para a Middle League.
NaroSot: a partida é disputada por duas equipas, cada uma composta por cinco robôs, podendo
um deles ser o guarda-redes. É permitido apenas um computador para controlar cada equipa. O
tamanho máximo de cada robô é de 4 cm x 4 cm x 5,5 cm. É utilizada uma bola de ping-pong
laranja. O tamanho do campo é de 130 cm x 90 cm.
RoboSot: nesta categoria, a partida é disputada por duas equipas, cada uma composta por um
a três robôs. Um dos robôs pode ser o guarda-redes. Cada robô pode ser totalmente
independente ou semi-autónomo. O tamanho máximo dos robôs é de 20 cm x 20 cm x 40 cm. A
bola utilizada no jogo é uma bola de ténis amarela. O tamanho do campo é de 220 cm x 180 cm.
SimuroSot: categoria de simulação de Futebol Robótico. Composta por um servidor que simula
o ambiente do jogo de futebol (campo de jogo, robôs, bola, etc.) e por dois programas clientes
com as estratégias de jogo de cada equipa. A partida é visualizada numa tela gráfica. As
equipas podem criar as suas próprias estratégias e competir uns com os outros sem utilizar um
hardware específico. Os jogos podem ser disputados por equipas de 5 ou 11 jogadores cada.
1.2.2. RoboCup
A RoboCup é uma iniciativa internacional, promovida pela comunidade científica na área da
Robótica, que procura servir-se do futebol para desenvolver actividades de investigação na área da
Robótica Móvel Inteligente, bem como estimular o ensino da Robótica junto de jovens estudantes dos
níveis de ensino secundário e superior. Organiza regularmente competições internacionais
(campeonatos europeus e mundiais), promovendo assim a troca científica de ideias a nível mundial
[RAC].
Figura 1.2.2.1 – ASIMO Honda, RoboCup 2003 Pádua.
Para o desenvolvimento de uma equipa de futebol robótico é necessário um elevado conjunto
de tecnologias. Desta forma, a investigação em futebol robótico e a competição internacional
associada – RoboCup – atraíram a participação regular de algumas das melhores empresas,
laboratórios de investigação e universidades mundiais, incluindo a Sony, Honda, SGI, Philips, GMD e as
universidades de Carnegie Mellon, Cornell, Freiburg, Karlsruhe, UNSW, Tsinghua, entre outros.
A RoboCup traz consigo um objectivo bastante ambicioso: defrontar em 2050 uma equipa de
futebol humana. Trata-se de um objectivo difícil de atingir. Mas com a manifestação e desenvolvimento
de pequenas iniciativas como a RAC, estamos a lutar por uma comunidade tecnológica cada vez maior,
que leva a um acentuado crescimento do poder de inovação e da ciência.
Página 13 de 119
Figura 1.2.2.2 – RoboCup 2004 Lisboa.
A RoboCup possui três grandes ligas: RoboCupSoccer, RoboCupRescue e RoboCupJunior.
A RoboCupRescue envolve a aplicação de robôs em situações práticas. Cada ano é lançado um desafio
diferente, como por exemplo, o resgate de vítimas num cenário de destruição urbana causada por um
terramoto. Já a liga RoboCupJunior foi criada para públicos jovens e envolve competições com robôs
comerciais, que podem ser comprados prontos a usar. A RoboCupSoccer, por sua vez, possui cinco
categorias diferentes, descritas a seguir. Maiores detalhes sobre as regras de cada categoria e das
demais ligas pode ser encontrada em [ROBOCUP]. As categorias são:
•
•
•
•
•
Simulation League: Futebol de Robôs simulados.
Small Size Robot League (F-180): composta por duas equipas de até cinco robôs cada. Os
robôs utilizados nesta categoria devem caber dentro de um cilindro de 18 cm de diâmetro e
22,5 cm de altura. Podem ser completamente autónomos, ou podem ser controlados por um
computador central que utiliza uma rede de computadores para os controlar. O tamanho do
campo é de 490 cm x 340 cm. É utilizada uma bola de golfe cor-de-laranja.
Middle Size Robot League (F-2000): composta por duas equipas com o mínimo de 7 e, no
máximo, 11 jogadores, sendo um deles o guarda-redes. O tamanho de cada robô é tal que a
sua projecção no chão deve caber dentro de um quadrado de 50 cm de lado. O peso máximo de
cada robô é de 40 kg. O tamanho do campo é de 1200 cm x 800 cm.
Sony Legged Robot League: possui duas equipas, cada uma composta por 4 jogadores,
incluindo o guarda-redes. Os robôs utilizados são os “cãezinhos” AIBO da Sony [AIBO]. O jogo é
composto por dois tempos de 10 minutos cada.
Humanoid League: são utilizados robôs humanóides ou antropomórficos compostos por duas
pernas, dois braços, um tronco e uma cabeça. É utilizada uma bola de futebol oficial da
Federação Internacional de Futebol Associação (FIFA). O tamanho dos robôs e do campo varia
conforme as sub-categorias desta liga.
1.3. Ligas de Competição
Conforme foi descrito anteriormente, o futebol robótico inclui diversas ligas que se dividem em
dois tipos: ligas robóticas (robôs pequenos, médios, “cães” e humanóides) e a liga de simulação.
Cada liga tem um conjunto próprio de desafios de investigação, com ênfase em determinados
tópicos necessários para colocar uma equipa de robôs a disputar uma partida de futebol. A liga de robôs
pequenos da RoboCup (Small Size League) é a liga que abrange o nosso projecto. Trata-se de uma liga
que realça a dinâmica e a velocidade destes robôs devido à sua leve e compacta constituição. Para
além de limitados no tamanho (diâmetro máximo de 18 cm e altura máxima de 22,5 cm) possuem
também limitações na capacidade sensorial e de processamento, levando a comportarem-se como
simples actuadores no sistema de jogo em si. Com regras estabelecidas para cumprir, esta liga
caracteriza-se por gerar grande espectáculo entre os participantes e a competição em si, mas nunca
esquecendo o seu valor cientifico.
Para além de outras ligas de igual importância, que se conjugam entre si, como é o caso da liga
de simulação, devemos realçar que os desafios no domínio do futebol robótico são muito superiores aos
desafios colocados por alguns problemas standard da Inteligência Artificial, como o xadrez. No futebol
robótico o mundo é dinâmico, parcialmente inacessível aos robôs virtuais, contínuo, não determinístico,
multi-objectivo, parcialmente cooperativo e adverso.
Página 14 de 119
Figura 1.3.1 – Ligas de Competição, RoboCup 2004 Lisboa.
As diversas ligas da RoboCup foram projectadas de forma a contemplarem um conjunto elevado
de complexidades, mantendo o custo e a dimensão do problema acessível aos grupos de investigação
em Robótica e Inteligência Artificial.
Os problemas de investigação colocados pela RoboCup, cobrem uma vasta área nos domínios
da Robótica e IA. Incluem, entre outras, a coordenação, a cooperação e comunicação multi-agente, as
arquitecturas de agentes inteligentes, a aprendizagem, o planeamento em tempo-real, a decisão
estratégica e táctica, o comportamento reactivo, a visão, o processamento e análise de imagem, o
controlo, os sistemas de locomoção, os sistemas sensoriais, a fusão sensorial em tempo-real, a
navegação e o controlo robótico [RAC].
O desafio associado à RoboCup é estimulante do ponto de vista científico, colocando um vasto
conjunto de problemas aos investigadores das diversas áreas científicas mas, simultaneamente,
atraente para o público em geral e para os meios de comunicação social.
O sucesso duma competição como a RoboCup reside fundamentalmente no desenvolvimento
de metodologias de coordenação que lhes permitem trabalhar em conjunto de forma harmoniosa no
sentido de atingir os seus dois objectivos principais: marcar golos na baliza adversária e evitar sofrer
golos na sua baliza. A coordenação é desta forma uma das áreas de investigação essenciais no
contexto da RoboCup e um factor crucial para o sucesso de uma equipa nas competições internacionais
realizadas neste âmbito.
1.4. RAC
Robótica Académica de Coimbra
A RAC – Robótica Académica de Coimbra – é um projecto do Departamento de Engenharia
Electrotécnica e de Computadores [DEEC] da Faculdade de Ciências e Tecnologia da Universidade de
Coimbra [FCTUC], que envolve alunos, investigadores e docentes desta instituição. É apoiado pela
FCT – Fundação para a Ciência e Tecnologia [FCT], ao abrigo do projecto de investigação
POSI/ROBO/43890/2002. Tem como objectivo principal formar e desenvolver uma equipa de futebol
robótico dinâmica e competitiva, que possa representar o DEEC da FCTUC em competições da liga de
robôs pequenos da RoboCup (SSL – Small Size League) [RAC].
Figura 1.4.1 – RAC - Robótica Académica de Coimbra.
Página 15 de 119
O sucesso dum projecto como a RAC traz sempre alguns benefícios para a instituição que
abraça, bem como para o país em geral. Promovida por alunos, investigadores e docentes na área da
Robótica, procura servir-se do futebol para desenvolver actividades de investigação na área da Robótica
Móvel Inteligente, bem como estimular o ensino da Robótica junto de jovens estudantes.
1.5. Futebol Robótico em Portugal
O Futebol Robótico é uma novidade no mundo inteiro. Muitas das investigações estão ainda em
regime de iniciação e muitos avanços tecnológicos estarão para vir. Portugal não foge à regra e também
possui equipas de Futebol Robótico, organizando todos os anos eventos que visam mostrar e
apresentar algumas das tecnologias nesta área.
Paralelamente à RoboCup, o Festival Nacional de Robótica é já um marco importante no nosso
país. A primeira edição realizou-se em 2001 na cidade de Guimarães e, com o passar dos anos, tem
vindo a ganhar destaque. Trata-se de um encontro anual de estudantes, professores e investigadores
que visa o desenvolvimento da ciência e do conhecimento. Paralelamente à parte lúdica e competitiva,
existe sempre um encontro cientifico, aberto a participantes e investigadores através da publicação de
artigos. A Robótica é o tema principal, no entanto, a divulgação de outras áreas tem vindo a ser visível.
A arte e o espectáculo são vividos com grande entusiasmo através dos seus participantes.
A última edição, em 2005, decorreu em Coimbra, nas instalações do Departamento de
Engenharia Electrotécnica e de Computadores da Faculdade de Ciências e Tecnologia da Universidade
de Coimbra. A RAC, estando em fase de evolução e preparação para as competições, teve um
contributo importante na realização e promoção do evento. O objectivo era estimular o gosto pela
ciência e pela tecnologia junto das camadas jovens, através de um ambiente de competição e convívio.
Figura 1.5.1 – Festival Nacional de Robótica 2005.
São iniciativas que juntam centenas de estudantes e investigadores não só das principais
universidades portuguesas com actividades na área da robótica, como também as escolas secundárias
e profissionais de todo o país.
Em 2004, foi também realizada a RoboCup em Lisboa, que é a mais importante competição
internacional de Futebol Robótico. Portugal cresce assim nesta área tão importante que é a Robótica.
1.6. Estado da Arte
A evolução do Estado da Arte em Futebol Robótico pode ser observada anualmente, durante os
campeonatos mundiais da FIRA e da RoboCup. Ao fazer uma análise das competições, verifica-se que
as equipas pioneiras, que participaram nos primeiros jogos, são bem menos sofisticadas que as equipas
mais recentes, tanto em termos de software, como de hardware.
Analisando as equipas que participaram nas primeiras edições dos campeonatos mundiais,
constata-se que alguns dos primeiros robôs possuíam apenas mecanismos de locomoção. Não havia
Página 16 de 119
mecanismos de domínio sobre a bola ou de chuto. Muitas vezes a estratégia da equipa era
simplesmente amontoar os jogadores na área de defesa e empurrar a bola para o campo do adversário,
marcando golo, se possível. De um modo geral, o funcionamento dessas primeiras equipas era: o
sistema de reconhecimento de imagens enviava os dados referentes às posições dos robôs e da bola,
para um programa que calculava todos os caminhos possíveis para essa configuração de jogo. Esses
dados eram processadas num sistema central que, tomando decisões estratégicas determinava quais os
movimentos a realizar pelos robôs. A comunicação com os robôs era realizada remotamente.
Com o passar dos anos, os sistemas de visão computacional e a tomada de decisões
estratégicas começaram a ser incorporados nos robôs, transformando-os em verdadeiros jogadores
autónomos. As equipas mais recentes apresentam muitas inovações electromecânicas e estratégias de
controlo bem mais sofisticadas e eficientes. Um bom exemplo é a equipa Big Red da Cornell University
[CORNELL]. Esta equipa já foi várias vezes campeã na categoria de robôs pequenos (SSL – Small Size
League) da RoboCup. Os novos robôs desta equipa possuem um sistema de direcção construído com
uma combinação de três pares de rodas e uma frente de ataque com maior abertura [D’ANDREA, 2001].
Esse sistema proporciona uma grande liberdade de movimentos aos robôs, para além duma capacidade
de aceleração superior. O mecanismo de chuto dos robôs da Big Red também representa um grande
avanço do Estado da Arte. Esse novo mecanismo permite que o robô mantenha um domínio efectivo
sobre a bola e, também, viabiliza a realização de passes eficientes. Graças a essas inovações de
hardware, foi possível obter grandes avanços no software. As novas estratégias utilizam jogadores que
cooperam entre si, realmente formando uma equipa, ao invés de simplesmente cada jogador chutar
cegamente para marcar golo ou defender o seu campo. Assim, além de evitar colisões e encontrar
caminhos, o sistema de estratégia passa a manipular a partida de tal forma a criar situações favoráveis
para a vitória, através de dribles, passes e de posicionamento estratégico dos jogadores em campo.
Novos sistemas que analisam o comportamento da equipa adversária para tentar antecipar as suas
jogadas estão também a ser desenvolvidos.
Figura 1.6.1 – RoboCup SSL (Small Size League).
Finalmente, salienta-se que o objectivo das competições e, portanto, das equipas que participam
delas, não é vencer o jogo, mas sim desenvolver ciência e tecnologia. Os artigos publicados durante os
eventos promovidos pela FIRA e RoboCup servem como referência para que todas as equipas possam
desfrutar dos avanços obtidos, ajudando a elevar o estado da arte em Futebol Robótico. Afinal, quem
revela o segredo do seu sucesso, obriga-se a desenvolver algo ainda melhor para o próximo
campeonato. Atitudes como a da equipa Big Red, que compartilha os seus conhecimentos e
tecnologias, demonstram o espírito desportivo que existe por detrás do Futebol Robótico.
Página 17 de 119
2. Problemas emergentes ao Futebol Robótico
Os maiores avanços da Inteligência Artificial foram obtidos através da investigação em
problemas padronizados. Os jogos, de um modo geral, constituem um bom domínio para a exploração
da inteligência das máquinas. Talvez o melhor exemplo seja o jogo de Xadrez. Grandes nomes da
computação, como Alan Turing e Charles Babbage, conceberam programas para jogar xadrez. Ou seja,
a ideia de que computadores poderiam competir em jogos é tão antiga quanto os próprios
computadores. Assim, a investigação em jogos levou à descoberta de diversos algoritmos de busca
poderosos, que podem ser aplicados noutras áreas, além do jogo em si. No xadrez, por exemplo, podese aplicar o algoritmo minimax [RICH, 1988]. Este algoritmo gera uma árvore com os movimentos
possíveis e busca maximizar a possibilidade de vitória, ao mesmo tempo que minimiza as hipóteses do
adversário.
Figura 2.1 – Robocup: Sony Legged Robot League e Humanoid League.
Os jogos são interessantes para a investigação da Inteligência Artificial porque possuem regras
bem definidas, além de ser fácil medir o sucesso ou fracasso. Além disso, eles despertam um interesse
muito grande. O Futebol Robótico, por sua vez, exerce um fascínio inexplicável sobre as pessoas,
especialmente sobre o público jovem. Além de ser um desafio intelectual programar ou competir com a
máquina, ainda existe a interacção física com os robôs. Ao contrário do xadrez e outros jogos em que os
movimentos são realizados em jogadas, onde um jogador espera que o outro faça um movimento, o
Futebol Robótico acontece em tempo real. Adicionalmente, por abranger o mundo físico real, incorpora
toda a complexidade e problemas inerentes da realidade, sendo um sistema altamente dinâmico.
Portanto, ruído, sincronismo, desgaste, imprecisão, falhas físicas, entre outros factores, fazem parte da
equação.
Consequentemente, muitos dos algoritmos desenvolvidos para jogos são inúteis no Futebol
Robótico, apesar de serem extremamente eficientes para o xadrez e afins. Um jogo de Futebol Robótico
possui regras bem definidas. Basicamente, utilizam-se as mesmas regras de um jogo de futebol com
jogadores humanos, mas com algumas modificações referentes ao tamanho do campo, número de
jogadores, duração do jogo, etc. E, assim como nos demais jogos utilizados em IA, é fácil medir o
sucesso ou fracasso: ganha a equipa que marcar mais golos. Entretanto, ao contrário de jogos que
constituem apenas uma tarefa abstracta, o Futebol Robótico incorpora todas as dificuldades intrínsecas
da solução de problemas do mundo real.
São inúmeras as áreas de investigação e pesquisa que podem ser realizadas com o Futebol
Robótico. Devido ao grande número e diversidade das tecnologias envolvidas no desenvolvimento de
uma equipa de futebol robótico, são muitas as áreas que podem ser abordadas por um projecto de
pesquisa deste tipo. Nas secções seguintes, serão analisadas as áreas nas quais o Futebol Robótico
pode ser utilizado como uma plataforma de estudos e testes dentro da Ciência da Computação. Assim,
serão abordados problemas de Inteligência Artificial, Visão Computacional, Tolerância a Falhas,
Engenharia de Software e Processamento Distribuído.
Página 18 de 119
2.1. Inteligência Artificial
A Inteligência Artificial é utilizada na tomada de decisões estratégicas, definindo o
comportamento dos jogadores (robôs). Ela interpreta os dados fornecidos por sensores e é responsável
pelo controlo dos jogadores.
Figura 2.1.1 – Sistema computacional de IA utilizado na Robocup99 para SSL.
São muitas as áreas da IA que podem ser estudadas através do futebol robótico. Por exemplo,
como cada equipa possui vários jogadores independentes um do outro, pode-se considerar cada robô
como um agente e utilizar um sistema multiagentes [BARONE, 2003] para implementar o sistema de
inteligência artificial. Da mesma forma, pode-se considerar a equipa como uma população de indivíduos
e utilizar-se algoritmos genéticos [RUSSEL, 1995] para controlar os robôs. Uma vez que cada robô é
dotado de um poder de processamento embebido, pode-se implementar uma rede neural em cada robô.
Adicionalmente, cada robô possui sensores e actuadores sobre o meio, além de capacidade de
comunicação remota. Assim, é possível fazer com que o sistema de multiagentes seja cooperativo. A
rede neural, por sua vez, pode ser implementada num computador central, que controle o sistema como
um todo e envia comandos via rádio para os robôs.
2.2. Visão Computacional
Num sistema de futebol robótico, a visão computacional realiza o processamento de imagens. O
sistema deve realizar o reconhecimento do campo, da bola e dos jogadores das duas equipas
envolvidas numa partida. Cada robô possui uma cobertura de cor predominantemente preta, com
marcações coloridas que distinguem uma equipa da outra. Opcionalmente, cada robô pode possuir
marcações adicionais, para diferenciar um robô específico dos demais.
Figura 2.2.1 – Marcações coloridas utilizadas pela RAC.
Página 19 de 119
Basicamente, o reconhecimento de imagens funciona da seguinte maneira: uma imagem
estática é capturada através de uma câmara de vídeo; é realizado um reconhecimento de cores, para
identificar a cor da bola, cada uma das equipas e, opcionalmente, alguma cor de marcação adicional
para a diferenciação dos jogadores; finalmente, é executado um reconhecimento de formas, para
distinguir os robôs da bola e filtrar eventuais ruídos. Ou seja, o reconhecimento de imagens dá-se
através de dois passos básicos: diferenciação de cores e reconhecimento de formas. Assim, podem ser
utilizadas duas abordagens, descritas a seguir.
2.2.1. Visão Global
Na visão global, uma câmara é colocada a uma determinada altura sobre o campo de jogo. Esta
altura pode variar conforme a regra da competição específica e o tamanho do campo. Dessa forma, as
imagens capturadas por esta câmara possuem uma visão global da situação do campo. O vídeo é então
enviado para um computador central, que realiza o reconhecimento de imagens e envia essas
informações para todos os robôs ou, conforme a abordagem utilizada pela Inteligência Artificial, para um
programa central.
Figura 2.2.1.2 – Sistema computacional de IA utilizado na Robocup99 para SSL.
Neste tipo de visão, apesar de ocorrerem sempre eventuais ruídos na imagem capturada,
dificilmente um dos objectos a ser reconhecido estará obstruído ou ocultado por outro. Adicionalmente, o
plano imagem é paralelo ao plano onde a bola se move (campo de jogo), o que facilita o reconhecimento
de formas. Uma vez que não é necessário levar a profundidade de um objecto em consideração, podese dizer que o reconhecimento de formas é bidimensional (2D).
2.2.2. Visão Local
Neste sistema de visão, cada robô possui uma (ou mais) câmaras embebidas. Não existe uma
visão global directa da posição da bola e de todos os robôs. Existe antes um conjunto de visões
individuais da situação de jogo de cada robô. Obviamente, a partir destas informações, é possível
calcular a situação global do sistema. Entretanto, tal processamento é bastante sofisticado e as
dificuldades são enormes. Por exemplo, para realizar o reconhecimento da bola, além de diferenciar a
sua cor e reconhecer a sua forma, será necessário, ainda, considerar a sua proximidade em relação ao
robô. Conforme varia a distância entre a bola e robô, o tamanho com que a bola aparece na imagem
também será variado. O mesmo problema também ocorre para o reconhecimento dos robôs. Esta é
apenas uma das dificuldades encontradas num sistema de visão local que, muitas vezes, não existe
num sistema global.
Página 20 de 119
Figura 2.2.2.1 – Sistema de Visão Local utilizado em diversos robôs destinados ao Futebol Robótico.
Outra dificuldade é a determinação da posição exacta de cada objecto reconhecido. Quando a
visão é local, a bola e os demais jogadores identificados têm a sua posição reconhecida em relação ao
robô que capturou a imagem. Mas qual é a posição deste robô em questão? A sua posição pode ser
obtida, por exemplo, através de uma triangulação com as imagens reconhecidas pelos outros robôs da
sua equipa, num sistema ainda completamente distribuído e descentralizado, mas no qual todos os
robôs trocam informações entre si, para a obtenção da situação global do sistema. Entretanto, nada
garante que este robô aparecerá na imagem capturada pelos outros robôs da sua equipa. E, ainda que
apareça, o mesmo pode estar obstruído por outro robô ou parcialmente bloqueado, impedindo assim o
seu reconhecimento. Adicionalmente, a imagem capturada por um robô pode estar vazia, isto é, não
possuir nenhum objecto para ser reconhecido.
A determinação da posição exacta da bola e de cada robô pode ser obtida através do
seguimento de cada jogador. Para isso, cada robô deve ser equipado com sensores nas suas rodas ou
motores para que seja possível monitorizar o seu movimento e saber, num dado momento, o quanto o
robô em questão se deslocou. Mais uma vez, a variedade de tecnologias e integração entre as
diferentes áreas de estudo está presente.
Entretanto, é extremamente difícil realizar um rastreamento preciso. Como existe atrito e,
adicionalmente, ocorrem colisões entre os robôs, implementar um sistema de rastreamento local que
seja confiável, apenas com sensores nas rodas ou motores torna-se difícil. Mesmo que, utilizando outros
tipos de sensores, seja possível realizar o rastreamento dos robôs da equipa, o problema de localização
ainda persiste para os robôs da equipa adversária, uma vez que não são trocadas informações com os
mesmos.
Por todas estas razões, é muito mais difícil realizar o reconhecimento local de imagens, em
comparação com a abordagem global. E o aumento da dificuldade, ocasionado pela escassez de
informação, não se restringe ao sistema de Visão Computacional. Como não existe um reconhecimento
de imagens global da situação do jogo, a Inteligência Artificial terá que tomar as suas decisões
estratégicas baseadas em informações locais e possivelmente incompletas.
Entretanto, a visão local possui também algumas vantagens. Como não existe nenhum
computador central que processe a imagem global e envie as informações para os robôs, o sistema
pode ser completamente distribuído, não existindo nenhuma dependência centralizada, ou um ponto
único de falha. Dessa forma, outras áreas como Tolerância a Falhas e Processamento Distribuído
podem implementar sistemas muito mais robustos e eficientes.
Salienta-se que a visão computacional para o Futebol Robótico não precisa, necessariamente,
restringir-se à imagens capturadas por câmaras de vídeo. Pode-se utilizar uma variedade de outros
sensores ou ainda uma combinação de diversos sensores. Por exemplo, é possível utilizar a tecnologia
de sonares no futebol de robôs. O sonar emite uma sequência de ondas acústicas numa determinada
frequência; conforme essas ondas são reflectidas por um determinado objecto, é possível determinar a
sua posição e forma. Deste modo, a identificação de cada robô deixaria de depender do reconhecimento
de cores e passaria a reconhecer a sua forma, ou seja, envolveria um campo de estudo e pesquisa
completamente diferente. Da mesma forma, um sensor de calor poderia ser utilizado. Assim, o
reconhecimento de cada robô seria feito pela sua assinatura térmica, e não mais pela sua marcação em
cores. Caso algum desses sensores não seja muito adequado para uma determinada tarefa, pode-se
utilizar ambos, cada um executando a tarefa que realiza com maior eficiência.
Página 21 de 119
2.3. Tolerância a Falhas
O objectivo da Tolerância a Falhas não é evitar que as falhas ocorram mas, na ocorrência de
uma falha, esforçar-se ao máximo para que aquela não ocasione um erro. Assim, no Futebol Robótico,
um ambiente abundante em hardware e software potencialmente susceptíveis a falhas, a Tolerância a
Falhas pode aumentar a confiabilidade do sistema, podendo significar a diferença entre a vitória ou a
derrota!
O hardware, devido ao seu desgaste físico natural, ou decorrente do uso, pode falhar. Qualquer
peça de hardware possui uma vida útil. Adicionalmente, a utilização de materiais inadequados pode
ocasionar o seu mal funcionamento. E mesmo com componentes de boa qualidade, defeitos de
montagem ou fabricação podem vir a gerar mais falhas. Finalmente, o hardware ainda pode conter
falhas de projecto. Ou seja, o hardware é altamente propenso a falhas.
O software, por sua vez, existe numa realidade completamente diferente. Não existe desgaste
de software [PRADHAM, 1996]. Ao produzir várias “unidades” de um mesmo programa, não existirão
falhas de “fabricação”, como ocorre na reprodução do hardware. Quando uma cópia de um software cujo
original funciona se apresenta corrompida, o defeito está no suporte usado para o armazenar, não no
software. O software não sofre desgaste com o tempo.
Saliente-se que o software pode existir sem o hardware. De facto, cada vez mais se escreve
softwares muito antes que qualquer hardware computacional tenha sido construído. A Máquina de
Turing [TURING, 1936], idealizada por Alan Turing em 1936, é universalmente aceite e reconhecida
como a formalização de algoritmo [DIVERIO, 1999]. Ela é capaz de realizar qualquer função
computável, ou seja, o seu poder computacional é equivalente a qualquer computador moderno.
Softwares que solucionam diversos problemas foram escritos para esta máquina. Entretanto, a máquina
em si, nunca foi construída.
Quando um software apresenta algum defeito, o erro pode ter ocorrido em três situações
distintas: falha durante o projecto do software; falha durante a implementação do software; ou uma falha
de hardware que provocou uma falha no software.
Assim, no Futebol Robótico, diversas abordagens de Tolerância a Falhas podem ser exploradas
e testadas. Por exemplo, pode-se implementar mecanismos de hardware para aumentar a Tolerância a
Falhas dos robôs, como o uso de componentes redundantes que entrariam em operação apenas no
caso de falha de uma peça. Outra opção é a implementação de mecanismos de software para
compensar a falha de hardware: caso um dos motores do robô pare de funcionar, por exemplo, o
software deve ser capaz de controlar um robô com um motor a menos, levando em consideração
velocidade e habilidade de movimentação reduzidas. Finalmente, pode-se implementar mecanismos de
software para lidar com falhas do próprio software: caso um programa bloqueie, outra versão do
programa executando em paralelo assumiria as suas funções.
2.4. Engenharia de Software
Numa equipa de Futebol Robótico, na qual estão envolvidas várias áreas de conhecimento, a
correcta integração das tecnologias desenvolvidas nas diferentes especialidades num único sistema é
crítico para o funcionamento eficiente do conjunto. Devido à sua complexidade, o desenvolvimento e
implementação de um sistema de Futebol Robótico é dividido em módulos. Cada módulo fica
encarregado de solucionar uma parte específica do problema. Assim, temos os módulos de Inteligência
Artificial, Visão Computacional, Comunicação, etc, tantos quanto forem necessários para uma
abordagem completa do sistema.
Independentemente da implementação final do sistema, a Engenharia de Software é
responsável pela determinação do fluxo de dados entre os diversos módulos, possibilitando a
comunicação correcta entre as diferentes partes do sistema. O sistema final pode ser implementado por
um ou mais programadores, utilizando diferentes paradigmas de programação (Orientada a Objectos,
Programação Estruturada, Funcional, Lógica, etc.). O resultado, pode ser na forma de um único grande
programa executável, ou em vários programas menores comunicando entre si. A comunicação, por sua
vez, pode ocorrer através de uma rede, ou pode ser feita num único computador, através de funções do
sistema operativo. Inclusive, pode-se ter um conjunto de programas em que cada um executa num
sistema operativo diferente. Entretanto, com uma boa engenharia de software, torna-se desnecessário
Página 22 de 119
que o programador de um módulo entenda ou tenha que alterar o código de outro módulo para que seu
programa possa comunicar e funcionar com outro.
Portanto, o projecto do software de uma equipa de Futebol Robótico, constitui uma óptima
plataforma para o teste de diferentes metodologias da Engenharia de Software, ou mesmo, para o
desenvolvimento de novas abordagens. Afinal, o Futebol Robótico não envolve apenas a programação
de computadores convencionais, mas inclui todo um sistema de hardware e, software embebido.
2.5. Processamento Distribuído
No Futebol Robótico, os programas de inteligência artificial e visão computacional exigem muito
poder de processamento. Assim, quanto mais rápida for a CPU (Central Processing Unit), melhor o seu
desempenho. Entretanto, por mais potente que seja o processador, a execução desses dois programas
num mesmo computador terá um desempenho pior do que se cada sistema executasse num
computador separado, com toda a CPU disponível para cada programa. Assim, o Processamento
Distribuído é utilizado no Futebol Robótico para melhorar o desempenho do sistema, através da
execução de partes pesadas do sistema em computadores distintos.
Página 23 de 119
3. RACmotion
Este capitulo apresenta o RACmotion [RACMOTION], o nosso Projecto de Final de Licenciatura.
O RACmotion tem o objectivo de oferecer uma solução para o controlo da trajectória do movimento de
um robô omnidireccional, definindo toda a sua estrutura e finalidades. Inicialmente, são introduzidos os
seus principais objectivos e por fim é descrita a sua motivação, bem como, toda a promoção efectuada e
desenvolvida em seu redor e, da entidade que o abraça, a RAC.
3.1. Objectivos
O objectivo deste projecto, consiste no controlo da trajectória do movimento de um robô
omnidireccional. O controlador a desenvolver será utilizado nos robôs da RAC que irão participar
eventualmente em competições oficiais da RoboCup SSL (Small-Size League). Esta liga de competição
caracteriza-se pela grande dinâmica dos robôs, que são de reduzidas dimensões e limitados no peso,
para poderem ter grandes acelerações.
Cada robô da RAC dispõe de uma configuração mecânica constituída por três motores, que
torna possível o movimento omnidireccional, ou seja, o robô não tem que se virar antes de se deslocar
para um ponto no espaço. Especificada a trajectória, o controlador a desenvolver terá de controlar o
robô durante a execução do movimento, em tempo-real e em malha fechada, enviando comandos de
velocidade para o robô e usando o sinal do sensor de visão global para realimentar o controlo.
No âmbito deste trabalho, será também desenvolvido software para decompor cada comando de
velocidade enviado à camada operacional do robô em comandos individuais de velocidade para os três
motores de tracção. Será desenvolvido um modelo cinemático do robô omnidireccional, bem como o
procedimento de identificação e calibração dos respectivos parâmetros.
Inserido nos objectivos gerais do projecto RAC, podemos dizer que este trabalho terá valor e
importância acrescentada pois, em conjunto com outros projectos efectuados na área, poderá levar em
frente o crescimento dos objectivos da RAC, a formação e o desenvolvimento de uma equipa de futebol
robótico dinâmica e competitiva, que possa representar o DEEC em competições nacionais e
internacionais.
Finalmente, este projecto serve como trabalho final para a obtenção do grau de Licenciatura em
Engenharia Electrotécnica e de Computadores, através da conclusão do Projecto Final, cujo foco poderá
ser voltado exclusivamente para a área da Robótica.
3.2. Motivação
A utilização de robôs na automação industrial e em locais de difícil acesso por humanos (por
exemplo, na inspecção de tubulações) ou em situações perigosas (por exemplo, no desarme de bombas
e de minas terrestres) tem crescido rapidamente no âmbito mundial. Da mesma forma, a exploração
espacial também dependerá de unidades robóticas, capazes de operar de modo satisfatório nos
ambientes hostis de outros planetas. Os países que não dominarem o ciclo de projecto, construção e
operação de robôs autónomos estarão comprometendo fortemente sua capacidade de competição num
mercado globalizado, uma vez que tais equipamentos já são considerados essenciais em vários tipos de
actividades industriais. Por exemplo, a indústria automóvel tem utilizado de forma rotineira robôs de
soldadura e pintura, com os quais é possível a construção de complexas estruturas dos modernos
automóveis com baixo custo e alta qualidade.
Robôs autónomos que operam em equipa necessitam de um conjunto alargado de tecnologias
de diversas especialidades. Um robô verdadeiramente autónomo deve ser dotado de visão
computacional e/ou sensores, capazes de posicioná-lo num ambiente desconhecido, associado a um
programa de controlo capaz de actuar em situações de conflito. Adicionando-se o requisito de acção
cooperativa entre máquinas inteligentes, leva-se ainda à necessidade de se implementar sistemas de
comunicação entre os robôs e a divisão de tarefas.
O estudo da robótica autónoma multi-agente tem sido realizada com baixa intensidade em
Portugal. Entre os factores que limitam a actuação dos investigadores e alunos tem sido apontado o alto
Página 24 de 119
custo de montagem de um laboratório de robótica. Os robôs necessários para um laboratório de
pesquisa implicam investimentos elevados, inviáveis no cenário local. Por exemplo o robô Nomad,
tipicamente utilizado em actividades de investigação em diversos países, tem um custo superior a
USD$ 40 000,00.
Para além do fascínio pelo Futebol Robótico, uma das principais motivações para o
desenvolvimento deste projecto é a formação e o desenvolvimento da equipa de futebol robótico do
DEEC, iniciativa levada a cabo pela Robótica Académica de Coimbra – RAC. O objectivo preciso deste
projecto, definido pelo desenvolvimento de um controlador de trajectórias para um robô omnidireccional,
vai permitir o crescimento e desenvolvimento da ideia que muitos lutam e esperam ver realizada no
departamento. Teve também como motivação o desenvolvimento de metodologias de coordenação,
cooperação e seguimento de trajectórias, suficientemente genéricas para que possam vir a ser
aplicadas a curto-prazo a problemas ligados ao Futebol Robótico, principalmente no caso da equipa da
RAC.
O futebol robótico representa uma área que abrange diversos domínios e temas que se
interligam sempre com o avanço e desenvolvimento de novas tecnologias. Cada vez mais, é preciso
encarar o futuro com bons olhos, com vontade de o fazer evoluir, seguindo um rumo correcto, que nos
levará a um futuro melhor.
3.3. Promoção e Divulgação
Para além da natural motivação resultante da participação em grandes competições envolvendo
equipas de investigação científica, como a RoboCup e o Festival Nacional de Robótica, este projecto foi
sempre encarado com a motivação de ajuda aos objectivos da RAC, bem como na sua promoção local e
nacional.
A sua promoção deu-se, principalmente, ao nível da divulgação e no recrutamento de novos
elementos. Com isso, a organização do Atelier de Robótica durante o evento Robótica 2005 veio
melhorar a publicitação do projecto RAC. A ideia de organizar este atelier, constituído por uma pequena
sessão de palestras e um atelier laboratorial, partiu fundamentalmente da nossa constatação que esta
área da engenharia, apesar de fascinante, não atrai muito estudantes e eventuais interessados para o
trabalho de investigação e desenvolvimento (I&D). Sendo assim, e tendo em conta que nós
organizadores somos alunos finalistas que estamos a realizar projectos na área da Robótica, surgiu a
ideia de organizar um evento constituído por palestras e visitas de estudo a laboratórios de I&D, com o
objectivo de mostrar a todos o quanto esta área é fascinante.
Figura 3.3.1 – Sessão de palestras do Atelier Robótica.
Este tipo de promoção, procurou desmistificar a robótica como uma área não apenas ao alcance
dos países mais desenvolvidos tecnologicamente, como por exemplo os EUA, Japão e Alemanha, mas
também mostrando que num país pequeno como Portugal se pode fazer ciência robótica e contribuir
para o seu avanço tecnológico.
Página 25 de 119
Figura 3.3.2 – Atelier laboratorial, demonstração RAC.
Na área da engenharia, somos todos os dias confrontados com matemática, com física, com
computação, ou seja, tudo ciências aplicadas, descorando de certa forma o exercitar das nossas
aptidões relacionadas com os aspectos sociais e capacidades organizativas e humanistas. Ao realizar
esta actividade, e levando em conta o trabalho já desenvolvido, tivemos o desejo de aprender coisas
novas e diferentes, que habitualmente não estão incluídas no programa curricular do nosso curso, como
seja tão simplesmente elaborar uma carta/ofício de uma forma mais formal e séria, deixando de parte as
mensagens tipo telegrama que nos fomos habituando a escrever através do uso dos e-mails.
Como vivemos numa sociedade digital repleta de informação, foram também desenvolvidas
páginas WEB, de modo a facilitar a divulgação do Atelier bem como do projecto RACmotion. A
introdução dos conceitos e temas abordados, bem como a troca de ideias, tornam-se fundamentais
neste tipo de promoção de iniciativas.
Figura 3.3.3 – Páginas WEB do Atelier e projecto RACmotion.
⇒ Sessão de Palestras e Atelier Robótica:
http://alumni.deec.uc.pt/~brandao/robotica2005atelier
⇒ Projecto RACmotion:
http://alumni.deec.uc.pt/~brandao/racmotion
De um modo geral o “feedback” dado pelos participantes foi muito bom e algum desse
“feedback” ainda hoje é visível. Foi sempre nosso objectivo mostrar o trabalho da RAC no DEEC e
dinamizar mais uma vez o nosso departamento nesta área tão aliciante que é a Robótica. Com a
realização deste evento, tivemos uma enorme adesão no quadro de admissões à RAC por parte de
colegas do DEEC e até mesmo pessoas de fora que estiveram presentes no Atelier, o que veio provar
mais uma vez que este tipo de iniciativas são cada vez mais necessárias. É sempre bom contribuir para
este tipo de causas e para o desenvolvimento da investigação do nosso departamento e, por isso,
estamos gratos por termos conseguido alcançar os nossos objectivos.
Segue em anexo alguns relatos informativos de diversos órgãos de comunicação social que
apresentaram algumas das iniciativas desenvolvidas.
Página 26 de 119
4. Arquitectura de Controlo da RAC
A arquitectura de controlo da RAC foi projectada com o objectivo de controlar em tempo real
uma equipa de robôs jogadores de futebol, dando a maior autonomia de controlo possível aos robôs. A
arquitectura de controlo é distribuída, mas com um modelo de representação do mundo centralizado,
que une os dados dos sensores de todos os robôs. Para além disso, a arquitectura é modular, escalável
e suporta equipas da liga média (MSL) e da liga pequena (SSL) com diferentes níveis de autonomia de
controlo do robô [MARTINS].
4.1. Descrição
A figura 4.1.1 mostra o diagrama da arquitectura global da equipa. A arquitectura é composta
por um modelo centralizado de representação do mundo (WM - World Model). Este modelo é acedido
por um número de agentes robóticos (AGENT 1, …, AGENT n) e pelo interface de sensores globais
(GLBSENS).
(5)
MNT
HMNSVS
System Monitor
Human Supervisor
(4)
(7)
(6)
RFRINT
Referee Interface
(6)
UPDMOD
WM
(7)
NTFYEV
Notify Event
World
Model
(7)
QRYMOD
Query Model
Update Model
(8)
(9)
Supervision
Events
Queries
Sensory Fusion
Inter-Agent
(2)
AGENT 1
LD
Local
Data
(2)
AGENT n
STRCTR
LD
Strategic Control
Local
Data
TCTCTR
Tactic Control
STRCTR
Strategic Control
TCTCTR
Tactic Control
SENSPROC
OPRCTR
SENSPROC
OPRCTR
Sensory Processing
Operational Control
Sensory Processing
Operational Control
GLBSENS
SENS
ACT
SENS
ACT
Global Sensors
Sensors
Actuators
Sensors
Actuators
(1)
(1, 3)
(1, 3)
World
Figura 4.1.1 – Diagrama global da arquitectura de controlo.
O módulo WM é uma representação centralizada do mundo. Guarda informação importante
sobre o jogo, como por exemplo, a orientação e velocidade de todos os jogadores e da bola, do
resultado e situação do jogo. Esta informação é usada pelos robôs para tomar decisões usando
informação consistente do estado do jogo e comum a todos. Os módulos UPMOD e RFRINT são
processos que actualizam WM sempre que são detectadas alterações no ambiente de jogo. O módulo
UPDMOD implementa a fusão sensorial dos sensores a bordo dos robôs e dos sensores globais. A
figura 4.1.2 mostra um exemplo da sequência de eventos que actualiza o módulo WM desde que nova
informação esteja disponível. O módulo RFRINT recebe comandos do árbitro do jogo e actualiza o
estado do jogo em WM de acordo com a decisão tomada pelo árbitro (cantos, faltas, lançamentos,
golos, etc.). O módulo MNT implementa um interface gráfico de utilizador que permite ao supervisor da
equipa controlar os acontecimentos do jogo. O módulo HMNSVS permita ao supervisor humano afinar a
estratégia seguida pela equipa. Os módulos QRYMOD e NTFYEV permitem que WM esteja disponível
para todos os robôs. QRYMOD processa os pedidos sobre o estado de jogo e NTFYEV é um processo
Página 27 de 119
que notifica os robôs quando um determinado evento acontece (alterações em WM) para o qual os
robôs pediram para ser notificados [MARTINS].
GLBSENS
SENSPROC
Agent 1
SENSPROC
Agent 2
UPDMOD
WM
localization-estimate
update-robots-position
Figura 4.1.2 – Diagrama de sequência para a actualização de WM
Os agentes robóticos são entidades de software que implementam a inteligência e a autonomia
de controlo dos robôs da equipa. A figura 4.1.3 mostra um diagrama de blocos detalhado da arquitectura
do agente.
Events
Queries
Sensory Fusion
Inter-Agent
(4)
(9.1) (8.1) (10.1)
STRCTR
Strategic Control
(9.2)
(11)
(8.2) (10.2)
TCTCTR
Tactic Control
(9.3)
(12)
(2)
(8.3)
OPRCTR
SENSPROC
Operational Control
Sensory Processing
LD
Local
Data
(13)
(2)
ACT
SENS
Actuators
Sensors
(3)
(1)
World
Figura 4.1.3 – Diagrama da arquitectura do agente robótico
Existem três módulos que controlam o robô ao nível estratégico, táctico e operacional: STRCTR,
TCTCTR e OPRCTR. O módulo SENSPROC processa a informação adquirida pelos sensores do robô.
Os módulos SENS e ACT fazem o interface directo com os sensores e actuadores do robô.
O módulo STRCTR coopera remotamente com os módulos STRCTR dos outros agentes
robóticos de maneira a seleccionar a melhor estratégia para a equipa de acordo com o estado actual de
WM. O módulo TCTCTRL realiza a mesma função que STRCTR mas ao nível táctico. Coopera
remotamente com os colegas de equipa de modo a aplicar a estratégia escolhida à táctica, atribuindo
funções de campo aos jogadores e coordenação de movimentos de jogo. A figura 4.1.4 mostra um
exemplo de um diagrama de sequência ao nível táctico numa situação onde foi aplicada uma estratégia
defensiva. O módulo OPRCTR implementa um conjunto de sequências de controlo (máquinas de estado
finitas) que são instanciadas ao nível táctico de modo a realizar acções básicas (por exemplo: driblar a
bola para uma posição). Cada acção básica é uma sequência de controlo em malha fechada usando
apenas os sensores e actuadores do robô, embora a informação global também possa ser usada. Cada
robô tem armazenado localmente um sub-modelo de WM construído a partir de dados adquiridos pelos
Página 28 de 119
sensores locais [MARTINS]. Estes dados são apropriados para o controlo operacional em tempo real do
robô. A figura 4.1.5 mostra um exemplo de um diagrama de sequência para uma acção básica.
STRCTR
Agent 1
STRCTR
Agent 2
TCTCTR
Agent 1
TCTCTR
Agent 2
QRYMOD
NTFYEV
OPRCTR
Agent 1
OPRCTR
Agent 2
defend
defend
robots-pose?
robots-pose?
robots-pose-is
robots-pose-is
bid-for-defender1-is
bid-for-defender1-is
follow-opponent-owning-ball
defend-goal
when-ball-enters-my-influence-area
ball-entered-in-influence-area
steal-ball-to-opponent
Figura 4.1.4 – Exemplo de diagrama de sequência para as acções ao nível táctico do robô
SENS
Agent i
SENSPROC
Agent i
QRYMOD
OPRCTR
Agent i
ACT
Agent i
encoder-readings
velocity
touching-ball?
yes-touching-ball
set-robot-velocity
Figura 4.1.5 – Exemplo de diagram a de sequência para a execução de uma acção básica
A figura 4.1.6 mostra exemplos da informação utilizada e das acções de controlo
desempenhadas pelos vários módulos da arquitectura de controlo da RAC.
Figura 4.1.6 – Exemplos de informação e de acções de controlo
Página 29 de 119
4.2. Aplicação em Robôs com Diferentes Níveis de Autonomia
A arquitectura projectada pode ser facilmente adaptada a diferentes níveis de autonomia dos
robôs. A RAC está particularmente interessada em dois casos: SSL (Small Size League) e MSL
(Medium Size League) da Robocup. Em ambos os casos, a atribuição de alguns módulos a recursos de
processamento computacional é fixo: os módulos SENS e ACT são sempre colocados nos robôs; os
módulos UPDMOD, RFRINT, MNT, HMNSVS, QRYMOD e NTFYEV são sempre colocados num
computador remoto. Se o uso dos recursos de comunicação ou o poder computacional dos robôs
tiverem de ser limitados a um mínimo, todos os módulos do agente, excepto SENS e ACT, podem ser
colocados num computador remoto. Por outro lado, se os módulos que definem a inteligência do robô
necessitarem de estar a bordo, então todos os módulos do agente necessitam de correr no robô.
Para a liga SSL existem muito poucos sensores a bordo dos robôs e está disponível um sensor
global muito poderoso – uma câmara colocada por cima do campo de jogo – que esta integrada com o
módulo WM através de GLOBALSENS. Como a maior parte da informação sensorial vem do sensor
global, a implementação do módulo UPDMOD é muito simples porque a fusão sensorial de diferentes
fontes é mínima. Por causa do poder computacional do robô ser reduzido, todos os processos, excepto
SENS e ACT, correm num computador remoto.
Para a liga MSL, os sensores globais são proibidos. Por isso, o módulo GLOBSENS não existe.
Como a capacidade sensorial está distribuída de maneira praticamente uniforme entre os robôs, o
processo UPDMOD é muito mais complexo do que no caso da SSL. Se os robôs possuírem um poder
computacional razoável, pode ser implementada a arquitectura mais distribuída e com maior autonomia.
A primeira implementação da arquitectura de controlo da RAC foi debruçada na plataforma para
a liga SSL, isto é, uma solução de controlo centralizado num computador remoto. Mais tarde, está
planeado construir uma plataforma para a MSL, onde se pretende implementar uma arquitectura
completamente distribuída.
Na secção seguinte, são identificadas as ferramentas de desenvolvimento de software para a
construção da plataforma, assim como a divisão de tarefas em equipas de desenvolvimento.
4.3. Ferramentas de Desenvolvimento
Tanto o computador PC remoto como os robôs vão correr o software de controlo em ambiente
Linux [LINUX], embora o software do robôs corram numa plataforma Linux minimalista.
As ferramentas de desenvolvimento são:
⇒ Compilador C para os programas do robô (GNU Compiler collection [GCC]);
⇒ Compilador C++ para os programas do computador PC remoto (GCC);
⇒ Ambos utilizam o protocolo TCP/IP como base da implementação do sistema de comunicação.
4.4. Divisão de Tarefas de Desenvolvimento
Esta secção dá uma perspectiva de como as tarefas de desenvolvimento, necessárias à
implementação da arquitectura de controlo da equipa SSL, foram divididas em grupos de trabalho.
⇒ T1 – Implementação dos módulos SENS e ACT: 2 pessoas – equipa de programação e
montagem do robô (Projecto RACmotion);
⇒ T2 – Implementação dos módulos GLBSENS, SENSPROC, RFRINT e UPDMOD: 2 pessoas –
equipa de actualização do modelo do mundo;
⇒ T3 – Implementação da base de dados do módulo WM e implementação dos módulos
QRYMOD, NTFYEV, MNT e HMNSVS: 2 pessoas – equipa WM;
Página 30 de 119
⇒ T4 – Implementação da base de dados local e dos módulos STRCTR, TCTCTR e OPRCTR: 2
pessoas – equipa de inteligência artificial.
Estas tarefas concorrentes necessitavam de ser precedidas por uma especificação exaustiva
das mensagens necessárias para implementar o fluxo de informação e controlo. A primeira tarefa de
cada equipa foi de contribuir para esta especificação. Existiram reuniões regulares entre as equipas de
desenvolvimento de software, e foi possível produzir um documento com a especificação completa
baseada na contribuição dos membros.
Página 31 de 119
5. Estrutura do robô
A estrutura dos robôs e a distribuição de componentes são fundamentais para o bom
desempenho e performance duma equipa de Futebol Robótico. É fundamental que os robôs se
encontrem equilibrados e com pouco peso de modo a executar sem dificuldades todas as demais
ordens que lhe são exigidas. A manutenção também é um factor importante em robótica, por isso, o
robô deve facilitar o manuseamento dos seus componentes e a sua substituição em situações
emergentes.
Numa primeira parte deste capítulo vamos abordar a escolha da plataforma para o robô, com
toda a distribuição dos componentes. O desenvolvimento do primeiro protótipo e de toda a equipa foi
levado ao cabo pelo projecto RACmotion, seguidamente é descrito a sua evolução. Por fim, é relatado o
estado actual do protótipo bem como a reprodução de toda a equipa.
5.1. Plataforma
A estrutura dos robôs da RAC garantem o movimento omnidireccional, ou seja, os robôs
conseguem rodar sobre si próprios e, simultaneamente, executar um movimento de translação (mudar
de posição). A escolha da RAC foi de construir um robô com três rodas, em que cada eixo da roda
encontra-se desfasado de 120º, para garantir mais facilmente o seu movimento omnidireccional
[RODRIGUES].
Conforme podemos observar na figura 5.1.1 a plataforma divide-se em dois níveis: num primeiro
nível são colocadas as baterias, juntamente com os três motores e os respectivos encoders do robô que
se encontram colineares com os eixos das rodas (desfasadas de 120º), num segundo nível é colocada
todo o hardware correspondente ao sistema de controlo e comunicação.
Figura 5.1.1 – Estrutura do RACbot.
A correcta disposição e configuração dos componentes no robô vai garantir o seu bom
manuseamento. Sendo uma, estrutura em evolução, será necessário que esta plataforma apresente
configurações para varias alternativas, dispondo assim de espaço para vários testes e ensaios relativos
ao posicionamento do hardware.
A estrutura mecânica do robô foi construída em alumínio, de modo a diminuir ao máximo a
influência do peso no seu movimento. Contudo, um estudo futuro da plataforma do robô torna-se
necessário de modo a analisar outro tipo de ligas ou materiais que eventualmente possam vir a ter
melhores prestações, bem como outras distribuições de modo a reduzir o alumínio necessário.
Página 32 de 119
Figura 5.1.2 – Plataforma em alumínio do RACbot.
5.2. Evolução
A evolução do primeiro protótipo para a equipa de Futebol Robótico da RAC teve diversas fases.
A junção de todo o hardware bem como a sua disposição e fixação na sua estrutura base foi levado
como objectivo pelo projecto RACmotion. A necessidade de ter uma base de ensaio e um protótipo
pronto a usar levou ao seu desenvolvimento.
v Fixação do PC na plataforma base do robô
Com base em algum material já concebido, e de acordo com o desejado, foi fixado o PC/104 na
plataforma base do robô. Foi elaborado um pequeno projecto com as localizações e dimensões dos
furos bem como de outros acessórios, optimizando assim o trabalho desenvolvido na oficina. O PC foi
colocado na posição original, apenas a placa 7I30 (4 Channel H-Bridge Motor Drive) foi colocada na
posição vertical com o apoio de uma chapa tipo L.
Shape:
A robot must fit inside a 180 mm diameter cylinder. If a team is using
the global vision system, each robot on that team must have height of 150 mm
or less. In all cases, a robot must have height less than 225 mm.
Figura 5.2.1 – Fixação do PC na plataforma base do RACbot.
Após a fixação do PC/104 ao corpo do robô, foram levantadas varias questões ligadas à
mecânica e à distribuição do hardware do robô. Após a adopção para testes de um disco rígido da
FUJITSU para portáteis de 40Gb foi necessária a construção de uma placa fixadora para fixar este no
corpo do robô, eventualmente a fixar por debaixo do PC/104 para evitar o aumento em altura.
Recorrendo novamente ao apoio da oficina foram construídas umas placas tipo L de fixação para o
disco, conforme mostra a figura.
Figura 5.2.2 – Fixação do disco FUJITSU na plataforma base do RACbot.
Página 33 de 119
De modo a facilitar as ligações ao robô (PS2, COM1, CRT, RJ45, USB,...), foi desenvolvida uma
chapa de apoio a ligações, conforme mostra a figura 5.2.3, melhorando assim a sua organização de
componentes e evitando eventuais danos ou destruição de alguns contactos no PC/104 causados por
ligações mal executadas.
Figura 5.2.3 – Chapa de apoio de ligações ao RACbot.
v Alimentação e testes em campo
Inicialmente, e também devido à indisponibilidade das baterias, os eventuais testes a ocorrer no
robô teriam ainda de suportar uma ligação (12V DC) a uma fonte de alimentação da bancada. Para
evitar um excessivo uso de cabos de alimentação para os diversos dispositivos utilizados foram
mudadas e adoptadas novas ligações de alimentação, recorrendo ao conversor já incorporado na fonte
do PC/104 (PC/104 Power Supply V104).
•
•
12V DC - 4 Channel H-Bridge Motor Drive;
5V DC - Disco rígido;
Posteriormente, foi desenvolvido uma extensão de ligação à fonte de alimentação da bancada
para iniciar os testes em campo, conforme mostra a figura 5.2.4.
Figura 5.2.4 – Extensão de ligação à fonte de alimentação da bancada.
v Inserção das baterias
A inserção das baterias veio trazer uma maior mobilidade ao protótipo, bem como um grande
avanço no seu desenvolvimento. Contudo, o seu elevado peso veio piorar o comportamento do robô. O
peso é um factor crucial em Futebol Robótico e no caso da RAC este factor é significativo. Em relação à
sua durabilidade, este pack de baterias veio trazer cerca de 30 min de actuação, o que se torna
favorável, uma vez que uma partida de Futebol Robótico tem duração de duas partes de 10 min, num
total de 20 min.
Periods of Play:
The match lasts two equal periods of 10 minutes, unless otherwise
mutually agreed between the referee and the two participating teams. Any
agreement to alter the periods of play (for examples, to reduce each half to
7 minutes because of a limited schedule) must be made before the start of
play and must comply with competition rules.
Página 34 de 119
Figura 5.2.5 – Inserção das baterias no RACbot.
Inicialmente, a limitação em corrente da fonte de alimentação usada veio trazer alguns
problemas, uma vez que o robô num arranque em carga exigia mais do que pode ser fornecido pela
fonte. Com a inserção das baterias, esse problema foi mitigado, no entanto, outros apareceram, tais
como o peso e o desequilíbrio do robô.
v Rodas omnidireccionais
Para garantir o movimento omnidireccional do robô, as rodas devem garantir tracção no
movimento perpendicular ao seu eixo e não devem apresentar atrito no movimento colinear com o seu
eixo. Para isso foram utilizadas rodas com a configuração apresentada na figura 5.2.6.
Figura 5.2.6 – Rodas omnidireccionais adoptadas no RACbot.
Inicialmente, foi testado outro tipo de rodas, rodas plásticas, conforme mostra a figura 5.2.7.
Apesar deste tipo de rodas possuir um raio menor, estas ocupam mais espaço na plataforma adoptada,
no entanto, são mais suaves no seu movimento. Rodas acrílicas também foram motivo de atenção, pois
apresentam maior tracção no campo de jogo devido aos seus anéis em metal, mas o seu elevado peso
inviabilizou o seu desenvolvimento. A escolha da RAC foi desenvolver as suas próprias rodas. Com a
motivação de outras equipas o design escolhido foi o que está ilustrado na figura 5.2.6.
Figura 5.2.7 – Roda plástica e roda acrílica.
Página 35 de 119
Outros testes foram executados, partindo das rodas adoptadas. A substituição dos anéis em
plástico por anéis em latão era uma mudança possível, mas a sua fricção com o resto da roda
inviabilizou a sua transformação.
v Outras modificações
Diversas modificações foram efectuadas de modo a melhorar o desempenho do robô, tais como,
a substituição do disco rígido por uma Compact Flash IDE CFADPT-CS da Mesa. O uso do disco rígido
torna-se inadequado para o Futebol Robótico, devido aos permanentes choques a que os robôs estão
sujeitos, no entanto, a sua substituição por uma Compact Flash induz a novas dificuldades, tais como a
minimização do Sistema Operativo. Assim, foi inserida numa posição lateral do PC/104 o adaptador
Compact Flash IDE, de modo a não ultrapassar os valores limites em altura.
Figura 5.2.8 – Montagem do protótipo da RAC.
Outras modificações, tais como a inserção do sistema de chuto (figura 5.2.8), foram efectuadas
juntamente com alguns testes e ensaios. Contudo, ainda se encontra em fase de conclusão. O sistema
de chuto foi implementado usando um solenoide standard, com algumas modificações, de modo a
encaixar dentro da caixa de chuto. Foi adaptado um circuito de Flash de uma câmara fotográfica
descartável, usando o seu circuito de bloqueio e o seu conversor de tensão para carregar um
condensador de alta voltagem e impulsionar uma descarga no acto de chuto.
5.3. Protótipo
O desenvolvimento de um protótipo torna-se sempre necessário e importante em qualquer
progresso tecnológico. É imprescindível possuir um modelo de testes de modo a executar diversos
ensaios, aperfeiçoando assim o desenvolvimento do robô bem como de todo o sistema global que o
rodeia. O desenvolvimento de um protótipo para a RAC foi sempre encarado como uma necessidade.
Durante o seu desenvolvimento e construção foram apresentadas diversas alternativas e soluções a
variados problemas emergentes, originando assim uma evolução coerente.
O estado actual do protótipo é o ilustrado na figura 5.3.1. A replicação para o desenvolvimento
da restante equipa já se iniciou e, neste momento, encontra-se em fase de finalização. O processo de
evolução do protótipo foi um processo alargado. O aparecimento de diversos problemas e dificuldades
veio atrasar um pouco a sua evolução, contudo os objectivos foram cumpridos. A estrutura base está
concluída e todo o hardware está em harmonia e funcionamento.
Página 36 de 119
Figura 5.3.1 – Protótipo RACbot.
O objectivo traçado para o Robótica 2005 veio ajudar no progresso da equipa de Futebol
Robótico da RAC. Um grande esforço foi demonstrado pelos seus elementos para assim apresentar
uma primeira versão da equipa, no entanto, muito trabalho falta concluir. A replicação pode-se mostrar
num processo relativamente rápido, no entanto, a ligação de todos os módulos requer sempre algum
trabalho.
Página 37 de 119
6. Hardware
Em termos de desenvolvimento, a aposta da RAC é de um progresso tecnológico numa
perspectiva de evolução, ou seja, pretendemos ter uma base capaz de suportar upgrades ao sistema
quer ao nível de hardware quer ao nível de software. Possuir unidades capazes de sustentar outro tipo
de tecnologia para desenvolvimento e investigação futura, plataformas com poder computacional e
potencial suficientes para uma evolução da equipa. É neste plano que se encaixa a escolha de um PC
embebido, baseado na arquitectura PC/104, a correr num sistema operativo linux.
6.1. PC/104
O nome de PC/104 [PC/104] surgiu do popular computador pessoal de secretária, inicialmente
desenvolvido pela IBM, chamado PC, e do seu número de pinos usados para conexão de periféricos e
placas em conjunto (total de 104 pinos). O PC/104 é muito mais pequeno que as placas ISA-Bus
encontradas nos PC’s normais e possui uma característica de encaixe próprio, que lhe permite uma
progressão e evolução do sistema. A alimentação e a transmissão de sinal são reduzidas, de modo a
cumprir as necessidades de um qualquer sistema embebido tradicional. O PC/104 é essencialmente um
PC. Permite-nos utilizar as mesmas ferramentas de desenvolvimento de software que um PC vulgar
utiliza, reduzindo assim o custo de investimento em novas ferramentas e reduzindo também a curva de
aprendizagem para os programadores e engenheiros de hardware.
Em termos de aplicação, os sistemas baseados em PC/104 aplicam-se em diversas áreas
distintas, no sector industrial, no sector automóvel, no sector médico, nos laboratórios de I&D, ou seja,
em qualquer dispositivo desde que o seu controlo possa ser feito por um computador programável. O
sistema PC/104 é um sistema pequeno com uma necessidade reduzida de alimentação, o que o torna
num sistema forte para aplicações onde normalmente não existe espaço para um PC normal. O design
do PC/104 é mais robusto que o de um PC normal e normalmente o seu preço é mais elevado que um
PC comercial, mas mais barato que uma rack de sistemas ISA-Bus.
Figura 6.1.1 – Módulos do PC/104 no RACbot.
A aplicação de sistemas baseados em PC/104 no futebol robótico permite uma abertura no
avanço tecnológico implementado. Contudo, tamanha tecnologia poderá influenciar no comportamento
do robô. Cada vez mais se recorre a hardware dedicado devido ao excesso de peso a bordo e
capacidade de processamento desnecessária. Porém, o avanço tecnológico só é possível e facilitado a
Página 38 de 119
quem possua uma base suficientemente configurável e possibilitada a evoluir. A escolha da RAC
baseia-se nessa perspectiva, e por isso, adoptou um sistema baseado em PC/104.
Quase todo o tipo periféricos estão disponíveis nos módulos do PC/104. Funções usuais tais
como: CPUs, portas I/O, controladores de vídeo já estão disponíveis no modulo principal, mas é sempre
possível progredir para outro tipo de necessidades, como por exemplo: receptores GPS, receptores e
emissores Wireless, etc.
O sistema do PC/104 adoptado é constituído por:
v Uma placa M570 [M570] da SECO com um processador Via Eden de 600Mhz e 512Mb de
SDRAM, que combina um poder gráfico possuindo um processador de aceleração gráfica VIA
ProSavage PN133T (Twister™ T) com outras capacidades de multimédia: portas áudio, portas
série, portas USB, porta paralela, porta Ethernet 10/100BaseT, interface EIDE (com
possibilidade de discos IDE Flash), controladores de rato e teclado, relógio em tempo real, e um
temporizador Watch Dog.
Figura 6.1.2 – Placa M570 da SECO para PC/104.
v Uma placa de programação I/O MESA 4I65 [MESA] específica para PC104-PLUS Bus. A 4I65
usa uma FPGA com duzentas mil portas lógicas da Xilinx, permitindo assim uma programação
baseada em VHDL/Verilog. O uso da FPGA possibilita a criação de quaisquer funções de I/O,
incluindo funções de micro-controlo. Possui também software de fábrica, que em conjunto com
outras placas, permite o controlo de servo motores (SoftDMC). Possuí 72 bits de I/O distribuídos
em 3 conectores de 50 pinos.
Figura 6.1.3 – Placa de programação I/O 4I65 da MESA para PC/104.
Página 39 de 119
v Uma placa H-Bridge de 4 canais de 3A e 34V, que interliga os encoders dos micro-motores DC
à placa de programação I/O MESA 4I65, permitindo assim um controlo de velocidade conforme
o desejado. Para isso, utiliza um conector de 50 pinos para ligar à 4I65 e 4 conectores AMP Mini
Mate-N-Lock para ligar aos encoders. Cada ligação destas pode ser limitada a 1 ou 3A por
hardware conforme o desejado e permite também a sua operação, quer em altas velocidades
quer em baixas velocidades [MESA].
Figura 6.1.4 – Placa H-Bridge de 4 canais para ligação à placa 4I65.
v Uma fonte de alimentação rectificadora V104 da TRI-M específica para veículos autónomos, que
usam um sistema baseado em PC/104. Tensão de entrada de 8 a 30V DC e saída de 5 ou 12V,
consumo 25W [V104].
Figura 6.1.5 – Fonte de Alimentação V104 da TRI-M para PC/104.
v Um adaptador Compact Flash IDE CFADPT-CS da MESA com conectores IDE para ligação na
CPU de 40 pinos de 2 mm ou 44 pinos de 1’’ que permite um suporte digital para um sistema
operativo (distribuição linux). Possui um LED indicador de actividade e uma patilha para ejecção
do cartão de memoria. É também possível alterar o estado do adaptador (master/slave) [MESA].
Figura 6.1.6 – Adaptador Compact Flash IDE CFADPT-CS da MESA para PC/104.
Página 40 de 119
6.2. Comunicação
O sistema de comunicações da plataforma da RAC utiliza uma rede de dados baseada no
modelo de referência de sete camadas do protocolo OSI. O protocolo IEEE 802.11b juntamente com o
dispositivo de comunicação wireless, implementam as duas primeiras camadas da pilha protocolar do
sistema de comunicação da plataforma da RAC (camada física e de ligação) .
Para comunicação entre o sistema central e os robôs usamos:
v Um adaptador wireless USB da Edimax EW-7117U [EDIMAX]. Este adaptador é normalizado
para sistemas que utilizam a norma IEEE 802.11b 2.4GHz, possuí uma taxa de transferência de
informação até 11Mbps, entre outras características [EDIMAX].
Figura 6.2.1 – Adaptador Wireless USB da Edimax EW-7117U.
6.3. Motores e Caixas de Desmultiplicação
O uso de micro-motores DC é já uma prática comum em Futebol Robótico, devido ao seu
reduzido peso e tamanho. O excesso de peso presente na estrutura do robô poderá influenciar o
comportamento do motores, bem como, no seu consumo. Em caso de esforço ou arranque do robô, este
factor é crucial. Contudo, as altas velocidades e binário prestados por estes tipos de motores poderão
mitigar alguns problemas.
No caso da RAC utilizamos para o protótipo RACbot:
v Três micro-motores DC de 12V da Faulhaber série 2224 012 SR. Estes motores possuem
tensão nominal de 12V, com consumos máximos na ordem dos 0.570A por motor. Em relação a
velocidades estes motores conseguem atingir 7800 RPM (em vazio). Consumos na ordem dos
4.05W [FAULHABER].
Figura 6.3.1 – Micro-motor DC de 12V série SR da Faulhaber.
Página 41 de 119
v As caixas de desmultiplicação que utilizamos para este tipo de motores são da série 23/1 da
Faulhaber, especialmente para combinações com motores da série 2224 da Faulhaber.
Figura 6.3.2 – Caixa de desmultiplicação para motores série SR da Faulhaber.
6.4. Baterias
A autonomia dos robôs em Futebol Robótico é fundamental, no entanto, este factor é o que mais
influência no peso do robôs.
O protótipo RACbot utiliza:
v Pilhas alcalinas Sony de NiMh de 1.5V para construção de packs de baterias. No nosso caso
são utilizados dois packs de 9V, ou seja, um total de 18V para alimentar todo o sistema do
RACbot. A aplicação dos respectivos packs garante uma autonomia ao sistema de cerca de
30 min, o suficiente para realizar uma partida de Futebol Robótico (10 min + 10 min).
Figura 6.4.1 – Packs de baterias utilizadas no protótipo RACbot.
Página 42 de 119
7. Modelo Cinemático
Após termos abordado no capítulo anterior diversas questões relacionadas com o robô, o
primeiro passo a fazer para desenvolver um controlador é determinar as suas equações de movimento.
Neste capítulo, vamos descrever o modelo cinemático adoptado, juntamente com os seus parâmetros.
Seguidamente vamos obter as expressões de Cinemática Inversa e Directa. Finalmente, vamos analisar
outros modelos alternativos utilizados em robôs para Futebol Robótico.
7.1. Modelo Cinemático RACbot
A escolha da RAC foi construir um robô omnidireccional de três rodas desfasadas entre si por
120º, para garantir mais facilmente o seu movimento omnidireccional. Com isso, o modelo cinemático
adoptado foi o seguinte:
Figura 7.1.1 – Modelo Cinemático do RACbot.
O nosso modelo considera dois tipos de referenciais: o referencial do robô, fixo no centro da
plataforma do robô e o referencial do mundo fixo no campo de jogo. A posição do robô é representada
por duas coordenadas de posição x, y e a rotação sobre o seu próprio eixo é representada pela
velocidade angular . As velocidades tangenciais das três rodas são dadas por v1, v2 e v3. O raio da
plataforma do robô é dado por R, enquanto que o raio das rodas é dado por r. As velocidades v1’, v2’ e
v3’ são as velocidades tangenciais das três rodas resultantes de possíveis desfasamentos. Os
desfasamentos das rodas, provocados por choques ou desalinhamentos de construção, são dados por
1, 2 e 3. Finalmente a velocidade linear do robô é dada pelo vector v, que contém duas componentes
vx e vy.
Os choques entre robôs ou desalinhamentos de construção são questões importantes. O
aparecimento deste tipo de fenómenos pode levar a um comportamento não desejado no robô e
comprometer toda a trajectória pretendida. Na figura 7.1.2, é ilustrado o modo como um desfasamento
pode ocorrer numa roda. No nosso modelo é apenas considerado o desfasamento ilustrado na figura
7.1.2-b), embora na realidade este desfasamento possa ocorrer de outra maneira, ou seja, em vez de
ocorrer ao nível da roda, o desfasamento pode ocorrer ao nível do eixo do motor, como podemos
observar na figura 7.1.2-c). Na realidade, os eixos dos RACbots são bem mais curtos e compactos do
que os que são representados na figura, permitindo assim anular este tipo de comportamento e ter uma
boa estabilidade.
Página 43 de 119
a)
b)
Figura 7.1.2 – Desfasamento
c)
da roda.
O modelo cinemático adoptado visa responder a todas as questões relacionadas com o
movimento do robô mediante a plataforma adoptada. Para isso, necessitamos de determinar as suas
equações de movimento, relacionando assim todos os parâmetros considerados.
Assim, analisando o modelo adoptado podemos dizer que as velocidades tangenciais das três
rodas são dadas por:
v1 = v x − ωR
1
v2 = − v x +
2
1
v3 = − v x −
2
3
v y − ωR
2
3
v y − ωR
2
em que v x e vy são as duas componentes da velocidade do robô segundo uma determinada orientação,
é a velocidade angular do robô (sobre o seu próprio eixo) e R é o raio da plataforma.
Introduzindo agora os desfasamentos das três rodas, parâmetros
vamos ter:
1,
2
e
3
respectivamente,
′
v1 = cos(α1 )v x − sin(α 1 )v y − cos(α 1 )ωR
π
π
′
v2 = − cos( + α 2 )vx + sin( + α 2 )v y − cos(α 2 )ωR
3
3
π
π
′
v3 = − cos( − α 3 )v x − sin( − α 3 )v y − cos(α 3 )ωR
3
3
Desta maneira podemos dizer que as velocidades rotacionais
dadas por:
w1 =
′
′
′
v1
v
v
, w2 = 2 , w3 = 3
r
r
r
1,
2
e
3
das três rodas são
,onde r é o raio das rodas.
Página 44 de 119
7.2. Cinemática Inversa
A Cinemática Inversa visa obter as velocidades rotacionais 1, 2 e 3 das três rodas do robô a
partir da entrada dos parâmetros da velocidade do robô, v, e da velocidade de rotação, .
Deste modo, organizando os termos das expressões das velocidades rotacionais
das três rodas, obtemos a seguinte expressão para a Cinemática Inversa:
v ′ 
 w1 
 w1 
v x 
 1 
 w  = 1 v ′  ⇔  w  = 1 M v 
 2 r  2 
 2 r  y
′
 w3 
 w3 
 ω 
v3 
1,
2
e
3
, onde M é dada por:


 cos(α 1 )
− sin(α 1 )
− cos(α 1 ) R 


π
π
M = − cos( + α 2 ) sin( + α 2 ) − cos(α 3 ) R 
3
3


π
 − cos( − α ) − sin( π − α ) − cos(α ) R 
3
3
3


3
3
7.3. Cinemática Directa
Implementar a Cinemática Directa de um robô significa, neste caso, determinar as relações que
exprimem a velocidade linear, v, e velocidade angular, , do robô, em função das velocidades
rotacionais das três rodas.
O cálculo da expressão da Cinemática Directa é dado por:
 w1 
v x 
1
rM −1  w2  = r M −1 M v y  ⇔
 
 
r
 w3 
 ω 
vx 
 w1 


−1 
⇔ v y  = rM  w2 
 ω 
 w3 
, onde M é dada de igual maneira por:


 cos(α 1 )
− sin(α 1 )
− cos(α 1 ) R 


π
π
M = − cos( + α 2 ) sin( + α 2 ) − cos(α 3 ) R 
3
3


 − cos( π − α ) − sin( π − α ) − cos(α ) R 
3
3
3


3
3
Estas expressões têm real importância, uma vez que vão ajudar no desenvolvimento do sistema
de controlo, bem como no diagrama de controlo do simulador para compreensão do movimento do robô.
Página 45 de 119
7.4. Modelos alternativos
O modelo seguido pela RAC visa facilitar o movimento omnidireccional do robô, uma vez que
possui os três eixos desfasados de 120º. No entanto, observamos que no futebol robótico existe sempre
uma frente de ataque no robô, aquela segundo a qual possuí maior binário, e consequentemente maior
velocidade/aceleração de movimento, normalmente corresponde à frente do robô onde se localiza o
sistema de chuto. Geralmente, a frente de ataque possui uma abertura entre eixos maior, colocando a
roda traseira como uma roda efeito de leme. Deste modo, conseguimos obter um maior binário de
arranque na frente de ataque, uma vez que as velocidades tangenciais das rodas não se anulam tanto
como na configuração com uma abertura menor. Diversos problemas abordam o Futebol Robótico, e a
velocidade/aceleração dos robôs são um deles.
Existem diversos tipos de modelos e configurações para robôs em Futebol Robótico, dezenas
de equipas desenvolvem as suas próprias ideias, contudo, apenas algumas podem saborear o sabor da
vitória. Existem robôs com duas, três e quatro rodas e, dentro de cada tipo, existem diversas
configurações. A figura seguinte exemplifica alguns casos.
Figura 7.4.1 – Diversos tipos de robôs utilizados em Futebol Robótico.
Página 46 de 119
8. O Simulador RACbot
No capítulo anterior, foram identificadas as equações referentes ao modelo cinemático. Este
capítulo descreve como estas equações foram utilizadas no Simulador RACbot de modo a simular o
comportamento do robô e o seu movimento omnidireccional. O Simulador RACbot foi programado em
MATLAB, em ambiente Simulink.
O Simulador RACbot é uma ferramenta versátil, que foi usada para estudar e desenvolver o
sistema de controlo de movimento. Este capítulo descreve como o Simulador funciona. É explicado
como a simulação é feita e como ela pode ser configurada. Também são apresentados alguns testes e
conclusões referentes a pesquisas e ensaios efectuados no simulador.
8.1. Motivação
Tanto a FIRA como a RoboCup possuem simuladores que são utilizados em competições
robóticas virtuais entre equipas. Cada equipa desenvolve o sistema de inteligência artificial que
implementa um interface standard para o simulador. No entanto, o Simulador RACbot não pretende ser
uma simulação de todo o jogo, trata-se apenas de uma ajuda laboratorial para o desenvolvimento de um
sistema de controlo para o robô. O Simulador tem como objectivo a simulação e compreensão dos
diversos tipos de movimento que o robô pode executar.
A necessidade de tal programa advém das dificuldades inerentes ao desenvolvimento de um
sistema de controlo que envolve tanto software como hardware: os robôs físicos consomem muito mais
tempo para entrar em operação quando comparados com um programa de Inteligência Artificial; também
existe a interrupção e espera para recarregar as baterias; e, é claro, o hardware também sofre
desgastes e pode danificar-se. Além disso, quando interage com o mundo físico, o sistema está sujeito a
ruídos e interferências. Um bom exemplo é o software de reconhecimento de Imagens: o programa
recebe os dados de uma câmara de vídeo colocada sobre o campo de jogo, detecta a posição dos robôs
e da bola e envia essa informação para o sistema de Inteligência Artificial. Sabemos que o desempenho
do módulo de reconhecimento de imagens é directamente influenciado pelas condições de iluminação
do ambiente. Portanto, se o reconhecimento de imagens não está a funcionar correctamente,
informações erradas poderão ser enviadas para o programa de Inteligência Artificial que, por sua vez,
vai aparentar estar a funcionar incorrectamente. Por essas razões, o Simulador RACbot torna-se muito
atractivo para o desenvolvimento do sistema de controlo.
No entanto, o nível de precisão e estabilidade dos dados gerados no simulador não podem ser
alcançados por nenhum sistema que interage com o mundo físico. Um robô real habita num ambiente
dinâmico, muito susceptível a falhas e erros de programação. O desenvolvimento do Simulador RACbot
vai ajudar na compreensão de alguns desses fenómenos e comportamentos indesejados.
8.2. MATLAB Simulink
MATLAB é uma linguagem de programação apropriada ao desenvolvimento de aplicações
científicas. Como o próprio nome sugere, o MATLAB é adequado para a implementação e teste de
soluções com facilidade e precisão, sem perder tempo com detalhes específicos de linguagem de
programação. Para isso, possui facilidades de computação, visualização e programação, dentro de um
ambiente amigável e de fácil aprendizagem.
Figura 8.2.1 – MATLAB - Simulink.
Página 47 de 119
Actualmente o MATLAB dispõe de uma biblioteca bastante abrangente de funções matemáticas,
geradores de gráficos e manipulação de dados que auxiliam muito o trabalho do programador. Possui
uma vasta colecção de bibliotecas denominadas toolboxes para áreas específicas como: equações
diferencias, estatística, processamento de imagem, processamento de sinal, etc. A linguagem e o
ambiente de programação MATLAB permitem ainda que, o programador possa escrever as suas
próprias bibliotecas para MATLAB.
O Simulink é uma extensão do MATLAB. É usado para simular sistemas dinâmicos, possuí uma
interface gráfica que, através do recurso a uma extensa biblioteca de funções, permite construir
facilmente diagramas de blocos representativos de sistemas para analise e projecto. Neste contexto, o
objectivo de desenvolver um simulador capaz de representar a trajectória do robô, perante uma
solicitação do utilizador, facilita a compreensão e o planeamento para o desenvolvimento dum sistema
de controlo adequado ao futebol robótico.
8.3. Implementação
A implementação do simulador, permite verificar rapidamente o comportamento do robô perante
um determinado conjunto de parâmetros. Contudo, o seu uso eficiente depende de uma série de
factores. Por exemplo, o modelo adoptado deve estar correcto e o tipo de teste a que ele se submete
deve ser coerente com o que se deseja comprovar, no entanto, existem limitações intrínsecas de
qualquer sistema de simulação que não podem ser evitadas.
Figura 8.3.1 – Fase de implementação do Simulador RACbot.
O simulador tem como principal vantagem a análise paralela que é feita quando este simula o
movimento do robô numa determinada trajectória, ou seja, pode ser observado o comportamento das
velocidades dos três motores, bem como o vector de entrada do modelo cinemático. A orientação do
robô, influenciada pela velocidade angular , também pode ser observada. Uma trajectória no simulador
é dividida em segmentos de recta. Cada segmento, ou set-point, é caracterizado por uma posição no
referencial do campo de jogo, por uma velocidade linear e por uma velocidade angular. O simulador
recebe um conjunto de set-points à entrada, que caracterizam o comportamento do robô ao longo da
trajectória.
Numa primeira versão o simulador funcionava apenas no interpretador de linha de comandos,
ou seja, era feita uma simulação do resultado das equações da cinemática para diferentes valores de
entrada. Nas versões posteriores foram desenvolvidos diagramas de blocos em ambiente Simulink para
representação do respectivo diagrama de controlo.
8.3.1. Diagrama de Controlo
Inicialmente foi desenvolvido um simulador capaz de demonstrar o movimento real do robô.
Embora não conseguisse corrigir o movimento, no caso em que o robô possuía velocidade angular
sobre o seu próprio eixo, conseguia demonstrar a influência dos desfasamento nas rodas. Nessa altura,
podemos tirar conclusões acerca da influência da rotação na trajectória e, de como ela influencia
bastante o movimento. Posteriormente, foi desenvolvido um diagrama de controlo capaz de corrigir esse
Página 48 de 119
fenómeno, ou seja, a trajectória omnidireccional segunda uma linha recta já era possível e sem qualquer
desvio, o problema foi portanto mitigado e a simulação foi conseguida.
Após várias alterações durante a fase de implementação, a versão final é ilustrada na figura
seguinte.
Figura 8.3.1.2 – Diagrama de Controlo do Simulador RACbot.
A sua constituição pode parecer algo complexa, no entanto, pode ser descrita da seguinte
forma:
•
A introdução dos parâmetros de entrada, ou seja, o conjunto de set-points que constituem uma
trajectória, é efectuada no primeiro bloco. O set-point corresponde ao conjunto de pontos (x, y)
por onde o robô vai passar, juntamente com a sua velocidade média, v, e velocidade angular, ,
a cumprir por esses mesmos pontos. A configuração do set-point utilizado é:
Exemplo: [10 10 1 0.05, 10 0 1 0, 20 0 1 -0.1, 20 10 1 0]
⇒ A trajectória vai ser a seguinte (o robô encontra-se na origem):
Ponto A
Ponto B
Ponto C
Ponto D
(10, 10)
(10, 0)
(20, 0)
(20, 10)
com v = 1 m/s e
com v = 1 m/s e
com v = 1 m/s e
com v = 1 m/s e
= 0.05 rad/s
= 0 rad/s
= - 0.1 rad/s
= 0 rad/s
•
O bloco seguinte faz a transformação do set-point para os parâmetros de entrada da cinemática
inversa, ou seja, realiza uma transformação em componentes vx e vy da velocidade linear, v, e
na componente de rotação sobre o eixo, representada pela velocidade angular . Essa
transformação é executada para todos os set-points.
•
As expressões de cinemática inversa obtidas no capítulo anterior, são utilizadas no bloco
seguinte para calcular as velocidades de rotação 1, 2 e 3 das três rodas do robô. São dados
importantes, pois, mostram a variação das velocidades dos motores ao longo do tempo de
acordo a trajectória pretendida.
•
Seguidamente é utilizado o bloco da cinemática directa, esta transforma as velocidades dos três
motores 1, 2 e 3 novamente nas componentes vx e vy da velocidade linear, v, e na
componente de rotação . Componentes que vão ser utilizadas no bloco seguinte para simular
o movimento do robô. Paralelamente a este bloco, existe um outro muito semelhante, a
diferença está nos parâmetros de desfasamento da cinemática, ou seja, num bloco o movimento
é ideal (os desfasamentos são nulos), no outro, o movimento é afectado pela introdução dos
parâmetros de desfasamento 1, 2 e 3.
Página 49 de 119
•
A representação do movimento é efectuada através do último bloco, que utiliza os parâmetros
de saída da cinemática directa para efectuar uma simulação gráfica da trajectória do robô. A
velocidade é integrada ao longo do tempo para obter a posição.
Com a ajuda das bibliotecas do MATLAB Simulink, é conseguida a simulação do movimento do
robô, segundo uma trajectória predefinida. A plataforma de programação do MATLAB permite assim
desenvolver uma aplicação harmoniosa e de fácil utilização. Podemos alterar facilmente o valor dos
parâmetros da cinemática, bem como, analisa-los em conjunto para melhor compreensão.
8.3.2. Visualização
A visualização da informação no Simulador RACbot pode ser feita de varias maneiras,
consoante a necessidade do utilizador. Após a introdução do set-point desejado, a simulação é realizada
durante o tempo de execução do robô na referida trajectória. Tal acontece, devido à utilização de um
contador interno do Simulink como base temporal, permitindo assim um maior realismo da simulação.
Por outro lado, a simulação também ocorre ao nível do diagrama de controlo, possibilitando
durante ou no final da simulação, analisar o estado de outras variáveis cinemáticas ao longo do tempo e
do espaço.
a) Trajectória ideal
b) Trajectória com desfasamentos
Figura 8.3.2.1 – Simulação da trajectória do robô, set-point [7 1 1 0.5, 10 3 1 0, 12 6 1 -0.5, 11 9 1 0, 9 10 1 0.5].
Na figura 8.3.2.1 é ilustrada a simulação da trajectória do robô segundo o set-point descrito,
quer no caso ideal, quer no caso de presença de desfasamentos. As linhas a azul na figura representam
a orientação do robô naquele ponto da trajectória. O comportamento das velocidades rotacionais 1, 2
e 3 das três rodas, ao longo do tempo, segundo o set-point introduzido é o ilustrado na figura 8.3.2.2.
Figura 8.3.2.2 – Velocidade dos três motores segundo o set-point anterior.
Página 50 de 119
Também é feita a visualização das componentes v x e vy da velocidade linear e a variação do
parâmetro
correspondente à velocidade angular, quer no caso ideal, quer no caso de presença de
desfasamentos. A possibilidade de visualização do comportamento dos três motores em termos de
velocidade, bem como, de outros parâmetros cinemáticos, ajuda-nos na análise da trajectória do robô e
no estudo de fenómenos que podem afectar o movimento.
Figura 8.3.2.3 – Variação dos parâmetros vx, vy e
segundo o set-point anterior.
O diagrama de controlo também nos possibilita a visualização e análise da orientação do robô
ao longo do tempo, quer no caso ideal, quer no caso de presença de desfasamentos.
Figura 8.3.2.4 – Orientação do robô ao longo do tempo segundo o set-point anterior.
A figura 8.3.2.4 ilustra a variação da orientação do robô ao longo do espaço percorrido de
acordo um set-point introduzido. Na figura 8.3.2.5-a) podemos analisar a trajectória ideal pretendida
(sem desfasamentos) juntamente com a variação do parâmetro . Na figura 8.3.2.5-b) podemos analisar
a mudança da trajectória e orientação do robô, com a introdução de um desfasamento numa roda.
Página 51 de 119
Figura 8.3.2.5 – Animação vectorial efectuada pelo Simulador RACbot.
Inicialmente, a aplicação gráfica da simulação era apenas de carácter vectorial, conforme ilustra
a figura 8.3.2.5. Posteriormente, desenvolveu-se uma animação de modo a tornar mais realista o
comportamento do robô.
Figura 8.3.2.6 – Animação efectuada ao Simulador RACbot.
Em relação à animação do simulador RACbot, foi efectuado um melhoramento no refresh da
aplicação que anima o comportamento do robô. Foram utilizadas ferramentas de rendering, tais como, o
OpenGL, que permitiram o melhoramento da animação. É possível introduzir, caso necessário, outros
conceitos e melhoramentos visuais, tais como, linhas de marcação de campo, balizas, obstáculos, etc.
8.3.3. Testes e Resultados
Com base no simulador desenvolvido, foram efectuados diversos testes, que levaram a uma
melhor compreensão do sistema de controlo e de todo o comportamento do robô durante o seu
movimento. De seguida são descritos e ilustrados alguns testes e ensaios correspondentes a variadas
trajectórias predefinidas.
A correcção do vector velocidade em função da velocidade angular, foi um problema testado.
Concluiu-se que, ao realizar um movimento de translação entre dois pontos, ao mesmo tempo que se
realiza um movimento de rotação sobre o centro de massa, é necessário corrigir o vector velocidade em
função da velocidade angular. O vector velocidade tem as componentes vx e v y no referencial do robô,
de modo que, se este rodar , temos de fazer uma rotação do referencial de forma a manter o vector
velocidade na mesma orientação.
Página 52 de 119
x ' = x cos α + y sin α
y ' = y cos α − x sin α
 x'  cos α
 y ' = − sin α
  
sin α   x 
cos α   y 
Figura 8.3.3.1 – Rotação do referencial do robô em .
Para que não ocorram desvios significativos, temos que corrigir o referencial em intervalos de
tempo reduzidos de acordo com a matriz de rotação. O parâmetro é o ângulo que o referencial roda
em função da velocidade angular dada.
O bloco da simulação também é afectado com esta correcção, como tal, temos que executar de
igual maneira uma rotação no referencial. Deste modo, o vector velocidade mantém a orientação
correcta. A matriz de rotação utilizada é dada por:
x2 = x1 cos α − y1 sin α
y2 = y1 cos α + x1 sin α
 x2  cos α
 y  =  sin α
 2 
Figura 8.3.3.2 – Rotação do referencial do robô em
− sin α   x1 
cos α   y1 
utilizada na simulação.
A simulação da trajectória era feita em relação a um referencial fixo do mundo, agora essa
simulação é feita em relação a um referencial móvel que é o robô. De modo a ilustrar a correcção do
vector velocidade, em função da velocidade angular do robô, são ilustradas as seguintes figuras que
demonstram o comportamento do robô nas varias trajectórias (ideal, real e com correcção).
b) Trajectória real
Página 53 de 119
c) Trajectória real com correcção
d) Todas as Trajectórias
Figura 8.3.3.3 – Simulação do movimento do robô, set-point [10 10 1 0.05, 10 0 1 0, 20 0 1 -0.1, 20 10 1 0].
Conforme já vimos, os desfasamentos das rodas provocados por choques ou desalinhamentos
de construção são dados por 1, 2 e 3. De modo a compreender estes fenómenos foram realizados
alguns testes. As figuras seguintes ilustram algumas conclusões.
b)Trajectória com desfasamentos
a) Trajectória ideal e Trajectória com desfasam entos
Figura 8.3.3.4 – Simulação do movimento do robô, set-point [7 1 1 0.5, 10 3 1 0, 12 6 1 -0.5, 11 9 1 0, 9 10 1 0.5].
Na figura 8.3.3.4 podemos observar como os desfasamentos mecânicos podem influenciar a
trajectória real do robô. Verifica-se que um pequeno desfasamento (1º a 5º graus) pode ter um impacto
muito significativo na trajectória. Se não existir um equilíbrio perfeito, o robô tem tendência a ganhar
velocidade de rotação sobre o seu centro, provocando um deslocamento progressivo na sua orientação.
Se não conhecermos a posição real do robô ao logo da trajectória, torna-se impossível estimar os
parâmetros correctamente.
Página 54 de 119
O problema da aceleração também foi testado, como sabemos o arranque do robô nunca será
instantâneo muito menos em carga, e quanto maior for o peso menos influente será a aceleração. Os
motores normalmente possuem uma rampa de aceleração e os robôs da RAC não fogem à regra. O
parâmetro da aceleração é colocado normalmente no máximo, no entanto, este factor pode levar a
alterações na trajectória do robô devido ao comportamento não linear dos três motores.
Foram efectuadas alterações no controlo de trajectórias do simulador passando a incluir um
parâmetro de aceleração com o objectivo de aproximar ainda mais o comportamento do simulador com
a realidade. Anteriormente, a simulação era realizada tendo em conta que o robô mudava
instantaneamente de velocidade no set-point seguinte. A partir de agora a velocidade é uma função
continua e por sua vez, a trajectória do robô é uma função diferenciável, ou seja, todas as mudanças de
direcção são curvas mais ou menos suaves de acordo com o valor da aceleração, como podemos ver
na figura 8.3.3.5. A figura 8.3.3.6 mostra as componentes da velocidade linear vx e vy bem como a
velocidade angular que neste caso é nula, também são representadas as velocidades angulares dos
motores afectadas também por este parâmetro. Podemos observar que todas as velocidades são
funções continuas e o declive das transições tem o valor do parâmetro aceleração.
Figura 8.3.3.5 – Simulação do movimento do robô, set-point [0.6 0 1 0, 0.6 0.4 1 0, 0 0.4 1 0, 0 0.2 1 0].
Figura 8.3.3.6 – Variação dos parâmetros vx, vy e
bem como a variação das velocidades dos três motores.
Página 55 de 119
8.3.4. Conclusões
Pela observação dos resultados das simulações anteriores verificamos que em condições ideais
o robô percorre a trajectória pretendida. O modelo converte os set-points em comandos de velocidade
ao longo do tempo. Os comandos de velocidade são posteriormente convertidos pela equação de
cinemática inversa nas velocidades angulares que são fornecidas aos motores. O bloco de simulação de
posição desenha a trajectória do robô tendo em conta os parâmetros físicos que foram implementados
no modelo.
Com a introdução dos parâmetros de desfasamento nas rodas verificamos que o
comportamento do robô é totalmente alterado, a necessidade da implementação de um sistema de
calibração torna-se evidente. O conhecimento destes parâmetros são de elevada importância, pois uma
vez conhecidos podem ser introduzidas correcções no sistema de controlo de modo a compensar os
comportamentos indesejados. No capítulo seguinte é abordada esta questão em mais detalhe.
No que diz respeito ao movimento omnidireccional, no simulador o robô comporta-se
correctamente, o que comprova a boa implementação da simulação e da cinemática. No entanto, no
mundo físico a realidade é outra. A presença de atritos, fricções e defeitos nas rodas bem como o
excesso de peso vai influenciar o comportamento do robô podendo este não executar o movimento
pretendido. Tratam-se de questões eminentes que requerem por vezes a alteração da estrutura da
plataforma e configuração. Mais à frente falaremos dos testes e resultados referentes ao sistema de
controlo implementado no robô na situação real, não simulada.
A aceleração dos motores é uma questão importante de simulação e estudo. Não foi feito
nenhum estudo teórico referente à dinâmica do robô, no entanto, através do simulador RACbot podemos
tirar como conclusão que a presença de um arranque não instantâneo dos motores do robô pode levar a
uma alteração da trajectória pretendida. No entanto pretende-se que o valor da aceleração seja o mais
alto possível de modo a simular um arranque imediato e desta forma evitar futuros problemas. O
comportamento em aceleração do robô é difícil de se estudar, devido ao facto de não podermos
desacoplar as rodas individualmente. A influência conjunta das três rodas interfere e dificulta o estudo
da dinâmica.
Página 56 de 119
9. Calibração
A inserção dos ângulos de desfasamento no modelo cinemático, introduz uma nova abordagem
na implementação do controlador de movimento. Torna-se necessário desenvolver um procedimento de
calibração de modo a conhecer estes parâmetros. Assim, o controlador ficará apto a corrigir desvios na
trajectória, provocados por eventuais desalinhamentos nos eixos. A correcção do movimento é realizada
introduzindo na matriz de cinemática inversa aproximações razoáveis para os parâmetros , conforme
foi analisado no capítulo 7.
9.1. Motivação
A introdução dos parâmetros de desfasamento
no modelo foi uma primeira tentativa de
conseguir melhorar o desempenho do controlador face aos previsíveis problemas de controlo. Como a
construção do protótipo decorreu em simultâneo com o projecto do controlador, não foi possível avaliar o
seu comportamento face a estes problemas. No entanto, a implementação do Simulador RACbot veio
facilitar este estudo. É de prever que surjam problemas em controlar o robô devido a desalinhamentos
mecânicos, ou às elevadas velocidades e acelerações da plataforma. Os dados de posição fornecidos
pela câmara são de importância fundamental para fechar a malha de controlo, no entanto, o fluxo de
dados e o seu atraso podem não ser suficientes para controlar em tempo real o movimento adequado do
robô.
O desenvolvimento deste procedimento de calibração visa tornar a plataforma mais controlável,
mas apenas pode ser visto como um primeiro passo no estudo da dinâmica do robô. Em função dos
testes efectuados sobre o modelo simples que é proposto, foram tiradas conclusões e orientações para
trabalho futuro.
Figura 9.1.1 – Desfasamento
da roda.
9.2. Assumpções
Dada a não linearidade das equações de cinemática inversa não é possível obter uma
expressão directa para 1, 2 e 3 (ângulos de desfasamento das rodas). Fazendo algumas
assumpções, foi desenvolvido um método iteractivo para calcular estes ângulos que causam desvios na
trajectória do robô. Foi assumido que: quando o movimento do robô é paralelo ao eixo de uma das
rodas, essa roda não desenvolve tracção, a sua influência no desvio da trajectória é pequena e pode ser
desprezada. Se se verificar que nestas condições este desfasamento não poderá ser desprezado, então
terá de se adaptar um género de patim ou base esférica à roda de modo a conseguir desacoplar este
desfasamento em relação aos outros dois.
9.3. Procedimento de Calibração
O procedimento de calibração é um procedimento iteractivo em três passos. Cada passo
introduz uma trajectória colinear a um dos eixos. O desvio provocado na trajectória devido aos
desfasamentos, pode ser corrigido através do ajuste dos parâmetros das restantes rodas, até que o
Página 57 de 119
robô realize um movimento em linha recta. No terceiro e último passo todos os ângulos de
desfasamento são ajustados em simultâneo, mantendo a mesma relação de magnitude e a mesma
relação entre eixos, dois a dois. Como consequência, cada eixo fica calibrado em relação aos outros
dois.
Na figura 9.3.1 pode-se observar a dependência entre desfasamentos em relação a uma
determinada trajectória. Por exemplo, ao ser injectada uma trajectória perpendicular à roda R1, ou seja,
velocidades simétricas para os motores 2 e 3 e velocidade nula para o motor 1, é possível que a
trajectória do robô não realize uma linha recta perpendicular à roda, mas sim uma curva.
Figura 9.3.1 – Dependência entre desfasamentos em relação a uma determinada trajectória.
Este comportamento é devido a existência de desfasamentos nas rodas. Se for colocado um
patim na roda 1 ou se for desprezado a existência de algum desfasamento nessa mesma roda, pode ser
tirada uma relação entre os desfasamentos nas rodas 2 e 3. Se a trajectória não se realizar em linha
recta perpendicularmente à roda R1 e se o robô começar a desviar-se para a direita, conclui-se que
2 + 3 < 0, se este for para a esquerda, então 2 + 3 > 0. Ao efectuar os ajustes nos parâmetros da
cinemática inversa é possível corrigir este comportamento para a situação desejada (linha recta
perpendicular à roda), inferindo assim os valores de 2 e 3.
Considerando outra trajectória, por exemplo, perpendicular à roda R3 a situação é semelhante,
apenas mudam os desfasamentos. É desprezado agora o parâmetro 3 e a analise é realizada em
relação aos outros desfasamentos. O processo torna-se assim repetitivo, terminando com um ajuste
final entre todos os desfasamentos em conjunto.
Este procedimento iteractivo de calibração pode ser descrito nos seguintes passos:
v 1º Passo - Injectar no robô uma trajectória perpendicular à roda R1, ou seja, velocidades
simétricas para os motores 2 e 3 e velocidade nula para o motor 1.
•
•
•
Observar a trajectória efectuada pelo robô.
Se este se deslocar em linha curva e não em linha recta, conforme o pretendido, variar o
parâmetro 2, aumentando ou diminuindo progressivamente de modo a corrigir essa
trajectória.
Após a correcção, o robô passa a deslocar-se em linha recta perpendicular à roda R1,
fica concluído o 1º passo.
Observação: De notar que o robô não deve variar a sua orientação durante o movimento.
Página 58 de 119
•
•
•
Se este se deslocar em linha curva e não em linha recta conforme o pretendido, variar o
parâmetro 1, aumentando ou diminuindo progressivamente de modo a corrigir essa
trajectória.
Após a correcção, ou seja, o robô passa a deslocar-se em linha recta perpendicular à
roda R3, fica concluído o 2º passo.
•
•
Se este se deslocar em linha curva e não em linha recta conforme o desejado, variar de
igual maneira e em conjunto todos os parâmetros 1, 2 e 3. No entanto, 2 terá que
possuir sinal contrário (por exemplo se aumentarmos 0,02 rad a 1 e 3, então 2 terá
que ser variado em –0,02 rad) de modo a manter a relação do desfasamento dois a
dois.
9.4. Testes em Simulação
Para validar o procedimento de calibração, numa primeira fase, foi utilizado o simulador RACbot.
Foram introduzidos parâmetros de desfasamento desconhecidos pelo controlador no bloco de
cinemática directa (bloco que implementa a simulação do movimento do robô), tais desfasamentos
resultam numa alteração significativa entre a trajectória real e a pretendida. Em seguida aplicou-se o
procedimento de calibração, tal como foi descrito anteriormente, fazendo variar os parâmetros na
matriz de cinemática inversa no bloco do controlador de movimento.
Figura 9.4.1 – Alterações efectuadas no simulador para simular o processo de calibração.
Página 59 de 119
Nas figuras seguintes é possível observar uma trajectória efectuada pelo robô simulado. Na
figura 9.4.2-a) é apresentada a trajectória ideal desejada. Na figura 9.4.2-b) é observada a trajectória
ideal (verde) e a trajectória real com desfasamentos desconhecidos (vermelho) realizada pelo robô. A
figura 9.4.2-c) representa a trajectória real do robô após a aplicação do procedimento de calibração e a
figura 9.4.2-d) mostra como a trajectória real coincide com a trajectória ideal após a calibração.
b) Trajectória ideal e trajectória com desfasamentos reais
c) Trajectória com correcção nos desfasamentos
d) Trajectória com correcção e trajectória ideal
Figura 9.4.2 – Procedimento de calibração utilizando o simulador RACbot.
9.5. Conclusões
O procedimento de calibração obtém bons resultados quando aplicado no simulador do robô.
Após a aplicação do procedimento de calibração as diferenças entre a trajectória real e a ideal são
mínimas. As próximas etapas de desenvolvimento passam pela aplicação manual do procedimento ao
protótipo da plataforma para que a sua validação seja efectuada. Tais resultados serão apresentados no
capítulo 11. Se for verificada a validade do procedimento ao protótipo, as características da plataforma
permitem que o procedimento de calibração possa vir a ser implementado ao nível do controlador
central de maneira automática e sem intervenção humana.
Este procedimento pode ser considerado como o primeiro estudo sobre o comportamento
dinâmico da plataforma. A optimização das funções de controlo passam por tentar compreender as
diversas variáveis que afectam o movimento do robô. Particularmente, o estudo das forças provocadas
pela aceleração podem ser alvo de um estudo futuro.
Página 60 de 119
10. Sistema de Controlo
As características do hardware utilizado nos robôs da RAC (RACbots) são uma consequência
directa das funcionalidades que se pretendem implementar a curto e a médio prazo. Muitas destas
funcionalidades requerem a utilização de recursos consideráveis em termos de processamento e de
recursos do sistema. Para além do sistema de controlo de movimento e do sistema de comunicação
TCP/IP [IETF] sobre IEEE 802.11b [IEEE], é necessário que o hardware e o software da plataforma da
RAC tenha capacidade para suportar, futuramente, aplicações de processamento de visão e de
inteligência artificial.
Dada a complexidade dos algoritmos, o sistema operativo tem de suportar um ambiente de
desenvolvimento de alto nível, assim como bibliotecas de funções desenvolvidas por terceiros que são
imprescindíveis, por exemplo, nos algoritmos de visão e comunicação.
Neste capítulo são enumeradas as características pretendidas e as opções tomadas a nível da
escolha do sistema operativo, em seguida é feita uma descrição das particularidades do sistema de
desenvolvimento e do sistema de produção. É abordado o subsistema de comunicações e a sua
configuração. São analisadas as funcionalidades do controlador dos motores (softDMC) e o interface
com o sistema operativo através da placa MESA 4i65. Para finalizar, é feita uma descrição da
arquitectura e implementação do programa de controlo de movimento.
10.1. Sistema Operativo
Os requisitos definidos para os robôs da RAC em termos de funcionalidades, tornaram
impossível a implementação do sistema de controlo usando um simples microcontrolador programável.
Um dos objectivos é precisamente criar uma plataforma robusta, dotada de boa capacidade de
processamento e de um sistema de comunicações fiável. Por outro lado, a plataforma tem de permitir o
desenvolvimento de aplicações complexas. Devido a complexidade do hardware utilizado, foi necessário
seleccionar um sistema operativo que verificasse alguns requisitos essenciais.
Em informática, o sistema operativo (SO) é o software responsável pelo controlo directo e
gestão do hardware e das funções básicas de todo o sistema. Para além disso, disponibiliza os serviços
que permitem correr as aplicações.
O sistema operativo certifica-se de que as aplicações são capazes de utilizar a memória, os
dispositivos de entrada/saída (I/O) e o acesso ao sistema de ficheiros. Se existirem várias aplicações a
serem executadas, o SO faz o escalonamento dos processos, de modo a atribuir a todas as aplicações
o tempo de processador adequado à sua execução, impedido também que possam interferir entre si.
Geralmente, o sistema operativo é a primeira camada de software carregada na memória de um
computador quando este é ligado. Sendo a primeira camada, todo o software que é carregado
posteriormente, depende desta para lhe fornecer diversos serviços básicos comuns. Já que é assumido
que estes serviços básicos são fornecidos pelo SO, não existe a necessidade de voltar a implementa-los
ao nível da aplicação. A parte do código que implementa estes serviços é o chamado kernel do sistema
operativo. O kernel dos sistemas operativos evoluiu de bibliotecas de funções para programas que
controlam os recursos do sistema devido à necessidade de proteger e registar a utilização dos recursos.
10.1.1. Características Pretendidas
O hardware que foi adoptado para a plataforma do robô, como já foi referido no capitulo 5, é
basicamente um computador embebido compatível com os computadores pessoais (IBM-PC). Existem
vários sistemas operativos e versões que suportam os dispositivos que a plataforma utiliza. No entanto
nem todos cumprem os requisitos necessários, que são:
v Tem de ser compacto de modo a caber num dispositivo do tipo Flash-ROM;
v Tem de permitir o funcionamento directamente da RAM do PC-104 e de permitir a modificação
do processo de arranque do sistema;
v Necessita de suportar todos os dispositivos e periféricos adicionais utilizados na plataforma;
Página 61 de 119
v Tem de ser uma plataforma eficiente e robusta, capaz de fornecer ferramentas de
desenvolvimento avançadas;
v Necessita de possuir suporte para o desenvolvimento de aplicações de tempo-real;
Após a análise geral dos requisitos ficou claro que, apenas existiam duas alternativas para o
sistema operativo que à partida poderiam reunir grande parte dos requisitos: O Microsoft Windows [WIN]
e o GNU/Linux [LINUX]. Cada um destes, possui um grande número de características diferentes e que
necessitavam de ser estudadas com mais detalhe.
O Windows é uma gama de sistemas operativos para computadores pessoais e servidores. Foi
inicialmente introduzido pela Microsoft em 1985 acabando por dominar o mercado mundial com uma
quota estimada em 95% nos computadores de secretária. As versões recentes do Windows são
sistemas operativos completos e não necessitam de outros sistemas mais antigos (MS-DOS) para
funcionar. O Windows é um sistema proprietário com código fonte fechado. A empresa Microsoft é
detentora dos direitos de autor e controla a sua distribuição.
A quota de mercado que o Windows detém nos sistemas operativos para computadores
pessoais, fazem dele o sistema mais conhecido e para o qual existe maior probabilidade de obter drivers
para os dispositivos. No entanto, o Windows não possui os requisitos necessários. As suas
características são orientadas para o uso em computadores de secretária, têm um interface gráfico
pesado e desadequado para o que se pretende, não é suficientemente configurável para poder ser
instalado de maneira fácil numa memória flash e para concluir, não é suficientemente compacto para
caber numa partição de memória virtual.
O sistema operativo Linux é um dos exemplos mais conhecidos de software livre e de
desenvolvimento de código aberto, ao contrário de outros sistemas operativos mais importantes (como o
Windows ou o Mac OS [MAC], todo o seu código fonte está disponível ao público e pode ser usado,
modificado e distribuído por qualquer pessoa.
O termo Linux refere-se especificamente ao kernel Linux, mas o termo é normalmente usado
para descrever todos os sistemas operativos derivados do Unix [UNIX], que são baseados no kernel
Linux combinados com as ferramentas e bibliotecas do projecto GNU [GNU] da Free Software
Foundation [FSF]. As distribuições de Linux oferecem grandes quantidades de software para além do
sistema operativo, existem mais de 300 distribuições disponíveis.
Inicialmente, o Linux foi desenvolvido e utilizado por entusiastas. Desde essa altura, ganhou o
suporte de grandes empresas como a IBM, Hewlett-Packard e Novell para o uso em servidores e está a
começar a ganhar quota de mercado nos computadores de secretária. Os analistas atribuem o seu
sucesso ao facto de ser independente do vendedor, ao baixo custo, à sua segurança e fiabilidade.
O Linux foi originalmente desenvolvido para os microprocessadores Intel 386, mas agora
suporta uma variedade de arquitecturas. Tem sido empregue em aplicações que vão desde os
computadores pessoais até aos super computadores e sistemas embebidos como é o caso dos
telefones moveis e os gravadores de vídeo pessoais.
O suporte para alguns dispositivos novos ou menos vulgares continua a representar um
problema. Embora alguns fabricantes mais reputados disponibilizem drivers para Linux, alguns dos
drivers disponíveis têm sido desenvolvidos por voluntários depois do lançamento do produto.
Frequentemente este desenvolvimento é obtido a custa de engenharia inversa de algum tipo, pois certos
fabricantes continuam a manter um véu de segredo sobre as especificações de hardware e firmware dos
seus produtos.
Pelas características apresentadas o Linux mostrou-se como o sistema operativo ideal para ser
utilizado na plataforma da RAC. No entanto, foi necessário fazer uma análise mais profunda nas
distribuições que melhor se enquadravam com os requisitos, pois cada uma tinha objectivos e
particularidades diferentes.
10.1.2. Analise de Candidatos
Linux é predominantemente usado como parte integrante de uma distribuição de Linux
[DISTRO]. Estas, são compilações de aplicações feitas por indivíduos, equipas e organizações
profissionais. Incluem um qualquer número de software de sistema adicional assim como aplicações
Página 62 de 119
úteis para o utilizador final. Incluem normalmente um processo que permite ser instalado de maneira
fácil no computador. As distribuições são criadas com objectivos diferentes. Localização geográfica,
suporte a uma arquitectura especifica, suporte a aplicações de tempo real e sistemas embebidos são
alguns dos exemplos de aplicações do Linux. Muitas distribuições incluem apenas e deliberadamente
software livre.
Uma distribuição generalista inclui o kernel Linux, as bibliotecas e ferramentas do projecto GNU,
interfaces de linhas de comandos e literalmente milhares de pacotes de aplicações de software, desde
pacotes de produtividade para escritório, ambientes gráficos, compiladores, editores de texto e
ferramentas cientificas.
10.1.2.1.
Puppy Linux
O Puppy Linux [PUPPY] foi a primeira distribuição analisada. Esta distribuição tinha sido a
primeira inicialmente seleccionada para avaliação pelos membros da RAC, pois cumpria grande parte
dos requisitos. É uma distribuição baseada em live-CD, ou seja, o sistema reside num CD-ROM que
serve como dispositivo de arranque. É bastante compacta, fiável, fácil de usar e cheia de
funcionalidades. A distribuição é actualizada regularmente, tem bom suporte e boa documentação. Todo
o sistema operativo e aplicações correm a partir da RAM, fazendo com que o sistema seja muito rápido
e permitindo que o suporte digital de arranque (CD-ROM) seja removido após a inicialização do sistema
operativo. São incluídas aplicações como o Mozilla, AbiWord, SodiPodi, Gnumeric e Gaim. A distribuição
é independentemente desenvolvida a partir do zero. É considerada útil para funcionar em computadores
lentos ou mais antigos, como sistema de emergência e recuperação, como sistema de demonstração
do Linux ou como um sistema operativo completo e generalista. Para além do CD-ROM, o Puppy Linux
pode arrancar a partir de uma memória flash com interface USB.
Quando o sistema arranca todo o conteúdo armazenado no suporte digital é descomprimido
numa zona da memória RAM (a ramdisk). O computador necessita de ter pelo menos 128M de RAM
para que todo o Puppy Linux seja carregado na memória.
No entanto, a distribuição Puppy Linux apresenta algumas lacunas que são comuns a todas as
distribuições semelhantes. O sistema já vem todo construído, trazendo um conjunto de drivers mais
comuns. Por outro lado, o kernel do sistema operativo é uma versão alterada para satisfazer um
determinado objectivo. Para além disso, o criador da distribuição não disponibiliza, nem seria viável,
todo o ambiente de desenvolvimento, código fonte e a respectiva configuração que usou para construir a
distribuição.
A necessidade de compilar de raiz todo o sistema resulta da plataforma da RAC utilizar o
dispositivo de comunicação wireless USB EDIMAX LAN Adapter [EDIMAX]. Este dispositivo é baseado
no chip Zydas zd1201 [ZyDAS]. O fabricante não disponibiliza um driver para Linux, mas existe o código
fonte de um driver em desenvolvimento por terceiros que, para funcionar, necessita de ser compilado
para uma versão standard, não alterada, do Kernel Linux. Para além disso, o dispositivo não implementa
correctamente o protocolo de handshake do hub USB [USB] devido a uma interpretação diferente do
protocolo por parte do fabricante, o que torna necessário a aplicação de um patch e à recompilação do
kernel do sistema.
10.1.2.2.
Gentoo Linux
O Gentoo Linux [GENTOO] é uma distribuição Linux baptizada com um nome de uma espécie
de pinguim (pinguim Gentoo). Foi concebido para ser modular, portável e optimizado para o sistema
onde se pretende instalar. Isto é, construindo todas as ferramentas e utilitários a partir do código fonte,
embora, por conveniência, vários pacotes pré-compilados estão disponíveis para diversas arquitecturas.
O Gentoo consegue isto através do sistema Portage. O Gentoo é também muito apreciado pelos seus
fóruns de discussão e pela grande base de conhecimento que representam.
A distribuição pode ser instalada de várias maneiras. A maneira mais comum é usar o Live-CD
do Gentoo, mas também pode ser instalado a partir de uma instalação Linux existente. O computador
precisa de ser preparado para a instalação criando partições no disco rígido e instalando um sistema
base que corresponde a varias etapas possíveis. A instalação a partir do Live-CD permite uma maior
personalização e optimização do SO, enquanto que a instalação a partir de um Linux existente permite
uma instalação mais rápida.
Página 63 de 119
O sistema Portage funciona de maneira semelhante ao APT da distribuição Debian [DEBIAN]. É
um sistema de gestão e obtenção de pacotes de aplicações, possui uma base de dados com os pacotes
instalados localmente e com os disponíveis para download pela Internet. O Portage é escrito na
linguagem Python [PYTHON] e pode ser considerada a aplicação que define a distribuição. Embora o
sistema seja conhecido por Portage as suas funcionalidades são invocadas na linha de comandos pelo
comando emerge.
A instalação é realizada num ambiente chroot (processo que modifica a raiz do sistema para
outra localização) onde o sistema Portage do Gentoo é usado para instalar os pacotes fundamentais no
novo sistema. O Gentoo não tem um programa de instalação como muitas outras distribuições, o
utilizador segue uma série de passos descritos no Gentoo Handbook disponível na página e no CD do
Gentoo.
O Kernel necessita de ser configurado, e compilado durante o processo de instalação. O Gentoo
não dispõe de um Kernel pré-compilado. Em vez disso oferece vários códigos fonte do Kernel, muitos
deles com correcções e optimizações consoante os requisitos dos utilizadores. A configuração do Kernel
pode ser efectuada usando utilitários como o menuconfig ou o genkernel.
Depois do Kernel ser instalado, os ficheiros de configuração do sistema necessitam de ser
editados manualmente de modo a satisfazer as necessidades do utilizador. Isto inclui a tabela do
sistema de ficheiros, a configuração da rede e as personalizações do sistema. Muito importante é a
configuração do ficheiro especifico do Gentoo, o ficheiro make.conf em /etc/. Este contém propriedades
que controlam o processo de compilação dos pacotes de aplicações e é geralmente actualizado pelo
administrador do sistema quando os valores predefinidos necessitam de ser alterados. As propriedades
deste ficheiro são passadas para o compilador no processo de construção das ferramentas e aplicações
do sistema, garantido assim, ficheiros binários optimizados para a plataforma.
O Gentoo é criticado pelo seu longo processo de instalação, demorando vários dias a ser
instalado em sistemas mais lentos. O que levou a um debate sobre as virtudes das distribuições por
pacotes binários versus distribuições por pacotes de código fonte. Alguns defendem que os pacotes
binários são mais lentos e menos personalizáveis, enquanto outros respondem que muitos pacotes
demoram dias a compilar e são incompatíveis com as necessidades dos utilizadores que requerem uma
instalação rápida.
O estudo efectuado à distribuição Gentoo mostra que os requisitos propostos adequam-se
perfeitamente à plataforma da RAC. O sistema operativo a incorporar na plataforma necessita de ser
altamente adaptado e o Gentoo permite esse nível de adaptação.
Para construir o sistema da plataforma da RAC é utilizado um sistema operativo de
desenvolvimento e teste. Este serve para construir o sistema operativo da plataforma, mas também todo
o software de controlo de movimento e comunicação. Em seguida é abordado em detalhe cada um
destes sistemas.
10.1.3. Sistema Operativo de Desenvolvimento e Teste
A plataforma da RAC esta equipada com um dispositivo de armazenamento de dados Compact
Flash com 256 mega bytes. Este dispositivo é utilizado para armazenar o sistema operativo e todos os
programas de controlo de movimento e comunicação, este sistema é uma versão reduzida e
compactada do Gentoo Linux. Para que fosse possível desenvolver e testar facilmente os programas de
controlo foi necessário utilizar um sistema de apoio em tudo idêntico, mas com todas as ferramentas e
bibliotecas de programação. Estas ferramentas, nomeadamente o compilador, as bibliotecas de funções,
o código fonte dos programas de controlo e do sistema operativo da plataforma, ocupam bastante
espaço, pelo qual, houve a necessidade de utilizar um disco rígido acoplado à uma das plataformas. O
sistema de desenvolvimento permite ainda construir automaticamente uma nova imagem do sistema da
plataforma, copiando-a directamente para a memória flash de cada um dos robôs usando a rede sem
fios.
Página 64 de 119
Figura 10.1.3.1 – Sistema de desenvolvimento e teste.
O C foi a linguagem utilizada para programar as aplicações de controlo de movimento e
comunicação com o apoio das ferramentas do projecto GNU, destacando-se principalmente a GNU
Compiler Collection (GCC) cujo o compilador é standard para todos os sistemas operativos Linux. O
interface exterior do GCC interpreta os argumentos da linha de comandos e gera ficheiros binários em
código máquina tendo em conta a arquitectura e as optimizações especificas do microprocessador da
plataforma.
As operações repetitivas de manipulação de ficheiros, execução de programas, e configuração
de dispositivos foram realizados usando shell scripts. Um shell script é um guião escrito para um
interpretador de linha de comandos (shell). Permite que vários comandos, que tradicionalmente seriam
introduzidos um a um, sejam executados automaticamente e rapidamente.
10.1.4. Sistema Operativo da Plataforma
Como já foi referido, o sistema operativo da plataforma é baseado na distribuição Linux Gentoo.
Esta foi modificada tendo em conta o espaço disponível na memória flash. Todos os componentes
desnecessários foram removidos e o processo de carregamento foi alterado para poder ser executado a
partir do dispositivo directamente para a memória principal da plataforma. O processo de compilação do
sistema foi optimizado tendo em conta a arquitectura e funcionalidades do microprocessador VIA Eden
[VIA].
O código fonte do sistema da plataforma é mantido intacto entre as várias interacções do
desenvolvimento. Isto permite uma actualização e configuração fácil, permitindo adicionar programas
como num sistema operativo tradicional. Para além disso, o tempo de construção de uma nova imagem
é bastante inferior porque mantemos o mesmo código fonte entre as interacções.
Podemos dividir o processo de desenvolvimento nas seguintes etapas:
Ø
Ø
Ø
Ø
Ø
Preparação do ambiente de construção
Instalação do sistema base Gentoo.
Criação da imagem Initrd.
Desenvolvimento e manutenção das aplicações de controlo
Construção do sistema.
O ambiente de construção é apenas uma directoria na qual é usado um ambiente de chroot,
tornando-a na raiz do sistema a construir, mas usando ligações simbólicas para as bibliotecas e
ferramentas no sistema de desenvolvimento. Nesta directoria é criado um esqueleto com as directorias
Página 65 de 119
base da distribuição Gentoo usando a primeira ou a segunda etapa de instalação da distribuição.
Seguidamente é necessário instalar o sistema Portage que será responsável pela obtenção e
manutenção dos pacotes instalados.
A instalação do sistema base consiste em fazer o download dos pacotes básicos do sistema
operativo, assim como todos os pacotes indispensáveis, como por exemplo, as ferramentas de
configuração das redes sem fios. O ficheiro /etc/make.conf é muito importante, pois contém os
parâmetros de optimização passados ao compilador no processo de compilação dos pacotes.
Nesta etapa, uma das principais tarefas é a compilação do kernel da plataforma. Ao código fonte
do kernel adicionamos as opções especificas e aplicamos os patches que corrigem o funcionamento do
dispositivo wireless. O kernel da plataforma tem de suportar os seguintes itens:
Ø
Ø
Ø
Ø
Ø
Ø
Squashfs – Suporte para sistema de ficheiros comprimido
Initrd com 8 MB – Suporte para imagem de arranque de sistema.
Loopback – Suporte para sistema de ficheiros em memória.
IDE/ATAPI – suporte para dispositivos IDE.
Ext2 – suporte para o sistema de ficheiros ext2.
Wireless – suporte para as extensões IEEE 802.11b.
A imagem initrd proporciona ao bootloader a capacidade de carregar um sistema de ficheiros na
memória principal da plataforma (ramdisk). Este sistema de ficheiros pode ser montado como a raiz do
sistema e os programas podem ser executados a partir dele. O sistema initrd foi desenhado para que o
arranque do sistema ocorra em duas fases, na primeira, o kernel com muito poucos drivers de
dispositivos, assume o comando do computador e carrega os drivers e ficheiros de configuração
presentes em initrd, para que na segunda fase, já com acesso aos principais dispositivos, arranque o
sistema principal.
A imagem initrd é um ficheiro que ocupa 8 mega bytes e contem para além do script de
arranque do sistema (linuxrc), as ferramentas de sistema usadas pelo script e respectivas bibliotecas de
funções.
Programa
/bin/sh
/bin/cat
/bin/mount
/bin/umount
/bin/mkdir
/bin/chroot
/bin/tar
/sbin/pivot_root
Função
Dependências
Interpretador de linha de
comandos (shell)
Faz a concatenação de
ficheiros de configuração
Monta um sistema de
ficheiros
Desmonta um sistema de
ficheiros
Cria directorias num sistema
de ficheiros
Modifica o sistema para um
sist. de raiz em jaula
Comprime e descomprime
ficheiros e/ou directorias
Substitui a raiz do sistema
de ficheiros
/lib/libc.so.6
/lib/ld-linux.so.2
…
Tabela 10.1.4.1 – Ferramentas de sistema presentes em initrd.
Após a criação da imagem initrd, são copiados os ficheiros executáveis dos programas de
controlo da plataforma, assim como os respectivos ficheiros de configuração.
Na última etapa, o sistema da plataforma é compactado numa estrutura squashfs (sistema de
ficheiros compactado) e copiado juntamente com o initrd e o kernel do sistema para a memoria flash.
Este processo é automaticamente realizado por um script que opcionalmente pode actualizar
remotamente o sistema de todos os robôs que se encontrarem ligados.
Página 66 de 119
Grande parte dos sistemas computorizados, não possuem um sistema operativo em memória. O
hardware por si só não consegue realizar as operações complexas de um sistema operativo, como ler
um programa de um dispositivo de armazenamento. Então parece estar criado um paradoxo: para
carregar um sistema operativo na memória é necessário que exista um sistema operativo previamente
instalado.
A solução para este paradoxo, envolve o uso de um pequeno programa, chamado bootloader.
Este programa não tem todas as capacidades de um sistema operativo, mas é construído à medida para
carregar software suficiente para que o sistema operativo consiga arrancar. Frequentemente são
utilizados bootloaders de múltiplas etapas, onde vários programas carregam-se em cadeia, até que o
último, carrega o sistema operativo.
Todos os dispositivos de memória flash da plataforma foram previamente preparados para
servirem como dispositivos de arranque. Para isso, foi instalado na sua partição principal um bootloader
que fica encarregue de ler os ficheiros do sistema operativo.
10.1.5. Processo de Arranque do Sistema
Após o arranque, o microprocessador da plataforma corre a instrução localizada no endereço
FFFF0h da BIOS (Basic Input/Output System). Esta localização é próxima do fim da memória do
sistema. Contém uma instrução de salto que transfere a execução para um programa, armazenado em
ROM da BIOS. Este programa corre um teste (Power-On Self Test) para verificar que dispositivos estão
a funcionar, e faz a sua inicialização. Em seguida a BIOS percorre uma lista de dispositivos previamente
definida até encontrar um que esteja preparado para arrancar o sistema operativo. Se a BIOS encontrar
um dispositivo de arranque, lê e executa o sector de arranque no sistema de ficheiros do dispositivo. No
caso da memória flash, este sector é a lista principal de arranque (MBR – Master Boot Record) que não
é específica de nenhum sistema operativo. O código da MBR verifica a tabela de partições pela
existência de uma partição activa. Se for encontrada, o código da MBR carrega o sector de arranque
dessa partição e executa-o. Este sector de arranque é onde esta instalado o bootloader, especifico do
sistema operativo, cuja principal função é carregar e executar o kernel.
Podemos sintetizar o processo que se segue nos seguintes passos:
1. O bootloader carrega em memória o kernel e a imagem inicial (initrd).
2. O kernel converte a imagem initrd num sistema de ficheiros em memória e liberta o espaço
ocupado pela imagem.
3. A imagem initrd é montada como apenas de leitura (read only) e como raiz do sistema de
ficheiros (root).
4. O script linuxrc é executado e realiza os restantes passos.
5. Guarda os parâmetros que foram passados ao kernel, para os passar posteriormente a /sbin/init.
6. Localiza o dispositivo de memória flash no bus IDE.
7. Monta o dispositivo em /flash.
8. Monta o sistema de ficheiros compactado (squashfs) em /new (contém toda a instalação do
Gentoo compactada num único ficheiro), este vai ser a raiz do sistema, em modo apenas de
leitura (read only).
9. Monta as directorias de leitura/escrita em memória usando o sistema de ficheiros tempfs (/var,
/etc, /tmp e /root) e preenche o seu conteúdo a partir da imagem compactada.
10. A raiz do sistema é alterada para a nova raiz usando a ferramenta pivot_root.
11. A sequencia de arranque habitual (i.e. a execução de /sbin/init) é executada na raiz do sistema
de ficheiros.
12. Os drivers de dispositivos são carregados e configurados
13. O sistema de ficheiros initrd é removido.
14. São executados os programas de controlo de movimento e comunicações.
Ao fim de alguns segundos após o arranque, a plataforma fica pronta a receber comandos de
movimento e a enviar dados de sensores e dispositivos.
10.2. Sistema de Comunicações
O sistema de comunicações da plataforma da RAC utiliza uma rede de dados baseada no
modelo de referencia de sete camadas do protocolo OSI (Open Systems Interconnection) [ISO].
Página 67 de 119
O modelo OSI divide as funções do protocolo de comunicações numa série de camadas. Cada
camada possui a característica de apenas usar as funções da camada a baixo e apenas disponibiliza as
suas funcionalidades e serviços à camada a cima. Um sistema de comunicações que implementa um
protocolo que consiste numa série destas camadas é designado por pilha protocolar (como por exemplo,
a pilha TCP/IP). As pilhas protocolares podem ser implementadas tanto em software como em
hardware, ou como uma mistura dos dois. Tipicamente, apenas as camadas inferiores são
implementadas em hardware e as camadas superiores em software.
O modelo OSI teve grande adesão por parte da indústria de telecomunicações e informática. A
sua característica principal está no interface entre as várias camadas que impõem especificações
exactas sobre a maneira como uma camada interage com a outra. Isto significa que uma camada
implementada por um fabricante pode interagir com a camada de outro (assumindo que a especificação
foi cumprida). Estas especificações são geralmente conhecidas com RFC’s (Request for Comments) na
comunidade TCP/IP. Elas constituem standards ISO na comunidade OSI.
A camada física é a mais básica da rede de comunicações, corresponde ao nível um no modelo
de sete camadas OSI. Esta camada executa serviços pedidos pela camada dois, a camada de ligação.
Este nível corresponde ao hardware de comunicações, cabos, ou a uma conexão electromagnética sem
fios. É também responsável pelas especificações eléctricas, conectores eléctricos, frequências de
transmissão, controlo de colisões e outras funções de baixo nível.
As principais funções e serviços executados pela camada física são:
•
•
•
Estabelecimento e terminação de uma conexão no meio físico de comunicação.
Participação no processo no qual os recursos do meio de comunicação são efectivamente
partilhados entre vários utilizadores, i.e. resolução de contenção e controlo de fluxo.
Conversão entre a representação dos dados digitais no equipamento do utilizador e os sinais
correspondentes transmitidos no canal de comunicações.
A camada de ligação corresponde ao nível dois no modelo de sete camadas OSI. Disponibiliza
serviços à camada de rede e pede serviços à camada física. Assegura que a informação é transmitida
correctamente entre nós adjacentes de uma rede alargada. Fornece os meios que possibilitam a
detecção e correcção de erros de transmissão que possam ocorrer na camada física. Esta camada é
composta por dois componentes. O primeiro componente é o controlo de ligação lógico. Este
componente determina onde acaba um segmento de dados e onde começa o segmento seguinte. O
segundo componente é o controlo de acesso ao meio (MAC – Media Access Control). Este componente
determina quem é que esta autorizado a utilizar o meio de comunicação baseado no endereço físico do
dispositivo. Exemplos de protocolos de ligação são: wi-fi para redes sem fios, ethernet para redes locais
e PPP, HDLC para ligações ponto a ponto.
A camada de rede corresponde à camada três do protocolo OSI. É responsável por converter
endereços lógicos e nomes em endereços físicos. Também determina o caminho desde a fonte ao
destinatário e faz a gestão de tráfego na rede, como a comutação, o encaminhamento e a congestão de
pacotes de dados. Fornece os meios para a transmissão de sequencias de dados de comprimento
variável mantendo a qualidade de serviço disponibilizada pela camada de transporte. No entanto, a
camada de rede, realiza as suas funções sem detecção e correcção de erros e controlo de fluxo.
Exemplos de protocolos de rede são: IP, ICMP, IPX, netBEUI e DECnet.
A camada de transporte corresponde ao nível quatro do modelo de sete camadas OSI. No
modelo de camadas da RAC, a camada de transporte disponibiliza serviços à camada de aplicação e
requer serviços a camada de rede. A camada de transporte fornece uma transferência de dados
transparente entre sistemas. É responsável pela recuperação de situações de erro e controlo de fluxo.
Assegura que a transferência de dados é completa. A sua missão é proporcionar às camadas superiores
uma transferência de dados eficaz e confiável. Permitindo que a implementação das camadas
superiores seja feita sem qualquer preocupação sobre a integridade dos dados enviados no canal de
comunicação. Existe uma longa lista de serviços disponibilizados por esta camada, no entanto, nem
todos são usados pelas aplicações. Alguns destes serviços podem levar ao desperdício de recursos ou
mesmo tornarem-se
contra-producentes em alguns casos. Alguns exemplos de protocolos de
transporte são: TCP, UDP, RTP e SPX.
A camada de aplicação corresponde ao nível sete do modelo OSI. No modelo de camadas da
RAC, a camada cinco e seis do modelo OSI não foram implementadas pois não são necessárias. Assim,
a camada de aplicação requer serviços à camada de transporte, e por sua vez, a camada de aplicação
Página 68 de 119
faz o interface directo com as aplicações de utilizador. No caso da RAC, estas aplicações são os
programas de controlo de movimento e aquisição de dados.
Na tabela seguinte é ilustrada a pilha protocolar usada na plataforma da RAC, esta pilha
implementa um subconjunto de cinco camadas das sete camadas originais do modelo de referência
OSI.
Pilha Protocolar da plataforma RAC
Camada
Aplicação
Protocolo
RACprotocol, SSH/SFTP
Implementação
Software
Transporte
TCP
Software
Rede
IPv4
Software
Wi-fi (IEEE 802.11b)
Hardware/Software
Radiofrequência (2,4 GHz)
Hardware
Ligação
Física
Tabela 10.2.1 – Pilha protocolar da plataforma RAC.
Nos três sub capítulos seguintes são analisados os protocolos que foram utilizados nas cinco
camadas protocolares da plataforma da RAC.
10.2.1. Protocolo IEEE 802.11b
O protocolo IEEE 802.11b juntamente com o dispositivo de comunicação wireless USB EDIMAX
LAN Adapter implementam as duas primeiras camadas (camada física e de ligação) da pilha protocolar
do sistema de comunicação da plataforma da RAC.
O protocolo IEEE 802.11 refere-se a um conjunto de standards para redes locais sem fios
desenvolvido pelo grupo onze do comité de standards LAN/MAN do IEEE (IEEE 802). O termo é
também usado para referir o protocolo original 802.11, que actualmente se encontra ultrapassado.
A família 802.11 inclui seis técnicas de modulação de radiofrequências que usam o mesmo
protocolo, as técnicas mais populares são as definidas pelas adendas a, b e g do protocolo original. A
segurança das comunicações foi originalmente incluída, e mais tarde reforçada através da adenda i.
Outros standards da família (c-f,h-j,n) são extensões para a melhoria do serviço, ou correcções a
especificações prévias. O 802.11b foi o primeiro protocolo de rede sem fios mundialmente aceite,
seguido ( de maneira pouco intuitiva) pelos 802.11a e 802.11g.
Figura 10.2.1.1 – Router wireless 802.11b.
Página 69 de 119
Os standards 802.11b e 802.11g usam a banda pública (não licenciada) dos 2,4 GHz. Nesta
banda podem ocorrer interferências provocadas por telefones sem fios e fornos micro-ondas, pois
utilizam as mesmas frequências. O standard 802.11a usa a banda não regulamentada dos 5 GHz.
A versão original do standard IEEE 802.11 lançado em 1997 especifica duas velocidades para a
transmissão de dados de 1 e 2 mega bits por segundo (Mbits/s) de modo a serem transmitidas através
de sinais infra-vermelhos (IR) ou através da banda Industrial Médico-Científica de 2,4 GHz. O IR
mantém-se como parte integrante do standard mas actualmente não existem implementações
comerciais.
O standard original também define como método de acesso ao meio o CSMA/CA (Carrier Sense
Multiple Access with Collision Avoidance). Uma percentagem significativa do canal de comunicação
disponível é sacrificado para permitir aumentar a fiabilidade da transmissão de dados em condições
ambientais adversas.
Surgiram pelo menos cinco implementações comerciais inter-operáveis usando a especificação
original. Uma das fraquezas da especificação foi a disponibilização de muitas opções, levando com isso
a uma inter-operabilidade difícil de conseguir. Era mais uma “meta-especificação” do que uma
especificação rígida, permitindo a cada fabricante a flexibilidade de diferenciar os seus produtos. O
802.11 original foi rapidamente suplantado pela popularidade do 802.11b
A adenda 802.11b ao protocolo original foi rectificada em 1999. O 802.11b tem uma velocidade
de transmissão dados máxima de 11 Mbit/s e utiliza o mesmo método de acesso ao meio (CSMA/CA)
definido no protocolo original. Devido à percentagem bastante significativa da largura de banda do canal
que o CSMA/CA utiliza, na prática o fluxo de dados máximo que uma aplicação pode atingir é
aproximadamente 5,9 Mbit/s sobre TCP e 7,1 Mbits/s sobre UDP.
Os dispositivos baseados no protocolo 802.11b apareceram no mercado muito rapidamente, já
que utilizam uma extensão directa da modulação DSSS (Direct-sequence spread spectrum) definida no
standard original. Assim, os produtos existentes foram rapidamente actualizados para suportarem as
evoluções introduzidas pelo 802.11b. O aumento significativo do 802.11b (quando comparado com o
standard original) e as reduções do preço dos dispositivos levaram a adopção definitiva do 802.11b
como a tecnologia LAN sem fios.
O standard 802.11b é usado mais frequentemente numa configuração ponto-multiponto, onde
um ponto de acesso (AP) comunica através de uma antena omnidireccional com um ou mais clientes
localizados dentro da área de cobertura do AP. Com antenas exteriores de alto ganho é possível utilizar
uma configuração fixa ponto a ponto para distancias típicas de oito quilómetros, embora já tenham sido
conseguidas distancias de 80-120 quilómetros.
Os dispositivos 802.11b podem funcionar a velocidades de 11 Mbits/s, mas se a qualidade do
sinal constituir um problema, podem reduzir a velocidade para 5,5, 2 e 1 Mbit/s. Como as velocidades
mais baixas utilizam métodos de codificação menos complexos e mais redundantes, são menos
susceptíveis a corrupção de dados devido a interferências e à atenuação do sinal. Foram realizadas
extensões ao protocolo 802.11b (como por exemplo a união de canais e técnicas de transmissão burst)
para se conseguir aumentar a velocidade de transmissão para 22, 33 e 44 Mbit/s, mas estas extensões
são propriedade de algumas empresas e, por isso, não são protocolos abertos, patrocinados pelo IEEE.
Estas extensões ultimamente têm sido postas de parte devido ao desenvolvimento do 802.11g, que
consegue 54 Mbit/s e é compatível com o 802.11b.
O 802.11b divide o espectro em 14 canais sobrepostos onde as frequências centrais estão
separadas 5 MHz umas das outras. É comum ouvir que os canais 1,6 e 11 (e 14 se a entidade
reguladora de comunicações local permitir o uso dessa frequência) não se sobrepõem e que esses
canais (ou outros conjuntos com o mesmo espaçamento) podem ser usados de modo a que várias
redes possam operar muito próximas sem causar interferências entre elas, no entanto esta afirmação é
um bocado simplificada. O standard 802.11b não especifica a largura do canal, em vez disso, é
especificado a frequência central do canal e a máscara espectral para o canal respectivo. A máscara
espectral para o 802.11b define que o sinal tenha uma atenuação de 30 dB da sua energia máxima a
+/- 11 MHz da frequência central e pelo menos 50 dB a +/- 22 MHz da frequência central.
Página 70 de 119
Figura 10.2.1.2 – Sobreposição de canais no protocolo 802.11b.
Uma vez que a máscara espectral apenas define a potencia do sinal até 22 MHz da frequência
central, algumas pessoas podem assumir que a energia do canal não se estende para além desse
limite, mas na realidade, é isso não acontece. De facto, se o transmissor for suficientemente potente, o
sinal pode ser bastante forte, mesmo depois do ponto dos +/- 22 MHz. É portanto, incorrecto dizer que
os canis 1, 6 e 11 não se sobrepõem. É mais correcto dizer que, dada a separação dos canais 1, 6 e 11,
o sinal em qualquer canal, deve estar suficientemente atenuado para não interferir significativamente
com o transmissor em qualquer outro canal. Por exemplo, um transmissor potente no canal 1 pode
facilmente sobrepor-se a um transmissor fraco no canal 6. Em testes de laboratório, a velocidade de
transferência de um ficheiro usando o canal 11 diminuiu sensivelmente quando uma transferência similar
começou no canal 1, indicando mesmo que os canais 1 e 11 podem interferir ligeiramente um com o
outro. Se os transmissores estiverem próximos e utilizarem canais mais juntos do que o 1, 6 e 11 (como
por exemplo o 1, 4, 7 e 10), a sobreposição de canais pode provocar uma degradação inaceitável da
qualidade do sinal e da velocidade de transferência de dados.
Os canais que estão disponíveis para utilização num determinado país diferem de acordo com a
legislação em vigor. Em Portugal estão disponíveis para utilização os canais 1 a 13. Nos Estados
Unidos, a autoridade reguladora (FCC) apenas permite a utilização dos canais 1 a 11. A lista actualizada
em 2001 das frequências para o protocolo 802.11 é apresentada na tabela seguinte. O canal 14, quando
disponível, é para uso exclusivo para o protocolo 802.11b.
Canal
Frequência
MHz
EUA
X10
Canada
X20
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2412
2417
2422
2427
2432
2437
2442
2447
2452
2457
2462
2467
2472
2484
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Europa
ETSI
X30
x
x
x
x
x
x
x
x
x
x
x
x
x
Espanha
X31
x
x
França
X32
x
x
x
x
x
x
x
x
x
x
x
x
x
Japão
X40
x
x
Japão
X41
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Tabela 10.2.1.1 – Canais 802.11 e a sua disponibilidade em vários países.
Página 71 de 119
Como o IEEE apenas define especificações mas não testa equipamentos para verificar a sua
conformidade, um grupo de trabalho chamado Wi-Fi Alliance [WIFI] executa um programa de
certificação onde participam virtualmente todas as empresas que comercializam equipamentos 802.11.
O logótipo do Wi-Fi, detido pelo grupo, e que apenas pode ser usado em equipamento certificado,
pretende garantir a interoperabilidade do equipamento de fabricantes diferentes.
Em 2001 um grupo da universidade da Califórnia em Berkeley apresentou um artigo cientifico
onde descrevia as vulnerabilidades do protocolo WEP (Wired Equivalent Privacy) do standard 802.11,
seguidos rapidamente por Fluhrer, Mantin, e Shamir's no paper cientifico "Weaknesses in the Key
Scheduling Algorithm of RC4". Pouco depois Adam Stubblefield e a empresa AT&T anunciaram
publicamente a verificação do ataque. No ataque, eles conseguiram interceptar transmissões e obter o
acesso não autorizado a redes sem fios 802.11.
O IEEE estabeleceu um grupo de trabalho dedicado para criar um protocolo de segurança
substituto, o 802.11i. A Wi-Fi Alliance anunciou entretanto uma especificação chamada WPA (Wi-Fi
Protected Access) baseada num subconjunto da especificação 802.11i que ainda se encontrava em
desenvolvimento. Os produtos certificados começaram a aparecer no mercado em meados de 2003. O
802.11i (também conhecido como WPA2) foi rectificado em Junho de 2004 e utiliza o standard de
encriptação AES (Advanced Encryption Standard) substituindo o RC4, que é usado no WEP e no WPA.
10.2.2. Protocolo TCP/IP
O protocolo TCP/IP faz parte da pilha protocolar do sistema de comunicações da plataforma da
RAC. O IP (Internet Protocol) é utilizado na camada de rede (camada três do modelo de referência OSI)
e o TCP (Transmission Control Protocol) é utilizado na camada de transporte (camada quatro do modelo
de referência OSI).
O IP é um protocolo orientado para a comunicação de dados entre uma fonte e um destino
utilizando uma rede de comutação de pacotes. Os dados numa rede IP são enviados em blocos,
também chamados pacotes ou datagramas (Os termos são basicamente sinónimos na terminologia IP).
No IP, não existe a necessidade de haver uma negociação prévia para que um sistema tente enviar
pacotes de dados para outro sistema.
O IP disponibiliza um serviço de distribuição de pacotes de melhor esforço, ou seja, não dá
garantias sobre as condições de entrega de um pacote. O pacote pode chegar ao seu destino
danificado, pode chegar fora de ordem em relação aos outros pacotes, pode chegar duplicado, ou pode
perder-se completamente. Se uma aplicação necessitar de fiabilidade na comunicação, existem outros
meios para a conseguir, tipicamente através dos protocolos das camadas superiores que são
transportados sobre IP.
Os comutadores de pacotes, e os encaminhadores, enviam os pacotes de dados sobre redes
interligadas pelos protocolos da camada dois. A ausência de garantias na entrega de pacotes significa
que a implementação dos dispositivos de comutação e encaminhamento (switches e routers) é muito
mais simples.
Os aspectos mais complexos do protocolo IP são o endereçamento e o encaminhamento. O
Endereçamento diz respeito a maneira como são atribuídos os endereços IP a cada sistema e como são
divididas e agrupadas sub-redes de sistemas IP. O encaminhamento IP é realizado por todos os
sistemas, mas principalmente pelos encaminhadores (routers) que interligam redes. Tipicamente
utilizam protocolos de encaminhamento complexos (como por exemplo, os IGP – Interior Gateway
Protocols e os EGP – External Gateway Protocols) que ajudam a tomar decisões de encaminhamento
através de redes IP interligadas.
O IP é o elemento comum encontrado na Internet publica actual. A versão do protocolo mais
popular e difundida é a versão 4, ou IPv4. No entanto a Internet esta lentamente a ficar sem endereços,
pois os campos de endereços de fonte e destino é de apenas 32 bits (4.294.967.296 endereços
diferentes, se bem que muitos deles estão reservados para aplicações especiais). O IPv6 é o sucessor
proposto ao IPv4 e para além de outras funcionalidades, possui um espaço para endereçamento de 128
bits o que vai resolver o problema da falta de endereços para um futuro próximo.
Página 72 de 119
+
Bits 0 - 3
0
Versão
32
64
96
128
160
4-7
Comprimento
do cabeçalho
8 - 15
Tipo de serviço
(DiffServ e ECN)
Identificação
Tempo de vida (TTL)
19 - 31
Comprimento total
Offset de
fragmento
Checksum do cabeçalho
Flags
Protocolo
Endereço da fonte
Endereço do destino
Opções
192
16 - 18
Dados
Tabela 10.2.2.1 – Cabeçalho de um pacote IPv4.
O TCP (Transmission Control Protocol) é um dos protocolos fundamentais do conjunto de
protocolos da Internet. Usando TCP os programas, que correm em computadores ligados em rede,
podem criar ligações e enviar dados. O protocolo garante que os pacotes de dados enviados são
recebidos pela mesma ordem pela qual foram enviados e sem falhas. Consegue diferenciar os dados
das diferentes aplicações que correm no mesmo sistema usando o conceito de portos de 16 bits.
As aplicações enviam streams de bytes ao TCP para distribuição, o TCP divide essa stream em
pacotes com um tamanho máximo definido pela camada de ligação (corresponde ao MTU – maximum
trasnmission unit da rede). Depois, o TCP passa esses pacotes ao IP que os envia e entrega a um
destinatário usando a rede de comunicações. O protocolo certifica-se que nenhum pacote de dados é
perdido dando a cada pacote um número de sequência, esse número também é usado para verificar o
ordenamento correcto dos pacotes. Os módulos TCP enviam entre si confirmações para os dados que
foram entregues correctamente. Um temporizador no módulo TCP de envio causa um timeout se não for
recebida uma confirmação dentro de um tempo razoável (RTT – Round Trip Time) e reenvia o pacote
que foi presumivelmente perdido. O TCP verifica que não existem pacotes danificados utilizando um
mecanismo de verificação (checksum), o checksum de um pacote é calculado antes de ser enviado, e é
verificado no acto da recepção.
As conexões TCP são realizadas em três fases: estabelecimento da conexão, transferência de
dados e terminação de conexão. É utilizada uma negociação de três etapas para estabelecer uma
ligação e para terminar a ligação é utilizada uma negociação de quatro etapas.
Embora seja possível que um par de sistemas inicie simultaneamente entre si uma conexão,
habitualmente, um dos sistemas espera passivamente por uma conexão de outro sistema. Este é
normalmente designado como o paradigma cliente/servidor. O cliente inicia uma ligação enviando um
pacote SYN inicial, o servidor responde a um SYN válido com um SYN/ACK. Finalmente o cliente deve
responder com um ACK completando o processo de negociação de três etapas o que conclui o
processo de estabelecimento de ligação.
O processo para terminar a ligação utiliza uma negociação de quatro etapas, onde cada lado da
ligação termina independentemente. Quando um dos lados deseja terminar a ligação transmite um
pacote FIN que é confirmado pelo outro lado com um ACK. Assim o processo típico vai ter um par de
pacotes FIN e um par de pacotes ACK trocados entre as duas partes. A ligação pode estar “meioaberta” no caso em que um dos lados terminou a ligação, mas o outro lado ainda não. O lado que
terminou já não pode enviar dados, mas o outro lado ainda o pode fazer.
+
0
32
64
96
128
160
192
Bits 0 - 3
4-9
10 - 15
16 - 31
Porto fonte
Porto de destino
Número de sequência
Número de confirmação
Offset de dados Reservado Flags
Janela
Checksum
Ponteiro Urgente
Opções (Opcional)
Opções (continuação)
Enchimento (até 32)
224
Dados
Tabela 10.2.2.2 – Cabeçalho de um pacote TCP.
Página 73 de 119
10.2.3. Protocolo de Comunicação RACprotocol
Esta secção descreve o protocolo ao nível da camada de aplicação (camada sete do modelo de
referencia OSI). Especifica as mensagens da arquitectura de controlo da RAC entre o software de
controlo de movimento do robô e o controlador centralizado. O nível inferior da arquitectura de controlo
está representado na figura seguinte. A interacção é do tipo cliente/servidor: a camada de controlo
superior é o servidor e a camada inferior é o cliente.
A arquitectura utiliza o protocolo TCP/IP, o servidor aceita ligações dos robôs clientes no porto
10000. Após o estabelecimento de uma ligação, tanto o servidor como o cliente podem enviar
mensagens. O controlo da fiabilidade da comunicação entre cliente e servidor fica a cargo do protocolo
TCP/IP, o cliente pode iniciar e terminar uma ligação. O servidor apenas pode terminar uma ligação.
Servidor
TCP/IP
BRAIN
Controlador Central
TRJCTR
Controlo de Trajectórias
ACTUADORES
SENSORES
Cliente
TCP/IP
Figura 10.2.3.1 – Nível inferior da arquitectura de controlo da RAC.
10.2.3.1.
Grandezas e Codificação
As unidades das grandezas descritas nesta secção podem ser divididas em cinco grupos:
•
•
•
•
•
•
Informação lógica, como identificadores de mensagens, flags e identificadores de estado;
Posição, medida em metros (m);
-1
Velocidade linear, medida em metros por segundo (m.s );
Ângulo, medidos em radianos, sendo positivo no sentido contrário ao dos ponteiros do
relógio.
-1
Velocidade angular, medida em radianos por segundo (rad.s );
Tempo, medido em segundos (s).
Todos os dados são codificados em código binário: As unidades do primeiro grupo são
codificadas como variáveis de 1 byte (equivalentes ao tipo unsigned char da linguagem C); velocidades,
posições e ângulos são codificadas como variáveis de virgula flutuante de 4 bytes (equivalentes ao tipo
float da linguagem C com uma gama de precisão 3.4 E +/-38 e 7 dígitos).
10.2.3.2.
Especificação das Mensagens
As mensagens têm tamanho variável e seguem a estrutura definida pela tabela:
Tamanho da
mensagem
Identificador
MsgSize
IDMsg
2 bytes
2 bytes
Campos
Field 1
Field 2
…
Field n
FIELDS bytes
Tabela 10.2.3.2.1 – Estrutura da mensagem.
Página 74 de 119
Descrição dos campos:
•
•
•
MsgSize: Indica o tamanho da mensagem em bytes;
IDMsg: Identifica o tipo de mensagem;
Field x: Campos da mensagem. O número de campos e o seu tamanho variam consoante o
tipo de mensagem.
Os tipos de mensagens podem ser classificados em três grupos:
1. Gestão de sessão: As mensagens deste tipo são utilizadas pelo cliente e pelo servidor para
iniciar e terminar uma ligação;
2. Comandos do servidor: Estas mensagens são utilizadas pelo servidor para controlar os
actuadores da plataforma e os parâmetros relacionados, também permitem obter o estado
interno da plataforma;
3. Comandos do cliente: Estas mensagens são utilizadas pelo cliente para obter a sua
posição actual, calculada a partir dos dados da câmara, utilizada no controlador de
trajectórias do robô para corrigir o movimento.
10.2.3.2.1.
Mensagens de Gestão de Sessão
Existem duas mensagens definidas nesta secção.
10.2.3.2.1.1
Mensagem OpenSess (0x02)
Abertura de Sessão
Esta mensagem é transmitida pelo cliente logo após o estabelecimento de uma ligação. O
servidor utiliza a informação adicional do campo da mensagem para identificar o robô que iniciou a
ligação.
Identificador
Campos
OpenSess
RobotID
0x02
1 byte
1 byte
Tabela 10.2.3.2.1.1.1 – Mensagem OpenSess.
•
RobotID: Número único de identificação do robô
10.2.3.2.1.2
Mensagem SessQuit (0x03)
Fecho de Sessão
Esta mensagem pode ser transmitida tanto pelo cliente como pelo servidor para terminar uma
ligação. É utilizada quando uma das aplicações necessite terminar devido a um comando de utilizador
ou a um erro interno do programa. Em situações normais cabe ao cliente restabelecer a ligação.
Identificador
Campos
SessQuit
ExitFlag
0x03
1 byte
1 byte
Tabela 10.2.3.2.1.2.1 – Mensagem SessQuit.
Página 75 de 119
•
ExitFlag: Condição que leva a uma das partes a terminar a ligação de acordo com a tabela
seguinte.
Flag
Descrição
0
Ordem do utilizador
1
Erro interno da aplicação
2
Falta de recursos do sistema
3
Bateria Fraca
Tabela 10.2.3.2.1.2.2 – Condições de erro da mensagem SessQuit.
10.2.3.2.2.
Mensagens de Comando do Servidor
Existem oito mensagens definidas nesta secção.
10.2.3.2.2.1
Mensagem GiveState (0x01)
Envia Estado
Esta mensagem é enviada pelo servidor para actualizar o estado interno de cada robô. Os
clientes respondem com uma mensagem do tipo State. A mensagem GiveState não tem campos.
Identificador
Campos
GiveState
⊗
0x03
1 byte
0 bytes
Tabela 10.2.3.2.2.1.1 – Mensagem GiveState.
10.2.3.2.2.2
Mensagem SetVelocity (0x05)
Define Velocidade
Esta mensagem define a velocidade instantânea pretendida para o robô. São enviados nos
campos da mensagem os parâmetros do movimento pretendido: o módulo da velocidade, a orientação
no referencial do robô e a velocidade angular.
Identificador
Campos
SetVelocity
v ∈ R0
θ ∈ [0,2π [
ω∈R
0x05
1 byte
1
Campo 1
4 bytes
2..5
Campo 2
4 bytes
6..9
Campo 3
4 bytes
10..13
Tabela 10.2.3.2.2.2.1 – Mensagem SetVelocity.
•
Campo 1 - v - Módulo da velocidade linear do robô.
•
•
Campo 2 - θ - Anglo de orientação no referencial do robô.
Campo 3 -
ω - Velocidade angular do robô.
Página 76 de 119
10.2.3.2.2.3
Mensagem KickBall (0x06)
Chuta a Bola
Esta mensagem ordena ao cliente que active o kicker para chutar a bola. O único parâmetro
desta mensagem é um valor que define a intensidade do remate. Basicamente, define o tempo de carga
do condensador do kicker, quanto mais alto é este valor, maior será a força de remate.
Identificador
Campos
KickBall
Intensity
0x06
1 byte
1 byte
Tabela 10.2.3.2.2.3.1 – Mensagem KickBall.
•
Intensity: Define a força do remate, quanto maior for o valor, maior é a força do remate.
10.2.3.2.2.4
Mensagem SetDribbling (0x07)
Activa o Dribbler
Esta mensagem define a velocidade de rotação ( d) do dribbler do robô. O dribbler é um cilindro
rotativo que tem a capacidade de atrair a bola, permitindo um maior domínio do jogo. Na versão actual
da plataforma da RAC, o dribbler ainda não está implementado.
Identificador
Campos
SetDribbling
ωd ∈ R
0x07
1 byte
1
4 bytes
2..5
Tabela 10.2.3.2.2.4.1 – Mensagem Setdribbling.
•
ωd - Velocidade angular do dribbler do robô.
10.2.3.2.2.5
Mensagem Halt (0x08)
Parar
Esta mensagem ordena ao robô que pare os motores de tracção e o dribbler. Não tem campos.
Identificador
Campos
Halt
⊗
0x08
1 byte
0 bytes
Tabela 10.2.3.2.2.5.1 – Mensagem Halt.
Página 77 de 119
10.2.3.2.2.6
Mensagem SetTrajectory (0x09)
Define Trajectória
Esta mensagem envia ao robô um conjunto de pontos no espaço, que definem uma trajectória, e
as respectivas características do movimento entre cada ponto (set-points). O primeiro set-point contem a
posição, velocidade e orientação actuais do robô no referencial do campo. Este comando esta limitado a
32 set-points.
Identificador
SetTrajectory
0x09
1 byte
1
Campos
x1 ∈ R0
y1 ∈ R0
v1 ∈ R0
θ1 ∈ [0,2π [
x2 ∈ R0
y2 ∈ R0
Campo
1
Campo
2
Campo 3
Campo 4
Campo 5
Campo 6
…
4 bytes
2..5
4 bytes
6..9
4 bytes
10..13
4 bytes
14..17
4 bytes
18..21
4 bytes
22..25
…
…
Tabela 10.2.3.2.2.6.1 – Mensagem SetTrajectory.
•
•
•
Campo 1 -
•
Campo 4 - θ - Orientação no referencial do robô.
x - Abcissa do ponto no referencial do campo.
Campo 2 - y - Ordenada do ponto no referencial do campo.
Campo 3 - v1 - Módulo da velocidade linear do robô.
10.2.3.2.2.7
Mensagem SetParms (0x0A)
Define Parâmetros de Calibração
Esta mensagem ajusta os três parâmetros de calibração no modelo cinemático (anglos
desfasamento das rodas). Este comando é apenas usado na calibração de movimento do robô através
de um procedimento inicial quando necessário.
Identificador
Campos
SetParms
α1 ∈ [0,2π [
α 2 ∈ [0,2π [
α 3 ∈ [0,2π [
0x0A
1 byte
1
Campo 1
4 bytes
2..5
Campo 2
4 bytes
6..9
Campo 3
4 bytes
10..13
Tabela 10.2.3.2.2.7.1 – Mensagem SetParms.
•
•
•
Campo 1 - α1 - Ângulo de correcção de desfasamento da roda 1.
Campo 2 - α 2 - Ângulo de correcção de desfasamento da roda 2.
Campo 3 - α 3 - Ângulo de correcção de desfasamento da roda 3.
10.2.3.2.2.8
Mensagem Position (0x0B)
Posição do Robô
Esta mensagem é enviada pelo servidor em resposta a um pedido de posição (GivePosition) de
um robô.
Página 78 de 119
Identificador
Campos
Position
x ∈ R0
y ∈ R0
θ ∈ [0,2π [
0x0B
1 byte
1
Campo 1
4 bytes
2..5
Campo 2
4 bytes
6..9
Campo 3
4 bytes
10..13
Tabela 10.2.3.2.2.8.1 – Mensagem Position.
•
•
•
x - Abcissa da posição do robô no referencial do campo.
Campo 2 - y - Ordenada da posição do robô no referencial do campo.
Campo 1 -
Campo 3 - θ - Ângulo de orientação no referencial do robô.
10.2.3.2.3.
Mensagens de Comando do Cliente
Existem duas mensagens definidas nesta secção.
10.2.3.2.3.1
Mensagem State (0x00)
Devolve Estado
Esta mensagem devolve o estado interno de vários componentes do robô em resposta a uma
mensagem GiveState enviada pelo servidor.
Campos
Identificador
State
Modified
General
Power
Bumpers
v ∈ R0
ω∈R
ωd ∈ R
0x00
1 byte
1
Campo 1
Campo 2
Campo 3
Campo 4
Campo 5
Campo 6
Campo 7
1 byte
2
1 byte
3
1 byte
4
1 byte
5
4 bytes
6..9
4 bytes
10..13
4 bytes
14..17
Tabela 10.2.3.2.3.1.1 – Mensagem State.
•
Campo 1 - Modified – Um byte onde os sete bits mais significativos informam quais os
campos da mensagem que foram alterados desde a ultima mensagem state enviada. (1) se
houve alteração, (0) em caso contrário. O bit de ordem 1 é para o campo 1 e assim
sucessivamente.
•
Campo 2 - General – Estado geral do robô – (0) se o robô detecta algum defeito e (1) se
tudo esta em condições.
•
Campo 3 - Power – Estado das baterias – (0) para muito fraco; (1) para fraco; (2) para
estável; (3) para bom e (4) para muito bom.
•
Campo 4 – Bumpers – Estado dos bumpers de contacto – Cada bit representa o estado de
um bumper, (1) para contacto e (0) sem contacto.
•
Campo 5 - v - Módulo da velocidade linear actual do robô.
•
Campo 6 - ω - Velocidade angular actual do robô.
Página 79 de 119
•
Campo 7 - ωd - Velocidade angular actual do dribbler do robô.
10.2.3.2.3.2
Mensagem GivePosition (0x0C)
Pede Posição
Nesta mensagem, o robô pede ao servidor a posição actualizada no campo. Essa posição é
utilizada pelo controlador de trajectórias para minimizar o erro de posição. O servidor responde com
uma mensagem do tipo Position. Esta mensagem não tem campos.
Identificador
Campos
GivePosition
⊗
0x0C
1 byte
0 bytes
Tabela 10.2.3.2.3.2.1 – Mensagem GivePosition.
10.2.4. Driver do Dispositivo Wireless
A escolha do hardware de comunicações utilizado na plataforma da RAC teve em consideração
um conjunto de requisitos fundamentais. Construir de raiz todo o hardware de comunicações via rádio
era uma das opções. No entanto, devido às necessidades actuais e futuras da plataforma, a escolha de
um sistema robusto e fiável era fundamental. Os requisitos fundamentais do sistema de comunicação
são:
•
•
•
Fiabilidade – O sistema de comunicação deve ser uma solução previamente testada e com
elevada fiabilidade.
Robustez – A necessidade de suportar aplicações futuras com necessidades consideráveis de
largura de banda.
Facilidade de implementação – A integração do sistema comunicações ao nível do software
deve ser standard de modo a facilitar o processo de desenvolvimento das aplicações de
controlo. Ao nível do hardware, o sistema tem de ser compacto e de fácil integração na
plataforma.
Depois de uma análise, os membros da RAC tomaram a opção de integrar na plataforma o
sistema de comunicação wireless 802.11b. A escolha de um dispositivo com interface USB em vez do
interface PCMCIA (dois dos interfaces mais comuns suportados pelo PC104) foi tomada devido ao
reduzido tamanho e baixo custo dos dispositivos USB. A integração ao nível de software revelou-se
mais complicada, pois o suporte para outros sistemas operativos, sem ser o Windows, era
desconhecido. Após alguns contactos a escolha recaiu sobre o dispositivo EDIMAX EW-7117U wlan
adapter USB que utiliza o chipset ZyDAS zd1201.
Devido a quota de mercado pouco significativa do sistema operativo GNU/Linux, quando
comparada com o Windows, surgem problemas de suporte ao nível dos dispositivos de hardware. A
grande maioria dos fabricantes não disponibiliza suporte para o Linux pois não existe retorno financeiro
que justifique suportar o investimento de desenvolvimento e suporte técnico a uma plataforma que não
dispõe de uma base de utilizadores considerável.
Cabe a terceiros o desenvolvimento de drivers de dispositivos para os quais o fabricante não os
disponibiliza. Este esforço de desenvolvimento recorre na maioria dos casos ao uso de técnicas de
engenharia inversa, pois os fabricantes, por razões de concorrência e protecção da sua propriedade
intelectual, não revelam a arquitectura interna do dispositivo.
Em Linux, um driver de dispositivo é chamado de módulo, ou LKM (Loadable Kernel Module),
constituem extensões ao Kernel Linux que lhe permitem comunicar com os dispositivos, sistemas de
ficheiros ou redes. Uma das grandes vantagens dos módulos é que podem ser carregados
dinamicamente na memória do Kernel quando é necessário utilizar o dispositivo. Como os módulos são
construídos separadamente, o trabalho de desenvolvimento e de manutenção é muito mais fácil.
Página 80 de 119
O projecto Linux ZyDAS zd1201 USB [DRIVER] foi um projecto iniciado por Jeroen Vreeken com
o objectivo de distribuir um módulo para o dispositivo de rede sem fios (802.11b) com interface USB
baseado no chipset ZyDAS zd1201. Existem numerosos fabricantes que comercializam dispositivos
baseados neste chipset como é o caso da Edimax, Sweex, Zyxel, Belkin, SureCom entre muitos outros.
Inicialmente a Sweex distribuiu um driver Linux para a sua gama de dispositivos de rede sem
fios (802.11) USB, mas inesperadamente, retiraram o suporte para Linux e de acordo com a sua página
Web, o Linux deixou de ser suportado para aquela gama de produtos.
O estado de desenvolvimento do driver passou pelas seguintes etapas:
•
•
•
•
Até à versão 0.3 o driver foi baseado num já existente, o wlan-ng, após a versão 0.4, foi
desenvolvido de raiz um novo driver com o nome zd1201.
O driver baseado em wlan-ng suporta as versões 2.4 e 2.6 do Kernel.
O driver novo apenas suporta as versões 2.6 do Kernel.
Em Julho de 2005, o driver foi incluído na árvore de código fonte do Kernel, podendo ser obtido
em conjunto com as versões superiores à 2.6.12. Todo o desenvolvimento futuro será incluído
directamente na árvore do Kernel.
Durante o desenvolvimento do driver descobriu-se que o dispositivo não implementa a
especificação do protocolo USB correctamente. Existe uma diferença no modo de enumeração de
dispositivos USB entre o Windows e o Linux (segundo as especificações, ambos os métodos estão
correctos), o dispositivo apenas implementa o método do Windows. Para o correcto funcionamento em
Linux, é necessário aplicar uma correcção à pilha USB do Kernel. Esta correcção deixou de ser
necessária em fins de Julho de 2005 com o lançamento da versão actualizada do Kernel Linux que
também inclui o driver.
10.2.5. Configuração da Rede Sem Fios
Os dispositivos de rede sem fios 802.11b USB de 11 Mbit/s a bordo dos robôs da RAC permitem
a comunicação com a rede cablada da RAC constituída pelos computadores de controlo central e
processamento de dados da câmara. Uma rede com esta configuração é do tipo Infrastructure, pois
integra as duas redes, com e sem fios. Um grupo de clientes a 11 Mbit/s e um ponto de acesso (AP)
formam um conjunto de serviço básico (BSS – Basic Service Set). Cada cliente num BSS pode
comunicar com qualquer computador na infra-estrutura de rede cablada através do AP.
Figura 10.2.5.1 – Configuração da rede sem fios.
Uma configuração do tipo Infrastructure possibilita o acesso de um sistema sem fios a uma rede
cablada e consegue aumentar o alcance de transmissão entre dois dispositivos sem fios, já que o AP é
responsável por encaminhar os dados dentro do BSS.
A utilização de um identificador único para um BSS é essencial. Cada robô necessita de ser
configurado para usar o identificador e as opções do BSS da RAC. Estas opções podem incluir o tipo de
encriptação e a respectiva chave de acesso ao BSS.
Página 81 de 119
10.3. Funções de I/O na Placa MESA 4i65
A 4i65 da MESA é uma placa para o bus PC104 onde podem ser implementadas funções de
entrada/saída complexas. A 4i65 utiliza uma FPGA (Field Programmable Gate Array) de duzentas mil
portas da Xilinx para a implementação da lógica programável.
Figura 10.3.1 – MESA 4i65.
A configuração da FPGA é carregada a partir do bus PC104 permitindo a criação de aplicações
de controlo especializadas, incluindo microcontroladores. Para facilitar as implementações do código da
FPGA é utilizado uma Bridge PCI que faz o interface entre a FPGA e o bus PC104. As aplicações de
programação na FPGA apenas têm que realizar um interface com um bus síncrono de 32 bits, evitando
a árdua tarefa de implementar o interface directo com o barramento PCI.
Todos os bits de entrada/saída suportam 5 Volts e conseguem fornecer uma corrente de 24 mA.
Existem resistências de Pullup para todos os pinos de modo a serem conectados directamente a optoisoladores, contactores etc. A 4i65 possui três conectores de cinquenta pinos, três leds com o estado de
configuração da FPGA e 8 leds que podem ser usados pelos programas da FPGA para informação de
estado ou debug das aplicações.
O relógio de sistema da FPGA utiliza um oscilador de 50 MHz. A FPGA também tem disponível
o relógio de 33 MHz do bus PCI. Outras frequências podem ser geradas utilizando o DLL (Delay Lock
Loop) incluído.
O fabricante disponibiliza vários programas com o dispositivo, incluindo uma implementação de
um controlador de servo-motores de quatro canais baseado em microcontrolador (softDMC) e também
um sistema de 72 bits de entrada/saída paralelo. Este tipo de programas constitui o que normalmente
chamamos firmware, pois é um caso de software feito para ser embebido num dispositivo de hardware.
O código fonte em VHDL esta disponível para todas as aplicações incluídas.
10.3.1. Características do Firmware softDMC
O controlador de movimento digital softDMC [SOFTDMC] é um controlador de motores DC para
vários eixos implementado inteiramente na FPGA. Um controlador de quatro eixos cabe numa FPGA
(Spartan II) de cem mil portas e um controlador de oito eixos cabe numa FPGA de duzentas mil portas.
A versão do softDMC utilizada na plataforma da RAC é a versão de quatro eixos o que significa que a
FPGA de duzentas mil portas dispõe ainda de bastante espaço livre para aplicações futuras.
Toda a lógica, CPU, RAM e o programa em ROM funcionam em apenas um chip FPGA o que
torna este sistema de controlo de motores extremamente flexível, poderoso e barato. A implementação
do softDMC é baseada num DSP (Digital Signal Processor) de 16 bits e com 50 a 100 MIPS (Milhões de
instruções por segundo). Em conjunto com a placa de interface de 4 canais H-Bridge, o softDMC,
dispõem de entradas de índice e dupla quadratura, dispõem de saídas PWM (Pulse Width Modulation),
Página 82 de 119
direcção e enable. Estão ainda livres 72 bits de entrada/saída disponíveis para limites, estados,
posições, ou qualquer outro uso. Os parâmetros de posição, velocidade e aceleração são todos de 32
bits. Cada eixo possui dois codificadores o que permite realimentação dupla por posição e velocidade. É
possível realizar movimentos multi-eixo com relações de caixa precisas através de um registo de 32 bits
para o rácio entre eixos.
Os interfaces do softDMC são totalmente síncrono, permitindo que a maioria dos parâmetros
seja alterado durante o movimento. Incluem o interface PC/104 de 16 bits, interface de microcontrolador
de 8 bits, PCI, série, entre outros.
O controlador PID de cada eixo para além dos termos normais (Proporcional, Integral e
Derivativo), possui os termos de realimentação de velocidade, aceleração, bias e fricção para extrair o
máximo de desempenho dos motores. As altas taxas de amostragem (>30 Khz para o movimento dos 4
eixos em simultâneo) suportam motores pequenos e rápidos. Podem ser programados acções para
responder em tempo real a eventos internos (posição, tempo, velocidade, flags, etc.) e externos (limites,
sensores, etc.).
10.3.2. Calibração do Controlador PID
Para cada motor da plataforma é necessário afinar os parâmetros do controlador PID.
Juntamente com o softDMC é fornecido o programa DMCtune [DMCTUNE]. Este programa permite a
afinação manual dos parâmetros do controlador PID mostrando no ecrã a resposta do sistema. O
DMCtune mostra quatro parâmetros: o perfil de movimento programado (verde), o perfil de movimento
actual (amarelo), o sinal do motor (vermelho) e o erro, que é a diferença entre o perfil programado e o
perfil actual (violeta).
Figura 10.3.2.1 – Interface gráfica de calibração DMCtune.
O controlador PID utiliza controlo realimentado para manter a posição actual do motor igual a
posição pretendida. Os ponteiros utilizados pelo PID são: POSENC para o codificador de posição,
VELENC para o codificador de velocidade e FOLLOW para a posição desejada. O valor por defeito de
POSENC e VELENC é ENCP, que é o codificador primário do eixo a ser controlado. O valor por defeito
de FOLLOW é DESPOS, que é a posição desejada criada pelo gerador de perfil.
O PID é controlado por 6 parâmetros principais:
•
•
•
•
•
•
KP – Termo proporcional ou ganho
KI – Termo Integral
KD – Termo derivativo
KF1 – Termo de velocidade (feed forward)
KF2 – Termo de aceleração (feed forward)
KIL – Limite de Integração
Página 83 de 119
A saída do controlador PID é um sinal Drive que estabelece os sinais PWM e de direcção que
controlam a intensidade e direcção de corrente que é aplicada ao motor. A equação simplificada para o
sinal de saída do PID é:
Drive = KP(−E ) + KI (∑ − E∆T ) + KD(− ACTVEL) + KF1(VELOCITY) + KF 2( ACCEL)
Onde E é o erro de posição (posição desejada menos posição actual), ACTVEL é a velocidade
actual, VELOCITY é a velocidade pretendida e ACCEL a aceleração.
O programa DMCtune gera um ficheiro com os valores dos parâmetros do PID que depois são
enviados pelas aplicações de controlo ao softDMC, durante a fase de inicialização.
10.3.3. Implementação do softDMC Loader
Tal como uma memória RAM uma FPGA necessita de corrente eléctrica para manter a
informação armazenada no seu interior, assim, cada vez que a plataforma é ligada é necessário
carregar e executar o softDMC na FPGA da placa 4i65. Esta operação é realizada pelo sistema
operativo durante a fase de arranque do sistema. O softDMC está armazenado no sistema de ficheiros
da memória flash como um ficheiro binário normal, sendo necessário a utilização de uma ferramenta que
comunique com a placa 4i65 e que transfira o código binário do programa. Esta ferramenta é ainda
responsável por executar o programa na FPGA.
A ferramenta disponibilizada pela MESA para realizar o carregamento do firmware era bastante
antiquada. A única versão disponível apenas funcionava em MS-DOS e nos Windows mais antigos
(anteriores ao Windows Millennium). Felizmente, o código fonte da aplicação estava disponível em
linguagem C, no entanto, existem diferenças consideráveis entre o Linux e o MS-DOS, principalmente
quando existe a necessidade de comunicar com dispositivos no barramento PCI [PCI].
Figura 10.3.3.1 – Fase de arranque no sistem a de desenvolvimento.
Após uma análise cuidada ao código fonte do carregador para MS-DOS verificou-se que grande
parte das rotinas de comunicação com dispositivos era feita com o recurso a bibliotecas que não eram
possíveis de transferir para o Linux. Grande parte das funções estavam definidas em dos.h que é uma
das bibliotecas que acompanha o compilador BORLAND C [BORLAND] para sistemas operativos
Microsoft mais antigos, entre os quais o MS-DOS. As funções definidas em dos.h fazem uso extensivo a
código máquina de 16 bits para processadores x86, no entanto o Linux utilizado na plataforma RAC é
um sistema operativo de 32 bits com uma arquitectura bem mais sofisticada. Tirando as funções de
comunicação com o barramento PCI o resto do código fonte era bastante standard, resumia-se a abrir o
ficheiro com o firmware e a transferir o seu conteúdo usando as rotinas de comunicação. Tirando alguns
pequenos pormenores de sintaxe, o código fonte de leitura do ficheiro era idêntico ao código em Linux.
Para solucionar o problema das funções de comunicação foram definidos duas tarefas:
v Identificar as bibliotecas do Linux que possuíam funções que realizem acções semelhantes às
utilizadas pelo carregador em MS-DOS.
Página 84 de 119
v Alterar todas as funções e estruturas de dados do carregador para utilizarem as novas
bibliotecas.
Todas as funções necessárias estavam disponíveis no Linux em pci.h que faz parte da biblioteca
libpci, no entanto, o método de utilização dessas funções, e as estruturas de dados utilizadas, eram
completamente diferentes. Houve a necessidade de voltar a implementar grande parte das funções de
comunicação com o barramento PCI. Das funções redesenhadas, destacamos:
Funções Redesenhadas
Nome
Descrição
outportswap
Envia um byte invertido para a placa 4i65
outportsnoswap
Envia um byte para a placa 4i65
findpcicard
Tenta descobrir a placa 4i65 no bus PCI
Pcicfgread16
Lê a “configuration word” da 4i65
Writeenable5i20
Prepara a FPGA para escrita
ProgramEnable5i20
Prepara a FPGA para programação
findports
Descobre as localizações i/o da 4i65
programcard
Envia os dados do ficheiro para a 4i65
Tabela 10.3.3.1 – Funções implementadas para o carregador Linux
O carregador de firmware para Linux possui dois parâmetros de entrada, o primeiro é o nome do
ficheiro binário que contém o firmware a carregar e o segundo é o número da placa 4i65 que desejamos
programar (caso existam várias 4i65 ligadas ao sistema). O carregador realiza os seguintes passos:
1. Inicializa as estruturas de dados e a biblioteca libpci, verificando se o sistema possui um
barramento PCI.
2. Obtém uma lista com os dispositivos ligados ao barramento.
3. Verifica se existem uma ou mais placas 4i65 no barramento PCI, através do VENDOR_ID
(0x10b5) e do DEVICE_ID (0x9030) dos dispositivos. Se não existirem, o programa termina
com uma mensagem de erro. Se existirem uma ou mais placas 4i65, utiliza o argumento de
entrada para escolher o número da placa a programar.
4. Verifica a existência do ficheiro binário que contém o firmware e carrega-o para uma
estrutura de dados em memória.
5. Lê a “configuration word” do dispositivo para determinar a gama e o mapeamento de portos
de entrada/saída atribuídos automaticamente pelo protocolo “plug & play” no arranque do
sistema.
6. Faz um reset à FPGA, apagando o seu conteúdo e parando a execução de programas.
7. Carrega o firmware na FPGA e verifica o sucesso da operação.
8. Finaliza a programação da FPGA e ordena a execução do programa.
9. Limpa os recursos utilizados e termina a aplicação.
10.4. Controlador de Movimento
A principal função do controlador de movimento é realizar a cinemática inversa do robô, ou seja,
transformar os comandos de velocidade ou de posição enviados pelo controlador central em comandos
de velocidade individuais para cada um dos três motores. No entanto, este programa não se limita ao
controlo de movimento, pois implementa todo interface com o exterior. Na primeira versão, o programa
também controla o kicker e fornece informação sobre o estado interno do robô, como o nível de carga
das baterias ou a existência de anomalias no hardware.
As funções básicas da aplicação são as seguintes:
1. Implementação do lado cliente do protocolo de comunicações: inicia a comunicação e processa
o envio e recepção das mensagens entre o controlador central e o robô.
Página 85 de 119
2. Realização do controlo de movimento, transforma os comandos de posição ou velocidade
enviados pelo controlador central em comandos individuais para cada motor.
3. Controlo da força e do disparo do kicker.
4. Controlo do estado interno do robô, nomeadamente, o nível de carga das baterias e a presença
de anomalias no hardware.
Algumas das mensagens definidas no protocolo de comunicações da RAC (RACprotocol) não
foram implementadas na primeira versão da aplicação de controlo, pois existia hardware que ainda não
estava disponível na primeira interacção da plataforma, como é o caso do dribbler.
10.4.1. Arquitectura do Controlador
A aplicação de controlo é constituída por dois processos que comunicam entre si através de um
pipe (tubo). Um pipe é uma funcionalidade disponibilizada pelo sistema operativo para comunicação
inter-processo (IPC – Inter Process Comunication), a analogia com um tubo é correcta, pois permite que
dois processos troquem um fluxo de dados entre si. Cada processo pode ler e escrever dados para o
pipe, é portanto uma forma de comunicação bidireccional. Uma das grandes vantagens de utilizar as
IPC do sistema operativo é a possibilidade dos processos bloquearem sempre que não existam dados
no pipe. Nesta situação o sistema operativo fornece o tempo de processamento a outras aplicações.
Figura 10.4.1.1 – Arquitectura geral da aplicação de controlo
O processo 1 é responsável pelo estabelecimento da ligação e codificação e descodificação das
mensagens TCP/IP que são trocadas entre o cliente e o servidor. Este processo estabelece a ligação ao
servidor central e inicia uma sessão, identificando o cliente respectivo. Quando é recebida uma
mensagem, o processo 1 interpreta o corpo da mensagem e, se respeitar o protocolo, envia o comando
associado ao processo 2 usando o pipe. Nas situações em que o processo 2 necessita de informação
de posição, o processo 1 codifica a mensagem respectiva e envia-a ao servidor. Sempre que não
existam mensagens tanto do servidor como do processo 2, o processo 1 fica bloqueado numa função
select que não é mais do que um interface para a rotina de sistema, com o mesmo nome, que permite
realizar operações de entrada/saída assíncronas. A função select aceita uma lista de objectos ou
descritores de ficheiros que podem ser “escutados”. Assim, a função bloqueia até que um desses
objectos possua informação para ser tratada. É possível definir um valor de timeout de modo a que a
função não fique bloqueada indefinidamente. A granularidade do temporizador de timeout da função
select permite realizar operações temporizadas com grande precisão.
O processo 2 é responsável pelo controlo de movimento e faz o interface com os sensores e
actuadores da plataforma. Este processo recebe os comandos do processo 1 e executa-os. De salientar
que existem comandos que podem demorar vários segundos a executar, como por exemplo, o
seguimento de uma trajectória, ou o carregamento do condensador do kicker. Este processo tem a
Página 86 de 119
capacidade de executar vários comandos em simultâneo, mantendo para cada um deles, a
temporização adequada. Como o controlador de trajectórias é essencialmente baseado em odometria, a
precisão do temporizador necessita de ser elevada para minimizar erros de integração da velocidade. O
processo 2 utiliza bibliotecas de funções matemáticas para o cálculo de matrizes que realizam a
cinemática inversa do movimento. Por outro lado, sempre que a velocidade angular do robô é diferente
de zero, é necessário multiplicar as velocidades dos motores por uma matriz de rotação que depende da
velocidade angular, tal como foi analisado na secção 8.3.3. A figura 10.4.1.1 dá uma visão geral da
arquitectura da aplicação de controlo.
Figura 10.4.1.2 – Diagrama de actividade da aplicação global
Como mostra o diagrama de actividade da figura 10.4.1.2, a aplicação começa por criar o socket
TCP/IP e o pipe de comunicação inter-processo. Seguidamente, é carregado o ficheiro de configuração,
este contém dados importantes, como por exemplo, o endereço IP do servidor, os parâmetros dos
controladores PID de cada um dos eixos e os parâmetros de desfasamento
das rodas. Após a
configuração, são criados os dois processos, passando cada um deles a executar concorrentemente,
cada processo é criado no mesmo espaço de memoria atribuído à aplicação principal, pelo que herdam
do processo pai todas as variáveis e descritores de ficheiros de modo a poderem comunicar através do
pipe. Cada um dos processos realiza as suas funções até que a ligação ao servidor seja terminada por
uma das partes. Para finalizar, a aplicação liberta os recursos do sistema e escreve no ficheiro de
configuração os parâmetros alterados pela última sessão. A aplicação pode ser configurada para tentar
Página 87 de 119
conectar-se indefinidamente ao servidor, o que é bastante útil, pois dispensa intervenção humana
sempre que a ligação ao servidor seja quebrada por qualquer motivo.
Figura 10.4.1.3 – Diagram a de actividade do processo 1
O diagrama de actividade da figura 10.4.1.3 mostra o comportamento do processo 1 como foi
referido, o processo 1 é responsável pela comunicação entre o programa de controlo e o servidor
central. Funciona basicamente como uma bridge (ponte) entre as duas aplicações. Implementa o
protocolo de comunicações RACprotocol, convertendo as mensagens em comandos e vice-versa. Cada
mensagem recebida do servidor é verificada de acordo com a especificação e transformada num
comando transmitido através do pipe para o processo 2. Quando um dos processos intervenientes
necessitar de terminar por algum motivo, o processo 1 envia uma mensagem à outra parte interessada
para que esta possa terminar correctamente.
O processo 2 da aplicação tem uma complexidade bastante grande, pois este é responsável por
todas as acções de controlo sobre actuadores e sensores da plataforma. Este processo recebe no pipe
Página 88 de 119
de comunicação inter-processo os comandos passados pelo processo 1 depois de enviados pelo
controlador centralizado. Os comandos podem ser divididos em duas categorias:
•
•
Comandos síncronos – São os comandos que resultam numa acção imediata, como por
exemplo, um comando de velocidade, o comando de paragem ou o comando de chutar a
bola.
Comandos assíncronos – São comandos em que a acção se propaga durante um tempo
relativamente longo, como por exemplo, o seguimento de uma trajectória ou carregamento
do condensador do kicker.
Comando
Síncrono
x
x
x
x
x
GiveState
SetVelocity
SetParms
Halt
KickBall
SetTrajectory
Tipo
Assíncrono
x
x
Tabela 10.4.1.1 – Classificação dos comandos de controlo
De salientar que o comando KickBall possuí duas acções, uma síncrona, chutar a bola, e outra
assíncrona, carregar o condensador do kicker. Logo a seguir ao chuto, o condensador é carregado
durante um intervalo de tempo que é proporcional à força desejada. Como o circuito leva alguns
segundos a carregar, a força não pode ser definida no momento do chuto.
Como foi analisado na secção 8.3.3, o vector velocidade tem as suas componentes v x e vy no
referencial do robô, de modo que se este rodar (rad/s) é necessário fazer uma rotação do referencial
de modo a que o vector velocidade mantenha a mesma orientação. No domínio da aplicação de
controlo, é necessário multiplicar a velocidade de entrada por uma matriz de rotação. O ângulo de
rotação é calculado multiplicando o intervalo de tempo pela velocidade angular do robô. Este
procedimento é necessário sempre que é diferente de zero.
A execução de comandos assíncronos requer que o estado de execução do comando seja
actualizado durante o tempo de execução, este estado é controlado por blocos de software que foram
designados de controladores de comandos assíncronos. Por defeito, a aplicação executa cada um
destes controladores a uma frequência de 40 Hz. Quando um controlador é executado, a saída é
calculada sabendo que a última execução do bloco ocorreu 25 ms atrás. Cada controlador é executado
em cadeia em cada ciclo de execução, deste modo, os comandos são executados em paralelo.
O controlador de rotação não implementa nenhum comando em particular. A sua função é
multiplicar a velocidade pela matriz de rotação, sempre que a velocidade angular é diferente de zero.
Os comandos síncronos requerem acções de controlo imediatas, de modo que a sua execução,
logo após a recepção, ocorra o mais rapidamente possível. A execução de um comando síncrono pode
interromper ou iniciar a execução de um controlador. Por exemplo, o comando halt, deve interromper a
execução do controlador de trajectórias.
Comando
GiveState
SetVelocity
SetParms
Halt
KickBall
SetTrajectory
Trajectoria
Desactiva
Desactiva
Activa
Controlador
Kicker
Activa
-
Rotação
-
Tabela 10.4.1.2 – Influencia dos comandos nos controladores
Página 89 de 119
Figura 10.4.1.4 – Diagrama de actividade do processo 2
10.4.1.1.
Controlo por Comando de Velocidade
O controlo por comandos de velocidade possibilita que o movimento do robô seja executado
fornecendo apenas as componentes do vector velocidade no referencial da plataforma. Adicionalmente,
é possível fornecer a velocidade angular desejada. No caso da velocidade angular ser diferente de zero,
o controlador de rotação corrige o movimento como já foi descrito anteriormente.
Este comando transforma a velocidade da plataforma em comandos de velocidade para cada
um dos três motores utilizando a matriz de cinemática inversa, cuja equação foi obtida na secção 7.2. A
execução deste comando implica que seja desactivado qualquer movimento que o controlador de
trajectórias esteja a executar na altura. Este comando é executado em apenas um ciclo de
processamento da aplicação. O diagrama de actividade do comando está representado na figura
10.4.1.5.
Página 90 de 119
Figura 10.4.1.5 – Diagrama de actividade do controlo por com andos de velocidade
10.4.1.2.
Controlador de Trajectórias
O controlador de trajectórias é activado pelo comando SetTrajectory e a sua função é realizar
um movimento programado ao longo de um caminho ou trajectória. Esta trajectória é dividida em
segmentos de recta. Por cada segmento, o movimento do robô é caracterizado por um conjunto de
parâmetros designado de set-point. Cada set-point possui quatro parâmetros que definem o movimento
nesse segmento da trajectória: A posição desejada no referencial do campo, x e y, a velocidade do robô,
v, e a velocidade angular, .
O controlo de movimento é implementado usando essencialmente odometria. A velocidade da
plataforma é integrada ao longo do tempo para estimar a posição pretendida. O estudo prévio em
simulador foi efectuado no capítulo 8.
Figura 10.4.1.6 – Diagram a de actividade do sistema de polling dos dados da câmara
A câmara de visão global fornece dados de posição de todos os objectos do campo. No entanto,
para que o controlo seja suficientemente rápido, o recurso a odometria é essencial. A realimentação de
posição da câmara é utilizada a uma frequência baixa apenas para corrigir os erros de integração da
Página 91 de 119
velocidade. Na figura 10.4.1.6 é mostrado como o controlador de trajectórias faz o polling para obter a
posição do robô.
Quando o controlador termina o movimento de um set-point, utiliza a posição fornecida pela
câmara para corrigir a posição actual do robô. O próximo movimento é calculado tendo em conta a
posição real e a posição pretendida. Durante a realização do movimento apenas é utilizada odometria
para controlar o movimento. Na figura 10.4.1.7 esta representado o diagrama geral do controlador de
trajectórias.
Figura 10.4.1.7 – Diagrama de actividade do controlo de trajectórias
10.4.1.3.
Controlador de Rotação
O controlador de rotação executa uma mudança do referencial do robô sempre que a velocidade
angular é diferente de zero, multiplica a velocidade desejada para a plataforma por uma matriz de
rotação, tal como foi analisado na secção 8.3.3. O ângulo de rotação da matriz é calculado multiplicando
a velocidade angular pelo tempo que decorreu desde a ultima rotação. Este controlo não possui nenhum
Página 92 de 119
comando associado, pois a sua condição de acção é a velocidade de rotação ser diferente de zero. O
diagrama de actividade do controlador está representado na figura 10.4.1.8.
Obtém velocidade angular
Velocidade angular != 0?
Não
Sim
Calcula ângulo de rotação
Multiplica velocidade pela matriz de rotação
Figura 10.4.1.8 – Diagrama de actividade do controlador de rotação
10.4.1.4.
Controlador de Carga do Kicker
O controlador de carga kicker controla a duração em que o circuito de carga fornece energia ao
condensador. O controlador passa ao estado activo assim que é executado um comando KickBall. A
força do chuto é proporcional à energia armazenada no condensador, que por sua vez está relacionada
com o tempo de carga. Um dos parâmetros da mensagem KickBall é a força desejada para o remate.
Este parâmetro é usado para determinar o tempo de carga. O controlador activa o circuito de carga e
inicia um contador. Por cada ciclo de execução, o contador é incrementado até que atinja o valor que
corresponde ao intervalo de tempo desejado, nesse instante o circuito é desligado e o condensador
estará carregado com a energia pretendida. O diagrama de actividade do controlador está representado
na figura 10.4.1.9.
Figura 10.4.1.9 – Diagrama de actividade do controlador de carga do kicker
Página 93 de 119
11. Testes e Resultados
Um dos objectivos finais da RAC é desenvolver uma equipa de Futebol Robótico competitiva e
eficiente. A melhor forma de avaliar a performance do sistema é submetê-lo a um teste de
funcionamento em competição, isto é, um jogo de Futebol Robótico. Os jogos constituem a melhor forma
para testar o desempenho da Arquitectura e Sistema, pois torna-se possível comparar o desempenho
com outras equipas. No caso da RAC isso ainda não foi possível, os testes efectuados foram realizados
ainda no Laboratório de Robótica Móvel.
Neste capitulo são apresentados alguns testes e conclusões das aplicações referentes ao
Sistema de Controlo do robô. Inicialmente são analisados aspectos referentes à participação em
competições e eventos. Seguidamente são ilustrados diversos testes e ensaios, juntamente com
algumas conclusões. No final é feita uma análise do Sistema de Controlo terminando com a
apresentação de algumas perspectivas de desenvolvimento.
11.1. Competições e Eventos
A realização do Festival Nacional de Robótica em Coimbra motivou todos os membros da RAC.
Durante as semanas que precederam o evento, foram feitos grandes progressos no desenvolvimento da
equipa de Futebol Robótico. A publicação de dois artigos no Encontro Científico, por parte da equipa
RACmotion e da equipa RACsmart, vieram mostrar alguns dos trabalhos e objectivos da RAC. A
participação na competição não foi possível de realizar conforme o objectivo inicial, no entanto a equipa
esteve presente com um expositor que veio realçar todo o trabalho desenvolvido. A oportunidade dada
ao público em geral de interacção com os robôs e de conhecimento sobre a sua tecnologia obteve
grande êxito. Durante dois dias dezenas de pessoas visitaram o expositor e puderam deliciar-se com as
competições e demonstrações apresentadas no Robótica 2005.
Figura 11.1.1 – Robótica 2005.
A realização de um Atelier e Sessão de Palestras vieram promover a divulgação do Projecto
RAC, bem como, projectos levados a cabo por outras pessoas e instituições. Foi o caso do artista
Leonel Moura e dos seus Robôs Pintores. É fundamental que a divulgação de projectos desta
envergadura seja feita junto da comunidade académica e público em geral. São precisas novas ideias e
pessoas com espírito de iniciativa, de modo a enraizar estes projectos na nossa comunidade e lhes
proporcionar um final feliz.
11.2. Testes e Ensaios
Os testes e ensaios descritos nesta secção foram realizados no Laboratório de Robótica Móvel
no Instituto de Sistemas e Robótica de Coimbra. Os objectivos visam testar a aplicação de controlo
Página 94 de 119
desenvolvida para o protótipo RACbot. É fundamental que os resultados obtidos em simulação sejam
validados pela implementação do controlador de movimento.
11.2.1. Arranque e Movimento do Robô
O desenvolvimento do Simulador RACbot permitiu a analise e estudo do movimento do robô
para diferentes trajectórias. Após a implementação do Sistema de Controlo na plataforma, foi necessário
analisar o seu comportamento em ambiente real, não simulado, para perceber as suas acções e
melhorar o controlo efectuado. Numa primeira fase, foi analisado o comportamento no arranque e o
movimento do robô de um ponto A para um ponto B. Foram utilizados diferentes pontos no campo de
jogo tal como mostra a figura 11.2.1.1.
Figura 11.2.1.1 – Testes de movimento efectuados ao robô (varias direcções num raio de 1.2m).
Este conjunto de 12 pontos vai permitir analisar o comportamento do robô em várias direcções
partindo do centro do terreno. Inicialmente foram marcados e medidos os pontos no campo e
seguidamente foram introduzidos na aplicação de controlo. Os 12 pontos situam-se sobre uma
circunferência com 1,2 metros de raio.
Pontos
A
B
C
D
E
F
x (m)
y (m)
0
1.03923
0.6
0
-0.6
-1.03923
1.2
0.6
1.03923
1.2
1.03923
0.6
Pontos
G
H
I
J
K
L
x (m)
-1.2
-1.03923
-0.6
0
0.6
1.03923
y (m)
0
-0.6
-1.03923
-1.2
-1.03923
-0.6
Tabela 11.2.1.1 – Conjunto de pontos utilizados no ensaio do movimento do robô.
Numa primeira análise podemos concluir que o robô tem alguma dificuldade no arranque. Existe
bastante atrito entre as rodas e o campo de jogo (alcatifa). Por outro lado, a plataforma ainda não foi
optimizada em relação ao peso, de modo que é possível melhorar o seu desempenho. Ao ensaiar o robô
fora do campo de jogo, observamos que as rodas não estão tão susceptíveis ao atrito e o seu
movimento ocorre mais suavemente. O estado das baterias também influencia o movimento, à medida
que se realizam os testes e as baterias se gastam, o robô vai gradualmente perdendo potência.
Em relação aos testes com os diversos pontos introduzidos, obtivemos bons resultados segundo
determinadas direcções do movimento, mas os resultados não foram satisfatórios quando o movimento
se realizou noutras direcções. Numa primeira fase, foi ensaiado o movimento sem velocidade angular,
ou seja, a rotação do robô sobre o seu próprio eixo permaneceu igual a zero durante todo o movimento.
Podemos concluir que os set-points B, F, J tiveram melhores resultados, uma vez que o robô se
deslocou para as proximidades dos pontos com um desvio máximo de cerca de 10 cm. Por exemplo,
Página 95 de 119
para o set-point B os motores 1 e 3 têm velocidades simétricas e o motor 2 tem velocidade igual a zero,
o que vai facilitar o movimento e equilíbrio do robô. O mesmo acontece no caso do ponto F, o motor 3
fica parado e os restantes motores executam a tracção. O caso J mantém o motor 1 parado e os
motores 2 e 3 em movimento.
Concluímos que os restantes set-points que colocam os três motores em movimento, vão
originar grandes discrepâncias nos resultados, o robô tem tendência a desequilibrar-se e executar
trajectórias incorrectas. A dificuldade de controlo do robô aumenta, quanto maior for a influencia dos três
motores na trajectória.
Figura 11.2.1.2 – Posição final do robô após a introdução do set-point C [0.6 1.03923 0.1 0].
Não foi possível fazer a aquisição de dados da trajectória, no entanto, conseguimos tirar
algumas conclusões com base no ponto final atingido pelo robô. De notar, que estes testes foram
realizados em malha aberta, ou seja, a realimentação através do sistema de visão não foi utilizada,
embora a aplicação esteja preparada para utilizar os dados da câmara na execução de trajectórias
complexas, nomeadamente, através do comando setTrajectory. O controlo de movimento utiliza apenas
odometria. O controlador integra a velocidade do robô ao longo do tempo para obter uma estimativa da
posição final.
O robô obteve alguns resultados satisfatórios, contudo, também foram obtidos resultados menos
bons. A figura 11.2.1.3 ilustra alguns resultados, através de gráficos XY, dos vários testes executados
para diferentes set-points.
a) Ponto H (-1.03923, -0.6)
b) Ponto L (1.03923, -0.6)
Figura 11.2.1.3 – Testes de movimento efectuados ao robô para os set-points H e L (vmed=1m/s).
Página 96 de 119
a) Ponto B (1.03923, 0.6)
b) Ponto C (0.6, 1.03923)
Figura 11.2.1.4 – Testes de movimento efectuados ao robô para os set-points B e C (vmed=1m/s).
Distância ao
Ponto B
Ponto B
1.03923
1
1.04
1.07
1.065
0.6
0.5
0.7
0.6
0.5
0.10742
0.100003
0.03077
0.103267
0.085365
Distância ao
Ponto C
Ponto C
0.6
0.45
1.1
0.65
0.4
1.03923
1.02
1.3
0.97
0.6
0.151228
0.563916
0.085398
0.482621
0.320791
Tabela 11.2.1.2 – Cálculo da média das distancias das varias amostras aos pontos B e C.
Na tabela 11.2.1.2 é evidente a eficácia do comportamento do robô na execução do set-point B
em relação ao set-point C. O set-point C obriga o funcionamento dos três motores, enquanto que o
set-point B apenas coloca em funcionamento os motores 1 e 3 com velocidades simétricas, o motor 2
fica parado.
O possível peso excessivo e a dificuldade no arranque foram iminentes nos testes efectuados. O
comportamento dos motores difere bastante entre vazio e carga, provando mais uma vez que diversos
factores (peso, atrito, desfasamentos, etc.) influenciam bastante a trajectória do robô.
Nos vários testes efectuados podemos tirar as seguintes conclusões:
v A execução dos movimentos para os pontos B, F e J, obtiveram resultados satisfatórios;
v O aumento e diminuição da velocidade do robô influencia muito a trajectória, Para velocidades
pequenas, os motores não conseguem vencer as forças de inércia e atrito. Para velocidades
elevadas é difícil manter o equilíbrio dinâmico da plataforma, causando uma trajectória muito
diferente da esperada. Um bom compromisso obtido foi: vmed= 1m/s;
v O valor da aceleração introduzido na aplicação de controlo deve ser o mais elevado possível.
v As trajectórias em que os três motores estão pleno funcionamento têm piores performances
comparadas com as trajectórias em que apenas actuam dois motores.
Como foi referido, as trajectórias B, F e J obtiveram bons resultados devido à forma simplificada
da cinemática, assim, concluímos que devemos valorizar este comportamento e adoptá-lo na
movimentação do robô. O movimento deve sempre ser realizado no sentido da frente de ataque, ou
seja, deve sempre utilizar as rodas 1 e 3 adjacentes ao kicker para tracção principal e utilizar a roda 2
apenas para mudança de direcção, só assim se consegue uma trajectória bastante próxima do
esperado.
Página 97 de 119
Figura 11.2.1.5 – Frente de ataque do robô.
A introdução de velocidade angular diferente de zero em simultâneo com o movimento de
translação do robô, não obtém resultados satisfatórios. Para cada intervalo t é calculada uma rotação
dos eixos no referencial do robô o que origina a actuação dos três motores em simultâneo, como foi
analisado na secção 8.3. Nestas circunstâncias, o robô sofre um desequilíbrio de forças o que origina
uma trajectória incorrecta muito longe da esperada. Chegámos à conclusão que a utilização de controlo
realimentado pelos dados de posição e orientação da câmara é essencial para corrigir os desvios que
ocorrem durante o movimento de translação e rotação simultâneo. A frequência de actualização dos
dados da câmara terá que ser superior à frequência de execução do controlador de rotação para que se
obtenham bons resultados. O controlador realiza actualizações 40 ciclos por segundo, no entanto, foi
confirmado que o sistema de processamento de visão apenas consegue um máximo de 15 ciclos por
segundo. Será possível alcançar uma solução de compromisso, mas todos os grupos de trabalho
envolvidos no projecto RAC, conjuntamente, terão realizar testes de interoperabilidade. Tal não
aconteceu, pois o desenvolvimento das aplicações de controlo sofreram atrasos, em todos os níveis da
arquitectura de controlo da RAC.
Outro dos problemas identificados envolve o controlador PID de cada motor, este utiliza controlo
realimentado para manter a posição actual do motor igual a posição pretendida, no entanto, a posição
actual tende a atrasar-se ao longo do tempo, o controlador tenta compensar este atraso, mas os
motores não conseguem desenvolver potência suficiente para compensar o atraso de posição. Neste
contexto, podemos concluir que o controlo do robô por comandos de posição é bastante difícil, a
abordagem mais correcta para esta versão da plataforma é o controlo por velocidade.
11.2.2. Execução de Trajectórias
Os testes seguintes, abordam, a execução de trajectórias através da inserção de vários
set-points na aplicação de controlo. Na figura 11.2.2.1 é ilustrada uma trajectória testada.
Figura 11.2.2.1 – Execução de trajectórias.
A aplicação de controlo está preparada para receber uma trajectória predefinida através da
inserção de vários set-points em simultâneo (comando setTrajectory). Cada set-point é então executado
por ordem, permitindo realizar movimentos complexos. Como vimos na secção anterior, nem todas as
direcções do movimento obtêm resultados satisfatórios. Por outro lado, a sucessiva realização de
movimentos leva à acumulação de erros de posição que necessitam de ser corrigidos pelos dados de
posição da câmara global. Ao nível da aplicação de controlo, a correcção do erro de posição é feita no
Página 98 de 119
final da execução de cada set-point, o movimento é corrigido tendo em conta a posição real obtida pelo
sistema de visão e a posição que se pretende atingir no próximo set-point.
Figura 11.2.2.2 – Execução de trajectórias.
Os testes realizados para a execução de trajectórias complexas tiraram partido das conclusões
obtidas na secção anterior, assim, todos os movimentos foram executados usando apenas as direcções
que obtiveram bons resultados.
A aplicação de controlo desenvolvida calcula os vários parâmetros de cinemática para os
diferentes set-points introduzidos, a introdução do parâmetro vmed=1m/s vai permitir calcular o tempo
necessário que o robô demora a percorrer um segmento da trajectória e seguidamente mudar para
outra, a aplicação utiliza um temporizador de alta resolução que permite definições na casa dos
microsegundos. Contudo, um pequeno atraso no arranque do robô origina um atraso na trajectória prédefinida. É bastante difícil prever este factor de modo a compensar toda a trajectória, contudo, a
introdução do sistema de visão vai ajudar na correcção deste parâmetro, pois é possível minimizar o
erro de posição entre dois set-points consecutivos.
A interligação com o sistema de controlo central e com a câmara de visão global não foi possível
de realizar durante a etapa final de testes do projecto RACmotion. Não foi possível reunir todos os
grupos de trabalho de modo a realizar testes conjuntos. Todos os resultados foram obtidos com controlo
baseado em odometria.
A figura 11.2.2.3 ilustra uma trajectória definida pelos pontos A, B e C. Ao introduzirmos este
conjunto de set-points na aplicação de controlo, vamos ter vários comportamentos. As trajectórias
representadas são uma aproximação do movimento realizado pelo robô em vários ensaios realizados.
Figura 11.2.2.3 – Trajectória utilizada nos testes efectuados ao robô
Pontos
A
B
C
x (m)
y (m)
0.6
0.6
3
1
-0.4
-0.4
Tabela 11.2.2.1 – Conjunto de pontos utilizados no ensaio de uma trajectória do robô.
Página 99 de 119
O cenário montado na figura 11.2.2.3 mostra algumas trajectórias satisfatórias, mas na realidade
o comportamento do robô não é constante entre dois ensaios consecutivos, realizados em condições
semelhantes. Na tentativa de melhorar o comportamento do robô, foram efectuadas algumas
optimizações na aplicação de controlo. O modo como a aplicação altera as velocidades entre cada
set-point foi modificado para garantir que as velocidades dos motores, em cada instante, sejam
proporcionais às velocidades que resultam da aplicação das equações de cinemática.
Figura 11.2.2.4 – Trajectória efectuada pelo robô
11.2.3. Procedimento de Calibração
A validação do procedimento de calibração não foi efectuada como desejávamos. Foram
executadas várias tentativas de aplicar o procedimento, tal como foi descrito no capítulo 9, mas os
resultando foram inconclusivos no que toca à validade do procedimento. A conclusão tirada dos vários
testes, mostra que existem outros factores que são muito mais influentes no movimento do robô do que
um possível ângulo de desfasamento dos eixos dos motores. Fenómenos como o atrito sobre
determinada roda, aceleração e distribuição de peso, provocam alterações na trajectória que se
sobrepõem ou somam ao efeito em analise. Apesar dos resultados não serem os que mais
desejaríamos, aprendemos ao menos quais serão os factores a incluir futuramente no modelo.
11.2.4. Controlo de Disparo e Carga do Kicker
Embora o circuito do kicker ainda se encontre na fase de desenvolvimento e teste, foi possível
realizar o ensaio ligando dois LEDs às saídas de dados da placa MESA 4i65. Uma das saídas controla o
disparo e a outra controla o tempo de carga do condensador. O programa de controlo responde ao
comando kickBall executando o disparo e activando o temporizador que controla a saída de carga.
11.2.5. Conclusões
Com a realização destes testes, pretendeu-se validar a implementação e analíse realizada no
Simulador RACbot, no entanto, a presença do robô num ambiente susceptível a muitos fenómenos
exteriores, leva a comportamentos imprevisíveis e por vezes, difíceis de corrigir. Como conclusões
tiramos:
v A necessidade de interligar o sistema de controlo com o sistema de visão é fundamental para
uma boa performance prestada pelo robô. O sistema de visão global terá de ser extremamente
rápido, só assim será possível controlar de forma eficaz os movimentos do robô;
v A calibração dos parâmetros do controlador PID de cada um dos eixos, torna-se essencial para
uma boa resposta dada pelos motores;
v O controlo dos motores do robô por posição usando odometria é bastante mais difícil de
implementar e mais susceptível a erros, do que o controlo por velocidade com realimentação de
posição pela câmara;
Página 100 de 119
v O sistema de controlo do robô deve privilegiar o movimento segundo a frente de ataque
analisada, onde as duas rodas laterais realizam tracção e a roda traseira apenas deve actuar
para mudança de direcção;
v O movimento omnidireccional do robô torna-se difícil de realizar sem a realimentação dos dados
de posicionamento do sistema de visão. Será necessário utilizar frequências de actualização
bastante altas e latências baixas.
v O seguimento de trajectórias complexas deve utilizar movimentos segundo as direcções que
minimizam o erro de posição de modo a minimizar desvios e erros de integração da posição;
v O procedimento de calibração não é possível de validar sem que as variáveis mais importantes
que afectam o movimento do robô (peso, aceleração, velocidade) sejam caracterizadas;
v O sistema de controlo do kicker funciona como esperado, no entanto, será necessário ligar o
circuito real, quando este estiver completamente desenvolvido, de modo a calibrar os tempos de
carga do condensador.
11.3. Perspectivas de Desenvolvimento Futuro
Dada a natureza do trabalho realizado no âmbito deste projecto, as perspectivas de
desenvolvimento que se apresentam são diversas. Em relação ao Sistema de Controlo implementado no
RACbot o seu desempenho será aumentado se forem abordados os seguintes pontos:
•
•
•
•
•
Extensão do sistema de controlo com maior capacidade de configuração dos parâmetros
utilizados;
Implementação de um logfile para analisar a execução de comandos recebidos;
Implementação de um algoritmo automático para calibração do robô;
Realização de um conjunto mais alargado de experiências utilizando o Sistema de Visão como
realimentação do Sistema de Controlo do robô, de modo a optimizar os parâmetros de controlo;
Calibrar os tempos de carga do condensador do circuito do kicker para diferentes forças de
chuto.
No que diz respeito à estrutura e plataforma do RACbot, apresentam-se como principais
perspectivas de desenvolvimento:
•
•
•
•
•
•
Optimizações ao nível do peso e da sua distribuição;
Análise de configurações de cinemática alternativas para optimizar o movimento do robô
segundo uma frente de ataque;
Analisar as limitações do softDMC e da H-bridge de controlo de motores de modo a aumentar a
potência fornecida pelos motores;
Aumentar a autonomia das baterias;
Conclusão e instalação do kicker;
Instalação de sensores de controlo de posição a bordo do robô.
Em relação ao Projecto RAC e aos seus objectivos existem diversas perspectivas e ideias para
desenvolvimento que podem levar ao crescimento do Projecto, tais como:
•
•
•
A inserção de mais Projectos de Final de Licenciatura no seio da RAC;
A criação do dia RAC, um dia que pode levar como objectivo a organização de varias visitas e
apresentações de vários Projectos relacionados com o Futebol Robótico;
O aumento da interacção entre os Projectos da RAC e o desenvolvimento de Trabalhos para
cadeiras da LEEC, LEI e LTIV;
Página 101 de 119
Conclusão
O objectivo principal do projecto RACmotion passou pelo estudo e desenvolvimento de um
sistema de controlo para os robôs omnidireccionais da RAC. No entanto, foi necessário fazer evolução
da plataforma e de toda a equipa de robôs, o que trouxe alguns acréscimos aos objectivos do projecto.
Neste contexto, as principais fases do trabalho desenvolvido incluíram:
v Estudo dos conceitos de Cinemática do robô e das diversas metodologias propostas pelos
orientadores;
v Projecto e implementação de um Simulador em MATLAB, de modo a compreender e analisar o
comportamento do robô num ambiente controlado;
v Analisar e desenvolver um método iterativo de calibração para o movimento do robô;
v Estudo e análise das diferentes abordagens de outras equipas a diversos problemas
emergentes ao futebol robótico e em particular a Small Size League;
v Construção mecânica de um protótipo, de modo a servir como base de ensaio e testes para o
desenvolvimento da plataforma de competição da RAC;
v Implementação de uma plataforma de desenvolvimento de aplicações de controlo;
v Implementação e configuração de um sistema operativo embebido num dispositivo do tipo
memória Flash que respeite os requisitos impostos;
v Desenvolvimento de um carregador de firmware em Linux para a FPGA da placa MESA 4i65;
v Implementação e configuração de um sistema de comunicação sem fios IEEE 802.11b para o
sistema operativo embebido;
v Desenvolvimento e implementação de um protocolo de comunicação sobre TCP/IP
(RACprotocol), que permita efectuar o controlo do robô a partir de um controlador centralizado
remoto;
v Implementação de uma aplicação de controlo a bordo do robô, de modo a executar os
comandos enviados pelo controlador centralizado;
v Implementação de controladores de velocidade, posição e trajectória a bordo do robô, usando
odometria e, esporadicamente, os dados de posição do sistema de visão global;
v Replicação da equipa de Futebol Robótico, em conjunto com os restantes membros da RAC.
v Promoção da RAC: Criação de uma Sessão de Palestras e Atelier de Robótica inserida no
Robótica 2005, desenvolvimento de um pequeno expositor de demonstração da RAC durante o
Robótica 2005.
v Elaboração de um artigo científico em colaboração com os orientadores do projecto,
denominado “RAC Robotic Soccer Small-Size Team: Omnidirectional Drive Modelling and Robot
Construction” apresentado no Encontro Científico do Robótica 2005;
O trabalho realizado e os objectivos conseguidos pelos membros do projecto RACmotion
ultrapassaram em número os objectivos iniciais. No entanto, não foram atingidos alguns dos objectivos
colocados à partida, aquando da proposta do projecto. Foi desenvolvido algum trabalho que não estava
inicialmente planeado, mas que era essencial para atingir os objectivos finais. O desenvolvimento de
uma plataforma base funcional tornou-se fundamental antes de se poder avançar para os objectivos
propostos. Ficaram por concluir algumas etapas ao nível de testes e integração dos diversos módulos
de controlo da arquitectura da RAC. No entanto, a colaboração dos membros do projecto RACmotion
não terminará com a avaliação dos júris na cadeira de Projecto.
Página 102 de 119
O desenvolvimento e o progresso do Projecto RACmotion levaram a diversas conclusões no que
respeita ao controlo do robô e à arquitectura adoptada. De um modo geral, é possível dizer que:
v O movimento totalmente omnidireccional na competição de futebol robótico da SSL, é utilizado
apenas em circunstâncias muito particulares. Normalmente são adoptadas arquitecturas com
frentes de ataque mais abertas, de modo a melhorar o movimento do robô e a sua aceleração
segundo uma direcção predefinida, colocando apenas a roda traseira como uma roda de efeito
de leme. O movimento do robô continua a ser omnidireccional, mas privilegia uma direcção
particular;
v O desenvolvimento de um Simulador tornou-se fundamental para o estudo e análise de
comportamento do robô. Foi possível analisar a influência de diversos factores como a presença
de desfasamentos, rotação e aceleração no movimento do robô. O Simulador também permitiu
testar o método iterativo de calibração implementado.
v A análise e desenvolvimento da estrutura mecânica do robô tornou-se fundamental. Uma
correcta distribuição e selecção do hardware é imprescindível, uma vez que diversos factores
como tamanho, peso e forma influenciam o movimento do robô;
v O Sistema Operativo que corre na plataforma deve ser bastante minimalista, mas por outro lado
bastante robusto para poder suportar uma arquitectura distribuída e habilitada a frequentes
actualizações. Os robôs tornam-se cada vez mais autónomos e para isso é fundamental adoptar
uma plataforma que permita a sua evolução;
v Em contrapartida, a evolução da plataforma pode levar à diminuição da sua autonomia e
aumento dos consumos e do peso, colocando em causa o seu comportamento e a escolha do
hardware;
v As equipas de Futebol Robótico estão cada vez mais susceptíveis a alterações e avanços
tecnológicos levados a cabo pela evolução das regras de jogo e pelo progresso dos níveis de
competição. A optimização do hardware e a implementação do software tornam-se assim
fundamentais.
v O Sistema de Controlo pode ser distribuído entre os robôs e um sistema centralizado. O controlo
a bordo dos robôs tem a vantagem de adquirir os dados de sensores locais muito rapidamente e
com baixa latência, por outro lado, o controlo centralizado e remoto, tem a capacidade de
efectuar um processamento pesado sobre uma grande quantidade de dados, como por
exemplo, o processamento dos dados obtidos pela câmara.
As dificuldades encontradas durante a realização do projecto resultaram da complexidade do
sistema que constitui o futebol robótico, ou seja, um ambiente bastante dinâmico com muitas variáveis
que necessitam ser equacionadas. A interligação com outros módulos, tais como, o controlador central e
a Visão, não foram possíveis de alcançar de modo a optimizar o sistema de controlo de movimento.
Encontrámos dificuldades ao nível do hardware, devido ao aparecimento de problemas, como a
aparente falta de potência dos motores que dificultaram a implementação dos algoritmos de controlo. A
definição de metodologias de coordenação entre grupos com tarefas diferentes, mas cooperantes,
implica sempre um domínio de técnicas de gestão de projecto avançadas, no caso da RAC, foi difícil de
alcançar uma coordenação perfeita.
O projecto RACmotion, foi um projecto ambicioso que envolveu diversas fases, tais como, o
planeamento, desenvolvimento e implementação. Como projecto inserido num contexto maior, onde
coexistiam outros projectos paralelos e cooperantes, constituiu uma parte fundamental, no sentido em
que a conjugação do esforço de muitas pessoas conduzirá certamente aos objectivos da RAC.
Em termos pessoais, a realização do projecto RACmotion foi bastante recompensadora.
Passámos por algumas dificuldades inerentes à complexidade do projecto, mas no geral sentimos que o
nosso esforço foi recompensado. A experiência adquirida na cadeira de Projecto certamente constitui
um alicerce para vida profissional, tanto ao nível técnico, como ao nível social.
Página 103 de 119
Referências e Bibliografia
ASADA, M.; KITANO, H. RoboCup-98: Robot Soccer World Cup II. Springer, 1999.
BARONE, D. Sociedades Artificiais: a Nova Fronteira da Inteligência nas Máquinas. Porto Alegre: Bookman, 2003.
BRAUNL, T. Embedded Robotics
Mobile Robot Design and Applications with Embedded Systems. Springer, 2003.
COSTA, A. GUARANÁ Robot-Soccer Team: some architectural issues. FIRA Robot World Cup France'98 Proceedings,
Federation of International Robot Soccer Association, 1998.
D’ANDREA, R. The Cornell robot soccer team. RoboCup-00: Robot Soccer World Cup IV, Lecture Notes in Computer Science.
Springer, 2001.
DIVERIO, T. A.; MENEZES, P. B. Teoria da Computação: Máquinas Universais e Computabilidade. Porto Alegre: Sagra
Luzzato, 1999.
GONZALEZ, R.; WOODS, R. Digital Image Processing. Addison-Wesley, 2002.
KITANO, H. RoboCup-97: Robot Soccer World Cup I. Springer, 1998.
KITANO, H.; ASADA M.; KUNIYOSHI Y.; NODA I.; OSAWA E. RoboCup: The Robot World Cup Initiative. Proceedings IJCAI-95
Workshop on Entertainment and AI/ALife, 1995.
MACKWORTH, A. K. On seeing robots. Singapore: World Scientific Press, 1993.
MARTINS, J.; ROCHA, R.; LOBO, J.; DIAS, J. RAC Robotic Soccer Small-Size Team: Control Architecture and Global Vision.
Actas do Encontro Científico do Festival Nacional de Robótica 2005, Coimbra, Portugal, 29 Abr. 2005.
PRADHAN, D. Fault-Tolerant System Design. New Jersey: Prentice Hall, 1996.
RICH, E. Inteligência Artificial. São Paulo: McGraw-Hill, 1988.
RODRIGUES, J.; BRANDAO, S.; LOBO, J.; ROCHA, R.; DIAS, J. RAC Robotic Soccer Small-Size Team: Onidirectional Drive
Modelling and Robot Construction. Actas do Encontro Científico do Festival Nacional de Robótica 2005, Coimbra, Portugal, 29
Abr. 2005.
RUSSEL, S.; NORVIG, P. Artificial Intelligence: A Modern Approach. New Jersey: Prentice Hall, 1995.
STEVENS, R. UNIX Network Programming. New Jersey: Prentice Hall, 1990.
TANENBAUM, A. S. Computer Networks. Prentice Hall, 1996.
TANENBAUM, A. S. Distributed Operating Systems. Prentice-Hall, 1995.
TURING, A. M. On Computable Numbers, with an application to the Entscheidungsproblem. London: Mathematical Society,
1936.
VELOSO, M. CMUnited-98: RoboCup-98 small-robot world champion team. AI Magazine, Spring 2000.
[CMDRAGONS] Equipa de Futebol Robótico, CMDRAGONS, USA, http://www.cs.cmu.edu/~robosoccer/small/
[CORNELL] Cornell RoboCup Lab, http://robocup.mae.cornell.edu/
[FIRA] FIRA - Federation of International Robot-soccer Association, http://www.fira.net/
[FUFIGHTERS] Equipa de Futebol Robótico, Fu-Fighters, Alemanha, http://robocup.mi.fu-berlin.de/
[IJCAI] International Joint Conference on Artificial Intelligence, http://www.ijcai.org/
[KAIST] Korea Advanced Institute of Science and Technology, http://www.kaist.edu/
[KTEAM] Informação sobre a K-Team, http://www.k-team.com/
[OSAKA] Osaka University, http://www.osaka-u.ac.jp/
[AIBO] Sony AIBO, http://www.us.aibo.com/
[SONYCSLAB] Sony Computer Science Laboratories, http://www.csl.sony.co.jp/
[RAC] Robótica Académica de Coimbra, http://www.deec.uc.pt/~rprocha/RAC/RAC.html
[RACMOTION] Informação sobre o Projecto RACmotion, http://alumni.deec.uc.pt/~brandao/racmotion/
[ROBOCUP] The RoboCup Federation, http://www.robocup.org/
Página 104 de 119
[ROGITEAM] Equipa de Futebol Robótico, ROGITEAM, Espanha, http://rogiteam.udg.es/
[5DPO] Equipa de Futebol Robótico, 5DPO, Portugal, http://paginas.fe.up.pt/~robosoc/
[PC/104] Informação sobre o PC/104, http://www.pc104.com/whatis.html
[M570] Informação sobre a placa M570, http://www.seco.it/schede_prod/M570-HTE01A.htm
[MESA] Informação sobre produtos MESA, http://www.mesanet.com/
[V104] Informação sobre a V104 Power Supply, http://www.tri-m.com/products/engineering/v104.html
[EDIMAX] Informação sobre produtos EDIMAX, http://www.edimax.com/
[FAULHABER] Informação sobre produtos FAULHABER, http://www.faulhaber-group.com/
[WIN] Informação sobre sistemas operativos Windows, http://www.microsoft.com/windows/default.mspx
[LINUX] Informação sobre o kernel Linux, http://www.kernel.org/
[UNIX] Informação sobre sistemas Unix, http://www.unix.com/
[MAC] Informação sobre produtos Macintosh, http://www.mac.com
[DISTRO] Informação sobre distribuições GNU/Linux, http://distrowatch.com/
[PUPPY] Informação sobre a distribuição Puppy Linux, http://www.goosee.com/puppy/
[ZyDAS] Informação sobre o chipset ZyDAS zd1201, http://www.zydas.com.tw/
[USB] Informação sobre o protocolo USB, http://www.usb.org/hom e
[GENTOO] Informação sobre a distribuição Gentoo, http://www.gentoo.org/
[DEBIAN] Informação sobre a distribuição Debian, http://www.debian.org/
[PYTHON] Informação sobre a linguagem de programação Python, http://www.python.org/
[GNU] Informação sobre o projecto GNU Not Unix, http://www.gnu.org/
[FSF] Informação sobre a Free Software Foundation, http://www.fsf.org/
[VIA] Informação sobre os produtos VIA, http://www.via.com.tw/en/index.jsp
[IEEE] Informação sobre o IEEE, http://www.ieee.org/portal/site
[IETF] Informação sobre o IETF, http://www.ietf.org/
[ISO] Informação sobre a ISO, http://www.iso.org/iso/en/ISOOnline.frontpage
[WIFI] Informação sobre a WIFI Alliance, http://www.wi-fi.org/OpenSection/index.asp
[DRIVER] Página do projecto do driver zd1201, http://linux-lc100020.sourceforge.net/
[SOFTDMC] Informação sobre o controlador de motores softDMC, http://www.mesanet.com/pdf/motion/softdmc.pdf
[DMCTUNE] Informação sobre o programa DMCtune, http://www.mesanet.com/pdf/motion/softdmc.pdf
[BORLAND] Informação sobre compiladores e ferramentas de desenvolvimento, http://www.borland.com/
[PCI] Informação sobre o barramento PCI, http://www.pcisig.com/home
Página 105 de 119
Anexo 1
Página 106 de 119
Reportagem
Diário As Beiras
21 Março 2005
Página 107 de 119
Reportagem
Diário As Beiras
1 Maio 2005
Página 108 de 119
Reportagem
Diário de Coimbra
1 Maio 2005
Página 109 de 119
Anexo 2
Página 110 de 119
Encontro Científico – Festival Nacional de Robótica 2005
Artigo Robótica2005
Omnidirectional Drive Modelling and Robot
Construction
Página 111 de 119
Página 112 de 119
Página 113 de 119
Página 114 de 119
Página 115 de 119
Página 116 de 119
Anexo 3
Página 117 de 119
Código Fonte das Aplicações Desenvolvidas
(...)
Página 118 de 119
Anotações
Página 119 de 119

RACmotion - DEEC - Universidade de Coimbra

Transcrição

Documentos relacionados

xbots

a era da cirurgia robótica no brasil hospital israelita albert

Regras para Corrida de Robôs - Blog das Exatas

FILMES SOBRE IA

Albert Einstein faz a primeira cirurgia robótica de baço da América

TDP M3R - Competição Brasileira de Robótica 2009

Soldagem robô DAIHEN OTC AII V6L 2012

visualizar

1 Exercícios de programação em TP no manipulador Fanuc

Artigo RoboParty