A partir do Ubuntu22.04 ou de junho de 2025, o suporte oficial de base ao ROS1 deixou de ser atualizado, recomendando-se a utilização do sistema ROS2, o ROS 2 em termos de arquitetura, tempo real, segurança e eco-extensibilidade, significativamente melhor do que o ROS 1, se o desenvolvimento do novo projeto for recomendado para utilizar diretamente o ROS2, mas se for necessário migrar para o ROS2, é necessário fazer um compromisso entre os recursos existentes e os ganhos a longo prazo. Relação pormenorizada do suporte da versão Ubuntu, ver ligação [ROS e Ubuntu versões diferentes da relação] A comparação dos dois quadros a analisar é a seguinte:
| Versão ROS 2 | Versão Ubuntu | LTS ou não | Tempo de libertação |
| Jazzy | 24.04 (Nobre) | Sim (LTS) | 2024 |
| De kilt | 24.04(Nobre) | Não | 2025-05 |
História e desenvolvimento
- ROS1: Desenvolvido pela Universidade de Stanford e pela Willow Garage, centrado na investigação e na criação de protótipos.
- ROS2: Iniciada em 2014, visa a robótica de nível industrial com middleware DDS para melhorar a capacidade em tempo real, o suporte multiplataforma e a segurança.
Conclusão: O ROS1 é mais adequado para a investigação e a criação de protótipos, enquanto o ROS2 é ideal para a implantação industrial e comercial.
2. Arquitetura do sistema
| Dimensão | ROS1 | ROS2 |
| Arquitetura de base | Adoção de uma arquitetura centralizada, com base no nó mestre (gestor de nós) para efetuar o registo e a comunicação dos nós. | Arquitetura distribuída, comunicação direta entre nós, sem necessidade de um mestre, suporte do mecanismo de descoberta dinâmica. |
| Modelo de comunicação | Sistema de comunicação personalizado baseado no protocolo TCP/UDP, que tem problemas como atrasos, perda de pacotes e incapacidade de encriptação. | Protocolo de comunicação normalizado baseado em DDS, com suporte de tempo real, encriptação e interação entre plataformas. |
| Fiabilidade | Depende do TCP para comunicação ponto a ponto, propenso a perda de pacotes | A transmissão fiável é garantida por políticas de QoS (por exemplo, fiável). |
| Sistema de compilação | Usa os sistemas de compilação rosbuild (early) e catkin. | Introduziu-se um sistema de compilação de elementos para suportar uma gestão de dependências mais flexível e a compilação em vários idiomas. |
3. Experiência do utilizador
| Dimensão | ROS1 | ROS2 |
| Curva de aprendizagem | Recursos comunitários ricos e documentação madura, adequados para começar. | As novas funcionalidades aumentam os custos de aprendizagem (por exemplo, configuração DDS, depuração em tempo real), mas são mais fáceis de manter a longo prazo. |
| Custos de migração | Os projectos ROS 1 precisam de refactorizar a lógica de comunicação, a gestão dos nós e o sistema de compilação para migrarem para o ROS 2. | Estão disponíveis ferramentas de migração (por exemplo, ros1_bridge) para interoperar entre os nós ROS 1 e ROS 2. |
| Depuração e cadeia de ferramentas | Baseando-se em ferramentas como o roslaunch e o rviz, o processo de depuração é mais tradicional. | Nova estrutura de lançamento (que suporta a configuração Python), sistema de registo integrado e melhores ferramentas de teste. |
| Comunidade e Ecologia | O ecossistema é vasto, mas algumas funcionalidades são difíceis de alargar devido a limitações arquitectónicas. | As novas funcionalidades são mais fáceis de integrar (por exemplo, uma maior integração com o Gazebo e as tecnologias Web) e o ecossistema continua a expandir-se. |
4. Comparação de tecnologias-chave
| Dimensão | ROS1 | ROS2 |
| Comunicação entre nós | A comunicação entre pares é estabelecida através do registo Master. | Os nós descobrem automaticamente e comunicam diretamente uns com os outros através de DDS. |
| Mensagens | Utiliza um tipo de mensagem personalizado (.msg) e depende da implementação do roscpp/rospy. | Gerar mensagens multilingues baseadas em IDL (Interface Definition Language) para uma melhor compatibilidade. |
| Tolerância a falhas | A falha do mestre pode provocar a avaria de todo o sistema. | Arquitetura distribuída para evitar um único ponto de falha, os nós podem entrar/sair dinamicamente. |
5. Diferenças de sintaxe
| Dimensão | ROS1 | ROS2 |
| Sintaxe de criação de nós | Usa ros::NodeHandle para gerenciar os nós, depende do roscore para iniciar o gerenciador centralizado. | Utilize rclcpp::Node ou rclpy::Node para criar nós diretamente sem roscore, suporta arquitetura distribuída. |
| Mecanismo de comunicação | Com base no protocolo TCP/UDP personalizado para conseguir a comunicação, é necessário gerir manualmente o registo e a descoberta de nós. | Com base na norma DDS (Data Distribution Service), os nós descobrem e comunicam automaticamente entre si. |
| Definição da mensagem | Utilizar o ficheiro .msg para definir o tipo de mensagem, confiar na implementação do roscpp/rospy. | Utilize a IDL (Linguagem de Definição de Interface) para gerar mensagens em vários idiomas para uma melhor compatibilidade. |
| Lançar ficheiros | Utilizar XML para escrever um ficheiro .launch, função única, difícil de configurar dinamicamente. | Utilizar Python para escrever ficheiros .launch.py, suportar a lógica dinâmica (como o julgamento condicional, a passagem de parâmetros). |
6. Diferenças na utilização efectiva
| Dimensão | ROS1 | ROS2 |
| Suporte multilingue | Suporta principalmente C++ e Python, outras linguagens precisam de ser adaptadas. | Suporte alargado para outras linguagens (por exemplo, Rust, Java) e compatibilidade entre linguagens através da linguagem de definição de interfaces (IDL). |
| Sistema de compilação | Baseia-se no sistema de compilação catkin, que requer uma adesão estrita à estrutura do espaço de trabalho. | Utilize o sistema de compilação ament para uma gestão de dependências mais flexível e compilações em vários idiomas. |
| Apoio em tempo real | Fraco desempenho em tempo real, difícil de satisfazer as necessidades do controlo industrial em tempo real. | Melhorar o suporte para sistemas em tempo real (por exemplo, o rclcpp do ROS 2 fornece agendamento de threads em tempo real). |
| Segurança | Falta de mecanismos nativos de encriptação e autenticação. | Suporta extensões de segurança DDS (DDS-Security) para fornecer autenticação, encriptação de dados e controlo de acesso. |
| Suporte multiplataforma | Funciona principalmente em sistemas Linux com suporte limitado para Windows/macOS. | Suporta múltiplas plataformas, como Linux, Windows, macOS, RTOS, etc., e divide claramente as plataformas em Nível 1 (ativamente apoiado pelo governo oficial) e Nível 2 (apoiado pela comunidade) para reforçar a compatibilidade entre sistemas. |
| Ferramentas de depuração | Baseando-se em ferramentas tradicionais como o roslaunch e o rviz, o sistema de registo é relativamente básico. | Fornecer um sistema de registo integrado (por exemplo, RCLCPP_INFO), suporte para scripts Python e melhores ferramentas de teste. |
| Tolerância a falhas | Uma falha do roscore pode provocar a avaria de todo o sistema. | Arquitetura distribuída para evitar um único ponto de falha, os nós podem entrar/sair dinamicamente. |
7. Cenários de aplicação típicos
- ROS 1: Educação, projectos de investigação (por exemplo, navegação de robôs móveis, SLAM), cenários que não requerem tempo real e segurança elevados. Se o projeto estiver maduro e não exigir funcionalidades em tempo real, de segurança ou multiplataforma, e depender de um grande número de recursos ecológicos do ROS 1, continue a utilizar o ROS 1.
- ROS 2: Automação industrial, condução autónoma, drones e outros cenários que requerem um elevado suporte em tempo real, segurança e multiplataformas, bem como a manutenção a longo prazo de projectos de grande escala (por exemplo, robots de entrega, Robô industrialrobôs médicos). Os projectos que exigem estabilidade de nível industrial, controlo em tempo real, encriptação segura ou implantação em várias plataformas têm preferência pelo ROS 2.
8. Compatibilidade de hardware e plataforma
- ROS1: Suporta principalmente Linux (Ubuntu).
- ROS2: Suporta nativamente Linux, Windows, macOS e plataformas incorporadas.
9. Apoio ao ecossistema e à comunidade
- ROS1: Grande número de pacotes e uma comunidade ativa.
- ROS2: Ecossistema em rápido crescimento, mas o número de pacotes ainda está a recuperar.
Conclusão: O ROS1 tem um ecossistema maduro, enquanto o ROS2 está a recuperar rapidamente.
10. Custo de migração e atualização
- As APIs são incompatíveis, exigindo reescrita de código.
- Os controladores podem necessitar de adaptação; o ros1_bridge pode ajudar na migração gradual.
Conclusão: Os custos de migração são significativos, mas os riscos podem ser reduzidos através de actualizações faseadas.
11. Segurança e normas industriais
- ROS1: Não existem mecanismos de segurança nativos.
- ROS2: Está em conformidade com as normas de segurança DDS e pode integrar OPC UA e TSN.
Conclusão: O ROS2 é mais adequado para aplicações industriais e críticas em termos de segurança.
Tendências futuras e roteiro
- ROS1Noetic é a versão final, mantida até 2025.
- ROS2segue uma estratégia de suporte a longo prazo (LTS) com actualizações activas de funcionalidades.
Conclusão: A tendência é claramente favorável ao ROS2.
Conclusões e recomendações
Para investigadores ou principianteso ROS1 continua a ser uma escolha madura e estável; para utilizadores industriais ou equipas comerciais, As vantagens do ROS2 em termos de sistemas distribuídos, desempenho em tempo real e segurança trazem valor a longo prazo.
Conselhos práticos: Avaliar a versão do ROS no início do planeamento do projeto e tomar decisões com base na maturidade do ecossistema e nas capacidades da equipa.
