自动驾驶，代码上车的最后一关，我来把关！

本文正在参与 #我的成功项目解析# 征文活动，一起来聊聊自己的成功经验吧，京东卡等你来领~

大家好，我是开车的阿Q，自动驾驶的时代已经到来，没时间解释了，快和阿Q一起上车。

作为一名自动驾驶系统工程师，在自动驾驶工程化落地的途中，最常遇到的问题就是：自动驾驶系统的跨平台移植与嵌入式部署等方面的问题。最近也有幸在公司参与了这样一些工作，在此分享出来，以供各位参考。 alt

算力评估

在算法移植之前，第一步便是进行跨平台的算力评估，无论是NVIDIA的Orin、Xavier，还是地平线、黑芝麻等平台，在移植之前都要要评估算力，具体包含两方面：

一方面是CPU的通用算力，比如说像规划控制这方面的算法就部署在CPU上，比如可以采用MIPS(Million Instructions Per Second)每秒处理的百万级的机器语言指令数。或者评分算法如：Dhrystone、CoreMark等来评估嵌入式ARM CPU和原来x86平台的算力

另一方面是异构的算力，如感知神经网络的加速，比如在GPU上或者定制的ASIC电路，不过这块算力就见仁见智了，有芯片公司提出的算力真的只供参考，动不动就几百tops，但实际表现还要以实际为主，此时特别需要留意这些算子的支持情况。

交叉编译

平台选择完成后，第二步就是算法代码的交叉编译，交叉编译就是考虑到嵌入式target端算力不够，需要在host端的PC上编译代码，搞交叉编译要熟练的掌握编译原理，在搭建好一套完备的交叉编译编辑链之后，分为编译和连接两个部分，而连接又分为静态连接和动态连接，其中静态连接库.a只在编译时调用，而动态连接库。so编译和运行时都要使用，所以还要找到对应平台的连接库。此时需要谨慎的处理好所有的交叉编译依赖库，然后才能把代码移植上去。而对于GPU来说，更要考虑底层的算子的支持以及相应的加速需求是否满足。

alt

仿真测试

在完成算力评估和交叉编译测试之后，代码能直接在嵌入式平台运行了，但这个时候一般是不能直接上车的。在自动驾驶的开发过程中，我们还需要进行仿真测试:

SIL：Software in Loop，在软件上验证模型是否与代码功能一致

PIL：Processor in Loop，在目标处理器上验证模型是否与代码功能一致

HIL：Hardware in Loop，在整套系统上验证代码是否与需求功能一致

算法本身的可靠性方面是通过SIL进行测试，而对于嵌入式上往往要进行PIL或者HIL的验证。通过搭建相应的测试平台，如模拟摄像头的输入，模拟感知信号的接入，可以在上面试运行部分代码来评估代码的性能，内存等资源消耗。由于嵌入式上往往算力低于原有平台，所以还要针对代码进行优化，比如说优化通信的结构，降低通信接口的数量，然后对代码层面进行优化，这样才是一个上车的好代码。

总之自动驾驶的工程落地还有很多问题，这些都需要自动驾驶工程师对整个系统有深入的理解，阿Q也还需要继续努力，持之以恒，不断学习进步。

这里还有阿Q整理的技术资料总结，欢迎大家关注！ 【岗位分析集合】