RoboCup
The Robot World Cup
Initiative
Daniela D. da S. Bagatini
Prof. Dr. Luis Otávio Campos Alvares
Sistemas Multiagentes e a
RoboCup
Desafio para SMA.
A RoboCup estimula a pesquisa na construção de
agentes avançados (comportamento inteligente).
Um Problema Padrão
• Plataforma para pesquisas:
–
–
–
–
agentes autônomos
colaboração de sistemas multiagentes
aquisição de estratégias de pesquisa em tempo real
entre outros.
Um Problema Padrão
• domínios específicos
• pesquisas de sistemas do mundo real
– exemplo: xadrez (ignora dificuldades)
Características
Xadrez
RoboCup
Meio ambiente
estático
dinâmico
Mudança de estado
turnos de tempos tempo real
Acessibilidade de
informações
completo
incompleto
Um Problema Padrão
• Lida com a complexidade do mundo real:
– comportamento reativo e cognitivo, aquisição de
estratégias, aprendizado, planejamento em tempo
real,
sistemas
multiagentes,
visão,
decisões
estratégicas, controle motor, controle de robôs
inteligentes, e muitas outras.
• Alto nível de competência para a realização de tarefas,
como chutar, interceptar.
• Colaboração em um problema dinâmico.
• Característica: promover pesquisas com a oportunidade de
demostrar resultados, na forma de competição em um
ambiente dinâmico.
RoboCup - The Robot World
Cup
“Reúne a necessidade de lidar com a complexidade
do mundo real criando robôs simulados que
demonstrem um alto nível de competência para a
realização de tarefas, como chutar , interceptar,
entre outros.” [KITANO]
Problema:
– Uma partida de futebol
Avaliação:
– Competição
97 Nagoya (IJCAI), 98 Paris (ICMAS), 99 Stockholm, 2000
Melborn, 2001 Seattle, ...
Objetivos
“Por volta do século 21, um time de robôs
humanóides autônomos deve enfrentar o time
campeão da copa do mundo conforme as
regulamentações da FIFA”. [ASA 99]
Conjunto de pequenos objetivos:
– avaliar os méritos da proposta de pesquisa usando tarefas padrões
de SMA:
• planos, conhecimentos, capacidades, emoções e outros.
– generalização da arquitetura para diversas outras aplicações.
O Desafio
• O trabalho em grupo é complexo;
• Domínios dinâmicos de sistemas multiagentes requer alta
flexibilidade de coordenação e comunicação para superar
as incertezas;
• Cumprir responsabilidades;
• Planejamento de coordenação em domínios com tantas
possibilidades de ação é uma tarefa complicada;
• O dinamismo do domínio causado pelas ações não
previstas do oponente torna a situação consideravelmente
mais complexa.
A Origem
• O Soccerserver (Noda, 1995) é realístico em alguns
aspectos:
• a visão do jogador é limitada;
• o jogador pode comunicar-se enviando recado;
• todos
os
jogadores
são
controlados
por
separados;
• cada jogador tem 10 companheiros e 11 oponentes;
• cada jogador tem energia limitada;
• ações e sensores têm ruídos;
• e o jogo ocorre em tempo real.
processos
A Origem
• Federação RoboCup: organização internacional, envolve
mais de 35 países e 150 universidades, institutos de
pesquisas nacionais e cooporações privadas.
• Idéia discutida em 1993.
Copa Mundial de Robôs
Local/Data
Times
Primeira
Nagoya, Japão, Agosto de 1997
+ 40
Segunda
Paris, Julho de 1998
+ 50
Terceira
Stockholm
+ 120
Hoje
Melbourne
+ 150
Amanhã
Seattle
• O mais extraordinário está no aprimoramento do jogo desde a
inauguração da copa mundial em 1997.
Análise da Estrutura
 Simulator League (Liga do Simulador)
 Small-size real robot league (Liga de Robôs Reais de
Pequeno Porte): O campo possui o mesmo tamanho e
a mesma cor de uma mesa de ping-pong e apresenta
cinco robôs por time, jogando uma partida com uma
bola de golfe.
 Midle-size real robot league (Liga de Robôs Reais de
Médio Porte): O campo é do tamanho e da cor de 3
mesas de ping-pong e apresenta cinco robôs por time,
utilizando a bola de Futsal-4.
O simulador Soccer Server
[NODA95]
Possibilidades Futuras
 Robôs para desenvolver tarefas perigosas.
 Robôs de pesquisa e Resgate.
 Futuros sistemas de transporte.
 Robôs de brinquedo.
 Robôs para socorrer idosos e deficientes.
 Robôs para trabalhar na indústria.
 Baterias de alta eficiência e uso de energia.
 Novos materiais e aparelhos.
 Evolução de Software.
 Vida Artificial.
