Futebol de Robos F180 » Inteligência

O Center Back é o comportamento que queremos implementar aos nossos 3 zagueiros e será baseado no Center Back da Equipe ER Force.
Atualmente, nossos zagueiros formam uma parede alinhada que tenta impedir os tiros diretos.

Nosso objetivo é fazer com que, a partir de agora, eles se comportem da seguinte maneira:

1-Contra equipes que realizem muitos passes:
-1 dos zagueiros tenta bloquear os chutes diretos.
-1 dos zagueiros fica à entrada da área marcando de longe o inimigo sem bola mais perigoso.
-1 dos zagueiros fica à entrada da área marcando de longe o segundo inimigo sem bola mais perigoso.

2-Contra equipes que realizem poucos passes ou que não realizem passes:
-2 dos zagueiros tentam bloquear os chutes diretos.
-1 dos zagueiros fica à entrada da área marcando de longe o inimigo sem bola mais perigoso.

Uma pergunta já levantada é: Como determinar se os times realizam muitos ou poucos passes.
Eu tinha pensado em podermos, através de um botão, alterar entre as duas formações de defesa. E a escolha de uma ou outra formação seria pautada em conhecimento prévio sobre a situação de passes da equipe adversária e/ou podendo ser alterada durante a partida nos tempos técnicos ou intervalos, de acordo com análise da partida.

Gabriel Borges da Conceição escreveu:

1-Contra equipes que realizem muitos passes:
-1 dos zagueiros tenta bloquear os chutes diretos.
-1 dos zagueiros fica à entrada da área marcando de longe o inimigo sem bola mais perigoso.
-1 dos zagueiros fica à entrada da área marcando de longe o segundo inimigo sem bola mais perigoso.

2-Contra equipes que realizem poucos passes ou que não realizem passes:
-2 dos zagueiros tentam bloquear os chutes diretos.
-1 dos zagueiros fica à entrada da área marcando de longe o inimigo sem bola mais perigoso.

Para equipes que não realizam passes ideal era usar nossa configuração atual. Então é bom que seja totalmente controlável por nós essas quantidades.

Uma pergunta já levantada é: Como determinar se os times realizam muitos ou poucos passes.
Eu tinha pensado em podermos, através de um botão, alterar entre as duas formações de defesa. E a escolha de uma ou outra formação seria pautada em conhecimento prévio sobre a situação de passes da equipe adversária e/ou podendo ser alterada durante a partida nos tempos técnicos ou intervalos, de acordo com análise da partida.

Podemos pensar em como nosso software estatístico poderia levantar essa informação.

A tarefa foi mais debatida no quesito organização dos zagueiros e seus papéis e foram definidas as seguintes formações defensivas no que diz respeito ao comportamento do 3 zagueiros:

Formação 1(Contra times que realizam passes):

Aqui ficou definido que montaremos uma barreia similar à atual, porém, com apenas 2 defensores(atuando então como Centers Back) e o terceiro irá atuar como ManMark. Esse ManMark é escolhido
a todo momento durante o jogo e é o jogador mais próximo àquele que queremos marcar. Então, há trocas a fim de determinar quem atuará como Center Back formando a barreia e quem atuará como ManMark em cada instante.
               A marcação é feita à distância: o zagueiro fica à entrada da área no alinhamento do inimigo que se quer marcar com o centro do gol. 
Definimos duas opções de marcação:

Formação 1.1: Aqui, marcamos o inimigo mais perigoso, sendo ele definido pelos critérios já utilizados anteriormente e explicitados na tarefa.
Formação 1.2: Aqui, marcamos o SEGUNDO inimigo mais perigoso, sendo ele definido pelos critérios já utilizados anteriormente e explicitados na tarefa.

Essas opções 1.1 e 1.2 foram pautadas na seguinte lógica: - O Striker já marca "corpo a corpo" o inimigo mais perigoso, podendo ele tentar interceptar o passe ou ficar atrás do adversário, bloqueando seu trajeto em direção ao gol. Então,
pode ser mais viável mandar o ManMark marcar o segundo inimigo mais perigoso porque assim teremos 2 inimigos sem bola sendo marcados ao invés de 1.

Isso pode ser determinado por fatores como: equipe inimiga ataca com 3 jogadores ou equipe inimiga só realiza passe para 1 jogador e etc.

Formação 2(Contra equipes que não realizam passes):

Para essa situação, chegamos à conclusão de que é melhor que se mantenha a defesa atual: - barreira bloqueando chute com 3 zagueiros, uma vez que não seria necessário marcar inimigo 
que não recebe a bola por passes.

Definidas as opções de sistemas defensivos, partimos para as implementações:

Implementação 1: Colocamos a opção de ser trocado o inimigo que o ManMark irá marcar(Mais perigoso ou segundo mais perigoso). Essa alternância é feita manualmente através de um Case Struct controlada por um Enum Control.

