Projeto

Geral

Perfil

Ações

Atividade #1232

Fechada

Fazer código de teste para analisar delay do código

Adicionado por Gabriel Borges da Conceição mais de 4 anos atrás. Atualizado aproximadamente 2 anos atrás.

Situação:
Fechada
Prioridade:
Normal
Atribuído para:
Início:
21/02/2020
Data prevista:
28/02/2020

Descrição

Para melhorar a proporção entre as frequências de processamento de cada câmera, foi criada uma branch readudp na qual a decodificação dos pacotes foi passada para o while Read UDP para podermos identificar qual câmera está chegando e escrever na referência dela (tarefa http://redmine.roboime.com.br/issues/1223).

Em teste no PIRF, percebemos delay na nossa visão e esta tarefa destina-se a montar um código que nos permita analisar esse delay.

Analisando sua possível ocorrência, posteriormente será criada tarefa para solução do problema


Arquivos

picture656-1.png (12,4 KB) picture656-1.png Lucas Germano, 27/02/2020 12:49 h
picture668-1.png (27,3 KB) picture668-1.png Lucas Germano, 02/03/2020 18:03 h
Ações #1

Atualizado por Gabriel Borges da Conceiçãomais de 4 anos

Deve ser criada branch a partir da readudp.

Ações #2

Atualizado por Lucas Germanomais de 4 anos

A branch criada para essa tarefa foi a: vision_delay_analysis

Vamos analisar a seguinte imagem que representa uma screenshot de onde os pacotes da visão estão em algum momemnto do código:

![](picture656-1.png)

Já nessa imagem é possível verificar dois problemas:

Problema 1: O atraso no recebimento dos pacotes pode acarretar uma sobrecarga no buffer UDP do Windows, esse buffer não temos conhecimento ao certo de como ele funciona. Mas ele pode acarretar principalmente um delay no tempo dos pacotes que estão sendo processados e o que está acontecendo realmente em campo. Além disso, uma crescente sobrecarga desse buffer pode significar uma perda de memória contínua, ou seja, um memory leak.

Problema 2: Como no nosso código escrevemos na referência do Game sempre que possível, para atualizar a referência com o dado mais atual, podemos estar processando dados diferentes em partes sequenciais do código, que não é o certo. Teríamos que ter, um mesmo pacote sendo processado na parte 1, parte 2 e na parte 3, quando esse pacote terminasse o processamento na AI, aí sim deveríamos atualizar a referência com outro pacote.

Ações #3

Atualizado por Lucas Germanomais de 4 anos

Minha primeira ideia para analisar esse problema é fazer um gráfico da diferença entre o tempo que o pacote é recebido pelo computador da intel e o tempo que o pacote é enviado pela visão, assim saberemos se existe um delay no recebimento de pacotes pelo LabView, sendo ele ocasionado por qualquer fonte. Segue na imagem uma explicação maior:

![](picture668-1.png)

Ações #4

Atualizado por Gabriel Borges da Conceiçãomais de 4 anos

Lembrando que no pacote da câmera também vem o t_capture, que é o tempo em que a imagem foi pega pela câmera e isso também poderia ajudar na sua análise de alguma forma.

Pelos testes de frequência de processamento de câmeras que fizemos no PIRF, (na tarefa http://redmine.roboime.com.br/issues/1223), percebemos que a câmera 1 estava sendo enviada pelo ssl-vision com menos frequência que as outras, por exemplo.

E também vale lembrar que idealmente o timestamp dos robôs e bola que usamos no Kalman, por exemplo, deveria ser o t_capture da câmera e atualmente estamos usando o tempo em que o pacote é recebido pelo nosso código e isso pode causar interferências se tr1-tr2 não for igual a t_capture1 - t_capture2.

Ações #5

Atualizado por Lucas Germanomais de 4 anos

Eu e o Viana fomos no PIRF na quarta-feira para testar o código que eu fiz, porém algumas coisas deram errado:
- Teste na branch nova que o gabriel criou: essa branch tinha um delay absurdo, antes mesmo de eu colocar meu código, então essa branch vai ser descontinuada por motivos de que não vale a pena tentar achar o problema, é melhor criar uma branch nova

- Teste na branch dev que está funcionando: não tínhamos robôs suficientes para gerar um delay perceptivo (inclusive pelo código), assim sendo só poderíamos/perceberíamos algum delay quando tivessemos perto de 12 robôs no campo. No teste feito no PIRF só tinha 1 funcionando e 3 tampas no chão, o que não gerou delay significativo.

Para minha próxima tarefa vou fazer uma branch que tentará resolver os problemas de delay que estamos tendo atualmente, focando nos principais problemas atuais: delay no código e receber umas câmeras mais que as outras. Essa tarefa será feita com o input que tivemos da reunião com o major na última sexta.

Ações #6

Atualizado por Gabriel Borges da Conceiçãomais de 4 anos

Ver o que acabei de escrever na tarefa http://redmine.roboime.com.br/issues/1223

Encontrei um erro grave que possivelmente é o causador do problema.

Ações #7

Atualizado por Lucas Germanoaproximadamente 2 anos

  • Situação alterado de Em andamento para Fechada
Ações

Exportar para Atom PDF