自動(dòng)駕駛?cè)绾螌?shí)現(xiàn)車(chē)輛配置，Apollo3.5車(chē)輛配置方案為你揭曉

Apollo 開(kāi)放車(chē)輛的接口標(biāo)準(zhǔn)主要涉及到兩大部分，即線控系統(tǒng)和車(chē)輛系統(tǒng)。Apollo 對(duì)這兩者的功能指標(biāo)、性能指標(biāo)、安全指標(biāo)進(jìn)行一系列的約定并提出了相關(guān)標(biāo)準(zhǔn)。以常見(jiàn)的剎車(chē)和油門(mén)為例， Apollo 對(duì)這兩者的控制精度、控制力度、系統(tǒng)的周期時(shí)間、響應(yīng)時(shí)間都有著嚴(yán)格的規(guī)定。

線控系統(tǒng)對(duì)指令越界保護(hù)和控制的處理等安全指標(biāo)都有著明確約定以及標(biāo)準(zhǔn)化的要求。而車(chē)輛系統(tǒng)要求有相對(duì)穩(wěn)定的CAN信號(hào)通道，同時(shí)對(duì)于車(chē)輛電源，包括電壓、功率、最大波動(dòng)、輸出誤差都有一系列的規(guī)定，以夠保證在整個(gè)自動(dòng)駕駛過(guò)程中電源輸出穩(wěn)定。

本文由Apollo開(kāi)發(fā)者社區(qū)認(rèn)證布道師-阿淵撰寫(xiě)，對(duì)Apollo 3.5 車(chē)輛配置方案進(jìn)行了詳細(xì)講解，希望這篇文章給感興趣的同學(xué)帶來(lái)更多幫助。

以下，ENJOY

最近在研究百度無(wú)人車(chē) Apollo 的工廠模式及車(chē)輛配置方式，有一些小心得希望和大家一起分享。

Apollo 無(wú)人駕駛平臺(tái)支持 Lincoln MKZ、WEY VV6 等來(lái)自多個(gè) OEM 的不同車(chē)型。

Apollo 兼容的開(kāi)放車(chē)型，來(lái)源： http://apollo.auto/vehicle/certificate_cn.html

眾所周知，各車(chē)廠車(chē)型的配置方式、接口、信號(hào)都各不相同。那么 Apollo 是如何兼容各個(gè)車(chē)型的呢？本文將從以下三個(gè)層次來(lái)回答這個(gè)問(wèn)題。

從平臺(tái)構(gòu)架上看，Apollo 借助“開(kāi)放車(chē)輛認(rèn)證平臺(tái) (Open Vehicle Certificate Platform)"完成與汽車(chē)的交互，其他上層平臺(tái)無(wú)需關(guān)注底層實(shí)現(xiàn)。

Apollo 3.5 架構(gòu)圖， 來(lái)源：https://github.com/ApolloAuto/apollo

Apollo 的平臺(tái)架構(gòu)如上圖所示，Apollo 開(kāi)放平臺(tái)包括了以下幾個(gè)部分：

云端服務(wù)平臺(tái)

開(kāi)源軟件平臺(tái)

硬件開(kāi)發(fā)平臺(tái)

開(kāi)放車(chē)輛認(rèn)證平臺(tái)

這里我們著重了解一下“開(kāi)放車(chē)輛認(rèn)證平臺(tái)”。

來(lái)源：http://apollo.auto/developer_cn.html

目前各個(gè) OEM 廠商的大多使用 CAN 總線協(xié)議來(lái)進(jìn)行車(chē)輛內(nèi)部各個(gè) ECU 節(jié)點(diǎn)之間的通訊。CAN 總線通訊協(xié)議中各節(jié)點(diǎn)的信息使用 DBC（Database Can）文件來(lái)進(jìn)行來(lái)進(jìn)行描述。

The DBC file describes the communication of a single CAN network. This information is sufficient to monitor and analyze the network and to simulate nodes not physically available.

DBC文件描述了單個(gè)CAN網(wǎng)絡(luò)的通信。 此信息足以監(jiān)視和分析網(wǎng)絡(luò)并模擬物理上不可用的節(jié)點(diǎn)。[1]

各車(chē)廠的 DBC 文件定義通常并不相同，并且是嚴(yán)格保密的。為了解決開(kāi)發(fā)者在開(kāi)發(fā)無(wú)人駕駛系統(tǒng)中與車(chē)輛交互的問(wèn)題，Apollo 搭建了《開(kāi)放汽車(chē)認(rèn)證平臺(tái)》，并提出了開(kāi)放車(chē)輛認(rèn)證計(jì)劃。

