カテゴリーアーカイブ GPS/GNSS

著者:杉浦

様々な高さの定義

 ある地点の地上からの高さを同じ物差しでできる限り正確に測るためにいくつかの高さの定義がされてきました。この記事ではそれらを紹介します。紹介する高さは楕円体高、ジオイド高、標高(海抜)です。
 楕円体高は地球を純粋な楕円体として仮定した場合、地球楕円体と対象の地点との高さを表します。2018/08/15の日本ではGRS80地球楕円体を用いています。GNSSではWGS84地球楕円体を用いています。GRS80とWGS84のそれぞれが表現する地球はとても近く、同じものと扱っても大きな問題は起こりにくいです。GNSSの出力する高度はWGS84地球楕円体を用いた楕円体高です。GNSSを用いて現地点の地上からの標高を知るためには少し手間がかかります。
 ジオイド高はジオイドの楕円体高です。ジオイドとは、海が地球を包み、海が重力の影響のみを受けていると仮定した時、その海面が落ち着いた時に成す面のことです。近年では高精度なGNSSを用いて測量を行うことでジオイド高が求められています。ジオイド測量の概要|国土地理院
 標高はジオイドからある地点までの高さです。標高は海抜とも呼ばれます。
 三者を図解すると次の図の様になります。
 
 ジオイドとは|国土地理院から引用
 GNSSが出力する高さは楕円体高です。このため標高を求めるためにはジオイド高が必要となります。日本各所のジオイド高は国土地理院が無償で提供してくれています。
 ジオイド計算
 ジオイド・モデルの提供|基盤地図情報ダウンロードサービス※要利用登録

  • この記事いいね! (0)
著者:杉浦

UTC、UNIX時間、ユリウス通日

 システムにおいて暦の変換処理というのは往々にして面倒なものです。慣れ親しんだ近年の年月日時分秒でさえ一月の長さの違い、閏日あたりが手間です。これが縁もゆかりもなさそうなイスラム常用暦やインド国定暦になると大変です。そのような手間を省くために世界中で利用する事を目的とした暦があります。UTC、UNIX時間、ユリウス通日はそのような暦です。
 UTC(協定世界時)は世界中を対象としたシステムの基盤としてよく使われる暦です。UTCは非常に正確に時間を刻む原子時を元にしています。地球の自転一周が一日となる様に、変化する自転の周期に合わせてUTCには適宜閏秒が挿入されます。UTCを基準に世界各地の標準時、タイムゾーンなどが決められています。GPS衛星に組み込まれている原子時計もこのUTCに同期して開始されました。
 コンピュータの世界においてよく用いられる暦の単位のひとつがUNIX時間です。UNIX時間はUTC1970年1月1日0時0分0秒からの秒数で表される暦です。分も閏もありません。UNIX時間はとにかく扱いが簡単な暦です。この点からよくコンピュータシステムの内部で用いられます。ユーザに向けて表示する時点ではその時々に合った暦に変換するわけです。
 世界にはUTC1970年1月1日0時0分0秒の記録もあり、各地各時の暦はまちまちです。ユリウス通日はそのような過去の出来事を統一した日付で扱うための暦です。ユリウス通日は紀元前4713年1月1日正午からの経過日数で表されます。ユリウス通日を用いると元禄15年12月14日=グレゴリオ暦1703年1月30日の様な比較が簡単になり餡巣。
 GNSS衛星による測位には時刻が密接にかかわっています。GNSS衛星における時刻の話にはUTC、UNIX時間、ユリウス通日がよくでます。
 国立天文台の暦計算室には、この手の話が多く詳しく載っています。

  • この記事いいね! (0)
著者:杉浦

