

ROS的诞⽣让机器⼈与智能网联汽车技术在共同的框架下快速发展,基于ROS诞⽣了多样化的智能⽣态及应⽤,机器⼈控制、感知和决策与智能网联汽车的感知,规划也得以更好的组织和运⾏。随着机器⼈与智能网联技术研究、设计及应⽤的逐步深⼊,ROS技术在低速机器人应用场景与高速机器人应用场景等多种应⽤环境下开启全面应用,伴随⾯对多样化的⾏业应⽤时,对机器⼈与智能网联汽车的导航、任务、调度、运⾏、系统稳定性及可拓展性乃⾄产品量化成本考核也有了越来越⾼的要求。
ROS1版本⾯对这些要求时,其单系统、单⼀平台、实时性、稳定性、通讯能力、保密性等前期底层架构问题也逐步显现出来,⽆法满⾜未来机器⼈与智能网联汽车⾯对复杂环境时的任务要求。
ROS2的推出与应⽤迭代,则为机器⼈与智能网联自动驾驶技术框架突破当前发展瓶颈提供了可能性及可⾏性。
接下来小y与大家一同讨论 ROS1 与 ROS 2 的差异与对比 。
Ros 1:只能运行在linux/windows
Ros 2:可以运行在linux/windows/macos甚至嵌入式实时操作系统

系统架构可以分为三层 :系统层、中间层、应用层
主要区别体现在中间层 :

