lucastrschneider
commented
3 years ago Boa noite galera.
Primeiramente, não gosto muito de configurar essas coisas usando os multipliers do diff_drive_controller. A própria definição deles que aparece no seu quote já é motivo suficiente pra não mexer neles numa simulação kkkkkkk
Mas enfim, tava achando estranho e fui dar uma olhada, mas não descobri que software é esse que você tava usando para testar @FelipeGdM, mó bonitinho. Mas acabei usando o rqt mesmo.
Primeiro, abri um plot para mostrar esses 3 tópicos:
- vision/yellow_team/robot_0/twist/angular/z -> O que a gente recebe do Gazebo
- yellow_team/robot_0/diff_drive_controller/cmd_vel/twist/angular/z -> O que a gente passa de comando
- yellow_team/robot_0/diff_drive_controller/odom/twist/twist/angular/z -> Odometria que o plug-in do ROS control utiliza para controle
Em seguida, configurei o tópico do comando de velocidade para receber uma senóide na velocidade angular da seguinte forma:
sin(i/3) * 7 (nesse caso, i é o tempo em segundos)
Dá para fazer vários testes com diferentes valores para frequencia angular e amplitude, mó divertido isso haushuahusa.
Por fim, abri o Dynamic Reconfigure do ros_control para tunar as constantes do PID. Acredito que você não tinha conseguido zerar o erro estacionário pois o valor máximo e minimo do termo integral estava por padrão como 0, então ele não fazia muita coisa.
Basicamente, utilizei as seguintes constantes para ambas as joints:
p: 0.015 i: 1.0 d: 0.0 i_clamp_min: -0.1 i_clamp_max: 0.1 antiwindup: active (nem sei se faz sentido ativar aqui se o derivativo ta nulo, mas sla)
E obtive esses resultados:
Da pra brincar usando o rqt_steering_topic tbm, e passar valores arbitrarios de velocidade angular, mas parecia estar se comportando bem.
Eu não fiquei muito tempo tunando esses parâmetros, então recomendo dar uma ajustada para conseguir um resultado melhor, mas acho que já é um bom ponto de partida.
Outra coisa que acho que seria bom fazer é o mesmo procedimento para a velocidade linear, só checando se essas constantes obtidas são satisfatórias nesse caso também.
Eu não acho que a odometria está mal configurada, nem sei se da para configurar ela de fato, mas pelo que eu plotei aqui, ficava sempre bem parecido com o que a gente obtia da visão (para constantes razoavelmente calibradas) ~para constantes arbitrarias era realmente só bagunça aushasau~
Mas enfim, só pra deixar de referência, foi aqui que aprendi a mexer nessas coisas do rqt, mt bom o video.
Salve salve amantes do mundo da bola
O @LucasHaug fechou a #19 antes que eu pudesse terminar os testes do impacto das mudanças, então aqui temos outra PR pra corrigir alguns probleminhas
Muito bem, contando a história do começo. Com a configuração das constantes de PID, o diff_drive_controller passa a usar os dados da odometria pra estimar o estado do robô ~e aà começa o caos~. Acontece que os dados da odometria estão mal configurados, de modo que o robô exibe um erro estacionário não trivial na velocidade linear/angular
Mexi um pouco nas constantes de PID e o erro estacionário não sumiu de jeito nenhum, o que me leva a crer que o problema é de fato no sistema de medição do estado do robô (a odometria no caso). De qualquer forma, deixei um Ki diferente de zero de forma que o erro estacionário tenda a zero
Dito isso, fiz uso de dois parâmetros de configuração do diff_drive_controller
Isso me lembra à s "constantes de proporcionalidade" das aulas de quÃmica do colégio hue
Com essa alteração, foi possÃvel zerar o erro estacionário do controle de velocidade
Não é a solução mais elegante de todas :stuck_out_tongue_closed_eyes:, imagino que uma solução mais robusta necessite da alteração da matriz de covarianca da posição e velocidade angular, mas ainda não tenho conhecimento suficiente para poder ajustar
No mais, é isso que temos para hoje. Fiquem bem e mantenham-se hidratados