GNSS受信機が何を出力しているかGUIで見るu-center

 u-centerはGNSS受信機のメーカであるu-bloxが公開しているフリーソフトです。このソフトはGUIが便利で多機能です。受信機の位置、受け取った衛星の状態をはじめとして様々な情報を確認できます。機能の一つであるパケットコンソール、メッセージビューからはGNSS受信機がどの様な情報を出力しているかを見ることが出来ます。
 パケットコンソールは信号のプロトコルとその信号についての簡単なメッセージを見せてくれます。View->Packet Consoleから呼び出します。
 
 下図の例では、信号をファイルから読み込んで再生しています。NMEA規格とUBX規格のデータを出力しているとわかります。

 メッセージビューは直近の信号(メッセージ)に含まれる情報の意味を分かりやすく見せてくれます。View->Messages Viewから呼び出します。

 下図はGNRMCの表です。G*RMCの*は衛星の種類を示します。PならGPS、LならGLONASS、NならGNSSまとめて、といった具合です。RMCは時刻(UTC,Date)と位置情報(Lat:緯度,Lon:経度)と簡単な速度(SOG:対地速度)を表しています。

 この二つの画面でどのような信号が流れているのか大体わかります。

  • この記事いいね! (0)
著者:杉浦

RTKLIBライブラリのSTRSVRでGNSS受信機の信号データを保存する

 RTKLIBはRealTimeKinematic測位を行うことを主な目的としたライブラリです。このライブラリの中には任意の通信方式の信号を任意の通信方式の信号として転送するSTRSVRというアプリケーションが含まれています。この記事ではrtklib_2.4.2_bin.zipに入っているSTRSVRを用います。STRSVR.exeはbinフォルダ直下に入っています。これを起動すると次の様な画面が出ます。初期状態Outputがどれも暗いですが、Typeを指定することで明るくなります。

 例としてhamamatsu-gnssから配信されるテスト用移動局データをファイルに保存してみます。
 StreamのInputにテスト用移動局データを、Outputにファイルを指定していきます。TypeはInput側をNTRIP Client、Output側をFileにします。Ntrip Casterで配信されているデータはType NTRIP Clientで受け取ります。

 Input側のOptをクリックして、詳細設定をします。

 hamamatsu-gnssの下の方に記述されている通りにデータを入力します。hamamatsu-gnss.org:2101は:より前がNTRIP Caster Hostの欄に、:より後がPortの欄に入ります。

 File側のOptをクリックして、詳細設定をします。

 ファイルの保存場所を設定するのみです。…ボタンでエクスプローラを開いて指定できます。
 Startボタンで保存を開始します。Stopボタンで信号の受け取りを打ち切ります。これで保存されます。
 
 u-blox Log FileはRTK測位やu-centerをはじめとした様々なソフトウェアに用いることが可能なファイル形式です。

  • この記事いいね! (0)
takahashi 著者:takahashi

“妖怪ウォッチ”の世界が現実化!? 位置情報ARゲーム”妖怪ウォッチ ワールド”