DDS实现层,由各个厂商提供相应的DDS软件产品;
该层的目的是为了让用户可以根据自己实际需求选择不同厂商
中间接口层,由C语言实现,直接和DDS交互,并向ros2 client层提供API接口;
该层的目的是让用户程序可以在不同供厂商的DDS之间进行无感移植
该层包含ROS2核心概念如Node、Action等的具体实现,以及不同编程语言如C++、Python和Java等API接口:rclcpp/rclpy/rcljava;
包含RCL库和不同的编程语言API,RCL库是一致的由C语言实现,编程语言API接口 是独立的,从而保证了不同编程语言下程序运行的一致性
有master节点:在ROS1中,需要开启中央节点管理器Master,统一管理所有节点。如果Master节点出现故障,将严重影响ROS系统功能
支持TCP和UDP通信,默认采用TCP。UDP适合网络不可靠的无线网络
取消了master节点
基于DDS分布式架构进行通信
ros1采用catkin进行编译。catkin是cmake的进一步封装和拓展;catkin_make是cmake和make命令的包装
ros1编译后生成build/devel文件夹
ros2采用colcon进行编译,支持不同的构建系统如catkin和ament等
ros2编译后生成build/install/log文件夹
不同节点在master注册后,通过master拿到其他节点并建立通信进行数据收发
通过DDS实现不同节点的相互发现,当一个节点启动后, 它会向其他拥有相同ROS域名的节点进行广播,其他节点在收到广播后返回自己的相关信息来建立通信,节点会定时广播它的信息,在下线前它也会广播其他节点自己要下线了,只会和具有相兼容的QoS设置的节点进行通信
节点和可执行文件紧密相关,一个可执行文件只能存在一个
ros 2中同一可执行文件可以存在多个ros 2节点
为了解决ros1中节点启动顺序无法控制的问题,ros2引入了生命周期节点的概念;
(1) Node:和ros1中一样的节点基类
(2) LifecycleNode:可管理状态的节点基类
声明周期节点有4个基础状态和6个切换状态,不同状态之间转换关系如下
不同状态之间的转换需要调用对应的回调函数如OnConfigure()等来实现,这些函数在对节点进行LCN改写时需要重新实现,即将不同功能划分到不同函数进行控制
LMN和LCN之间通过service模式进行通信,LMN作为client,LCN作为server,LMN发起service request给LCN请求LCN状态转移操作
节点运行时ros2会为每个节点配置默认的service,LCN会有特殊的service配置如
change_state、get_state等
命令行进行节点状态切换:
ros1使用xml编写launch启动文件,roslaunch package_name launch_file.launch
ros2默认使用python编写launch启动文件,也可以使用xml进行编写
ros1中service是同步的,当客户端向服务器发起请求时,等待响应期间会强行阻塞程序,直到服务器响应/或失败,完全无法获知服务端的处理进度,更不能取消或变更请求
ros2中的service是异步的,一个server可支持多个client,但每次只能响应一个request。client在调用服务请求时会添加一个回调函数,在服务端response时触发,在这期间主线程不会阻塞
ros1中action机制是运行服务端和客户端异步请求,采用无阻塞的编程方式;
ros2中action是一个上层的沟通机制,action包括三个部分:目标、结果和反馈。由topic和service共同构建
ros1中的参数由参数服务器处理,而参数服务器本身由master处理;
ros2的参数是由service构建出来,因为ros2中没有master,也就没有参数服务器。ROS2不再有全局参数,每个参数都特定于一个节点,每个节点声明和管理自己的参数,这些参数在节点被杀死时被销毁
ros1未考虑不稳定网络情况下的通信可靠性;
ros2通过不同的qos以适应不同的网络情况,可以像TCP一样可靠,也可以像UDP一样尽力而为,进而优化带宽和时延;
如果两个ros2节点的qos设置不兼容,将无法通信
ros1中msg、srv和action并没有统一定义为接口;
ros2引入通信接口的概念,接口用来描述不同节点之间交换信息的数据结构,这些数据结构以与编程语言无关的方式进行定义。ros2的通信接口包含topic+msg+srv+action,这些接口都通过对应接口文件进行定义。通过IDL来映射通信接口,IDL可以自动地生成不同目标语言的接口类型的源码
ros2使用json文件格式定义ros消息内容、topic和qos配置
使用同样的json文件,通过统一脚本可实现代码生成并完成qos的设置,不同编程语言可以生成不同的接口文件,完成msg->hpp的转换;另外,相同的json文件使用不同的ros2版本编译生成的接口文件是有区别的,跨版本直接拷贝接口文件使用会报错
ros1的命令行语法:rosbag play xxx, rostopic xxx, rosnode xxx等
ros1常用命令汇总
ros2的命令行语法:ros2 bag play xxx, ros2 topic xxx, ros2 node xxx等
ros2常用命令汇总
rqt工具ros1和ros2命令保持一致;ros1是rviz,ros2是rviz2,名称变了,其他保持一致
ros1采用Gazebo作为仿真平台,Gazebo 11为最终版将于2025年停止维护;
ros2采用Ignition作为仿真平台,Ignition为Gazebo新一代版本
基于此,YUHESEN 通过对ROS 版本与ROS 2版本的深⼊探索与研究,认真梳理了当前⾏业需求与痛点,并以ROS2 为基础设计并研发了 全球首款 ROS2 Humble 移动机器人开源导航教育套件 。
ROS2 Humble 开源教育套装基于智能网联与机器人技术科研教育及⾯向未来行业场景应⽤部署需求,提供了ROS2 智能网联汽车算法版本,移动机器人算法版本,以满⾜不同⽤户的需求。
该套件基于YUHESEN ⾃主移动机器⼈平台--DGT MINI 与FW MINI 系列,以ROS2 humble版本为核⼼,搭载了 2DLiDAR、9轴IMU、深度双⽬相机等传感器,⼯控机采⽤X86架构,并基于 Ubuntu20.04 系统提供包含Nav2、Gazebo11等新特性,以 Nav2 为核⼼的导航组件全⾯兼容NAV2官⽅新特性,为科研教育提供⼀个全⾯深⼊的 ROS2 学习研究探索综合机器⼈开发平台。
图片:基于Gazebo11路径仿真仿真图片
您可以在可视化界⾯中进⾏仿真模拟,也可以在YUHESEN 官网上获得ROS2仿真包(全⻋型均已⽀持ROS2),更为⾼效便捷。
图片:基于Catergrapha点云地图构建片
图片:室内环境SLAM算法构建图片
图片:NAV2导航堆栈图片
图片:机器人避障算法图
图片:机器⼈室内环境避障算法仿真图片
YUHESEN ROS2 套件适配 ROS2 所有特性,支持用户以ROS2 为基础,进行移动机器人研究及开发。针对近年来用户所关心的智能网联汽车 ,机器人中的农业应用、军事应用、户外测量勘探、巡逻安防等行业应用具备科研、教学、展示等软硬件功能,可以低成本地、安全地、开发、测试和部署解决方案。后期将针对 ROS 2 不同版本进行对比说明 。让大家对ROS 2的了解更为清晰 。
YUHESEN科技全系列底盘也支持ROS2,ROS2 适配包可在官网与GitHub或市场销售工程师获取,同时欢迎大家将使用的经验、感受等发布在煜禾森b站 ,我们将会定期发布技术视频与资料,大家可以在b站社区、GitHub自由交流,同时YUHESEN作为全球自动驾驶技术拓展与开发的助力者 ,深度了解智能网联汽车与移动机器人应用需求与难点,从客户需求出发,旨在降低自主导航技术开发门槛、提升机器人高模块化、复用能力,简化任务量 。与大家一起推动机器人技术向更美好的未来发展 。
移动机器人的路未来很长,YUHESEN 将陪伴所有合作伙伴一步一个脚印地前行。欢迎大家位临公司交流学习 ,一同推动移动机器人导航技术发展与技术落地。