Implementação 2: Temos agora a opção de escolher entre a nova defesa proposta e a que já se usa para cada uma das seguintes situações de jogo: "Force Start", "PKA Normal Start", "PKE Normal Start", "Direct Free Ally", "Indirect Free Ally", "Ball Placement Ally", "None", Default, "Goal Enemy", "Ball Placement Enemy", "Stop", "Prepare Kickoff Ally", "Prepare Kickoff Enemy", "Direct Free Enemy", "Indirect Free Enemy", "Goal Ally", sendo alterada da mesma forma que a implementação 1.

Implementação 3: Linkamos o "atacando ao contrário" já existente em diversas partes do código de modo que os zagueiros considerem o Attacker e Striker do nosso time como adversários. Neste caso, só há a opção de marcar um jogador, que é o Striker, haja vista atacarmos com 2 jogadores.

Observação: Os dois jogadores que atuam como Centers Back fechando a barreira seguem o código estabelecido na VI da defesa que está sendo usada atualmente. A diferença é que esse código é, agora, mandado apenas para 2 robôs ao invés de 3. E foi tomado o cuidado de excluir do vetor "Defensores" o robô que atuará como ManMark, então a barreia fica fechada com 2 robôs.

Não seria legal criar uma aba chamada playbook? Lá ficarão nossas jogadas e formações, tenho o pressentimento que irão surgir mais implementações como essa, que usaremos contra equipes diferentes e de formas diferentes.

Tá ok!
Vou trabalhar nisso.

Deficiências encontradas na nova defesa proposta:

Os Centers Back se posicionam em ordem crescente de id. Então, quando os zagueiros saem de ordem seja para marcar um jogador ou para chutar a bola, ao volar, eles se esbarram prejudicando a formação defensiva.

O primeiro artifício pensado foi considerar os companheiros de equipe como obstáculos na movimentação RRT.
                     Vamos avaliar a melhor solução e partir para sua implementação.

Outro problema é a "indecisão" de qual robô vai chutar a bola. Acontece de às vezes um robô ir chutar, parar ao meio do caminho e outro ir para o chute.

Luciano Barreira escreveu:

Nicolas Oliveira escreveu:

Gabriel Borges da Conceição escreveu:

Os Centers Back se posicionam em ordem crescente de id. Então, quando os zagueiros saem de ordem seja para marcar um jogador ou para chutar a bola, ao volar, eles se esbarram prejudicando a formação defensiva.

Trabalhar agora em como tornar essa ordenação não dependente do id dos robôs, mas sim da proximidade com a posição desejada e se não há robôs no caminho. Por exemplo:


Apesar do robô mais acima ser próximo ao ponto de baixo da defesa, o ideal é q ele vá para o de cima para facilitar a aproximação do segundo defensor.

Algumas ideias:

Estou tentando pensar numa maneira de fazer isso sem quebrar com a nossa arquitetura atual, já que a definição de personalidade é decidida antes das velocidades de cada robô. Talvez pudéssemos pensar em abstrair os IDs da defesa (podemos melhorar isso):

- Os IDs abstraídos da defesa continuariam ordenados, e existiria um mapeamento direto entre o ID real do robô e o ID da defesa.
- A defesa define os pontos de marcação, com uma dada ordenação
- Os robôs da defesa terão um ID de acordo com a distância ao ponto mais próximo dentre os de marcação
- Podemos pensar em uma maneira de esta abordagem não gerar swaps desnecessários entre os robôs (trocarem de posição desnecessariamente)
- O número de pontos é atualizado dinamicamente pelo número de center-backs

Ou ainda algo como:

- A defesa define uma quantidade de pontos, ordenados por prioridade de perigo
- Pega-se os `n` primeiros pontos e distribui-se para os respectivos robôs mais próximos

