阿波罗(百度阿波罗平台)详细资料大全
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了阿波罗(百度阿波罗平台)详细资料大全相关的知识,希望对你有一定的参考价值。
参考技术A
阿波罗是百度发布的名为“Apollo(阿波罗)”的向汽车行业及自动驾驶领域的合作伙伴提供的软体平台。发布时间是2017年4月19日,旨在向汽车行业及自动驾驶领域的合作伙伴提供一个开放、完整、安全的软体平台,帮助他们结合车辆和硬体系统,快速搭建一套属于自己的完整的自动驾驶系统。而将这个计画命名为“Apollo”计画,就是借用了阿波罗登月计画的含义。
2018年2月15日,Apollo无人车亮相2018年中央电视台春节联欢晚会广东珠海分会场。在春晚直播中,百余辆Apollo无人车跨越港珠澳大桥。4月19日,百度Apollo开放平台正式发布Apollo2.5版本。11月7日,Apollo自动驾驶开放平台发布。2019年1月,百度在拉斯维加斯举行的2019CES(消费电子展)上宣布,全球首个最全面智慧型驾驶商业化解决方案Apollo Enterprise正式问世。
基本介绍
中文名 :阿波罗 外文名 :Apollo 所属公司 :百度 涉及领域 :汽车行业及自动驾驶领域 属性 :软体平台 成立时间 :2017年4月19日
发布背景,平台介绍,平台体系,生态系统,技术合作,核心支柱,研发历程,战略意义, 发布背景
2017年4月19日,百度又一次展示了自动驾驶领域领导者的大气风范,发布了一项名为“Apollo(阿波罗)”的新计画,向汽车行业及自动驾驶领域的合作伙伴提供一个开放、完整、安全的软体平台,帮助他们结合车辆和硬体系统,快速搭建一套属于自己的完整的自动驾驶系统。 百度开放此项计画旨在建立一个以合作为中心的生态体系,发挥百度在人工智慧领域的技术优势,促进自动驾驶技术的发展和普及。 而将这个计画命名为“Apollo”计画,就是借用了阿波罗登月计画的含义。 平台介绍
平台体系
百度此次开放的阿波罗平台是一套完整的软硬体和服务系统,包括车辆平台、硬体平台、软体平台、云端数据服务等四大部分。 百度还将开放环境感知、路径规划、车辆控制、车载作业系统等功能的代码或能力,并且提供完整的开发测试工具。同时会在车辆和感测器等领域选择协同度和兼容性最好的合作伙伴,推荐给接入阿波罗平台的第三方合作伙伴使用,进一步降低无人车的研发门槛。百度集团总裁兼营运长陆奇对此也表示,百度把自己所拥有的最强、最成熟、最安全的自动驾驶技术开放给业界,旨在建立一个以合作为中心的生态体系,发挥百度在人工智慧领域的技术优势,为合作伙伴赋能,共同促进自动驾驶技术的发展和普及。 生态系统
未来百度将用百度核心AI技术,建立一个强大的、公开的、高速创新的新生态系统。Apollo计画有两种形式开放自动驾驶能力:一种是开放代码,一种是开放能力。 百度集团总裁兼营运长陆奇表示:“开放能力是基于通过API或者是SDK可以通过标准公开方式来获取百度提供的能力,开放代码跟一般传统开放开源软体一样,代码公开,大家可以运用可以参与一起开发。我们的开放范围包括,感知体系、路径规划、车辆控制体系等等重要的组成部分。” 根据规划,百度将通过人工智慧技术打造出一个平台,这不仅是一个系统软体平台,它还包括用软体来支撑现有的、将来的汽车硬体平台,现有的、将来的感测器和车载的作业系统,和核心服务。 技术合作
目前百度与众多车企建立了合作关系,包括奇瑞,比亚迪还有北汽,而对陆奇介绍,Apollo计画的目的就是“把合作厂商的创新速度和质量往上提高、往前推进。” 借用阿波罗登月计画来命名搭建自动驾驶平台,可以看出百度所希望的突破与创新,在自动驾驶时代到来的前期搭好平台,做好布局。 陆奇认为:“现在跟我们合作的伙伴,我们的代码,我们的核心能力他们都看不见,对他们来讲是黑盒子。Apollo计画之后,我们的能力和代码合作伙伴都能看见,可以帮我们的合作伙伴,非常方便、快速建立他们自己的自动驾驶能力。” 2018年3月5日,景驰科技宣布正式加入百度Apollo开放平台,成为Apollo合作伙伴。 核心支柱
Apollo计画的核心是人工智慧技术,这也是该平台搭建的核心支柱,如果百度兼容了高精度地图的领先者与人工智慧技术的平台提供者这两种属性,势必会在无人驾驶时代到来前占据先机,但这样的期盼是否能够达成也同样需要时间来检验。 研发历程
从2015年开始,百度大规模投入无人车技术研发,2015年12月即在北京进行了高速公路和城市道路的全自动驾驶测试。 2016年9月获得美国加州自动驾驶路测牌照,11月在浙江乌镇开展普通开放道路的无人车试运营。 2017年7月,将率先开放封闭场地的自动驾驶能力,年底输出在城市简单路况下的自动驾驶能力,在2020年前逐步开放至高速公路和普通城市道路上的全自动驾驶。 2018年1月8日下午,在拉斯维加斯举办的BAIDU WORLD发布会上,百度正式推出了旗下第二代自动驾驶平台Apollo 2.0。Apollo 2.0具备最开放、最完整、最安全的自动驾驶能力。 2018年1月9日,2018年美国拉斯维加斯消费电子展(CES)正式开幕,百度在开幕前的媒体日活动上发布了新版自动驾驶开放软体平台“阿波罗2.0”。 2018年2月15日,Apollo无人车亮相2018年中央电视台春节联欢晚会广东珠海分会场。在春晚直播中,百余辆Apollo无人车跨越港珠澳大桥。 2018年4月19日,百度Apollo开放平台正式发布Apollo2.5版本。Apollo2.5支持限定区域视觉高速自动驾驶,“解锁”高速公路场景。提到高速公路,发布会现场演示了长沙智慧型驾驶研究院有限公司利用Apollo2.5,快速实现高速公路场景下重型卡车自动驾驶的案例。百度方面表示,这意味着Apollo新增卡车物流套用场景,再度扩宽了其商业化想像空间。 2018年7月4日,在Baidu Create 2018百度AI开发者大会上,百度发布Apollo3.0。 Apollo已经开放了超过22万行代码,超过1万名开发者推荐使用Apollo的开放代码,生态合作伙伴规模达到116家。面向量产,Apollo发布了自主泊车(Valet Parking)、无人作业小车(MicroCar)、自动接驳巴士(MiniBus)三套自动驾驶解决方案,帮助开发者及合作伙伴三个月内即可打造出属于自己的“阿波龙”。基于Apollo自主泊车解决方案,百度已联合盼达用车实现了中国首次自动驾驶共享汽车示范运营,并联合现代汽车展开定点接驳的落地套用。 此外,无人作业小车新石器AX1也已实现量产,在雄安、常州两地实地运营。自动接驳巴士“阿波龙”在四个城市、五大场景启动常态化运营,并获得国家客车质检中心重庆测试场安全认证。Apollo3.0还带来了更加智慧型的量产车联网系统解决方案——小度车载OS,并首次发布了车载语义开放平台。 安全决定自动驾驶量产的真正速度。当天,百度Apollo发布了中国首个自动驾驶量产相关的安全报告,并与国际一流自动驾驶公司Mobileye合作,融合了其核心的自动驾驶安全模型RSS。该报告是中国首个针对自动驾驶量产的、细分场景与功能的、专业的安全报告,对于推动自动驾驶安全行业统一标准的建立提供了理论支持。 Apollo还带来了更多样化的智慧型仿真,推出业内首创真实环境AR仿真,能提供虚拟交通流结合实景渲染的全栈式闭环仿真解决方案,帮助开发者实现“日行百万公里”的仿真测试。 2018年7月10日,百度(NASDAQ:BIDU)与宝马集团宣布双方签署了一份谅解备忘录,根据这份谅解备忘录的内容,宝马集团将作为理事会成员加入阿波罗(Apollo)开放平台。这标志著宝马集团和百度在自动驾驶领域将开启又一段全新的合作伙伴关系。双方将一起致力于为中国消费者带来安全、便捷和智慧型的出行体验。 2018年11月7日,在第五届世界网际网路大会世界网际网路领先科技成果发布活动上,张亚勤现场发布Apollo自动驾驶开放平台。 2018年12月28日,湖南湘江新区智慧型公交示范线首发仪式暨湖南湘江人工智慧学院授牌仪式,在国家智慧型网联汽车(长沙)测试区举行。活动期间,百度Apollo自动驾驶全场景车型亮相活动现场测试区,并完成全国首例L3及L4级别等多车型高速场景自动驾驶车路协同演示。同时由百度Apollo提供技术支持的国内首条智慧型公交示范线也首发通车。此外,湖南湘江人工智慧学院百度Apollo实训基地也正式揭牌。 2019年1月,百度在拉斯维加斯举行的2019CES(消费电子展)上宣布,全球首个最全面智慧型驾驶商业化解决方案Apollo Enterprise正式问世。百度Apollo3.5发布,可支持复杂城市道路自动驾驶,并发布了全球首个面向自动驾驶的高性能开源计算框架Apollo Cyber RT。 百度还表示,总部位于加利福尼亚的无人驾驶汽车制造商Udelv将在2019年使用Apollo 3.5软体试用多达100辆试运货车。据悉,搭载Apollo3.5的福特城市厢式货运车Transit自动送货服务Udelv,将于2019年在矽谷开始运营。Apollo3.5的升级将实现从简单城市道路到复杂城市道路的自动驾驶,面对窄车道、减速带、人行道、十字路口、无信号灯路口通行、借道错车行驶等多达十几种路况。 2019年,100辆自动驾驶计程车将在湖南长沙130英里的城市道路上行驶,配备百度的V2X技术。这支车队将成为中国第一批自主驾驶计程车,由百度的V2X系统管理。 战略意义
这意味着百度在人工智慧的系统级开放进程中又迈出了坚实的一步,也是全球范围内自动驾驶技术的第一次系统级开放。
京东多端全流程交易解决方案阿波罗平台iOS单元测试实践
“我非常确信,在我有生之年,对软件发展的最大贡献不是来自面向对象方法和高级语言、函数式编程、强类型、MVC 或其他任何东西,而是来自测试文化的兴起。”单元测试,是针对一小段代码或方法,检验被测代码一个小的、明确的功能是否正确 ,证明某段代码的行为和开发者期望一致的行为。简单来说,是针对单个程序、函数、过程进行正确性检验的工作的白盒测试。独立(Independent)测试应该相互独立,不能有依赖。可重复(Repeatable)测试应当可在任何环境重复通过。包括无网络的环境。自足验证(Self-Validating)测试应该有布尔值输出。及时(Timely)测试应及时编写。单元测试应该恰好在使其通过的代码之前编写。一个成熟的软件开发人员非常清楚测试的重要性。当我们需要开发一个新功能、新需求时,我们通过单元测试来验证一段代码中是否运行的正常,传入极端边界值是否会出现问题,单元测试还能使第一次阅读代码的开发人员更好的理解这段代码的含义。经过良好的的单元测试过的代码总会给开发人员带来勇气。当我们需要重新修改需求、甚至重构代码时,因为有了良好的单元测试,即使你搞砸了,你也会很快通过运行不通过的单元测试发现问题。所以单元测试,前端和后端都很重要,现在和以后都很重要。开发成本增加。TDD原则要求我们在开发代码前先编写单元测试,按照这条规则,我们编写的单元测试将覆盖所有业务代码。测试的代码量足以匹敌需求代码量,编写单元测试所需要花费的时间将和开发需求的时间相同甚至远超开发时间,这无疑增加了开发人员的开发成本。无法验证单元测试的有效性。基于控制唯一变量的原则,如果要验证单元测试的有效性,我们需要找到两个强大的团队来执行重要的开发任务,并且在规模、结构、工具、技能水平和工作实践——在除测试之外的所有方面的表现都大致相同。然后,还需要在一个比较长的周期内研究他们的生产力和质量差异。无疑还没有团队能够这样去做,所以我们无法使用有效的数据来说明单元测试的有效性,只能凭借以往开发者的经验积累来进行单元测试。在阿波罗早期调研时,公司内部还没有太多的方案可供选择。所以我们主要是使用手动导入XCodeCoverage和OCMock库再接入Bamboo的方案。现在iBiu最新版本已经支持了单元测试,内部也是使用XCodeCoverage库来生成覆盖率。那么就先针对这两个平台对现有的单测支持能力做一个对比:1. 如果你现在已经接入了iBiu,但是现在不是太着急生成视图的单测覆盖率报告,可以先使用Xcode的自带单测覆盖率查看,等iBiu与Bamboo数据打通后直接通过iBiu接入。(两个团队已经在紧急建设中)2. 如果部门需要统一在Bamboo中统计单侧覆盖率,那么可以直接使用手动接入Bamboo方式,除了第一次配置略麻烦,后面直接在Bamboo定时运行还是很方便。3. 如果你的工程没有接入iBiu,或者还不想接入Bamboo,但是想要生成更加详细的单测覆盖率,可以只接入XCodeCoverage和OCMock,生成本地单测详细报告。iBiu接入和Bamboo中生成单测覆盖率报告都是使用XCodeCoverage,下文会详细介绍这个库的使用方法。无论在iBiu、还是Bamboo,我们关注的有效数据都是单元测试覆盖率。
无论是哪种方式接入,单测覆盖率最终的数据来源都是通过Xcode生成。2. 开启覆盖率需要覆盖的范围,选择你需要测试target,一般是我们的组件源码所在的target;4. 写好单测代码,运行command+U后,就可以看到生成的单测覆盖率5. 点开详细内容,可看到具体哪些代码被覆盖,其中红色代表没有被覆盖,绿色代码已经被覆盖。当每一次运行单测后,都应该快速的点开浏览所有重要的代码块,查看被覆盖和没被覆盖的部分。往往有些你觉得单元测试已经被覆盖到的部分,其实并没有覆盖到。一般来说,单测覆盖率不会达到100%。阿波罗前端本次接入单测只考虑业务逻辑的代码部分,UI单测并不在本次的规划当中,所以我们的单测覆盖率对比服务端相对会更低一些。XcodeCoverage提供了一种简单的方法来生成Xcode项目的Objective-C代码覆盖率报告。生成的报告包括HTML和XML。覆盖数据不会包括苹果sdk,并且XcodeCoverage现在还不支持Swift。如果工程是使用iBiu,那么在Podfile文件平级的文件夹中,新增一个Podfile.custom文件,然后使用iBiu进行安装。如果工程没有使用iBiu,那就使用CocoaPods正常安装,在Podfile文件中增加pod \'XcodeCoverage\',然后pod install。xcpretty用于对xcodebuild的输出进行格式化。并包含输出report功能。
ocunit2junit用来将 OCUnit 的输出转换成 JUnit 风格的报告在你的主工程中加一个Run Script,运行一个脚本文件$PODS_ROOT/XcodeCoverage/exportenv.sh
打开一下要运行的脚本,文件就在Pod/XcodeCoverage/下主要作用是新生成了一个env.sh文件,并写入了BUILT_PRODUCTS_DIR、CURRENT_ARCHOBJECT_FILE_DIR_normal、OBJROOT、OBJROOT等参数。然后我们先command+b或者command+u一下,运行这个脚本去生成env.sh。OBJECT_FILE_DIR_normal,这个值默认生成的是我们主工程的地址,但是现在我们要测试的是包含业务代码的target,所以这个值需要修改为目标target的地址。我们真正的代码其实在工程中是相当于一个pod,所以这个值需要改成Pod所在的位置/Users/xxxx /Library/Developer/Xcode/DerivedData/xxxCartModule-gtprkfazpqerpsczqxftrlwkzauw/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/xxxCartModule.build/Objects-normal。SRCROOT,可以看到默认生成的值是指向Example文件夹的,也就是我们一般写调用、验证组件的等的测试代码的地方,而我们实际的需要被单测的代码都在classes文件中,所以这个值需要改成:/xxxCartModule/xxxCartModule/Classes。
需要注意,因为env.sh是由于run exportenv脚本每次动态生成,就会导致每次build或者跑单测都会生成一次,都需要改一次上述的两个值。如果觉得比较麻烦可以写一个脚本进行修改。修改完成后我们cd到Pods/XcodeCoverage文件夹,执行getcov脚本。/getcov -s,运行后,浏览器会自动打开生成的单测覆盖率详细报告。生成的报告包含总代码行、已覆盖的代码行、代码覆盖率、总方法数、已覆盖的方法数、方法覆盖率,可以点击每一个类查看覆盖的代码和没有覆盖的代码。如果想要将单测报告生成到指定文件夹,可以执行Xcode编译后会为每个可执行文件生成对应的 .gcno 文件;之后在代码中调用覆盖率分发函数,会生成对应的 .gcda 文件。其中,.gcno 包含了代码计数器和源码的映射关系, .gcda 记录了每段代码具体的执行次数。覆盖率解析工具都需要结合这两个文件给出最后的检测报表。这就是为什么我们需要修改env.sh中的文件路径,因为需要让XcodeCoverage去扫描正确的gcda 文件。刚刚在终端运行生成单测覆盖率时的输出记录可以验证以上内容。在生成覆盖率报告的日志中,我们还会发现有类似这样的输出:像我的工程输出这个报错是因为在代码中使用了外部类的一个方法。
一般我们工程中会引用到许多JD内部库,除了上面的运行错误日志外,还会导致无法生成最后的单测报告文件:解决办法是:需要让XcodeCoverage在扫描文件的时候忽略掉JD库,在Classes下新增一个.xcodecoverageignore文件,文件内容中写要忽略的库就可以了。$SRCROOT/报错的库 /*
`--show` or `-s`: Show HTML report. `--xml` or `-x`: Generate Cobertura XML. 生成覆盖率XML`-o output_dir`: Specify output directory. 将结果输出到一个文件夹`-i info_file`: Specify name of generated lcov info file. 指定生成的lcov信息文件的名称 `-v`: Enable verbose output.`-h` or `--help`: Show usage.当通过以上步骤本地工程可以正常生成覆盖率报告文件时,接入Bamboo就变得非常容易。开发测试代码和开发需求代码一样重要。测试必须跟随业务代码的修改而修改,它不是一次性的产物,也需要开发人员进行维护。下面表格列举出一个工程中主要部分和是否需要单元测试,供大家参考:写单元测试应该在代码开发之前,且应该自下向上进行,从最基础的开始写。Given:配置测试的初始状态,比如造一些数据、mock一些对象等,这里我们可能需要OCMock这个库的辅助。When:对要测试的目标执行代码,调用你要测试的方法Then:对测试结果进行断言(成功 or 失败),对于结果做一个预判,并且通过编译来判断你的预判是否正确。一个单测类只测一个代码类。一个单测类中只测试这个类的相关方法,不要把所有的单测方法都写在一个测试类中。这样看上去拥挤不堪,既不美观又不好维护。并且注意命名规则,可以是被测试的类名+Test。一个单测方法只测一个方法的一种情况。我们不要想写一个超长的测试方法,在同一个方法里测试完这个又测试那个,就像下面这种,需要拆分成两个单测方法。当然一个方法中可以针对一种情况写多条断言。如果你需要测试定义在.m中的一个方法或者一个属性。可以在单测的target中,创建一个Category,将私有的方法和属性开放到.h中。并且可以将Category的.m文件删除,它并没有什么用。举个例子,业务代码如下,单元测试需要验证是否走到了if里:
方式2:你当然可以不关心假数据是什么,只关注这个方法中的逻辑。那就使用OCMock直接存根一份对象。具体选择哪种方式可以根据被测试的方法自行判断:如果入参是一个对象,那么选择OCMock;如果入参是一个基础数据,造假数据比较麻烦可以选择OCMock,假数据结构不麻烦的话可以直接mock假数据。需要特别关注断言失败的单测,这可能证明你对你的代码有某些误判。苹果提供了断言XCTAssert等方法,具体如下:从以上表格中可以看到苹果提供的基本是对变量的判断。当我们需要校验的是最后是否跳转到另一个方法时,就需要使用OCMock的OCMVerify方法。OCMock实际是利用runtime原理,通过消息转发方式来实现的。感兴趣的同学可打开源代码看一看。1. OCMock生成的对象是id类型,在使用mock对象的时候,调用属性名和方法名都不会自动带出,所以调用的方法名需要自己写出来。3. 在使用断言方法判断一个方法时,如果方法有入参,可以使用[OCMArg any]当做入参,该方法可以返回一个id类型的参数,这样无需纠结入参的值,需要注意int、float等类型不可以使用。如果在断言方法时代码明明走到了单测依旧报错,可以校验下方法中的传参是否相同。4. 使用OCMock时,最好在每次使用完后手动调用stopMocking,养成用完即释放的好习惯以上就是OCMock经常使用的方法,建议在使用时看看官方文档《OCMock》关于OCMock的实际用法还可以参考《OCMockTests》。阿波罗平台致力于提供多端、全流程的交易解决方案,帮助用户快速搭建交易类的APP和小程序,并且具备一定的组件配置和共建能力,满足业务需求。
内部员工详细资料请在神灯查阅。
以上是关于阿波罗(百度阿波罗平台)详细资料大全的主要内容,如果未能解决你的问题,请参考以下文章
百度“阿波罗计划”开放自动驾驶平台,F8大会开源Caffe2深度学习框架 | 一周AI关注
小虞汽车百度自动驾驶车在唐廊高速测试 搭Aopllo平台
国内首次深度学习自动驾驶,阿波罗不再只是计划:来自百度开发者中心的观察报告
阿波罗读取乐观响应的片段
Apollo github - 百度阿波罗
天神宙斯和太阳神阿波罗是啥关系?