開(kāi)放車(chē)輛認(rèn)證計(jì)劃第一次在業(yè)內(nèi)提出標(biāo)準(zhǔn)化的無(wú)人駕駛系統(tǒng)與車(chē)輛接口，透過(guò)這個(gè)計(jì)劃，車(chē)企/車(chē)輛提供商可以更方便的將車(chē)輛平臺(tái)接入到Apollo開(kāi)放平臺(tái)，從而覆蓋更廣泛的無(wú)人駕駛開(kāi)發(fā)者人群，加速無(wú)人駕駛能力的上車(chē)部署。[2]

該平臺(tái)作為軟硬件中間層，提出了開(kāi)放車(chē)輛接口標(biāo)準(zhǔn)，定義了系統(tǒng)與汽車(chē)的線控接口，負(fù)責(zé)完成系統(tǒng)與汽車(chē)的具體交互。該平臺(tái)抽象出了與車(chē)型無(wú)關(guān)的信號(hào)作為上層算法模塊的輸入，使得上層平臺(tái)可以與底層車(chē)輛信號(hào)解耦。

Apollo 的開(kāi)放車(chē)輛接口標(biāo)準(zhǔn)定義了 Apollo 需要的諸多用于控制車(chē)輛和接收反饋的信號(hào)。大體而言， Apollo 需要車(chē)企提供線控轉(zhuǎn)向、驅(qū)動(dòng)、制動(dòng)、檔位、駐車(chē)、燈光、雨刮控制、喇叭控制等控制及故障反饋等接口。Apollo 乘用車(chē)的線控需求具體的詳細(xì)信息可參見(jiàn)下列規(guī)范。

https://link.zhihu.com/?target=http%3A//apollo-homepage.bj.bcebos.com/Apollo_by_wire_requirement.xlsx

此外，根據(jù)《開(kāi)放車(chē)輛認(rèn)證車(chē)企認(rèn)證流程》，想要接入到 Apollo 開(kāi)放平臺(tái)，車(chē)企需要遵循 Apollo 的接口規(guī)范，向 Apollo 開(kāi)放平臺(tái)提供對(duì)應(yīng)的 DBC 文件。

Apollo 在與開(kāi)放車(chē)輛的信號(hào)交互上和開(kāi)放車(chē)輛配置上均使用了Protobuf。

Protocol Buffers 是一種輕便高效的結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)格式，可以用于結(jié)構(gòu)化數(shù)據(jù)串行化，或者說(shuō)序列化。它很適合做數(shù)據(jù)存儲(chǔ)或 RPC 數(shù)據(jù)交換格式?？捎糜谕ㄓ崊f(xié)議、數(shù)據(jù)存儲(chǔ)等領(lǐng)域的語(yǔ)言無(wú)關(guān)、平臺(tái)無(wú)關(guān)、可擴(kuò)展的序列化結(jié)構(gòu)數(shù)據(jù)格式。目前提供了 C++、Java、Python 三種語(yǔ)言的 API。[3]

通常車(chē)企會(huì)使用 DBC 文件來(lái)完成 CAN 信號(hào)的定義和解析， Apollo 則大量使用了 Protobuf 來(lái)進(jìn)行模塊間的通信和配置，因此車(chē)企需要使用 Apollo 提供的工具基于 DBC 來(lái)生成 Apollo 可用的 Proto 文件 (如下所示)。

1//modules/canbus/proto/wey.proto 2messageWey{ 3optionalAds_shifter_115ads_shifter_115=1;//controlmessage 4optionalAds_eps_113ads_eps_113=2;//controlmessage 5optionalStatus_310status_310=3;//reportmessage 6optionalVin_resp3_393vin_resp3_393=4;//reportmessage 7optionalVin_resp2_392vin_resp2_392=5;//reportmessage 8optionalVin_resp1_391vin_resp1_391=6;//reportmessage 9optionalAds_req_vin_390ads_req_vin_390=7;//controlmessage10optionalAds1_111ads1_111=8;//controlmessage11optionalFbs2_240fbs2_240=9;//reportmessage12optionalFbs1_243fbs1_243=10;//reportmessage13optionalFbs4_235fbs4_235=11;//reportmessage14optionalFail_241fail_241=12;//reportmessage15optionalFbs3_237fbs3_237=13;//reportmessage16optionalAds3_38eads3_38e=14;//controlmessage17}

