从零搭建UM982厘米级RTK定位系统：硬件接线、NTRIP配置与飞控接入实战

前阵子调试一架DIY远航机，GPS定点模式悬停时飞机自己在天上画圈，返航落点每次都偏出好几米。后来换上了UM982模组做RTK定位，同一个飞场、同一套飞控，定点和返航的误差直接压到了厘米级。这篇就把我从零搭建UM982厘米级RTK定位系统的过程完整写出来，包括硬件接线、差分源选择、配置代码、飞控接入，以及我在实测中踩过的坑。内容基于我自己跑通的方案，适合正在做无人机DIY项目、想摆脱米级GPS精度瓶颈的朋友参考。

1. 先搞清楚RTK到底解决了什么问题，为什么偏选UM982

1.1 普通GPS在无人机上的米级瓶颈从哪来

消费级无人机用的GPS模块基本都基于伪距定位。接收机测量卫星信号从卫星到天线的传播时间，乘以光速得到伪距，再用至少四颗卫星解算位置。原理听起来简单，但卫星钟差、电离层延迟、对流层延迟、多路径效应，全都会注入伪距误差。民码信号本身精度有限，正常情况下水平定位误差在2米到5米之间，靠近楼体或者有金属反射面时多路径误差还能更大。

飞控拿到这样的定位结果，GPS定点模式自然稳不住。油门稍微一动，位置估计就跳几十厘米，飞控只能不断修正，表现出来就是悬停漂移、航线走偏、自动返航落点离散。很多DIY玩家觉得“GPS就该这么飘”，其实不是GPS不行，是普通GPS本身就只有米级能力。想真正解决，就得从定位原理上换一条路。

1.2 RTK的原理可以用一句话加一个例子讲透

RTK（实时动态载波相位差分）的核心不是提高单台接收机的测量精度，而是利用误差的空间相关性把公共误差消掉。基准站架在已知坐标点上，连续接收卫星观测值；移动站（也就是无人机上的UM982）同时接收同样的卫星信号；两份观测值相减，电离层、对流层、星历误差这些在短基线内近似相同的分量就被抵消了，剩下的主要是载波相位模糊度需要解算固定。

打个比方：两个人站在同一片操场上看远处同一个目标，视线都会受同样的大气折射影响，各自测的角度都有偏差，但两人测量值相减后，共同偏差就被消掉了，剩下的就是两人之间的相对关系。RTK就是干这件事，只是一边是固定基准站，一边是移动站。当模糊度固定成功后，定位精度进入厘米级；固定失败时退到浮点解，精度大约亚米级；差分数据都没收到时就是普通单点解，回到米级。

1.3 UM982的参数和选型理由

UM982是双天线高精度定位测向模块，支持GPS、BDS、GLONASS、Galileo多系统多频点，内部集成RTK解算引擎，不需要外接计算单元。移动站模式下，它的RTK固定解水平精度标称在1.5厘米加1ppm左右，双天线测向精度大概0.1度量级。这意味着一块模组既能当高精度定位源，又能当电子罗盘输出航向，对固定翼和多旋翼来说都很实用。

我选UM982而不是u-blox F9P，主要看中三点。一是内置RTK解算，F9P同样内置，但UM982的双天线基线测向能力在DIY里更灵活；二是协议输出支持NMEA、UBX等格式，飞控接入方便；三是价格相对同级别板卡有优势，资料也开放到一定程度。性能上两个型号都够用，但UM982更贴近“一块板子解决定位加测向”的需求。

1.4 为什么不用成品的RTK商用方案

市面上也有集成好的RTK套装，到手即用，但价格高、接口封闭，想接进自己的飞控或是改差分数据链路很费劲。DIY项目本来就强调可控性和扩展性，用UM982模组自己做，成本压下来了，链路上哪一段出问题也能自己排查。这个思路适合愿意花一晚上焊线、刷配置、看串口日志的玩家，不适合完全不想碰底层的人。

2. 搭建一套RTK定位系统的硬件清单与接线

2.1 我实际用到的物料清单

搭建一套移动站（无人机端）加一个CORS/NTRIP差分源的RTK系统，核心物料不多。UM982模组或带底板的最小系统板一块，有源GNSS天线一根（移动站单天线就够定位），如果还要测向就再加一根天线，USB转TTL串口模块一个，5V转3.3V稳压模块一个（如果用5V供电），若干杜邦线和短粗导线，再加一台机载电脑或飞控。

