-
Notifications
You must be signed in to change notification settings - Fork 0
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
base: develop
Are you sure you want to change the base?
Conversation
👀 👀 👀 👀
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.
Tava vendo aqui, vi uma pessoa colocando isso daí no próprio launchfile em python.
Meo deos que doidera ahushuashaushasuhas. Nossa agora é o gazebo que precisa de uma ponte, parece que o jogo virou auhshuashuashuash.
Nossa que coisa bonita ahusuhhushuashuahsu
Precisa migar também os plugins tipo da câmera e do diff drive? |
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
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 😁 |
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_PATH
eGAZEBO_MODEL_PATH
. Na migração, as duas variáveis passam a se chamarIGN_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 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