Java教程

【翻译】利用 SSR信息在RTKLIB 中进行PPP解算

本文主要是介绍【翻译】利用 SSR信息在RTKLIB 中进行PPP解算,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

原文作者为rtklibexplorer,写作时间为2018年,非最近更新文章。原文地址: using-ssr-corrections-with-rtklib-for-ppp-solutions这里只是做翻译,方便自己查看记录。

If you have been following recent announcements in precision GNSS, you may have been hearing a lot about SSR (State Space Representation).  SwiftNav recently announced their Skylark corrections service, and u-blox announced a partnership with Sapcorda to provide correction service for their upcoming F9 receivers.  Both of these services are based on SSR corrections.

如果您最近一直在关注精密 GNSS 方面的公告的话,您可能已经听到了很多关于 状态空间域SSR (State Space Representation)的消息。SwiftNav 最近宣布了他们的 Skylark 校正服务,u-blox 宣布与 Sapcorda 合作,为他们即将推出的 F9接收机系列提供校正服务。这两项服务都是基于安全部门改正。

So, what is SSR?  Very briefly, it refers to the form of the corrections.  In traditional RTK with physical base stations or virtual reference stations (VRS), the corrections come in the form of observations in which all of the different error source are lumped together as part of the observation.  This is referred to as OSR (Observation Space Representation).  In SSR corrections, the different error source (satellite clocks,  satellite orbits, satellite signal biases, ionospheric delay, and tropospheric delay) are modeled and distributed separately.  There are many advantages to this form but what seems to be driving industry towards it now is that it allows the current VRS model where each user requires a unique data stream with observations tailored for their location to be replaced with a single universal stream that can be used by all observers.  This is a requirement if the technology is going to be adopted for the mass-market automotive industry for self-driving cars, since it is not practical to provide every car with it’s own data stream.

那么,什么是SSR呢?简而言之,它指的是一种校正服务形式。在传统的基于物理基站或虚拟参考站的 RTK 中,校正是以观测值的形式出现,其中所有不同的误差源集中在一起作为观测值的一部分。这被称为 观测空间域 (Observation Space Representation,OSR)。在 SSR 修正中,对不同的误差源(卫星时钟、卫星轨道、卫星信号偏差、电离层延迟和对流层延迟)分别建模。这种形式有很多优点,但是现在推动行业发展的是,在当前的 VRS 模型中,每个使用VRS的用户会根据自身的位置获取一个独特的数据流,而未来,这将被一个可供所有用户使用的单一通用流所取代。由于SSR服务不需要为每辆车提供特定的数据流,所有汽车都可以使用一样数据流,所以在不久的将来,这项技术将可能被拥有广大市场的自动驾驶汽车行业所采用。

For more detailed information on SSR, Geo++ has a one page summary here and IGS has an 18 minute video presentation on the topic here.  Both are excellent.

要了解更多关于 SSR 的详细信息,Geo + + 在这里有一页总结,IGS 在这里有一个18分钟的主题视频演示。两者都很精彩。

Below is an image I borrowed from the IGS presentation which shows the flexibility of the SSR format.  It is intended to show how the same SSR data stream can be used globally for PPP quality corrections and also regionally for RTK quality corrections but it is also a good visual for understanding the message details I describe below.

下面是我从 IGS 演讲中借来的一张图片,它展示了 SSR 格式的灵活性。它旨在说明如何在全球范围内使用相同的SSR数据流进行PPP改正,以及在区域范围内进行 RTK 校正,同时它也能很直观的帮助我们理解我接下来将要描述的内容。

The RTCM standards committee is still in the process of finalizing the messages used to send the different correction components.  They have split the work into three phases.  Phase 1 includes the satellite clock, orbit, and code biases.  Phase 2 includes satellite phase biases and vertical ionosphere corrections, and phase 3 includes ionospheric slant corrections and tropospheric corrections.

RTCM 标准委员会最近仍努力就发送不同的改正信息达成一致。他们把这项工作分成三个阶段。第一阶段包括卫星时钟、轨道和伪距偏差。第2阶段包括卫星相位偏差和天顶电离层改正,第3阶段包括电离层倾斜校正和对流层改正。

There are several real-time SSR streams accessible for free today.  Unlike the paid services, they do not contain enough detailed regional atmospheric corrections to use as a replacement for a VRS base but they can easily be used for static PPP solutions.

现在有几个实时的 SSR 数据流可以免费访问。与付费服务不同的是,它们没有包含足够详细的区域大气校正,无法用作 VRS 基地的替代品,但可以很容易地用于静态 PPP 解算。

