RoboCup The Robot World Cup Initiative

Apresentação em tema: "RoboCup The Robot World Cup Initiative"— Transcrição da apresentação:

1 RoboCup The Robot World Cup Initiative
Daniela D. da S. Bagatini Prof. Dr. Luis Otávio Campos Alvares

2 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.

3 Um Problema Padrão Características Xadrez RoboCup 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 completo incompleto informações Controle central distribuído

4 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.

5 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, ...

6 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.

7 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. Uma das maiores razões porque a RoboCup atrai tantas pesquisas está no fato de requer a integração de tecnologias dentro de um time completo de agentes.

8 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 processos 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. Várias complexidades do mundo real são asseguradas.

9 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 + 150 Melbourne Amanhã Seattle O mais extraordinário está no aprimoramento do jogo desde a inauguração da copa mundial em 1997.

10 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. Sony four legged league: Eles tem de coordenar todas as suas quatro pernas para levar a bola para dentro do gol. O robô Sony joga em um campo de carpete verde com declive.

11 O simulador Soccer Server [NODA95]

12 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.

13 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 considera aspectos físicos como: inércia, energia, vento número limitado de informações envia mensagens pelo simulador contém ruído

14 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).

15 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.

16 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

17 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.

18 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. O segundo tempo: 5 minutos. Prorrogação: tempo extra (até ocorrer um gol).

19 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. goal_l ou goal_r: ocorrência de um gol.

20 Comunicação cliente/servidor
percepção Cliente socket ação Cliente socket Cliente socket Informações Sensoriais: see hear sense_body Comandos de Ação: kick dash turn turn_neck move catch ... UDP

21 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. (kick Power Direction): -30 ~ 100, -180 ~ 180. Kickablearea Distância inicial.

22 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.

23 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).

24 Posição Absoluta Percepção do mundo             

25 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))

26 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, Disponível em (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 STONE, Peter. The CMUnited-99 Simulator Team In: RoboCup-99: Robot Soccer World Cup. Disponível em (10, junho de 2000).

27 Um Sistema Multiagente para o Simulador Soccer Server
Daniela D. da S. Bagatini Prof. Dr. Luis Otávio Campos Alvares

28 Clientes (times) CMUnited AT Humboudt UFSC Team UFRGS (desde 1996)
Arquitetura Característica CMUnited (desde 1996) AT Humboudt (desde 1997) UFSC Team (desde 1998) UFRGS Híbrida Layered Learning Híbrida BDI Controles difusos Híbrida Híbrida Híbrida “Subsunção” “Subsunção”

29 A Arquitetura Proposta
Agente Percepção do Mundo Escolha da Ação variáveis de controle simulador Interface de Entrada Interface de Saída Informação Sensorial Ação Socket UDP

30 Modelo do Mundo recv 2035: (see 14 ((goal r) 73 -7) ((flag r t) ) ((flag r b) ) ((flag p r t) ) ((flag p r c) ) ((flag p r b) ) ((player A) ) ((ball) ) ((line r) )) 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

31 Interface de Comunicação
Funções de envio: init (TeamName, Goalie) catch (Direction) change_view (Width, Quality) dash (Power) kick (Power, Direction) move (x, y) say (Message) sense_body() turn (Angle) turn_neck (Angle) String de envio montada Comando parametros Acesso ao socket UDP Uso da função send(), envio da mensagem através da porta de comunicação. Servidor

32 Interface de Comunicação
Acesso ao socket UDP Uso da função receive(), recebimento da mensagem através da porta de comunicação. String de recebimento bruta Interpretador de mensagens Servidor Função receive() - duas opções: socket bloqueante ou não-bloqueante.

33 Processamento Concorrente
Thread de Recebimento Recv Buffer Thread Principal Thread de Envio Send Buffer Timer 100ms Variáveis compartilhadas: RecvBuffer e SendBuffer. Timer na Thread de envio.

34 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.

35 A Arquitetura Proposta
Agente Percepção do Mundo Escolha da Ação variáveis de controle simulador Interface de Entrada Interface de Saída Informação Sensorial Ação Socket UDP

36 A Arquitetura - Interface Entrada/Saída
de Entrada Recebe percepção Controle das ações de saída Envia ação Previsão Interface de Saída see Cliente kick dash 100 ms

37 A Arquitetura - Percepção do Mundo
Parser Modelo do Mundo Memória Variáveis de Controle Tempo 2 Tempo 1 Recebido : (see 341 ((goal r) ) ((flag c) ) ((flag c t) ) ((flag c b) ) ((flag r t) ) ((flag r b) ) ((flag p r t) ) ((flag p r c) ) ((flag p r b) ) ((flag g r t) ) ((flag g r b) ) ((flag t l 10) ) ((flag t 0) ) ((flag t r 10) ) ((flag t r 20) ) ((flag t r 30) ) ((flag t r 40) ) ((flag t r 50) ) ((flag b l 10) ) ((flag b 0) ) ((flag b r 10) ) ((flag b r 20) ) ((flag b r 30) ) ((flag b r 40) ) ((flag b r 50) ) ((flag r t 30) ) ((flag r t 20) ) ((flag r t 10) ) ((flag r 0) ) ((flag r b 10) ) ((flag r b 20) ) ((flag r b 30) ) ((ball) ) ((player ufrgs 2) ) ((player ufrgs 3) ) ((player) ) ((player) ) ((line r) )) Objeto1 Objeto 2 Objeto n ... Tipo: Nome: Distancia: Direção: Tempo 0 Modelo do Mundo 2 1 estou_desmarcado companheiro_perto_da_bola companheiro_aproxima_da_bola ... Atualizar variáveis

38 A Arquitetura - 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 Enviado : (dash 80) SE  posso_chutar e  companheiro_perto_da_bola ENTÃO comportamento( ir para a bola )

39 Escolha da ação: exemplo
sim não Posso pegar a bola? pegar a bola Estou no ponto de interseção? girar para o ponto de interseção caminhar para o ponto de interseção Estou na direção do ponto de interseção?

40 A Arquitetura - Um exemplo
 Cond ESCANTEIO e companheiro_perto_da_bola comportamento( ir para a área do gol oponente ) Ação Vantagens: Comportamentos bem definidos (arquitetura de subsunção) resultados eficientes comportamento e cooperação emergente

41 Atacante Condição 1: posse de bola Condição 2:  posse de bola
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

42 Atacante Condição 2:  posse de bola fugir_da_marcação*
ir para a bola (marcar e interceptar) acompanhar ataque posicionar estrategicamente fugir da marcação (vejo_a_bola) && (estou_marcado) && (bola_aproxima) && (não_meu_lado_de_campo) Cond Ação * modificar posição, não perder a visão da bola Regra 4 fugir_da_marcação*

43 Dificuldades Inconsistência Incerteza Sincronização Documentação
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)