2. UWB技术基础

做UWB定位项目这么多年，我见过不少团队一上来就急着调算法、测精度，结果连系统里谁该干什么都没理清楚。说白了，UWB定位系统就三样东西：标签、基站、定位引擎。但怎么把它们搭起来、数据怎么跑、用什么协议——这里头门道不少。今天咱们就把这个骨架拆开看看。

2.1 系统核心组成

先说说这三个角色各自是干什么的。

2.1.1 标签（Tag）

标签就是被定位的对象。它是个发射器，周期性地发UWB脉冲信号。我习惯把标签分成两类：

  • 主动式标签：自己发信号，基站只管收。功耗高一点，但实时性好。
  • 被动式标签：等基站问它才回。省电，但刷新率低。

嗯，这里要注意——标签的发射功率直接影响定位距离和电池寿命。我在一个仓储项目里遇到过，标签设成最大功率，结果电池两天就废了。后来改成动态功率调节，续航直接拉到三个月。

我的习惯：标签刷新率别设太高。人员定位1Hz够用，AGV小车可以提到5-10Hz。再高就是浪费电。

2.1.2 基站（Anchor）

基站是固定安装的参考点。它接收标签信号，算出距离信息，然后传给定位引擎。基站分两种角色：

  • 主基站：负责同步时钟、汇总数据、跟定位引擎通信。
  • 从基站：只管收信号、打时间戳，然后把原始数据发给主基站。

你想想看，如果每个基站都直接连服务器，网络布线得多乱？所以实际部署时，一个区域只设一个主基站，其他从基站通过有线或无线连到它。

避坑：我曾经在一个化工厂项目里，把基站装在了金属管道旁边。结果信号反射得一塌糊涂，定位误差直接飙到2米。基站安装位置一定要避开金属物、大水体、混凝土承重柱。

2.1.3 定位引擎（Location Engine）

定位引擎是大脑。它接收基站上报的TOA/TDOA数据，跑定位算法，算出标签坐标。可以跑在本地服务器上，也可以上云。

我个人习惯把定位引擎拆成三层：

  1. 数据接入层：收基站数据，做校验、去重、时间对齐。
  2. 算法计算层：跑TDOA/AOA/TOF算法，输出原始坐标。
  3. 业务应用层：做滤波、平滑、区域判断、电子围栏。
关键点：定位引擎的算力瓶颈不在算法本身，而在并发处理。一个引擎同时处理500个标签和50个标签，压力完全不是一个量级。

2.2 系统拓扑结构

拓扑结构决定了系统怎么连、怎么部署。我见过的主流方案有三种，直接上SVG图看更清楚。

UWB定位系统三种拓扑结构对比 UWB定位系统拓扑结构对比 星型拓扑 定位引擎 基站1 基站2 基站3 链式拓扑 主基站 从基站1 从基站2 从基站3 混合拓扑 定位引擎 主基站A 主基站B 说明： 星型：每个基站直连引擎 链式：从基站通过主基站上传 混合：多主基站+从基站组合

三种拓扑各有适用场景：

拓扑类型 适用场景 优点 缺点
星型 小范围、高精度（如实验室） 延迟低、数据不经过中间节点 布线多、引擎端口压力大
链式 长条形区域（如隧道、走廊） 节省布线、扩展方便 中间节点故障会断链
混合 大面积复杂场景（如工厂、园区） 灵活、可靠性高 配置复杂、调试成本高
我的建议：别一上来就搞混合拓扑。先从小范围星型开始验证，确认算法和精度没问题了，再扩展成链式或混合。我见过太多人把拓扑搞复杂了，结果定位不准都不知道是算法问题还是网络问题。

2.3 数据流与通信协议

系统搭好了，数据怎么跑？这是整个定位系统的血管。我把它分成三段：

2.3.1 标签 → 基站（UWB空口）

标签发UWB脉冲，基站收。这里用的协议是IEEE 802.15.4-2011 UWB。说白了就是物理层标准，规定了脉冲怎么发、频率用多少、时间戳怎么打。

数据包结构大概长这样：

| 前导码 (64/128/256 symbols) | SFD (帧起始定界符) | PHR (物理层头) | PSDU (数据负载) |

嗯，这里要注意——前导码越长，抗干扰越强，但功耗也越高。我在一个电磁环境复杂的车间里，把前导码从64 symbols调到256，定位成功率从70%提到了98%。代价是电池少用一周。

2.3.2 基站 → 定位引擎（有线/无线回传）

基站算出了TOA/TDOA数据，得传给定位引擎。主流方案有三种：

  • 以太网（TCP/UDP）：最稳，延迟低，但布线成本高。
  • Wi-Fi：灵活，但容易受干扰，延迟不稳定。
  • LoRa/4G：适合室外大范围，但带宽低，只能传精简数据。

我个人习惯用UDP + 应用层ACK。为什么不用TCP？因为TCP重传机制在实时定位场景下反而会引入不确定延迟。UDP丢包了，让定位引擎做插值补偿，比等重传靠谱。

数据格式示例（JSON over UDP）： 
{
  "anchor_id": "A003",
  "tag_id": "T015",
  "toa_ns": 1623456789000,
  "rssi": -65.3,
  "seq": 1423,
  "timestamp": 1623456789123
}

2.3.3 定位引擎 → 应用层（API/WebSocket）

定位引擎算出坐标后，得喂给上层应用。这里我推荐两种接口：

接口类型 适用场景 数据格式 延迟
REST API 非实时查询（如历史轨迹回放） JSON 秒级
WebSocket 实时定位（如电子围栏、导航） JSON/Protobuf 毫秒级
避坑：我曾经在一个项目里用REST API做实时定位，结果标签一多，HTTP请求把服务器打崩了。实时场景必须用WebSocket或者MQTT，别偷懒。

2.4 完整数据流链路

把上面三段串起来，整个数据流就是：

  1. 标签发UWB脉冲 → 基站收信号、打时间戳
  2. 基站通过UDP把TOA数据发给定位引擎
  3. 定位引擎做TDOA解算、卡尔曼滤波 → 输出(x, y, z, 置信度)
  4. 定位引擎通过WebSocket推给应用层

整个过程从标签发脉冲到应用收到坐标，延迟控制在10-50ms算正常。超过100ms就得排查了——是网络问题还是算法算力不够？

我的经验：调试阶段一定要在定位引擎侧打日志，记录每个数据包的接收时间戳。这样能快速定位是基站上报慢了，还是算法算慢了。别问我怎么知道的——当年在一个煤矿项目里，我花了三天才发现是交换机端口限速了。

好了，系统架构这块就聊到这儿。记住一句话：架构决定上限，细节决定下限。拓扑选对了、协议选好了，后面调精度才有意义。不然你算法再牛，数据链路一塌糊涂，定位照样飘。

← 上一章 📖 返回目录 下一章 →