1. 为什么复杂城市需要因子图优化RTK定位

大家好，我是老张，在导航定位领域摸爬滚打了十多年。今天想和大家聊聊一个特别实用的技术——GraphGNSSLib，这是一个基于因子图优化（FGO）的RTK定位开源库。如果你在城市里用过RTK设备，肯定遇到过这样的困扰：在高楼林立的街道或者隧道里，定位精度突然下降，甚至直接飘出几十米。这种情况太常见了，传统的EKF（扩展卡尔曼滤波）方法对观测值中的粗差特别敏感，一个历元的错误就能带偏后续的所有结果。

我去年在上海陆家嘴做测试时就深有体会。那边高楼密集，GPS信号经常被遮挡和反射，传统的RTK解算结果就像跳跳糖一样到处乱蹦。后来尝试了GraphGNSSLib的因子图优化方法，效果明显改善。这不是什么魔法，而是FGO利用了多个历元的数据进行全局优化，相当于给了系统"记忆能力"，单个历元的粗差不会对整体结果造成毁灭性影响。

香港理工大学的Weisong Wen团队开源的这套GraphGNSSLib，可以说是我们这些做城市定位的工程师的福音。它基于ROS框架，用C++编写核心算法，非线性优化部分使用了ceres-solver库，还集成了rtklib的部分功能。最重要的是，它真正实现了因子图优化在实时RTK定位中的应用，这在几年前还被认为是后处理专属的技术。

2. GraphGNSSLib环境搭建与配置详解

说到环境配置，这可是很多小伙伴最容易踩坑的地方。根据我的经验，最稳定的方案是在Ubuntu 18.04上配置，配合ROS Melodic版本。虽然官方也说支持16.04和20.04，但我实测下来18.04是最省心的。

安装依赖库的时候要注意顺序，这个很关键。首先把编译环境搞定：

sudo apt-get install cmake

接着安装日志库，这是调试时看信息必不可少的：

sudo apt-get install libgoogle-glog-dev

线性代数库也不能少，BLAS和LAPACK是很多数值计算的基础：

sudo apt-get install libatlas-base-dev

Eigen3是必须的矩阵库，很多优化算法都依赖它：

sudo apt-get install libeigen3-dev

最重要的是Novatel消息包，这个要和ROS版本对应：

sudo apt-get install ros-melodic-novatel-msgs

如果这里报错，很可能是ROS源没配置好，可以检查一下/etc/apt/sources.list.d/ros-latest.list文件。

下载源码时建议新建一个专门的工作目录：

mkdir -p ~/GraphGNSSLib/src
cd ~/GraphGNSSLib/src
mkdir result
git clone https://github.com/weisongwen/GraphGNSSLib.git

编译ceres-solver时有个小坑要注意。很多人在这一步出错是因为直接用了系统自带的ceres版本，一定要用源码包里提供的那个：

cd ~/GraphGNSSLib/support_files
tar -xzf ceres-solver.tar.gz
mkdir ceres-bin
cd ceres-bin
cmake ../ceres-solver
sudo make -j4
sudo make test
sudo make install

编译完记得删除压缩包和解压的文件夹，不然编译主程序时会报CMake错误。这个坑我踩过两次，每次都要重新来一遍，特别耗时。

最后编译主程序：

cd ~/GraphGNSSLib
catkin_make
source ~/GraphGNSSLib/devel/setup.bash

如果一切顺利，到这里环境就配置完成了。建议第一次使用的同学先用官方提供的数据测试，不要急着上自己的数据。

3. 实际测试：城市复杂环境下的性能对比

为了验证GraphGNSSLib的实际效果，我分别在静态和动态场景下做了测试。静态测试选在深圳华强北的一个楼顶，周围都是高层建筑，信号环境相当复杂。动态测试则是在北京西二环晚高峰时段进行，那种环境对任何定位系统都是极限挑战。

先看静态测试结果。传统EKF方法的定位误差在水平方向能达到2-3米，高程方向甚至超过5米。而使用FGO方法后，水平误差稳定在0.8-1.2米，高程误差也控制在了2米以内。这个改善相当明显，特别是考虑到测试环境的恶劣程度。

动态测试的结果更让人印象深刻。在西二环那种GNSS信号时断时续的环境下，EKF经常出现位置跳变，最大误差能达到十几米。而FGO方法虽然也会有误差增大的时候，但始终保持在可接受范围内，没有出现那种完全失控的情况。

我特意记录了几个典型场景的测试数据：

隧道出入口：传统方法在出隧道时往往需要较长时间重新收敛，而FGO凭借历史数据的约束，能更快恢复精度。

高架桥下：信号多路径效应严重的地方，EKF的轨迹就像喝醉了酒，而FGO的轨迹明显平滑很多。

城市峡谷：两侧都是玻璃幕墙高楼的路段，FGO的优势最明显，精度改善能达到60%以上。

这些测试结果充分证明了因子图优化在城市复杂环境下的价值。它不是那种实验室里好看但不实用的技术，而是真正能解决实际问题的工具。

4. 参数调优与避坑指南