O simulador Soccer Server
[NODA95]
• Problema padrão para SMA
–
–
–
–
desempenho
cooperação
aprendizado
habilidades do agente
• Características
Meio Ambiente
Dinâmico
Mudança
Tempo real
Acesso
Incompleto
Controle
Distribuído
 número limitado de informações
 envia mensagens pelo simulador
 considera aspectos físicos como:
inércia, energia, vento
 contém ruído
O Simulador da RoboCup
• O campo de futebol:
– objetos bidimensionais
– apresenta um campo virtual (soccer monitor)
– o tamanho do campo: regras de futebol humano
• comprimento é de 105m
• largura é de 68m
• largura do gol é dupla, sendo 14.64m
• jogadores e bola são representados como círculos
• Existem os seguintes objetos:
– objetos móveis (a bola e os jogadores) e
– objetos visíveis (gols, flags e linhas).
Características
 Sistema cliente-servidor
 Proporciona um campo virtual
 Um cliente é o cérebro do jogador em campo, e
controla as ações do jogador
 Sistema aberto: Clientes podem ser escritos por
algum sistema de programação que tem interface
UDP/IP.
 Múltipla plataforma. O SS roda em SunOS 4.1.x,
Solaris 2, DEC OSF/1, NEWS-OS, Linux e Irix 5.
Características
• Fatores randômicos na ação e restrições de desempenho
em seus sentidos.
• Não sabe a posição exata de muitos objetos distantes
(ruído)
• A incorreta sincronização: comportamento completamente
indesejado.
• Incerteza: Nem sempre os comandos enviados ao servidor
são executados. Nada garante que o efeito do comando
seja percebido.
• A informação enviada pelo simulador pode ser
inconsistente.
• Os movimentos dos jogadores não são tão seguros.
Comando: turn, kick
Características (cont.)
• Limite do sensor de informação: informação visual.
• As informações sobre os jogadores visualizados são
perdidas, quando as distâncias entre os objetos são
longas.
• Cada jogador possui uma certa energia (stamina).
• Colisões são também simplificadas
• Força negativa pode causar ao agente caminhar para
trás, causando o consumo de energia duas vezes mais.
• O servidor proporciona um canal de comunicação
(através de comandos say e hear), mas com capacidade
restrita.
A Partida
• A partida é basicamente controlada pelo módulo juiz.
• Faltas como obstrução, possibilita que um juiz humano
possa marcar.
• O módulo árbitro controla o jogo da seguinte forma:
 Gol
 Bola fora de campo
 Desobstrução
 Controle do modo de jogo
 Final do primeiro tempo e final de jogo
• O primeiro tempo: 5 minutos (3000 ciclos).
• O intervalo: 5 minutos, os competidores podem modificar
os programas clientes.
A Partida
• Cada partida pode assumir os seguinte estados:
• before_kick_off: jogo parado, aguardando início.
 time_over: final de jogo.
 play_on: quando a bola está em jogo.
 kick_off_l ou kick_off_r: saída de bola.
 kick_in_l ou kick_in_r: reposição de bola em jogo.
 free_kick_l ou free_kick_r: chute livre.
 corner_kick_l ou corner_kick_r: cobrança de escanteio.
 goal_kick_l ou goal_kick_r: cobrança de tiro de meta.