`

Estava pensando se o software estatístico não consegue nos otimizar ainda mais essa questão :

- podemos revezar o esforço dos robôs de acordo com o quanto ele se movimentou durante a partida estando naquela posição de center-back, alternando a posição entre stops ou, se pensarmos em uma boa heurística, durante a própria partida.
- detectando deflecções bem sucedidas, podemos priorizar robôs que estão indo bem naquela posição para manter-se lá, já que não temos a garantia que os robôs são isométricos.
- a velocidade máxima e o tempo de resposta dos robôs, podendo ser medidos em tempo real pelo software estatístico, pode nos ajudar a priorizar posições mais dinâmicas.

Entendi a lógica. Após a reunião debatemos como implementar.

Qual era o intuito dos vídeos?

Luciano Barreira escreveu:

Estava pensando se o software estatístico não consegue nos otimizar ainda mais essa questão :

- podemos revezar o esforço dos robôs de acordo com o quanto ele se movimentou durante a partida estando naquela posição de center-back, alternando a posição entre stops ou, se pensarmos em uma boa heurística, durante a própria partida.
- detectando deflecções bem sucedidas, podemos priorizar robôs que estão indo bem naquela posição para manter-se lá, já que não temos a garantia que os robôs são isométricos.
- a velocidade máxima e o tempo de resposta dos robôs, podendo ser medidos em tempo real pelo software estatístico, pode nos ajudar a priorizar posições mais dinâmicas.

São boas ideias, vou colocá-las na tarefa do software estatístico.

Também não entendi muito bem o 2º e o 3º video, pode explicar melhor o que aconteceu?

Lucas Germano escreveu:

Também não entendi muito bem o 2º e o 3º video, pode explicar melhor o que aconteceu?

Esses são vídeos da atuação dos zagueiros.
No 1° vídeo (gravado do grSim), eu mostrei o posicionamento dos zagueiros quando a bola fica hora com um robô, hora com outro. Este posicionamento dinâmico está funcionando perfeitamente como determinado.

Os próximos vídeos (um gravado no grSim e outro na SSL vision log player), quis mostrar o comportamento dos zagueiros quando a bola é chutada, ou se aproxima da área e etc. Neles podemos ver as falhas ainda existentes: A toda hora fica trocando o robô que irá disputar a bola e robôs se esbarram quando tentam ir cada um pra sua posição.

Gabriel Borges da Conceição escreveu:

Luciano Barreira escreveu:

Nicolas Oliveira escreveu:

Gabriel Borges da Conceição escreveu:

Os Centers Back se posicionam em ordem crescente de id. Então, quando os zagueiros saem de ordem seja para marcar um jogador ou para chutar a bola, ao volar, eles se esbarram prejudicando a formação defensiva.

Trabalhar agora em como tornar essa ordenação não dependente do id dos robôs, mas sim da proximidade com a posição desejada e se não há robôs no caminho. Por exemplo:


Apesar do robô mais acima ser próximo ao ponto de baixo da defesa, o ideal é q ele vá para o de cima para facilitar a aproximação do segundo defensor.

Algumas ideias:

Estou tentando pensar numa maneira de fazer isso sem quebrar com a nossa arquitetura atual, já que a definição de personalidade é decidida antes das velocidades de cada robô. Talvez pudéssemos pensar em abstrair os IDs da defesa (podemos melhorar isso):

- Os IDs abstraídos da defesa continuariam ordenados, e existiria um mapeamento direto entre o ID real do robô e o ID da defesa.
- A defesa define os pontos de marcação, com uma dada ordenação
- Os robôs da defesa terão um ID de acordo com a distância ao ponto mais próximo dentre os de marcação
- Podemos pensar em uma maneira de esta abordagem não gerar swaps desnecessários entre os robôs (trocarem de posição desnecessariamente)
- O número de pontos é atualizado dinamicamente pelo número de center-backs

Ou ainda algo como:

- A defesa define uma quantidade de pontos, ordenados por prioridade de perigo
- Pega-se os `n` primeiros pontos e distribui-se para os respectivos robôs mais próximos

`

Estava pensando se o software estatístico não consegue nos otimizar ainda mais essa questão :

- podemos revezar o esforço dos robôs de acordo com o quanto ele se movimentou durante a partida estando naquela posição de center-back, alternando a posição entre stops ou, se pensarmos em uma boa heurística, durante a própria partida.
- detectando deflecções bem sucedidas, podemos priorizar robôs que estão indo bem naquela posição para manter-se lá, já que não temos a garantia que os robôs são isométricos.
- a velocidade máxima e o tempo de resposta dos robôs, podendo ser medidos em tempo real pelo software estatístico, pode nos ajudar a priorizar posições mais dinâmicas.

Entendi a lógica. Após a reunião debatemos como implementar.

Tive uma ideia mais simples a qual acho que pode resolver o problema de os robôs ficarem se esbarrando:
1-As 3 posições as quais os zagueiros devem ocupar são definidas.
2-Pegamos essas posições e as ordenamos em ordem crescente em função de sua coordenada y.
3-Pegamos os robôs e também os ordenamos em função de suas coordenadas y.
4-O robô de menor y deve ir para a posição de menor y e assim sucessivamente.
Dessa forma os robôs não se cruzarão.

Acho que ficará bom assim. Boa ideia.

Problemas resolvidos!

Como dito anteriormente, havia 2 problemas:

1: Robôs tentavam ficar em ordem crescente de id na barreia e ficavam se esbarrando até que cada um fosse para sua posição.
2: O código ficava trocando de duelist(zagueiro que sai para disputar a bola) indefinidamente, em função da escolha do manmark.

Foi feita um implementação que resolveu os problemas:

1 - Peguei as 3 posições que terão de ser ocupadas pelos 3 zagueiros(1 posição de manmark e 2 posições de barreira) e as coloquei num vetor de forma que ficassem ordenadas em ordem crescente de suas coodenadas y.

