0%
ROS原理（二）
Apollo ROS对ROS的改进（续）
- 去中心化网络拓扑
- 原因，两个明显的缺点：
- 节点之间的通信过于依赖Rosmaster单点
- ROS没有提供一种异常恢复机制
- 比较主流的Nvidia Drive PX2板卡，它就包括两个系统：一个主系统，一个是冗余备份系统即容错系统
- Apollo ROS的改进：
- Apollo ROS进行了比较大的改造：先把这个中心化的网络拓扑给去掉，然后建立了一个点对点之间的一个复杂网络拓扑，主要是使用RTPS服务发现协议去完成P2P网络拓扑
- 节点建立连接和通讯的主要流程：
- 第一步：Sub节点启动，通过组播向网络注册
- 第二步：通过节点发现，两两建立unicast（单点广播; 单播）
- 第三步：向新加入的节点发送它们已经有拓扑信息
- 第四步：收发双方建立连接，开始通信
- 通过RTPS拓扑发现方式，Apollo ROS去除了对Rosmaster这一个单点的依赖，从而提升整个系统的鲁棒性
- 数据兼容性扩展
- 原生ROS基于Message的订阅发布消息模型，发送者和接收者在进行实际通讯之前需要进行消息格式定义，其包含字段：基础的数据类型或者复杂的数据类型
- Message是两个节点进行消息通信的抽象描述文件
- Message接口升级，不同版本之间的兼容是需要做大量的适配工作
- Apollo ROS的改进：
- Apollo ROS实践里面引入了一种新的消息描述的格式去实现很好的向后兼容即Protobuf
ROS原理（三）
- TF坐标系转换
- 因为自动驾驶使用的ROS架构是一个松耦合关系，每个节点独立运行，节点有一套自己的XYZ坐标系，当把他们组装到一块时，每个节点的坐标系都是相对独立的，但整个自动驾驶系统需要把每一个节点所使用的信息和一些参数转化到同一个世界坐标系里
- TF节点就提供了对应的坐标系转换功能，TF消息也是通过基于Message的订阅和发布消息来完成的
- 当下游的Planning节点想使用Obstacle信息时，需要将Obstacle信息转化到同一个世界坐标系，这时候它会发起一个TF去查询Obstacle处于哪一个世界坐标系里面的哪一个位置，从而感知整个车身周围的情况
- RQT用户接口
- R实质是ROS的缩写，QT是可视化的图形工具，RQT是ROS给开发者提供的一套比较方便的图形化相关展示的一套工具
- RQT imageview主要是为自动驾驶顶层的一些传感器设计的，可实现实时查看Driver接收图像是否正确
- Multipot可以将二维的数据在一个二维坐标系里面进行实时展示，这样可以更直观地看到我们所需要的数据是否符合我们的预期
- RQT的graph工具，在开发的实际过程当中使用得比较广泛，这个工具把整个网络拓扑用图形化的方式展现出来
- RQT console是对应ROS日志系统所提供的一套可视化工具
- RQT logleve是为ROS日志系统所提供的另外一个可视化工具
- 机器人模型
- 在进行实际模拟的时候，可以用一套语言来定义机器人模型，这套语言被定义为统一机器人描述格式语言URDF
- 这个描述格式里面包含两个核心的概念：一个是节点Link，一个是节点之间的连接关系Joint（Joint会指定Parent节点和Child节点）
- 仿真描述
- Simulation Description Format（SDF）是另外一个调试工具
- 进行仿真模拟，如机器人模拟的时候，则使用一套ROS的开发包——Gazebo
- Gazebo里面所使用的描述语言就是Simulation Description Format
- 用Gazebo加载URDF时，Gazebo首先把URDF描述语言转换成SDF语言，然后再进行加载和展示
ROS原理（四）
- ROS Service
- ROS提供了三种节点之间通信的方式：
- 第一种是大家最常用的基于消息的订阅发布模型
- 第二种就是ROS Service
- 第三种Param，它借鉴了Service的思想
- Service在自动驾驶系统里面使用的比较广泛
- Service启动的时候，需要提前启动Roscore，即节点管理器
- 通过List和Type命令可以看到在启动某一个节点后，这个节点里面注册了某个Service的一个实际展示
- 它有一个Service方法，定义了节点提供的服务类型，以及当Client向它发出请求时，节点会做出什么样的行为同时把这个结果再发送给Client
- 在注册Service时，把Service的Name，和Service所提供的函数注册即可
- 发起一个Service请求需要等到返回一个正确的Response结果才会退出
- ROS Actions
- ROS还提供了另外一种通讯方式，这种不常见通讯方式就是Actions
- 相比Service，它多了一个取消的功能和带有反馈机制
- Actions在发送一个Service请求之后，它可以发送取消的命令，可用于一些较长时间的Service场景
- ROS Time
- ROS系统供了一套time机制，这个time的时间源来自于PC机的系统时间
- Rostime基于此提供了一个重要的功能点：仿真时间
- 仿真时间：保证在回放一些历史实验数据，或者其他地方实验数据时，让整个仿真系统认为现在的场景就是所需要的那个系统时间和系统场景
- ROS Bags
- 把实际车上调试的数据或者是把自动驾驶进行道路测试的原始传感器数据按一定格式录制到某个bag文件里
- 实验室或者开发环境可以根据bag文件不断的回放，去复现当时的网络场景
- ROS Bags数据对算法进行模型训练和调优也是非常有必要的
- 调试工具
- ROS提供了一些简单的功能，比如说ROS WTF
- 可以让用户很简单地查看当前系统是环境变量设置的问题，还是其他的一些核心库链接的位置问题，通过WTF都可以很快的定位
- ROS也提供了一些其他的Debug诊断功能供开发者在实际开发过程当中去使用
参考资料