menu

Ubuntu for Autonomous Vehicle 在自动驾驶车上使用Ubuntu

在自动驾驶的机动车上使用classic Ubuntu,是个很乱七八糟的事情。 ;-)

但其实这也是很合理。

在过去几年的工作里,我主要为一些行业客户提供GNU/Linux的支持。在系统的选型上,有几种选择提供给他们:Ubuntu/Debian发行版,Yocto, BuildRoot/OpenWRT,Busybox。因为平台的规格较高,应用场景相对复杂的缘故,所以主要集中前面两种选择上(后面两种主要专注于制作tiny os,类似家用路由器/行车记录仪等产品。
我一直偏执的向他们推广Yocto,因为:

  • “powerful customization architecture”,小到几mb的IoT OS,大到完整的Debian Desktop,都可以在这个框架下生成。
  • “compile everything from source”,整个项目,从最底层的libc/gcc到最终运行的应用,都有比较清晰的管控。

但是,除开一些比较专业的客户,会去选择Yocto以外,基本不吃我这套忽悠,Ubuntu/Debian发行版选择的比例更大。

Disadvantages

看下面这个Ubuntu为了推销Ubuntu Core所画的图会更加直观

可以看到classic的发行版是一堆package的集合,不像现在的移动端系统,没有层级的概念 —— 这直接导致了

  • 应用软件无法快速和方便部署
    • 依赖基于系统,升级应用的同时需要对系统进行升级
    • 应用间共享依赖,升级单个应用会影响到其他应用
  • 不具备SOTA/备份等功能
    • 没有用户分区/系统分区概念, 没办法区分擦除
    • 系统只有一份实例,不能在运行时升级自己
  • 应用软件默认没有权限控制/隔离

Advantages

这么多区县级独角兽客户喜欢选择Ubuntu,肯定还是有原因的。

Ubuntu最主要的优势在于生态。
比如说现在我们想要运行tensorflow,如果你使用的Yocto,那你要做的事情有

  • 移植bazel到yocto
  • 整理tensorflow的依赖到yocto
  • 基于yocto编译tensorflow

对于Classic Ubuntu而言,你只需要输入sudo apt-get install xxx就可以安装了。

编译部署过后,代码还会存在版本适配的问题:lib1的版本A跑的正常,用版本B替换后出现问题。
在Ubuntu上,有非常多的开发者和你用着同样的环境,这种问题基本已经暴露。

另外,很多缺陷也都是可以被容忍的。

  • 硬件平台的规格越来越高,Gigabyte的存储需求对很多应用场景来说并不是问题
  • 没有定制性无所谓,在没有几百人的OS Team前,没人想去动他们
  • OTA是可以通过粗暴的方法实现的,比如说A/B分区,比如说snapshot

关于OTA,对有历史包袱的桌面系统而言,很多通过snapshot的方式来实现SOTA/备份等功能。虽然对端侧设备而言,这样的实现开销是比较大的:snapshot的copy-on-write特性导致系统体积增大。

Summary

缺点  
臃肿 Ubuntu/Debian系统标准安装下附带的软件包及其庞大,至少是Gigabyte计量
没有定制性 concept of a “distribution” of Linux,发行版诞生之初的目的,是提供预编译/配置的应用程序库,让用户可以通过CD/网络等方式跑起需要的Linux程序 —— 但这种便利也意味着定制能力的缺失
OTA 结构上的历史包袱,大部分发行版并不能做到像Android这种移动端/IoT系统所支持的atomic system OTA
维护成本高 系统以应用包为单位,应用之间耦合大
其他 专利/License风险
优点  
apt源 源码编译是个坑,不解释
生态
环境一致 开发环境和生产环境的一致性可以带来很大便利, 不然像以前所对接的客户都有专门的所谓rootfs工程师(类似运维?

其他

Classic Linux Distribution

现在SBC(Single Board System)越来越流行,比如说Raspberry PI。 基于SBC,有大量开源的小伙伴们都在尝试classic发行版在这些平台的应用

  • rasbian, 树莓派的操作系统
  • armbian, 专门针对sbc的ubuntu/debian定制版本
  • ……

虽然说端侧设备,大多是low-cost的方案,并不适用发行版。 但在storage越来越便宜的未来,还是有很大的空间的。

Container-like OS

对于现在的系统而言,实现层级的方式也有很多,除开像Android/ChromeOS这种从libc开始重写的,目前linux上比较流行的是更换package manager,采用containerize application/system的方式实现层级, 比如说rpm-ostree,flatpak,snap。

这块用于我们的无人车,主要面对的问题是投入:

  • containerize增加额外开发成本,不像classic Ubuntu, 直接apt/pip
  • container到kernel之间过了一层containerd+runc, app的运行环境不能确认和host userspace一致

理想的情况:

但是,如下图,container内部要和GPU交互的话,可能还需要driver+containerd端的支持(也可能不需要?如果运行在privilege的模式下:

Continue

  • System OTA: 为Ubuntu实现系统固件OTA
  • OS Build system: 构建/发布基于Ubuntu系统的无人车固件
  • Safety + Realtime Robot Framework: