BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Migrando duas grandes bases de código robótico ROS1 para ROS2

Migrando duas grandes bases de código robótico ROS1 para ROS2

Em 2018, o Robot Operating System 2 (ROS2) foi lançado como sucessor do ROS1. Na ROSCon 2019, vários palestrantes compartilharam suas experiências na migração do ROS1 para o ROS2. As lições foram compartilhadas em duas palestras distintas: O projeto Autoware, e uma Demonstração de portabilidade para a Rover Robotics.

O projeto Autoware aproveitou a oportunidade para reiniciar o design do software visando melhor funcionamento no ROS2. O Autoware começou como Autoware.AI, que é um software open source para veículos autônomos. Os projetistas basearam o software no ROS1, o que foi excelente para a criação de protótipos. No entanto, há três razões pelas quais o Autoware não era adequado para a fabricação de produtos certificáveis. O principal motivo é que o ROS1 não é certificável, e isso levaria muitos anos, tempo e esforço das pessoas. O determinismo e a segurança da memória do aplicativo Autoware AI também não permitiam o feito. Por último, mas não menos importante, restam menos de seis anos de vida útil de suporte, pois o fim da vida útil do ROS1 está especificado para o ano de 2025. Portanto, a Autoware decidiu iniciar o autoware.auto como sendo um novo software, que era mais trabalhoso, mas provava obter melhor resultados no longo prazo.

A mudança para o ROS2 forneceu vários benefícios em relação ao ROS1. Um deles foi o lançamento gerenciado, no qual podemos especificar em que ordem os nós serão lançados. Outro benefício foi o protocolo de comunicação DDS (Data Distribution Service), que pode transmitir mensagens com cópia zero, economizando recursos de CPU e memória. Em termos de desenvolvimento, o ROS2 se dedica mais ao aumento da cobertura de testes, documentação cada vez mais compreensível e integração contínua para obter uma certificação de software.

Para garantir o uso agradável e contínuo do Autoware existente, a equipe de engenharia adicionou suporte do novo projeto ao projeto antigo, isto foi possível devido a ponte entre as duas versões. Dessa forma, novos recursos de alta qualidade são introduzidos no novo projeto, garantindo a satisfação dos atuais colaboradores. Em termos de colaboração, devido à maior qualidade esperada, o Autoware precisava ter uma cobertura de teste maior, um documento de design para todas as principais contribuições, além de escrever e testar a execução determinística. Para incentivar os colaboradores atuais e os novos, estão sendo orientados pelas pessoas que trabalham com o Autoware. Eles passam pelo processo de contribuição para o Autoware com colaboradores potencialmente interessados, que também recebem incentivos frequentes.

Uma segunda palestra foi proferida por Nick Fragal e Nick Padilla, ambos trabalhando na Rover Robotics. Ambos usaram o ROS1 para compartilhar o código de robótica comum e para minimizar a reescrita de tarefas recorrentes. Eles querem usar o ROS2 para compartilhar códigos robóticos confiáveis. O comitê técnico de direção do ROS2 contém diversas pessoas que trabalham em grandes empresas que levam a sério a confiabilidade e, portanto, pode-se esperar que o ROS2 seja adotado por estas organizações. Isso fornece ao ROS2 muitas promessas.

Fragal falou sobre a aplicação: um robô de entrega de camisetas que leva camisetas aos participantes de uma conferência. Os Nicks fizeram uma demonstração usando o ROS1 e queriam migrá-lo para o ROS2. A portabilidade inicial correu bem, mas quando fizeram uma nova demonstração em uma conferência com wifi lento, tiveram alguns problemas.

O motivo dos problemas foi o protocolo DDS, que não funcionou bem em um link de wifi lento. Para resolver esse problema, analisaram os parâmetros que podem ser ajustados para fazer o DDS funcionar melhor em uma rede lenta. Também compararam diferentes implementações do protocolo DDS e trabalharam em conjunto com os fornecedores para melhorar a implementação. Eventualmente, vários provedores de DDS podem ser usados para ativar o software no robô em até 10 segundos. A mensagem dada foi escolher um middleware DDS com cópia zero para evitar problemas relacionados à movimentação de imagens na memória.

No geral, a Rover Robotics estima que gastaram aproximadamente 60% de tempo observando o protocolo de comunicação ao portar esta demonstração. No entanto, agora que está funcionando melhor, esperam concentrar 90% dos esforços no código de navegação e de aplicação.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT