一种港口自动驾驶单车端通信消息解耦处理方法与流程

1.本发明属于港口自动驾驶、单车智能以及软件架构设计领域，适用场景是单车自动驾驶系统各子系统间消息通信处理方法，具体涉及一种港口自动驾驶单车端通信消息解耦处理方法。


背景技术：

2.在港口自动驾驶单车智能中，各子系统(包括作业处理、规划控制、感知、定位、高精地图等)间的通信必不可少。
3.业界普遍使用的通信方案为：利用ros这样的消息中间件，规定好各子系统间交互的topic和message。若某个子系统需将自己的数据发送出去，则它publish对应topic，那么它就将数据以对应message的格式广播出去了。此时subscribe了此topic的其他子系统，就能收到对应的message，进而进行后续业务处理。publish和subscribe的消息格式都依赖于ros，须符合ros 的消息格式规范。
4.上述方案的缺点在于，随着作业场景的变化，若哪天需要更换消息中间件(如ros2或自研消息中间件)，则原先程序中所有使用ros1 message 的部分都需要修改，适配成符合新中间件的message格式。这不仅带来了修改上的麻烦(修改每一处容易出错，每一个修改处都须重新测试)，更不符合软件设计上的“对扩展开放，对更改封闭”的设计原则。


技术实现要素：

