Atividade #1270
AbertaCorreção de Bugs
Descrição
Já que ficamos prejudicados devido interdição do PIRF, é válido aproveitar esses dias para corrigir problemas de lógica que conseguimos perceber no grsim, como penalty shoot out, troca de plays, movimentação entre outros.
Arquivos
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
Já consertei as Plays de Penalty normal e Penalty shoot out. Fiz isso na branch PenaltyShootOut criada a partir da dev.
Para consertar penalty normal e shoot out, coloquei a Tactic Shoot na lugar da que tinha pro penalty, coloquei future pose com dt de 0,15 e KickTo com chute fraco a fl/7.
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
Agora criei a branch MotionCorrection para analisar os problemas de robô não desviando da bola e movimentação estranha perto do destino.
Curioso é que com o robô em campo esses problemas não aparecem tanto, algo os camufla. Correções como essas necessitam de testes no pirf. Porém do jeito que está no grsim não conseguimos testar as jogadas direito, o robô varia muito em torno da posição final, se enrola com a bola, entre outros. Vou analisar o problema e corrigir no grsim, posteriormente fazendo testes em campo.
Todos os consertos serão feitos numa branch específica para ele, criada a partir da dev.
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Arquivo MotionEstranho.mp4 MotionEstranho.mp4 adicionado
Para entender o que estou dizendo, no seguinte vídeo abaixo coloquei o robô para bater um shoot out e ele se enrola com a bola, com movimentação estranha e sem aparentemente desviar dela:
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Arquivo VendoTrajAtrapalhar.mp4 VendoTrajAtrapalhar.mp4 adicionado
Repeti a situação de shoot out desenhando a trajetória para entender melhor a situação e na verdade percebi que o problema é de lógica. Quando a bola anda um pouco, mandamos o attacker para a pos est da bola e esse destino fica muito a frente da bola e o robô acaba tentando ultrapassar ela. Para esse problema, acredito que a solução seja reduzir a pos est da bola:
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Arquivo ConsertandoFuturePose.mp4 ConsertandoFuturePose.mp4 adicionado
A pos est ball (ou future pose) nada mais é do que Pbola + Vbola*t. Esse t é setado manualmente por nós estava com valor de 0,8.
Fui testando e cheguei ao valor de 0,15. Mas como isso depende da estimativa de velocidade da bola, temos que testar no campo e colocar outro valor que se adeque melhor.
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Arquivo zigzag.mp4 zigzag.mp4 adicionado
Sobre o problema de movimentação temos o seguinte:
Temos 4 trajetórias (considerando ida e volta) e o curioso é que o erro é diferente para trajetórias diferentes e o mesmo para a mesma trajetória (numa delas o erro é chegar perto do destino e voltar um pouco, em outra é varar bastante a reta a ser seguida, em outra não tem erro e na última é passar um pouco do destino)
Podem ser vistos no vídeo os parâmetros utilizados para maxoutputxy, maxacel, etc além das ctes PID todas nulas (o que faz a estimativa de velocidades ter pouca influência).
Não tínhamos esses problemas em versões anteriores do código. Provavelmente construímos esses problemas fazendo pequenas alterações no rrt e na navigation na preparação e durante a larc (mudanças essas que aparentemente melhoraram a movimentação do robô em campo). Como não sei listar exatamente todas as mudanças, o que penso em fazer por enquanto é substituir toda navigation e rrt (primeiro navigation e rrt se for necessário) por de alguma versão de código que não tenha esses problemas e analisar se volta ao normal. Fazer isso é importante para definir se esses erros foram gerados pelas alterações em rrt e naviagtion ou se é por algum outro motivo do código novo (taxas de amostragem e etc).
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Situação alterado de Em andamento para Feedback
Atualizado por Nicolas Oliveira há mais de 4 anos
Gabriel Borges da Conceição escreveu:
A pos est ball (ou future pose) nada mais é do que Pbola + Vbola*t. Esse t é setado manualmente por nós estava com valor de 0,8.
Fui testando e cheguei ao valor de 0,15. Mas como isso depende da estimativa de velocidade da bola, temos que testar no campo e colocar outro valor que se adeque melhor.
Procurar uma solução definitiva, que n precise de adequação de parâmetros. Como, por exemplo, mudança do valor do parâmetro com a distância ou velocidade da bolo, do robô, algo nesse sentido.
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Arquivo AttackerCerto.png adicionado
- Arquivo AttackerErrado.png adicionado
Fazendo testes, percebi que algumas vezes o attacker ficava errando a bola quando tentava chutar, indo para os lados, destino indo pra trás, etc.
Pelo o que eu identifiquei, ocorre o seguinte:
1- Quando attacker chega reto:
![](AttackerCerto.png)
2- Quando o attacker chega torto:
![](AttackerErrado.png)
Ou seja, devido ao problema de movimentação que citei em comentários acima, algumas vezes o robô se move mal e chega torto na bola. Quando isso acontece, a lógica do KickTo manda ele ir pra trás pra tentar se alinhar novamente e por isso dá a impressão de que ele fica errando a bola.
Portanto, primeiro vou consertar o erro de movimentação e depois analiso como ficou esta situação.
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Arquivo excluído (
AttackerCerto.png)
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Arquivo excluído (
AttackerErrado.png)
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Arquivo AttackerCerto.png adicionado
- Arquivo AttackerErrado.png adicionado
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Arquivo excluído (
AttackerCerto.png)
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Arquivo AttackerCerto.png adicionado
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Arquivo excluído (
AttackerCerto.png)
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Arquivo excluído (
AttackerErrado.png)
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Arquivo AttackerCerto.png AttackerCerto.png adicionado
- Arquivo AttackerErrado.png AttackerErrado.png adicionado
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Situação alterado de Feedback para Em andamento
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Arquivo PosEstBallAdapted.mp4 PosEstBallAdapted.mp4 adicionado
Nicolas Oliveira escreveu:
Gabriel Borges da Conceição escreveu:
A pos est ball (ou future pose) nada mais é do que Pbola + Vbola*t. Esse t é setado manualmente por nós estava com valor de 0,8.
Fui testando e cheguei ao valor de 0,15. Mas como isso depende da estimativa de velocidade da bola, temos que testar no campo e colocar outro valor que se adeque melhor.
Procurar uma solução definitiva, que n precise de adequação de parâmetros. Como, por exemplo, mudança do valor do parâmetro com a distância ou velocidade da bolo, do robô, algo nesse sentido.
Fiz o seguinte: Na skill KickTo, ao invés de passar apenas o PosEst, agora faz-se a seguinte análise:
Seja d a distância do robô à bola, então
1)d > 1000mmm, passa PosEstBall
2) 150 <= d <= 1000, passa linear entre PosEstBall e PoseBall (x, y reais)
3) d < 150, passa PoseBall (x, y reais)
Fiz isso criando o método adaptPosEstBall para a class KickToSkill.
Teve o seguinte efeito:
Com isso, o funcionamento da jogada não fica tão dependente do dt do futurePose; deixei com 0,3. Além disso, agora também coloquei em Parameters o atributo ShootOutForce, que é a força do toquinho no shoot out para ficar mais rápido de alterarmos (já que no grsim 5 fica bom e no robô real, 20), e coloquei também o dtPosEstBall.
Mas, na verdade, acho que deveríamos desconsiderar a bola como obstáculo do robô caso ela esteja "consideravelmente" à frente do robô devido o seguinte:
Neste vídeo, quando a bola está à frente do robô e com velocidade, seu destino é PosEstBall ou fração disso com o intuito de ele conseguir chegar mais rápido do que se fosse mandado apenas para a posição atual bola. Porém, ele está de certa forma alinhado com a direção da bola e como ela é considerada como obstáculo, a trajetória criada é feita para desviar dela, o que atrapalha a movimentação do robô que, neste caso, deveria ir reto para a bola.
Essas alterações juntamente às do Penalty estão na Branch FixBugs.
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Arquivo BolaObstaculo.mp4 BolaObstaculo.mp4 adicionado
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Situação alterado de Em andamento para Feedback
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Situação alterado de Feedback para Em andamento
Atualizado por Antonio de Souza Gomes Pereira há mais de 4 anos
- Arquivo removeBallObstacle.wmv adicionado
Para tentar resolver isso, botei ele para desconsiderar a bola como obstáculo (raio do obstáculo 0) quando estiver na situação de attacker, estiver em stop, estiver atrás da bola e com distância maior que 500mm(parâmetro AttackerIgnoreBallObstacle).
O resultado foi o seguinte:
Atualizado por Antonio de Souza Gomes Pereira há mais de 4 anos
- Arquivo excluído (
removeBallObstacle.wmv)
Atualizado por Antonio de Souza Gomes Pereira há mais de 4 anos
- Arquivo removeBallObstacle.mp4 adicionado
Atualizado por Antonio de Souza Gomes Pereira há mais de 4 anos
- Arquivo excluído (
removeBallObstacle.mp4)
Atualizado por Antonio de Souza Gomes Pereira há mais de 4 anos
- Arquivo removeBallObstacle.mp4 adicionado
Atualizado por Antonio de Souza Gomes Pereira há mais de 4 anos
- Arquivo excluído (
removeBallObstacle.mp4)
Atualizado por Antonio de Souza Gomes Pereira há mais de 4 anos
- Arquivo removeballobstacle.mp4 removeballobstacle.mp4 adicionado
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
Antonio de Souza Gomes Pereira escreveu:
Para tentar resolver isso, botei ele para desconsiderar a bola como obstáculo (raio do obstáculo 0) quando estiver na situação de attacker, estiver em stop, estiver atrás da bola e com distância maior que 500mm(parâmetro AttackerIgnoreBallObstacle).
O resultado foi o seguinte:
Error executing the video macro (undefined method `find_by_filename' for []:Array Did you mean? find_index)
Tem que ser não estar em stop! Conferi e vi que vc colocou certo no código, só escreveu errado aqui mesmo.
É importante dizer que o parâmetro AttackerIgnoreBallObs foi você que criou, confere?
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
Em quais VIs vc mexeu?
Seria bom fazer uma lista simples dizendo o que alterou em cada uma. Essa parte do código é bastante sensível, então é bom que todo mundo possa analisar com calma.
Atualizado por Antonio de Souza Gomes Pereira há mais de 4 anos
Gabriel Borges da Conceição escreveu:
Em quais VIs vc mexeu?
Seria bom fazer uma lista simples dizendo o que alterou em cada uma. Essa parte do código é bastante sensível, então é bom que todo mundo possa analisar com calma.
Basicamente o que eu fiz foi modificar a vi ObstacleBallradius.vi, se as condições forem verificadas, o raio da bola é setado para 0.
Além disso, criei uma vi que, dado a role do robô, atribui um valor para o atributo function do cluster robot.
Consequentemente algumas vis foram modificadas, sendo adicionado o control para ignorar a bola:
- ObstacleBallRadius.vi
- DetectCollisionImproved.vi
- DetectTrajetoryCollision.vi
- CanUseSimplePath.vi
- NeedRecalcPath.vi
- FindEndStartEndPointsRRTIproved.vi
- Extended.vi
- RRTAlgorithm.vi
- SmoothPath.vi
- SmootherPath.vi
- FindCollisionPoints.vi
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
Ok! Vou testando e reportar caso encontre algum erro.
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
Testei e por mim está tudo okay!
Atualizado por Antonio de Souza Gomes Pereira há mais de 4 anos
- Arquivo barrierdistance.png barrierdistance.png adicionado
Para consertar o erro do ManMark estar em um x diferente da barreira, criei a vi shiftOutsideDistanceFromQuad.vi, que da um shift para fora do quadrado em x ou y, dependendo da posição dos robôs, de acordo com o parâmetro criado BarrierDistanceToArea.
O resultado para 150mm foi o seguinte:
![](barrierdistance.png)
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
Testei e falta consertar para o caso em que a posição da barreira é corrigida por estar fora do campo.
Atualizado por Antonio de Souza Gomes Pereira há mais de 4 anos
Gabriel Borges da Conceição escreveu:
Testei e falta consertar para o caso em que a posição da barreira é corrigida por estar fora do campo.
Acabei de dar push
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Arquivo DefesaAbreQndColocaAFrenteDaArea.png DefesaAbreQndColocaAFrenteDaArea.png adicionado
Testei e os problemas de manmark em cima da barreira e defesa não ficando à frente da área quando posições fora do campo estão okay.
Ainda vi dois problemas:
1- Barreira não se dividindo na quina.
2- Barreira abre um espaço quando tá na quina e colocamos distância à frente da área maior que 0, como segue:
![](DefesaAbreQndColocaAFrenteDaArea.png)
Quando for mexer, lembre de da pull porque eu dei um push para clonar a Navigation e entrar nela com os booleanos de Shoot Out e Test Mode em todas as 3 navigations.
Atualizado por Antonio de Souza Gomes Pereira há mais de 4 anos
- Arquivo abertura.png abertura.png adicionado
Para resolver o problema da barreira não estar abrindo na quina, o que fiz foi basicamente calcular a porcentagem da distância que o robô estava no quadrado sem shift na barreira e mandar ele para a posição que tenha a mesma porcentagem, mas no quadrado com shift. Dessa forma evitamos a criação de uma área que ele nunca chegaria caso apenas somássemos uma distância em x e em y.
O resultado pode ser visto abaixo:
![](abertura.png)
A distância entre os robôs pareceu aumentar um pouco, mas não pareceu ser muito problema se a distância não for muito grande (<=350mm)
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Atribuído para alterado de Gabriel Borges da Conceição para Antonio de Souza Gomes Pereira
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
Acertei as situações em que o robô deve andar devagar, criando o método "slowBehavior" para Robot. Este método recebe o Robot, e de acordo com sua tactic retorna um booleano, significando se deve andar devagar ou normalmente. Esse booleano é levado para "slowBehavior" criado no cluster OurRobot.
Na navigation, mudei para pegar o booleano de "slowBehavior" ao invés de "PassState".
As tactics nas quais o robô deve andar devagar são "AttackerStop", "KickToPassReceiver" e "Timeout".
Já dei merge com a dev e com a dev2.
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
Consertei os seguintes checklists:
Colocar role PassReceiver e SimplePassRollReceiver na FollowAttacker: Bastou colocar mais um "ou" nessas roles no for que as busca na FollowAttackerSkill.
Attacker errando a bola quando tenta chutar as vezes: Na navigation, existem algumas situações em que a velocidade do robô é limitada. Adicionei à limitação de vmax de 0,3m/s a condição de robô com distância menor que 300 mm da bola. Dessa forma, ao se aproximar para chutar, ele anda mais devagar, ficando mais controlado e errando muito menos seu posicionamento para realizar um bom chute.
FollowAttacker atrapalhando chute do Attacker por cruzar o campo as vezes: O FollowAttacker manda seu robô para a outra metade do campo (em y). Acontecia algumas vezes de ambos estarem do mesmo lado, devido a uma jogada de passe, por exemplo. Nessas situações, quando entrava na Tactic de FollowAttacker, o robô queria ir pro outro lado do campo e as vezes passava na frente do chute.
Então coloquei uma condição que se ambos estiverem do mesmo lado do campo em y e o FollowAttacker estiver com x maior, seu destino é alterado da seguinte forma (destx = destx - 1000 e desty = desty*(sinal de y atual)). Assim ele não passa na frente do robô que vai chutar e vale ressaltar que ele não vai chegar no destino, pois quando o FollowAttacker ficar com x menor que do robô que vai chutar, ele vai ser mandado pro outro lado do campo.
ManMark da defesa não funcionando com AttackingOurselves: Alterei o código colocando um case pra quando AttackingOurselves estiver ativado, pegar o segundo robô do nosso time mais próximo da bola para ser marcado pelo ManMark da defesa.
Duelist não funcionando com AttackingOurselves: Coloquei cases pra funcionar quando AttackingOurselves estiver ativado, tanto para condição de início do Duelist quanto para o StealBall.
Colocar em parameters distância do goleiro à frente da área: Nas 3 VIs de Skills dos robôs, ao invés de ser uma constante em cada, agora o quanto o goleiro fica à frente da linha do gol é um valor pego de Parameters de Game, atributo chamado "GoalieInFrontGoal".
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Atribuído para alterado de Antonio de Souza Gomes Pereira para Gabriel Borges da Conceição
Consertei:
1- Fazer follow attacker funcionar no atacando contra (a volta no attacker)
2- Pequenos ruídos de velocidade atrapalham chute do PassReceiver: aumentei distância mínima no adaptPosEstBall e percebi que colocando wait constante no while da visão faz a estimativa ficar melhor.
3- SimplePass não funciona com AttackingOurselves: fiz funcionar no atacando contra e troquei a tactic de rolar pra rolar lateralmente.
4- Fazer numberOfRobots de forma mais organizada no pickRobots (dentro dos cases)
5- Destino dos robôs está sendo perdido no pickRobots: criei o método de Ally updateDest que recebe o vetor atual de robôs e o último e seta os destinos de quem tem. Coloquei isso nos 3 pickRobots.
6- Colocar em Parameters velocidade máxima quando perto da bola: testei e ficou melhor 0,4 m/s.
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Arquivo VanishingComLifetime.mp4 VanishingComLifetime.mp4 adicionado
- Arquivo VanishingSemLifeTime.mp4 VanishingSemLifeTime.mp4 adicionado
Fiz tbm:
7- Recolocar lifetime após mediaCameras: apenas coloquei novamente as VIs de LifeTime que tinha feito pra larc.
Liguei o desaparecimento do grsim com 10% de probabilidade para robôs azuis e bola.
Como fica nossa visão sem Lifetime:
Como fica nossa visão com Lifetime:
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
Consertei:
Fazer update de tactic do robot no pickRobots: feito no método updateDest de Ally logo antes de sair como o array de Robots.
dev2 não pegando bola quando abre o grsim, só se mover: Isso era problema no MediaCameras no GetCamerasPositionById que tem no MediaBalls e no MediaRobots. Problema é que estava sendo feito apenas no first call e o first call não está sendo identificado corretamente por algum motivo. Então coloquei pra fazer sempre.
Consertar pickRobots do PreparePenaltyAlly e KickPenaltyAlly: Cases dessas Plays pra escolha de robôs continham erros. Apaguei o case e elas entram no Default.
Colocar LifeTime na dev2: Coloquei mas ainda falta mudar a posição com a velocidade nesse lifetime tanto na dev quanto na dev2.
KickToSkill permite troca de mira mesmo com robô já muito próximo da bola. Isso atrapalha o chute: criei o método fixTarget para KickToSkill. Este método recebe a posição calculada e a anterior e passa a anterior caso o robô esteja a menos de 300mm da bola, fixando sua mira. Deixar ele mudar a mira a qualquer instante atrapalha o chute devido à movimentação dos inimigos.
Método de evento de toque e posse zoada pq faz um loop for para os robôs dos dois times. Se tiver qtd diferente, dá ruim. Colocar para fazer apenas para o robô mais próximo da bola dos dois times: Coloquei para fazer a conferência apenas para o robô mais próximo da bola de ambos os times.
Consertar orientação do robô no Best Y inverso: usei método de Utilities robotOrientedToBall
Fazer PO funcionar com TablePass tbm: coloquei a busca por roles em cases dependendo de cada play.