Atividade #1233
AbertaAnalisar Sobrescrita de objetos em referência
Descrição
Essa tarefa tem como intuito verificar alternativas à estrutura In Place Element Structure, uma vez que para transcrição de dados é necessário transcrever dado por dado e não o objeto em si.
Como se observa na imagem, o labview não permite tal feito, logo , atualmente, é feito da seguinte forma.
Todavia, estudando o funcionamento do In Place Element Structure, sabe-se que somente uma loop pode usar a refência, além de que é percebível que o caminho que tomamos não é efetivo.
Assim, na Branch ObjRefer
Eu introduzo uma função de sincronização. O Notifier:
Vantagens:
Pode mandar um dado objeto entre loops
Pode ser lido por multiplos loops
O loop consumidor espera o loop produtor enviar uma mensagem, isto é a sincronização pode ser feita sem os waits nos loop.
Pode evitar o vazamento de memória atual do código
Desvantagens:
Se o produtor for muito mais rápido que o consumidor pode se perder dados
Não fica armazenada o ultimo dado como a referência
Arquivos
Atualizado por Felipe Welington há mais de 4 anos
- Arquivo Notifier.png Notifier.png adicionado
- Arquivo Normal.png Normal.png adicionado
Em um primeiro momento
Eu verifiquei se o notifier transcreveria os dados do objeto tanto da visão quanto do game.
E cheguei a conclusão que ele faz isso.
Em seguida
Eu verifiquei a sincronia dos loop em halt, visto que como os robos não executam ação o fps dos loops keeper, offensive e defensive deveriam chegar bem próximo da visão.
Com base nos em transcrição por referência
Com base no Notifier ( tanto para visão, quanto para camera)
Vê-se que o wait cria uma pequena perda de eficiência nos loops, enquanto que com o notifier o loop só executara quando receber o dado novo.
Além de que a diferença de tempo da leitura udp à execução do código é menor com o notifier.
Atualizado por Felipe Welington há mais de 4 anos
Testando a troca de grande parte das referências do game por notifiers, vê-se que em um momento os robôs da nossa equipe somem da imagem e o comando do jogo não sai de halt, posto que o notifier não armazena informação para as próximas interações e parte do nosso código utiliza as informações anteriores via referência na parte do game. Então, vejo que a utilização de tal ferramenta pode ser útil na visão para transcrição do loop read udp para o loop da visão, visto que a maior eficiência desse loop pode evitar o atraso do código que acarretaria em armazenamento de pacotes. Todavia, para o resto das referências seria necessário adaptar parte do código.
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Prioridade alterado de Alta para Normal
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
Com base no que conversamos e pensamos na quarta-feira, você agora precisa entender o fluxo das informações do código e conseguir determinar quais informações vai passar em cada notifier de cada while.
Vá postando os avanços.
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
Sugiro fazer teste para analisar diferença de tempo de execução/processamento entre In Place Element Structure e Notifier.
Pega uma VI em branco, coloca dois whiles e utiliza passagem de parâmetros por referência com In Place. Faça o mesmo em outro teste mas utilizando Notifier e passando a mesma informação que no teste anterior. Utilize "get date in time" ou coisa parecida pra analisar quanto tempo demorou cada um.
Na verdade rode esses testes diversas vezes para analisarmos diversas amostras de tempo para garantir que não teve interferência do pc ou algo do tipo.
Também é importante testar se quando um while lê do notifier ele apaga da memória ou não. Porque se apagar, whiles diferentes não conseguirão ler a mesma informação.
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
Recrie sua branch a partir da dev