Uuv_simulator: Liberação noética

Eu estou trabalhando nisso ;)

Bem, isso é muito rápido! :D

Nem todas as dependências estão liberadas para noetic ainda, por exemplo joy e joy_teleop, necessárias para uuv_teleop.
https://github.com/ros-drivers/joystick_drivers/issues/170
https://github.com/ros-teleop/teleop_tools/issues/51

isso é verdade, o primeiro passo seria adicionar um job no Travis para que possamos verificar quando todas as dependências podem ser encontradas.

Eu fiz alguns experimentos para atualizar a compilação do Travis. https://github.com/arturmiller/uuv_simulator/tree/noetic
https://travis-ci.org/github/arturmiller/uuv_simulator/jobs/693993787
Não é fácil implementar isso, porque industrial_ci fez grandes mudanças. Não há mais argumentos BEFORE_SCRIPT e AFTER_SCRIPT e eles foram movidos para colcon em vez de catkin.
Como eu sei catkin_tools também não está disponível para noetic, ainda.

sim, eu vi que eles disponibilizaram uma versão legacy com a configuração antiga. Eu fiz alguns experimentos localmente na minha máquina aqui, há algumas coisas para verificar ainda.

Agora sou capaz de construir e testar o uuv_simulator com as recentes alterações do industrial_ci:
https://github.com/arturmiller/uuv_simulator/tree/noetic
https://travis-ci.org/github/arturmiller/uuv_simulator/builds/696565670
A maioria das alterações é direta, mas há um problema que requer alguma forma de refatoração. Os testes de uuv_gazebo_ros_plugins requerem uuv_descriptions. Isso resulta em uma dependência circular. Por enquanto removi os testes em uuv_gazebo_ros_plugins.
Além disso, não sei por que o script run_tests.sh é usado em vez do procedimento de compilação do industrial_ci. Eu usei a compilação no test runner, porque catkin_tools ainda não foi lançado no Ubuntu 20.04. Isso parece funcionar bem.
Se você quiser mesclar isso, eu limparia meus commits e criaria vários problemas e PRs, onde podemos discutir tudo, se necessário.

Eu esqueci de mencionar. Os pacotes joy e joy_teleop ainda não estão disponíveis. Por enquanto, para que as compilações do travis sejam bem-sucedidas, comentei essas dependências no package.xml. Construir e testar não os exigem. Mas ainda está bloqueando a liberação noética.

@arturmiller Alguma atualização?
Posso usar este repositório para ROS noetic agora, já que joy e joy_teleop agora estão disponíveis para ROS noetic?

Ressalto. Estaria muito interessado em saber se o UUV Sim é bom para ir (ou seria bom com algum trabalho no lado do usuário ao instalar) no Noetic. Meu lugar é totalmente no Python3 e atualmente estou lidando com a dor de cabeça de coagir o Melodic a trabalhar com o Python3.

Sim joy e joy_teleop já estão disponíveis para noetic. catkin_tools ainda não está devidamente portado, mas pode ser facilmente instalado a partir da fonte com pip.
@purvikpatel Eu não recomendaria usar meu garfo diretamente. A compilação está passando, mas não fiz nenhum teste manual. Tenho certeza de que não funcionará, pois a cobertura do teste não é muito alta. Além disso, esta ramificação está cheia de commits "exploratórios", porque não consegui duplicar exatamente a compilação do travis localmente.
Eu esperava mais interesse dos mantenedores sobre isso, mas eles parecem estar bastante ocupados. Minha última edição #406 quase não recebeu atenção.
Eu gostaria de ver este repositório sendo atualizado, mas também poderia criar um fork de trabalho para noetic e Python3 (se o interesse em geral for grande o suficiente e se a manutenção do repositório continuar faltando). No entanto, eu não seria capaz de manter este projeto ainda mais e não posso liberar nenhum pacote debian.

catkin_tools ainda não está devidamente portado, mas pode ser facilmente instalado a partir da fonte com pip.

Na verdade, acho que isso está resolvido. Do Ubuntu 20.04 eu posso simplesmente fazer sudo apt install python3-catkin-tools

Alguma atualização sobre o andamento disso? Eu tentei o repo que @arturmiller fez e está me dando um erro free(): double free detected in tcache 2 no gazebo.