我建议新手直接买带底板和接口的UM982开发板，十几块钱的差价换来的却是省去手工焊接的麻烦。底板一般已经引出串口、电源接口和天线座，还有指示灯，排查问题时方便很多。天线方面，移动站常用的有源天线有两种，一种是普通有源陶瓷贴片天线，适合装在飞控附近但环境要求高；另一种是带地面金属板的测量型天线，体积大一点，但抗多路径能力强，厘米级定位建议至少用后者。

2.2 串口接线和电平匹配容易翻车

UM982的串口逻辑电平一般是3.3V，USB转TTL模块如果跳线在5V档，直接接上去就可能烧模块。接线原则是：模块的TX接USB转TTL的RX，模块的RX接USB转TTL的TX，GND必须共地。第一次上电前用万用表量一下USB转TTL模块的输出电压，确认是3.3V再动手插线。

供电也要注意。UM982正常工作电流大概几十毫安到一百多毫安，峰值出现在启动搜星和RTK解算时。从飞控或者机载电脑取电时，尽量从稳压模块输出端取，不要直接挂电池电压。我见过一个案例，有人把UM982直接接到动力电池分电板，结果一推油门定位就直接丢星，后来发现是供电纹波太大导致接收机前端饱和。正确的做法是在模块电源入口并联一个100uF电解电容和0.1uF陶瓷电容，形成简单滤波。

2.3 天线安装位置决定你能不能拿到厘米级

天线是RTK系统里最容易成为瓶颈的部件。有源天线内部的LNA（低噪声放大器）需要馈电，馈电通过天线电缆的芯线提供，所以选天线时要确认它是“有源”并且支持3.3V或5V馈电。若误接无源天线，UM982内部已经开启馈电的话，信号强度会异常，但定位效果极差。

安装位置上，天线要尽量放在机身顶部、远离碳纤维板、电机、电调和图传天线的地方。碳纤维和金属会对GNSS信号产生遮挡和反射，电机电调的高频干扰会抬高噪底，图传天线紧贴GPS天线时会让载噪比正常但RTK固定不稳定。多旋翼我通常把天线用尼龙柱抬高到飞控上方，固定翼则放在机背靠近重心处。记住一点：天线看到的天空越大，RTK固定率和精度越好。

2.4 第一次上电该检查什么

接线完成后，先用USB转TTL把模块连到电脑，打开官方上位机软件（U-Center或Unicore Control，随开发板资料包提供）。正常时软件里能看到卫星列表、信噪比柱状图，载噪比好的信号在40dB以上。如果什么都看不到，先检查串口号、波特率、接线方向和供电，其中波特率不对最迷惑人，因为模块默认9600和115200都有可能出现，输出语句不同，找不到数据时逐个试。

这个阶段不上电不要急，先确认模块自身工作正常，再谈差分链路。很多后续“不固定”的问题，根源其实是天线或串口这些基础环节，而不是RTK本身。

3. 差分数据从哪来：三种玩法按需求选

3.1 自建基准站：适合野外无网络环境

一套RTK系统除了移动站还需要差分源。自建基准站是最传统的方式：一台固定在已知坐标点的UM982或者任意可输出RTCM3的接收机，加上一套数传链路，把基准站实时生成的差分数据发送给移动站。数传可以选用大功率数传电台，频率一般是433MHz或915MHz，也可以借用4G网络走TCP/UDP。

基准站的坐标最好是精确已知的，不知道的话就让基准站连续静态采集几分钟，用平均值当近似坐标。这里有个经验：基准站坐标误差在米级以内影响不大，真正影响移动站绝对精度的是基准站绝对坐标的准确性；如果只是做相对定位，比如让无人机相对某个起降点精确落点，基准站坐标略粗略一点也能用。

3.2 网络CORS/NTRIP：省事的主流选择

自己在城市里搭建基准站不现实，因为位置不一定开阔，而且数据链容易受遮挡。我更推荐用网络RTK服务，也就是CORS站的NTRIP服务。买一个账号（很多测绘服务商有套餐），手机卡开热点，机载电脑连接网络，就能通过NTRIP协议从服务器实时拉取差分数据。市面上的千寻、移动CORS各省CORS等都属于这一类。

NTRIP的链路逻辑不复杂：客户端连上服务器，发一个请求指定挂载点（mountpoint），通过认证后服务器会持续下发RTCM3格式差分数据；同时客户端要周期性上传移动站当前GGA位置，服务器才能为该位置生成有效的改正数，通常5秒到10秒上报一次GGA。

