FOSS4G Advent Calendar 2017、1日目の記事です。時間切れであまり完成度が高くないです(；´Д｀)　こめんと、ぷりーず！

1. 単周波 GPS 受信機を使った PPK 処理の奥が深かった件
～またはイノベーションに関するちょっとした悲しみ～
いわさき＠OSGeo.JP

2. １．cm 測位 GNSS へのあこがれ
GPS。というか、最近は GNSS という方がいいでしょうか。既に日々の生活の中で聞かない日はあっても、使
わない日はないと思います。特に我々のように地図スキーな人種は、当然の様にスマホの各種地図アプリを使
いますし、私のように Ingre××とかをやっている場合、GNSS のない日など考えられます。自分の場合、更に
Garmin は持ってるし、ロガーはあるし、デジ一も GPS がついてる等々･･･。出かけたときに GNSS 付きの機器
の数が片手で足りないことは、普通にあります。さすがに量で数えられる程度ではありますが（汗
さてそんな私ですが、GNSS には大ざっぱに現在位置がわかればいいやーていどで、あんまり精度は求めて
いませんでした。というか、一般に手に入るロガーよりも高い位置精度を求めるとお高い機器と、お高いソフトウェ
アが必要になります。まぁ、数 10 万から 100 万円単位かなと。ところが最近、数万円程度の受信機でこの様な
精度での測位が可能になってきました。詳しくは、トランジスタ技術 2016 年 2 月号あたりを見ていただくこととし
て、今回はお手軽価格の Reach RTK と RTK-LIB を使った Post Processed Kinematic の実例について、
紹介したいと思います。なお今更説明の必要はないかもしれませんが、RTK-LIB は東京海洋大学の高須先生
が開発されているオープンソースの GNSS 解析ソフトウェアで、日本発の FOSS4G としては、世界で最も著名
なものだと思います。
２．とりあえず、データ形式変換
さてさて、今回使用するデータは、日本時間で 2017 年 10 月 24 日 13 時 22 分から 13 時 40 分ぐらいの 20
分弱の観測データです。この間、ロガーを設置しておきました。といっても、三脚とかにつけたわけではなく、コン
クリートの杭の上に直置きでしたが（汗 この log データは、GitHub レポジトリからダウンロードできます。さてこ
のファイル、実はこのままでは PPK 処理には使えません。そこで、RTK-LIB にふくまれる RTKCONV という
プログラムを使って、ファイル形式を変換します。ちなみに、アプリの画面は以下の通り。ポイントは、Format の
部分で、u-blox を選択する事です。
さて、次に Option をおもむろにクリック。以下の通り設定します。ここでキモは「RINEX VERSION」を 3.02 と
するところです。
使用する GNSS は、GPS、GLO（グロナスのこと？）、GAL（ガリレオのことかな）、GZS（QZSS でしょ）、
SBS（SBAS だと思われ）を選択しました。ちなみに、お解りの通り動けばいいやなので、間違いも多々あるとは
思いますので、生暖かい目で見守り下さい（汗

3. で、これでコンバートを実行すると「rov_201710240428.obs」というファイルと「rov_201710240428.nav」とい
うファイルが出来上がります。これが、次のステップで位置情報に変換する元ファイルになります。
なお、RTKCONV があるフォルダに RTKPLOT を配置して、ここで PLOT をクリックすると、下図のような
GPS の DOP 情報や、天空上での位置情報を見ることができます。

4. さてこれらの図を見ると、まともに情報が取れているのが GPS 時間で 04：43，日本時間に直すと 13:43 ぐらい
までなので、以降の処理は、その時間を対象とすることします。
３．基準点データの入手
さて、RTLLIB を使った PPK の場合、基準点のデータが必要となります。
なぜ？ こちらのトプコンさんの資料をご覧下さい（汗 とにかく基準点のデータが必要なのです。日本の場合、
国土地理院さんの電子基準点データ提供サービスからそのデータの入手が可能です。取得画面は以下の様な
感じ、ここでも RINEX ver は、「ver3.02」を選択します（正確には、ここが 3.02 だったので、）。

5. １日毎のダウンロードで対象となる日を選択し、さらに、観測ファイルをダウンロードします。
ダウンロードしてできた「06272970.17o」というファイルを以下の処理では使います。
４．さあ変換だ！！
さてつぎに、RTKPOST の登場です。ここでまず、ファイルを選択する前に、Options をクリックします。まず、
Setting1 では次のように設定。この設定は、Reach RTK のページを参考にしています。

6. つづけて、Setting2 を以下のとおりに、
そして Positoin タブの Base Station を REINEX Header Postion にします。（あれ、Position じゃない？）。
OK をクリックし RTKPOST の画面に戻ったら、上から、
• rov_201710240428.obs
• 06272970.17o
• rov_201710240428.nav
を選択します。出力ファイルは、ppk01.pos としました。なお、GPS のデータ処理をする時間が決められるので、
ここでは、Time end を 2017/10/24 04:43:00 としました。
そして、Execute をクリック。Plot で結果を確認します。

7. ・・・。正直、あんまりよろしくない結果ですね。下に緑の Q=1 と黄色で 2 とあるのがキネマティック測位で FIX
解がでた場合と、Float 解がでた場合です。こうなると、あまり FIX 解が出ていないのがわかります。さてここで、
Setting2 の Interger Ambiguity Res を「Continues」から、「FIX and Hold」に変えます。
そして実行した結果が、以下です！！！！！！！！！

