miivii域控制器(Xavier)实现TensorRT加速后的Ultra-Fast-Lane-Detection项目

TRT_ONNX2是神力模型转换工具链
鸡汤哥知乎金天

一、配置TRT_ONNX2

1、安装依赖

（2020.09.30更新）昨天刷了JetPack4.4，很好用！只需要下载编译thor即可，其他依赖项原生满足。

（1）TensorRT 7

(2020.09.29更新)TensorRT是深度学习推理(Inference)优化器，主要针对NVIDIA GPU，应用于模型部署、实际预测阶段。TensorRT通过分析深度学习模型，将各层进行横向、纵向合并，减少CUDA对输入/输出张量的读写时间，从而使模型更小、更快、更高效，加速推理过程。Tensorflow\Caffe深度学习框架训练出来的模型，可以直接丢进TensorRT框架中去，对模型进行分析优化。PyTorch\Caffe2等框架训练出来的模型，需要先转化为ONNX通用深度学习模型，然后才能丢进TensorRT中优化。详细的TensorRT介绍参考TensorRT(1)-介绍-使用-安装。

nvidia官网TensorRT各版本下载
Installing TensorRT

（2020.09.28更新）域控制器刷机后自带tensorrt5.1.6.1，鸡汤哥说工具链不支持tensorrt5，因为该版本的很多接口过时了，因此参照安装教程，卸载了自带的tensorrt。

我看了安装教程，主要是安装一些python接口和库，而项目中主要用到tensorrt中的c++库，因此下载TensorRT 7.0.0.11 for Ubuntu 18.04 and CUDA 10.0 tar package(这里还有坑，make时报错今天没有解决)，在~/目录下解压，将文件夹重命名为TensorRT，并执行

$ ln -s /home/nvidia/TensorRT /home/nvidia/cola/trt_onnx2

就会在trt_onnx2文件夹下创建一个TensorRT软链接文件，它是软链接到/home/nvidia/TensorRT目录的。

这里有2点要注意：一是安装包解压位置必须是~/，二是必须重命名为TensorRT，这是项目作者在编译规则中制定了的，不这样做make就报错。如图在cmake时，TensorRT的头文件和库文件总是包含在特定路径之下。

（2）gflags

(2020.10.02更新)JetPack4.4不需要再另外配置gflags

（3）thor

安装编译thor
thor是一个C++库，为深度学习提供大量的工具、算法和可视化模块。

build_full.sh安装完整版，在配置glog时，同时执行了源码安装和sudo apt安装，把环境搞得乱七八糟，导致最后刷机。

build_simple.sh安装简化版本，客服大佬说安装简化版本时，能自动把需要的依赖全部安装上。于是执行了命令build_simple.sh，如愿以偿地报了错：

显示需要OpenCV4.0，而在系统中检测出来了3.2.0和3.3.1。欲仙欲死的Xavier配置OpenCV4.0之路开始了：
a. 按照百度上各路大神的“TX2配置OpenCV教程”、“Xavier配置OpenCV攻略”，我需要先执行sudo apt-get purge libopencv*删除系统中现有的opencv，一顿操作过后，我发现/usr/lib/aarch64-linux-gnu中opencv相关的文件都不存在了。然而我进入python，import cv2后，发现一切正常！！这不是我想要的结果啊，我刚才都做了什么？？
b. 先不管了，接下来配置4.0.0版本，仍然是参照各路大神的操作，进行源码安装，cmake步骤要了亲命，使用cuda的、不使用cuda的、使用opencv_contrib的，试了各种各样的camke命令，无一例外都失败了，各种闻所未闻见所未见的bug蜂拥而来。。。草泥马
c. 群里请教，有位大佬推荐了一个看起来很牛逼的安装方法，然并卵
d. 最大的疑惑是，系统里从哪冒出来一个3.2.0的版本？

删除CMakeLists.txt里对OpenCV4.0的指定： 时间花了不少，我感觉自己解决不了这个问题，于是请教鸡汤哥。鸡汤哥说把CMakeLists.txt里指定的4.0去掉，不必安装4.0版本。试了下，还真起作用，同时产生了新的问题：

显示找到了opencv3.2.0，谁配置的你？

配置protobuf: 貌似是protobuf没有安装，参考Protobuf安装步骤，protobuf-cpp-3.13.0下载链接，提取码eibq。安装时间大约半天，中间没出什么岔子，protobuf测试参考google protobuf安装与使用，注意两点：一是.proto文件名称是addressbook.proto，二是两个.cpp文件中，包含addressbook.pb.h头文件时要加绝对路径#include "/tmp/address.pb.h"，否则会报错找不到该文件。以为一切就绪，然而还是那个错误：

