Futebol de Robos F180 » Inteligência

O efeito que isso teria é que no while Read UDP, além de receber o pacote da rede, ele seria decodificado, o que produz maior tempo de execução do while. Mas acredito que esse processamento a mais não deva causar atrasos e nem chegada de pacotes sem que possam ser lidos imediatamente, pois decodificar os pacotes não é uma tarefa custosa. Mas só testando no PIRF pra saber.

Já comecei a implementação!

Percebi que no Cluster Detection Frame já tem um atributo frame number, então não vou precisar criar nada relacionado à identificação dos frames, como tinha dito (sequence number).

Já terminei a implementação descrita, vou postar o que foi feito e aguardar feedback de possíveis erros, sugestões de melhoria de implementação etc.

Mudanças no while da visão:

Agora, antes de entrar no método que contém o Kalman, tem um método "getCurrentCameras". Essa VI lê as 4 referências de câmeras e de field size e analisa quais câmeras já foram pegas pela visão anteriormente, como pode ser visto abaixo:


Há um vetor de inteiros que armazena o último frame_number pego pela visão de cada câmera. Verifiquei e, pelo menos no grSim, o primeiro frame_number é 0. Por isso, inicializei o vetor com [-1,-1,-1,-1].

Para cada uma das 4 câmeras pegas da referência verificamos se o frame_number já foi pego pela visão. Ou seja, pode ser que entre a iteração de while de visão passada e essa de agora, alguma referência não tenha dado novo, então não precisamos pegar esse dado novamente pois já está no nosso vetor de câmeras com Kalman já aplicado (esse vetor fica na parte do Kalman).

Caso esse frame_number ainda não tenha sido pego, adicionamos ele ao vetor e o atributo New é setado como True (o default é False). Eu criei esse atributo no cluster para sabermos se aplicamos o Kalman a essa câmera ou não. Pois nosso vetor de câmeras que entra na VI do Kalman tem câmeras repetidas (a menos que a gente pegue da referência 4 câmeras novas na VI getCurrentCameras). Além disso, atualizamos o último frame_number dessa câmera no vetor.

Outra diferença é que no método receiveDecodeAndDoKalman agora tem só o Kalman. A parte de recebimento de pacotes foi tirada daqui quando criamos o while Read UDP e agora, nesta tarefa, também tirei a decodificação. O nome desse método será mudado posteriormente.


Também foi necessária modificação na VI Update Frame Array (VI branca logo depois do cluster NewCameras das fotos acima):


Antes, essa VI atualizava no vetor de 4 câmeras a câmera que estava chegando. Mas, como agora podem chegar de 0 a 4 câmeras novas, coloquei um loop em volta da VI que atualiza os dados da câmera nova.

Conversando com o Leo, ele mencionou dois detalhes:

Pode ser que não tenha nada escrito na referência de determinada câmera ainda (acontece nas primeiras iterações). Tenho que tratar isso ainda.

Além disso, ele também sugeriu analisar analisar se, na VI getCurretCameras, vale a pena fazer a análise de forma paralela e não iterativa. Isso por causa de complexidade computacional, tempo de execução; esses cluesters de câmera são pesados.

Tudo feito até agora está atualizado na branch readudp.

Pensei em duas coisas para os casos de referência sem nada escrito.

Uma delas foi escrever vetor de uma câmera na referência porque dessa forma, quando formos ler da referência no getCurrentCameras, basta conferir se é um empty array.

Outra coisa que pensei foi criar uma flag como atributo das câmeras e setar para True quando for escrever na referência (default False) e verificar essa flag quando for pegar da referência.

Vou analisar o que é melhor.

Testamos o que foi feito nesta tarefa com um robô fazendo zigzag no PIRF e já causou delay visível. Então, com a ajuda da tarefa http://redmine.roboime.com.br/issues/1232 vamos analisar esse delay e propôr nova solução.

ok

Em qual tarefa ficou o problema que essa implementação causou (lentidão na leitura dos pacotes)?