Protobuf 提供的 Codegen 工具會(huì)根據(jù) Proto 文件中定義的變量生成可直接使用的 C++ 代碼，十分便捷。

Protobuf 提供了一種名為T(mén)extFormat的序列化格式，該格式類似于Json，清晰易懂。配合事先定義的 Proto 文件， 開(kāi)發(fā)者可以輕易實(shí)現(xiàn)從可讀的配置文件到具體對(duì)象的實(shí)例的反射，配置文件經(jīng)過(guò)反序列化后可以作為業(yè)務(wù)代碼類的輸入。這種方式使得配置變得便捷，不易出錯(cuò)，且具有很好的向后兼容性。

Apollo 的代碼中大量使用了這種方式來(lái)管理配置。Apollo 激活車(chē)輛的配置文件為 modules/canbus/conf/canbusconf.pb.txt，開(kāi)發(fā)者可以在這里定義車(chē)型及對(duì)應(yīng)的 CAN card 的參數(shù)，開(kāi)發(fā)者只需修改 "vehicle_parameter" 相應(yīng)的字段，即可使 Apollo 支持對(duì)應(yīng)的車(chē)型。

1#modules/canbus/conf/canbus_conf.pb.txt 2vehicle_parameter{ 3brand:LINCOLN_MKZ 4max_enable_fail_attempt:5 5driving_mode:COMPLETE_AUTO_DRIVE 6} 7 8can_card_parameter{ 9brand:ESD_CAN10type:PCI_CARD11channel_id:CHANNEL_ID_ZERO12}1314enable_debug_mode:false15enable_receiver_log:false16enable_sender_log:false

上述配置文件的參數(shù)的含義是由下面的 Proto 文件決定的。

1//modules/canbus/proto/canbus_conf.proto 2messageCanbusConf{ 3optionalapollo.canbus.VehicleParametervehicle_parameter=1; 4optionalapollo.drivers.canbus.CANCardParametercan_card_parameter=2; 5optionalboolenable_debug_mode=3[default=false]; 6optionalboolenable_receiver_log=4[default=false]; 7optionalboolenable_sender_log=5[default=false]; 8} 910//modules/canbus/proto/vehicle_parameter.proto11//Apollo支持了LINCON_MKZ,GEM,LEXUS等多種車(chē)型12messageVehicleParameter{13enumVehicleBrand{14LINCOLN_MKZ=0;15GEM=1;16LEXUS=2;17TRANSIT=3;18GE3=4;19WEY=5;20}21optionalVehicleBrandbrand=1;22optionaldoublemax_engine_pedal=2;23optionalint32max_enable_fail_attempt=3;24optionalChassis.DrivingModedriving_mode=4;25}2627//modules/drivers/canbus/proto/can_card_parameter.proto28messageCANCardParameter{29enumCANCardBrand{30FAKE_CAN=0;31ESD_CAN=1;32SOCKET_CAN_RAW=2;33HERMES_CAN=3;34}35...36}

另外要提到一點(diǎn)的是，Protobuf 提供了兩個(gè)版本的庫(kù)，即精簡(jiǎn)版 ("libprotobuf-lite.so") 和 完整版 ("libprotobuf.so" )。

The "lite" library is much smaller than the full library, and is more appropriate for resource-constrained systems such as mobile phones.

精簡(jiǎn)版體積遠(yuǎn)小于完整版，因此更適合使用在諸如移動(dòng)電話等資源受限的系統(tǒng)上。[4]

精簡(jiǎn)版的 Protobuf 常用于嵌入式設(shè)備，但精簡(jiǎn)版的庫(kù)并不支持 TextFormat 的反射功能。開(kāi)發(fā)者如果想兼具代碼體積和功能的話，可以考慮自己寫(xiě)一套格式化語(yǔ)言的反射機(jī)制，有興趣的同學(xué)可以參考《簡(jiǎn)單的 C++ 結(jié)構(gòu)體字段反射》。

Apollo Software Overview, 來(lái)源：https://github.com/ApolloAuto/apollo

從軟件實(shí)現(xiàn)上看，Apollo 通過(guò)CANBus模塊來(lái)實(shí)現(xiàn)對(duì)車(chē)輛的管理和通訊 。

