LucasHaug
commented
1 year ago Finalmente a tão esperada migração para ROS 2
:eyes: :eyes: :eyes: :eyes:
Em ROS 2, launchfiles podem ser escritos em python ou YAML além de XML, de modo que essa é uma excelente oportunidade de largar o XML. Os launchfiles do ros_gz são escritos em python, de modo que é mais fácil estende-los se também usarmos python, então acho que temos uma boa direção a seguir.
Eu concordo que o melhor aí é fazer em python, até porque aí dá pra simplificar muito umas coisas do repositório. A gente tinha feito o spawn_robots.py em python justamente porque o launchfile em XML não era suficiente pras nossas necessidades, então acho que a gente tem que fazer os launchfiles em python agora pra migração de ROS 2.
Os nossos launchfiles são responsáveis por algumas configurações do ambiente, em especial a atualização das variáveis de ambiente
GAZEBO_RESOURCE_PATHeGAZEBO_MODEL_PATH. Na migração, as duas variáveis passam a se chamarIGN_GAZEBO_RESOURCE_PATHe fiz um protótipo de configuração usando environment hooks do colcon, de modo que as variáveis de ambiente são configuradas sempre que o usuário executarsource install/setup.bash. Os arquivos ainda precisam ser melhor organizados para que possamos simplificar o valor guardado na variável de ambiente.
Tava vendo aqui, vi uma pessoa colocando isso daí no próprio launchfile em python.
Por fim, uma questão de usabilidade especialmente relevante para o travesim. A nova versão do Gazebo é bem mais desacoplada do ROS do que a versão anterior, de modo que seu uso é bem mais simples em projetos que não utilizam ROS. O método de transporte padrão é o Google Protobuf, em oposição ao DDS utilizado pelo ROS 2. Para a nossa alegria, Protobuf já é o método de transporte padrão utilizado na comunidade de VSS, de forma que podemos simplificar consideravelmente o travesim_adapters. Penso em transformar o travesim_adapters num plugin Gazebo, que traduza a interface definida pelo VSSSProto para a interface do Gazebo, acho que teremos um ganho considerável em facilidade de uso e performance
Meo deos que doidera ahushuashaushasuhas. Nossa agora é o gazebo que precisa de uma ponte, parece que o jogo virou auhshuashuashuash.
No mais, fiquem com um screenshot do campo no novo Gazebo \o/
Nossa que coisa bonita ahusuhhushuashuahsu
Em resumo
- [ ] Migrar ros_control para ros2_control
- [ ] Migrar launchfiles para python
- [ ] Atualizar modelo visual do robô (remover scripts OGRE)
Precisa migar também os plugins tipo da câmera e do diff drive?
FelipeGdM
Finalmente a tão esperada migração para ROS 2
Para quem não acompanha o mundo da bola, o ROS noetic é a última versão do ROS, sendo ROS 2 o sucessor direto do framework. Vou deixar a referência oficial Why ROS 2? para contextualizar melhor a decisão da mudança disruptiva depois do ROS noetic. Como essa é uma atualização que quebra a compatibilidade com versões anteriores, é necessária uma refatoração um pouco mais profunda do nosso projeto.
Surfando a mesma onda de renovação do ROS, o Gazebo também passou por uma repaginada, por um breve momento mudou de nome para "Ignition" mas acabou voltando a se chamar Gazebo. O código do simulador foi profundamente refatorado, de modo que também temos que lidar com uma quebra de compatibilidade devido a essa atualização
Como não podemos ficar de fora dessa brincadeira, essa PR é o pontapé inicial da migração para a nova era do software em robótica
Alguns desafios a vista
Questões mais elaboradas
A interface ROS 2 - Gazebo é feita pelo pacote ros_gz, que substitui o gazebo_ros_pkgs. É um pouco confuso pq o gazebo_ros_pkgs também existe no mundo ROS 2, para que as pessoas ainda pudessem usar o Gazebo antigo no ROS 2. O travesim estende os launchfiles do gazebo_ros_pkgs para iniciar o ambiente, de modo que eles precisam ser migrados para utilizar o ros_gz, ou refatorados do zero para não ter dependência em nenhum dos dois.
Em ROS 2, launchfiles podem ser escritos em python ou YAML além de XML, de modo que essa é uma excelente oportunidade de largar o XML. Os launchfiles do ros_gz são escritos em python, de modo que é mais fácil estende-los se também usarmos python, então acho que temos uma boa direção a seguir.
Os nossos launchfiles são responsáveis por algumas configurações do ambiente, em especial a atualização das variáveis de ambiente
GAZEBO_RESOURCE_PATHeGAZEBO_MODEL_PATH. Na migração, as duas variáveis passam a se chamarIGN_GAZEBO_RESOURCE_PATHe fiz um protótipo de configuração usando environment hooks do colcon, de modo que as variáveis de ambiente são configuradas sempre que o usuário executarsource install/setup.bash. Os arquivos ainda precisam ser melhor organizados para que possamos simplificar o valor guardado na variável de ambiente.Por fim, uma questão de usabilidade especialmente relevante para o travesim. A nova versão do Gazebo é bem mais desacoplada do ROS do que a versão anterior, de modo que seu uso é bem mais simples em projetos que não utilizam ROS. O método de transporte padrão é o Google Protobuf, em oposição ao DDS utilizado pelo ROS 2. Para a nossa alegria, Protobuf já é o método de transporte padrão utilizado na comunidade de VSS, de forma que podemos simplificar consideravelmente o travesim_adapters. Penso em transformar o travesim_adapters num plugin Gazebo, que traduza a interface definida pelo VSSSProto para a interface do Gazebo, acho que teremos um ganho considerável em facilidade de uso e performance
Por enquanto é isso que eu tinha a falar, vou abrir a PR como rascunho para deixar os tópicos em discussão
No mais, fiquem com um screenshot do campo no novo Gazebo \o/
Em resumo