简而言之：在需求分析阶段之后，您通常会得到两到三种可能满足需求的架构方案。本阶段的目标是在任何电路板送交制造之前，利用真实世界数据并在具有代表性的硬件上，将这些选项缩减为一种。核心决策在于定位引擎的运行位置：是在模块上还是在主机上。 通过四个数据流相关的问题，可以进一步缩小剩余选项的范围。而且，原型设计过程本身往往会揭示出最初需求说明中未提及的要求，而在V模型的左侧阶段，这些要求很容易被纳入。
这是关于自主系统与机器人定位系统设计系列文章的第四篇。前几篇文章分别介绍了V模型及设计项目的各个阶段、最常导致项目脱轨的六大错误，以及在评估硬件之前必须明确的三个要求。每篇文章都源自汤姆·威克斯（Tom Weeks）与我之间的真实对话。本文将从“需求探索”阶段结束之处继续展开。
需求分析阶段会为您提供一套属于您产品的具体要求，而非数据表中列出的某个数值。此外，它还会为您提供两到三种可能满足这些要求的候选架构。
这就是V型模型左侧不再停留在理论层面之处。你必须做出选择。而做出选择的方式并非进行更多分析——而是要在产品实际运行的环境中对候选方案进行测试。
这是我最喜欢的工作部分。
关键决策：定位引擎的运行位置
市面上大多数RTK接收机都是模块化的。定位引擎在模块自身的计算资源上运行，而这些资源是有限的。对于许多应用场景而言，这确实是合适的解决方案，这一点值得明确指出——我们并不主张团队采用基于主机的架构。关键是要确认模块内置的解决方案确实适用于您正在开发的项目。
当应用需求超出标准RTK加IMU解决方案的范围时，该方案便无法胜任。例如：非标准平台动态特性；多径效应持续存在的城市复杂环境；以及与摄像头、激光雷达或车轮里程计的融合应用。在这些情况下，该模块的计算能力上限将成为一道难以逾越的壁垒，此时的解决方案便是采用基于主机的架构——即让定位引擎在平台的主计算单元上运行。
我们目前观察到的一种变化是，各团队会更早地询问是否可以利用平台上已有的计算能力。运行激光雷达栈的机器人，其计算能力通常已远超GNSS模块。通常情况下，答案是肯定的。
如果在设计验证测试（DVT）阶段发现这一问题，团队将面临重新设计；如果在架构选型阶段发现这一问题，团队则会就此展开讨论。
四个问题，帮助确定剩余架构的具体方向
定位引擎的位置是关键所在，但四个关于数据流的问题则决定了其下游的所有内容。每个问题的答案都会排除某些架构方案。
仅使用GNSS还是与惯性导航融合？在某些应用场景中，仅使用RTK引擎是更优的选择——如果你仅希望在获得载波相位定位时依赖位置信息，并且由你自己的传感器堆栈中的其他传感器来处理连续性问题，那么这就是最简洁的解决方案。如果系统需要在GNSS信号中断期间保持位置，你就需要惯性融合，这会改变上述关于计算的问题。它还引发了松耦合与紧耦合的决策问题。
校正源是什么？该应用能否为了获得更稳定的覆盖范围而容忍精度略有降低？ SSR和VRS解决方案与单基线RTK的权衡方式不同，正确答案取决于产品的工作位置以及它与最近参考站之间的距离。网络密度是决定您实际需要做出多少这种权衡的关键变量。
仅需位置信息，还是包含姿态信息的完整PVT？一台试图确定地下公用设施绝对位置的扫描仪只需位置信息。仅此而已。 而一辆需要在赛道弯道上了解自身偏航角、俯仰角和横滚角的车辆——或者在驶入停车场时需要提供航向，以便下游系统知晓其朝向——这则完全是另一套需求，后端所需的数据流也截然不同。这一点往往被忽视，因为航向和姿态参数并未在GNSS数据表中明确列出。
姿态信息也必须源自某种物理量。两根基线固定的天线可直接输出GNSS航向，这就是双天线系统存在的理由——我们的产品Atlas Duo便是其中之一。单根天线与IMU融合后也能输出航向，但前提是平台必须移动到足以使航向成为可观测量；而这恰恰是需要静止状态下获取姿态信息的车辆所面临的限制。 俯仰角和横滚角则来自惯性测量结果。这一点值得尽早确定，因为它涉及天线数量和安装方式的决策，而非日后可以随意更改的软件设置。
连接性有哪些要求？归根结底，更正功能需要网络连接。了解产品在何处运行以及当地的网络接入情况，是架构设计的一部分，而不是留待日后解决的实现细节。
实际上共有四种方案，而大多数系统最终都会采用一种主方案和一种备用方案。对于地面平台而言，蜂窝网络是默认选择——校正数据通过NTRIP传输，但其代价是存在覆盖盲区。当平台在已知覆盖范围内运行时（例如仓库或固定作业现场），Wi-Fi即可发挥作用。 通过本地无线链路连接您自有的基站，可以完全摆脱对网络的依赖，这也是该方案在农业和 测绘领域得以持续应用的原因——但其应用范围仅限于您已安装基站的地理区域。L波段卫星可在完全没有地面网络的地方提供校正数据，但其精度低于地面RTK。
备用方案决定了在那个仅占百分之一左右、却会耗尽您全部可用性预算的瞬间会发生什么。这一点值得您有意识地做出决定。
构建概念验证：具有代表性，而非完全相同
一旦我们有了两到三个参考架构，接下来的任务就是尽可能忠实地复现它们，并将其投入实际应用。
具体来说，以一款中型户外移动机器人为例，三种方案可能包括：（1）基于模块化的RTK加IMU解决方案，通过蜂窝网络NTRIP接收校正数据，并通过串行接口输出位置信息——成本最低、计算需求最低； (2) 采用相同的接收机硬件，但将定位引擎运行在机器人的主机计算单元上，并在GNSS信号较弱的路段将车轮里程计数据纳入融合算法；以及 (3) 采用集成硬件加速器，通过以太网提供完整的PVT（位置、速度、时间）及姿态数据，其集成中的未知因素最少，但单位成本最高。 这三种方案在理论上都能满足精度要求。但在树线以下的环境中表现差异巨大，且在5,000台的批量生产时，其物料清单（BOM）也大不相同。
标准是具有代表性的硬件，而非完全相同的硬件。理想情况下，概念验证应使用客户计划投入生产的同一款硬件，但这取决于客户的时间表以及现有资源。如果无法做到这一点，那么信号路径架构才是关键。
例如：某个团队选定了一个模块，但该模块的样品要再过三个月才能到货。为了不辜负这个季度，我们利用手头现有的接收器进行开发，将其配置为通过相同的串行接口，以与该模块在生产环境中主机所见相同的速率发送相同的消息集。他们的集成工作是真实的工作，性能数据也是真实的数据。部件编号会在后续进行更改。
如果客户已经确定要使用一种通过串行接口向主机输出数据的模块——也就是说，该模块在机载端计算位置，并通过串行接口将计算结果流式传输到主计算设备，而不是将原始观测数据交给主机进行处理——那么我会搭建一套通过串行接口向主机输出的测试平台，即使底层的接收器不同也无妨。 如果客户使用的是高端接收机，我可以使用不同的评估套件（EVK）——即供应商提供的用于在确定设计方案前测试接收机的开发板——构建结构上相似的系统。我们验证的是架构，而不是物料清单（BOM）。
正是这种区别使得快速原型制作成为可能。如果你必须等待数月才能拿到首批电路板，才能进行有意义的测试，那么在你获得任何结果之前，你的时间缓冲就已耗尽。而且，如果在这段时间内进行的测试仅针对单个元器件而非整个系统，问题就会由此产生。
案例研究：可穿戴眼镜上的RTK技术
如今，配备摄像头和惯性测量单元的可穿戴眼镜已随处可见。一位正在构建VIO系统（视觉惯性测距系统，通过融合摄像头图像与IMU数据来追踪位置）的客户联系我们，希望在该系统中集成GNSS功能。
他们早就放弃了GPS。他们测试过，发现行不通，于是转而尝试其他方案。
当我们深入探讨他们实际测试的内容时，发现问题出在天线的安装位置上。无论是佩戴在胸前还是安装在头部一侧，所获得的信号质量都无法满足要求。由于身体的遮挡以及安装位置的不确定性，这种信号环境与安装在汽车车顶上的天线所处的环境有着根本性的差异。这并不是GPS的问题，而是一个被错误归咎于GPS的设计问题。
于是，我们搭建了一个可测试的系统。他们向我们寄来了一套自家计算平台的评估套件——这套套件搭载了其产品将采用的同款处理器，并配有一块我们可以进行接线的开发板。我们连接了他们正在使用的同款接收器，并搭建了一个小型模块化装置，可供真实用户在真实环境中佩戴。有几张我佩戴该装置的照片：计算单元位于腰间，天线就位，旁边还配有一根头戴式天线，用作地面参考系统。
那个头戴式地面实测装置是刻意采用低技术方案设计的，而且已经使用很久了。如果有人需要，可以提供。
在此基础上，我们便能借助这些设备收集真实数据，并解答实际问题。每种环境会使信号质量下降多少？当信号质量下降时，定位引擎如何仍能生成可用的定位结果？当GNSS信号中断时，IMU能多好地维持位置信息？
这为他们开辟了一条此前未曾考虑过的途径：他们已经拥有了运行VIO系统的计算平台。该模块的通用惯性解算方案虽未针对人体运动特性进行优化——但没有理由认为GNSS融合算法不能在现有的计算平台上运行。
该产品从“GPS对我们不起作用”发展成了一个可行的架构。这并不是因为算法更优，而是因为我们测试了正确的内容。
原型设计是一种需求分析工具，而不仅仅是一种验证工具
可穿戴设备是常态，而非例外。对于刚涉足精准定位领域的应用——如应急救援人员可穿戴设备、安全装备、随身传感器等——在原型开发过程中，往往会涌现出最初需求文档中未曾提及的要求。
有时这意味着要回到需求分析阶段。在V型模型的左侧，这种回溯成本很低。你只需修改一份文档，然后重新搭建一个测试平台即可。而在右侧，同样的回溯则意味着重新设计、延误，最坏的情况下甚至会导致项目取消。
该阶段的迭代版本大致是这样的：那套硬件没用，我们来搭建一套配置更高的硬件，看看数据有没有变化。或者：让我们回过头来重新审视你真正想要实现的目标。目前这两种做法成本都不高。但一旦你已经生产了数十、数百甚至数千块电路板，却在那个时候才发现故障，这两种做法的成本都会变得很高。
硬件加速器的应用场景
还有一种值得了解的中间方案。我们实施这一流程的方式之一，是使用生产级硬件，将所需的一切——接收机、惯性测量单元（IMU）、RTK引擎和传感器融合——整合到一个单元中。我们称这些为硬件加速器。Atlas INS和Atlas Duo是当前一代产品。
如果是10或50个单位，您可能根本不需要基于模块的设计。您可以使用一款能够代表您正在验证的架构的硬件加速器来交付产品。如果是1,000个单位，采用您自己的基于模块的设计就很有意义。 当产量达到10,000或20,000时，您需要考虑采用“芯片级封装”设计——即将接收器芯片组直接集成到您自己的PCB上，而不是购买预封装的模块。这种设计虽然前期需要投入工程开发工作，但在大规模生产时，能通过降低物料清单（BOM）成本和节省电路板面积来收回成本。
在上述每个过渡阶段，概念验证方法依然适用。你不能只是将一个新的接收器直接塞进已上市的产品中，就以为大功告成。每一代产品都要经历相同的阶段——而这正是开展有趣的成本降低工作的关键所在。在下一代产品中进行芯片级优化，可以让你获得更多的频段、更多的星座，并降低物料清单（BOM）成本，因为你可以剔除模块中未使用的那部分元件。
真正的交付成果
该阶段的输出结果是基于数据选定的一种架构。
但实际目标比这更窄。当设计进入制造阶段时，出现灾难性需求遗漏——即系统设计出现重大缺陷，导致必须回到V模型的左侧，甚至导致项目流产——的可能性，应通过该流程尽可能降至接近零。
这就是测试能带来的价值。它带来的不是确定性——因为没有人能拥有确定性——而是让你确信，你所投入的这项工作，已经在它实际投入使用时的环境中得到了验证。
下一篇博文将介绍进入工程验证测试（EVT）阶段后会发生什么——以及当V模型的左侧阶段完成得当，其右侧阶段会呈现怎样的状态。
如果您正在评估各种架构方案，并希望在做出最终决定前使用真实数据对其进行压力测试，请与 Point One 的工程师预约一次探索研讨会。
常见问题解答
本地化系统设计的架构和原型设计阶段包括哪些内容？
这是从需求阶段到确定硬件方案之间的关键一步。你从需求探索阶段筛选出的两到三种候选架构入手，为每种架构构建具有代表性的原型，在实际运行环境中进行测试，并根据测试数据选定其中一种。其目标是通过实证而非分析来淘汰不合适的架构。
定位引擎应该在GNSS模块上运行，还是在主机上运行？
这取决于计算需求。大多数模块化RTK接收机都在模块上运行定位引擎，对于开阔天空信号覆盖良好且仅需标准RTK加IMU的应用而言，这已足够。 而需要进行复杂传感器融合的应用——例如非标准平台动力学、信号受限的城市环境，或与摄像头、激光雷达或里程计进行融合——往往会超出模块的计算上限，需要采用基于主机的架构。在需求阶段做出这一决定成本较低；若在设计验证测试（DVT）阶段才发现这一问题，则意味着需要重新设计。
在GNSS概念验证中，“代表性硬件”是什么意思？
一种能够再现目标设计信号路径和数据流的硬件，即使具体组件有所不同。如果生产设计是一个通过串行方式向主机输出的模块，那么原型也应是一个通过串行方式向主机输出的模块——具体的接收器可以不同。验证的对象是架构，而非物料清单。
如何从GNSS系统中获取航向和姿态？
有两种方法。在固定基线上的双天线配置可直接计算出GNSS航向，且在静止状态下也能工作。单天线与IMU融合后也可计算航向，但仅当平台移动到足以使航向可观测的程度时才可行。俯仰角和横滚角则来自惯性测量结果。由于这决定了天线数量和安装方式，因此必须在架构选型阶段就确定，而非作为软件配置来处理。
提供RTK校正时有哪些连接选项？
对于大多数地面平台而言，通过NTRIP连接蜂窝网络是默认方案，但其代价是存在覆盖盲区。对于活动范围限定在已知区域内的平台，Wi-Fi是一种可行的方案。 通过本地无线链路连接至自有基站可消除对网络的依赖，但其覆盖范围仅限于已安装基站的地理区域。L波段卫星可在无地面网络的区域提供校正服务，但其精度低于地面RTK。大多数生产系统采用主路径加备用路径的方案，而备用路径决定了在网络中断期间的行为方式——这种中断会破坏高可用性要求。
为什么天线的放置位置对可穿戴设备如此重要？
车辆车顶安装的天线具有开阔的天空视野和地面平面作为有利条件。而佩戴在胸前或侧面的天线则会受到身体的遮挡，且方向会不断变化，从而形成截然不同的信号环境。团队经常认为GNSS不适用于其可穿戴设备，但实际的限制因素其实是天线的位置。通过使用具有代表性的测试平台进行测试，可以区分这两者。
如何测量穿戴式定位系统的真实值？
在同一平台上佩戴第二个质量更高的参考系统。对于可穿戴设备，我们使用头戴式天线装置作为基准——这种方法刻意设计得简单，却行之有效。如果没有基准参考，虽然可以收集数据，但无法测量误差，这会大大降低测试的价值。
什么是 SSR？在什么情况下应该使用它来代替单基线 RTK？
SSR（状态空间表示法）通过在整个区域内校正模型误差源，而非仅传输单个基准站的观测数据。与短基线单站RTK解相比，SSR和VRS解通常能在更大范围内提供更一致的覆盖，但峰值精度会略低一些。最佳选择取决于产品的应用区域以及基准站的密度。网络密度决定了这种权衡关系的显著程度。
在本地化系统设计中，什么是硬件加速器？
一款生产级设备，将接收机、惯性测量单元（IMU）、RTK引擎和传感器融合功能整合为单一集成系统。它使团队无需自行进行基于模块的设计，即可实现小批量生产，并在架构验证过程中作为代表性硬件使用。Atlas INS 和 Atlas Duo是 Point One 的硬件加速器。
什么是芯片下置式设计？
将GNSS接收机芯片组直接集成到自研PCB上，而非使用预封装模块。虽然前期需要投入更多的工程精力，且需要具备射频设计能力，但在大批量生产时，这将通过降低物料清单成本和节省电路板面积得到回报。此外，这种做法还能扩展功能，因为您不再受限于模块供应商所选的频段和星座配置。
当产量从100单位扩大到100,000单位时，本地化架构会发生怎样的变化？
在产量为 100 单位时正确的架构，在产量达到 100,000 单位时往往就不合适了。在小批量生产时，集成硬件加速器通常是最快的实现途径。 随着产量增长，采用自主开发的模块化设计便更具经济性；而在大规模生产时，则应采用芯片级设计。每次转型都应经历相同的概念验证流程——而每次转型都蕴含着机遇，因为芯片级设计既能增加频段和星座，又能通过剔除未使用的模块组件来降低成本。
如何进一步了解“Catalyst”流程？
Catalyst 是 Point One 用于本地化系统设计的方法论。关于 V 模型的博文介绍了各阶段内容，并阐述了为何左侧决策会主导右侧成本。关于六大常见错误的博文则探讨了最常导致重新设计的一些具体选择。关于需求探索的博文则介绍了在架构选型之前需要考虑的三个需求输入要素。后续博文将深入探讨 EVT、V 模型的右侧部分，以及需求定位在大规模环境下的演变过程。 您还可以直接体验定位引擎，或预约与现场工程师进行交流。