Catkin tools está operacional no Noetic agora.
Alguém está disposto a liberar isso para a Noetic? :slightly_smiling_face:

Você está fazendo um trabalho incrível! Agradeço este lançamento real: https://github.com/uuvsimulator/uuv_simulator/pull/423/commits/66474bd3648f9fa2d0cf1d42e153ee08f3d3da7e#diff -71b515d752a471114f16806cd6bf541d62e8d81e79f4fbce636cd6bf541d62e8d81e79f4fbce63d62e8d81e79f4fbce636cd6bf541d62e8d81e79f4fbce636
por adaptar a versão melódica de uuv para noetic, mal posso esperar pelo lançamento oficial. Você é incrível.
(postando isso aqui para aqueles que tentam desesperadamente fazê-lo funcionar no noetic por enquanto).

Ei a todos. Até que haja um lançamento oficial para o noetic, alguém tem um fork funcional do repositório ou um conjunto de instruções que possam ser usadas para instalá-lo? Aprecie todo o trabalho incrível que está sendo feito aqui!

confira o link do comentário acima ;) Foi adicionado lá para facilitar sua vida.

Obrigado! Tentei configurar tudo com base nesse link e examinar as diferentes solicitações de pull e seus comentários. Cheguei a maior parte do caminho, mas estou recebendo o seguinte erro depois de construir tudo e tentar executá-lo:

ERROR: cannot launch node of type [message_to_tf/message_to_tf]: message_to_tf

Além disso (não tenho certeza se está relacionado), mas o Gazebo está apenas mostrando uma tela preta, mesmo que meu código esteja realmente em execução.

Compilei o processo que usei aqui: https://github.com/Waterloo-Aquadrone/aquadrone2020_dev_workspace/blob/master/noetic_setup.md.

Há uma boa chance de eu estar cometendo um erro idiota. Eu realmente aprecio qualquer ajuda em tudo. Muito obrigado por todo o trabalho incrível!

bem, até onde eu sei, message_to_tf refere-se apenas a um arquivo de inicialização e ac em uuv_description ~para verificar novamente~.
Se tudo compilado, você pode assumir que instalou corretamente o uuv_simulation.

Convido você a fazer esta pergunta em respostas ros (verifique: https://answers.ros.org/question/67488/roslaunch-error-error-cannot-launch-node-of-type/) ou stackoverflow.

Estou tentando implementar esta versão do Neotic e estou enfrentando um segfault quando adiciono meu arquivo robot. Eu reduzi para sempre que eu adiciono um sensor. Eu posso gerar meu robô sem nenhum sensor e ele flutua e funciona. O mesmo código funciona na versão melódica, mas não na noética.

Aqui está um exemplo de um bloco de código que causará um segfault. Tenho quase certeza de que o namespace e o inertial_reference_frame existem enquanto outros códigos funcionam.

<xacro:include filename="$(find uuv_sensor_ros_plugins)/urdf/sensor_snippets.xacro"/>

<xacro:default_imu_macro
    namespace="${namespace}"
    parent_link="${namespace}/base_link"
    inertial_reference_frame="${inertial_reference_frame}">
    <origin xyz="0 0 0" rpy="0 0 0"/>
</xacro:default_imu_macro>

O Gazebo apenas imprime "Falha de segmentação (núcleo despejado)" e, em seguida, o processo morre. Alguém tem alguma idéia?

Se mais alguém estiver tendo esse problema, adicione return true; à linha 144 do ROSBasePlugin.cc.
Eu também tive muitos erros relacionados ao ned. Como solução temporária, excluí as linhas 207 e 208 de UnderwaterObjectROSPlugin.cc

Enfrentando este tópico novamente :) @musamarcusso você ou qualquer outro mantenedor lançará esses pacotes para a Noetic no curto prazo? Se não, ou se você estiver ocupado, deixe-me saber como posso ajudar.

@hidmic , infelizmente, não tenho acesso total ao repositório para gerenciar a portabilidade para o Noetic, talvez esperando alguma resposta do @musamarcusso ou trabalhando em algum fork :/

Olá @pxalcantara! Há quanto tempo :)

talvez esperando alguma resposta do @musamarcusso ou trabalhando em algum fork

Entendo. Não bifurcar (ou seja, não dividir os esforços entre as cópias deste repositório) seria o melhor IMHO.