1. 从一次误操作说起为什么Portal界面值得单独拿出来讲我第一次接触Apollo的Portal界面是在一个自动驾驶仿真项目里。当时团队里有个刚入行的同学在Portal上点了几下把一台测试车的配置参数改了结果第二天路测时车辆行为异常排查了大半天才发现是配置被覆盖了。这件事让我意识到Portal界面虽然看起来只是一个“网页后台”但它背后连接的是整个自动驾驶系统的配置、车辆管理、仿真任务和数据分析链路操作不当的代价可能非常直接。Apollo的Portal界面本质上是Apollo开放平台提供的一套可视化管理工具。它把原本需要通过命令行、配置文件、接口调用才能完成的操作收敛到了一个浏览器页面里。你能在里面做车辆管理、传感器标定、地图加载、仿真场景配置、任务下发、数据回放这些事。对于刚接触自动驾驶开发的人来说它降低了上手门槛对于有经验的工程师来说它提升了日常调试和验证的效率。这篇文章适合三类人看第一类是刚进入自动驾驶领域、准备用Apollo做开发或学习的工程师第二类是已经在用Apollo但主要靠命令行操作、想了解Portal能帮自己省哪些事的人第三类是做测试或运维、需要频繁和车辆配置、仿真任务打交道的人。我会从整体设计思路讲到具体操作细节把每个关键步骤背后的逻辑说清楚也会分享一些我在实际使用中踩过的坑和总结出来的技巧。2. Portal界面的整体设计与操作逻辑拆解2.1 Portal到底解决了什么问题在没有Portal之前Apollo的很多操作是分散的。车辆配置可能在一个yaml文件里传感器标定参数在另一个目录下仿真任务需要通过脚本启动地图数据要手动放到指定路径。这种方式对于熟悉系统的人来说没问题但对于团队协作、快速验证、新人上手来说效率很低而且容易出错。Portal的核心价值在于三点集中管理、可视化操作、状态可追踪。集中管理意味着所有和车辆、地图、仿真相关的资源都在一个界面里维护可视化操作意味着你不需要记住每个配置文件的路径和字段含义界面会引导你填写状态可追踪意味着每次任务下发、配置修改都有记录出问题能回溯。我个人的体会是Portal最适合的场景是“频繁调整配置并快速验证”的阶段。比如你在调试感知模块的参数需要反复修改配置文件然后跑仿真用Portal会比手动改文件再启动任务快很多。但如果是一次性的、批量化的操作命令行反而更高效。所以理解Portal的定位比单纯学会点按钮更重要。2.2 界面布局与功能分区Apollo Portal的界面布局遵循了典型的后台管理系统的设计思路左侧是导航菜单右侧是内容区域。导航菜单里通常包含这几个核心模块车辆管理查看已注册车辆列表编辑车辆基本信息管理车辆与硬件配置的绑定关系。传感器标定上传或查看摄像头、激光雷达、毫米波雷达等传感器的标定参数。地图管理查看已加载的高精地图管理地图版本查看地图覆盖区域。仿真管理创建仿真场景配置仿真任务查看仿真结果。数据管理查看车辆运行数据、传感器数据、任务日志等。系统设置用户权限、系统参数、版本信息等。这个布局的逻辑是“按资源类型划分”而不是“按操作流程划分”。也就是说你要完成一个完整的任务可能需要在多个模块之间切换。比如你要跑一个仿真任务需要先在车辆管理里确认车辆配置再在地图管理里确认地图版本最后在仿真管理里创建任务。这种设计的好处是每个模块的职责清晰坏处是新手容易迷失不知道下一步该去哪。我的建议是刚开始用的时候先花十分钟把每个菜单点一遍不用深入操作就看看每个页面大概有什么内容。这样你脑子里会有一张地图后面遇到具体任务时知道该去哪个模块找。2.3 操作流程的底层逻辑Portal上的每一个操作背后都对应着Apollo系统里的一次配置变更或任务下发。理解这一点很关键因为它决定了你操作时应该关注什么。举个例子当你在Portal上修改一辆车的传感器标定参数时系统实际上是在做这几件事第一校验你填写的参数格式是否正确第二把参数写入到对应的配置存储中第三通知相关模块重新加载配置。如果你填的参数格式不对Portal会在前端就拦截下来不会让你提交。但如果你填的参数在格式上没问题、在物理意义上不合理Portal可能不会报错但车辆实际运行时就会出问题。所以我在操作Portal时会养成一个习惯每次修改配置后不只看Portal上显示“保存成功”还会去对应的日志或状态页面确认配置是否真的生效了。这个习惯帮我避免了好几次“以为改好了其实没生效”的情况。3. 核心模块的实操要点与细节解析3.1 车辆管理从注册到配置绑定车辆管理是Portal里最基础也最常用的模块。一辆车要在Apollo系统里跑起来需要先在这里完成注册和配置。注册车辆时需要填写车辆名称、车辆ID、车辆类型这些基本信息。车辆ID是系统里的唯一标识建议用有意义的命名规则比如“test_vehicle_01”这种不要用随机字符串。因为后面在仿真任务、数据记录里都会用到这个ID命名清晰能省很多事。车辆注册完成后需要绑定硬件配置。Apollo支持多种硬件组合比如不同型号的激光雷达、摄像头、组合导航等。在Portal上绑定硬件配置时需要注意两点第一选择的硬件型号必须和实际车辆上安装的一致否则标定参数会不匹配第二硬件配置的绑定关系一旦确定不要随意更改因为标定参数是和硬件配置绑定的改了硬件配置标定参数可能需要重新做。我踩过的一个坑是有一次为了测试方便把一辆车的硬件配置改成了另一种型号想着测试完再改回来。结果测试过程中产生了一批数据后来分析时发现这批数据的标定参数和实际硬件不匹配数据没法用。所以我的建议是如果只是临时测试最好新建一辆虚拟车辆不要动真实车辆的配置。3.2 传感器标定参数上传与校验传感器标定是自动驾驶里非常关键的一环标定参数的准确性直接影响感知模块的效果。Portal提供了标定参数的上传和查看功能。上传标定参数时Portal通常会要求你选择传感器类型、填写标定文件路径或直接上传文件。这里有几个细节需要注意第一标定文件的格式必须符合Apollo的要求。不同传感器类型的标定文件格式不一样比如摄像头的内参和外参、激光雷达的外参、毫米波雷达的外参都有各自的模板。建议先从Apollo的官方文档里下载对应的模板文件在模板基础上修改不要自己从头写。第二标定参数上传后Portal会做一个基本的格式校验但不会做物理合理性校验。也就是说如果你填了一个明显不合理的参数比如摄像头的焦距填成了负数Portal可能不会报错但实际运行时就会出问题。所以上传后最好在仿真环境里跑一下看看感知结果是否正常。第三标定参数是有版本管理的。如果你更新了标定参数旧版本会被保留但新任务会使用新版本。这个机制的好处是你可以随时回滚坏处是如果你忘了自己更新过可能会困惑为什么结果和之前不一样。我的做法是每次更新标定参数时在备注里写清楚更新原因和日期方便后面追溯。3.3 地图管理版本选择与加载确认高精地图是自动驾驶的基础数据之一。Portal的地图管理模块可以查看已加载的地图、管理地图版本、查看地图覆盖区域。在实际操作中最常见的问题是地图版本和车辆实际运行区域不匹配。比如你在Portal上加载的是A区域的地图但车辆实际在B区域测试那车辆就无法正常定位。所以在每次测试前确认地图版本和测试区域是否一致是一个必须做的检查项。另外地图加载是一个耗时操作尤其是大范围的高精地图。在Portal上点击加载后不要频繁刷新页面或重复点击等待系统提示加载完成即可。我有一次因为着急连续点了三次加载结果系统里出现了三个重复的地图加载任务虽然最后没出大问题但浪费了不少时间。3.4 仿真管理场景配置与任务下发仿真管理是Portal里功能最丰富的模块之一。你可以在这里创建仿真场景、配置仿真任务、查看仿真结果。创建仿真场景时需要选择场景类型比如跟车、变道、避障等、设置场景参数比如车速、距离、天气条件等、选择参与仿真的车辆和地图。这里的关键是场景参数要合理。比如你设置了一个前车距离只有0.5米的跟车场景那仿真结果大概率是追尾但这不代表你的算法有问题而是场景本身就不合理。配置仿真任务时需要选择仿真模式比如单机仿真、分布式仿真、设置仿真时长、选择要运行的模块。这里有一个经验刚开始调试时仿真时长不要设太长先跑短时间的仿真确认基本流程没问题再跑长时间的。因为仿真任务一旦下发中途停止比较麻烦而且会浪费计算资源。查看仿真结果时Portal会展示一些关键指标比如碰撞次数、偏离车道次数、平均车速等。但这些指标只是参考真正要判断算法好坏还需要看详细的日志和回放数据。我通常会先把仿真结果里的异常片段找出来逐个分析而不是只看汇总指标。4. 完整实操流程从零开始跑通一个仿真任务4.1 前置准备确认环境和资源在开始操作之前需要确认几件事Apollo系统已经正常启动Portal服务可以访问车辆已经注册并绑定了正确的硬件配置所需的地图已经加载完成标定参数已经上传并校验通过。这些准备工作看起来琐碎但缺了任何一项后面的仿真任务都可能失败。我习惯在开始前做一个检查清单逐项确认。这个清单包括Portal登录是否正常、车辆列表里是否有目标车辆、车辆配置是否和实际一致、地图列表里是否有目标区域的地图、标定参数是否是最新版本。4.2 创建仿真场景的具体步骤第一步进入仿真管理模块点击“创建场景”。第二步选择场景类型。如果是测试跟车算法就选跟车场景如果是测试变道算法就选变道场景。第三步设置场景参数。以跟车场景为例需要设置主车初始车速、前车初始车速、初始距离、前车减速曲线等。这些参数要根据你的测试目的来定不要随便填。第四步选择参与仿真的车辆和地图。车辆要选已经注册并配置好的地图要选覆盖测试区域的。第五步保存场景。保存后场景会出现在场景列表里可以随时编辑或删除。这里有一个细节场景名称建议包含关键参数信息比如“跟车_主车60_前车40_距离20”这样后面在列表里找的时候一眼就能看出来是什么场景不用逐个点开看。4.3 下发仿真任务与监控状态场景创建好后就可以下发仿真任务了。在仿真管理模块里选择“创建任务”然后选择刚才创建的场景设置仿真时长和仿真模式点击“下发”。任务下发后Portal会显示任务状态通常是“排队中”、“运行中”、“已完成”、“失败”这几种。在任务运行过程中可以点击任务查看实时状态包括当前仿真时间、已运行的模块、是否有异常报错等。如果任务失败Portal会显示失败原因。常见的失败原因包括场景参数不合理导致仿真无法启动、车辆配置和场景不匹配、地图未加载、计算资源不足等。根据失败原因逐个排查通常都能解决。4.4 查看仿真结果与数据回放任务完成后可以在仿真管理模块里查看结果。Portal会展示一个结果概览页面包括关键指标和异常事件列表。点击异常事件可以跳转到对应的数据回放页面查看当时的车辆状态、传感器数据、模块输出等。数据回放是分析问题的关键工具。我通常会先看异常事件发生前后的几秒钟数据重点关注感知模块的输出是否正常、规划模块的决策是否合理、控制模块的执行是否到位。如果发现问题再往前追溯看是哪个环节出了偏差。5. 常见问题与排查技巧实录5.1 Portal页面操作无响应或报错这是最常见的问题之一。可能的原因有几种浏览器兼容性问题、Portal服务异常、网络连接不稳定、权限不足。排查顺序建议是先换一个浏览器试试推荐用Chrome或Edge的最新版本如果换浏览器没用检查Portal服务是否正常运行可以尝试重启服务如果服务正常检查网络连接确认能正常访问Portal所在的服务器如果网络也没问题检查当前账号是否有操作权限有些操作需要特定角色才能执行。我遇到过一次Portal页面卡住的情况最后发现是浏览器缓存的问题清理缓存后恢复正常。所以如果遇到莫名其妙的问题清理缓存、强制刷新CtrlShiftR是一个值得先试的操作。5.2 仿真任务下发后一直排队任务一直排队通常是因为计算资源不足。Apollo的仿真任务需要消耗计算资源如果同时下发的任务太多或者已有任务占用了大量资源新任务就会排队。解决办法有两个一是等待已有任务完成后再下发新任务二是检查仿真集群的资源使用情况如果确实资源不足可以考虑增加计算节点或优化现有任务的资源占用。另外有些仿真模式比如分布式仿真对资源的要求更高如果资源有限可以先用单机仿真模式跑通流程再考虑分布式仿真。5.3 仿真结果与预期不符仿真结果和预期不符可能的原因很多需要逐项排查。我通常会按这个顺序检查第一场景参数是否合理。比如跟车场景里前车减速曲线设置得太激进导致主车根本来不及反应那结果肯定是追尾。这种情况下问题不在算法而在场景设计。第二车辆配置是否正确。如果车辆的传感器标定参数不对感知模块的输出就会有问题进而影响规划和控制。检查标定参数是否是最新版本、是否和实际硬件匹配。第三算法模块的版本是否正确。如果最近更新过某个模块的代码但仿真任务用的还是旧版本结果就会和预期不符。确认仿真任务使用的模块版本和当前代码版本一致。第四仿真环境是否和实际环境有差异。仿真里的传感器模型、车辆动力学模型都是简化的和实际环境有差异是正常的。如果仿真结果和实际测试结果差异很大可能需要调整仿真模型参数使其更接近实际。5.4 数据回放时找不到对应数据数据回放时找不到对应数据通常是因为数据存储路径配置不对或者数据已经被清理。Apollo的数据通常会保存一段时间超过保留期的数据会被自动清理。如果需要长期保存某些数据需要在数据管理模块里设置保留策略或者手动导出数据。另外数据回放需要的数据可能分散在不同的存储位置比如车辆运行数据、传感器数据、模块日志等。如果某个位置的数据缺失回放就会不完整。检查数据存储配置确认所有需要的数据都正常保存。5.5 常见问题速查表问题现象可能原因排查方法解决措施Portal页面无响应浏览器兼容性、缓存问题换浏览器、清缓存使用Chrome最新版强制刷新操作报权限错误账号角色权限不足检查账号角色联系管理员分配权限仿真任务一直排队计算资源不足查看集群资源使用等待或增加计算节点仿真结果异常场景参数、标定参数、模块版本逐项检查修正参数或更新版本数据回放缺失数据被清理、存储配置错误检查数据保留策略调整保留策略或导出数据地图加载失败地图文件损坏、版本不匹配检查地图文件完整性重新上传或更换地图版本6. 我在实际操作中总结的几个关键习惯用了这么久Portal我慢慢养成了一些习惯这些习惯帮我省了不少时间也避免了很多低级错误。第一个习惯是操作前先确认状态。不管是改配置还是下发任务先看一眼当前的状态是什么。比如改车辆配置前先确认这辆车当前没有正在运行的任务下发仿真任务前先确认地图和标定参数都是最新的。这个习惯看起来简单但能避免很多“改了配置导致正在跑的任务失败”的情况。第二个习惯是每次修改都留记录。Portal本身有操作日志但那个日志比较简略。我会在修改配置时在备注里写清楚改了什么、为什么改、什么时候改的。这样后面如果出问题回溯起来很快。第三个习惯是先用小规模验证再大规模执行。比如跑仿真先跑一个短时间的、简单的场景确认流程没问题再跑长时间的、复杂的场景。这样即使出问题排查成本也低。第四个习惯是定期清理不需要的资源。Portal里积累的仿真任务、场景、数据会越来越多定期清理不需要的能让界面更清爽也能减少误操作的概率。最后再分享一个小技巧Portal的很多页面支持URL直接跳转如果你经常需要访问某个特定页面可以把URL收藏起来下次直接打开省去从首页逐级点击的时间。这个技巧在需要频繁切换页面的调试场景下特别有用。 
长河君 · 2026/10/13 5:34:12 · 阅读 1.2k Apollo Portal界面实战指南：从车辆管理到仿真任务全流程解析
1. 从一次误操作说起为什么Portal界面值得单独拿出来讲我第一次接触Apollo的Portal界面是在一个自动驾驶仿真项目里。当时团队里有个刚入行的同学在Portal上点了几下把一台测试车的配置参数改了结果第二天路测时车辆行为异常排查了大半天才发现是配置被覆盖了。这件事让我意识到Portal界面虽然看起来只是一个“网页后台”但它背后连接的是整个自动驾驶系统的配置、车辆管理、仿真任务和数据分析链路操作不当的代价可能非常直接。Apollo的Portal界面本质上是Apollo开放平台提供的一套可视化管理工具。它把原本需要通过命令行、配置文件、接口调用才能完成的操作收敛到了一个浏览器页面里。你能在里面做车辆管理、传感器标定、地图加载、仿真场景配置、任务下发、数据回放这些事。对于刚接触自动驾驶开发的人来说它降低了上手门槛对于有经验的工程师来说它提升了日常调试和验证的效率。这篇文章适合三类人看第一类是刚进入自动驾驶领域、准备用Apollo做开发或学习的工程师第二类是已经在用Apollo但主要靠命令行操作、想了解Portal能帮自己省哪些事的人第三类是做测试或运维、需要频繁和车辆配置、仿真任务打交道的人。我会从整体设计思路讲到具体操作细节把每个关键步骤背后的逻辑说清楚也会分享一些我在实际使用中踩过的坑和总结出来的技巧。2. Portal界面的整体设计与操作逻辑拆解2.1 Portal到底解决了什么问题在没有Portal之前Apollo的很多操作是分散的。车辆配置可能在一个yaml文件里传感器标定参数在另一个目录下仿真任务需要通过脚本启动地图数据要手动放到指定路径。这种方式对于熟悉系统的人来说没问题但对于团队协作、快速验证、新人上手来说效率很低而且容易出错。Portal的核心价值在于三点集中管理、可视化操作、状态可追踪。集中管理意味着所有和车辆、地图、仿真相关的资源都在一个界面里维护可视化操作意味着你不需要记住每个配置文件的路径和字段含义界面会引导你填写状态可追踪意味着每次任务下发、配置修改都有记录出问题能回溯。我个人的体会是Portal最适合的场景是“频繁调整配置并快速验证”的阶段。比如你在调试感知模块的参数需要反复修改配置文件然后跑仿真用Portal会比手动改文件再启动任务快很多。但如果是一次性的、批量化的操作命令行反而更高效。所以理解Portal的定位比单纯学会点按钮更重要。2.2 界面布局与功能分区Apollo Portal的界面布局遵循了典型的后台管理系统的设计思路左侧是导航菜单右侧是内容区域。导航菜单里通常包含这几个核心模块车辆管理查看已注册车辆列表编辑车辆基本信息管理车辆与硬件配置的绑定关系。传感器标定上传或查看摄像头、激光雷达、毫米波雷达等传感器的标定参数。地图管理查看已加载的高精地图管理地图版本查看地图覆盖区域。仿真管理创建仿真场景配置仿真任务查看仿真结果。数据管理查看车辆运行数据、传感器数据、任务日志等。系统设置用户权限、系统参数、版本信息等。这个布局的逻辑是“按资源类型划分”而不是“按操作流程划分”。也就是说你要完成一个完整的任务可能需要在多个模块之间切换。比如你要跑一个仿真任务需要先在车辆管理里确认车辆配置再在地图管理里确认地图版本最后在仿真管理里创建任务。这种设计的好处是每个模块的职责清晰坏处是新手容易迷失不知道下一步该去哪。我的建议是刚开始用的时候先花十分钟把每个菜单点一遍不用深入操作就看看每个页面大概有什么内容。这样你脑子里会有一张地图后面遇到具体任务时知道该去哪个模块找。2.3 操作流程的底层逻辑Portal上的每一个操作背后都对应着Apollo系统里的一次配置变更或任务下发。理解这一点很关键因为它决定了你操作时应该关注什么。举个例子当你在Portal上修改一辆车的传感器标定参数时系统实际上是在做这几件事第一校验你填写的参数格式是否正确第二把参数写入到对应的配置存储中第三通知相关模块重新加载配置。如果你填的参数格式不对Portal会在前端就拦截下来不会让你提交。但如果你填的参数在格式上没问题、在物理意义上不合理Portal可能不会报错但车辆实际运行时就会出问题。所以我在操作Portal时会养成一个习惯每次修改配置后不只看Portal上显示“保存成功”还会去对应的日志或状态页面确认配置是否真的生效了。这个习惯帮我避免了好几次“以为改好了其实没生效”的情况。3. 核心模块的实操要点与细节解析3.1 车辆管理从注册到配置绑定车辆管理是Portal里最基础也最常用的模块。一辆车要在Apollo系统里跑起来需要先在这里完成注册和配置。注册车辆时需要填写车辆名称、车辆ID、车辆类型这些基本信息。车辆ID是系统里的唯一标识建议用有意义的命名规则比如“test_vehicle_01”这种不要用随机字符串。因为后面在仿真任务、数据记录里都会用到这个ID命名清晰能省很多事。车辆注册完成后需要绑定硬件配置。Apollo支持多种硬件组合比如不同型号的激光雷达、摄像头、组合导航等。在Portal上绑定硬件配置时需要注意两点第一选择的硬件型号必须和实际车辆上安装的一致否则标定参数会不匹配第二硬件配置的绑定关系一旦确定不要随意更改因为标定参数是和硬件配置绑定的改了硬件配置标定参数可能需要重新做。我踩过的一个坑是有一次为了测试方便把一辆车的硬件配置改成了另一种型号想着测试完再改回来。结果测试过程中产生了一批数据后来分析时发现这批数据的标定参数和实际硬件不匹配数据没法用。所以我的建议是如果只是临时测试最好新建一辆虚拟车辆不要动真实车辆的配置。3.2 传感器标定参数上传与校验传感器标定是自动驾驶里非常关键的一环标定参数的准确性直接影响感知模块的效果。Portal提供了标定参数的上传和查看功能。上传标定参数时Portal通常会要求你选择传感器类型、填写标定文件路径或直接上传文件。这里有几个细节需要注意第一标定文件的格式必须符合Apollo的要求。不同传感器类型的标定文件格式不一样比如摄像头的内参和外参、激光雷达的外参、毫米波雷达的外参都有各自的模板。建议先从Apollo的官方文档里下载对应的模板文件在模板基础上修改不要自己从头写。第二标定参数上传后Portal会做一个基本的格式校验但不会做物理合理性校验。也就是说如果你填了一个明显不合理的参数比如摄像头的焦距填成了负数Portal可能不会报错但实际运行时就会出问题。所以上传后最好在仿真环境里跑一下看看感知结果是否正常。第三标定参数是有版本管理的。如果你更新了标定参数旧版本会被保留但新任务会使用新版本。这个机制的好处是你可以随时回滚坏处是如果你忘了自己更新过可能会困惑为什么结果和之前不一样。我的做法是每次更新标定参数时在备注里写清楚更新原因和日期方便后面追溯。3.3 地图管理版本选择与加载确认高精地图是自动驾驶的基础数据之一。Portal的地图管理模块可以查看已加载的地图、管理地图版本、查看地图覆盖区域。在实际操作中最常见的问题是地图版本和车辆实际运行区域不匹配。比如你在Portal上加载的是A区域的地图但车辆实际在B区域测试那车辆就无法正常定位。所以在每次测试前确认地图版本和测试区域是否一致是一个必须做的检查项。另外地图加载是一个耗时操作尤其是大范围的高精地图。在Portal上点击加载后不要频繁刷新页面或重复点击等待系统提示加载完成即可。我有一次因为着急连续点了三次加载结果系统里出现了三个重复的地图加载任务虽然最后没出大问题但浪费了不少时间。3.4 仿真管理场景配置与任务下发仿真管理是Portal里功能最丰富的模块之一。你可以在这里创建仿真场景、配置仿真任务、查看仿真结果。创建仿真场景时需要选择场景类型比如跟车、变道、避障等、设置场景参数比如车速、距离、天气条件等、选择参与仿真的车辆和地图。这里的关键是场景参数要合理。比如你设置了一个前车距离只有0.5米的跟车场景那仿真结果大概率是追尾但这不代表你的算法有问题而是场景本身就不合理。配置仿真任务时需要选择仿真模式比如单机仿真、分布式仿真、设置仿真时长、选择要运行的模块。这里有一个经验刚开始调试时仿真时长不要设太长先跑短时间的仿真确认基本流程没问题再跑长时间的。因为仿真任务一旦下发中途停止比较麻烦而且会浪费计算资源。查看仿真结果时Portal会展示一些关键指标比如碰撞次数、偏离车道次数、平均车速等。但这些指标只是参考真正要判断算法好坏还需要看详细的日志和回放数据。我通常会先把仿真结果里的异常片段找出来逐个分析而不是只看汇总指标。4. 完整实操流程从零开始跑通一个仿真任务4.1 前置准备确认环境和资源在开始操作之前需要确认几件事Apollo系统已经正常启动Portal服务可以访问车辆已经注册并绑定了正确的硬件配置所需的地图已经加载完成标定参数已经上传并校验通过。这些准备工作看起来琐碎但缺了任何一项后面的仿真任务都可能失败。我习惯在开始前做一个检查清单逐项确认。这个清单包括Portal登录是否正常、车辆列表里是否有目标车辆、车辆配置是否和实际一致、地图列表里是否有目标区域的地图、标定参数是否是最新版本。4.2 创建仿真场景的具体步骤第一步进入仿真管理模块点击“创建场景”。第二步选择场景类型。如果是测试跟车算法就选跟车场景如果是测试变道算法就选变道场景。第三步设置场景参数。以跟车场景为例需要设置主车初始车速、前车初始车速、初始距离、前车减速曲线等。这些参数要根据你的测试目的来定不要随便填。第四步选择参与仿真的车辆和地图。车辆要选已经注册并配置好的地图要选覆盖测试区域的。第五步保存场景。保存后场景会出现在场景列表里可以随时编辑或删除。这里有一个细节场景名称建议包含关键参数信息比如“跟车_主车60_前车40_距离20”这样后面在列表里找的时候一眼就能看出来是什么场景不用逐个点开看。4.3 下发仿真任务与监控状态场景创建好后就可以下发仿真任务了。在仿真管理模块里选择“创建任务”然后选择刚才创建的场景设置仿真时长和仿真模式点击“下发”。任务下发后Portal会显示任务状态通常是“排队中”、“运行中”、“已完成”、“失败”这几种。在任务运行过程中可以点击任务查看实时状态包括当前仿真时间、已运行的模块、是否有异常报错等。如果任务失败Portal会显示失败原因。常见的失败原因包括场景参数不合理导致仿真无法启动、车辆配置和场景不匹配、地图未加载、计算资源不足等。根据失败原因逐个排查通常都能解决。4.4 查看仿真结果与数据回放任务完成后可以在仿真管理模块里查看结果。Portal会展示一个结果概览页面包括关键指标和异常事件列表。点击异常事件可以跳转到对应的数据回放页面查看当时的车辆状态、传感器数据、模块输出等。数据回放是分析问题的关键工具。我通常会先看异常事件发生前后的几秒钟数据重点关注感知模块的输出是否正常、规划模块的决策是否合理、控制模块的执行是否到位。如果发现问题再往前追溯看是哪个环节出了偏差。5. 常见问题与排查技巧实录5.1 Portal页面操作无响应或报错这是最常见的问题之一。可能的原因有几种浏览器兼容性问题、Portal服务异常、网络连接不稳定、权限不足。排查顺序建议是先换一个浏览器试试推荐用Chrome或Edge的最新版本如果换浏览器没用检查Portal服务是否正常运行可以尝试重启服务如果服务正常检查网络连接确认能正常访问Portal所在的服务器如果网络也没问题检查当前账号是否有操作权限有些操作需要特定角色才能执行。我遇到过一次Portal页面卡住的情况最后发现是浏览器缓存的问题清理缓存后恢复正常。所以如果遇到莫名其妙的问题清理缓存、强制刷新CtrlShiftR是一个值得先试的操作。5.2 仿真任务下发后一直排队任务一直排队通常是因为计算资源不足。Apollo的仿真任务需要消耗计算资源如果同时下发的任务太多或者已有任务占用了大量资源新任务就会排队。解决办法有两个一是等待已有任务完成后再下发新任务二是检查仿真集群的资源使用情况如果确实资源不足可以考虑增加计算节点或优化现有任务的资源占用。另外有些仿真模式比如分布式仿真对资源的要求更高如果资源有限可以先用单机仿真模式跑通流程再考虑分布式仿真。5.3 仿真结果与预期不符仿真结果和预期不符可能的原因很多需要逐项排查。我通常会按这个顺序检查第一场景参数是否合理。比如跟车场景里前车减速曲线设置得太激进导致主车根本来不及反应那结果肯定是追尾。这种情况下问题不在算法而在场景设计。第二车辆配置是否正确。如果车辆的传感器标定参数不对感知模块的输出就会有问题进而影响规划和控制。检查标定参数是否是最新版本、是否和实际硬件匹配。第三算法模块的版本是否正确。如果最近更新过某个模块的代码但仿真任务用的还是旧版本结果就会和预期不符。确认仿真任务使用的模块版本和当前代码版本一致。第四仿真环境是否和实际环境有差异。仿真里的传感器模型、车辆动力学模型都是简化的和实际环境有差异是正常的。如果仿真结果和实际测试结果差异很大可能需要调整仿真模型参数使其更接近实际。5.4 数据回放时找不到对应数据数据回放时找不到对应数据通常是因为数据存储路径配置不对或者数据已经被清理。Apollo的数据通常会保存一段时间超过保留期的数据会被自动清理。如果需要长期保存某些数据需要在数据管理模块里设置保留策略或者手动导出数据。另外数据回放需要的数据可能分散在不同的存储位置比如车辆运行数据、传感器数据、模块日志等。如果某个位置的数据缺失回放就会不完整。检查数据存储配置确认所有需要的数据都正常保存。5.5 常见问题速查表问题现象可能原因排查方法解决措施Portal页面无响应浏览器兼容性、缓存问题换浏览器、清缓存使用Chrome最新版强制刷新操作报权限错误账号角色权限不足检查账号角色联系管理员分配权限仿真任务一直排队计算资源不足查看集群资源使用等待或增加计算节点仿真结果异常场景参数、标定参数、模块版本逐项检查修正参数或更新版本数据回放缺失数据被清理、存储配置错误检查数据保留策略调整保留策略或导出数据地图加载失败地图文件损坏、版本不匹配检查地图文件完整性重新上传或更换地图版本6. 我在实际操作中总结的几个关键习惯用了这么久Portal我慢慢养成了一些习惯这些习惯帮我省了不少时间也避免了很多低级错误。第一个习惯是操作前先确认状态。不管是改配置还是下发任务先看一眼当前的状态是什么。比如改车辆配置前先确认这辆车当前没有正在运行的任务下发仿真任务前先确认地图和标定参数都是最新的。这个习惯看起来简单但能避免很多“改了配置导致正在跑的任务失败”的情况。第二个习惯是每次修改都留记录。Portal本身有操作日志但那个日志比较简略。我会在修改配置时在备注里写清楚改了什么、为什么改、什么时候改的。这样后面如果出问题回溯起来很快。第三个习惯是先用小规模验证再大规模执行。比如跑仿真先跑一个短时间的、简单的场景确认流程没问题再跑长时间的、复杂的场景。这样即使出问题排查成本也低。第四个习惯是定期清理不需要的资源。Portal里积累的仿真任务、场景、数据会越来越多定期清理不需要的能让界面更清爽也能减少误操作的概率。最后再分享一个小技巧Portal的很多页面支持URL直接跳转如果你经常需要访问某个特定页面可以把URL收藏起来下次直接打开省去从首页逐级点击的时间。这个技巧在需要频繁切换页面的调试场景下特别有用。