Defeito #379
FechadaMelhorar pontaria do chute
Adicionado por Nicolas Oliveira aproximadamente 7 anos atrás. Atualizado quase 7 anos atrás.
Descrição
Ao tentar realizar um passe o maior problema q estou encontrando é mesmo mirando no ponto certo (visualizando através dos debugs visuais) o passe quase sempre n acerta o robô. Talvez tenhamos q fazer algo estilo a OpAmp com uma aproximação para o passe bem lenta.
Arquivos
depois.wmv (7,17 MB) depois.wmv | Luciano Barreira, 22/10/2017 21:58 h | ||
antes.wmv (7,96 MB) antes.wmv | Luciano Barreira, 22/10/2017 21:58 h | ||
depois+striker.wmv (4,9 MB) depois+striker.wmv | Luciano Barreira, 22/10/2017 22:06 h | ||
picture539-1.png (810 Bytes) picture539-1.png | Luiz Renault Leite Rodrigues, 22/10/2017 23:03 h | ||
cone.png (2,13 KB) cone.png | Nicolas Oliveira, 22/10/2017 23:38 h | ||
cone-erro.png (3,19 KB) cone-erro.png | Luciano Barreira, 23/10/2017 00:23 h | ||
attck1.wmv (7,14 MB) attck1.wmv | Nicolas Oliveira, 24/10/2017 17:16 h | ||
attck2.wmv (13,2 MB) attck2.wmv | Nicolas Oliveira, 24/10/2017 17:16 h | ||
testecampo.mp4 (5,64 MB) testecampo.mp4 | Nicolas Oliveira, 24/10/2017 22:13 h | ||
Video_1508885409.mp4 (19,8 MB) Video_1508885409.mp4 | Nicolas Oliveira, 24/10/2017 22:57 h | ||
Video_1508942762.mp4 (13,2 MB) Video_1508942762.mp4 | Nicolas Oliveira, 25/10/2017 17:02 h | ||
NewAttacker.mp4 (9,6 MB) NewAttacker.mp4 | Nicolas Oliveira, 25/10/2017 23:11 h |
Atualizado por Luciano Barreira há aproximadamente 7 anos
Tentei fazer uma modificação simples no 'GoTo Tangent.vi' para o robô mirar para o target em vez da bola, e aparentemente a precisão de chute foi melhorada, pois há mais tempo para o robô alinhar com o target antes de chutar. Talvez seja interessante mantermos possibilidade de retornar facilmente à versão anterior por questões de predições inimigas (se nos alinharmos com o target o mais cedo possível, talvez o robô inimigo consiga antecipar uma defesa com maior facildade). Ainda não upei esta versão pois ainda estou experimentando outras sugestões.
Dentre elas, temos:
- Alinhamento com target como critério de chute
- Refino do offset do cone de chute (condição para entrar no estado gotoandkick)
- Consertar o erro de transição de estados que provoca oscilação entre estados gotoandkick e gototangent
Atualizado por Luiz Renault Leite Rodrigues há aproximadamente 7 anos
É sempre interessante tentar colocar um vídeo mostrando o antes e o depois.
Aquela modificação para o robô manter o alinhamento target-bola foi implementada? Estou me referindo ao controle lateral, ao invés de XY.
Atualizado por Luciano Barreira há aproximadamente 7 anos
- Arquivo antes.wmv antes.wmv adicionado
- Arquivo depois.wmv depois.wmv adicionado
- Arquivo depois+striker.wmv depois+striker.wmv adicionado
Cap, quando gravo a tela abaixa um pouco a performance, mas dá pra perceber um pouco a diferença.
Acredito que uma mudança significativa seria ao resolver as transições - o robô alterando de estado enquanto avança na bola . Esse problema ocorre quando o robô sai do cone de chute - condição para avançar na bola é estarem uma seção atrás da bola em relação ao ponto de chute - ao tentar se aproximar da bola - na tentativde de se controlar em direção à bola, em algum momento sai da condição de chute.
EDIT: (não consegui tirar o audio... tinha uma galera conversando na sala)
Atualizado por Luciano Barreira há aproximadamente 7 anos
- Data prevista ajustado para 28/10/2017
Atualizado por Luciano Barreira há aproximadamente 7 anos
- Situação alterado de Não Iniciada para Em andamento
Atualizado por Luiz Renault Leite Rodrigues há aproximadamente 7 anos
- Arquivo picture539-1.png picture539-1.png adicionado
Interessante.
Vocês estão usando um cone para determinar a condição de chutar a bola, certo?
Se for isso mesmo, o problema do cone (triângulo) é que à medida de se aproxima, o espaço é menor, podendo retirar o robô da área de chute.
Minha sugestão é usar um lugar geométrico que mantém sempre uma largura minima, equivalente à metade da área de chute. Como na figura.
Se o robô estiver com um pequeno desvio paralelo, a direção do chute não se altera. O que acham?
Atualizado por Nicolas Oliveira há aproximadamente 7 anos
O que eu tinha feito para melhorar isso foi q o a ponta do triângulo n está em cima da bola, mas sim um pouco a frente, sendo essa distância controlável. E na robocup tinha dado uma boa melhorada.
![](cone.png)
Atualizado por Luciano Barreira há aproximadamente 7 anos
- Arquivo cone-erro.png cone-erro.png adicionado
Um problema que eu reparei na abordagem da seção é que se o robô passar muito perto da bola durante o GoTo Tangent, ele pode passar pela área em vermelho e alterar de estado para GoTo and Kick:
![](cone-erro.png)
Atualizado por Nicolas Oliveira há aproximadamente 7 anos
Após teste com partida simulada contra a inteligencia versão robocup pude perceber que o alinhamento do robô fixo com o gol faz com q a movimentação do atacante seja mais lenta. Já que em diversas situações ele deverá mover-se de lado, e nossa movimentação é otimizada para frente.
Durante a partida perdemos algumas disputas de bola pois quando a equipe inimiga chutava n estávamos olhando para a bola o que retardava nossa reação ao comportamento de posse de bola inimiga.
Atualizado por Nicolas Oliveira há aproximadamente 7 anos
Luciano Barreira escreveu:
Um problema que eu reparei na abordagem da seção é que se o robô passar muito perto da bola durante o GoTo Tangent, ele pode passar pela área em vermelho e alterar de estado para GoTo and Kick:
![](cone-erro.png)
Realmente isso acontece em algumas situações, principalmente se a bola está exatamente atrás do robô. Talvez a abordagem que o Capitão sugeriu seja mais adequada.
Atualizado por Luciano Barreira há aproximadamente 7 anos
Tive uma ideia:
Podemos fazer o GoTo Tangent com um raio de proximidade da bola variável. Quando fora do critério de chute, o raio de proximidade mantém-se constante - como já ocorre - , e quanto mais se aproxima em termos de abertura ao ponto desejado, esta distância diminui, até que no alinhamento máximo o robô converge para a bola. É como se tivéssemos um relógio centrado na bola e as 3 horas apontando para o target; entre 7 e 11 horas, por exemplo, o raio de proximidade diminuísse linearmente com mínimo nas 9 horas, que é quando estaria alinhado com a bola e o target, e entre 11 e 7 horas este raio fosse constante.
Uma conseqüência imediata é que não precisaríamos de intervalos de ação, ou seja, o robô não precisaria parar em um ponto atrás da bola para depois avançar. Em contrapartida, não é tão rápido quanto um GoTo pois o ponto de destino se altera, portanto a saída do controlador do GoTo será de magnitude um pouco menor que uma solução otimizada.
O que acham?
Atualizado por Nicolas Oliveira há aproximadamente 7 anos
Acho a ideia válida. O melhor é implementá-la e realizar uma comparação com o desempenho antigo.
Isso deve ser bem significativo na questão de quando o robo sai do cone, atualmente, ele dá uma "ré" pra voltar a distância do gotoTagent, se essa distância tender pra bola agt pode contornar isso.
Acho q o principal tbm é saber o quão rápido essa distância deve reduzir com a aproximação a abertura correta.
Atualizado por Luiz Renault Leite Rodrigues há aproximadamente 7 anos
O que tem que alterar é que quando ele entra no modo de chute, ele não pode sair mais. Deve sim procurar corrigir o alinhamento lateralmente, com aquele modo de controle diferenciado para chute. E vai até chutar a bola. Mesmo se sair do cone.
Atualizado por Luciano Barreira há aproximadamente 7 anos
Qual seria o critério para sair do estado de chute? E se a bola for interceptada e o chute falhar?
Atualizado por Luiz Renault Leite Rodrigues há aproximadamente 7 anos
Quais são os eventos passíveis de ocorrer a partir do início do procedimento do chute?
Atualizado por Nicolas Oliveira há aproximadamente 7 anos
- Arquivo attck1.wmv attck1.wmv adicionado
- Arquivo attck2.wmv attck2.wmv adicionado
Foi implementado o novo cone sugerido pelo cap.
![](picture539-1.png)
Pude ver melhora significativa na questão de n trocarmos de estado repentinamente enquanto o robô se aproxima da bola, seguem os videos do desempenho.
Os overshots que são vistos nos vídeos se devem ao fato de quando reposiciono a bola pelo grsim e detectada pelo kalman uma variação na posição muito brusca, logo uma grande velocidade, podendo ser vista no segundo vídeo pela imagem do simulador, fazendo com q o robô n se comporte corretamente. Situação q será corrigida em breve.
Atualizado por Luiz Renault Leite Rodrigues há aproximadamente 7 anos
Achei que melhorou bastante mesmo. Consegue já testar com robô real?
Atualizado por Nicolas Oliveira há aproximadamente 7 anos
- Arquivo testecampo.mp4 testecampo.mp4 adicionado
Realizei um teste em campo e a transição entre os estados parece melhorar, porém o campo n ajudou muito os testes.
No grsim a melhora parace muito maior.
Atualizado por Nicolas Oliveira há aproximadamente 7 anos
- Arquivo Video_1508885409.mp4 Video_1508885409.mp4 adicionado
No grsim:
Atualizado por Nicolas Oliveira há aproximadamente 7 anos
- Arquivo Video_1508942762.mp4 Video_1508942762.mp4 adicionado
Luciano Barreira escreveu:
Tive uma ideia:
Podemos fazer o GoTo Tangent com um raio de proximidade da bola variável. Quando fora do critério de chute, o raio de proximidade mantém-se constante - como já ocorre - , e quanto mais se aproxima em termos de abertura ao ponto desejado, esta distância diminui, até que no alinhamento máximo o robô converge para a bola. É como se tivéssemos um relógio centrado na bola e as 3 horas apontando para o target; entre 7 e 11 horas, por exemplo, o raio de proximidade diminuísse linearmente com mínimo nas 9 horas, que é quando estaria alinhado com a bola e o target, e entre 11 e 7 horas este raio fosse constante.
Uma conseqüência imediata é que não precisaríamos de intervalos de ação, ou seja, o robô não precisaria parar em um ponto atrás da bola para depois avançar. Em contrapartida, não é tão rápido quanto um GoTo pois o ponto de destino se altera, portanto a saída do controlador do GoTo será de magnitude um pouco menor que uma solução otimizada.
O que acham?
Ideia implementada com melhoria significativa na movimentação e na transição de estados. Principalmente por n ser perceptível a alternância incorreta entre os estados de GoToTangent e GoToKick.
Segue video no simulador:
Atualizado por Nicolas Oliveira há aproximadamente 7 anos
- Arquivo NewAttacker.mp4 NewAttacker.mp4 adicionado
- Situação alterado de Em andamento para Feedback
Teste em campo:
*O feltro do campo está solto o q dificultou bastante os testes, e a força do chute está reduzida durante o teste.
Atualizado por Luciano Barreira há aproximadamente 7 anos
Feedback: =========
Ficou muito bom. Definitivamente estamos precisando de um campo maior (e melhor) para realizar testes.
Melhoramos muito desde a primeira iteração do atacante, acredito que só temos a refinar agora. Estamos conseguindo interceptar a bola em movimento em alguns casos, estamos mais perto que nunca do objetivo inicial dessa tarefa. Com a iteração resultante dos esforços dessa tarefa, fizemos 3 gols contra a inteligência antiga (versão RoboCup) em uma partida simulada por completo com direito a gol de passe (e levamos um gol contra, mas isso faz mais parte da melhoria da defesa que trataremos em seguida).
Como sabemos que estamos chutando com uma boa precisão ? Uma sugestão:
Podemos medir a precisão implementando um "marcador" de chute semelhante a ensaios de tiro:
- Assim que for dado chute (podemos usar o evento de toque) , armazenamos o valor do Best Y calculado para aquele chute;
- No momento que a bola ultrapassar a linha do gol a partir do lado dentro do campo, guardamos seu valor Y, fazemos a diferença com o best Y calculado e armazenamos o resultado.
- Resetamos o "marcador" e repetimos o ciclo.
Assim temos uma maneira de analisar quantitativamente se estamos acertando ou não com a precisão desejada.
No geral estou bem satisfeito com o progresso.
Alguns problemas que podemos considerar para melhorar o atacante em geral: ==========================================================================
- A aproximação da nova maneira, apesar de parecer mais precisa, está se dando um tanto lentamente. Podemos talvez alterar a função do raio do GoTo tangente para que convirja mais rapidamente para a bola.
- Em alguns momentos, ao tentar interceptar a bola, o robô a "atropela", o empurrando para fora do campo e, como vimos no teste de hoje, isso pode causar um gol contra.
- A resposta do nosso modelo a mudanças bruscas de direção da velocidade da bola (vide os ricocheteamentos em robôs inimigos ou na trave)
- Adicionar heurística de passe além dos estados de indirect e direct kick.
Atualizado por Nicolas Oliveira há aproximadamente 7 anos
Precisamos testar passes para validarmos a precisão do chute também, vamos poder ver também o quão rapidamente o chute a gol será executado após o passe.
Atualizado por Leonardo Gomes Goncalves há quase 7 anos
- Situação alterado de Feedback para Fechada
Fechamento de todas atividades passadas visando renovação para 2018 do redmine da inteligência.