CANBus 模塊接收并執(zhí)行來(lái)自 Control 模塊的指令，同時(shí)收集汽車(chē)底盤(pán)的狀態(tài)，這些狀態(tài)是Apollo 抽象出的一組與車(chē)型無(wú)關(guān)的信號(hào)。Canbus 模塊處理這些狀態(tài)與各個(gè)汽車(chē)底盤(pán)信號(hào)的映射關(guān)系，隨后將這些狀態(tài)反饋回 Control 模塊。基于這樣的設(shè)計(jì)，Apollo 得以兼容多個(gè)不同的車(chē)型。

chassis.proto文件對(duì) Apollo 抽象出的信號(hào)進(jìn)行了定義，大體包括下列信息：

Chassis 信號(hào)

CANBus 模塊主要由以下兩個(gè)部件組成

Vehicle:the vehicle itself, including itscontrollerandmessage manager

CAN Client- CAN client has been moved to/modules/drivers/canbussince it is shared by different sensors utilizing the canbus protocol[5]

在這里著重介紹一下Vehicle部分。

Vehicle的Controller(modules/canbus/vehicle/vehicle_controller.h)的類圖如下(有簡(jiǎn)化)：

Vehicle Controller 類負(fù)責(zé)完成與汽車(chē)底盤(pán)的具體交互，下面對(duì)部分公有接口做一些解釋。

1/***@briefstartthevehiclecontroller.*注：該函數(shù)會(huì)在內(nèi)部起一個(gè)名為"SecurityDogThreadFunc"的線程，該線程會(huì)周期性的檢*查與底盤(pán)的通訊狀況，關(guān)鍵信號(hào)是否有響應(yīng)，是否有錯(cuò)誤等等。*@returntrueifsuccessfullystarted.*/ 2virtualboolStart()=0; 3 4/***@briefstopthevehiclecontroller.*/ 5virtualvoidStop()=0; 6 7/***@briefcalculateandreturnthechassis.*注：該函數(shù)完成了汽車(chē)底盤(pán)信號(hào)和Apollo內(nèi)部定義的底盤(pán)狀態(tài)信號(hào)的映射。*@returnsacopyofchassis.Usecopyheretoavoidmulti-threadissues.*/ 8virtualChassischassis()=0; 910/***@briefupdatethevehiclecontroller.*注：該函數(shù)負(fù)責(zé)執(zhí)行來(lái)自Control模塊的具體的指令。根據(jù)指令的要求和汽車(chē)目前所處*的模式(完全自動(dòng)、完全手動(dòng)、自動(dòng)轉(zhuǎn)向等)來(lái)為執(zhí)行器的信號(hào)(檔位、油門(mén)、轉(zhuǎn)向等)進(jìn)行*賦值。*@paramcommandthecontrolcommand*@returnerror_code*/11virtualcommon::ErrorCodeUpdate(constcontrol::ControlCommand&command);

Vehicle 的 MessageManager 類負(fù)責(zé)完成對(duì)具體信號(hào)的接收、發(fā)送、解析等，其類圖如下：

1//modules/drivers/canbus/can_comm/message_manager.h 2//用于指定系統(tǒng)向汽車(chē)底盤(pán)發(fā)送的控制型號(hào) 3template 4template 5voidMessageManager::AddSendProtocolData(); 6 7//用于指定系統(tǒng)接收的信號(hào) 8template 9template10voidMessageManager::AddRecvProtocolData();

接下來(lái)我們以 Wey VV6 車(chē)型為例，來(lái)分析 Apollo 是如何在代碼層面上完成配置任務(wù)的。

Wey 文件夾包含有如下文件：

根據(jù) Apollo 的官方文件how_to_add_a_new_vehicle， 想要為 Apollo 添加 Wey 車(chē)型需要完成以下內(nèi)容：

實(shí)現(xiàn)新的車(chē)輛控制器--wey_controller.cc，繼承VehicleController類

實(shí)現(xiàn)新的消息管理器--wey_message_manager.cc繼承MessageManager類

實(shí)現(xiàn)新的車(chē)輛工廠類--wey_vehicle_factory.cc, 繼承AbstractVehicleFactory類

更新配置文件

在modules/canbus/vehicle/vehicle_factory.cc中進(jìn)行注冊(cè)

更新配置文件modules/canbus/conf/canbus_conf.pb.txt

通過(guò)上述方式可以增加新車(chē)型的原因在于 Apollo 的配置是基于工廠模式實(shí)現(xiàn)的。

