第七篇：RTK + 地图 + 机器人：完整定位系统架构解析
上一篇我们讲了：
《Android / IoT 如何接入 RTK 模块？——串口、蓝牙、TCP 工程实践》
很多人已经知道：
RTK 模块会输出 NMEA
Android / IoT 可以通过串口、蓝牙、TCP 接收数据
上层系统需要解析经纬度、Fix 状态、卫星数量、HDOP
但问题来了：
拿到 RTK 经纬度之后，机器人就能正常跑了吗？
答案是：还远远不够
因为真实机器人需要的，
不是单纯的：
经度
纬度
而是：
我在哪里？
我朝哪个方向？
我有没有越界？
我该往哪里走？
我能不能继续运动？
所以：
RTK 只是定位系统的入口。
真正的机器人定位系统，
一定是：
RTK + 地图 + 围栏 + 路径规划 + 控制系统
共同工作。
今天这一篇，我们就从工程视角，真正讲透：
RTK 在机器人中的完整系统架构
一、先理解一个核心问题
很多人第一次做机器人定位时，容易把问题想简单。
他们以为：
RTK 输出经纬度
↓
地图上显示一个点
↓
机器人就能跑
但真实工程不是这样。
因为机器人真正需要的是：
可用于控制的位姿
也就是：
x
y
heading
speed
status
而不仅仅是：
latitude
longitude
二、为什么经纬度不能直接给机器人用？
因为经纬度是地理坐标。
例如：
经度：120.123456
纬度：31.123456
它表示的是：
地球上的位置
但机器人运动控制更关心：
向前多少米
向左多少米
距离边界多少米
距离目标点多少米
这些都是：
平面坐标问题
所以在真实工程中，通常需要把经纬度转换成：
局部地图坐标
例如：
x = 12.5m
y = 8.3m
这样机器人才能真正使用。
三、机器人最终需要的不是 Location，而是 Pose
这是一个非常关键的工程认知。
普通定位系统关心：
Location
也就是：
在哪里
但机器人系统关心：
Pose
也就是：
在哪里 + 朝向哪里
通常表示为：
Pose = (x, y, theta)
其中：
- x：地图坐标 X
- y：地图坐标 Y
- theta：机器人朝向角
所以：
RTK 解决的是位置问题
但：机器人还需要朝向问题
这也是为什么 RTK 通常会结合：
- IMU
- 电子罗盘
- 双天线 RTK
- 编码器
- 轮速计
一起使用。
四、完整定位系统长什么样？
真实机器人系统中，
完整链路通常是：
RTK 模块
↓
NMEA 定位数据
↓
定位数据解析
↓
定位质量判断
↓
坐标转换
↓
地图坐标
↓
电子围栏判断
↓
路径规划
↓
运动控制
↓
机器人执行
如果有多传感器融合，
还会加入：
IMU
编码器
轮速计
SLAM
激光雷达
最终输出：
机器人当前位姿 Pose
五、第一层：RTK 数据接入层
这一层就是前面第六篇讲的内容。
RTK 模块通过：
- 串口
- 蓝牙
- USB
- TCP
不断输出：
NMEA 数据
例如：
$GNGGA,...
$GNRMC,...
上层系统负责：
读取数据流
解析 NMEA
提取经纬度
提取 Fix 状态
提取卫星数量
提取 HDOP
这一层的目标是：
拿到原始定位数据
六、第二层：定位质量判断层
拿到经纬度之后，不能直接用。
必须判断：
这条定位数据是否可信
因为 RTK 会出现：
- 无定位
- 普通 GPS
- Float
- Fix
- 跳点
- 数据超时
- 卫星数量不足
所以系统必须做过滤。
常见判断指标
通常包括：
Fix 状态
卫星数量
HDOP
时间戳
位置连续性
速度是否异常
例如：
如果当前状态是：
RTK_FIX
说明可信度高。
如果是：
RTK_FLOAT
说明精度下降。
如果是：
GPS
NONE
就不能作为高精度定位使用。
七、第三层：坐标转换层
这是很多 Android / IoT 开发容易忽略的地方。
RTK 输出的是：
WGS84 经纬度
但地图系统和机器人控制，通常需要：
平面坐标
例如：
x
y
所以需要坐标转换。
常见坐标体系
工程里经常会遇到：
WGS84
GCJ-02
BD-09
UTM
ENU
局部地图坐标
简单理解
WGS84：
卫星定位原始坐标
GCJ-02：
国内地图常用坐标
BD-09：
百度地图坐标
ENU / 局部坐标：
机器人内部使用的平面坐标
八、为什么机器人更适合用局部坐标？
因为机器人运动控制，通常关心的是：
距离
角度
方向
边界
路径
例如：
目标点在前方 3 米
边界在左侧 0.5 米
机器人需要右转 15 度
这些都不适合直接用经纬度算。
所以真实机器人里，通常会定义一个地图原点：
originLat
originLng
然后把 RTK 经纬度转换成：
x
y
最终机器人内部使用：
局部地图坐标系
九、第四层：地图系统
定位数据进入地图之后，
地图系统要负责：
显示机器人位置
管理边界
管理禁区
管理路径点
管理任务区域
比如割草机器人：
地图中可能包含：
- 草坪边界
- 禁区
- 充电桩位置
- 起点
- 路径
- 已完成区域
- 未完成区域
所以：
RTK 只是告诉系统：
机器人在哪里
地图系统还要知道：
这个位置属于哪里
十、第五层：电子围栏判断
第四篇我们讲过：
电子围栏的核心是：
Point-In-Polygon
也就是：
判断机器人当前位置是否在多边形区域内
在完整系统中，
它通常位于：
定位系统
↓
地图系统
↓
电子围栏判断
↓
运动控制
如果机器人当前位置：
不在允许区域内
系统就要：
- 停止
- 回退
- 告警
- 重新规划
所以：
RTK 负责定位
PIP 负责判断是否越界
十一、第六层：路径规划
当系统知道机器人当前位置后，
下一步就是：
规划机器人怎么走
比如：
- 从当前位置到目标点
- 沿边界行走
- 覆盖整个草坪
- 绕开禁区
- 返回充电桩
路径规划需要不断读取：
当前位姿
目标点
地图边界
障碍物
任务状态
然后输出：
下一步运动方向
所以：
定位数据是路径规划的基础。
没有稳定定位，路径规划也无法稳定。
十二、第七层：运动控制
路径规划告诉机器人：
应该往哪里走
但真正执行动作的是：
运动控制系统
它会控制：
- 电机
- 轮子
- 转向
- 速度
- 刹车
例如：
向前 0.5m
右转 20°
减速
停止
回退
这时候定位系统会持续反馈：
机器人当前是否到达目标点
有没有偏离路径
有没有越界
形成一个闭环。
十三、完整闭环是什么？
机器人不是一次性拿到位置就结束。
而是一个实时闭环：
获取当前位置
↓
判断定位质量
↓
更新地图位置
↓
判断是否越界
↓
计算下一步路径
↓
控制机器人运动
↓
再次获取当前位置
这个过程会一直循环。
所以：
机器人定位系统是实时系统
不是普通 App 里显示一个定位点那么简单。
十四、为什么 RTK + 地图容易出问题？
真实工程中，很多问题并不是 RTK 单独导致的。
而是：
RTK、地图、坐标系、控制系统之间没对齐
常见问题包括：
1. 坐标系不一致
RTK 是 WGS84。
地图可能是 GCJ-02。
机器人内部又是局部坐标。
如果没转换对，地图上的点就会偏。
2. 地图原点错误
如果局部坐标原点设置错了，所有点都会整体偏移。
3. 朝向不准
RTK 只能提供位置。
如果 heading 不准，机器人会出现：
位置对了
但方向错了
最终路径还是会偏。
4. 定位延迟
如果 RTK 数据延迟，机器人看到的是：
过去的位置
而不是真实当前位置。
这会导致控制滞后。
5. 跳点没有过滤
如果 RTK 突然跳出 10 米，
地图直接使用，
机器人可能立刻误判越界。
所以必须做跳点过滤。
十五、为什么需要 RTK + IMU 融合？
RTK 的优点是：
全局准
但缺点是：
容易受遮挡和网络影响
IMU 的优点是：
短时连续
响应快
但缺点是：
时间长了会累积误差
所以二者结合：
RTK 负责长期校准
IMU 负责短时稳定
这就是工程里常说的：
多传感器融合
十六、真实机器人里的定位架构
真实工程里，
完整架构可能是：
RTK 模块
IMU
编码器
轮速计
↓
定位融合模块
↓
Pose(x, y, theta)
↓
地图系统
↓
电子围栏
↓
路径规划
↓
运动控制
↓
机器人执行
这个架构才是机器人真正需要的。
不是单纯：
拿一个经纬度
十七、Android / IoT 里怎么设计这套架构？
如果上层是 Android，
可以这样分层：
RtkDataSource
↓
RtkRepository
↓
LocationEngine
↓
MapEngine
↓
FenceEngine
↓
NavigationEngine
↓
RobotController
RtkDataSource
负责：
串口 / 蓝牙 / TCP 数据读取
RtkRepository
负责：
NMEA 解析
状态维护
异常处理
LocationEngine
负责：
定位质量判断
跳点过滤
数据超时判断
坐标转换
MapEngine
负责：
地图坐标
边界
禁区
路径点
FenceEngine
负责：
Point-In-Polygon 判断
越界检测
NavigationEngine
负责：
路径规划
目标点计算
任务状态
RobotController
负责：
运动控制
停止
转向
速度控制
十八、推荐的数据模型
上层不应该直接传 NMEA 字符串。
而应该传统一模型。
例如：
data class RobotPose(
val x: Double,
val y: Double,
val heading: Double,
val speed: Double,
val fixType: FixType,
val satelliteCount: Int,
val hdop: Double?,
val timestamp: Long,
val isReliable: Boolean
)
这样地图、围栏、路径规划都可以统一使用。
十九、定位状态应该怎么设计？
真实工程中，定位状态必须明确。
例如：
enum class LocationStatus {
NONE,
GPS,
RTK_FLOAT,
RTK_FIX,
DEGRADED,
LOST
}
这样系统才能根据状态做决策。
例如：
RTK_FIX
→ 正常运行
RTK_FLOAT
→ 降速运行 / 提醒风险
LOST
→ 停止运动 / 等待恢复
不能所有状态都当成正常定位。
二十、机器人遇到定位异常怎么办？
这是工程里非常关键的一点。
机器人不能盲目相信定位。
如果定位异常，系统应该有降级策略。
常见策略
1. RTK Fix 正常
机器人正常运行。
2. RTK Float
可以：
- 降速
- 缩小动作范围
- 提醒定位精度下降
- 结合 IMU 短时运行
3. 无定位
应该：
- 停止运动
- 等待恢复
- 告警
- 进入安全模式
4. 跳点异常
应该：
- 丢弃异常点
- 使用上一帧可信位置
- 等待连续稳定数据
二十一、为什么这是系统架构问题？
很多人以为：
RTK 问题就是：
模块问题
其实不是。
真实工程中，RTK 定位稳定性，取决于整个系统：
硬件
天线
差分
网络
协议
解析
坐标转换
地图
围栏
规划
控制
任何一层出问题，机器人都会表现为：
定位不准
路径偏移
越界
跳点
回充失败
所以：
RTK 不是单点技术
而是：
机器人定位系统工程
二十二、面试怎么回答？
如果面试官问：
“RTK 在机器人系统里是怎么工作的？”
推荐回答：
标准答案（面试版）
RTK 在机器人系统中，通常不是单独使用的。
它首先通过串口、蓝牙或 TCP 输出 NMEA 定位数据。
上层系统解析经纬度、Fix 状态、卫星数量、HDOP 等信息。
然后进行定位质量判断，过滤跳点和过期数据。
接着把 WGS84 经纬度转换成机器人内部使用的局部地图坐标。
地图系统根据当前位置更新机器人位置，电子围栏通过 Point-In-Polygon 判断是否越界。
路径规划模块根据当前位姿和目标点计算下一步路径。
运动控制模块再控制机器人执行。
真实工程中，RTK 通常还会融合 IMU、编码器、轮速计或 SLAM，
最终输出稳定的机器人位姿：
Pose(x, y, theta)
所以 RTK 只是定位系统的一部分，
完整机器人定位系统本质上是：
RTK + 传感器融合 + 地图 + 围栏 + 规划 + 控制
二十三、总结
一句话总结：
RTK 负责“知道机器人在哪里”
地图负责“知道环境是什么样”
电子围栏负责“判断能不能过去”
路径规划负责“决定怎么走”
控制系统负责“让机器人真正动起来”
所以：
真正的机器人定位系统，
不是：
RTK 输出经纬度
而是：
RTK
+ 坐标转换
+ 地图系统
+ 电子围栏
+ 路径规划
+ 运动控制
共同组成的工程闭环。
二十四、系列最终总结
到这里，
《RTK / GNSS 工程实战系列》基本就形成闭环了。
从最开始的：
为什么机器人能厘米级定位
到：
RTK 为什么比 GPS 准
再到：
为什么 RTK 会漂
再到：
电子围栏
数据链路
Android / IoT 接入
完整系统架构
这一整套下来，
你会发现：
RTK 并不是一个孤立知识点。
它连接的是：
GNSS
差分定位
数据协议
Android / IoT
地图系统
机器人控制
多传感器融合
所以最终目标不是成为：
GNSS 算法专家
而是成为：
懂 RTK 系统的 Android / IoT / 机器人工程师
这才是这个系列真正的定位。
《RTK / GNSS 工程实战系列》
- 为什么机器人能厘米级定位？——一篇讲透 GPS、北斗 与 RTK
- RTK 为什么比 GPS 准？——差分定位原理详解
- 机器人为什么会“漂”？——RTK 漂移问题详解
- Point-In-Polygon 是什么？——机器人电子围栏核心算法
- NMEA、RTCM、NTRIP 到底是什么？——RTK 数据链路详解
- Android / IoT 如何接入 RTK 模块？——串口、蓝牙、TCP 工程实践
- RTK + 地图 + 机器人：完整定位系统架构解析
DAMO开发者矩阵，由阿里巴巴达摩院和中国互联网协会联合发起，致力于探讨最前沿的技术趋势与应用成果，搭建高质量的交流与分享平台，推动技术创新与产业应用链接，围绕“人工智能与新型计算”构建开放共享的开发者生态。
更多推荐
3
0- 0
已为社区贡献6条内容
所有评论(0)