（2020.09,30更新）JetPack4.2和4.4版本都是自带protobuf的，不用另外配置。今天用JetPack4.4试了一下，不需要任何其他操作，./build_simple一次成功。

修改CMakeLists.txt中libprotobuf.so读取路径: 鸡汤哥又提供了一种思路——看看报错提示的那个路径有没有.so，没有就是有问题，有时候有但可能只是残存的错误软链接，把那个文件拷贝下看看。
按照提示自然是不能找到.so文件的，arm架构怎么可能会有x86的路径，我在根目录下搜索了libprotobuf.so，结果是这样的：

.so文件是有的，但不在x86目录下，那么为什么会出现x86这个神奇的路径？我想到编译时需要的各种头文件、库、依赖都是在CMakeLists.txt里指定的，于是打开CMakeLists.txt，果然看到了写死的路径：

• 这种方法是把库的路径写死了，理论上打开第一个注释，就会自动寻找需要的protobuf库，这个有待在新的域控制器上实验，这里就不折腾了。
• 鸡汤哥说自动查找动态库时，默认链接libprotobuf.a，但是链接.a文件就会出错，因此写死了路径，链接.so。目前没有好的解决办法。

修改.so的路径后终于将thor编译成功

折腾几天，或许最大的收获并不是thor编译成功本身，而是在这个死去活来的过程中，我意识到其实强如鸡汤哥这样的大佬，在面对疑难bug时，也并不能一剑封喉，一上来就找到解决办法，而是在理解编译原理的基础上，找到造成bug的可能原因，然后一个个试验，这是个不断试错的过程。

（4）opencv

Xavier上配置OpenCV，可以说是苦海无边！参考上一步编译thor。
（2020.10.2更新）JetPack4.4刷机后自带OpenCV4.1.1，不需要另外配置。

2、编译

TensorRT的坑在这里：TensorRT/lib/中有两个.so文件不兼容

用readelf命令查看elf格式文件信息，Machine显示x86-64，目前推测原因是：TensorRT安装包是在x86平台上编译生成.so共享库文件，在arm架构上不兼容，暂时没有找到解决办法。

（2020.09.29更新）Nvidia官网上没有看到支持arm架构的TensorRT版本，鸡汤哥说Xavier平台不能单独安装TensorRT等，它们是随JetPack一起烧录进去的。JetPack4.2烧进去的是TensorRT5.1.6.1，问了米文，JetPack烧进的是TensorRT7，下载烧写镜像，刷机。

（2020.09.30更新）刷了JetPack4.2，自带TensorRT7.1.3，OpenCV4.1.1，这两个都不需要另外配置了，只需要下载编译thor。终于编译成功trt_onnx2

二、运行（2020.10.3更新）

1 配置onnx-tensorrt，.onnx 转 .trt

要先配置onnx-tensorrt，将*.onnx模型转换为*.trt模型。参考onnx-tensorrt，下载源码进行编译。

BUG 1 cmake版本太低

参考Jetson TX2上升级cmake方法

BUG 2 源代码下载不完全

third_party/onnx/目录下是空的，进github里一看，onnx这里是一个链接，在third_party/文件夹下源码下载链接对应的源码即可。

BUG 3 $ onnx2trt my_model.onnx -o my_engine.trt报错

一种方法是：用./onnx2trt代替onnx2trt
另一种方法是：build文件夹路径下，终端执行sudo make install，将编译出来的二进制文件、库、配置文件等放到相应的目录下，参考linux系统应用编译构建：make 、 make all 、 make clean 、 make install 区别，模型转换命令就可以正常执行。

2 检测视频

将上一步转换得到的.trt模型复制到trt_onnx2/models/文件夹下，终端执行命令

$ ./build/examples/demo_ultra_fast_lane_det -trt_f ./models/lx_engine.trt -data_f ../video.mp4