工廠方法模式（Factory method pattern）是一種實(shí)現(xiàn)了“工廠”概念的面向?qū)ο笤O(shè)計(jì)模式。就像其他創(chuàng)建型模式一樣，它也是處理在不指定對(duì)象具體類型的情況下創(chuàng)建對(duì)象的問(wèn)題。工廠方法模式的實(shí)質(zhì)是“定義一個(gè)創(chuàng)建對(duì)象的接口，但讓實(shí)現(xiàn)這個(gè)接口的類來(lái)決定實(shí)例化哪個(gè)類。工廠方法讓類的實(shí)例化推遲到子類中進(jìn)行。”[6]

Canbus 模塊中 Vehicle 相關(guān)的內(nèi)容使用工廠模式抽象出了 VehicleController，MessageManager，AbstractVehicleFactory 三個(gè)接口。 Canbus 的業(yè)務(wù)代碼（canbus_component.cc）通過(guò)以上接口來(lái)操縱具體的對(duì)象，用戶無(wú)需關(guān)心具體的對(duì)象是什么，從而實(shí)現(xiàn)了業(yè)務(wù)邏輯和目標(biāo)對(duì)象的解耦。

工廠方法模式的定義和實(shí)現(xiàn)的相關(guān)講解有很多，本文就不再贅述，可參考下列鏈接和書(shū)籍:

https://en.wikipedia.org/wiki/Factory_method_pattern

《設(shè)計(jì)模式：可復(fù)用面向?qū)ο筌浖幕A(chǔ)》

《Head First 設(shè)計(jì)模式》

Apollo 社區(qū)布道師賀志國(guó)老師曾對(duì) Apollo 的工廠模式進(jìn)行過(guò)介紹， 接下來(lái)本文會(huì)在此基礎(chǔ)上繼續(xù)延伸。

https://blog.csdn.net/davidhopper/article/details/79197075

Apollo 提供了一個(gè)工廠模版(modules/common/util/factory.h)，該模版可支持任何類型的輸入，類圖如下：

工廠模版

Factory類包含了Register()、Unregister()、Empty()、CreateObjectOrNull()、CreateObject()等公有函數(shù)，其中Register()、Unregister()函數(shù)用于注冊(cè)和反注冊(cè)產(chǎn)品類，其作用與經(jīng)典模式中抽象工廠接口類的功能類似，Empty()函數(shù)用于判斷當(dāng)前工廠類中是否包含產(chǎn)品創(chuàng)建函數(shù)，CreateObjectOrNull()、CreateObject()函數(shù)用于創(chuàng)建可能包含空指針和不包含空指針的產(chǎn)品類對(duì)象。[7]

Factory 工廠模版維護(hù)了一個(gè) Map 用來(lái)管理 IdentifierType 和 ProductCreator 的鍵值對(duì)，根據(jù)輸入的 IdentifierType， 模版可返回 ProductCreator 生產(chǎn)的產(chǎn)品，從而實(shí)現(xiàn)了從 IdentifierType 到 Product 的“映射“。

在Canbus 模塊中，工廠類為 "VehicleFactory"， 該類繼承于工廠模版 "Factory" 。VehicleFactory 工廠維護(hù)了鍵值對(duì)為 VehicleParameter::VehicleBrand和AbstractVehicleFactory 的 Map。

如下所示，每新注冊(cè)一種車(chē)型，該 Map 中就會(huì)插入一條汽車(chē)品牌(VehicleBrand)和該品牌汽車(chē)生產(chǎn)工廠(AbstractVehicleFactory )的鍵值對(duì)。

1voidVehicleFactory::RegisterVehicleFactory(){ 2Register(apollo::common::LINCOLN_MKZ,[]()->AbstractVehicleFactory*{ 3returnnewLincolnVehicleFactory(); 4}); 5Register(apollo::common::GEM,[]()->AbstractVehicleFactory*{ 6returnnewGemVehicleFactory(); 7}); 8Register(apollo::common::LEXUS,[]()->AbstractVehicleFactory*{ 9returnnewLexusVehicleFactory();10});11Register(apollo::common::TRANSIT,[]()->AbstractVehicleFactory*{12returnnewTransitVehicleFactory();13});14Register(apollo::common::GE3,[]()->AbstractVehicleFactory*{15returnnewGe3VehicleFactory();16});17Register(apollo::common::WEY,[]()->AbstractVehicleFactory*{18returnnewWeyVehicleFactory();19});20}

