- roscore(或者说master)的问题。在进行压力测试时，系统连续运行长了，master莫名宕机，某个节点可能突然失效。单master结构不利于多个机器人组成的集群
- 严重依赖Ubuntu，不同的Ubuntu版本对应不同的ROS的版本
- ROS延迟很大，断网再连接时会挂掉
- 参数服务器机制设计不好，程序退出但roscore不退出时，参数没有更新，或者说还留在参数服务器里
- 安装与运行体积较大，运行在配置较低的ARM上会占用过多资源
- ROS通信的本质是XML-RPC机制，造成了实时性差，传递数据时需要发送一大堆无用的xml节点，没办法实现毫秒级的机器人控制，容易经常受到带宽和处理性能的影响
- 安全性较差，通信数据是开放式的，没有加密，只要在网络中的节点都可以轻松获取
- ROS不支持时间同步，多台机器人之间的同步得先使用linux的工具进行同步
- 在ROS1中节点启动是无序的，更不能暂停节点。ROS1系统设计时并没有考虑节点启动时可能存在的互相依赖。但在实际生产使用环境中，某些节点能正常工作的前提是其他一些节点已经启动。
a. ROS 2采用全新的架构，底层基于DDS(Data Distribution Service)通信机制，支持实时性、嵌入式、分布式、多操作系统，ROS2支持的系统包括Linux、windows、Mac、RTOS，甚至是单片机等没有操作系统的裸机。
b. ROS 2的通讯系统是基于DDS，取消了master，同时在内部提供了DDS的抽象层实现，有了这个抽象层，用户就可以不去关注底层的DDS使用了哪个商家的API。
c. ROS2基于DDS进行数据传输，而DDS基于RTPS的去中心化的通信框架，这就去除了对roscore的依赖，系统的稳定性强，对资源的消耗也得到了降低。
d. 由于ROS 缺少Qos机制，topic的稳定性与质量难以保证；ROS2则提供了Qos机制，对通信的实时性、完整性、历史追溯等功能有了支持，这便大幅加强了框架功能，避免了高速系统难以适用等问题。
e. ROS2中引入了节点生命周期管理的概念，各个节点的状态是可管理的。比如如果想从建图功能切到导航功能。在ROS1中，需要先将建图功能的程序杀干净，然后再启动导航程序。在这个场景里，大可让建图程序休眠，而不用杀掉。切换功能时只需要激活相应功能的节点即可。