(2020.10.2更新)国庆献礼，终于跑通Ultra Faster Lane Detection TensorRT加速项目！从8月20号来恒大城开始，就一直饱受车道线检测的虐待折磨，时常心如死灰，生无可恋。在找项目，换模型，配环境，解决bug的苦闷日子里，我经常去楼道里锻炼身体来转移注意力，或是去房顶眺望远方，不断地问天问地问自己，这种屡试屡错、原地踏步、毫无进展的日子什么时候才是个头？好在项目和甲方都不允许我放弃，逼我硬着头皮死磕，现在总算看到了胜利的曙光。
现大体总结下在车道线项目我走过的“山路十八弯”：
目标：检测出车道线，并把车道点通过ROS消息发布出去，要求适时性要好。
过程：
（1）a.整个项目都要基于ROS;b.之前试验过传统方法，受光照、阴影、道路磨损、转弯不稳定等诸多因素影响，达不到上车要求，于是我锁定了目标方法的2个条件：基于ROS和深度学习方法。无人驾驶汽车系统入门（三十）——基于深度神经网络LaneNet的车道线检测及ROS实现同时具备了我设定的两个条件，简直不要太爽，因此在这个项目上花费了大量的时间与精力。程序依赖tensorflow和sklearn库，而tf又不好下载，arm上安装难度又大，折腾了一个星期，终于总结出了米文域控制器（基于Xavier）安装tensorflow-gpu，然而在安装成功的时候，我发现烧写的JetPack4.2里面自带tensorflow1.13，欲哭无泪。历经艰难终于把环境配置好，程序的运行又出现了各种各样的版本、模型输入bug，我甚至对着大段大段的报错一行行修改源码，连warning都不放过，然并卵。我怀疑是不是用的模型有问题，试了github源项目作者提供的模型，又试了原始的lanenet模型，都以失败告终。半个月过去了，我的进展只是证明了这个项目跑不通！那时候心态开始崩溃，我被迫彻底放弃了这个我曾经寄予厚望的完美匹配的项目。
（2）在光哥的催问下，我决定退而求其次，先用传统方法实现一个初级版本，之后再探索深度学习方法。传统的OpenCV方法本来是在设定目标条件时就被我排除在外的，但是在项目进度的压力下，实在是没有什么办法。疫情期间，我在家里实现过无人驾驶技术入门（十五）| 再识图像之高级车道线检测，现在只需要把它改造成ROS版本，我对此还是很有信心的。我在域控制器上复制了之前在台式机上正常运行的程序，结果出人意料，失败了。在台式机上运行时，程序有一个致命的bug，有时候会莫名其妙地报“容器不能为空”的bug，锁定了出问题的代码，同时锁定了程序报错时检测的那一帧图片，发现图片里车道线很清晰，光线也还好，上一帧检测的好好的，下一帧就报错。这个问题不会一开始就报错，而是程序运行一段时间过后报错。而在Xavier上，刚运行就报这个错，各种改，各种加判断条件都无济于事。那时候我完全慌了，深度学习方法行不通，传统方法又报错，这个功能是不是就实现不了了？？？我问师兄要了份他改造过的代码，还是没运行通。心里一慌，根本没办法静下心来再认真看代码、改代码了。我从怀疑代码、怀疑项目，开始怀疑自己，一度觉得每天吃饭都是多余。
（3）与光哥讨论后，看了Nvidia和Autoware，前者准确度太差，后者没有视觉检测车道线模块，也放弃了。
（4）怀疑归怀疑，睁眼起来，项目还是要搞的。我用残存的一点思考力对浪费的将近3周的时间作了小结。OpenCV方法的套路都是大体相同的，代码非常相似。这个运行不通，其他的传统方法一定也不行。这次算是彻底堵死了传统方法的路。但是深度学习方法不一样，框架多，模型多，一个不行可以换另一个。最终确定：**还是要用深度学习方法，因为实在找不到用ROS实现的现成项目，这次没有基于ROS的限制，**只要能运行通就好，基于ROS自己来改。又反复看了lanenet-lane-detection，最终因为报错涉及到模型本身，放弃了。在完成深度学习大作业时，我实现过PINet，回顾了下，发现加入了后处理，每秒只有10帧左右，适时性太差，去掉后处理程序，检测结果太差，放弃。这期间的各种尝试、各种失败，可以看基于ROS的车道线检测项目记录。
（5）实验课期间，请教了班里几个同学，接触到了mana，想着死马当活马医，再试试。先是在miivii域控制器(基于Xavier)上复现Ultra-Fast-Lane-Detection源论文项目，然后就是这篇实现加速项目的记录。自己本来就菜，很多时候大佬的一句话，就需要我花费一天甚至两三天的时间来进行尝试消化，期间各种辛酸真是一言难尽。

死磕40天，今天总算是看到了胜利的曙光，后面ROS版本改造会更复杂，而且基本没有人再指导了。mike加油～～～