Self-driving challenge in a week

  1. 赛制
  2. 硬件
  3. 对的工具就是加速的轮子
  4. [参考]

用一场线下比赛挑战人类老司机?

本次比赛,虽然参加的是学生为主,但辅助的导师也并非等闲。有大学教授、研究生,有公司CEO、工程师等。结果我们知道,最后没有挑战成功,我试着从工程师的角度,重新剖析下,如何才能让这个挑战变得可行?

当我到贵阳科学城,看到来自各个国家的小伙伴,听到要挑战人类老司机这个很突然的消息时,觉得太不可思议。要知道,10多年前,DARPA的比赛,也只是在挑战环境而已。而现在做的,是先挑战某些场景任务,然后再跟老司机的挑战。

我认为还是没有完全理解这其中的问题,我再展开描述下。7天要完成的任务包括:无人车的改造、完成场景任务,最后跟人类老司机的成绩较量。

按照目前的情况,是不可能完成的任务。“不难,就不叫挑战赛了”,从这个角度,这个比赛就应该从Racing 改称为Challenge。我从三方面赛制 标准硬件工具三方面讲述下这种不可能性。

赛制

本次任务包括场景

每项任务都有对自动驾驶技术的考量,每个场景都有对于无人车而来,每增加一个场景,就以为需要增加相应的节点(ROS Node,以参赛同学的方案),处理相应的场景识别逻辑。

也就是说,这种情况下,并非目前所有的自动驾驶框架都能拿来即用,都要做些场景适配,这是解决问题,工具选择的大前提。

看完这些任务,你就能知道,这些项目基本上都是为无人车设置的。在比赛园区,GPS与人为驾驶,其实并没有关系,导航时会用到地图,但人类司机也会按照最基本的道路驾驶,而不是开到草坪上还不刹车。

而人类司机的考核应该是哪些?我在朋友圈第一次发这个消息的时候,也有同学提到这个问题,这人类司机也得看什么类型司机,新手司机,就应该把现在考驾照的那些科目拿过来。如果是老司机,那就是F1中的摩纳哥赛道,78圈的比赛圈数,让你考虑的不仅是车技,还有轮胎类型(软胎、极软胎)等等策略。

一级方程式轮胎

我从Nancy那里了解到参加这次比赛,人类司机的情况:”人类车手这次一共来了4个,3男1女,女生就是普通的女性,然后有一个年轻的小哥哥,其余就是普通的司机,各种职业都有。”虽然我没有亲眼看这些老司机的“表演”,但我想,应该是他们参加过最轻松的赛事吧。

从人类驾驶的方案上来说,上面的评分标准会有扣分项吗,我觉得很少。这个概率太小了,那这个标准跟人工驾驶的方案比,追求很高,比赛的上限就是对无人驾驶技术的最高挑战。如果技术可以到达这种程度,人工驾驶的司机报名,也许反而没有那么积极了。假如AlphaGo在没有完成与李世石、柯洁之前,认为总会给人类选手押注更多,选手也更加有带入感。

所以,任务列表并没有考虑参赛两方的针对情况,这是比赛不可能完成的原因之一。

如果期限是7天,一辆标准的自动驾驶实现方案应该是怎样的?我体验过#贵阳的无人驾驶全球挑战赛#,全球化的氛围感觉缩小了世界,开放的交流也感觉从未有过的程度。

硬件

传感器与车辆都属于硬件范围,两者正好是输入与输出的两端。传感器负责无人驾驶系统所需基础数据的收集,从而生成车辆在横向、纵向上的的执行命令,车辆负责最终控制指令的执行。所以硬件在自动驾驶平台中的左右至关重要。

根据我了解到的情况,大家在硬件方面花了不少的时间。至少前三天都在解决CAN、执行等方面的问题。问题不应该是这样的,车辆的不同,EUC等的执行器确实要跟车辆有个适配的过程,理想的情况应该是线控车辆调试完毕,即通过控制命令完成对横、纵方向上的控制验证。

我离开赛场之前的第二圈,我上车体验了下,此时的速度控制,在一些特殊的场景下,还是没有做到足够的平滑。在速度由大变小的过程中,不够连续是明显的体感不佳的原因。而速度的减弱与刹车执行是有很大关系的。所以到此时,大伙已经不关心这个存在已经很久的问题了。

另外一方面,其实是软件问题了,比如比赛的最后一天,我看见还有一辆车在重新安装软件,GPU版本适配不加,最后使用CPU运行,速度不尽如人意。这方面与与时间博弈的问题,可以提前规划分工。

写这篇短文的时候,电视正好在播《春光奏鸣曲》,以前看这些音乐家的故事,尤其李斯特的部分觉得挺乱的,果然,感情生活更是。这不是重点,乔治亚这位投机取巧的画家,在肖邦的评价下评价不错。而她,是这么说的“都是为了赶时间拿到酬劳”,这让我想到在比赛最后的时间,战斗力越强的情况。

对的工具就是加速的轮子

非常遗憾,这次比赛大家最终的选择并非Apollo,不过,我问了几位参赛的同学或者导师,“如果Apollo举办这样的赛事,你会参加吗?”,我听到的答案没有拒绝而且很积极的给我名片。让我印象深刻的是DYNAMOVE的CEO,Rohan Rao,他在听完我的介绍之后,立即给我他的邮箱,让我提前通知他。

我们倡导开放,提出开源的轮子,的同时,如果不能够让使用者体会到这种使用的快感,我们也应该开始反思。反思在开发者使用中的阻碍,在国际群体中的社区建设。

如前文所说,并没有一个框架解决拿来即用,解决所有问题。比如这次赛事中使用的挥旗启动、公交站避让等任务。如果使用AutoWare,可以在众多Packages的基础上,增加部分节点来解决这些场景的进入问题。

基于线控车辆,对控制的执行,表现做得还不够精细,也许从控制量上也可以体现出来。
AutoWare速度与姿态描述主要使用geometry_msgs/Twist,一个包含三维线速度和角速度。比如线速度控制车辆纵向上的速度变化,而角速度要跟车辆的转向关联起来,还需要二次计算。

Apollo对于包含与时间相关轨迹点的控制描述:

trajectory_point {
path_point {
x: -124.367072419
y: 364.831849142
z: -31.332377322
theta: -1.81237826921
kappa: -0.00252617800322
s: 0
dkappa: 0
}
v: 1.62222218513
a: 0.786162598236
relative_time: -0.089999914169311523
}
trajectory_point {
path_point {
x: -124.371192947
y: 364.815408289
z: -31.3321617292
theta: -1.81246574077
kappa: -0.00248790128945
s: 0.016305555109999981
dkappa: 0.00234746462335
}
v: 1.63055551052
a: 0.823007905434
relative_time: -0.079999923706054688
}

也许Apollo可以带来一些变化。这个说得再好,还是需要各位上车,体验调试过程中的问题,才能体会。

参赛的同学真的非常有才有活力,为他们集体组队对抗人类司机的选择感到动容的同时,也因为工程师这种不解决问题,不优化得到一个更好的版本二不休不眠的精神感同身受。

最后,“开放的交流”真的是非常不错的学习环境,技术不再是单纯的交流语言,可以是足球,可以是兴趣,还可以是其他,总有话题把异国的同学勾搭在一起。这里只有个人,没有公司名义,哪怕是CEO,他们也以顾问的形式加入家里,为开发者提供需要的帮助。

[参考]

script>