3.3 外部注入RTCM和UM982内置NTRIP客户端的区别

UM982有两种方式接收差分数据。一种是“外部注入”模式：机载电脑通过串口把从NTRIP服务器收到的RTCM3字节流直接塞给UM982的UART，模块自己解析并进行RTK解算。这种方式链路灵活，我可以任意换差分源，还能在机载电脑里做日志记录、断线重连。

另一种是UM982内置NTRIP客户端模式：模块直接上网登录NTRIP服务器，省掉机载电脑转发。听起来更方便，但模块固件对网络栈支持有限，挂断重连、网络鉴权这些都不够灵活，我实际用下来不如外部注入稳定。所以我最终选择机载电脑（或飞控附加的计算单元）跑一个Python脚本，从网络取RTCM，再通过串口转发给UM982，控制权完全在自己手里。

3.4 固定解、浮点解、单点解必须分清楚

RTK状态直接决定定位结果的可用性，从UM982输出的GGA语句里可以读取。GGA的第6个字段是质量因子，1表示单点定位，2表示差分定位，4表示RTK固定解，5表示RTK浮点解。对厘米级来说，只要质量因子是4，也就是固定解，结果才可以用；浮点解虽然已经进入载波相位域，但模糊度没固定，误差还是亚米级；单点就更不用提了。

有一次调试，我看到脚本打印的GGA质量因子一直是5，以为差分链路有问题，查了半天才发现是移动站天线在室内窗边，头顶只有一小片天空，卫星数目不足导致模糊度一直固定不上。所以看RTK状态不要只看有没有差分数据，固定解是一个综合结果，天线环境、卫星数量、差分数据质量都会影响。

4. UM982的配置与Python代码实战

4.1 先用图形化工具把模块基本配置调好

UM982默认配置不一定满足无人机使用场景。建议先用官方上位机软件做两件事。第一，设置动态模式。模块里有静态、动态等多种场景参数，无人机必须选动态或机载模式，否则RTK解算参数不适合高动态环境，固定会不稳。第二，配置输出语句。至少要打开GGA、RMC，如果飞控需要UBX格式就同时打开UBX-NAV-PVT；如果只做定位数据转发，NMEA的GGA加RMC就够。

这套配置改完后记得保存到模块的Flash里，不然断电就丢。我习惯同时导出一份配置文件放到Git仓库，后面改了哪个参数能追查，换模组时也能直接灌回去。这里顺便说说PyCharm管理配置代码仓库的事，我所有串口脚本、配置文件和文档都放在同一个项目仓库里，用Git做版本管理，new一个Python项目时选择virtualenv环境，然后在Terminal里装上pyserial，最后把串口配置脚本和导出配置放在scripts目录下。这样做的好处是：三个月后换电脑、换模组，拉一次仓库就能恢复完整开发环境，不用靠聊天记录找配置。

4.2 用Python转发NTRIP差分数据给UM982

“外部注入”方案的代码核心分两块：一块是从NTRIP服务器拉取RTCM数据，另一块是把RTCM写入串口。下面这个脚本是我的基础版本，直接可用。

import socket import serial import time import threading NTRIP_HOST = "你的服务器地址" NTRIP_PORT = 2101 NTRIP_USER = "你的账号" NTRIP_PASS = "你的密码" NTRIP_MOUNT = "你的挂载点" SERIAL_PORT = "/dev/ttyUSB0" SERIAL_BAUD = 115200 def build_ntrip_request(): auth = base64.b64encode(f"{NTRIP_USER}:{NTRIP_PASS}".encode()).decode() req = f"GET /{NTRIP_MOUNT} HTTP/1.0\r\n" req += f"Host: {NTRIP_HOST}:{NTRIP_PORT}\r\n" req += f"Authorization: Basic {auth}\r\n" req += "User-Agent: DIY_RTK/1.0\r\n\r\n" return req.encode() def send_gga(serial_port, server_sock): while True: line = serial_port.readline() try: text = line.decode() except UnicodeDecodeError: continue if text.startswith("$GNGGA"): server_sock.sendall(text.encode()) time.sleep(5) def main(): import base64 ser = serial.Serial(SERIAL_PORT, SERIAL_BAUD, timeout=0.5) sock = socket.create_connection((NTRIP_HOST, NTRIP_PORT), timeout=10) sock.sendall(build_ntrip_request()) resp = b"" while b"\r\n\r\n" not in resp: chunk = sock.recv(1024) if not chunk: break resp += chunk print(resp.decode(errors="ignore")) t = threading.Thread(target=send_gga, args=(ser, sock), daemon=True) t.start() while True: rtcm = sock.recv(4096) if not rtcm: break ser.write(rtcm) if __name__ == "__main__": main()

