A partir do Ubuntu 22.04 ou de junho de 2025, o suporte oficial básico deixará de ser atualizado para o ROS 1, sendo recomendado o uso do sistema ROS 2. O ROS 2 apresenta uma arquitetura, tempo real, segurança e extensibilidade ecológica significativamente melhores do que o ROS 1. Para o desenvolvimento de novos projetos, recomenda-se a utilização direta do ROS 2; no entanto, caso seja necessária uma migração, deve ponderar-se o equilíbrio entre os recursos existentes e os ganhos a longo prazo. Para obter informações detalhadas sobre a relação de suporte das versões do Ubuntu, consulte o link A relação entre o ROS e as diferentes versões do Ubuntu, a seguinte comparação das duas frameworks a analisar:
| Versão do ROS 2 | Versão do Ubuntu | LTS ou não | Data de lançamento |
| Jazzy | 24.04 (Noble) | Sim (LTS) | 2024 |
| De kilt | 24.04 (Noble) | Não | 2025-05 |
História e Desenvolvimento
- ROS1: Desenvolvido pela Universidade de Stanford e pela Willow Garage, com foco na investigação e na criação de protótipos.
- ROS2: Lançado em 2014, destina-se à robótica de nível industrial com middleware DDS, com o objetivo de melhorar a capacidade em tempo real, o suporte multiplataforma e a segurança.
Conclusão: O ROS1 é mais adequado para investigação e prototipagem, enquanto o ROS2 é ideal para implementação industrial e comercial.
2. Arquitetura do sistema
| Dimensão | ROS1 | ROS2 |
| Arquitetura Central | Adotando uma arquitetura centralizada, que recorre ao nó mestre (gestor de nós) para efetuar o registo e a comunicação entre os nós. | Arquitetura distribuída, comunicação direta entre nós, sem necessidade de um nó mestre, compatível com mecanismos de deteção dinâmica. |
| Modelo de Comunicação | Sistema de comunicação personalizado baseado no protocolo TCP/UDP, que apresenta problemas como atrasos, perda de pacotes e incapacidade de encriptação. | Protocolo de comunicação padronizado baseado em DDS, que suporta interação em tempo real, encriptação e interoperabilidade entre plataformas. |
| Fiabilidade | Baseia-se no TCP para a comunicação ponto a ponto, sendo suscetível à perda de pacotes | A transmissão fiável é garantida pelas políticas de QoS (por exemplo, «Reliable»). |
| Sistema de compilação | Utiliza os sistemas de compilação rosbuild (versão inicial) e catkin. | Foi introduzido um sistema de compilação automatizado para permitir uma gestão mais flexível das dependências e a compilação em várias linguagens. |
3. Experiência do utilizador
| Dimensão | ROS1 | ROS2 |
| Curva de aprendizagem | Recursos abundantes da comunidade e documentação bem desenvolvida, ideais para quem está a dar os primeiros passos. | As novas funcionalidades aumentam os custos de aprendizagem (por exemplo, configuração do DDS, depuração em tempo real), mas são mais fáceis de manter a longo prazo. |
| Custos de migração | Os projetos ROS 1 precisam de refatorar a lógica de comunicação, a gestão de 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 permitir a interoperabilidade entre nós do ROS 1 e do ROS 2. |
| Depuração e conjunto de ferramentas | Com o recurso a ferramentas como o roslaunch e o rviz, o processo de depuração é mais tradicional. | Nova estrutura de lançamento (compatível com a configuração em Python), sistema de registo integrado e melhores ferramentas de teste. |
| Comunidade e Ecologia | O ecossistema é vasto, mas algumas funcionalidades são difíceis de ampliar devido a limitações arquitetónicas. | As novas funcionalidades são mais fáceis de integrar (por exemplo, uma integração mais profunda com o Gazebo e com as tecnologias Web) e o ecossistema continua a expandir-se. |
4. Comparação das principais tecnologias
| Dimensão | ROS1 | ROS2 |
| Comunicação entre nós | A comunicação entre pares é estabelecida através do registo do Master. | Os nós detetam-se automaticamente e comunicam diretamente entre si através do DDS. |
| Mensagens | Utiliza o tipo de mensagem personalizado (.msg) e baseia-se na implementação do roscpp/rospy. | Gerar mensagens multilingues com base na IDL (Linguagem de Definição de Interfaces) para uma melhor compatibilidade. |
| Tolerância a falhas | Uma falha no servidor principal pode provocar a paragem de todo o sistema. | Arquitetura distribuída para evitar um único ponto de falha; os nós podem entrar e sair dinamicamente. |
5. Diferenças sintáticas
| Dimensão | ROS1 | ROS2 |
| Sintaxe para a criação de nós | Utilize o ros::NodeHandle para gerir os nós, o qual recorre ao roscore para iniciar o gestor centralizado. | Utilize rclcpp::Node ou rclpy::Node para criar nós diretamente sem o roscore, que suporta uma arquitetura distribuída. |
| Mecanismo de comunicação | Com base num protocolo TCP/UDP personalizado para estabelecer a comunicação, é necessário gerir manualmente o registo e a deteção dos nós. | Com base na norma DDS (Data Distribution Service), os nós identificam-se automaticamente e comunicam entre si. |
| Definição da mensagem | Utilize um ficheiro .msg para definir o tipo de mensagem, recorrendo à implementação do roscpp/rospy. | Utilize a IDL (Linguagem de Definição de Interfaces) para gerar mensagens multilingues, de modo a garantir uma melhor compatibilidade. |
| Ficheiros de arranque | Utilize XML para criar um ficheiro .launch, com uma única função, difícil de configurar dinamicamente. | Utilize o Python para criar um ficheiro .launch.py que permita a implementação de lógica dinâmica (como decisões condicionais e passagem de parâmetros). |
6. Diferenças na utilização efetiva
| Dimensão | ROS1 | ROS2 |
| Suporte multilingue | Suporta principalmente C++ e Python; outras linguagens têm de ser adaptadas. | Suporte alargado a linguagens adicionais (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 exige o cumprimento rigoroso da 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árias linguagens. |
| Suporte em tempo real | Desempenho em tempo real insuficiente, sendo difícil satisfazer as necessidades do controlo industrial em tempo real. | Melhorar o suporte para sistemas de tempo real (por exemplo, o rclcpp do ROS 2 oferece agendamento de threads em tempo real). |
| Segurança | Ausência de mecanismos nativos de encriptação e autenticação. | Suporta as extensões de segurança DDS (DDS-Security) para proporcionar autenticação, encriptação de dados e controlo de acesso. |
| Suporte multiplataforma | Funciona principalmente em sistemas Linux, com suporte limitado para Windows e macOS. | Suporta várias plataformas, tais como Linux, Windows, macOS, RTOS, etc., e divide claramente as plataformas em Nível 1 (suportadas ativamente pelo governo oficial) e Nível 2 (suportadas pela comunidade), a fim de 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 a scripts em Python e melhores ferramentas de teste. |
| Tolerância a falhas | Uma falha no Roscore pode provocar a paragem de todo o sistema. | Arquitetura distribuída para evitar um único ponto de falha; os nós podem entrar e sair dinamicamente. |
7. Cenários típicos de aplicação
- ROS 1: Educação, projetos de investigação (por exemplo, navegação de robôs móveis, SLAM), cenários que não exigem um elevado desempenho em tempo real nem segurança. Se o projeto estiver maduro e não exigir funcionalidades em tempo real, de segurança ou multiplataforma, e se basear num grande número de recursos do ecossistema do ROS 1, continue a utilizar o ROS 1.
- ROS 2: Automação industrial, condução autónoma, drones e outros cenários que exigem elevado desempenho em tempo real, segurança e compatibilidade entre plataformas, bem como a manutenção a longo prazo de projetos de grande escala (por exemplo, entrega robôs, irobôs industriais, robôs médicos). Os projetos que exigem estabilidade de nível industrial, controlo em tempo real, encriptação segura ou implementação multiplataforma são preferíveis ao ROS 2.
8. Compatibilidade de hardware e plataformas
- É compatível principalmente com o Linux (Ubuntu).
- RO suporta nativamente Linux, Windows, macOS e plataformas embarcadas.
9. Ecossistema e apoio à comunidade
- ROS1:Um grande número de pacotes e uma comunidade ativa.
- ROS2: Um ecossistema em rápido crescimento, mas o número de pacotes ainda está a tentar acompanhar esse ritmo.
Conclusão: O ROS1 possui um ecossistema maduro, enquanto o ROS2 está a ganhar terreno rapidamente.
10. Custos de migração e atualização
- As APIs são incompatíveis, o que obriga a reescrever o código.
- Os controladores poderão ter de ser adaptados; o ros1_bridge pode ajudar na migração gradual.
Conclusão: Os custos de migração são elevados, mas os riscos podem ser reduzidos através de atualizações faseadas.
11. Normas de segurança e industriais
- ROS1: Não existem mecanismos de segurança nativos.
- ROS2: Cumpre as normas de segurança DDS e permite a integração com OPC UA e TSN.
Conclusão: O ROS2 é mais adequado para aplicações industriais e em que a segurança é fundamental.
Tendências futuras e roteiro
- ROS1A Noetic é a versão final, cuja manutenção se prolongará até 2025.
- ROS2 segue uma estratégia de Suporte de Longo Prazo (LTS) com atualizações ativas de funcionalidades.
Conclusão: A tendência aponta claramente a favor do ROS2.
Conclusão e Recomendações
Para investigadores ou principiantes, o ROS1 continua a ser uma opção madura e estável; para utilizadores industriais ou equipas comerciais, as vantagens do ROS2 em sistemas distribuídos, no desempenho em tempo real e na segurança trazem valor a longo prazo.
Conselhos práticos: Avalie a versão do ROS numa fase inicial do planeamento do projeto e tome decisões com base na maturidade do ecossistema e nas capacidades da equipa.