I used the CLK93 stream from CNES for an experiment to test how well RTKLIB handled the SSR corrections.  It includes the Phase 1 and Phase 2 RTCM messages but not the Phase 3 messages.  Here is the format of the the messages in the CLK93 data stream:

我使用来自 CNES 的 CLK93流进行了一个实验,以测试 RTKLIB 如何处理 SSR 修正。它包括第1阶段和第2阶段 RTCM 消息,但不包括第3阶段消息。下面是 CLK93数据流中消息的格式:

You can register for free access to the CLK93 (and other) streams from any of these locations:

你可从以下任何一个地点免费登记使用 CLK93(及其他)资讯流:

  • USA:  美国:CDDIS and  及IGS Central Bureau 国际制药协会中央局
  • Europe :  欧洲:Bundesamt fuer Kartographie und Geodaesie 联邦军事特派团(联特派团)
  • China:  中国:The GNSS Research Center, Wuhan University 武汉大学全球导航卫星系统研究中心 and  及The ShangHai Astronomical Observatory (SHAO) 中国科学院上海天文台
  • Australia:  澳大利亚:Geoscience Australia 澳大利亚地球科学

Unfortunately, RTKLIB currently only supports the Phase 1 RTCM messages and even this is not complete in the release version.  I have gone through the code and made a few changes to make the Phase 1 SSR functional and have checked those changes into the demo5 Github repository.  I also added some code to handle the mixed L2 and L2C observations from the ComNav and Tersus receivers.  After a little more testing I plan to release this code into the demo5 executables, hopefully in the next week or two.

不幸的是,RTKLIB 目前只支持第1阶段的 RTCM 消息,即使在发行版中也不完整。我检查了代码并做了一些修改,使得第1阶段 SSR 功能正常,并将这些修改检查到 demo5 Github 存储库中。我还添加了一些代码来处理来自 ComNav 和 Tersus 接收器的混合 L2和 L2C 观测。经过一些更多的测试后,我计划将这段代码发布到 demo5可执行文件中,希望在未来一两周内完成。

With only phase 1 measurements, the RTKLIB PPP solutions will work much better with dual frequency receivers than with single frequency receivers.  This is because single frequency receivers require ionospheric corrections for longer baselines.  For this reason, I did not bother with collecting any single frequency data.  Instead, I collected both L1/L2C data with a Swiftnav Piksi Multi receiver and L1/L2/L2C data with a ComNav K708 receiver and a Tersus BX306 receiver.

只有第一阶段的测量,RTKLIB PPP 解决方案将工作得更好与双频接收机比单频接收机。这是因为单频接收机需要对较长的基线进行电离层修正。出于这个原因,我没有费心去收集任何单一频率的数据。相反,我用 Swiftnav Piksi 多接收器收集 L1/L2C 数据,用 ComNav K708接收器和 Tersus BX306接收器收集 L1/L2/L2C 数据。

RTKLIB is usually used to calculate PPP solutions without SSR corrections but this requires downloading multiple correction files for orbital errors, clock errors, and code bias errors and it is usually done with post-processing rather than real-time, after the corrections are available.  With SSR, the process is simpler because the solution can be done real-time and there is no need to download any additional files.  It does, however, require access to the internet to receive the real-time SSR data stream from an NTRIP caster.  The solution can be calculated real-time or the SSR corrections and receiver observation streams can be recorded and the solution post-processed.

RTKLIB 通常用于计算购买力平价解决方案,无需进行二次修正,但这需要下载多个修正文件,用于修正轨道错误、时钟错误和代码偏差错误,而且通常是在进行修正之后进行后期处理,而不是实时处理。使用 SSR,过程更简单,因为解决方案可以实时完成,而且不需要下载任何其他文件。然而,它确实需要通过互联网从 NTRIP 施法者那里接收实时的 SSR 数据流。该方法可以实时计算溶液,也可以记录 SSR 校正和接收机观测流,并对溶液进行后处理。

To enable the use of SSR corrections in RTKLIB, you need to set the “Satellite Ephemeris/Clock (pos1-sateph) input parameter to either “Broadcast+SSR APC” or “Broadcast+SSR CoM”.  Note that CoM stands for Center of Mass and APC for Antenna Phase Center.  They refer to the reference point for the corrections.  The CLK93 corrections are based on antenna phase centers.

为了能够在 RTKLIB 使用二次雷达修正,你需要把「卫星星历/时钟(pos1-sateph)输入参数设定为「广播 + 二次雷达平面波检测」或「广播 + 二次雷达平面波检测」。注意 CoM 代表质量中心,APC 代表天线相位中心。它们指的是修正的参考点。CLK93校正是基于天线相位中心的。