Essa branch resultou num delay absurdo no código, cerca de 10 a 15 segundos de delay do que estava se passando no campo e o que estávamos vendo na tela. Vou tentar achar o erro de implementação, mas a princípio não vou perder muito tempo com isso para tentar criar uma branch nova de uma forma mais organizada (montando diagramas etc) para não termos que refazer essa tarefa mais uma vez.

O ideal seria fazer o teste no grsim de 4 cameras, pra evitar uma viagem perdida ao pirf

Outro fator pra não ter percebido antes foi que no meu PC aparentemente nada de errado acontecia, mas o Antonio me avisou sobre problemas de processamento com o PC dele, então fiz os testes no PC da Intel e pude identificar o problema.

Famoso pc da xuxa.

Mas assim, esse loop n deveria acontecer apenas quando algo chegasse na porta serial? Isso n já garantia que o problema descrito n fosse acontecer?
O fato de ser referência q ta causando isso né?

Nicolas Oliveira escreveu:

Outro fator pra não ter percebido antes foi que no meu PC aparentemente nada de errado acontecia, mas o Antonio me avisou sobre problemas de processamento com o PC dele, então fiz os testes no PC da Intel e pude identificar o problema.

Famoso pc da xuxa.

Mas assim, esse loop n deveria acontecer apenas quando algo chegasse na porta serial? Isso n já garantia que o problema descrito n fosse acontecer?
O fato de ser referência q ta causando isso né?

A VI de recebimento de pacotes da câmera pela porta serial está em outro while junto com a decodificação (while readUDP). While esse que escreve cada câmera que chega (decodificada) em sua respectiva referência.

Essa última foto que coloquei na tarefa é do while da visão (que faz o kalman e etc). Essa VI getCurrentCameras lê as 4 referências e, baseado no frame number das câmeras, analisa quais das 4 referências têm dados novos (pode ir de 0 a 4). O que sai dessa VI getCurrentCameras é um vetor com as câmeras novas (pode ir de 0 a 4). O resto do while da visão a gente só roda se esse vetor não for vazio (ou seja, se tiver chegado pelo menos câmera nova desde a última vez que esse while rodou).

Então essa parte de fazer Kalman e etc rodava só quando chegava dado novo (por consequência rodava praticamente à mesma taxa de recebimento de pacotes), mas essa VI getCurrentCameras rodava indefinidamente (a única coisa que trava seu processamento é qunado chega dado novo e ela tem que esperar o resto while terminar de ser executado). Mas enquanto não chegava nada novo, esse while inteiro tinha só essa VI executando e rodava a 2000fps, daí comprometia o funcionamento dos outros whiles e fazia, por exemplo, o while readUDP (de recebimento de pacotes da porta serial) rodar muito mais devagar do que deveria (devido ao processamento do pc estar sugado por esse while da visão que rodava indefinidamente a getCurrentCameras) e consequentemente acumulava pacotes. A solução que eu dei foi colocar um Wait pra fazer essa o while da visão rodar a 300 fps (porque com essa taxa, teoricamente, a VI getCurrentCameras sempre vai conseguir pegar as câmeras atualizadas (sem deixar passar nenhuma), seja no campo ou no grsim. Mas lembrando que a parte do while que tem o Kalman está dentro do um case e não roda todas as iterações e seu fps fica muito justo à taxa de recebimento de pacotes.

E sim, por usarmos a referência, tivemos que criar essa VI getCurrentCameras e analisar "na mão" quando tem um dado novo em cada referência ou não. O ideal seria usarmos outra estrutura (como a fila de substituição sugerida pelo major).

Não comentei no texto acima, mas o while readUDP, além de 4 referências para câmeras, também tem uma referência para escrever o Field Size decodificado. E a VI getCurrentCameras no while da visão também, além de ler 4 referências de câmeras, lê a referência do Field Size.

Entendi. Essa solução é razoável. Mas o ideal seria pensar/usar alguma estrutura com notificação. Q avisasse caso houvesse dado novo. Assim vcs n precisavam chegar na mão. É equivalente a um interrupção, que é bem melhor q o polling (que é o que vcs estão fazendo).

Vamos correr atrás de um jeito melhor.