4、UWB定位系统架构：基站、标签与定位引擎

这一章我们来聊聊UWB定位系统的骨架——系统架构。说白了，就是搞清楚谁负责发信号、谁负责收信号、谁负责算位置，以及它们之间怎么连起来。

我刚开始接触UWB时，总觉得基站和标签不就是个收发器嘛，能有多复杂？直到第一次在现场部署时，组网方式选错了，导致整个系统延迟高得离谱。嗯，从那以后我再也不敢小看架构设计了。

4.1 基站（Anchor）与标签（Tag）的角色

先讲最基础的两个角色：基站和标签。

• 标签（Tag）：通常是移动端，戴在人身上、贴在物资上、装在AGV上。它的任务就是定时发送UWB脉冲信号，或者响应基站的测距请求。标签一般功耗敏感，电池供电，所以发射功率和发送频率都要精打细算。
• 基站（Anchor）：固定安装在已知坐标位置，通常是天花板、墙壁或立杆上。基站负责接收标签的信号，或者主动与标签完成双向测距。基站一般有稳定供电，计算能力也比标签强一些。

你可能会问：基站和标签能不能互换角色？理论上可以，但实际项目中很少这么做。因为标签的硬件资源有限，让它干基站的活，电池撑不了多久。

我在一个仓储项目中遇到过这样的坑：客户把基站和标签的固件刷反了，结果所有设备都在广播，谁也收不到谁。排查了半天才发现是角色配置错了。所以部署前一定要确认每个设备的角色。

4.2 定位引擎（Location Engine）的功能

基站和标签只负责测距，真正算位置的是定位引擎。它可以是软件（运行在服务器或边缘计算盒子上），也可以是固件（集成在某些高性能基站里）。

定位引擎的核心功能，我归纳为三步：

1. 数据汇聚：收集所有基站上报的测距值（TOF/TDOA原始数据）。
2. 算法解算：根据测距值和基站坐标，用三边定位、最小二乘、卡尔曼滤波等方法算出标签坐标。
3. 输出与优化：输出位置结果（x, y, z），同时做平滑、去野点、轨迹预测等后处理。

举个例子，一个典型的定位引擎输出格式可能是这样的：

{
  "tag_id": "TAG_001",
  "timestamp": 1712345678.123,
  "x": 12.34,
  "y": 56.78,
  "z": 1.50,
  "quality": 0.95
}

我个人习惯把定位引擎部署在靠近基站侧的边缘节点上，而不是全部上云。为什么？因为延迟。如果所有数据都传到云端再算，来回一趟可能多出几十毫秒，对于实时定位来说，这几十毫秒可能就是“准”和“不准”的区别。

4.3 系统组网方式：星型 vs 网状

基站和标签之间怎么通信？这就涉及到组网方式。最常见的两种：星型和网状。

4.3.1 星型组网

星型组网，说白了就是所有标签只跟一个主基站通信，或者所有基站都通过一个中心节点（网关）汇聚数据。

• 优点：结构简单，部署快，延迟可控。每个标签只需要和一个基站交互，调度容易。
• 缺点：中心节点是单点故障。网关挂了，整个系统瘫痪。另外，覆盖范围受限于中心节点的通信距离。

我曾经在一个小型实验室部署中用了星型组网，5个基站、20个标签，效果很好。但后来客户要扩展到200个标签，星型就撑不住了——网关的带宽和时隙根本不够分。

4.3.2 网状组网

网状组网里，基站之间可以互相通信，数据可以多跳转发。标签的数据不一定直接到网关，可能经过其他基站中转。

• 优点：覆盖范围大，可靠性高。某个基站坏了，数据可以绕路走。适合大面积、复杂环境的部署。
• 缺点：网络拓扑复杂，延迟可能增加（多跳），部署和调试成本高。

网状组网在矿井、隧道、大型厂房里很常见。我记得有一次在一条300米长的隧道里做定位，星型根本覆盖不了，最后用了网状组网，每隔30米放一个基站，数据逐级回传，效果很稳。

4.3.3 两种方式对比

对比维度	星型组网	网状组网
部署复杂度	低	高
覆盖范围	受限于中心节点	可扩展，覆盖大
可靠性	单点故障风险	多路径冗余
延迟	低（一跳直达）	可能较高（多跳）
适用场景	小范围、高实时	大范围、高可靠

4.4 系统架构总览

下面这张图把基站、标签、定位引擎和组网方式串在一起，你可以看到数据是怎么流动的。

从这张图你可以看到，整个系统其实就三层：标签层（移动端）、基站层（固定基础设施）、定位引擎层（计算中心）。组网方式决定了基站层内部怎么通信。

我个人建议，初学者先从星型组网入手，搭一个最小系统（3~4个基站、1个标签、1个定位引擎），跑通全流程。等理解了数据怎么流、位置怎么算，再考虑网状组网和优化。别一上来就搞复杂拓扑，容易把自己绕进去。