Atividade #695
FechadaObjetivo #623: Criar software para análise estatística dos jogos
Criar histograma de erro do chute
Adicionado por Lucas Germano mais de 6 anos atrás. Atualizado mais de 6 anos atrás.
Descrição
Fazer uma VI que plote um gráfico do (erro do chute previsto em relação ao que ele executou)x(número de chutes)
Arquivos
| picture299-1.png (1,18 KB) picture299-1.png | Lucas Germano, 26/04/2018 04:30 h | ||
| teste_ball_out.mp4 (7,94 MB) teste_ball_out.mp4 | Lucas Germano, 27/04/2018 06:27 h | ||
| picture404-1.png (3,42 KB) picture404-1.png | Lucas Germano, 27/04/2018 06:28 h | ||
| picture463-1.png (31,7 KB) picture463-1.png | Lucas Germano, 30/04/2018 04:07 h |
Atualizado por Lucas Germano há mais de 6 anos
- Arquivo picture299-1.png picture299-1.png adicionado
A VI do histograma de erro do chute foi criada e ela já está gerando o histograma com o número de chutes em função do erro. Funciona dessa maneira: o máximo erro permitido para o chute é 700mm, caso contrário irá ser considerado que algum fator externo desviou a bola, não propriamente que o robô errou o chute. Esse valor será divido em 14 intervalos, gerando intervalos de 50mm que representarão as células de um vetor. A 1ª célula representa quantas vezes o robô errou até uma distância de 50mm de onde ele queria chutar, a 2ª célula representa quantas vezes o robô errou em uma distância de 50mm-100mm de onde ele queria chutar e assim por diante.
Para uns poucos casos de teste o vetor ficou assim:
O que mostra que o robô no grSim, está errando os chutes por aproximadamente 90mm (para esse caso de teste rápido).
A VI "Y Goal Marker", que é a VI que diz quanto o robô erra do chute esperado em relação ao chute feito precisa ser ajeitada, pois nem sempre ela está detectando que a bola entrou no gol, que é o que caracteriza somar uma unidade à alguma célula no vetor.
Atualizado por Nicolas Oliveira há mais de 6 anos
Detalhar melhor esse erro na VI de kickerror. Esse histograma já está sendo plotado em um gráfico pra facilitar a visualização? O número de intervalos pode ser controlado, certo?
Atualizado por Lucas Germano há mais de 6 anos
Atualmente, para definir se foi gol ou não, verifica se ball_x > field_length/2 e se ball_x_anterior < field_length/2. As vezes, por algum motivo estranho, quando o robô chuta a bola e ela entra no gol, essa verificação não é validada e não é contado como um gol.
Ainda não está sendo plotado em um gráfico pq quero consertar os erros antes, mas isto é o de menos, dá para fazer rapidamente.
Sim, o número de intervalos está em um control.
Atualizado por Nicolas Oliveira há mais de 6 anos
Provavelmente deve ter um feedback node pra pegar o último x, se vc for nas propriedades tem como colocar um delay nele. Faz isso e vê se melhora.
Atualizado por Lucas Germano há mais de 6 anos
- Arquivo teste_ball_out.mp4 teste_ball_out.mp4 adicionado
- Arquivo picture404-1.png picture404-1.png adicionado
Acho que descobri o problema de a VI não estar detectando que a bola passou da linha do gol. Preste atenção aos probes 35 e 36, vamos olhar para o evento ball out enquanto um atacante chuta continuamente a bola para dentro do gol.
Dá pra perceber claramente que no probe 35 (antes do channel) aparecem bem mais ball out do que no probe 36. Isso se deve á quantidade de pacotes enviadas através do channel. Como a quantidade é muito alta, alguns pacotes serão perdidos, sendo que as vezes o pacote perdido é aquele que contém o evento ball out verdadeiro.
Existe alguma forma de não perder nenhum pacote ou driblar essa situação?
Atualizado por Nicolas Oliveira há mais de 6 anos
Tenta criar, como eu tinha dito pra fazer, um loop separado pra cada tipo de dado q desejamos gerar, principalmente separada do que gera o heatmap. A taxa que o channel manda é igual ao fps do loop que está recebendo. Naturalmente a VI do heatmap roda mais lentamente do que o resto do código, como é o desenho do campo na IA por exemplo.
Se vc colocar em loops separadas a taxa dessa VI deve ficar bem próxima da que recebe pacotes, ai assim, vc n vai perder tantos dados.
Mas bom trabalho descobrindo qual era o problema. Recomendo q vc coloque a VI de fps counter nesse loop pra ver q a taxa está mais lenta que 60fps.
Atualizado por Luciano Barreira há mais de 6 anos
Antes de tudo:
A thread de cima é realmente necessária ? Precisa paralelizar esse cálculo ? Ou seja, dá pra fazer o que você está fazendo dentro do mesmo "loop infinito" sem perda de performance e continuando a fazer sentido ? Se sim, eu sugiro que não abuse dos caninhos. Eles são necessários quando temos tarefas que podem ( e devem ) ser feitas de maneira paralela e que a perda de informações é tolerável ( por isso o nome do caninho é "Lossy Stream" ), como por exemplo o desenho do campo. Se perdermos um pacote de configuração do campo e só for desenhado o próximo pacote, praticamente não vai fazer diferença pra visualização.
Atualizado por Nicolas Oliveira há mais de 6 anos
Por isso acho q a VI de heatmap deve ser uma tarefa paralela, a perda de pacote nela é tolerável. E as outras VIs (q demandam menos processamento, mas n toleram perda de pacote) seriam outra thread.
Atualizado por Luciano Barreira há mais de 6 anos
Lucas Germano escreveu: não, verifica se ball_x > field_length/2 e se ball_x_anterior < field_length/2. As vezes, por algum motivo estranho, quando o >robô chuta a bola e ela entra no gol, essa verificação não é validada e não é contado como um gol.
Ainda não está sendo plotado em um gráfico pq quero consertar os erros antes, mas isto é o de menos, dá para fazer rapidamente.
Sim, o número de intervalos está em um control.
Outra coisa (isso independe de estar perdendo pacote ou não!!), não basta verificar a primeira condição ? Sugiro que se divida em dois eventos :
- Ricochete, quando a diferença bola_atual.x - bola_anterior.x troca de sinal
- Bola dentro do gol, quando bola_atual.x > field_length/2 e y entre -(tamanho_do_gol-espessura_do_gol)/2 e (tamanho_do_gol-espessura_do_gol)/2
O Ricochete serve pra definir se ouve interceptação da bola ou se ela bateu em alguma parede do campo
O segundo serve para definir se a bola está ou não dentro do gol.
Quando o primeiro ocorrer, verifica-se o segundo.
Um detalhe importante é que há a possibilidade do primeiro evento ser impreciso com ruído na bola.
Atualizado por Nicolas Oliveira há mais de 6 anos
Verdade, fica bem melhor assim.
Atualizado por Lucas Germano há mais de 6 anos
Ele também estava perdendo a informação que ball_x > field_length/2 pq a bola ficava pouco tempo nessa situação, também verifiquei essa ideia.
Atualizado por Lucas Germano há mais de 6 anos
Luciano Barreira escreveu:
Antes de tudo:
A thread de cima é realmente necessária ? Precisa paralelizar esse cálculo ? Ou seja, dá pra fazer o que você está fazendo dentro do mesmo "loop infinito" sem perda de performance e continuando a fazer sentido ? Se sim, eu sugiro que não abuse dos caninhos. Eles são necessários quando temos tarefas que podem ( e devem ) ser feitas de maneira paralela e que a perda de informações é tolerável ( por isso o nome do caninho é "Lossy Stream" ), como por exemplo o desenho do campo. Se perdermos um pacote de configuração do campo e só for desenhado o próximo pacote, praticamente não vai fazer diferença pra visualização.
Não entendi, oq vc está falando é pra trazer a VI do erro do chute pro while onde estava o probe 35?
Atualizado por Luciano Barreira há mais de 6 anos
Lucas Germano escreveu:
Luciano Barreira escreveu:
Antes de tudo:
A thread de cima é realmente necessária ? Precisa paralelizar esse cálculo ? Ou seja, dá pra fazer o que você está fazendo dentro do mesmo "loop infinito" sem perda de performance e continuando a fazer sentido ? Se sim, eu sugiro que não abuse dos caninhos. Eles são necessários quando temos tarefas que podem ( e devem ) ser feitas de maneira paralela e que a perda de informações é tolerável ( por isso o nome do caninho é "Lossy Stream" ), como por exemplo o desenho do campo. Se perdermos um pacote de configuração do campo e só for desenhado o próximo pacote, praticamente não vai fazer diferença pra visualização.
Não entendi, oq vc está falando é pra trazer a VI do erro do chute pro while onde estava o probe 35?
Sim, caso faça sentido.
Atualizado por Luciano Barreira há mais de 6 anos
- Versão ajustado para RoboCup 2018
Atualizado por Nicolas Oliveira há mais de 6 anos
- Versão excluído (
RoboCup 2018)
Não seria melhor n ter nenhuma VI estatística dentro do loop de recepção do pacote? Pra que agt possa sempre ver o contfps da recepção limpo?
Atualizado por Nicolas Oliveira há mais de 6 anos
- Versão ajustado para RoboCup 2018
Atualizado por Lucas Germano há mais de 6 anos
- Arquivo picture463-1.png picture463-1.png adicionado
- Situação alterado de Em andamento para Feedback
O problema da perda de pacotes foi resolvida fazendo um while a parte pro histograma, separando-o do heatmap.
Foi feito um teste com 100 chutes aleatórios em um campo sem goleiro, de acordo com as VI's de ball replacement e robot replacement feitas recentemente, o resultado foi plotado em um gráfico e ficou desta maneira:
Como já era esperado em um teste sem goleiro, a maior parte dos chutes ficou perto do erro mínimo, que é o que deve ser maximizado em qualquer situação.
OBS: Cada pico no gráfico representa um intervalo onde o erro de chute caiu. O gol, que possui 700mm, foi dividido em 20 intervalos, sendo que o primeiro pico representa os chutes que cairam no intervalo de erro de 0mm a 35mm, o segundo pico representa os chutes que cairam no intervalo de erro de 36mm a 70mm e assim por diante..
Atualizado por Nicolas Oliveira há mais de 6 anos
- Situação alterado de Feedback para Resolvida
Por mim ta ok. Vamos gerar um teste comparativo entre o nosso atacante na larc e o atual usando RRT.
Atualizado por Lucas Germano há mais de 6 anos
- Situação alterado de Resolvida para Fechada
O teste foi criado e está funcionando, falta testar o comparativo entre o atacante atual e o utilizado na LARC.