當(dāng)VehicleFactory類的"CreateVehicle" 方法被調(diào)用時(shí)， VehicleFactory會(huì)根據(jù)輸入的汽車(chē)品牌，在 Map 中查找并返回可以生產(chǎn)這種汽車(chē)的工廠 。

例如輸入汽車(chē)品牌"WEY" ， VehicleFactory 會(huì)返回 WeyVehicleFactory ，WeyVehicleFactory 繼承于 AbstractVehicleFactory 。

1/**2*@briefCreatesanAbstractVehicleFactoryobjectbasedonvehicle_parameter3*@paramvehicle_parameterisdefinedinvehicle_parameter.proto4*/5std::unique_ptrCreateVehicle(6constVehicleParameter&vehicle_parameter);

AbstracVehicleFactory 工廠會(huì)產(chǎn)出一組適用于該品牌車(chē)型的產(chǎn)品即 MessageManager 和 Vehicle controller。

以 “Wey” 為例， WeyVehicleFactory 會(huì)產(chǎn)出 WeyMessageManager 和 WeyController 用于實(shí)現(xiàn) “Wey”車(chē)型的通訊和控制。

完整的類圖如下所示：

最后對(duì) CANBus 模塊的CanbusComponent進(jìn)行介紹 。該類繼承于 " TimerComponent"， 主要作用為處理來(lái)自控制模塊的控制指令，并將信號(hào)消息發(fā)送至 Can card。

CanbusComponent 的初始化函數(shù) (init )主要完成了以下工作：

1. 讀取 CANBus 配置文件

1if(!GetProtoConfig(&canbus_conf_)){2AERROR<

2. 根據(jù)配置文件初始化 Can—client.

1can_client_=can_factory->CreateCANClient(canbus_conf_.can_card_parameter());

3. 根據(jù)配置文件獲取汽車(chē)工廠

1VehicleFactoryvehicle_factory;2vehicle_factory.RegisterVehicleFactory();3autovehicle_object=4vehicle_factory.CreateVehicle(canbus_conf_.vehicle_parameter());

4. 獲取該汽車(chē)工廠生產(chǎn)的 message_manager 和 Vehicle_contorller

1message_manager_=vehicle_object->CreateMessageManager();2...3//初始化can_receiver_和can_sender_4if(can_receiver_.Init(can_client_.get(),message_manager_.get(),5canbus_conf_.enable_receiver_log())!=ErrorCode::OK){...}6if(can_sender_.Init(can_client_.get(),canbus_conf_.enable_sender_log())!=7ErrorCode::OK){...}89vehicle_controller_=vehicle_object->CreateVehicleController();

5. 使能 Can 收發(fā)和 Vehicle_contorller

初始化完成之后，CanbusComponent 會(huì)周期性的報(bào)告車(chē)身狀態(tài)，并執(zhí)行來(lái)自 Control 模塊和 Guardian 模塊的命令。

1boolCanbusComponent::Proc(){ 2//publish底盤(pán)信息 3PublishChassis(); 4if(FLAGS_enable_chassis_detail_pub){ 5//Publish底盤(pán)的細(xì)節(jié)信息 6PublishChassisDetail(); 7} 8returntrue; 9}1011//事件觸發(fā)，執(zhí)行來(lái)自Control模塊的指令12voidCanbusComponent::OnControlCommand(constControlCommand&control_command){...}1314//事件觸發(fā)，執(zhí)行來(lái)自Gurdian模塊的指令15voidCanbusComponent::OnGuardianCommand(16constGuardianCommand&guardian_command){17apollo::control::ControlCommandcontrol_command;18control_command.CopyFrom(guardian_command.control_command());19OnControlCommand(control_command);20}

Apollo 開(kāi)放車(chē)輛認(rèn)證平臺(tái)定義了系統(tǒng)與線控車(chē)輛的接口標(biāo)準(zhǔn)，并且從各個(gè)車(chē)型中抽象出了用于算法的與具體車(chē)型無(wú)關(guān)的信號(hào)。

在軟件模塊中， Canbus 模塊負(fù)責(zé)處理這些信號(hào)與車(chē)輛底盤(pán)信號(hào)的映射。

Apollo 以 Protobuf 為基礎(chǔ)使得車(chē)輛配置管理變得十分簡(jiǎn)潔易用。

Apollo 使用抽象工廠模式，使業(yè)務(wù)邏輯得以與具體的車(chē)輛解耦。

上述方式的綜合應(yīng)用，使得 Apollo 得以支持多種不同的車(chē)輛。