在上一篇中,我们介绍了DDS,eProsima的Fast DDS是DDS规范的C++实现,Fast DDS的前称是Fast RTPS,目前ROS2将Fast DDS作为默认的DDS中间件实现。Fast DDS主要包括以下内容:
DDS API
DDS采用的通信模型是一种多对多单向数据交换,其中产生数据的应用程序将数据发布到属于使用数据的应用程序的订阅者的本地缓存。信息流由负责数据交换的实体之间建立的服务质量(QoS)策略来控制。
作为一个以数据为中心的模型,DDS建立在所有感兴趣的应用程序都可以访问的“全局数据空间”的概念之上。提供信息的应用程序作为发布者,访问部分数据空间的应用程序作为订阅者。每当发布者向该空间发布新数据时,中间件就将该信息传播给所有感兴趣的订阅者。
通信发生在多个域之间,即连接所有能够相互通信的分布式应用程序的孤立抽象平面。只有属于同一个域的实体才能进行交互,订阅数据的实体和发布数据的实体之间的匹配通过主题进行中介。主题是明确的标识符,它将在域中惟一的名称与数据类型和一组附加的特定于数据的QoS相关联。
DDS实体被建模为类或类型化接口,后者意味着更有效的资源处理,因为在执行前了解数据类型允许提前分配内存,而不是动态分配。
依赖接口意味着需要一个生成工具,将类型描述转换为适当的实现,以填补接口和中间件之间的空白。这个任务由生成工具Fast DDS-Gen完成,这是一个Java应用程序,它使用接口定义语言(IDL)文件中定义的数据类型生成源代码。
Fast DDS在标准网络上交换消息所使用的协议是实时发布-订阅协议(RTPS),这是由OMG联盟定义和维护的用于DDS的互操作性有线协议,参考上一篇介绍。该协议通过TCP/UDP/IP等传输协议提供发布者-订阅者通信,并保证不同DDS实现之间的兼容性。
由于RTPS协议的发布-订阅和它的规范是为满足DDS应用程序域所解决的相同需求而设计的,因此RTPS协议映射到许多DDS概念。所有RTPS核心实体都与一个RTPS域相关联,该域表示一个端点匹配的隔离通信平面。RTPS协议中指定的实体与DDS实体一一对应,因此允许通信发生。
-
实时性:提供可配置的实时功能,保证在指定的时间限制内响应;
-
服务发现:内置基于对现有发布者和订阅者的动态发现,并且不需要联系或设置任何服务器就可以持续执行此任务,同时也支持配置其他发现机制;
-
-
传输层:实现了可插拔的体系结构,当前版本支持五种传输:UDPv4, UDPv6, TCPv4, TCPv6和SHM(共享内存);
-
安全性:提供可配置的安全通信,实现了可插拔的安全配置,包括:远程参与者的身份验证、实体的访问控制和数据加密;
-
流量控制:支持可配置的吞吐量控制,可限制在特定条件下发送的数据量;
-
即插即用连接:新的应用程序和服务能够自动发现,可以在任何时候加入或离开网络,而不需要重新配置;
-
可伸缩性和灵活性:DDS建立在全局数据空间的概念之上,中间件负责在发布者和订阅者之间传播信息,这使得分布式网络可以适应重新配置,并可扩展大量实体;
-
可移植性:DDS规范包括到IDL的特定平台映射,允许使用DDS的应用程序只需重新编译就可以在DDS实现之间切换;
-
可扩展性:允许使用新的服务扩展和增强协议,不会破坏向后兼容性和互操作性;
-
可配置性和模块化:提供了一种通过代码或XML配置文件进行配置的直观方
式。模块化允许简单设备实现协议的子集,同时仍然参与网络;
-
高性能序列化:基于eProsima的Fast Buffers序列化,官网说其性能要高于Protocol Buffers和Thrift:
-
低资源的消耗:允许预分配资源,减少动态资源分配,避免无限制使用资源,最小化数据复制的需要;
-
多平台:默认情况下,该项目可以在Linux、Windows和MacOS上运行;
-
免费和开源:Fast DDS库、Fast RTPS库、Fast DDS-Gen、内部依赖项(如Fast CDR)和外部依赖项(如foonathan库)都是免费和开源的。
以上大部分内容都是官网翻译+一点自己理解,下面我来具体讲一下如何使用Fast DDS。其实,Fast DDS对开发者非常友好,不仅有框架文档、API文档,还自带了丰富的示例代码,不止HelloWorld那么简单,基本上所有主要的功能点都能在示例代码中找到,可以说很容易上手。
但是,我还是决定从零跑个HelloWorld看看,事实上,真的也碰到了一些问题,所以呀,绝知此事还是要躬行的。
关于下载和安装,还是写在了README里,回复“演示代码”就可以看到链接。官方的示例中已经用HelloWorld.idl生成了代码,而当我用Fast DDS-Gen,相同的idl,却生成了不一样的代码,而我并不知道官方代码是用了哪个版本的工具生成的,或者用的命令是不是不一样,这是我遇到的第一个问题。
fastddsgen HelloWorld.idl
├── HelloWorld.cxx --> 实际存储数据的结构
├── HelloWorld.h
├── HelloWorldPubSubTypes.cxx --> 继承自eprosima::fastrtps::TopicDataType
└── HelloWorldPubSubTypes.h
后来发现,可以通过“-example”选择生成某一个平台下的示例代码:
fastddsgen -example CMake HelloWorld.idl
├── CMakeLists.txt
├── HelloWorld.cxx
├── HelloWorld.h
├── HelloWorldPublisher.cxx --> 发布者的实现
├── HelloWorldPublisher.h
├── HelloWorldPubSubMain.cxx --> 主程序
├── HelloWorldPubSubTypes.cxx
├── HelloWorldPubSubTypes.h
├── HelloWorldSubscriber.cxx --> 订阅者的实现
└── HelloWorldSubscriber.h
但这仍然和官方示例看起来不大一样,事实上,发布者和订阅者的实现真的就不一样!而且,即使改了CMakeLists,编译能过,运行时还是会crash,查了问题发现,用老一点版本的工具生成的就和官方示例差不多了,猜测官方示例并不是用最新工具生成的,所以我觉得保险的做法是只生成前面四个文件,可以参考官方示例实现发布者和订阅者。
其实我理解在实际项目应用中,发布者和订阅者的实现部分本来也是要自已写的。前几天在后台收到了一条小伙伴的消息,说想了解如何使用Fast DDS的Log,其实代码可以参考:test/unittest/logging/LogTests.cpp,但是我还是想在HelloWorld中简单尝试了一下,结果发现即使设置了日志级别,Info日志还是没显示出来:
查了源码和文档,发现需要在编译阶段,打开Debug模式和关闭LOG_NO_INFO开关,才可以显示Info级别的日志(前方预警:Log会多到你怀疑人生,个人感觉这种方式并不是很合理,因为我想要的其实只是第一句而已):
最后,结合个人体会和网上各路大神的回答(比如:
知乎&Stack Overflow),对比一下SomeIP和DDS:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
DDS Security安全规范,支持细粒度的安全规则,也支持TLS
|
|
|
|
抛开具体场景去谈哪个好,没有什么意义,从个人学习的角度,我觉得DDS有更多新颖的东西可以学习,Fast DDS的实现也非常值得开发者深入研究。
相关活动:汽车以太网技术论坛
投稿合作:18918250345(微信)