2- Coloquei os zagueiros num vetor e os ordenei da mesma maneira.

Dessa forma, o zagueiro da posição 0 desse vetor vai ocupar a posição 0 do primeiro vetor e assim sucessivamente. Ou seja, o robô de maior y vai para a posição de maior y e assim em diante, não ficando mais em função de sua ordem de id.

Pode-se perceber que o ManMark não é mais definido, necessariamente, pelo o zagueiro mais próximo do inimigo a ser marcado. Determinado zagueiro vai para a posição de ManMark de acordo com a escolha das posições explicada acima.

E, continuamos tirando o ManMark do vetor Defensores, de forma a não influenciar na determinação da posição dos dois robôs que ficaram na barreira.

O vídeo demonstrativo da atuação e posicionamento dos zagueiros será postado amanhã, devido a problemas de gravação no meu computador.

Os zagueiros ainda se posicionam segundo a área antiga.

Em breve, estarão se posicionando sobre área quadrada. Para isso, basta que sejam mudadas as interseções das retas que ligam (bola ou robôs inimigos)----(centro do gol) com a área. Além disso, os os vetores posições gerados deverão ser ordenados de maneira diferente, assim como os zagueiros.
Porém, todo o resto da lógica será aproveitado!

Bom! Os outros zagueiros já são capazes de andar numa área quadrada? Se sim, postar o resultado.
Coloque um tamanho de área maior, pode ser inserindo constantes mesmo. Mas que seja proporcional a área antiga para que possamos avaliar melhor o resultado.

Nicolas Oliveira escreveu:

Bom! Os outros zagueiros já são capazes de andar numa área quadrada? Se sim, postar o resultado.

Sim! Postarei agora.

Coloque um tamanho de área maior, pode ser inserindo constantes mesmo. Mas que seja proporcional a área antiga para que possamos avaliar melhor o resultado.

Fiz um teste com a área pequena na log player pra avaliar posicionamento e outro com valores de 1000mm e 2000mm.

Testamos a defesa no pc do lab e identificamos a necessidade dos seguintes ajustes:

1- Definir uma distancia mínima para o manmarker marcar alguém, caso n seja atingida, ficar na barreira
2- Deixar ter quantos defensores eu quiser. Atualmente só funciona para até 3 defensores.
3- Poder tirar o manmarker(usar defesa antiga).
4 -Usar a bola falsa para evitar que robo fique fora do campo.

Nicolas Oliveira escreveu:

Testamos a defesa no pc do lab e identificamos a necessidade dos seguintes ajustes:

1- Definir uma distancia mínima para o manmarker marcar alguém, caso n seja atingida, ficar na barreira
2- Deixar ter quantos defensores eu quiser. Atualmente só funciona para até 3 defensores.
3- Poder tirar o manmarker(usar defesa antiga).
4 -Usar a bola falsa para evitar que robo fique fora do campo.

Tudo feito! fotos e videos dos resultados serão postados amanhã.
Já está tudo atualizado na branch defense_rework.

Excelente. Tudo upado no github?
Se lembrou de levar em consideração se a quantidade de robôs era par ou ímpar na hora de posicionar a defesa?

Nicolas Oliveira escreveu:

Excelente. Tudo upado no github?
Se lembrou de levar em consideração se a quantidade de robôs era par ou ímpar na hora de posicionar a defesa?

Tudo upado! E usei sim a paridade do vetor Defensores para saber como somar ou subtrair da posição central.

Ao revisar o código, Nicolas percebeu a necessidade de mais dois ajustes:

1) A barreira estava abrindo um espaço grande em algumas situações de posicionamento na quina.
Solução: Percebi que não estava informando o índice para um Replace Subset em um dos casos. Feito isso, problema encerrado.

2) Quando a bola estava muito perto do fundo do campo, os zagueiros da barreira estavam se posicionando em cima da linha da área quadrada, e não um pouco à frente como deveria ser e como estava sendo nas demais situações de posicionamento.
Solução: Somente ajustei uma constante de um dos casos para 120 mm mais à frente e detalhe resolvido.

Vamos simular uma partida para ver a melhora da defesa.

Nicolas Oliveira escreveu:

Essa implementação n trata o caso em que a bola está, por exemplo, na lateral do robô inimigo mas perto deles, onde deveríamos sim chutar no gol. Existe uma VI chamada eventgenerator aqui:

Vou ajustar isso!


Nela o evento de posse é gerada. Porém o parâmetro que ajusta as distâncias se encontra no AI parameters, aqui na tela inicial:


Basta você tentar aumentar esses parâmetros com cuidado. Além disso lembre de definir esses valores como default. A uma parte da wiki fazendo uma descrição melhor dos eventos, leia.

Tá ok!