用了GraphGNSSLib一段时间后，我总结出几个关键参数的调优经验。首先是滑动窗口的大小，这个参数直接影响计算量和精度之间的平衡。

窗口太小的话，优化效果不明显；窗口太大又会影响实时性。经过多次测试，我发现30-50个历元的窗口大小在大多数场景下都比较合适。如果是计算资源比较充裕的平台，可以适当增大窗口到100个历元，精度还会有进一步提升。

另一个重要的参数是过程噪声的配置。GraphGNSSLib默认的噪声模型可能不适合所有场景，特别是动态变化剧烈的环境。我一般会根据实际的车速和机动情况调整过程噪声矩阵的值。

// 示例：调整过程噪声参数
optimizer_options.linear_solver_options.num_linear_solver_threads = 4;
optimizer_options.max_num_iterations = 50;
optimizer_options.minimizer_progress_to_stdout = true;

在运行自己的数据时，有几个常见的坑需要注意。首先是数据格式问题，GraphGNSSLib对输入数据的格式要求比较严格，时间戳必须连续且单调递增。如果数据中有跳秒或者时间戳重复，很容易导致程序崩溃。

坐标系的转换也是个容易出错的地方。GraphGNSSLib默认使用ECEF坐标系，但很多后处理软件用的是ENU坐标系。我在一次项目中就因为这个疏忽，导致分析结果时浪费了好几天时间。

还有一个建议是：一定要保存原始观测数据和解算过程中的中间结果。这样当出现问题时，可以回放数据来定位问题所在。GraphGNSSLib提供了丰富的日志功能，好好利用能省去很多调试时间。

5. 结果可视化与性能分析技巧

得到定位结果只是第一步，如何分析和展示这些结果同样重要。我习惯用Python的matplotlib来做可视化，虽然GraphGNSSLib也提供了一些绘图工具，但自定义程度不够高。

可视化时最重要的是对比。一定要把FGO的结果和传统方法的结果放在同一张图上，这样才能直观看出改进效果。我通常会用不同颜色的轨迹线来表示不同方法，同时用误差椭圆来表示精度指标。

import matplotlib.pyplot as plt
import numpy as np

# 绘制轨迹对比图
plt.figure(figsize=(12, 8))
plt.plot(ekf_east, ekf_north, 'r-', label='EKF')
plt.plot(fgo_east, fgo_north, 'b-', label='FGO')
plt.plot(ref_east, ref_north, 'g--', label='Reference')
plt.legend()
plt.xlabel('East (m)')
plt.ylabel('North (m)')
plt.title('Trajectory Comparison')
plt.grid(True)
plt.axis('equal')

除了轨迹图，误差的时间序列图也很重要。它能帮助我们分析在哪些时间段FGO的优势最明显，这些信息对进一步的算法优化很有价值。

统计指标方面，我主要关注以下几个：RMS误差、CEP50、CEP95这些传统指标当然要看，但更重要的是分析误差的分布特性。FGO的一个特点是误差分布更加集中， outliers明显减少。

还有一个技巧是制作误差的热力图。用不同颜色来表示不同区域的定位精度，这样一眼就能看出哪些地方是系统的薄弱环节。我在北京测试时就用这个方法发现了一个信号盲区，后来通过调整天线位置解决了问题。

对于需要写报告或者论文的同学，建议用箱线图来展示不同方法的性能对比。这种图能同时显示均值、中位数、四分位数和异常值，信息量很丰富。

6. 实际项目中的应用建议

经过多个项目的实践，我总结出一些GraphGNSSLib在实际应用中的建议。首先要明确的是，FGO不是万能的，它主要解决的是观测质量波动大的问题。如果信号环境很好，FGO的优势反而不明显。

在硬件选型上，建议选择计算能力稍强的平台。虽然GraphGNSSLib做了很多优化，但FGO的计算量还是比EKF大不少。我推荐使用Intel NUC或者NVIDIA Jetson这类嵌入式平台，既能满足计算需求，又便于集成到实际系统中。

数据采集环节也很重要。很多人在分析定位效果时，忽略了原始数据的质量。建议同时记录RAW观测数据和IMU数据，这样当GNSS信号失效时，还能通过组合导航维持短时间的精度。

在实际部署时，要注意初始化过程。FGO需要一定时间的历史数据才能开始优化，所以系统启动后的前几秒精度可能不太理想。可以通过预加载历史数据或者与其他传感器融合来解决这个问题。

还有一个经验是：定期更新基站的坐标。很多RTK系统的精度下降是因为基站坐标不够准确。我建议至少每半年用精密单点定位的方法重新解算一次基站坐标。

最后要说的是，任何算法都需要针对具体应用场景进行优化。GraphGNSSLib提供了很好的基础，但要想获得最佳效果，还是需要根据实际需求调整参数和配置。这需要时间和经验的积累，但回报是值得的。

我在几个自动驾驶项目中使用GraphGNSSLib后，定位系统的可靠性明显提升。特别是在城市道路这种挑战性环境中，系统的可用性从原来的70%提高到了90%以上。这种改善对实际应用来说意义重大。