Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate project to ROS 2 #41

Draft
wants to merge 6 commits into
base: develop
Choose a base branch
from
Draft

Migrate project to ROS 2 #41

wants to merge 6 commits into from

Conversation

FelipeGdM
Copy link
Member

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

  • Os plugins do ros_control para acionamento dos motores dos robôs precisam ser migrados para seus correspondentes no ros2_control
  • O Gazebo passou a suportar mais engines de renderização além do OGRE, de modo que todo o nosso código específico pra OGRE precisa ser refatorado para o padrão mais genérica SDFormat - Guia oficial como migrar modelos SDF

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_PATH e GAZEBO_MODEL_PATH. Na migração, as duas variáveis passam a se chamar IGN_GAZEBO_RESOURCE_PATH e 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 executar source 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/

Screenshot from 2023-04-13 14-01-15

Em resumo

  • Migrar ros_control para ros2_control
  • Migrar launchfiles para python
  • Atualizar modelo visual do robô (remover scripts OGRE)

@LucasHaug
Copy link
Member

Finalmente a tão esperada migração para ROS 2

👀 👀 👀 👀

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_PATH e GAZEBO_MODEL_PATH. Na migração, as duas variáveis passam a se chamar IGN_GAZEBO_RESOURCE_PATH e 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 executar source 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/

Screenshot from 2023-04-13 14-01-15

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
Copy link
Member Author

Tava vendo aqui, vi uma pessoa colocando isso daí no próprio launchfile em python.

Usar um env hook facilita a extensão do pacote, pois a configuração é feita automaticamente sempre que o travesim estiver disponível no workspace. Se a configuração for feita no launchfile, a gente fica preso ao uso de ros2 launch e perde a capacidade de iniciar as coisas com ros2 run

Precisa migar também os plugins tipo da câmera e do diff drive?

O diff drive eu tava colocando dentro do pacote de mudanças ros2_control, o plugin da câmera eu tinha esquecido de contar hehehe 😁

@FelipeGdM
Copy link
Member Author

Screenshot from 2023-05-02 15-52-00

Cores pseudo aleatórias

@FelipeGdM
Copy link
Member Author

Screenshot from 2023-05-02 17-25-39

Habemus camera \o/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants