Atividade #695
FechadaObjetivo #623: Criar software para análise estatística dos jogos
Criar histograma de erro do chute
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
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.