Futebol de Robos F180 » Inteligência

Como eu disse na descrição, lembro que, de alguma versão do código novo pra cá, as estimativas pioraram consideravelmente. Na época, tentamos identificar o que estava causando isso e não conseguimos e acabamos não investigando mais devido a outras prioridades (até porque percebemos isso muito perto da competição).

Não tenho ainda como garantir que foi a partir da versão que separamos a leitura de pacotes, mas faz sentido ser. A diferença que isso causa é que o while Read UDP roda com fps igual ao recebimento de informações, pois tem uma VI que faz código ficar parado até chegar um pacote na porta. Já o while da visão não tem nenhum "bloqueio" de execução, seu fps depende apenas do seu processamento. Então, se não colocarmos nenhum wait, ele roda bem mais rápido (no grsim, na competição não). Nós criamos uma VI que leva em consideração os tempos de execução das últimas iterações dos dois whiles em questão e gera um valor que é levado a um wait no while da visão, com o intuito de forçar o while da visão a rodar menos que o Read UDP. Porém, isso não funciona tão efetivamente e o while da visão ainda continua rodando alguns FPS acima.

Com isso, o while da visão (e consequentemente todo o restante do código) trabalha com informações repetidas, pois pega pacotes repetidos. Sendo assim, a princípio, a estimativa tende a ficar ruim mesmo.

Mas como eu disse, não temos certeza de que é isso. Então o que temos que fazer é pensar numa maneira melhor de fazer o while da visão trabalhar apenas quando houver novo pacote e fazer um novo teste de estimativa.

O que eu fiz nesta tarefa me atentou para um detalhe.

Em resumo, o que estava causando piora tão significativa nas estimativas de velocidade era o fato de o while da visão estar processando pacotes repetidos e perdendo alguns.

Mas com 4 câmeras, não é toda vez que o while da visão vai processar 4 dados novos. No código anterior à separação do Read UDP, o while da visão rodava sempre com apenas 1 câmera nova (e sempre uma nova) e realizava todo o Kalman para as 4, o que é incorreto já que usava a mesma medição como se fosse nova.

Do jeito que está o código agora, o Kalman só é realizado para as câmeras novas. Mas agora também acho isso incorreto. O que acho que deve ser feito é realizar todo o Kalman para as câmeras novas (predição de atualização) e realizar apenas predição para as que não possuem informação nova.

Em resumo:

1- Com apenas uma câmera ligada no PIRF qualquer método de estimação de velocidades testado funciona sem ruídos.

2- Com mais de uma câmera ligada, só funciona sem ruído se estimarmos a velocidade antes da VI MediaCameras. Sendo que na RoboCup, começamos a usar o bloco de derivada do labview (método de tustin) na VI TeamAndSide, que fica depois do MediaCameras, mas como nessa competição havia apenas 1 câmera para todo o campo, não causava ruídos.

O que nós entendemos:

Sabemos que chega uma câmera por vez no código. Então considere a iteração que chega uma câmera que não tenha o robô 3, por exemplo. Esse robô continuará no código mas sua posição não será alterada. Então, se derivarmos a posição dele, estaremos causando um erro, já que não temos uma nova informação sobre sua posição e isso causa o ruído. Logicamente, isso só acontece quando tem mais de uma câmera.

Então, não podemos usar derivadas depois do MediaCameras pois não sabemos se determinado robô ou bola teve novo input de posição ou não, temos que derivar por câmera, ou seja, pra cada câmera derivamos apenas os robôs e bola que vêm nela.