Comunicação cliente/servidor
percepção
Cliente
socket
ação
socket
Cliente
socket
Informações Sensoriais:
• see
• hear
• sense_body
Cliente
Comandos de Ação:
• kick
• dash
UDP
• turn
• turn_neck
• move
• catch
...
Comandos de Controle
 (move X Y)
 (turn Moment): -180 (minmoment) ~ 180 (maxmoment).
– Inércia: em sua velocidade máxima (1.0), o máximo de turn
efetivo que pode fazer é -30 ~ 30.
• (turn_neck Angle): –90 ~ 90. O ângulo da cabeça =
ângulo de visão.
• (dash Power): aceleração para a direção atual, -30 ~ 100.
– Power negativo = dash para trás (duas vezes energia).
• (say Message): mensagens num raio de 50m.
– caracteres do alfabeto, números e símbolos ("+-*/_"), com
tamanho máximo de 512 caracteres.
Comandos de Controle
•
(change_view Width Quality): narrow= 45, normal= 90, wide= 180 e a
qualidade pode ser low ou high.
– A informação visual depende do modo de visão utilizado

(catch Direction): agente goleiro
 A possibilidade: “catch_probability”
 Para pegar a bola: “goalie_cacthable_area”.
 Pode fazer um catch a cada catch_ban_cycle)
 Sucesso: modo free_kick, o goleiro pode se mover dentro da área de
pênalti junto com a bola.
•
O modelo de ação é discreto (movimentos ocorrem ao final do ciclo).
•
Os comandos podem não causar os efeitos esperados (física e ruídos).
•
A mensagem enviada está limitada ao tamanho máximo de 256 bytes.
•
O servidor aceitará apenas um comando de ação de cada cliente, em cada
ciclo de simulação.
Informações Sensoriais
• Um cliente possui três tipos de informações sensoriais: visuais,
auditivas e do próprio corpo.
• As informações visuais: informa a distância e o ângulo relativo aos
"pontos estacionários" aos jogadores (nome do time, número do
uniforme, distância e ângulo dos jogadores) e a bola (distância e
ângulo).
(see Time ObjInfo ObjInfo ...)
• No campo existem 55 "pontos estacionários”.
• O jogador pode também "ver" na visible_distance. Se o objeto está
nessa distância mas não no cone de visão, o jogador pode saber
somente o tipo do objeto (Player, Goal, Flag).
Posição Absoluta
Percepção
do mundo













