Meta #720
FechadaObjetivo #557: Obter um controle de navegação otimizado
Implementar malha de controle por Velocidade
Adicionado por Nicolas Oliveira mais de 6 anos atrás. Atualizado mais de 6 anos atrás.
Descrição
Mudar o controle atual baseado em posição para controle de velocidade.
Deve ser gerado um perfil de velocidade (bang-bang) para o robô seguir e ser capaz de alcançar a posição desejada.
A realimentação de velocidade seria pelo filtro de kalman.
Arquivos
kalman.PNG (2,52 KB) kalman.PNG | Nicolas Oliveira, 22/05/2018 02:10 h | ||
Path2.jpeg (13,3 KB) Path2.jpeg | Nicolas Oliveira, 02/06/2018 22:52 h | ||
Profile3.jpeg (114 KB) Profile3.jpeg | Nicolas Oliveira, 02/06/2018 22:53 h | ||
Profile4.jpeg (114 KB) Profile4.jpeg | Nicolas Oliveira, 02/06/2018 22:53 h | ||
Path1.jpeg (14,7 KB) Path1.jpeg | Nicolas Oliveira, 02/06/2018 22:53 h | ||
Profile1.jpeg (117 KB) Profile1.jpeg | Nicolas Oliveira, 02/06/2018 22:53 h | ||
Profile2.jpeg (114 KB) Profile2.jpeg | Nicolas Oliveira, 02/06/2018 22:53 h | ||
control.mp4 (3,81 MB) control.mp4 | Nicolas Oliveira, 03/06/2018 00:08 h | ||
Profile5.jpeg (49 KB) Profile5.jpeg | Nicolas Oliveira, 04/06/2018 18:51 h | ||
controle.mp4 (5,82 MB) controle.mp4 | Nicolas Oliveira, 05/06/2018 00:31 h | ||
caso1.PNG (49,4 KB) caso1.PNG | Nicolas Oliveira, 05/06/2018 01:17 h | ||
caso2.PNG (58,6 KB) caso2.PNG | Nicolas Oliveira, 05/06/2018 01:17 h | ||
30fps.mp4 (7,56 MB) 30fps.mp4 | Nicolas Oliveira, 07/06/2018 23:27 h | ||
60fps.mp4 (8,97 MB) 60fps.mp4 | Nicolas Oliveira, 07/06/2018 23:27 h | ||
frente.txt (45,5 KB) frente.txt | Lucas Germano, 10/06/2018 00:25 h | ||
frente_com_mais_velocidade.txt (33,4 KB) frente_com_mais_velocidade.txt | Lucas Germano, 10/06/2018 00:25 h | ||
lado.txt (30,6 KB) lado.txt | Lucas Germano, 10/06/2018 00:25 h | ||
VelAccel.png (49 KB) VelAccel.png | Nicolas Oliveira, 12/06/2018 20:47 h | ||
VelX.png (47 KB) VelX.png | Nicolas Oliveira, 12/06/2018 20:47 h | ||
VelY.png (45,2 KB) VelY.png | Nicolas Oliveira, 12/06/2018 20:47 h |
Atualizado por Nicolas Oliveira há mais de 6 anos
- Arquivo kalman.PNG kalman.PNG adicionado
Após um estudo do filtro de kalman percebi que nossa implementação atual não utiliza o comando de velocidade enviado ao robô na predição do próximo estado. O qual está presente na parte em destaque da equação abaixo:
![](kalman.PNG)
A dificuldade era como inserir isso nas contas, inspirado na forma como a velocidade influencia na próxima posição(e por uma ideia do luciano), decidi utilizar a aceleração. Assim pego a velocidade atual e a desejada (a que estou enviando ao robô) faço a diferença e divido pelo intervalo de tempo, assim tenho a "aceleração desejada". Porém para essa conta fazer sentido devemos limitar a aceleração com base nas limitações físicas do robô (essa mesma limitação de aceleração irá aparecer no controle por velocidade). Assim a próxima velocidade é a atual mais a aceleração vezes o tempo.
A resposta do kalman ficou muito mais rápida. Acho que agora o controle pode se basear nela. Lembrando que isso só funciona para os nossos robôs. Vou postar um vídeo aqui depois mostrando a diferença.
Atualizado por Nicolas Oliveira há mais de 6 anos
- Arquivo Profile3.jpeg Profile3.jpeg adicionado
- Arquivo Path2.jpeg Path2.jpeg adicionado
- Arquivo Profile4.jpeg Profile4.jpeg adicionado
- Arquivo Path1.jpeg Path1.jpeg adicionado
- Arquivo Profile2.jpeg Profile2.jpeg adicionado
- Arquivo Profile1.jpeg Profile1.jpeg adicionado
- Data prevista alterado de 11/05/2018 para 03/06/2018
- Prioridade alterado de Alta para Urgente
- Versão ajustado para RoboCup 2018
Feita a VI para gerar perfil de velocidade para uma dada trajetória. Ela gera o perfil para cada trecho e os concatena. O perfil busca a movimentação bang-bang, sendo assim temos aceleração máxima quando queremos mudar de velocidade e depois a mantemos.
Estou gerando o perfil separadamente em x e y, dessa forma com a direção da trajetória controlo a velocidade máxima em cada componente fazendo assim o robô já seguir a trajetória naturalmente.
Os parâmetros de entrada são a aceleração máxima, a desaceleração máxima, o ponto de partida, de chegada, o tempo, a velocidade estimada e a velocidade no destino.
Seguem algumas imagens exemplificando:
Para a trajetória abaixo:
![](Path1.jpeg)
![](Profile1.jpeg)
Para uma aceleração máxima menor por exemplo.
![](Profile2.jpeg)
Agora para essa trajetória abaixo:
![](Path2.jpeg)
![](Profile4.jpeg)
O caso ainda n tratado é se o perfil n puder ser gerado, devido a uma aceleração baixa por exemplo
![](Profile3.jpeg)
Atualizado por Nicolas Oliveira há mais de 6 anos
O próximo passo é gerar o comando da velocidade com base nesse perfil e então controlá-la.
Atualizado por Nicolas Oliveira há mais de 6 anos
- Arquivo control.mp4 control.mp4 adicionado
Comando de velocidade gerado. Segue vídeo com robô se movendo com aceleração de 2m/s^2 e desaceleração de 8m/s^2 (valores menores que os do robô real):
Podemos ver q mesmo em malha aberta o robô já é capaz de se mover bem!
Agora falta a parte do controle. Vou manter usando aql controle lateral para se manter sobre a trajetória, visto que quando ele desvia dela n há nada previsto no perfil para arrumar isso.
Atualizado por Nicolas Oliveira há mais de 6 anos
Controle implementado da seguinte forma: a velocidade enviada ao robô é composta por 3 parcelas. Calculo o erro entre a velocidade medida e a velocidade desejada, passo isso por um PID e somo com a própria velocidade desejada mais o ganho lateral para se manter na trajetória.
Estou com dificuldade de estimar as constantes agora.
Atualizado por Luiz Renault Leite Rodrigues há mais de 6 anos
Acho que deveríamos considerar aceleração quando se afasta da velocidade 0 e desaceleração quando se aproxima, independente do sinal da velocidade.
Atualizado por Nicolas Oliveira há mais de 6 anos
Luiz Renault Leite Rodrigues escreveu:
Acho que deveríamos considerar aceleração quando se afasta da velocidade 0 e desaceleração quando se aproxima, independente do sinal da velocidade.
Já está sendo feito assim.
Atualizado por Luiz Renault Leite Rodrigues há mais de 6 anos
Atualizado por Nicolas Oliveira há mais de 6 anos
Atualizado por Nicolas Oliveira há mais de 6 anos
- Arquivo Profile5.jpeg Profile5.jpeg adicionado
Atualizado por Nicolas Oliveira há mais de 6 anos
- Arquivo controle.mp4 controle.mp4 adicionado
Controle P com realimentação da velocidade estimada implementado. Uma coisas alterada que melhorou muito no kalman é que a unidade de velocidade em todo nosso código é m/s, menos no kalman, como é feito s = s0+v*t, v precisa estar em mm/s. Assim a contribuição do comando de velocidade enviado ao robô era quase irrisória. Agora podemos ver como a atualização é bem mais rápida no vídeo abaixo:
Atentar para o módulo da velocidade mostrada na canto inferior esquerdo, onde para uma vmax = 2m/s vemos o perfil trapezoidal e para v=3m/s vemos o perfil triangular.
Atualizado por Nicolas Oliveira há mais de 6 anos
Meu problema atual é como tratar os casos onde um perfil válido não consegue ser gerado. Por exemplo no caso abaixo, a velocidade desejada no ponto final n é capaz de ser alcançada com as acelerações definidas.
Nessa situação eu posso por exemplo reduzir a velocidade no ponto final. Porém no caso abaixo onde eu começo com uma velocidade tão alta que na saída eu não sou capaz de chegar na velocidade desejada como eu trataria esse caso?
Atualizado por Luiz Renault Leite Rodrigues há mais de 6 anos
Uma das possibilidades é nesse caso ignorar a aceleração máxima e tentar acelerar o necessário.
Atualizado por Nicolas Oliveira há mais de 6 anos
Luiz Renault Leite Rodrigues escreveu:
Uma das possibilidades é nesse caso ignorar a aceleração máxima e tentar acelerar o necessário.
Implementei, porém estou tendo alguns problemas do robô frear do nada. Preciso revisar meu código. Porém sem tratar esses casos o robô tem mais overshoot porém funciona ok.
Retirei todos os pequenos bugs q meu código ainda tinha e calibrei as constantes de controle.
A questão é que é um pouco desleal comparar com a intel antiga agora, ela é bem mais rápida. Só que quando eu mando um degrau pro robo no grsim ele consegue alcançar uma aceleração de até 20m/s^2, o que é bem impraticável. Controlando a velocidade agora ele se comporta muito mais parecido com o real. A questão é que estamos perdendo um pouco de precisão no chute. Vou gerar um teste depois para avaliar.
Pretendo testar amanhã na IMBEL. Vou precisar adaptar os parâmetros para o robô real amanhã.
Agora mesmo a 30 fps o robô permanece controlado, espero q assim seja possível testar com a câmera presente na imbel.
Robô em modo teste a 60 fps:
Robô em modo teste a 30 fps:
Atualizado por Nicolas Oliveira há mais de 6 anos
Um problema notado hoje nos testes da imbel é que quando o lado do campo é trocado, estou enviando o comando de velocidade na direção errada. Isso não era para acontecer, já que esse tipo de coisa é abstraída em nossos cálculos. Porém amanhã irei revisar o código.
Atualizado por Lucas Germano há mais de 6 anos
- Arquivo frente.txt frente.txt adicionado
- Arquivo frente_com_mais_velocidade.txt frente_com_mais_velocidade.txt adicionado
- Arquivo lado.txt lado.txt adicionado
Arquivos referentes ao teste feito na imbel com zig-zag entre os pontos:
P_0 = 2300;1500
P_1 = -2300;-1500
Atualizado por Nicolas Oliveira há mais de 6 anos
- Arquivo VelAccel.png VelAccel.png adicionado
- Arquivo VelX.png VelX.png adicionado
- Arquivo VelY.png VelY.png adicionado
Medi a velocidade e a aceleração do robô real na imbel com 2 câmeras.
Os resultados seguem abaixo. Estão de acordo com os parâmetros de controle.
Com velocidade máxima em torno de 2m/s e aceleração entre 1m/s^2 e 2m/s^2.
![](VelY.png)
![](VelY.png)
![](VelAccel.png)
Atualizado por Luiz Renault Leite Rodrigues há mais de 6 anos
De onde vem tanto ruído na velocidade?
Atualizado por Nicolas Oliveira há mais de 6 anos
Creio que seja devido ao fato de usarmos 2 câmeras. O código roda a 60fps e cada câmera a 30fps. E os frames vem alternados, assim em uma câmera recebemos a posição do robô e na outra (que não está vendo o robô) e posição é mantida do ultimo frame. Assim parece que o robô não se mexeu entre esses frames, dando uma variação quase 0.
Assim o ruído na medição da velocidade aparece.
Atualizado por Luiz Renault Leite Rodrigues há mais de 6 anos
De onde vem a medição da velocidade?
Atualizado por Gabriel Borges da Conceição há mais de 6 anos
- Situação alterado de Em andamento para Resolvida
Atualizado por Gabriel Borges da Conceição há mais de 6 anos
- Situação alterado de Resolvida para Fechada