Desde Ubuntu22.04 o junio de 2025, la base oficial ya no actualizar el apoyo ROS1, recomienda el uso del sistema ROS2, ROS 2 en la arquitectura, en tiempo real, la seguridad y la eco-extensibilidad significativamente mejor que el ROS 1, si el desarrollo de nuevos proyectos se recomienda utilizar ROS2 directamente, pero si usted necesita para migrar a un compromiso entre los recursos existentes y las ganancias a largo plazo. Relación detallada de apoyo a la versión de Ubuntu ver enlace [ROS y Ubuntu diferentes versiones de la relación] , la siguiente comparación de los dos marcos a analizar:
| Versión ROS 2 | Versión Ubuntu | LTS o no | Tiempo de liberación |
| Jazzy | 24.04 (Noble) | Sí (LTS) | 2024 |
| Kilted | 24.04(Noble) | No | 2025-05 |
Historia y desarrollo
- ROS1: Desarrollado por la Universidad de Stanford y Willow Garage, centrado en la investigación y la creación de prototipos.
- ROS2: Iniciado en 2014, se centra en la robótica industrial con middleware DDS para mejorar la capacidad en tiempo real, la compatibilidad entre plataformas y la seguridad.
Conclusión: ROS1 es más adecuado para la investigación y la creación de prototipos, mientras que ROS2 es ideal para la implantación industrial y comercial.
2. Arquitectura del sistema
| Dimensión | ROS1 | ROS2 |
| Arquitectura básica | Adopta una arquitectura centralizada y depende del nodo maestro (gestor de nodos) para lograr el registro y la comunicación de los nodos. | Arquitectura distribuida, comunicación directa entre nodos, sin necesidad de Maestro, soporta mecanismo de descubrimiento dinámico. |
| Modelo de comunicación | Sistema de comunicación personalizado basado en el protocolo TCP/UDP, que presenta problemas como el retardo, la pérdida de paquetes y la imposibilidad de cifrar. | Protocolo de comunicación estandarizado basado en DDS, compatible con tiempo real, cifrado e interacción entre plataformas. |
| Fiabilidad | Depende de TCP para la comunicación entre iguales, propensa a la pérdida de paquetes. | La transmisión fiable está garantizada por las políticas de calidad de servicio (por ejemplo, fiable). |
| Sistema de compilación | Utiliza los sistemas de compilación rosbuild (early) y catkin. | Se ha introducido un nuevo sistema de compilación que permite una gestión más flexible de las dependencias y la compilación multilingüe. |
3. Experiencia del usuario
| Dimensión | ROS1 | ROS2 |
| Curva de aprendizaje | Recursos comunitarios ricos y documentación madura, adecuados para empezar. | Las nuevas funciones aumentan los costes de aprendizaje (por ejemplo, configuración de DDS, depuración en tiempo real), pero a la larga son más fáciles de mantener. |
| Costes de migración | Los proyectos ROS 1 necesitan refactorizar la lógica de comunicación, la gestión de nodos y el sistema de compilación para migrar a ROS 2. | Existen herramientas de migración (por ejemplo, ros1_bridge) para interoperar entre nodos ROS 1 y ROS 2. |
| Depuración y cadena de herramientas | Confiando en herramientas como roslaunch y rviz, el proceso de depuración es más tradicional. | Nuevo marco de lanzamiento (compatible con la configuración de Python), sistema de registro integrado y mejores herramientas de prueba. |
| Comunidad y ecología | El ecosistema es amplio, pero algunas funciones son difíciles de ampliar debido a limitaciones arquitectónicas. | Las nuevas funciones son más fáciles de integrar (por ejemplo, mayor integración con Gazebo y las tecnologías Web), y el ecosistema sigue ampliándose. |
4. Comparación de tecnologías clave
| Dimensión | ROS1 | ROS2 |
| Comunicación de nodos | La comunicación entre iguales se establece a través del registro Master. | Los nodos se descubren automáticamente y se comunican directamente entre sí a través de DDS. |
| Mensajería | Utiliza un tipo de mensaje personalizado (.msg), depende de la implementación de roscpp/rospy. | Genere mensajes multilingües basados en IDL (Interface Definition Language) para mejorar la compatibilidad. |
| Tolerancia a fallos | Un fallo en el maestro puede provocar la caída de todo el sistema. | Arquitectura distribuida para evitar un único punto de fallo, los nodos pueden unirse/salir dinámicamente. |
5. Diferencias sintácticas
| Dimensión | ROS1 | ROS2 |
| Sintaxis de creación de nodos | Utiliza ros::NodeHandle para gestionar nodos, depende de roscore para iniciar el gestor centralizado. | Usa rclcpp::Node o rclpy::Node para crear nodos directamente sin roscore, soporta arquitectura distribuida. |
| Mecanismo de comunicación | Basado en el protocolo personalizado TCP/UDP para lograr la comunicación, necesita gestionar manualmente el registro y descubrimiento de nodos. | Basados en el estándar DDS (Data Distribution Service), los nodos se descubren automáticamente y se comunican entre sí. |
| Definición del mensaje | Utilizar el archivo .msg para definir el tipo de mensaje, depender de la implementación de roscpp/rospy. | Utilice IDL (Interface Definition Language) para generar mensajes en varios idiomas y mejorar la compatibilidad. |
| Archivos de lanzamiento | Utiliza XML para escribir el archivo .launch, función única, difícil de configurar dinámicamente. | Utiliza Python para escribir el archivo .launch.py, soporta lógica dinámica (como juicio condicional, paso de parámetros). |
6. Diferencias en el uso real
| Dimensión | ROS1 | ROS2 |
| Soporte multilingüe | Soporta principalmente C++ y Python, otros lenguajes necesitan ser adaptados. | Compatibilidad ampliada con otros lenguajes (por ejemplo, Rust, Java) y compatibilidad entre lenguajes mediante el lenguaje de definición de interfaces (IDL). |
| Sistema de compilación | Se basa en el sistema de compilación catkin, que requiere un estricto cumplimiento de la estructura del espacio de trabajo. | Utilice el sistema de compilación ament para una gestión de dependencias más flexible y compilaciones multilingües. |
| Asistencia en tiempo real | Bajo rendimiento en tiempo real, difícil de satisfacer las necesidades de control industrial en tiempo real. | Mejorar la compatibilidad con sistemas en tiempo real (por ejemplo, rclcpp de ROS 2 ofrece programación de hilos en tiempo real). |
| Seguridad | Falta de mecanismos nativos de cifrado y autenticación. | Admite extensiones de seguridad DDS (DDS-Security) para proporcionar autenticación, cifrado de datos y control de acceso. |
| Soporte multiplataforma | Funciona principalmente en sistemas Linux con compatibilidad limitada con Windows/macOS. | Admite múltiples plataformas, como Linux, Windows, macOS, RTOS, etc., y divide claramente las plataformas en nivel 1 (apoyadas activamente por el gobierno oficial) y nivel 2 (apoyadas por la comunidad) para reforzar la compatibilidad entre sistemas. |
| Herramientas de depuración | Basado en herramientas tradicionales como roslaunch y rviz, el sistema de registro es relativamente básico. | Proporcionar un sistema de registro integrado (por ejemplo, RCLCPP_INFO), compatibilidad con scripts de Python y mejores herramientas de prueba. |
| Tolerancia a fallos | Un fallo en el roscore puede provocar la caída de todo el sistema. | Arquitectura distribuida para evitar un único punto de fallo, los nodos pueden unirse/salir dinámicamente. |
7. Escenarios típicos de aplicación
- ROS 1: Educación, proyectos de investigación (por ejemplo, navegación de robots móviles, SLAM), escenarios que no requieran un alto tiempo real y seguridad. Si el proyecto es maduro y no requiere características de tiempo real, seguridad o multiplataforma, y depende de un gran número de recursos ecológicos de ROS 1, siga utilizando ROS 1.
- ROS 2: Automatización industrial, conducción autónoma, drones y otros escenarios que requieren un alto tiempo real, seguridad y soporte multiplataforma, así como mantenimiento a largo plazo de proyectos a gran escala (Ej, robots de reparto, Robot industrialrobots médicos). Los proyectos que requieren estabilidad de grado industrial, control en tiempo real, cifrado seguro o despliegue multiplataforma se prefieren a ROS 2.
8. Compatibilidad de hardware y plataformas
- ROS1: Soporta principalmente Linux (Ubuntu).
- ROS2: Compatible de forma nativa con Linux, Windows, macOS y plataformas integradas.
9. Ecosistema y apoyo comunitario
- ROS1: Gran número de paquetes y una comunidad activa.
- ROS2: Ecosistema en rápido crecimiento, pero el número de paquetes aún no ha alcanzado su nivel.
Conclusión: ROS1 tiene un ecosistema maduro, mientras que ROS2 se está poniendo al día rápidamente.
10. Coste de migración y actualización
- Las API son incompatibles, lo que obliga a reescribir el código.
- Los controladores pueden necesitar adaptación; ros1_bridge puede ayudar con la migración gradual.
Conclusión: Los costes de migración son significativos, pero los riesgos pueden reducirse mediante actualizaciones escalonadas.
11. Seguridad y normas industriales
- ROS1: No hay mecanismos de seguridad nativos.
- ROS2: Cumple las normas de seguridad DDS y puede integrar OPC UA y TSN.
Conclusión: ROS2 es más adecuado para aplicaciones industriales y críticas desde el punto de vista de la seguridad.
Tendencias futuras y hoja de ruta
- ROS1Noetic es la versión final, que se mantendrá hasta 2025.
- ROS2sigue una estrategia de soporte a largo plazo (LTS) con actualizaciones activas de funciones.
Conclusión: La tendencia favorece claramente a ROS2.
Conclusiones y recomendaciones
Para investigadores o principiantesROS1 sigue siendo una opción madura y estable; para usuarios industriales o equipos comerciales, Las ventajas de ROS2 en sistemas distribuidos, rendimiento en tiempo real y seguridad aportan valor a largo plazo.
Consejos prácticos: Evalúe la versión de ROS al principio de la planificación del proyecto y tome decisiones basadas en la madurez del ecosistema y las capacidades del equipo.