Só relembrando que nesta tarefa não estamos entrando no mérito se os estimadores que estamos testando estão condizendo com a realidade ou não (isso será feito na tarefa http://redmine.roboime.com.br/issues/1230). Aqui focamos apenas em identificar o que estava causando o excessivo ruído na estimação.

Sabemos que chega uma câmera por vez no código. Então considere a iteração que chega uma câmera que não tenha o robô 3, por exemplo. Esse robô continuará no código mas sua posição não será alterada. Então, se derivarmos a posição dele, estaremos causando um erro, já que não temos uma nova informação sobre sua posição e isso causa o ruído. Logicamente, isso só acontece com mais de uma câmera.

Então, não podemos usar derivadas depois do MediaCameras pois não sabemos se determinado robô ou bola teve novo input de velocidade ou não, temos que derivar por câmera, ou seja, pra cada câmera derivamos apenas os robôs e bola que vêm nela.

Concordo com o dito acima, pra mim esse é o problema, já tinha levantado essa hipótese algumas vezes mas nunca ataquei o problema.

Como conclusão desta tarefa temos que:

1- Código da dev processa pacotes repetidos e isso causa ruído. Foi resolvido com http://redmine.roboime.com.br/issues/1223 (lembrando que a solução dada no link ainda precisa ser melhorada).

2- Temos que estimar por câmera e não por elemento depois do MediaCameras.

Identificados e consertados esses dois erros, a estimação de velocidades voltou a ficar normal, ou seja, sem presença absurda de ruído.

Vamos partir agora para estudo e implementação do novo estimador/ melhoria do atual.

Seria uma boa estudar como o autoref faz o cálculo da velocidade da bola em azul. Esse gráfico em verde, se não me engano, detecta grandes variações na velocidade da bola. Eles usam esse gráfico em verde junto a velocidade estimada da bola para calcular uma velocidade mais real. (Isso são só suposições do que eu me lembro do pessoal da Tigers falando na competição)

O estimador do autoref é talvez o mais preciso da competição, caso queiramos melhorar o estimador é uma boa estudar como eles fazem isso.

Existem também outros autorefs, como o da ER-Force. Geralmente eles são usados em conjunto na competição, de tal forma que se chegue num consenso. Mas pra começar, podemos ficar com o da Tigers (caso achem documentação é o bizu, caso não achem tentem procurar o código fonte e fazer uma engenharia reversa).

Lucas Germano escreveu:

Seria uma boa estudar como o autoref faz o cálculo da velocidade da bola em azul. Esse gráfico em verde, se não me engano, detecta grandes variações na velocidade da bola. Eles usam esse gráfico em verde junto a velocidade estimada da bola para calcular uma velocidade mais real. (Isso são só suposições do que eu me lembro do pessoal da Tigers falando na competição)

O estimador do autoref é talvez o mais preciso da competição, caso queiramos melhorar o estimador é uma boa estudar como eles fazem isso.

Existem também outros autorefs, como o da ER-Force. Geralmente eles são usados em conjunto na competição, de tal forma que se chegue num consenso. Mas pra começar, podemos ficar com o da Tigers (caso achem documentação é o bizu, caso não achem tentem procurar o código fonte e fazer uma engenharia reversa).

Sim, realmente tem uma documentação explicando como eles fazem essa filtragem para ter uma melhor estimativa. Está nos nossos planos estudar isso.

Lucas Germano escreveu:

Seria uma boa estudar como o autoref faz o cálculo da velocidade da bola em azul. Esse gráfico em verde, se não me engano, detecta grandes variações na velocidade da bola. Eles usam esse gráfico em verde junto a velocidade estimada da bola para calcular uma velocidade mais real. (Isso são só suposições do que eu me lembro do pessoal da Tigers falando na competição)

O estimador do autoref é talvez o mais preciso da competição, caso queiramos melhorar o estimador é uma boa estudar como eles fazem isso.

Existem também outros autorefs, como o da ER-Force. Geralmente eles são usados em conjunto na competição, de tal forma que se chegue num consenso. Mas pra começar, podemos ficar com o da Tigers (caso achem documentação é o bizu, caso não achem tentem procurar o código fonte e fazer uma engenharia reversa).

Gabriel Borges escreveu:

Vamos partir agora para estudo e implementação do novo estimador/ melhoria do atual.

Acho q o primeiro passo seria realmente oq o germano falou, isso já era uma ideia nossa a algum tempo. Dê prosseguimento nesse sentido. Mas essa tarefa aqui acho q ta ok já. Muito bom. Colocar na wiki como ficou organizada essa estimação!

Okay, então vou fechar essa tarefa.