きっとこれは妖怪のせい…(オイ
どうも、最近夏バテ気味なたかはしです。

最近、”妖怪ウォッチ”のスマホ版ゲームが出たことを知ったのですが、内容がなかなかすごかったので取り上げてみたいと思います。

その名も、”妖怪ウォッチ ワールド”

Googleアカウント(Playゲーム)でユーザー登録して早速ログイン。


唐突に妖怪ウォッチの正当な所有者に選ばれちゃいましたw


ログインすると地図が表示されます。
実際には現在地が表示されるようですが、今回はチュートリアルなので、東京某所のエリアが表示されています。

右下に妖怪ウォッチアイコンがあり、クリックすると

サーチモードに移行。

はてなアイコンなら見えましたよウィスパーさん。


了解!
タップしてみますね。


するとカメラが起動。
…何やら空間内を紫色の靄が動き回っています。

この靄を、画面中央の円内に一定時間とらえ続けないといけないようなのですが、この靄が結構すばしっこくて、思わずあたふたしてしまいましたw

なんとかとらえ続けると、この靄が招待を表し…

</a

なんとオフィス内にジバニャンが!!!
なんだかやる気満々の様子。
どうやらここでバトルが始まるようです。


この後、チュートリアルの動画が再生されるのですが、
説明してくださる方はなんと超有名な有名なあの方…!!!

一体だれが出演するのかは、是非アプリで確かめてみてくださいw

しかしバトルとは言っても、自分まだ手持ちの妖怪(?)いないっすよ…?

と思っていたら…

なんと初期の時点で仲間の妖怪が!
流石ウィスパーさん、かなり親切ですw

バトルは基本的に自動進行します。
が、仲間側の妖怪たちが状態異常になったり、体力が減ってきた場合に、控えの妖怪と入れ替えたりなどを行ってバトルを有利に進めることができます。
また、妖怪たちが持つ必殺技の発動なども、プレイヤーが行わせることができるようです。

ちなみに、妖怪に勝つと、場合によって仲間になってくれる場合もあるようです。
自分がまるで妖怪ウォッチの世界に入ってしまったかのような気分で楽しむことができますw

ちなみに、ゲームをプレイしていてふと、Pokemon Goに非常によく似ているなーと感じ、まさかNiantic社と妖怪ウォッチの版元であるLevel-5社がコラボしたのか…!?
と思ったら、なんと

パズドラ などで有名なGungHo社とLevel-5社のコラボで製作されていました…!
ただし、地図データはGoogleMapを使っているようで、地図データは完全にNiantic社系アプリと同じ情報源となっています。

今までこのタイプのゲームはほぼNiantic社しか出していないような印象で、今回初の競合他社が現れたか!?といった感じでした。

Niantic社のIngressやPokemon Goがヒットした理由として、そのゲーム性の面白さもありますが、現実世界で遊ぶことによって、ほかのプレイヤーの方々とのつながりやコミュニティ、そしてイベントの開催などによってよりコミュニケーションをとることができる”場”を提供してきたことが大きな要因となっています。

GungHo社とLevel-5社の今回の試みでも、ゲーム世界の内側外側両方で魅力を付加することができるのか。
是非注目したいですね。

妖怪ウォッチ ワールド公式サイト

  • この記事いいね! (0)
takahashi 著者:takahashi

INGRESSと伊藤園がコラボした”売らない自販機”XMProfilerで遊んでみた!

前から伊藤園は位置情報ゲームのINGRESSとのコラボレーション企画にかなり力をいれていますが、勢いのあまり、”状態が可視化されて確認できるポータル”マシンを作ってしまっています。
“XMProfiler”っていうんだけど…

ITOEN × INGRESS XM-Profiler – 面白法人カヤック
面白法人カヤックさんが作られていたんですね…!
知りませんでしたw

このXMProfiler、全国に3台(今度4台目が設置されるらしい?)しかなく、しかも首都圏に集中しているのでなかなか見る機会はなかったのですが、今回はそのうちの一台、XM Profiler OSAKA を先日たまたま機会があって実物を見ることができました!

思ってたよりも質感が凄い…
上部画面はエリアランキングやインストール済みMODなどのXMProfilerに内蔵(?)されているポータルの情報などが表示されています。


そして下部にはポータル本体とそこに刺さっているレゾネーターとその所有者の情報が。
自分のレゾネーターが刺さっているのを見ると、普段以上にしてやったぜ感が倍増しますw


現地でスクショを取り損ねてしまったので、代替えのスクショで申し訳ないですが、XMPでこうやって攻撃した際やレゾネータ等を破壊したときに、連動してXMProfilerから被攻撃音が鳴ります。普通のポータルを攻撃したときに比べて結構臨場感がありました。
これは面白いですw

単純に位置情報単体で考えるとナビのような便利ツールに流れがちですが、工夫次第でこんな面白いことができるんだなぁと考えると、ちょっと刺激になりますよね。

ちなみに…


XMProfilerはmacOSで動いているようです…w

組み込み機器でmacを使用するってなかなか珍しい気がします。
いろいろな意味でレアなXMProfilerでした。

  • この記事いいね! (0)
著者:杉浦

NMEAについてざっくり

NMEAを詳しく知りたい方のための資料として私がおすすめする資料はu-bloxの公開しているu-blox 8 / u-blox M8 Receiver Description Including Protocol Specificationのpp.105~127あたりです。このふんわりした小話よりもそちらでがっつり読み込んだ方がためになると思います。私は検索がうまくできませんでしたがtrimbleのhelpなども詳しいです。
NMEAとはGNSSの受信したデータを出力する複数のプロトコルをまとめた呼称です。NMEAは正式にはNMEA0183といい、団体であるNMEA(この記事中に出てくるこれ以外のNMEAはプロトコルNMEA0183のことを指した語です)が制定したプロトコルです。GNSS受信機はGNSS衛星から送られてきた信号を元に自らの位置などを推定しています。この推定された位置などの便利そうな情報をいい感じにまとめるプロトコルがNMEAになるわけです。ほとんどのGNSS受信機はこのNMEAに従ってデータを出力します。このNMEAには様々な種類があります。その中でも使われる頻度の高いGGA、GSA、GSV、RMCについてほんのり紹介します。実際に受信機から送られてくるデータを読んだことがある人はGGA、GSAでなく$GPGGA、$GNGSAなどの頭文字を持ってデータが送られてくることを知っているでしょう。NMEAは受信機によってGPGGA、GNGGAと頭文字が変わります。この頭文字は受信機が対応する衛星に従って付けられています。
GGAはざっくりと今の受信機の状態が分かるプロトコルです。位置、使用衛星数、精度低下率などがわかります。

$xxGGA,time,lat,NS,long,EW,quality,numSV,HDOP,alt,M,sep,M,diffAge,diffStation*cs<CR><LF>

GSAは誤差について詳しく記述されたプロトコルです。使用衛星、精度低下率について詳しく記述されています。

$xxGSA,opMode,navMode{,sv},PDOP,HDOP,VDOP,systemId*cs

GSVはGNSS Satellites in Viewの略称であり可視状態にある衛星について詳しく記述されています。

$xxGSV,numMsg,msgNum,numSV,{,sv,elv,az,cno},signalId*cs

RMCはRecommended Minimum dataとされています。RMCに大体のGPSに時刻、位置、速度といったGNSSに要求されている結果が記されています。

$xxRMC,time,status,lat,NS,long,EW,spd,cog,date,mv,mvEW,posMode,navStatus*cs
  • この記事いいね! (1)
著者:杉浦

アプリGNSS Viewについて

GNSS Viewは、指定した時間や場所におけるみちびきやGPS、GLONASSなどの測位衛星の位置を知ることができるWebアプリです。(みちびきより)
GNSS Viewというアプリを見つけましたが、技術者以外の人も対象にしているような作りのサイトで説明がろくになかったのでざっくりと機能と使えそうな用途の例の説明させてもらいます。
web版GNSSViewの全体図が下図です。

 BASE CONDITIONについてはほぼ割愛。英語が読めれば多分大丈夫です。GPS/QZSS WeeksもMaskAngle操作してみればわかるでしょう。 レーダ部を飛ばしてSELECT SATELLITE部。これはBASE CONDITIONとSELECT SATELLITEの設定でレーダー部をいじるためです。チェックボックスは衛星の種類です。自分の知りたい受信機に対応する衛星を選ぶとよいです。GPSはほぼすべての受信機で対応しています。ついでGLONASSです。GNSSを謳う受信機でしたらすべてに対応していることもあります。ラジオボタンは発信している信号の種類です。下の方ほど多種で精度の良い信号を持つ衛星になります。
 レーダー部は先に述べた通りBASE CONDITIONとSELECT SATELLITEの設定で動きます。上部のレーダは見たまま設定時点で見える衛星の配置です。色が衛星の種類を区別しています。TimeLine、Visible GNSSも見たままです。HDOP、VDOP。これはGNSSの精度低下率です。もしこの条件でGNSSによる測位を行ったら、という時の精度の目安になります。これらが0に近づくほど良好な受信環境になると予想できるわけです。なぜ実際に受信を行っていないのに、精度低下率が出せるのかというと衛星の散らばり具合によって算出しているからです。最近、3DMAPによる工事などが話題に上ったりもします。3DMAPによってマルチパス、可視衛星の精密な予測ができることによってより優れたHDOPに成り代わるものが現れるかもしれません。

  • この記事いいね! (2)
著者:杉浦

GNSSの測定する位置と速度

 前情報としてAccuracy(正確さ)、Precision(精度)の話を挟ませていただきます。誤差はランダムな誤差と規則的な誤差の二種類に分けることができます。計測、予測の世界においては下図の様にランダムな誤差の大きさをAccuracy(正確さ)、規則的な誤差の大きさをPrecision(精度)と呼びます。

 GNSSの測定する位置と速度の精度の話に入らせていただきます。GNSSから得られる情報には様々なものがあります。この中で容易に得られる成形された情報としてNMEAというフォーマットに沿った情報があります。このフォーマットの中には位置と速度が含まれています。しかしながらこの位置と速度を導き出される過程はとても異なるものとなっています。
 GNSSはGNSSはなぜ都心で精度が悪くなりやすいのかに書いた通りGNSS受信機の位置を、GNSS受信機一台と地球の衛星軌道上の人工衛星三基を結んでできる三角錐から受信機の位置を連立方程式によって解く手法によって測定しています。最近はRTK-GNSSによるcm級測位などが話題となっておりますが、この手法による誤差は10m~20mほどです。(受信環境、受信信号を用いた計算に対する工夫、他技術を交えることによって市販されている様々なGNSS受信機における実際の誤差はもっと少ないものが多いです)一方で、GNSS受信機の速度はドップラ効果から測定されます。これは信号を受け取った時点の波長と発信された時点の信号の波長のずれから速度を計算するという手法です。こちらの手法はとても精度がよく、水平速度精度0.36m/sec、垂直速度精度0.72m/secとなっています。RTK-GNSS以前からcm単位で語れる誤差があったわけです。
 一見、このドップラ効果を用いた測定された速度を積算することによって位置を推定したならばとても誤差の小さい位置の推定ができるように思えます。ここでAccuracy(正確さ)、Precision(精度)の話が出てきます。このドップラ効果によって測定された速度の誤差が小さいことは述べた通りです。しかしながら、積算のみによる位置の推定には完璧なAccuracy(正確さ)が求められてしまいます。これは上図の左下のような偏りがわずかでもあった場合、偏りが膨らみ続け大きな誤差を生むことになることが原因です。これによってドップラ効果から得られた速度の積算のみによる位置の推定には問題があるわけです。
 ネガティブな意見を述べましたが、現実にこのドップラ効果による速度は高精度であり、この高精度速度を利用して得られた位置の誤差はRTK-GNSSを用いずとも2、3m程度になります。この位置と速度を組み合わせてより正確な位置を求めることに使われている技術の主となるのがカルマンフィルタと呼ばれる技術です。カルマンフィルタはGNSSのみならず制御工学、宇宙工学、経済学などで広く使われる優れた技術です。

  • この記事いいね! (1)
著者:杉浦

GNSSはなぜ都心で精度が悪くなりやすいのか

 GNSS(Global Navigation Satellite System)/全球測位衛星システムの略称であり、GPSを含む衛星を用いた位置情報を得るシステムのことです。
GNSSについて書かれた記事:GNSS(Global Navigation Satellite System)とは
この記事はGNSS全体に共通することについての話なので、この記事の中のGNSSはGPSと読み替えても何ら問題ありません。
 スマートフォン、テレビ、ラジオを始め世の中には電波を用いて通信を行う機器が多々あります。それらは都心の様な障害物の多い中であっても良好な通信を行うことができます。GNSSはなぜスマートフォン、テレビの様に障害物の多い中で良好な通信を行うことが簡単でないのでしょうか。この原因はGNSSが位置情報を算出するには直接電波を受け取ることが重要であるという点にあります。
 GNSSの行っている計算は下図の様な地上のGNSS受信機一台と地球の衛星軌道上の人工衛星三基を結んでできる三角錐をイメージするとなんとなくわかりやすいです。

この三角錐をなす四つの点のうち、GNSS受信機の位置は未知であり、人工衛星の位置は既知であります。また、三角錐を成す辺の長さのいずれも既知であります。GNSS受信機は自身の位置を計算する時、「衛星の三点の位置と各辺の長さのみがわかる。未知である受信機の一点の位置は?」という問題を解いています。(大体このようなことをしているというイメージ程度で実際は異なります)この計算を行う時、受信機と衛星間の辺の長さをGNSSは衛星から電波が発信された時刻と受信機が電波を受け取った時刻の差によって算出しています。電波の速度はほぼ一定のため、電波の発信受信間の時間と合わせることで距離=速度×時間の式で衛星と受信機の距離を求めることができます。ここで電波が建物に遮られ、反射した電波をGNSS受信機が受け取ったと仮定します。この時、反射した電波を受け取った時刻は、反射した分、直接電波を受け取るはずだった時刻より遅れます。この時刻の遅れが前の話とつながって位置の誤差となります。そのため、直接電波が受け取れず反射した電波を受け取りやすい状況が生まれやすいビル街ではGNSSの精度が悪くなりやすいのです。

  • この記事いいね! (0)