节俭的百度:给自动驾驶阿波罗计划算个账(附Apollo技术框架)

在四月份的时候,在百度宣布阿波罗计划后,本公众号发了一篇《百度能开源出什么东西?》的文章,对阿波罗计划有了一个基本的预判。于是,我就开始耐心的等待7月5日百度AI开发者大会的召开,等着阿波罗开源一探究竟,验证一下自己的判断,顺便学习学习。

终于等到了,看着朋友们从现场发来的图片和信息,看到陆奇在现场连线坐着无人车赶来的李彦宏时,心里忽然有一种莫名的激动,而当陆奇在台上挥舞手臂号召大家鼓掌的时候,这种激动居然还包含了一丝感动,我看到的是一种偏执,一种对技术的偏执,我看到了一种力量,一种敢于迎难而上的力量。

节俭的百度:给自动驾驶阿波罗计划算个账(附Apollo技术框架)

文/老王同志 机器人评论(微信ID:RobotReview)

于是,心里忽然幻想了一下,或许在百度的旗帜下,我们真的能够打倒那些帝国主义列强,让他们把压榨我们的还回来,让他们把我们这个勤劳善良的民族的美好时光还回来,我们也要过好日子,我们也要带上老婆出城去,吃着火锅唱着歌。

对,找帝国主义列强算个账,但是,但是……

(一)李彦宏违章了

在这个消息发布之前,李彦宏的视频我也仔细看了看。尽管那辆龙辇是在前后左右、穿着廉价便服的大内护卫的掩护下一路前行,但看着还不错,特别是看到彦宏同学的满面春风,the feel so good。

可惜,好景不长,有细心的网友发现,李彦宏那辆车实线并道违章了,并且还有热心的朝阳群众把这个事举报给交管部门了。朝阳群众们呀,你们举报名人嫖娼吸毒的主要业务模式不能乱变呀。难道是海淀码农伪装的?有可能。

为什么会出现这种情况呢?

有两种可能:
第一、视频连线结束、任务完成,驾驶员接管了。
第二、行驶中驾驶员打了转向灯,车辆自动变道了。

第一种跟技术没关系。那么如果是第二种情况,就是技术问题,表明:要么是高精度地图没建好或者车道线识别不够好,要么是定位出问题,要么是决策时根本就不考虑虚实线。不管什么原因吧,这个瑕疵还OK,它只会增加一点点事故发生的几率,此外,在咱们伟大的祖国,严格按照交规驾驶可能会更不安全。

不纠结这个了,总体来说,这辆主要依靠博世的L3级ADAS系统的自动驾驶车辆,表现还是不错的。百度无非最多被扣三分、罚两百,但如果让人误认为这辆车是百度做的,那还是很划算的,这笔账百度算的比较精明。

这些本来就在意料之中,百度的自动驾驶技术本来就掌握的比较粗浅,所以,这些事情是改不了我对Apollo的期待的,因为至少从它发布的框架来看,还是很中规中矩,亮点十足的。

(二)Apollo技术框架

就这么一张图,大的方面分总共四层。

节俭的百度:给自动驾驶阿波罗计划算个账(附Apollo技术框架)

(1) Reference VehiclePlatform层
Reference VehiclePlatform在最底层。Reference的含义是:我提供了一个Specific的东西,但是你可以根据我这个Specific的东西来创建你自己的Specific的东西。

那么对于Reference VehiclePlatform来说,这个特定东西是什么呢?

很简单:一个特定的应用层协议以及应用实现代码。

对于,车辆与上层控制系统来说,这个应用层协议主要包含三个类型的消息:1)自动与人工模式设定消息;2)油门刹车转向档位灯光等控制消息帧;3)车辆运动状态和运行状态消息帧。

基于这个应用层协议,根据选择的应用层以下的协议(TCP/IP、CAN、RS232),结合特定的计算机接口驱动API(CANDriver、Socket、Serial),就可以写代码了,最终形成一个特定应用的代码。

是的,这就是一个很简单的东西,唯一的难点是底层车辆上的总线如何规划,如何给自动驾驶系统配置总线资源,不过这个跟百度无关,是车辆提供方的事情。

综上,这个Reference VehiclePlatform大概等于一个正常软件工程师一周的工作量吧,就按互联网公司计算,大概也就1W吧,再上电费、工位费乱七八糟的就按2W算吧。