这个脚本的前提是UM982的串口波特率已经通过官方工具设置成115200，且输出语句中包含GNGGA。注意NTRIP服务器返回的响应里包含ICY 200 OK，这是正常的，不是报错。我把GGA放在读串口后直接转发给服务器，保证服务器知道移动站大概位置，能下发合适的差分信号。

4.3 通过串口代码配置UM982的UBX命令

图形化工具能用，但批量生产或者远程升级时还是要脚本化配置。UM982协议规范里定义了一套配置命令，格式是CFG-VALSET或CFG-PRT等，数据帧带校验和。核心校验函数可以这样写：

def ubx_checksum(msg): ck_a = 0 ck_b = 0 for byte in msg: ck_a = (ck_a + byte) & 0xFF ck_b = (ck_b + ck_a) & 0xFF return ck_a, ck_b def build_ubx_frame(cls, msg_id, payload): msg_class = bytes([cls, msg_id]) length = len(payload).to_bytes(2, "little") msg = b"\xB5\x62" + msg_class + length + payload ck_a, ck_b = ubx_checksum(msg[2:]) return msg + bytes([ck_a, ck_b])

配置具体项时，比如设置输出语句、动态模式，需要根据协议规范中对应的配置ID来生成配置帧。因为不同固件版本的配置ID可能有差异，我建议先在官方工具里手动改一次参数，然后用工具的“生成命令”或者串口日志把帧内容导出来，保留到仓库里，以后直接用这些现成帧批量配置。这个办法比对着数十页协议文档手工扒字节快得多，也不容易错。

4.4 用PyCharm建好工程仓库，不让自己一个月后看不懂脚本

RTK项目踩坑无数，大部分时间不是花在接线上，而是花在“改了一百遍的脚本不知道哪版能跑”。我习惯在PyCharm里新建项目时直接把目录结构定下来，分几个子目录：capture存放串口原始日志，config存放UM982导出配置和NTRIP账号配置文件，scripts存放Python脚本，docs存放手册和笔记。新开的虚拟环境里强制安装pyserial和pynmea2，打包进requirements.txt，记录版本号。

把网络热词“代码仓库”落到实际流程里：串口脚本、配置脚本、NTRIP账号信息，全部纳入Git管理。注意账号信息这种敏感内容不要提交，用config.example.py占位，真实配置本地保留。这样不管是换电脑还是分享给朋友抄作业，都能直接复用整套工程结构。

4.5 配置完成后怎么确认真的生效

配置脚本跑起来后，不要直接看是否输出数据，要按照链路一条条验证。第一步，确认串口能收到GGA，并且质量因子字段有数值变化；第二步，确认NTRIP连接正常，脚本能持续打印服务端下发字节数；第三步，确认RTCM有写入串口，观察UM982上位机软件里的RTK状态是否从“单点解”跳成“浮点解”再“固定解”。固定收敛的时间一般在10秒到30秒，如果超过两分钟还是单点解，大概率是RTCM数据没有送到模块，检查串口写方向有没有接反。

5. 把UM982接入飞控和装机时最容易忽略的细节

5.1 与Pixhawk飞控的接线和参数设置

UM982接Pixhawk系列飞控很直接，模块的TX接飞控的RX，模块的RX接飞控的TX，共地。接完后需要在飞控上设置对应串口的协议，ArduPilot里是SERIAL_PROTOCOL设为5（GPS），Pixhawk的原生固件则是在参数列表里打开对应端口的GPS。GPS类型GPS_TYPE建议设为UBLOX或NMEA，取决于你在第4.1节输出的语句格式。UBX格式信息更丰富，GGA照常，飞控处理更顺。

模块的PPS（秒脉冲）引脚如果接到飞控，可以用于时间同步，对RTK和飞控数据融合有帮助，但不是必须。我前期简化就只接了TX/RX/GND，飞行效果已经能接受，后来为了做后处理才补了PPS。

5.2 双天线测向在固定翼上的应用