5.本发明的目的在于提供一种港口自动驾驶单车端通信消息解耦处理方法，旨在解耦消息中间件消息格式与子系统业务处理的消息格式。分离出中间件消息到子系统消息转换模块，当更换消息中间件，只需适配此消息转换模块，子系统处理部分无需做任何变动。
6.为实现上述目的，本发明提供如下技术方案：
7.一种港口自动驾驶单车端通信消息解耦处理方法，其特征在于，
8.对publish侧的中间件消息与子系统消息分离，即：
9.定义子系统消息转换成ros2消息函数tomsg()；
10.定义用于pubilsh的类pubproxycore，实现pubproxycore：：pub()函数；
11.定义pubproxy类，封装pubproxycore，用于对子系统提供统一调用接口；
12.对subscribe侧的中间件消息与子系统消息分离，即：
13.定义ros2消息类型到子系统消息类型的转换函数toinnerdata()及映射关系；
14.定义用于subscribe的类subproxycore，实现subproxycore：：create_sub ()函数；
15.控制subproxycore::create_sub()的生命周期，对子系统提供统一订阅子系统消息接口subproxy::create_sub()。
16.本发明进一步设置，定义子系统消息转换成ros2消息函数tomsg() 时，以子系统消息类型为形参，不同的子系统消息类型构成tomsg()的函数重载；
17.本发明进一步设置，定义用于publish的类pubproxycore，实现 pubproxycore：：pub(t inner_msg)函数时，类型t根据传入的实参，具象化为具体的子系统消息类型。由传入的子系统消息类型和tomsg()，可得到对应的ros2消息类型，从而创建出此ros2消息类型的publisher对象，最后，调用publisher对象的publish()方法，将转换成ros2消息的子系统消息发送出去。
18.本发明进一步设置，定义pubproxy类，封装了pubproxycore，用于对子系统提供统一调用接口。pubproxy将需publish的每个topic对应的 pubproxycore存入unordered_map，作为成员变量；当子系统需要publish 某topic时，直接调用pubproxy对象pub()成员函数。同时，将pubproxy 定义成单例类，其对外调用接口为：
19.pubproxy::instance().pub(topic,inner_msg)；
20.本发明进一步设置，定义用于subscribe的类subproxycore，实现 subproxycore：：create_sub()函数时，obj::fp()为用户需实现的回调函数，入参为子系统消息类型，create_sub()实现中，调用了ros2的subscribe ()方法，并转换成调用使用子系统消息类型的obj::fp()方法。
21.本发明进一步设置，控制subproxycore::create_sub()的生命周期时，为subproxycore再封装一层，定义一个subproxy类，根据其vector成员变量，vector的元素为subproxycore::create_sub()的返回值，子系统类通过包括一个subproxy的成员变量对象，来使用subproxy::create_sub()来订阅topic，当subproxy成员对象被销毁时，创建的subscriber对象也会被销毁。
22.本发明进一步设置，若消息中间件变更成除ros2之外的其他中间件时，再扩展一个对应的pubproxy/pubproxycore/subproxy/subproxycore/中间件消息与子系统消息转换函数即可。
23.本发明的有益效果：提出了单车端各子系统间通信消息解耦处理方法。该方法解耦了消息中间件消息格式与子系统处理消息格式,发明提出分离出中间件消息到子系统消息转换模块，当更换消息中间件，只需用预定义宏控制，适配此消息转换模块即可，子系统处理部分无需做任何变动。这提高了系统的可维护性和可扩展性，降低了测试成本，提高了开发效率。
附图说明
24.图1为本发明实施例定义子系统消息转换成ros2消息函数tomsg() 的示意图。
25.图2为本发明实施例中pubproxycore::pub()函数模板的示意图。
26.图3为本发明实施例中定义pubproxy类，封装pubproxycore，用于对子系统提供统一调用接口的示意图。
27.图4为本发明实施例中pubproxy定义成单例类的示意图。
28.图5为本发明实施例中ros2消息转换成子系统消息toinnerdata() 的示意图。
29.图6为本发明实施例定义子系统消息到ros2消息映射关系的示意图。
30.图7为本发明实施例中create_sub()实现的示意图。
31.图8为本发明实施例中为subproxycore再封装成subproxy的示意图。
32.图9为-图11为本发明实施例中子系统类使用subproxy对象subscribetopic/
message方法的示意图。
具体实施方式
33.以下将配合实施例来详细说明本技术的实施方式，借此对本技术如何应用技术手段来解决技术问题并达成技术功效的实现过程能充分理解并据以实施。
34.本发明采用如下技术方案，一种港口自动驾驶单车端通信消息解耦处理方法，
35.对publish侧的中间件消息与子系统消息分离，即：
36.定义子系统消息转换成ros2消息函数tomsg()；
37.定义用于pubilsh的类pubproxycore，实现pubproxycore：：pub()函数；
38.定义pubproxy类，封装pubproxycore，用于对子系统提供统一调用接口；对subscribe侧的中间件消息与子系统消息分离，即：
39.定义ros2消息类型到子系统消息类型的转换函数toinnerdata()及映射关系；
40.定义用于subscribe的类subproxycore，实现subproxycore：：create_sub ()函数；
41.控制subproxycore::create_sub()的生命周期，对子系统提供统一订阅子系统消息接口subproxy::create_sub()。
42.其中定义子系统消息转换成ros2消息函数tomsg()时，以子系统消息类型为形参，不同的子系统消息类型构成tomsg()的函数重载；定义用于publish的类pubproxycore，实现pubproxycore：：pub(t inner_msg) 函数时，类型t根据传入的实参，具象化为具体的子系统消息类型。由传入的子系统消息类型和tomsg()，可得到对应的ros2消息类型，从而创建出此ros2消息类型的publisher对象，最后，调用publisher对象的publish ()方法，将转换成ros2消息的子系统消息发送出去；定义pubproxy类，封装了pubproxycore，用于对子系统提供统一调用接口。pubproxy将需 publish的每个topic对应的pubproxycore存入unordered_map，作为成员变量；当子系统需要publish某topic时，直接调用pubproxy对象pub()成员函数。同时，将pubproxy定义成单例类，其对外调用接口为：
43.pubproxy::instance().pub(topic,inner_msg)；
44.此外在定义用于subscribe的类subproxycore，实现subproxycore：： create_sub()函数时，obj::fp()为用户需实现的回调函数，入参为子系统消息类型，create_sub()实现中，调用了ros2的subscribe()方法，并帮助转换成使用子系统消息类型的obj::fp()方法。控制 subproxycore::create_sub()的生命周期时，为subproxycore再封装一层，定义一个subproxy类，根据其vector成员变量，vector的元素为 subproxycore::create_sub()的返回值，子系统类通过包括一个subproxy 的成员变量对象，来使用subproxycore::create_sub()来订阅topic，当 subproxy成员对象被销毁时，创建的subscribe()对象也会被销毁。
45.若消息中间件变更成除ros2之外的其他中间件时，再扩展一个对应的 pubproxy/pubproxycore/subproxy/subproxycore/中间件消息与子系统消息转换函数即可。
46.现就具体的实施过程对本发明作进一步的阐述：
47.一、publish的中间件消息与子系统消息分离
48.步骤一、定义子系统消息(或称内部消息)转换成ros2消息函数 tomsg()；
49.如图1所示，实现内部消息到ros2消息的转换函数tomsg()。以内部消息类型为形参，不同的内部消息类型构成tomsg()的函数重载。
50.步骤二、定义用于publish的类pubproxycore，实现pubproxycore：： pub()函数；
51.如图2所示，pubproxycore::pub()为函数模板。类型t根据传入的实参，具象化为具体的内部消息类型。由传入的内部消息类型和 tomsg()，可得到对应的ros2消息类型，从而创建出此ros2消息类型的publisher对象，最后，调用publisher对象的publish()方法，
52.将转换成ros2消息的内部消息发送出去。
53.步骤三、定义pubproxy类，封装了pubproxycore，用于对子系统提供统一调用接口；
54.如图3所示，pubproxy将需publish的每个topic对应的pubproxycore 存入unordered_map，作为成员变量。当用户(即子系统)需要publish 某topic时，直接调用pubproxy对象pub()成员函数即可，不需要每遇到一个topic创建一个pubproxycore对象。并且，将pubproxy定义成单例类，如图4所示：这样就统一了对外调用接口：
55.pubproxy::instance().pub(topic,inner_msg)
56.方便了子系统的使用。由上述调用接口可见，子系统代码只需填入 topic和对应的内部消息结构的消息，即可publish成功。
57.二、subscribe的中间件消息与子系统消息分离
58.步骤一、定义ros2消息类型到子系统消息(或称内部消息)类型的转换函数toinnerdata()及映射关系
59.如图5所示，ros2消息转换成内部消息toinnerdata()；
60.如图6所示，定义内部消息到ros2消息的映射关系；
61.步骤二、定义用于subscribe的类subproxycore，实现subproxycore：：create_sub()函数；
62.如图7所示，上述create_sub()实现，obj::fp()为用户需实现的回调函数，入参为内部消息类型。create_sub()实现中，调用了ros2的 subscribe()方法，并转换成调用使用内部消息类型的obj::fp()方法。
63.步骤三、控制subproxycore::create_sub()的生命周期；
64.港口自动驾驶场景中，通常create_sub()的回调函数入参为类的成员函数，故它的生命周期与对象的生命周期一致。为此，为
65.subproxycore再封装一层，定义一个subproxy类，它有一个vector 成员变量，vector的元素为subproxycore::create_sub()的返回值。用户类(即子系统类)通过包括一个subproxy的成员变量对象，来使用subproxy::create_sub()来订阅topic。当subproxy成员对象被销毁时，创建的subscriber对象也会被销毁。实现方法如图8所示：用户类使用subproxy对象subscribe topic/message方法：如图9-11 所示；
66.三、对扩展开放，对更改封闭
67.若消息中间件变更成其他中间件，只需再扩展一个对应的 pubproxy/pubproxycore/subproxy/subproxycore/中间件消息与内部消息转换函数即可。预定义宏，控制使用哪种中间件。子系统代码不需要做修改。
68.本发明的有益效果为，提出了单车端各子系统间通信消息解耦处理方法。该方法解耦了消息中间件消息格式与子系统处理消息格式。发明提出分离出中间件消息到子系统消息转换模块，当更换消息中间件，只须需用预定义宏控制，适配此消息转换模块即可，子系统处理部分无需做任何变动。这提高了系统的可维护性和可扩展性，降低了测试成本，提高了开发效率。
69.如在说明书及权利要求当中使用了某些词汇来指称特定组件。本领域技术人员应可理解，硬件制造商可能会用不同名词来称呼同一个组件。本说明书及权利要求并不以名称的差异来作为区分组件的方式，而是以组件在功能上的差异来作为区分的准则。如在通篇说明书及权利要求当中所提及的“包含”为一开放式用语，故应解释成“包含但不限定于”。“大致”是指在可接收的误差范围内，本领域技术人员能够在一定误差范围内解决所述技术问题，基本达到所述技术效果。
70.需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的商品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种商品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的商品或者系统中还存在另外的相同要素。
71.上述说明示出并描述了本发明的若干优选实施例，但如前所述，应当理解本发明并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文所述发明构想范围内，通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本发明的精神和范围，则都应在本发明所附权利要求的保护范围内。