To generate my PPP solution I set the solution mode to “PPP-Static”,  ephemeris/clock (pos1-sateph) to “brdc+ssrapc”, ionosphere correction (pos1-ionopt) to “dual-freq”, and troposphere correction (pos1-tropopt) to “est-ztd”.  I also enabled most of the other PPP options including  earth tides,  satellite PCVs, receiver PCVs, phase windup, and eclipse rejection.

为了生成我的 PPP 解决方案,我将解决方案模式设置为“ PPP-static”,星历/时钟(pos1-sateph)设置为“ brdc + ssrapc”,电离层校正(pos1-ionopt)设置为“ dual-freq”,对流层校正(pos1-tropopt)设置为“ est-ztd”。我还启用了大多数其他 PPP 选项,包括地球潮汐、卫星 PCVs、接收器 PCVs、相位提升和日食拒绝。

RTKLIB PPP solutions don’t support ambiguity resolution so the ambiguity resolution settings are ignored.  I specified the satellite antenna file as “ngs14.atx” which is the standard antenna correction file and is available as part of the demo5 executable package.  I also needed to include the CLK93 data stream as one of the inputs in addition to the receiver observations (and navigation file if post-processing).

RTKLIB PPP 解决方案不支持歧义解决,因此忽略了歧义解决设置。我将卫星天线文件指定为“ ngs14.atx”,这是标准的天线校正文件,可作为 demo5可执行包的一部分使用。我还需要将 CLK93数据流作为接收器观测值(如果是后期处理,还需要导航文件)之外的一个输入。

I collected a couple hundred hours of observations with the SwiftNav receiver connected to a ComNav AT-330 antenna on my roof with moderately good sky visibility.  I then ran many four hour static solutions over randomly selected data windows.  I also collected a small amount of raw data from a ComNav K708 receiver and a Tersus BX306 receiver.

我用 SwiftNav 接收器收集了几百个小时的观测数据,这个接收器连接到我屋顶上的 ComNav AT-330天线上,天空能见度还算不错。然后我在随机选择的数据窗口上运行了四个小时的静态解决方案。我还从 ComNav K708接收器和 Tersus BX306接收器收集了少量的原始数据。

Below is a typical 12 hour static solution for a SwiftNav and a ComNav receiver.  The SwiftNav solution is in green and the ComNav solution is in purple.  Zero in these plots represents an online PPP solution from CSRS from data collected over a month earlier.  In this particular example, the SwiftNav solution is slightly better but this was not always the case.

下面是一个典型的12小时静态解决方案的 SwiftNav 和 ComNav 接收器。SwiftNav 溶液是绿色的,ComNav 溶液是紫色的。这些图表中的零代表来自 CSRS 一个月前收集的数据的在线 PPP 解决方案。在这个特定的例子中,SwiftNav 解决方案稍微好一些,但是情况并不总是这样。

Here is a shorter data set from a Tersus BX306 receiver.  With the relatively small amount of Tersus and ComNav data I collected, I did not notice any differences in convergence rates or final accuracy between any of the three receivers.

下面是来自 Tersus BX306接收器的一个较短的数据集。由于我收集的 Tersus 和 ComNav 数据相对较少,我没有注意到三个接收器之间在收敛速度或最终精度方面的任何差异。

The solutions generally all converged to less than 6 cm of error in each axis after 4 hours with one or two minor exceptions that seemed to involve small anomalies at the day boundary.  Since the RTKLIB PPP solutions don’t include ambiguity resolution they do take longer to converge but the eventual accuracy should be similar.

一般来说,解决方案在每个轴4小时后都会收敛到小于6厘米的误差,但有一两个小的例外,似乎涉及到日边界的小异常。由于 RTKLIB PPP 解决方案不包括模糊解决方案,它们确实需要更长的时间收敛,但最终的准确性应该是相似的。

I’ve uploaded some of the raw observation data for the different receivers and the CLK93 data stream as well as the config file that I used for the solution here.

我已经上传了一些不同接收器和 CLK93数据流的原始观测数据,以及我在这里用于解决方案的配置文件。

This seems like a good start and I hope that RTKLIB will support phase 2 and phase 3 corrections in the future.

这似乎是一个良好的开端,我希望 RTKLIB 将在未来支持阶段2和阶段3的修正。

WordPress.com is excited to announce our newest offering: a course just for beginning bloggers where you’ll learn everything you need to know about blogging from the most trusted experts in the industry. We have helped millions of blogs get up and running, we know what works, and we want you to to know everything we know. This course provides all the fundamental skills and inspiration you need to get your blog started, an interactive community forum, and content updated annually.

这篇关于【翻译】利用 SSR信息在RTKLIB 中进行PPP解算的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!