(2) Reference HardwarePlatform
这一层主要包含计算机硬件和传感器,当然这些都可以买,百度唯一可以做的工作就是像Reference Vehicle Platform层一样,写个软件把这些数据采集进来。

不偏不向,还是按每个2W算,GPS、IMU、Camera、Lidar、Radar,总共10W,那个人机接口设备HMI Device跟自动驾驶关系不大,考虑代码量,多给点,5W吧。

好吧,这一层也就15W,当然如果去参考一些网络上的数据采集代码或者使用一些库,就会节省很多,当然百度肯定会这么干,所以这一层花费10W应该够了。

(3) Cloud Service Platform

这个层多少钱,不清楚,互联网我不懂,不过这个层的钱不能算在自动驾驶头上呀。

(4) Open Software Platform

这一层是核心,也是Apollo要开源的东西,包含了各种自动驾驶技术,并且还包含了RTOS(实时操作系统)、runtime framework(运行时框架)。单一个RTOS,花个1000万也不多,runtime framework至少花500万,自动驾驶的算法那就得1亿起了。

但是
昨天在晚高峰的地铁里
朋友给我发来了Apollo项目的地址
经过仔细翻阅

发现:其实OpenSoftwarePlatform花不了什么钱

节俭的百度:给自动驾驶阿波罗计划算个账(附Apollo技术框架)

(三)Open Software Platfrom

总是谈钱,不太好,先浏览一下这个开源代码吧,地址是https://github.com/ApolloAuto。

总共有三大块:apollo、apollo-platform、apollo-kernel。

(1)apollo-kernel是个什么?

很简单:Apollo-kernel=开源linux+一个免费的RT-OS补丁+显卡驱动+CAN卡驱动。

那么这个需要多少钱?

如果你拿这个问题去问一个linux系统工程师,他会觉着你在侮辱他,因为这就是装个操作系统。难道每次装个系统都要送一个师姐吗?

但是,就是这么个装机的事情被Apollo弄成装A的弟、C的哥。

回看一眼Apollo的技术框架,在哪张图里有个RTOS,就是它,开发需要1000W吧,但是如果装个机不开发,那不值钱。并且,这个东西你不开源都不行。

(2)apollo-platform值多少钱

之前的文章里提到过ROS,我说它是后操作系统,它构建在操作系统之上,能够为各个应用程序之间的交互提供runtime framework的功能。这个Apollo-platform就是这个runtime framework(此外还包括在apollo里的那个docker),并且如早前所言,用了ROS。

既然用了ROS,这个Apollo-platform也不值钱,对不对?

当然不是,至少这个Apollo-platform还是花了些钱的。它“深度”修改了ROS,可以称之为Apollo-ros,可以算作是Ros的一个版本,但与原生Ros不兼容(不兼容的具体含义我试着在后面解释)。

它主要修改了三部分:
1)为ros提供了共享内存的IPC机制;
2)把集中式的采用CS模式的rosmaster变成了对等式的rosmaster;
3)提供了ros消息定义规范之外的消息定义机制。

这些都是有些难度的,如果对ROS理解不深是做不出来的,不过代码量不大。但我想说的是,这些工作是没什么太大意义。

A.提供共享内存IPC机制的伪需求

共享内存和Socket回环网络相比,主要的区别是:1)Socket会比共享内存机制多一两次数据Copy的开销;(2)共享内存需要互锁机制,稍有不慎容易出现灾难性的segment error,Socket没有这个顾虑。

基于上述基本分析,如果在高强度测试的情况下共享内存机制会比Socket在读写时间和资源消耗上有明显优势。更多自动驾驶汽车解读:www.yangfenzi.com/tag/zidongjiashiqiche

可惜,这个高强度在自动驾驶汽车的应用上基本不存在。

B.对集中式master认识不足下的乱改造

原生Ros的基本机制可以这样粗俗的理解:Master是一家婚介所、Node代表一个家庭,这个家庭里有子女,有需要娶老婆的publisher,也有需要嫁汉子的subscriber。

子女告诉这个家庭的家长想嫁娶,家长就去婚介所找信息。

在婚介所找到信息后,跟对方一相亲,很般配,然后结婚就开始过日子了。

在这种机制下,要想结婚必须通过婚介所。现在只有一个婚介所,如果这个婚介所没了的话,那就无法继续提供婚姻服务了,大家就结不了婚了,当然,原来结婚的该怎么过日子就怎么过日子。

