李得毅驾驶脑设计与实现.pptxVIP

李 德 毅 2016年2月15日; 设计是一个从全局到局部的过程，要高屋建瓴；实现正好反过来，要关注细节。对于轮式机器人中的驾驶脑，无论由上而下还是由下而上都理清楚了，才能构成一个原理型驾驶脑样机，也才谈得上驾驶脑的品质和智商,;驾驶脑设计与实现 (上篇);一、呼之欲出的驾驶脑;驾驶脑;智能车产业化;智能车驾驶脑研发历史回顾;在后备箱里放着一堆交换机、工控机等软硬件耗电几百瓦，启动慢，通风散热不好，如何产业化？能否做成一块板卡？; 驾驶脑的量产是智能车产业化的必然选择，要求驾驶脑是一种“大接口、小尺寸、高性能、高可靠、低功耗、低成本”的嵌入式平台，它可以是一个盒子、一块板卡，最好是一个芯片。;智能车传感器种类和数量如何确定？如何配置？ 车载计算机、操作系统、编程语言如何选择？ 如何设计出“不牵一发动全身”的软件架构？ 支撑??块和应用模块如何划分？各需多少？如何配置？ 计算、存储、带宽等资源如何冗余？可靠性如何保证？ 智能化和汽车已有的自动化如何握手？ 驾驶脑的智商如何提高？;例如：英伟达DrivePX的自动驾驶系统;英伟达DrivePX自动驾驶系统软件架构; 回顾近十年来我们参加的比赛和里程碑试验，智能车各种感知和认知手段，相互依存，彼此缠绕。在各类比赛场、测试场，智能车表现千奇百怪、反反复复，我们困惑过，迷茫过，试来试去，换车、换平台、加电源、换模块，通过多车交叉验证和常态试验，终于理出了头绪，形成全新的驾驶脑设计!;FPGA; 和各种车载传感器相比，驾驶脑的架构设计、模块划分和界面约定才是智能车的生命力，进而决定智能车产业的核心竞争力！; 这不是一个教授的学术报告，而是一个团队总工程师的技术版本升级报告，也可以说是一个架构师认知工程最新设计方案；这不是一个共识的总结，而是一个非共识部分或者说特色部分的问题解决方案，几乎融入我们所有的相关发明专利和实践经验，要尊重自己的创造！;充分肯定智能车架构1.0中的成功实践！;驾驶脑3大认知并列 动态路权理论 传感器不相互依赖 传感器布局体现选择性注意 传感器之间免同步技术 点云不进入决策;记忆抽象和认知背景 已有认知协助当前感知 3x3形成的试验方法学 智能化和自动化握手机制 一次、二次规划隔离; 但是，智能车架构1.0也存在问题，……;“猛狮4号”智能车传感器等硬件物理连接图;以太网;发送者; 人机交互和在线调试占用了智能驾驶实时信息处理的计算资源和带宽，又没有规定基于组播技术的虚拟交换中交换的优先级，当通信量增大时出现阻塞和丢包现象，重要小包的丢失会造成车辆失控的严重后果！;二、架构设计原则和设计约束;;系统原则; 研发驾驶脑，如果架构师一开始就讨论传感器的高性能、高并发、大流量、大数据以及跨媒体的关联计算，一开始就讨论高智商，只能说明他还不懂得忽略和聚焦，不懂得抽象和分离。 ; 架构师应该在智能车的性能、可靠性和成本等诸多制约因素中，确保架构设计的普适性，当某一传感器或者某一软件性能提高后，仍然能够保证架构的扩展和可持续发展 ，以及量产后的低成本实现。 对架构师而言，传感器的多少、驾驶智商的高低不应该影响架构；换一个新型传感器或者软件模块新版本，如同汽车换一个车灯；换一个车辆平台，甚至换一种驾驶风格，都不会影响架构。 ;不做什么？为???么不做？;先觉后视;做好做强什么？;明确任务目标;分层与模块化是智能车软件工程的重要思想，切分要尽最大可能减少耦合，不从模块中导出函数 核心是工作总线和调试总线的切分，以及调试总线和自学习总线的复用 确立“没有哪个软件模块不会被再修改”的原则 ;表现原则; 软件工程随着遗产代码的积累和进化，新系统的架构设计已经取代传统编码成为软件工程的核心问题，软件开发已经演变为配置为主、编程为辅，驾驶脑研发也不例外。; 尽管架构中模块配置的过程本身还是通过模块化编程的方式来完成，但本质上这些模块只是在定制成熟算法的运作方式，其技术难度要比编写平台自带的、或者可以移植过来的高质量的成熟算法至少低一个数量级。悲催的是，多数人在认真地做着相反的事。;快乐编程原则; 体现人类认知的驾驶脑的架构设计，是智能车项目的精髓。只要架构适用，传感器缺陷也好，软件脏代码也好，算法创新也好，车辆平台的动力学性质也好，都是局部性的、暂时性的！; 智能车传感器的添加可以从少到多、从低级到高级，例如从单目相机到深度相机，甚至到雷达相机。但是，体现人类认知的驾驶脑架构仍然不变。只要架构合适了，智商提高的关键，转向特定传感器或特定模块内部的优化，架构师依然很轻松很潇洒。;需求再分析;智能驾驶等级区分;驾驶脑数据流程图 软件模块在双总线中的连接关系图