8. ・・・。プロットの見た目はあんまり変わりませんね。(´・ω・`)ｼｮﾎﾞｰﾝですね･･･・。が、ちょっと注目。緑の Q=1 の
割合が、「48.1%」にまで上昇しています！！！！ ここでズームアップした ppk2.pos がこちら。
同じ位置の ppk01.pos がこちら

9. 明らかに、FIX 解が増え、かなりの位置情報が 10cm 以内で測位されています！！
さて、これはなんぞやということですが、RTKLIB ver2.4.2 のマニュアルを元に作成された、GSILIB Manual
をみると、
• Continuous : スタティック整数アンビギュイティを継続的に推定して決定する。
• Fix and Hold :スタティック整数アンビギュイティを継続的に推定して決定する。もし妥当性が OK の場
合、アンビギュイティは決定値に強制的に固定される。
とあります。・・・すみません、わかりません(；´Д｀)
ということで探しところ、「夜行虫のつぶやき RTK をやってみる（手順編）」というところに、これはという回答があ
りました！ちょい長いですが引用すると
ここで重要なのは「Integer Ambiguity Res」です。Continuous は連続して FIX する解の探索を行いま
す。「Fix and Hold」は、一旦妥当と思える FIX 解が得られたら、拘束条件を強くして、あまり解が飛ば
ないようにするもののようです。受信状態が良好の場合は Fix and Hold で良いと思いますが、受信状
態があまり良くない状態でこれを選択すると、変なところで座標値が固定されてしまう恐れがあります。最
初 Continuous にしておいて、結果を rtkplot で Google Map などで確認して、問題が無ければ再度
Fix and Hold で計算するなどをすると良いかも知れません。
とのことです。つまり、一回回答が出たらその条件を使い続けるのが FIX and Hold で、解となった場所があまり
おかしくなければ、そのままにしておくのが良い、と理解しました（間違えてたら突っ込みプリーズ）。
５．Kinematic モードと Static モード！
なるほどなーとおもって、同 blog を読んでいると、
「Positioning Mode」ですが、求めようとする点が動いていない場合は「Static」で良いと思います。動い
ている場合は「Kinematic」を選択します。
との記述が。早速、Setting1 を「Static 」に変えたところ、全データの計算結果がこれだ！！！

10. FIX 解、94.4％！！！！ まさに、センチメートルの世界！！！
さてここで、ppk02.pos と比較したのが下の図。
緑が ppk03 の fix 解で青が ppk02 の fix 解です。こう見ると、同じデータであっても、GPS が動いていると仮定
いて計算する場合と、静止していると仮定して計算した場合で、測位結果が異なることがわかります。
ふ、ふかい・・・・
ちなみにですが、他の地点で取ったデータの例なのですが、GPS の固定と移動繰り返して測位した場合、
Static モードだと、FIX 解が全然出ず、Kinematic モードにしたら解が出たというばあいもありました。何故かと
悩んでいたところ、こちらのトランジスタ技術の記事が参考になりました。つまり、
• タティック測位は，1 時間程度アンテナを三脚で固定して連続観測した後，パソコンで後処理解析する
こと
• ネマティック測位は，動き回りながら連続観測し，その軌跡を求めるもの

11. とありまして、（たぶん）移動させちゃダメみたいです。
ふ、ふかい・・・・
ということで、ちょっと計算結果に偏りが出ましたが、確かに cm オーダーでの測位ができることが確認できまし
た。しかし、しかしですね。更に続きがあるのですよｗ
６．さらなる精度を求めて ～GPS Satellite Ephemerides / Satellite & Station Clocks
さて、これで十分という話もありますが、更に精度を上げるべくチャレンジします。これは、GPS の正しい軌道
（最初の計算の際は、予測軌道で計算している）と、時間に基づく補正を加えることです。すみません、時間の方
は、どういう意味があるのか、ちょっとわかりませんでした(；´Д｀)
さておき、sp3 というファイルと clk というファイルをこの辺から取ってきます。ファイルの命名規則は、GPS 精密
暦を参考にして、GPS 時間の算出はこちらのページをご利用下さい。今回は、「igs19722.clk」と
「igs19722.sp3」というファイルを使いました。設定は以下で、出力は ppk04.pos としました。

12. ・・・かわらない(^_^;
うーん、拡大すると精密度は上がっているのですが、逆に FIX 解が減っています。なぜだろ？うん、他の場所で
やったらかなり良くなったのですが、それは Kinematic モードを使っていた場合のようです。
ということで、何となくもやもやするのですが、今回は時間切れということで、ここまでです。
７．最後に
さて、この GPS 受信機、というか販売セット、何となくロシア製のようです。中は intel のエジソンと、u-blox の
チップセットです。で、ソフトは日本製なんです。
・・・。高須先生には FOSS4G 2009 Tokyo でご講演いただきました。確かに、u-blox のチップ他で他の最近と
いう話もあるかもしれませんが、なんでこんなにいいソフトがあるのに、日本国内であまり使われないのでしょうか。
国土地理院さんが使われているのは知っているのですが、もっと早く、こういう製品が、日本国内で生まれなかっ
たのでしょうか。これだけの精度が、安価な機器とオープンソースソフトで提供できれば、きっと色々なサービス
が生まれたはず･･･。
何となく、凄く大きなイノベーションの種があったのに、上手く開花しなかったように感じました。もったいない
なぁ。
上で処理が上手くいかなかったことも含め、何となくもやもやした気分になって終わるのでした。
おしまい。
（というか、時間切れ。仕事に戻る）