这个体制本身没有太大问题,因为只要不增加新的结婚需求,婚介所没了也就没了,各家的日子照过。并且,这家婚介所凭什么就没了呢?

但是apollo杞人忧天了,用互联网思维给大家拉个群,所有信息共享,不要婚介所了,这个当然更好,但没必要。

并且此举还带来了问题,这个问题就是apollo版本的Ros与原生ros不兼容。你在原生ros下编译运行的程序,无法与apollo ros下的程序沟通。你看不到它,当然它也看不到你。随之而来的结果是在原生ros环境下运行rosnode list,rostopic list这些命令会不起作用,据推测在那个docker运行环境下应该会有效。

详细的原因以及apollo ros作了那些修改从而实现了上述机制,我这里提供几条线索,欢迎交流。

1)Apollo修改了rosmaster.cpp,以及master.py的一些源码,开了微信群截取了注册请求、查询请求信息。不过,这些代码更改没有标注说明。

2) Apollo利用DDS的机制来构建微信群实现了注册、查询、发现服务,具体请看一个participant.h, .cpp。需要骂街的是participant被Apollo闭源了,核心实现提供了一个.so的库。

C. 为了与ROS解耦,提供了另外一种消息定义机制。这个完全没必要,如果仅仅为了不耦合ROS,这个真没必要,因为你耦合的已经很严重了,不如就乖乖的从了吧。

综上,根据工作量和工作难度,Apollo-platform花上个20W,应该够了。现在说第三个板块apollo

(3)Apollo里有什么

apollo就是一个自动驾驶的功能框架了,各种模块的源码,当然也包含一些算法。在这个Apollo里还是看到了一些高大上的东西,比如Factory、Adapter、Observer等软件架构范式,并且采用了Google的一个叫做docker的工具用于提供进程粒度的运行管理,当然也包含了一个代码管理编译工具bazel,这些我也不懂,都是百度出来的知识。

值得表扬的是:它的模块封装不错,并且是和Ros解耦的。

值得警惕的是:目前这个框架中的AI范式采用的是SPA,这个框架是否能解决自动驾驶问题有待讨论,总之,这个驾驶脑很僵硬,不聪明。

此外,没啥算法,这个东西估计花20W就能搞定。

(四)算个总账吧

经过初步估价,如图总共是52万,再加上200块钱的交通罚款,总价应该52万零200。结论是,花小钱办大事。

节俭的百度:给自动驾驶阿波罗计划算个账(附Apollo技术框架)

(五)百度为什么开源?

有情怀的说:是为了与帝国主义算账。
不谈情怀的话就是:圈你们的算法,圈用户粘性。

(六)怎么跟百度玩?

你觉着的呢?

我觉着吧:应该把Apollo下载下来,学习它的软件架构设计思路、代码组织结构、学习类似于docker这样的好工具、从它玩坏ros的教训中学习如何玩好ros、下载它的数据,然后好好做算法,好好搞科研,等待百度的态度变化,然后再决定是否上船。

(七)后记

本文章是通过阅读代码进行思想试验得出结论的,非常不靠谱。
所以还是那句话,不要当真,纯属娱乐。

但愿我是度了君子之腹,希望大家在保证自己利益的情况下,多支持apollo,毕竟对于很多人来说,没有百度的日子更难过。

不一定要批评那些爱忽悠高层领过导的中层干部,让大boss误判形势,累死千军,自身也得不到好处。

当然更要批评那些大boss,你会不会算账呀?

·氧分子网http://www.yangfenzi.com)延伸阅读:

➤ Uber杀入战场,无人驾驶颠覆传统汽车只要3年?

➤ 百度无人车负责人揭秘项目核心技术光学雷达(LiDAR)

➤ 百度顾嘉唯:智能人机对话和自动驾驶才是人工智能的核心场景

➤ 百度发布“智慧汽车战略”,并计划三到五年与长安合作推智能汽车

➤ 地平线机器人李星宇:复杂的中国驾驶场景,正是深度学习的优势

➤ 丁健对话戴雷王劲徐成光张博赵勇 交通革命从创新而来向未来而去

氧分子网(www.yangfenzi.com)是关注互联网生态圈的科技新媒体

·氧分子网http://www.yangfenzi.com)综合整理

分享给您的好友:

您可能还喜欢…

发表评论

电子邮件地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>