|
日記・備考録 |
2005 | 2006 | 2007 | 2008 | 2009 | 2010 | 2011 | 2012/1 2 3 4 5 6 7 8 9 10 11 12 | 2013 |
| June | July 2012 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 |
August | Home |
...................................................................................................................................
Workshop on GNSS Biases, January 18-19, 2012, University of Bern
今年1月に行われたIGS バイアスWS。プレゼン資料もupされている。とりあえず貼っておく。7/14に少し書いたようにバイアス特に受信機バイアスはマルチGNSS解析において避けて通れない中心的な課題。ただ多数の複雑な問題が絡みあっていてその対応は簡単ではない。個人的には、アンテナ位相中心と同じように、誰かがまとめて受信機バイアス校正をやって、結果をデータベースとして公開してくれる位しか本質的な対応は難しいのでは、と思っているのだが、例えばIGSがやるとしてもまだ5年10年かかるよなあ、という感じ。それまでの間どうすればよいことやら。
...................................................................................................................................
ポーランドから帰国。
...................................................................................................................................
IGS WS完。感激のないWSだった。5年位前は、WSの資料見て、IGS凄い、Jim Ray凄い、という感じだったのだけど、(Jimはまだ凄いんだけど) 今は皆普通に淡々とやってるんだなあという感じ。活動の進捗やたら遅いしね。まあ、自分が知らないうちにレベルアップしてるという部分もあるかも。さて1週間日本を空けたせいで、完全に作業は止まっているし、来週はフルに打合せが入ってしまった。どこでリカバリしよう。その前に遠路はるばる日本まで帰らにゃならん。ふう。
...................................................................................................................................
IGS WS 4日目。今日はOrbit Dynamics関係で少し面白い話を聞けた。SRPって現在empiricalなモデルが主流
(実際精度が出る)。ただ、empricalなモデルはgeocenter変動等の地球科学シグナルが推定値に埋もれてしまうという問題がある。そこを衛星形状、熱輻射、レイトレーシングを入れた精密物理モデルて改善しましょうという話。これ、複雑な形状の大型衛星の精密軌道決定に有用。実用準天頂衛星にも大きなアンテナが載る可能性高いので、empiricalなモデルでは軌道決定性能出ない可能性高いし。
後はホテルで日本と色々メールやりとり。ところで、ネットでニュース見てたらいつのまにかオリンピック始まってるんだ。
...................................................................................................................................
IGS WS 2日目。今までのところ技術的に面白い話はなかった。Splinterではどうでもいい様なやたら細かい話しかしてないし。次回はもういいかなという感じ。
...................................................................................................................................
待ち時間も入れると約25時間かかってオルシュテイン着。風光明媚な田舎都市という感じ。でも疲れた。
...................................................................................................................................
さて、これからポーランド オルシュテイン。
-------------------------------------
カルマンフィルタの観測更新則
K=P*H'*(H*P*H'+R)^-1
x=x+K*v
P=(I-K*H)*P
を実際に実装する場合、最速は以下の標準更新則と言われる。
(1) D=P*H'
(2) S=H*D+R
(3) K=D*S^-1
(4) x=x+K*v
(5) P=P-K*D'
ここでH, Rはほとんどsparseなので (1)(2) はsparse行列乗算、(3) はLU分解かcholeskyを使うのが普通。ただ問題はPの更新が対称ではないので、更新を多数回続けるとフィルタの数値不安定が出ること。実際、n=3000程度のフィルタで5000回程度の更新でPの対角にマイナス項が現れ、発散してしまうという現象に悩まされていた。対策としては、Joseph stabilized formを使う、UD, SRIF等sqaure root系の更新則に置き換える等が考えられるが、単純に計算量が多くなるし、最適化行列ライブラリを利用しづらい形式になるので、さらに遅くなる、という問題があった。ということで、どうすればいいかここ1週間ぐらいずっと悩んでいたのだけど、
(1) D=P*H'
(2) S=H*D+R
(3) U=chol(S) (U'*U=S)
(4) E=D*U^-1
(5) K=E*U^-T
(6) x=x+K*v
(7) P=P-E*E'
という形に変形すれば、計算量は変わらずPを対称に更新できることに気がついた。また(3)はLAPACKのDPOTRF、(4)(5)はDTRSM、(6)(7)はBLASのDGEMV, DGEMMを使えるので、MKL使えば計算速い。ということで、実装して試してみたら、フィルタの不安定性が嘘のように消えた。万々歳。一応、Gelb, Grewal, Simon, Gibbs, CrassidisのKalman filter本は手元にあるので全部調べたのだけど、この形式載ってないんだけど。もしかすると新しい方式? でも論文書くほどのネタでもないしなあ。
補足: 手元に実行環境がないので確かめられないのだけど、(7) はもしかすると、DGEMMじゃなくてDSYRK (symmetric rank-k operation) の方が少し速いかも。ただ、upper triangularのままだと(1)(2)のsparse行列計算の効率が落ちるのでlowerにもコピーした方が良い。 (7/27追記)
再補足: (7) にDSYRKを使って速度を測ってみた。やはりDGEMMよりこっちの方が1-2割は速い。多分これが最速。(7/29追記)
...................................................................................................................................
結論からすると、RTKLIBのマルチGNSS対応 基線解析はまだ全然未完成ということ。今まではほぼJAVADのデータしか解析していなかったから、問題点が顕在化していなかっただけ。色々な受信機の観測データが入手できる様になってきたので、問題点を再整理した上で根本的な対策をとる必要がある。
-------------------------------------
ここまでと書いときながら、ちょっと気になって解析継続。GPS + QZS, Trimble - TOPCON基線での問題。座標をF3解に固定してFixedモードで基線解析し事後残差を見てみた。QZSS L1 (左), L2 (右)。L1コードに1m, L2コードに5m程度の大きなバイアスが認められる。多分これが原因だな。
これは受信機P1-C1, P2-C2バイアス起因と思われる。これらは同一機種間基線なら二重差でキャンセルされるけど、異機種間ではキャンセルされないということ。結局、異機種間では、異なるコード間では二重差とっちゃいかんということで、QZSを基線解析に使うときには、今のところほぼL2は使えないということになってしまう。これを改善するためには受信機機種毎、コード毎に校正が必要なわけで、こりゃまた大変な作業だ。
補足: 最近の受信機ではRF段以降は殆どデジタル処理なので (衛星と違って) 受信機ではP1-C1やP2-C2バイアスって原理的に発生しないはずなのだけど。まあ、所要帯域幅違うからRF段で別回路になっている可能性もあるけど。(17:27追記)
-------------------------------------
新しいGEONETデータのTrimble - TOPCON基線で正常にアンビギュイティが解けない件、やはりコードを混合して使っていたのが問題だった様。2.4.1ではRINEXに同一周波数で複数コードの観測データが含まれている場合、固定されたコード優先度に従いデータを読み込む。そのため同一周波数に複数コードを含んだRINEXの解析に問題を起こす場合がある。ということで、RTKPOSTに使用するコード選択オプションを追加することに。追加したオプションでGPSはL1はC/A固定、L2はP(Y)固定にした結果 (左) (基線: 0918 河北 Trimble - 0549: 矢本 TOPCON, 基線長12.3km, GPSのみ) 右は RTKPOST 2.4.1による結果。これバグではないので対応は次のバージョン (v.2.4.2) をお待ちください。(正式リリース前に提供が必要な場合は直接ご相談ください) 改良版でも一時的にFIXが外れるのは、TOPCON受信機のL2捕捉が遅いのがやはり影響している様。これ受信機でなんとかなんないんですかねえ。
補足: GPSはうまくいったと思ったら、GPS + QZSの、Trimble - TOPCON基線で問題発生。うーん...。マルチGNSS - 異機種間の基線解析は、まだ色々と問題をはらんでいそう。疲れたのでとりあえず今日はここまで。(16:32追記)
-------------------------------------
RTKLIB 2.4.1で新しいGEONETデータの基線解析がホントにできるの、ということを確認してみた。基線 0918 河北 - 0550 牡鹿 (基線長28.8km, Trimble - Trimble)。基準局とローバ座標は最新のF3解、アンテナモデルはIGS08.ATX、暦は放送暦、長基線RTK条件でpartial fixingを使っている。設定、結果 (左からGPS, GPS+GLO, GPS+GLO+QZS)。
以上を見る限り、GLONASSの効果は明らか。QZSSの効果は微妙。
ただ、Trimble - TOPCON基線で、GPSのみでも正常にアンビギュイティが解けない問題が発生。原因不明だがquarter cycle phase shift問題がからんでいる可能性がある。また、3H間隔のGEONET RINEX観測データを併合して使う場合、観測値の重複により正常に測位できない問題も発見。従って、以上では6H間隔のみのRINEX観測データを使っている。この問題は2.4.2で直す予定。
-------------------------------------
R.Langley, Russian SBAS Satellite Begins Transmissions, July 12, 2012
昨年12/11に打ち上げられたロシア版SBAS SDCMのLuch-5A衛星が信号送信を開始したとのこと。PRN番号は140。まだ補正はGPSのみでGLONASSは含まれていないらしい。静止位置が当初発表されていた西経16度から東経95度に変更になった様で受信機が対応していれば日本でも受信できるはず。ただ、多くの受信機ではSBASのPRN番号は120〜132までしか対応していないはずで受信にはF/Wの更新が必要と思われる。もちろんSDRを使えば簡単に信号が確認できるはず。GLONASSの補正情報の送信が始まればちょっとその内容チェックしてみたい。
-------------------------------------
国土地理院GEONETデータで気になった点。
GEONETのQZSS航法データとQZ-visionにアップされているQZSS航法データを比較してみると、QZ-visionの方は同一のTOEで複数 (4つ) のエフェメリスが出力されているのに対し、GEONETの方は1つしか出力されていない。たぶん、GEONETではIODC-only-updateのエフェメリスを取りこぼしているのではないか。これ、TOPCON受信機側の問題なのかRINEXコンバータ (BINEX2RINEX) 側の問題なのかは不明だが、可能なら直した方がよいと思う。(本件、RTKLIBでも問題が発見されパッチを出している。昨年6/30の備考録参照)
...................................................................................................................................
国土地理院からGLONASS, QZSS対応のGEONETデータが公開されたのでさっそくダウンロードしてみた。今回からユーザ登録が必要になった様だ。GPSのみは従来と同じディレクトリ。GPS+GLO, GPS+GLO+QZSはディレクトリが新設されている。つくば1 GPS+GLO+QZSのRINEX観測データ (21101946.12.o.gz) の頭だけ。
2.12 OBSERVATION DATA M (MIXED) RINEX VERSION / TYPE
BINEX2RINEX 0.33 GSI, JAPAN 20120713 01:13:27UTCPGM / RUN BY / DATE
smtt off - ms jumps in time tag (smooth phase and range) COMMENT
smtt off - ms jumps in time tag (smooth phase and range) COMMENT
smtt off - ms jumps in time tag (smooth phase and range) COMMENT
smtt off - ms jumps in time tag (smooth phase and range) COMMENT
smtt off - ms jumps in time tag (smooth phase and range) COMMENT
smtt off - ms jumps in time tag (smooth phase and range) COMMENT
smtt off - ms jumps in time tag (smooth phase and range) COMMENT
2110 MARKER NAME
GSI, JAPAN GEOSPATIAL INFORMATION AUTHORITY OF JAPAOBSERVER / AGENCY
00000 TPS NETG3 3.6 Feb,28,2012 p1 REC # / TYPE / VERS
TPSCR.G5 GSI ANT # / TYPE
-3957160.4048 3310202.1487 3737751.0078 APPROX POSITION XYZ
0.0000 0.0000 0.0000 ANTENNA: DELTA H/E/N
1 1 WAVELENGTH FACT L1/2
21 CA LA SA P1 L1 S1 CB LB SB# / TYPES OF OBSERV
CC LC SC CD LD SD L2 S2 P2# / TYPES OF OBSERV
C5 L5 S5 # / TYPES OF OBSERV
2012 7 12 15 0 0.0000000 GPS TIME OF FIRST OBS
30.000 INTERVAL
16 LEAP SECONDS
smtt off - ms jumps in time tag (smooth phase and range) COMMENT
END OF HEADER
12 7 12 15 0 0.0000000 0 17G17J01R09G23G05R24G10G12G13G07R22G04 0.000028309
R08G02R01R07R23
22549801.276 118500033.836 7 46.800 22549800.6834 118500034.08746
38.4004 22549799.292
92337693.609 7 47.300
92337693.36946 38.2004 22549798.8894
...
RINEXバージョンは2.12 + QZSS拡張。この局はTOPCON NETG3でL1+L2+L5の観測データが含まれている。RINEX 3でないのはやはり解析ソフト側の対応を考えてか。航法データはGPS, GLO, QZS用のRINEXファイルをまとめてtar gzipで圧縮したものが提供される。RTKPLOT 2.4.2bで表示させたvisibility chartとskyplot。特に問題はなさそうだが、できればLLIを出力してほしい。L2の捕捉がかなり遅いのはTOPCONの特性?
-------------------------------------
国土地理院, 東北地方などの電子基準点より準天頂衛星やグロナス衛星のデータ提供を開始 - GNSS時代への対応による震災復興支援 -, 平成24年7月13日
報道発表が出た様で。電子基準点のマルチGNSS対応は当初予定より前倒しで今年度中にはほとんど置き換わると聞いている。ただこの発表によると全点の配信は来年度になるよう。「電子基準点を利用したリアルタイム測位推進協議会」による実験ももうすぐ始まるらしい。ただQZSSを使った基線解析やRTKに対応している受信機や解析ソフトはまだほとんどなく、現状ではRTKLIBがほぼ唯一。ということでこれらの実験でもRTKLIBを使ってもらうということで色々と話が進んでいる。
-------------------------------------
内閣府 民間資金等活用事業推進室, PFIの概要について
やっぱり「PFI」良く分からない。基本的な考え方は、従来型公共事業を民間へアウトソーシングすることでコストカットしましょうということなのだとは思うけど、なぜそれが「民間資金を活用」することになるのかが分からない。まあ事業を任された民間企業は、その資金を使って開発した技術を他の事業に転用しやすいから、将来的な事業展開の目処があれば (持ち出しでも受けるから) 結局長期的には民間資金を使っていることになるのかも。でも短期的には今までの公共事業とそんなに変わらない気が。まあ、従来の親方日の丸体質を払拭してねという、官から民へのメッセージ?
補足: PFIについて分かりやすい解説を貰いました。情報感謝。でも国の予算が単年度でしか執行できないところが元々の問題なのでそこを直せばいいのに、とは思った。 (まあそう簡単にはいかんのでしょうが) (22:04追記)
-------------------------------------
日本経済新聞, 日本版GPS整備へ宇宙戦略室が発足, 平成24年7月12日
> 政府で宇宙政策の新たな司令塔となる「宇宙戦略室」が12日、内閣府に発足した。各省庁で
> ばらばらに担当してきた宇宙行政を一元化して司令塔の役割を担い、古川元久国家戦略相が
> 宇宙政策担当相を兼務した。中長期を含む政策の全体方針を打ち出すほか、米全地球測位シ
> ステム（ＧＰＳ）の日本版「準天頂衛星」の整備・運用なども手がける。政府は近く戦略室
> 内に有識者で構成する宇宙政策委員会も新設。戦略室は同委の助言を受け、2013年度の概算
> 要求に向けて関連予算の見積もり方針をまとめる
とのこと。これで実用準天頂衛星の開発も本格的にスタートするという感じ。
...................................................................................................................................
R.F.Leandro et al., Real-Time Extended GNSS Positioning, GPS World, 2012
内容的には昨年ION GNSS発表の要約の様だが、Trimble RTXが記事になっている。記事のカテゴリがPrecision Agになっているので、まずは精密農業を主な対象と考えている様だ。IGUとRTXのGPSリアルタイム軌道の比較があるが、やはりIGUは品質悪いなあという感じ。リアルタイムの軌道で世界一を狙うには、当面RTXの3D誤差約4cmというのが目標精度となるだろう。GLONASS軌道の結果がないのは良い基準がないからなのか、GPSと比較して今一なのかは不明。でも、補正情報のレイテンシが3.7秒 (50%), 5.6秒 (99%)というのはそれ程良い値ではない。長基線RTKならレイテンシ1秒以下はそれ程無理なく実現できるので、ホントのリアルタイムでは長基線RTKとは差が出てくると思う。しかし、なんとか半周遅れ位でついて行きたいものだ。
補足: 「ホントの」と書いたのは分かる人は分かると思うけど、ローバ (ユーザ) 受信機側のデータも遅らせて、見かけ上補正データのレイテンシを隠ぺいすることも可能なので。これは厳密には「リアルタイム」とは言えないと思うのだけど、多分多くのリアルタイムPPPの精度評価ではこのモードを使っているはず。もちろんローバ受信機側だってデータ出力のレイテンシは0ではないので「リアルタイム」かどうかは程度問題だとも言えるのだけど。ちなみにRTKLIBの2.4.2では補正情報や基準局データのレイテンシを隠ぺいするための「matched solution」モードの新設を予定している。(7/13追記)
-------------------------------------
International Launch Services, ILS Proton succesfully launches SES-5 for SES, July 10, 2012
2012/07/09 18:38 UTC, SES-5 GEO衛星 カザフスタン バイコヌール宇宙基地からプロトン ブリーズMロケットで打ち上げ成功。SES-5はSS/L (Space Systems/Loral) 1300 プラットフォームベースの通信衛星で、Kuバンド、Cバンドのトランスポンダに加えて、欧州EGNOS GPS測位補強用のLバンドペイロードが搭載されている。別の記事によれば複数周波数帯 (多分L1/L5) に対応するとのこと。
-------------------------------------
注文していたSandy Bridge-EP の計算機が来たので性能を測ってみた。CentOS 6.2 + MKL 10.3 update 11。
matmul() 200 x 200: time= 0.043 s ( 371.2 MFLOPS) matmul() 500 x 500: time= 0.013 s ( 19211.5 MFLOPS) matmul() 1000 x 1000: time= 0.009 s (222111.1 MFLOPS) matmul() 2000 x 2000: time= 0.065 s (246092.3 MFLOPS) matmul() 5000 x 5000: time= 0.734 s (340565.4 MFLOPS) matmul() 10000 x 10000: time= 5.475 s (365278.5 MFLOPS) solve() 200 x 200: time= 0.035 s solve() 500 x 500: time= 0.005 s solve() 1000 x 1000: time= 0.024 s solve() 2000 x 2000: time= 0.115 s solve() 5000 x 5000: time= 1.289 s solve() 10000 x 10000: time= 8.975 s
マトリクスサイズが大きいところでは流石に速いのだけど、小さいところでは思ったほど性能出てない様な。実AP性能でも大体 Core i7 3930K (6-core) の倍くらい。2600K (4-core) の3倍は行っていない。コストパフォーマンスは必ずしも良くない。ちなみに計算機はここのこれ。CPUは当然、Xeon E5-2687W × 2 (16-core)、RAM 128GB (8GB × 16 ECC)、HGST HDD 4 TB × 2、スクラッチ用にIntel SSD 520 240GB × 2 (RAID0)。DELLやHPのオンライン見積りを取ってみたら、同じ様な構成でどうやっても120万以下に収まらなかったのだけど、ここは非常に安い。自分で部品集めて組むよりむしろ安いくらい。メモリを沢山積んだので少し大きい解析を流してみたい。
補足: 8GBメモリが急に安くなって128GBにできたので、n=100,000の最小二乗がギリギリで解けるはず。10万点のパラメータって概ねGEONET全点の一括ネットワーク解析の大きさなので、これが実用的な時間で解けるかをちょっと試してみたい。(22:38追記)
再補足: もし、コストパフォーマンスを考えて自分のお金で計算機買うなら、今だったら 3930Kかなあという感じ。3930K結構オーバークロック耐性高いし、32GBのRAM積んでも15万も出せば1台組めるから。あとは、CUDAのコレスキーが結構速いという話を聞いたので、GPGPUも試してみたいのだけど次世代 NVIDIA Kepler 2が出て、Open ACCがまともに使えるようになってからかなあ、とは思っている。(23:10追記)
...................................................................................................................................
C.Cai et al., Modeling and assesment of combined GPS/GLONASS precise point positioning, GPS Solutions, 2012
GPS/GLONASS PPPのモデルと評価。暦はIACとESAを使っている。結論としてGLONASSを入れることにより、スタティック精度は差なし、キネマティック精度は改善、収束時間は大幅改善、という、ほぼ予想されるもの。細かく見るとあらの多い論文だけど、GPS/GLONASS PPPの性能評価って過去殆どないはずなので価値がない訳ではない。GLONASSを (特にキネマティック) PPPに使うにはやっぱり暦が問題で、現状では使えるのはESA位しかない。まあこの辺を改善するために、今色々とやってる訳だけど。
...................................................................................................................................
NEC, LaVie Z
875g。ちょっと欲しい。問題は約400gのために、2年前のMBAから買い替える価値があるかどうか。あと個人的には、NEC製ノートPCってトラブル多くてあまりいい印象ないので。やはり噂のある次期Retina MBAを見てから。Retina MBPがあと500g軽ければ、即決なんだけど。
...................................................................................................................................
Wired.jp, 「うるう秒」障害がネットで頻発, 2012年7月2日
結構色んなところで障害が発生しているようで。
NASA GSFCのGNSS (や地球観測衛星) データサーバ、CDDIS
(Crustal Dynamics Data Information System)
もずっと落ちている様なのだけど、これはleap
second関係ないのかなあ。これ見ると"Extreamly Strong Storm"が原因の電源障害とあるけど。CDDISが止まっている関係で、CDDISから定期的にデータをダウンロードして解析処理するGNSS関係のサービスも止まっている所が多いはず。実は某プロジェクトのデモ用解析サーバもこれが原因で昨日から落ちていたりする。
...................................................................................................................................
| Home | by T.Takasu |