简而言之： 在评估任何GNSS/RTK硬件之前，您需要明确三方面的输入：设计约束（功耗、成本、外形尺寸和计算能力——其中计算能力往往被严重低估）、运行环境（天空可见度、天线安装方式和平台动态特性），以及应用场景（即系统在最恶劣条件下必须输出的结果，而非最佳状态下的表现）。 针对这三个输入要素进行一小时的深入探索，即可得出两到三个可供实际测试的候选架构——从而避免在DVT阶段因重新设计而导致项目流产的情况。
每当有新客户进来时，我最常听到的一句话是：“我需要GPS达到1厘米的精度。”
这个数值通常来自接收机的数据手册。他们找到一款支持RTK的模块，看到其规格——“1厘米加上基线长度的百万分之一”——便将其写入了技术要求。接下来的问题是：该接收机如何在产品将要运行的各种环境中真正实现1厘米的定位精度？
这就是探索过程的开始。
规格表上的数值是真实的，但这些数值是在理想条件下测得的：视野开阔、天线周围没有任何干扰、与基站的基线距离很短。大多数产品实际运行时的环境都远非如此。规格表中并未提供六种不同环境下的精度数据，因为这些环境并非该产品需要考虑的问题——而是需要由您在设计时加以考虑的。
需求分析是指将数据表中的某个数值替换为符合您产品的一套要求的过程。
尽快投入硬件开发的直觉是正确的——顺序很重要
工程师们渴望进行开发和测试。这种对硬件的倾向是可以理解的。但若在收集到正确的信息之前就贸然行动，项目就会因此耽误时间。
在V型模型左侧阶段能压缩进度的团队，往往是那些将探索阶段执行得很好的团队。一次聚焦的探索性讨论大约在一小时内就能涵盖核心输入内容。架构方案是在讨论过程中就开始酝酿的，而不是在讨论之后——其结果是，团队能够更快地获得具有代表性的硬件，并对正在测试的架构抱有更高的信心。
正在设计的系统是完整的定位技术栈：天线、接收机、惯性测量单元（IMU）、定位引擎软件以及用于接收校正数据的连接功能。而不仅仅是GNSS模块。每个组件的设计都将根据需求分析的结果来确定。
这三个输入因素分别是设计约束、运行环境和应用用例。
输入 1：设计约束——限制每项硬件决策的四个物理限制
在评估硬件之前，您需要了解任何硬件选择都必须满足的约束条件。这些约束条件界定了设计空间的边界。
功耗预算。可穿戴设备配备的电池容量较小。这一限制会立即缩小可选接收器的范围。性能更强的接收器通常功耗更大，因此更严格的功耗预算会迫使系统在其他方面做出权衡。
成本目标。如果机队中的每架无人机都配备高端测绘接收机，虽然能实现卓越的定位精度，但在大规模应用时却不可行。成本目标界定了批量生产时的硬件成本上限。RTK校正技术从根本上改变了这一计算逻辑：一款能够接入校正网络的低成本接收机，可以达到其独立工作时无法企及的精度，这为团队提供了一种最初往往未被考虑的性能与成本之间的权衡。
尺寸、外形尺寸和PCB空间。天线必须安装在平台上的某个位置，且该位置需能清晰地面向天空。接收器和计算单元必须符合机械尺寸限制。PCB空间是有限的，每个共享该空间的组件都会带来潜在的射频干扰。外形尺寸决定了天线的布置方式，这进而影响信号质量，最终影响整个定位系统。
计算资源的可用性——切勿选错。这是最常被低估的限制因素，也是导致后期重新设计时最令人头疼的问题。
大多数RTK接收机都是模块化的——定位引擎在模块自身的计算资源上运行，而这种计算资源是有限的。对于开阔天空条件良好的应用场景，这没有问题。但当需要融合额外传感器、平台动态特性复杂，或者需要超出标准RTK加IMU解决方案范围的功能时，计算能力的上限便成为一道难以逾越的障碍。
那些围绕模块化接收器构建系统，却在DVT阶段发现其环境所需的传感器融合功能超出了该模块支持范围的团队，面临两种选择：缩减系统规模，或者围绕基于主机的架构进行重新设计，使定位引擎在平台的主计算单元上运行。在该阶段，无论选择哪种方案，成本都很高。
我们观察到的一种变化是，团队会更早地提出这样的问题：能否利用平台上现有的计算资源？通常答案是肯定的——而尽早确认这一点，可以降低架构决策的成本。
输入 2：运行环境——决定硬件必须能够承受哪些条件的三个层面
设计约束决定了硬件必须具备什么特性。运行环境则决定了硬件必须能够承受什么样的条件。
GNSS 的应用场景。开阔天空是最简单的情况。如果某款产品始终在开阔天空下运行且能连接互联网，那么仅支持 RTK 的引擎可能是合适的解决方案——这一点值得直接说明。但开阔天空的情况很少能完全涵盖所有场景。 城市环境、建筑工地、室内外过渡区域，以及任何在建筑物附近运行的情况，都会产生多径效应和信号衰减，从而彻底改变系统架构。一款在停车场工作的地下管线扫描仪，与直接贴着建筑物墙壁进行扫描的设备，绝非同一款产品。
设备安装的位置。安装在汽车车顶的天线拥有极佳的天空视野，且受地面平面效应的有利影响。而佩戴在胸前或肩上的设备则面临不同的信号环境——身体遮挡、姿态变化以及更难控制的信号质量。物理安装位置决定了初始信号质量，这进而决定了定位引擎需要投入多少计算资源，最终决定了融合过程中需要使用哪些传感器。
平台动力学、振动与运动模型。无人机与汽车的运动特性不同。四轮转向车辆与两轮转向平台的动态表现存在差异，这些差异对传感器融合算法如何建模运动具有重要影响。农业拖拉机具有特定的振动和滑移特征。行走中的人会产生截然不同的动态特征。
运动模型正是这一概念的具体体现。传感器融合软件会建模特定平台的运动方式——即该平台在加速、转弯、振动或暂时失去GNSS信号时会发生什么。 通用模型能够充分应对各种类型的平台。但在性能极限条件下，针对平台实际动力学特性进行优化的解决方案将表现更佳。大多数模块化接收机都提供通用惯性解决方案——这是一种已知的权衡，但必须是针对具体应用而言的正确权衡。
信号质量将这三层紧密联系在一起。它是决定在特定工作环境下能否实现厘米级RTK的关键因素。
输入 3：应用用例——系统在最艰难时刻必须输出的内容
系统在最严峻的时刻——而不是最轻松的时刻——应该输出什么？一款在开阔天空下能达到厘米级精度，但在其他所有情况下都失效的产品，根本算不上产品——它只是通过了错误测试的原型。我们的目标是打造一个系统，使其在应用将面临的各种环境中，99.9%的时间都能正常运行。
这意味着精度必须设定在可设计实现的范围内。1厘米是一个目标值。关键在于1西格玛误差、2西格玛误差、保护等级，以及系统在无法满足这些限制时会采取什么措施。是仅需定位，还是还需姿态控制——即航向、俯仰和横滚？在倾斜转弯过程中需要确定自身姿态的飞行器，与仅需绝对位置信息的扫描仪相比，所面临的问题截然不同。
应用场景的探讨还会揭示出一些起初并不明显的限制。一个将产品描述为户外手持设备的团队，起初可能不会将其定位为城市环境问题——直到理解了具体的使用场景。一旦情况明朗，设计上的启示便随之而来。
业务成果与规模。该应用程序如何扩展？目标处理量将决定修正策略、连接性要求以及架构决策——即使在需求阶段，这些因素似乎还很遥远。需求探索本身就是一项生产力投资：花一小时有针对性地收集需求，可以压缩原本在设计验证（DVT）阶段需要数周才能完成的迭代工作。
一项有价值的发现能带来什么
一次运作良好的需求探索会议的成果并非最终确定的设计方案，而是两到三个能够合理满足需求的参考架构，这些架构已准备好在真实环境下使用真实硬件进行相互评估。
在这个阶段，关键在于保持多种选项的开放性。需求探索阶段提供的信息足以避免过早淘汰不合适的架构。下一步——架构选项和实际原型制作——是在任何电路板进入量产之前，构建每个候选方案的代表性版本，并在实际运行环境中对其进行测试。
这就是下一篇博文要讲的内容。
如果您正处于本地化系统设计项目的初期阶段，且希望在确定硬件方案之前先梳理需求，请与 Point One 的工程师安排一次需求探索研讨会。
常见问题解答
什么是“Catalyst”发现流程？
Catalyst 是 Point One 用于本地化系统设计的方法论。发现阶段是第一步：在评估任何硬件之前，通过结构化的对话来厘清设计约束、运行环境和应用需求。该阶段通常耗时约一小时，并能产出两到三种可供实际验证的候选架构。
GNSS定位系统设计需要考虑的三个要素是什么？
这三个输入包括设计约束（功耗预算、成本目标、尺寸和外形尺寸以及计算资源可用性）、运行环境（GNSS天体可见性、物理安装方式和平台动态）以及应用场景（所需输出、精度范围以及大规模部署时的业务成果）。
为什么接收器的数据手册中的规格无法作为系统要求？
数据手册中的数值（如“1 厘米 + 1 ppm”）是在理想条件下测得的——即开阔天空、短基线、无干扰。实际产品运行的环境往往与这些条件不符，而数据手册并未说明在不符合这些条件的情况下性能表现如何。将数据手册中的规格作为设计要求，意味着设计时依据的是你可能遇到的最佳情况，而非产品实际投入使用时的环境条件。
什么是计算可用性？它为何对GNSS系统设计如此重要？
大多数模块化GNSS接收机出厂时，其板载计算能力都较为有限。对于需要进行复杂传感器融合的应用——例如将GNSS与IMU、摄像头、激光雷达或非标准平台动力学数据进行融合——这一计算能力上限便成为了一项硬性限制。如果开发团队在设计验证阶段才发现这一问题，而非在需求阶段就发现，将面临代价高昂的架构重构。尽早识别这一问题，可以降低决策成本。
什么是运动模型？它为何会影响定位性能？
运动模型是指传感器融合软件中关于平台运动方式的一系列假设——包括其动力学特性、转弯行为、振动特征以及对加速度的响应。通用模型能够充分满足各类平台的广泛需求。对于处于性能极限、具有特殊动力学特性或对精度要求极高的应用，采用针对其特定平台进行调优的模型将大有裨益。
运行环境如何影响GNSS硬件的选择？
环境决定了系统可预期的信号质量，这进而决定了融合架构，进而影响硬件的选择。开阔地形支持更简单的纯RTK方案。而城市环境、可穿戴应用以及动态特性复杂的平台，则需要额外的传感器、更高精度的惯性测量单元（IMU）以及针对特定平台进行优化的定位引擎软件。
发现阶段需要多长时间？
对于大多数项目而言，核心需求探讨大约需要一个小时。在此过程中，架构方案开始初步成形。对于规模较大的项目或更复杂的环境，在提交正式提案之前可能会进行内部跟进，但只要按照正确的顺序提出正确的问题，收集意见的大部分工作就能迅速完成。
如何进一步了解GNSS定位系统中的传感器融合技术？
传感器融合——即将GNSS、IMU及其他传感器数据整合为单一位置输出——是贯穿定位系统设计各个阶段的核心要素。Catalyst系列通过多篇博文对此进行了深入探讨。关于V模型的那篇博文解释了，为何在设计初期做出的融合决策，会成为后期最难更改的约束条件。《六大常见错误》一文重点探讨了与融合相关的具体选择——IMU等级、计算架构、运动模型——这些因素最常导致在DVT阶段需要重新设计。该系列后续文章将更深入地探讨架构选项、概念验证原型设计，以及随着设计规模从10台扩展到100,000台时，融合需求如何发生变化。您还可以直接探索Point One的定位引擎，或预约与现场工程师进行交流。