UM982双天线输出航向，接上第二根天线并配置基线后，模块可以输出真实航向角，替代磁罗盘。这项功能对固定翼特别有价值，因为固定翼机载磁罗盘容易受电机电流干扰，校准麻烦；双天线测向完全依赖卫星信号，没有磁偏角问题，也几乎没有磁干扰。

安装时两根天线要形成一条基线，基线越长测向精度越高。我用的安装方式是机身头部和尾部各一根天线，沿机体纵轴拉开，基线长度尽量超过30厘米。模块配置里需要告诉它基线方向和长度，或者让它自动标定。注意：天线安装不能左右对称乱摆，否则基线方向的初始对准会很乱，航向可能是反的。

5.3 供电纹波和电磁干扰对RTK固定率的影响

这个话题前面提过，但必须再展开一次。我实测中发现，UM982的RTK固定率对供电纹波极其敏感。用万用表测静态电压看不出问题，但一推油门，动态负载拉低电压，接收机前端就饱和，卫星信噪比曲线明显变差，RTK直接从固定解掉到浮点解。处理办法是给模块单独加一个低纹波LDO，并把模块的地和飞控模拟地尽量靠近，避免大电流回路穿过模块附近。

电磁干扰方面，电机电调和图传是主要来源。图传的功率信号如果与GNSS天线挨得太近，轻则定位抖动，重则直接丢星。我把图传天线放在机翼末端、GNSS天线抬高到机背最高点，实测固定率从不到70%提升到95%以上。安装时尽量让所有高频干扰源与GNSS天线保持至少一个馈线长度的距离，这是最便宜有效的抗干扰方案。

5.4 飞行前的地面和动态测试方法

装机完成后别急着飞，先做三类测试。第一类是静态对中杆测试：把移动站放在已知点上，看固定解坐标跳动是否在厘米级，记录五分钟数据，检查CE95半径。第二类是地面动态绕行测试：手持移动站绕飞场走一圈，观察固定解是否持续保持，哪些位置掉成浮点解，这些位置就是飞行时要避开的区域。第三类是装机后上电测试：电机上锁状态下看固定解，解锁但不推油再看一次，推油再看一次，三级对比能快速暴露电源问题。

6. 我的实测数据和故障排查记录

6.1 开阔环境下实测精度与收敛时间

在操场正中，天线架在1.5米三脚架上，UM982移动站连NTRIP服务器，冷启动后首次固定解耗时大约12秒，连续运行半小时固定率98%以上。统计坐标跳动，水平方向圆概率误差大概2厘米，高程误差略差，约4到5厘米。这个数据符合标称精度，也能满足绝大多数无人机DIY任务。

到了楼宇缝隙或树荫浓密处，情况明显恶化。固定解变浮点解的时间变多，严重时直接回到单点解。RTK不是随时随地都能用的技术，它的前提是至少能看到足够多的天空，天线收到的卫星信号越干净，误差消除越彻底，固定解就越稳定。

6.2 常见故障排查表

下面这些问题是DIY圈子里最常见的，也是我一个个踩出来的。

每个现象背后的根源不唯一，排查顺序建议从供电和环境开始，再到数据链路，最后再怀疑模块本身。UM982的可靠性在同类产品中算是好的，绝大多数问题出在边缘环节。

6.3 一个值得复盘的高架桥案例

有一次测试区域在高架桥辅路，一侧高楼一侧高架桥，车辆多、金属表面密集。UM982在桥下完全拿不到固定解，走出桥底后大约40秒才重新固定。这个案例说明RTK在城市峡谷环境下的边界非常明确，如果要做城市低空物流这类任务，单靠RTK不够，还需要视觉定位或者惯性导航辅助，在RTK短暂失效时保持姿态和位置的连续估计。我后来在机载电脑里加了一个简易的GPS/INS松组合滤波，用IMU数据在差分失效期间顶住几秒钟，效果提升明显。

7. 最后说几句实在话

RTK定位本身只是解决了“无人机在哪”的问题，但真正把一个厘米级定位模块用好，要把供电、天线、数据链路、飞控参数、测试方法串起来。UM982的潜力很大，配置代码和脚本一定要放进Git仓库管理，不然固件升一次级、换一次电脑，之前的调参记录就全丢了。我最近正在整理一套更完整的开源配置模板，包含UM982、Pixhawk和机载电脑的整套工程，等测完会放出来，到时候再写一篇更详细的装机说明。