|
日記・備考録 |
2005 | 2006 | 2007 | 2008 | 2009 | 2010 | 2011 | 2012 | 2013/ 1 2 3 4 5 6 7 8 9 10 11 12 | 2014 |
| February | March 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
April | Home |
...................................................................................................................................
The formal manual of RTKLIB 2.4.2 is now available at RTKLIB document page.
The release of RTKLIB 2.4.2 itself is delayed until the middle of April. Sorry for your long waitting.
...................................................................................................................................
パブリックコメント: 結果公示案件詳細
「準則」改訂のパブコメ。
> 準天頂衛星利用について、精度検証について更なる検証が必要である状況、受信機及び解析ソフトとも対応
> するメーカーが無い状況、RINEX やRTCM
などの標準フォーマットが規定されていない状況での規定は時期
> 尚早と思われます。
回答。
> オープンソースの解析ソフトウェアRTKLIBを用いてGPSと準天頂衛星システムの観測データを処理し、所定
> の精度が出ることを確認しています。技術的には準天頂衛星システムとGPSを併用した測量が可能です。
特定の異機種受信機間の基線解析で問題が発生することは確認済みで「時期尚早」というのは個人的には同意。
補足: 問題は、QZSS-GPS間バイアスいわゆるISBが大きい受信機があること。そのために異機種間基線でQZSS-GPS間アンビギュイティが正常に解けない。QZSS-GPS間差使えないとすると、QZSS 1機しかないので殆ど解改善に寄与しない。すなわち基線解析においては「GPS補完」にならないということ。まあバイアスなので適当な校正手順があればなんとかなるし、時間がたてば受信機側も対応してくる可能性は高い。ただ実用に使うためにはまだ色々な知見が不足している。やはり「時期尚早」だろうと思う。(3/30追記)、
-------------------------------------
NEC, 豊かな未来へ導く宇宙からの道しるべ, 準天頂衛星システム, 平成25年3月29日
ということで、峰さんのインタビュー復活。
-------------------------------------
RTKLIB 2.4.2のリリース準備。(UTCで) 3月一杯までになんとか。
-------------------------------------
内閣府, 準天頂衛星システムの運用等事業の民間事業者の選定及び事業契約の公表について, 平成25年3月29日
内閣府, 準天頂衛星システム衛星開発等事業の民間事業者の選定について, 平成25年3月29日
ようやく決まった様で。総合設計, 地上系及び運用は準天頂NECグループが設立したPFI SPC, 準天頂衛星システムサービスで20年, 約1200億円。衛星系は三菱電機で4年, 約500億円。宇宙戦略室の皆様ご苦労様でした。
-------------------------------------
IGSのリアルタイム軌道・クロックサービス (RTS) が、3月末にIOC (initial operational capability) 宣言され、正式プロダクトしてローンチするとのこと。パイロットプロジェクト (RTPP) の開始から約12年、長い期間に渡っての関係各位の努力に敬意を表する。本件、BKGのGeorg Weberから直接連絡貰った。
...................................................................................................................................
GPS World, Real-time PPP with Galileo Demonstrated by Fugro, March 26, 2013
多分、水平1-2cm、垂直3-4cm RMS位だと思うのだけど、Seastar G2ってこんなに精度出るんだ。周回遅れにならない様に頑張ってるつもりなのだけど、なんか結局追いつけない気がしてきた。
...................................................................................................................................
測位航法学会ニュースレターで紹介されている、古野電気の新しいGNSS受信機チップ eRideOPUS 7。正式発表はまだの様だが、内容転載してしまおう。2013年発表予定で、主な仕様は、
> マルチGNSS: GPS, GLONASS, QZSS, Galileo,
SBAS
> 追尾感度: -161dBm
> 更新レート: 1/5/10 Hz
> TTFF: 1秒以下 (ホットスタート)
> エフェメリス: 3日先まで予測
> 自律航法: 3種類のセンサ組合せに対応
とのこと。long-term ephemeris入れるのやっぱり最近の流行りなのかなあ。いずれにしても頑張ってほしい。
補足: 正式発表来た (→参照)。同時にeRideOPUS6という機種も発表。(3/28追記)
...................................................................................................................................
SPAC, 特別セミナー - 準天頂衛星システムの利用推進に係わる期待と課題, 平成24年3月11日
先日の特別セミナーの講演資料が公開されている。面白い講演が多かった様。特に自動車自動運転系の技術動向は現在の興味の対象に近く、とても興味深かった。
...................................................................................................................................
とかく時刻系は難しい。3/20に書いたsatellite clock biasのrelativity correctionも、実は仕様が曖昧な点があって、cm級補正にはインフラ側、ユーザ側双方で注意深い実装が必要。まあ、結局双方別々に実装するとなかなか精度出ないよ、ということなのだけど。
-------------------------------------
3/5に、「現在のQZSSのQZSST-UTCパラメータは、GPSのGPST-UTC(USNO)パラメータを再送信している」と書いてしまったのだけど、実際には異なるパラメータが送られているはず、とご指摘を頂いた。(QZ-visionのRINEX QNAVのUTCパラメータが一致しているのは、RINEXコンバータのバグらしい?)。ということで古いデータしか手元にないのだけど、2011/07/05のJavad受信機のデータをRTKCONV 2.4.2でRINEX 3.02に変換。
3.02 N: GNSS NAV DATA M: Mixed RINEX VERSION / TYPE
RTKCONV 2.4.2 20130323 222506 UTC PGM / RUN BY / DATE
log: D:\data\qzss\20110705\javad1_201107050000.jps COMMENT
format: Javad COMMENT
GPSA 4.6566E-09 1.4901E-08 -5.9605E-08 -1.1921E-07 IONOSPHERIC CORR
GPSB 8.1920E+04 8.1920E+04 -6.5536E+04 -5.2429E+05 IONOSPHERIC CORR
GAL 0.0000E+00 0.0000E+00 0.0000E+00 0.0000E+00 IONOSPHERIC CORR
QZSA 1.3970E-08 -6.7055E-08 5.9605E-08 -5.9605E-08 IONOSPHERIC CORR
QZSB 6.3488E+04 7.7005E+05 -5.8982E+05 -8.3886E+06 IONOSPHERIC CORR
GPUT -4.6566128731E-09-6.217248938E-15 405504 1643 TIME SYSTEM CORR
GAUT 0.0000000000E+00 0.000000000E+00 0 0 TIME SYSTEM CORR
QZUT -7.4505805969E-09 8.881784197E-16 221184 1643 TIME SYSTEM CORR
BDUT 0.0000000000E+00 0.000000000E+00 0 0 TIME SYSTEM CORR
15 LEAP SECONDS
END OF HEADER
確かに、この時点ではGPUTとQZUTの値は 3 ns位異なっている。
ということで、IS-QZSSを、再度良く読んでみる。QZSSのnavigation subframe 4, 5に含まれているUTCパラメータは、"time offset between UTC(NICT) (with QZSS as the standard) and GPS time" (5.2.2.2.5.2 (6)) とのこと。すなわち、QZUTの値はQZSST-UTCではなく、GPST-UTC(NICT)、らしい。まずここの理解が間違っていた。BIPM Circualar Tによると、2011/7/7のUTC-UTC(NICT) = -2.8 ns、UTC-UTC(USNO) = -3.8 ns、従って、UTC(NICT)-UTC(USNO) = -1.0 ns。GPSおよびQZSの航法データでは、GPUT - QZUT = (GPST - UTC(USNO)) - (GPST - UTC(NICT)) = UTC(NICT)-UTC(USNO) = 2.8 ns。ただ1日に数 nsは動いているので、その程度の誤差の範囲で一致している。ということで矛盾はしていないことは分かったけど、QZSSTはいったいどこへ行ったのだろう。
問題はQZSSのSV Clock parameterの基準時刻系が何か? ということである。再度IS-QZSS 5.2.2.2.3 (8)を良く読んでみるが、定義が曖昧である。これ他の記述から当然QZSST基準だと思っていたのだけど実はGPST基準? もしそうだったとして、QZSST=UTC(NICT)-Δt_LSと仮定すると仕様矛盾はなくなるかも。でも、やっぱりCNAVの「QZSSのGGTOはゼロ」の記述の矛盾は残る。
うーんやっぱり、QZSSTはいったいどこへ行ってしまったのだろう。この謎に誰かちゃんと答えてくれる人いないかなあ。
補足: 「どこへ行ってしまったのだろう」と書いたのは、良く考えてみるとQZSSTは何の基準にもなっていないということである。すなわちQZSSTがなくても誰も困らないのである、多分。もしQZSSTがないと困ること思いついた人があったら教えてください。(23:15追記)
...................................................................................................................................
GPS World, Look, No Base-Station! - Precise Point Positioning (PPP), March 20, 2013
現状の商用PPPサービスの紹介。取り上げているのは、OmniStar, RTX, StarFire, TERRASTAR (Veripos), iPPP。これ以外ではFugro SeaStar, GMV magicGNSS/PPPがあるはず。しかし皆、事業としてペイしているのかどうかは良く分からない。
...................................................................................................................................
今日で約2年間の仕事の区切り。反省点ややり残したことはいっぱいあるのだけど、メンタルも含めて自分の能力の限界はこの辺だなと分かったのが一番の収穫。
-------------------------------------
先日の「リアルタイムGNSS解析セミナー」の講演資料を公開したと連絡頂いた。特に岩淵さんの資料はPPPの応用を網羅し技術の可能性を示唆するよいまとめになっている。
...................................................................................................................................
メモ。
IS-GPSの相対論補正は Δt = F e sqrt(A) sin
Ek、RTCM SSRは Δt = - 2 rTv/c2、これらの差は1 cmはあるので全く無視できない。PPPの精度が出ない原因が長らく不明だったのだけどようやく見つけた。これDenisからも指摘を貰っていたはず。Denisありがとう。
補足: これ厳密には、IS-GPSにはどっちでもいいと書いてあるのだけど、cm以上の差があるということ。従ってcm級補強にはどちらを適用するかを規定する必要がある。実はRTCM SSRは後者を使えと書いてあるのだけど、RTKLIBの実装では前者を使っていたので無視できない誤差が生じていた。似たような話は、ケプラーの収束条件、数値積分とか幾何学距離計算にもあって、採用するモデルが十分な精度があるか一つ一つ確認が必要。でも補強生成側とユーザ側の整合性をcmレベルで確保するのは、技術詳細が公開されていない場合は相当大変。だから外国技術導入しちゃうと後々困りますよ、ということでもあるのだけど。(3/24追記)
...................................................................................................................................
裏で解析をずっと流しながら、RTKLIBのマニュアルを書く。今日は付録E半分と付録F書いた。付録Eは今年のサマーセミナーのネタ兼用。これから図を色々と引っ張ってきて入れるので最終的に200頁超えるかも。チュートリアルは多分誰か書いてくれるはずなので、あと4月以降になるけどAPI referenceを書く予定。
...................................................................................................................................
T.Takasu, Multiple constellation PPP with RTKLIB v.2.4.2, GNSS Precise Point Postioning Workshop: Reaching Full Potential, June 12-14 2013, Ottawa, Canda (abstract submission)
ということで、6月のPPPワークショップにはやっぱり行った方が良いかなと思ったので申し込んだ。RMITのChoyさんに誘われたしね。
...................................................................................................................................
どうもここ1カ月くらい、CDDISのアドレス解決に失敗してデータダウンロード時にFTPエラーとなるケースが頻発している。いつもダメな訳では無くてちゃんと繋がる場合もある。直接IPアドレス指定すると問題なさそうなのでDNSがうまく引けていないのではと思うのだけど何でだろう。もしかすると多量にダウンロードしているので制限食ったかなあ。
>> ftp cddis.gsfc.nasa.gov
ftp: cddis.gsfc.nasa.gov: Name or service
not knownftp>
ということで、CDDISのname servier絡みのトラブルの可能性が高いので、hostsファイルで直接IPアドレス指定することにした。Windows 7の場合、C:\Windows\System32\drivers\etcの下に、Linuxの場合は/etcの下にhostsファイルがあるので、これに以下の行を追加すればよい。
128.183.20.84 cddis.gsfc.nasa.gov # CDDIS
今のところうまく動いているっぽいけど、すこし様子を見ないと本当のところは分からない。
...................................................................................................................................
RTNet-GPS/GNSSデータの高精度リアルタイム解析 - ソフトウェア紹介 - デモンストレーション - サンプルデータ
GPS Solution社のRTNet紹介とデモ。
実は昨日「GNSSリアルタイムデータの活用による防災・減災を目指したリアルタイムGNSS解析に関するセミナー」(参照) というのに参加して、RTNet開発者の一人であるGPS Solutions社 岩淵さんの講演を聞いたのだけど、リアルタイム暦は、Veripos APEXを使っていて、PPP 精度 2-4cm (水平), 4-10cm (垂直)、PPP-AR 1-2cm (水平), 3-5cm (垂直) とのこと。(PPP-ARは開発版で正式版は1-2年後)。もうすぐ評価用に機能限定版のRTNetを公開する、と言っていた様な気がするので、公開されたら少し使ってみたい。
補足: Veripos APEX、これ見ると基準局75局位。確かエンジンはESAのNAPEOS使っていて、サポートする衛星はGPS+GLONASS。補正データはRTCM 2のベンダ定義メッセージを使って、静止衛星 (Inmarsat) とインターネット (NTRIP) で配信。基準局網、網制御局、サーバ、回線等全て冗長構成になっていて、さすが高信頼な商用サービスという感じ。これ基準局データだけ売ってくれないだろうなあ。(15:48追記)
再補足: GPS Solutions社、米コロラド州ボルダーのダウンタウンにあって、スタッフ9名の小さな会社とのこと。社長のRockenさんには確か昨年3月のフランクフルトPPP-RTKシンポでお会いしている。岩淵さんの講演はリアルタイムPPPの応用を網羅するもので、大変分かりやすいものだったので、ぜひ資料をどこかで公開してもらいたい。(15:59追記)
...................................................................................................................................
おお、いつの間にかこんなのができている。
DiGiMate, 独自の新技術による高精度RTK測位・GNSS測位システム
検索してたら、こんなのも見つけてしまった。
...................................................................................................................................
GPS World, First Galileo-Only Position Fix Performed, March 12, 2013
Galileoがようやく正規の航法データの放送を始めた様で。ということでRTKNAVIで、Galileo受けているMGEXの局を探す。以下スリランカのSGOC局。受信機はTrimble NetR9。フォーマットはRTCM3。現状、航法データは10分毎更新の様。GPSと混合測位で15-25mの残差が出ている。これGPST-GST (Galileo system time) (+受信機バイアス) 起因だろう。GPST-GLOTと同様に推定するよう改修しないとダメだな。
補足: もしかするとまだGalileoエフェメリスのデコーダにバグが有るかもしれないのだけど、BGD E1/E5a, E1/E5bは0が放送されている。
...................................................................................................................................
RTCM 10403.2, Differential GNSS (Global Navigation Satellite Systems) Services - Version 3, February 1, 2013
2月のRTCM SC104委員会で承認されたRTCM 3.2が入手可能になっている。3.1 with amendment 1-5からの主な変更は、MSM (mutiple signal messages) の追加。
-------------------------------------
ということで、Stop and Go modeは時間切れ、次版送り。Matched solution modeはrtksvrの実装結構直す必要あって、間に合うかはギリギリ。
...................................................................................................................................
最近まで知らなかったのだけど、日本測量機器工業会 (JSIMA) というのがあって、GNSSアンテナの位相特性データを提供しているらしい。検定センターというのがあるので、頼めばロボット使った位相特性計測もやってくれるのかなあ。将来的には色んな受信機のバイアス測ってデータベース化してくれるとうれしいのだけど。
-------------------------------------
ずっと積み残しになっていたOTLとpole tideの実装。以下IGS COCO局のkinematic PPP結果で、補正なし(左)、補正あり(右)。特に上下はそれなりに効いている様に見える。なお内陸の局は殆ど差が出ない様。この機能は2.4.2正式版に入る。
Earth Tides Correction=Solid (left), =Solid/OTL
(right), IGS COCO 2012/01/08-14
Kinematic PPP by RTKPOST 2.4.2 with IGS Final
-------------------------------------
黙祷。
...................................................................................................................................
CSG Shop: u-blox NEO-7N GPS/GNSS Receiver Board with SMA for UAV, Robots
まだ殆ど出回っていないu-blox 7, NEO-7Nの受信機ボード。$64.99也。GPS, GLONASS, Galileo, QZSS, SBAS対応 56CH。解出力10Hz。raw出ないはずだけど、FlashなのでF/W更新可能で、もしかするとクラック可能かも。
...................................................................................................................................
ということで、RTKLIB 2.4.2のリリース準備色々。一部は積み残しで次のバージョンへ送る。早めにコードをフリーズして、試験・評価で1週間の予定なのだけど、時間がとれるかが問題。
-------------------------------------
国土地理院, 第6回マルチGNSSによる高精度測位技術の開発に関する委員会, 平成25年3月4日
今週月曜にあった委員会資料がもうアップされている。
-------------------------------------
おお、いつのまにかSDR使ってJAXA LEX PPPが動いている。
...................................................................................................................................
ということで、ION GNSS+ 2013のアブスト〆切が明日なのだけど、どう考えても書いている暇ないなあ。ネタが無いことないんだけど。
-------------------------------------
RTKLIB 2.4.2 manual is now updated (draft 2).
...................................................................................................................................
JAXA, 第7回QZSSユーザミーティング開催報告, 平成24年2月13-14日
先日行われた第7回QZSSユーザミーティングの資料がアップされている。NICTの時刻関係実験の総括。これ、前から何度も説明聞いているのだけど、結局未だに実験の目的や意義が理解できないのだけど、頭が悪いだけ? すいません誰か分かりやすく教えて下さい。資料中、GQTO = UTC(NICT) - GPSTみたいに書かれているけど、少なくとも現在のJAXAの定義ではQZSST ≠ UTC(NICT) なのでこれ嘘だよね。
補足: 私の理解が間違ってなければp.17に書かれている、GQTOを「MCSでは、航法メッセージのUTC項生成に使用」というのも嘘のはず。(18:21追記)
再補足: QZ-visionにアップされているQZSS航法データとGPS航法データのQZUT及びGPUTを比較すれば分かる様に、現在QZSSのQZSST-UTCパラメータは、GPSのGPST-UTC(USNO) パラメータを再送信しているだけのはずである。IS-QZSS-1.4の5.3.2.4.3.3 (2)(b)、5.5.2.2.8.2、5.6.2.2.8.2にある「QZSSのGGTOがゼロ」の記述も入れて総合判断すると、現在のQZSSTは、特定の原子時計(群のアンサンブル)で決まる時系ではなく、(何からの手段で) GPSTに合致する様に人為的にステアリングされた時系、であると推定される。これは、IS-QZSSの3.1.4.1の「QZSSTはUTC(NICT)に準拠」(「準拠」は英語版ではconform to) の記述に矛盾する。仕様矛盾だけでなく、時刻系の安定性、精密時刻同期の保証 (QZSS - UTC(NICT)差を誰がどう担保するか)、SIS-URE定義の曖昧さ等、現在のQZSSTの定義はいくつか技術的な問題点を抱えている。前にも書いた様にQZSSTについては実用準天に向け再整理・再定義が必要と思う。(19:08追記)
再々補足: 本件一部事実誤認があり、追加情報を書いた。(→3/24)
...................................................................................................................................
AnandTech, NVIDIA's GeForce GTX Titan Review, Part 2: Titan's Performance Unveiled, February 21, 2013
秋葉原では現在Titanの争奪戦で入手困難の様だが、これ見るとCUBLAS DGEMMで1.3TFLOPS (!) 出るらしい。うまく使えば13万円で、Sandy-EP 16 coreの3倍以上性能出る訳でコストパフォーマンス抜群。ECC付いてないし、癖あって実APで性能出すの大変そうだけど。ということで少し落ち着いたらちょっと入手してテストしてみたい。(なんか書いてることがコロコロ変わっている気もするけど、まあ状況が色々と変わっているので)
補足: 単精度やFFTも速いのでSDRにも良いかも。多分2年もすれば普及価格帯に降りてくるしね。(9:43追記)
再補足: これ見るとHPC向けのTesla K20 (価格約40万円) で500GFLOPS強しか出てないんだけど、Titanとどこが違う? (11:45追記)
再々補足: Tesla K20/K20XとTitanの違いについての記事。やっぱり2倍以上の性能差の説明にならない様な。(18:50追記)
...................................................................................................................................
NASA Science News, Solar cycle update: twin peaks?, March 1, 2013
何か予期されないことが太陽に起こっているらしい。sunspot countのグラフ見ると2013年極大の予想が、既に活動レベルは下がりつつあるらしい。何かの天変地異の前兆でなければ良いのだけど。
-------------------------------------
RTKLIB 2.4.2 manual (draft) is now available.
...................................................................................................................................
GNSS Precise Point Positioning Workshop: Reaching Full Potential, June 12-14, Ottawa, Canada
6/12-14にカナダ ヨーク大で開催される精密単独測位 (PPP) に関するワークショップ。アブスト締め切り3/22。
-------------------------------------
あっと言う間に3月。さて、RTKLIB 2.4.2は本当に2013 1Qに出せるのでしょうか。
-------------------------------------
Beta 11 is now available. See release notes for 2.4.2 new features.
...................................................................................................................................
| Home | by T.Takasu |