Informações Sensoriais
• Toda comunicação entre clientes é feita pelo servidor: say.
• Informadas aos jogadores distantes até 50m.
• As informações auditivas: são mensagens assincronamente enviadas
por outros jogadores através do Soccerserver ou pelo próprio árbitro.
(hear Time Direction Message)
• Informação do corpo do jogador: sense_body.
(sense_body Time
(view_mode View_Quality ViewWidth)
(stamina Stamina Effort)
(speed AmountOfSpeed)
(head_angle HeadDirection)
(kick KickCount)
(dash DashCount)
(turn TurnCount)
(say SayCount)
(turn_neck TurnNeckCount))
Referências
•
KITANO, H. RoboCup: The Robot World Cup Initiative. In: International Joint
Conference on Artificial Intelligence (IJCAI’95), 14., 1995, Montreal. Proceedings...
Canada, 1995.
•
CORTEN, E; DORER, K; HEINTZ, F; KOSTIADIS, K; KUMMENEJE, J; MYRITZ, H;
NODA, Itsuki; RIEKKI, J; RILEY, P; STONE, Peter; YEAP, T. Soccer Server manual.
Technical report, RoboCup Federation, 1999. Disponível em
http://www.dsv.su.se/~johank/RoboCup/manual/ (10, junho de 2000).
•
NODA, Itsuki; MATSUBARA, Hitoshi. Soccer Server and Researches on Multi-Agent
Systems. In: International Conference on Intelligent Robots and Systems (IROS-96),
1996, Osaka. Proceedings... 1996.
•
STONE, Peter. The CMUnited-99 Simulator Team In: RoboCup-99: Robot Soccer
World Cup. Disponível em
http://www.ida.liu.se/ext/robocup/simul/CMUnited99/teampage.html (10, junho de
2000).
Um Sistema Multiagente
para o Simulador Soccer
Server
Daniela D. da S. Bagatini
Prof. Dr. Luis Otávio Campos Alvares
Clientes (times)
Arquitetura
• CMUnited
(desde 1996)
• AT Humboudt
(desde 1997)
• UFSC Team
(desde 1998)
• UFRGS
Híbrida
Característica
Layered Learning
Híbrida
BDI
Híbrida
Controles
difusos
Híbrida
“Subsunção”
A Arquitetura Proposta
Percepção variáveis de controle
do Mundo
Interface
de Entrada
Escolha
da Ação
simulador
Interface
de Saída
Agente
Informação Sensorial
Ação
Socket UDP
Modelo do Mundo
recv 2035: (see 14 ((goal r) 73 -7) ((flag r t) 84 -31)
((flag r b) 76.7 18) ((flag p r t) 63.4 -28) ((flag p r c)
56.8 -10) ((flag p r b) 56.8 10) ((player A) 13.2 40)
((ball) 22.2 -26 0 0) ((line r) 72.2 -90))
Parser
• Comando: see
...
• Bloco2: - Objeto: flag r t
- Time e Numero:null
- Distância: 84
- Direção: -31
• Bloco7: - Objeto: player
- Time: A
- Numero: null
- Distância: 13.2
- Direção: 40
Interface de Comunicação
Funções de envio:
String de envio montada
• init (TeamName, Goalie)
Comando parametros
• catch (Direction)
• change_view (Width, Quality)
• dash (Power)
• kick (Power, Direction)
• move (x, y)
Acesso ao socket UDP
Uso da função send(), envio
da mensagem através da
porta de comunicação.
• say (Message)
• sense_body()
• turn (Angle)
• turn_neck (Angle)
Servidor
Interface de Comunicação
Acesso ao socket UDP
String de recebimento bruta
Uso da função receive(), recebimento
da mensagem através da porta de
comunicação.
Interpretador de mensagens
Servidor
• Função receive() - duas opções: socket bloqueante ou não-bloqueante.
Processamento Concorrente
Recv
Thread de
Recebimento Buffer
Thread
Principal
Send
Buffer
Thread de
Envio
Timer
100ms
• Variáveis compartilhadas: RecvBuffer e SendBuffer.
• Timer na Thread de envio.
Processamento Paralelo
• Socket bloqueante para não perder processamento da
CPU.
• Sincronização entre as threads - MutEx.
• Thread bloqueadas esperando para acesso à memória.
• Envio de mais de um comando por ciclo - Soccer Server
aceita apenas um.
• Processamento principal deve ser o mais rápido
possível.
A Arquitetura Proposta
Percepção variáveis de controle
do Mundo
Interface
de Entrada
Escolha
da Ação
simulador
Interface
de Saída
Agente
Informação Sensorial
Ação
Socket UDP
A Arquitetura - Interface
Entrada/Saída
Interface
de Entrada
• Recebe percepção
• Controle das ações de saída
• Envia ação
• Previsão
Interface
de Saída
see
Cliente
dash
kick
100 ms
A Arquitetura - Percepção do
Mundo
Percepção
do Mundo
• Parser
• Modelo do Mundo
• Memória
• Variáveis de Controle
Tempo 2
Tempo 1
0 c) 17.6 12 -0 0)
Recebido : (see 341 ((goal r) 69.4 1)Tempo
((flag
((flag c t) 34.1 -61) ((flag
42.12 64) ((flag
r t) 75.9
-24) ((flag r b) 79.8 27)
Objeto1 c b)
Objeto
...
Objeto
n
((flag p r t) 55.1 -18) ((flag p r c) 53.5 2) ((flag p r b) 58.6 23)
Tipo:
Tipo:t l 10) 35.2 -80)
((flag g r t) 69.4 -3) Tipo:
((flag gTipo:
r b) 70.8
7) ((flag
Nome:
Nome:
Nome:
Nome:
Modelo
Mundo
((flag
t 0)do
38.5
-65) ((flag
r 10) 43.8
-53) ((flag
t r 20) 50.9 -44)
Distancia:t Distancia:
Distancia:
Distancia:
Direção:
Direção:
((flag2t r 30) 58.6 -38)
((flagDireção:
t r 40) 66.7
-33)Direção:
((flag t r 50) 75.2 -29)
...
...
...
...
((flag b1 l 10) 44.3 78) ((flag b 0) 46.5 66) ((flag b r 10) 51.4
56)
estou_desmarcado
0
((flag b r 20) 57.4 47) ((flag b r 30) 64.1 40) ((flag b r 40) 71.5 35)
((flag b r 50) 79.8 31) ((flag r t 30) 79 -20) ((flag
r t 20) 75.9
-13)
Atualizar
companheiro_perto_da_bola
((flag r t 10) 74.4 -6) ((flag r 0) 74.4 1) ((flag r b 10) 75.9 9)
variáveis
((flag r b 20) 78.3 16) ((flag r b 30) 82.3 22) ((ball) 73.7 -24)
companheiro_aproxima_da_bola
((player ufrgs 2) 16.4 42 -0 0.1 -42 -42) ((player ufrgs 3) 12.2
16 -0 0 -21 -21)
...
((player) 66.7 2) ((player) 66.7 -18) ((line r) 69.4 88))
A Arquitetura - Escolha da Ação
Escolha
da Ação
• Regras de decisão:
Conjunto de condição/ação
Arquitetura de subsunção
Chutar p/ posição
-
Chutar p/ comp. perto do gol
Chutar p/ comp. perto do gol desmarcado
SE  posso_chutar e  companheiro_perto_da_bola ENTÃO
comportamento( ir para a bola )
Enviado : (dash 80)
+
Escolha da ação: exemplo
Posso pegar a bola?
sim
não
Estou no ponto de
interseção?
pegar a bola
sim
não
girar para o ponto de
interseção
Estou na direção do
ponto de interseção?
sim
caminhar para o ponto
de interseção
não
girar para o ponto de
interseção
A Arquitetura - Um exemplo













Cond
ESCANTEIO e companheiro_perto_da_bola
Ação
comportamento( ir para a área do gol oponente )
Vantagens:
Comportamentos bem definidos (arquitetura de subsunção)
resultados eficientes
comportamento e cooperação emergente
Atacante
Objetivo: fazer gol
• Condição 1: posse de bola
– chutar à gol
– driblar (conduzir)
– passar a bola
• Condição 2:  posse de bola
–
–
–
–
ir para a bola (marcar e interceptar)
acompanhar ataque
posicionar estrategicamente
fugir da marcação
• Condição 3:  vê bola
– procurar a bola
Atacante
Condição 2:  posse de bola
– ir para a bola (marcar e interceptar)
– acompanhar ataque
– posicionar estrategicamente
– fugir da marcação
Regra 4
Cond
Ação
(vejo_a_bola) && (estou_marcado) &&
(bola_aproxima) &&
(não_meu_lado_de_campo)
fugir_da_marcação*
* modificar posição, não perder a visão da bola
Dificuldades
 Inconsistência
 informações sensoriais
 Incerteza
 comandos enviados X comandos executados
 informação de percepção
 Sincronização
 controle dos ciclos
 Documentação
 boa com relação a RoboCup e aos clientes
 difícil com relação ao Soccer Server (manual)