这个之前上七月在线的GAAS课就听到了他们开发人员不喜欢TX2，用的up square
GAAS开发笔记<1> 为什么应该用x86_64而非arm架构处理器作无人机机载计算平台
我们认为借助开源的力量，中国的无人机开发者将迎来一个无比光明的未来：我们能发明载人的全自主飞行汽车----中国人发明的飞行汽车----15分钟零32秒从中关村抵达T2航站楼某某出口，通勤拥堵的痛苦将彻底被下一代人遗忘，就像我们遗忘modem拨号上网加载图片的痛苦一样。人人都有自己的飞行汽车，享受汽车出行时代人们“难以言喻的自由”；飞行汽车（而不是电动汽车）成为新时代的新汽车工业----而这正是我们这代开发者亲手创造的。
我是无人机自主驾驶开源平台GAAS的作者。GAAS的雏形是一个我个人的粗糙项目，最终目的是实现人人都有全自主驾驶的飞行汽车。2016年我用我的小macbook做了一个简单的基于opengl的无人机避障/寻路的小项目，然后又开始了SLAM和双目视觉，建图等方向的粗略研究。
在2019年2月我们决定开源整套代码，不过我个人很少直接对这个项目本身发表言论。我的言论更多只是代表我个人的观点，请谨慎参考。
写这篇文章的初衷是看到群里很多开发者在使用GAAS做无人机机载平台开发的过程中遇到一些问题，我认为应该把我的观点发表出来，让用户能更好的了解到我开发和维护整套系统的时候是依照什么思路和原则进行的。
这些观点仅仅代表我个人观点，与任何公司和组织无关。作品一旦发表，解释权就不归作者所属了；正如同阅读理解的答案可以和文章原作者的想法不同一样。内容中可能有错误，欢迎指出。观点可能比较激进，谨慎食用。
这将是整个系列的第一篇，我们先从硬件配置说起。
没错，说的就是你，万恶之源tx2和nano.
Nvidia Jetson Nano和Jetson TX2因为价格低廉，又有较为方便的cuda支持，被很多实验室采用。然而在我看来这样的配置根本就不适合搞无人机自主驾驶研发，至少不适合大多数场景。
一.无人机自主驾驶的核心--SLAM 和平台选择的关系
我们曾经尝试过很多开源的SLAM框架。ORBSLAM ,VINS-Mono，MSCKF,ROVIO(包括ROVIOLI的全套框架）。最终我们决定使用高博的ygz-slam作为我们的初版slam系统。上面这些框架被否决，是因为
- 稳定性太差，不符合无人机上实际要求。
- 标定的要求太高。
- 计算复杂度太高
- 以上三种原因的各种组合
曾经有一段时间我们也用tx2作为机载方案，因为Skydio也在使用tx2作为产品级别的机载处理器，且之前我们预估机载平台上会有一些神经网络计算的负载。最后我们不堪折磨放弃了tx2,选择了up squared开发板。
因为tx2的性能实在太差，我们只能在x86_64的笔记本平台上开发，仿真，然后在tx2上上实机测试。
这个东西用起来的体验实在是只能用痛苦来形容。（我们全程都使用clock.sh开启性能模式）区区32GB的存储空间，30fps的图像跑ygz位姿输出频率只能到15hz（跑上一会频率就会掉到5hz左右），存储空间和I/O性能的低劣导致很难录一个大一些的包分析问题，都给我们的实机实验带来了很多麻烦。我们曾经因此一度怀疑是不是px4的ekf2视觉融合有问题。
如果说tx2本身性能低劣对tx2来说可能有些不公平。准确的说arm处理器的指令集和x86本身是有区别的，因此sse指令对计算速度的优化无法在arm平台开启，需要换成neon指令。而且arm指令集本身性能就没有同频率x86的好，定长指令双发射三发射还是无法与变长4发射比拟。而且许多依赖库在arm平台支持也不好，开发起来体验很差。
SLAM的主要计算分前端和后端。前端主要任务是追踪特征点，维护追踪结构。后端主要任务是进行图优化相关的矩阵运算。对于前端追踪特征点，cpu和gpu在单张图像的前提下性能差距不大（因为即使只有一张图，也必须考虑主存-显存的IO性能消耗），在x86平台上都是几十毫秒的级别，tx2的cuda支持优势不大。
对于后端一般常用的优化库g2o,ceres和gtsam中只有ceres支持gpu加速。因此对于后端也没有什么优势可言。
本身的开发体验上讲，x86平台的upsquared和nuc等产品只要装入开发环境用的镜像直接就可以使用。而tx2的镜像烧录相对复杂。编译一次OpenCV要一下午，而编译一个PCL库甚至要要一整天。arm平台本身适合移动端锂电池设备低耗电的性能用在手机上很合适，但对于无人机平台，尤其是经常要尝试新的算法，需要一定程度性能过剩的平台来说明显差太多了。
二.DNN inference不是无人机机载平台的刚需，甚至不是核心需求
对于RGB-D点云获取来说现在的realsense d415/d435和structure core已经做的很不错了。如果要使用双目，也可以使用基于三角剖分的手法（在algorithm/MeshGenerator中），只追踪少数几个较为精确的gftt点而无需进行不准确的稠密追踪，因此神经网络估计视差图也不是刚需。
到这里为止，SLAM, Planning和Perception都不需要CNN的参与，唯一需要的是Tracking这一块，因为没有神经网络参与的情况下跟踪目标一旦被遮挡，重找回是一个难点。
不过本身无人机做Tracking这一块现在业界也很少将它作为一个有硬性指标的要求。如果指标相对宽松，那么使用TLD之类的传统算法完全够用。很少有需求要求无人机追踪和路径规划必须达到什么条件下的什么召回率。GAAS的最终目的是实现载人无人驾驶飞行器的全自动化，因此目标跟踪也不是其中的必经之路。
就算你的需求真的需要使用gpu（比如在无人机上跑实时目标检测），tx2的性能也实在是捉襟见肘。区区256GFlops如果不对网络进行较为深入的优化，性能还是很难接受。yolov3只有不到4fps.(数据从博客随便找的，我们自己之前跑过不过记不清楚了。链接：https://blog.csdn.net/chandanyan8568/article/details/81098591）
牺牲了CNN inference能力换来的时间上的节省和可复现性，可解释性的提高却是实实在在的。每次飞行都可以录ros bag，每个bag都可以拷贝到开发环境里详细的查看复盘。而且由于使用i5/i7处理器，性能和开发用的笔记本/台式机区别不大了，在仿真环境里运行成功能给开发者更强的信心，而无需担心算法理论上可行到了实际机器上性能能否顶得住。
另外由于OpenCV支持transparent API, i5/i7这种级别的处理器可以使用核显加速OpenCV的特征点提取/追踪/稠密光流等算法。这些优化也会在新的代码中体现出来。后面的开发中预计GAAS会在每个模块中加入对多个摄像头同时输入的支持，核显加速可以大大降低CPU的运算负载，对于多张图像同时处理来说有很大的优势。
也许未来我们会尝试在无人机上用mini pci 连接up squared和nvidia桌面级显卡----Titan或2080这个级别，如果成功会分享出来。真正让开发者彻底摆脱性能焦虑，配置焦虑。
最后给大佐
传个教。
喝牛奶，吃牛肉，用i7处理器!
飞行汽车好，电动汽车坏！
浪费CPU的时间,节省开发者的时间!一次开发，到处部署！
告别arm平台，告别手动shrink CNN，告别调参侠的命运，告别内卷！