2007/02/01〜

.....................................................................................................................................

2007/01/31

RTKと言うからにはやっぱりリアルタイムで測位できるものを作らなきゃならん。ということでRTKLIBによるWindowsで動くデモ用RTKプログラムの開発。といっても最低限のUIで簡単に動かすため使い慣れたC++ Builderを使う。後はRTCM SC-104のRTKメッセージを調べる。メッセージ18と19がRTK用観測データなので、このエンコード/デコードを書いてローバ、基準局毎にCOMポートからこれを取り込む機能を付ければOKのはず。NMEA0183のGGAセンテンスを出力出来るようにすればNMEA対応地図ソフトで現在値や軌跡を表示できる。基準局データをNTRIPを使ってインターネット経由で取得できるようにすれば面白いがこれだけで研究テーマになるのでこれは後回し。
それから試験用に、RINEXを読み込んでRTCMメッセージをCOMポートから出力する受信機シミュレータを作る。このシミュレータもL5を適当に追加してあげると3周波でのRTK試験が出来る。これもすぐに研究テーマになる。ということでRTKLIB一つ使うと研究テーマはすぐに見つかるので学生さん誰かやりません。(結局今まではRTKモジュールをブラックボックスとしてしか使えなかったのでできる実験に制約があった。RTKLIB開発の目的は実は結構深いのであった)

Windows Vista Home Premium (DSP版+FDD) が届いた。衝動で64bit版を買ってしまったので入れると色々と動かないAPが出そう。とりあえず今やっている事の区切りがつくまでインストールはお預け。HDの整理もしたいし。

.....................................................................................................................................

2007/01/30

TEQC使いのベテラン名大太田さんからmailを頂いた。感謝。1Hz RINEX OBSを30sに間引くオプション (もう一度よーくマニュアルを読んだら書いてあった...)

teqc -O.dec 30 xxxx.05o

強烈なインパクトのあるスパムが届いたのでちょっとGoogle検索。どうも「名作」と呼ばれるもののパクリらしい。スパムでも届けば一応メーラを見てしまうのでも集中力をそがれてしまう。メーラを常時起動しないで一々立ち上げてメールチェックする方が効率が上がる様に思うので、そうすることにした。メールの応答が少し遅くなるかも知れませんがご容赦を。

.....................................................................................................................................

2007/01/29

RTKLIB ver.1.1引き続き。RTKLIB ver.1.0はちょっと拡張すると中長基線RTK、ネットワークRTKやネットワークRTK補正値生成に使えるのだが、そのためのフック(機能追加のための仕掛け)が不足しているのでその点の修正。これを使って試してみたいことがあるので。さっと直して確認してうまく行きそうなら春の連合大会はこのテーマで出すつもり。テーマ的には少し場違いではあるのだが、多分PPP高度化は時間的に間に合わないので。
もしこのテーマでいくとすると一昨年は精密軌道決定、昨年はHR-PPP、今年はRTKということになる。何か全然テーマに一貫性がないなあ、とは思う。

TEQC - The Toolkit for GPS/GLONASS/SBAS Data, UNAVCO
ちょっとRINEXファイルの編集をやりたくてTEQCマニュアルを調べる。やりたいのは1Hz観測データから30sサンプリングデータだけ抜き出す。よーく調べたけどどうもTEQCにはこの機能がない様だ...。全く、全然使えない。仕方ないので自前で書く。ふー疲れる。

.....................................................................................................................................

2007/01/27

RTKLIB性能改善引き続き。5Hz 1H分で58秒位までにはなったがファイル入出力を除いても1エポック2msはかかっている (gcc)。ちょっと遅い。何故か分からないがicc+mklでは最適化を効かせても、もっと遅い(1分14秒)。ライブラリを使っていたり最適化したりするとgprofではちゃんとした実行時間プロファイルが取れない様で、何処に時間がかかっているのかよく分からない。こういう場合はコードをコメントアウトして計測し直すといった原始的な手段で解析するしかない。
解析の結果。58sの内訳: 入力:13s, 出力:5s, AR:10s, 単独測位+相対測位:30s。単独測位にはiterationが入っているのでこの割合は7:3位か。多分そのうちdgemmが5割。1エポック1ms以下にはしたいのだがもうあんまり削りしろは無いかも知れない。(補足: 観測データの中身をよく見たら。3H 54000エポック分だった。入出力を除いて1エポック1ms以下なので良しとする。2/4)

.....................................................................................................................................

2007/01/26

RTKLIB ver.1.0は凍結したのだが、やっぱり色々と気にくわない所が出てきてもうver.1.1に向けての修正。一つは簡単な拡張で移動基準局でも測位できて基線ベクトルを出力できる様に。GPS姿勢計対応。この機能を使って某所から頂いた移動体の5Hzマルチアンテナ観測データ (すいません、まだ解析終わってません。もう少しお待ちを) で少し評価。基線長30m位なので1周波でもほぼ瞬時FIXする(悪くても2-3 epoch、1秒以内)。某発表で「数分かかる」というのがあったがいったいどういう条件で評価しているのだろうか (この件に限らず、どうも実際に自分で実装して評価した結果と、世の中で「評価した」と発表される結果との乖離が激しい。何故だろう)
あとは5Hzだと1時間分の解析に1分半もかかっているので少し実行時間プロファイルをとって性能改善。

Crazy Multi-Input Touch Screen, YouTube
昨日紹介のJ.Y.Hanのマルチタッチスクリーンの別デモ映像がYouTubeにあったので張っておく。革新的なUI。デバイスより、あれだけちゃんと動くAPを揃えている所が凄い。

China's Asat Test Will Intensify U.S.-Chinese Faceoff in Space, Aviation Week
暗いニュースだが少しは宇宙開発に関係している身なので。中国に限らず衛星を思ったところに投入できる技術を持った国なら他国の衛星を破壊するのは難しくない。何せ衛星はマッハ20で飛行しているのだからその前方に一寸チリをばらまけばよい。そしてこれを阻止するのはほぼ無理である。GPSに限らず衛星はインフラとして必要不可欠なものになってしまっているから衛星の破壊は社会に壊滅的な影響を与えうる。この様に安全保障面で脆弱なシステムにあまりにdependした社会自体を見直す必要がある、という警笛に取るべきだろう。(補足: 今回中国が使ったのは弾道ミサイルによるASATらしい。Wikipedia。いずれにしても大量のデブリを撒き散らし宇宙空間を汚した上、他の衛星の障害確率を増し宇宙利用に悪影響を与える愚挙。これが原因で衛星故障が発生した場合中国に損害賠償を請求できるのだろうか。1/27)

.....................................................................................................................................

2007/01/25

タッチスクリーンで映画「マイノリティレポート」は現実になる, GIZMODO
これ凄い。UIデバイスとしてマウスの覇権がもう随分続いているのだがそろそろ別のデバイスが出てきてもいいのかも。でも一日使っていたら肩こりそう。そういえばAppleが最近発表したiPhoneでもタッチスクリーンをうまく使っていた。ちょっと考えたのだが別に画面タッチで無くても、ノートパソコンのスライドパッドをA4くらいまで大きくして、マルチタッチ認識が出来る様にすれば充分安価で使いやすいUIデバイスになるのでは。もしかすると何処かで既に開発済み? (補足: マルチタッチスクリーンはiPhoneの一つの売りの様だからOS Xでは直ぐに標準サポートされる様になるかもしれない)
実を言うとPCやアプリケーションのUIには興味があって、自分が実装するプログラムには自分なりになるべく使いやすいと思われるUIを取り入れているのだが、デバイスとしてのマウスの限界を感じることがある。例えばGoogle EarthのUIは近頃では出色の出来ではあるがやはりマウスでは使いづらい。特に3D地図をグリグリ回すとかのケースで顕著である。そういった面で新しいAPに合った新しいUIデバイスが早く現れて欲しい。

.....................................................................................................................................

2007/01/24

今日は色々と考えることが多い日だった。当たり前なのかも知れないが若い人も皆真剣に生きているんだなあと感心。私も見習わねば。

.....................................................................................................................................

2007/01/22

VS上でCLAPACKがうまくリンク出来ないのを解消するため、LAPACK/BLAS互換ルーチン(と言ってもdgemmとLU分解、逆行列くらい)を書いて、RTKLIB ver.1.0の開発完了。現行、実行時間の8割位dgemmで食っているので互換ルーチンを使うと倍くらい時間がかかるがまあ仕方ない。これで完全に標準C(89)のみで構築出来るようになったので、可搬性もほぼ目標通り。

.....................................................................................................................................

2007/01/21

昨日の移動体キネマティックは、東京海洋大 院生向けRTK講義用に開発した(大体終わったので過去形) RTKLIBと呼ぶC言語ライブラリを使用した、後処理基線解析プログラムRNX2RTKPを使った結果である。RTKLIB開発の一つの目的は講義用測位アルゴリズムの検証であるが、もう一つは実用的で可搬性の高い測位演算ライブラリを、測位の勉強や研究をされる方のベースとして提供できればと考えての事である。従って新しいアルゴリズムや複雑な手法はあえて避けてconventionalで簡潔な方法のみ実装した。また頑張って単体試験ルーチンやマニュアルも整備した。了解が得られればソースプログラムも含めて一般公開したいと考えている。

前から世の中の多くの基線解析プログラムや受信機ファームウェアのキネマティック測位性能について予想されるものより悪すぎるという印象を持っている。これはちゃんと評価をした上の話ではないのでうかつな事は書けないのだが、今回実際に実装をして有る程度の評価を行いその感を強くした。製品の実装のせいでRTK-GPSの真の実力が過小評価されている可能性も高い。移動体のRTK応用にはまだ技術開発要素は多いのであるが条件の良い環境では充分に使えるという印象も受けた。この辺も今後もう少し突っ込んでみたい。

.....................................................................................................................................

2007/01/20

まいったな。バックワード+スムーザを入れたら移動体キネマティック測位のFIX率が95%を越えてしまった (バックワードが入っているのでRTKではない) 。これは少し良すぎる気がする。問題はこの中にどれだけミスFIXが含まれるかだが移動体は検証が難しい。なにかうまい手はないだろうか。
ちなみに昨日のケースのスムーザ解。概ね綺麗な解が得られていることが分かる (なお昨日の結果の飛びはどうもスリップではなくDOP条件が悪くFIX解でも誤差が大きいのが原因らしい)。
この例は移動体と言っても割と条件の良いケースなのだが、別に特別なことをやっている訳ではなく普通のRTKアルゴリズムを地道に実装しただけである。うーん、某後処理基線解析ソフトのFIX率があんなに悪いのは何故なのだろう。

.....................................................................................................................................

2007/01/19

移動体RTKでスリップを旨く捉え切れていない事例。左下(南西)から右上(東北)への自動車走行で信号待ち停止直前に東南に10cm近く解が飛んでいる。瞬時AR結果(所謂epoch-by-epoch)では飛びは出ていないので、多分1cycleスリップを検出出来なくて測位解が飛んでしまっているのだろう。衛星数が少ないのでAR検定でも引っかからない。移動体ではこの手の微少スリップが結構頻発するのだが検出は難しい。こういうケースでは受信機側がトラッキングをあきらめてくれればいいのだが、下手に頑張り続けてしまって余計処理を難しくしている。多分受信機を移動体用にチューニングすれば改善すると思うが、現行受信機は測量用に使われる事が多いので必ずしも移動体用には最適化されていない。解析結果を細かく分析するとこの手の問題が見つかって面白い。

.....................................

IGS Workshop 2006, ESOC Conference Centre, Darmstadt, Germany, 8-12 May, 2006
2006年5月に独ダルムシュタットで開催されたIGS Workshop 2006の論文がいつの間にかDownload可能になっている。頁の上の方の"PAPERS (click here) Nov-2006"の所から論文一覧に飛ぶことが出来る。IGS解析仕様切り替わりの節目のWorkshopであり技術的にも興味深い。精密測位研究者にとって必見だろう。

.....................................................................................................................................

2007/01/18

閏秒切り替えで頭ぐちゃぐちゃ。コードを書く毎にいつも訳が分からなくなる。こういう時は具体的に書き出してみる。leap secを入れない時刻表現では通常UTCの23:59:60を表現できない。Cの標準時刻ライブラリでも、標準型 time_t は特定の日時からの累積秒で表されることが多いのでleap sec切り替えを挟んだUTC - UTCをdifftime()で求めようとすると正確な値を求められない (これは言語仕様)。従って時刻差を取る場合、GPSTで差をとらなければならない。time_t は1970/1/1 00:00:00UTCからの累積秒で実装されるので、64bit整数を使えない処理系では32bit整数のオーバーフローにより2038/1/19以降正常な処理が行われなくなるという、いわゆる2038年問題が発生する (wikipedia)。最近のマシンでは64bit整数で実装されることが多いようで問題は起きないらしい。まあ31年後のことなのでまだあんまり考えなくてもいいのかも知れない。全く時刻は色々と難しい。

そういえばUTCにおけるleap secondの取り扱い方法が変更になるという話が何処かで出ていたはずだがどうなったのだろうか。

.....................................................................................................................................

2007/01/17

RTK測位に関し面白い研究テーマを見つけた。1/15に書いた移動体RTK測位結果についてご質問を頂きそれに関連して思いついた。内容は秘密。実用的には大変有用な手法。多分誰もやっていないと思うが。理論的にはうまく行くはずだが、色々と評価してみよう。

.....................................................................................................................................

2007/01/15

電子基準点3.3km基線での1年分のRTK測位FIX率がやっと97%を越えた。なるべくシンプルにと思いながら結局色々と入れてしまった。(E-W, N-S, U-D)。移動体RTKもやっとFIX率が80%を越えた。概ね目標に達したので整理の方向。後はライブラリの単体試験ルーチンを書いて文書をまとめてひとまず終わり。しかし予想以上に信頼性の高い単独測位の実装が難しかった。例えば単独測位の誤差モデル一つとっても沢山の観測データの統計をとってちゃんと評価をした文献は少ない。誰かこういう地味で基礎的な研究を進んでやろうという人が出てこないだろうか。

覚え書き: 最終的に採用した単独測位コード観測誤差モデルσ²=a²+b²/sin²(el)+c²I² (a=1.5m, b=1.0m, c=0.3, I:電離層遅延モデル)
係数は移動体短基線RTKで値を振ってみてFIX率最大となる値で決定。FIX率: TEST8=62.661.8%, TEST11=85.085.5%

.....................................................................................................................................

2007/01/12

S.Jin et al., Impacts of Stochastic Modeling on GPS-Derived ZTD Estimations, Geomatics Research Australasia, 2004
対流圏推定における搬送波位相観測誤差モデルの評価。以前一度張っているはずだが備考録を何度検索しても出てこないので再検索。評価の結果、最終的にRTKプログラムにはBernese形式σ²=a²+b²cos²(el) (a=3mm, b=3mm)を採用することにした。(追記: 最終的にはまた気が変わってGAMITのσ²=a²+b²/sin²(el) (a=34mm, b=23mm) 形式を採用。本当は基線長依存項を入れた方がよいかも。1/15)

2004年1月2日に発生したGPS衛星の特異現象について, 海上保安庁交通部計画運用課
RTKプログラム試験で2004年1年分のデータを流し始めたら初っぱなから異常。てっきりプログラム問題かと思って色々調べても原因不明。事後残差を見るとPRN23が臭いとにらんで除外するとOKとなる。お手上げと投げ出しそうになったら、どうも有名な衛星側の障害だったよう。電子基準点 三浦2の疑似距離観測データ。搭載原子時計障害でかつ衛星ヘルスが正常となっていたらしい。この手の障害はRAIMを入れないと対応は無理なのでとりあえずあきらめることにする。(なお、GTでは単独測位にRAIMが入っているし残差検査でも引っかかるはずなのでちゃんと動けば自動的に障害衛星を除外してくれるはず。この辺のQCは実用APでは手を抜けない所。)

.....................................................................................................................................

2007/01/11

検索頁にGoogle Scholarを追加。

日本地球惑星科学連合2007年大会, 幕張メッセ国際会議場, 2007/5/19-24
予稿原稿締切 2/14 12:00。忘れないように張っておく。

ION GNSS 2007, Fort Worth Convention Center, Texas, USA, 25-28 Sep, 2007
アブスト締切 3/7。今年はIONに何か出してみようかなと思っているので張っておく。

梅田, 平野, ウェブ人間論, 新潮新書, 2006
ウェブ進化論の梅田と作家 平野啓一郎の対談集。インターネット特に新しいウェブ(Web2.0)が人間生活をどう変えるか。正直あんまり面白く無かった。自分自身を考えてみると、インターネットが、普及し始めて10年ちょっとしかたっていないとは信じられないほど必要不可欠なツールとなってしまったことは否定しないが、大多数の人間生活を根本から変えるような変革力を持っているとも言い難い。その点明らかに携帯電話の方が影響が大きい。梅田もこの点では案外と保守的な見方をしている所がさすがという感じ。それが商売だから当たり前なのかもしれないが、梅田氏というのは新しい技術の勘所や可能性といったものを万人に分かりやすく伝えるという面で大変優秀な人だなあとは思った。私も少しは見習わねば。

Google Scholarがどれくらい有用なのか確認するため昨年1年間で読んだ論文の数を数えてみた。備考録に記録した論文誌または会議論文のみ。全47件。週あたり1本弱。殆ど研究者とは呼べない数。
検索でどんなに良質な情報のインデックスが得られても内容を読まなければ無意味。その点、読んで理解する側のキャパシティが追いついていないから明らかに情報検索精度が上がっても研究の質が大きく変わるわけではない。広く浅くあるいは専門外の研究を短い時間でキャッチアップするには有効かもしれないが、ちょっと深いところまで突っ込もうとすると情報検索の効率はそんなに重要な要素ではない、という至極真っ当な結論に行き着く。ということで少し安心した。

.....................................................................................................................................

2007/01/10

梅田, ウェブ進化論 本当の大変化はこれから始まる, ちくま新書, 2006
ずいぶん前から話題になっていた本。遅ればせながら読んだ。現在Googleを中心にインターネット上で起こりつつある大変化、いわゆるWeb 2.0について平易にまとめている。筆者はシリコンバレーでベンチャを経営するITコンサルタントで技術的なツボは押さえていているし大きなトレンドを掴まえるには良い本。でも私には後半は退屈で途中で投げ出したくなった。
確かにGoogle EarthやGoogle Scholarの出来を見ると、混沌としたWebから価値ある上澄みをすくい上げる技術に関してGoogleは圧倒的でGoogleの覇権は当分揺るがないだろう。これは例えばライバルとされるYahoo!のディレクトリに登録されているGPS関連サイトとGoogle Scholarで検索できるGPS関連文献の品質を比較すれば簡単に実感できる。研究者や技術者にとってGoogle+Webというツールは使えるのは当たり前で、そこをスタートにしてどれだけオリジナルで価値ある仕事が出来るかが問われる訳でより厳しい時代であるとも言える。でも本当はバーチャル空間から半自動的に提供される情報より、身近な生身の人間との議論や泥臭い実践が本質的に重要なのだと言いたい気分もある。

.....................................................................................................................................

2007/01/08

Google Scholar beta
学術論文、資料、要約、記事のみ検索できるというGoogle Scholar。これは凄い。引用元を辿っていくとどんどん重要な論文が検索できる。いいもの見つけた。試しに"GPS PPP"で検索してみると...。結構ウチの頁が上位に来るではないか。うーん、これは信頼性が高いと言えるのだろうか...。

RTKライブラリ/プログラム引き続き。位相バイアスの初期分散を大きくするとlambda最初のL'DL分解でコケる原因を調べていたらやはり共分散行列の正定値性が崩れている。標準カルマンフィルタの数値演算誤差の問題らしい。仕方ないのでSquare Rootフィルタに置き換えるか。そうすると共分散もコレスキ分解のまま持ち回りたいし色々と修正は必至。コードが増えるとアルゴリズムの本質が見えにくくなるのであまり増やしたくないのだけれど。

.....................................................................................................................................

2007/01/07

窓の外では雪煙が舞っている。また本格的な雪。今日は静かに休養。

.....................................................................................................................................

2007/01/06

久しぶりの本格的な雪。もう10cmは積もっているだろうか。統計を取ったわけではないが雪は週末に積もる事が多い気がする。と言ってもこの辺では一冬に3、4回、多くても30cm位しか積もらないから、大した雪とはとても呼べないのだが。

NMEA 0183 Standard, National Marine Electronics Association
NMEA-0183 GGAセンテンスの規格が知りたくて調べた。ホントはちゃんとした規格書が欲しいのだが$270もするのでパス。NMEA-0183もいい加減な実装や、勝手な拡張が多いようでWeb上でも厳密な解説は殆ど無い。桁数とか適当でいいのかなあ。地図ソフト等でNMEA GGAが入力できるものが多いのでその対応。ついでなのでRTKライブラリにジオイドモデル (EGM96) の組み込み。

gcc -O3でコンパイルするとたまにlambda reductionで無限ループに陥るという問題点発見。比較演算が微妙で最適化すると数値演算誤差のためループから抜けなくなる。最適化しないとこの状況は発生しない。デバッグプリントの位置で症状が変わるという原因究明が難しいやっかいなバグ。演算誤差を考慮し比較演算することで解決。

G.Gendt, Combined IGS clocks with 30 second sampling rate, IGSMAIL-5525, 5 Jan, 2007
とうとうIGSが正式に30s間隔時計プロダクトの提供を始めたようだ。GPS week 1406 (2006/12/17-) 分から従来の5min時計とは別ファイル (igswwwwd.clk_30s) で提供するとしている。4 ACの30s時計をcombinedして作成するらしい。まあ遅すぎたくらい。時計サマリファイルを見てみると4 ACとはCODE, EMR(NRCan), JPL, MITの様。確認していないがcombineするということはJPL 30s時計の変なノイズは既に修正されている可能性が高い。IGSで進められている再解析でも30s時計は作られる予定の様なので、今後キネマティックPPPにおいてはこのIGS 30s時計を使うのが標準になるだろう。CODE 30s時計で良く見られるday boundary付近の雑音問題が解決されているか興味があるところ。GT0.7.1でこの時計のサポートを追加せねば。

.....................................................................................................................................

2007/01/05

GPSTk, The University of Texas at Austin
GPSTk (GPS Toolkit) と呼ぶC++ベースのオープンソース測位アルゴリズムライブラリ。ライブラリを使ったアプリケーション(AP)も含まれる。参考のためソースをダウンロードして幾つか読んでみたが出来は悪くはない。ただライブラリのソースファイルが(ヘッダを含めて)300近くも有り多すぎるし、全般にプログラムも冗長で長すぎる。単にライブラリとして使うにはいいかも知れないが、読んで勉強するには向いていない。これはC++だということも影響しているだろう。vecsolと呼ぶ基線解析(相対測位)APが付属しているがmain()ルーチンが1000行近くもあるのでそれだけで読む気をなくしてしまう。もっとずっとコンパクトで実用的なライブラリとAPが欲しい。...と書きながら実は今開発中のRTKライブラリとそれを使ったRTKプログラムはその辺を狙っているのだが。

NGA: DoD World Geodetic System 1984, NIMA TR8350.2, National Geospatial-Intelligence Agency
ちゃんとWGS84で定義された定数を知りたかったので検索。GPS-ICDでは地球重力定数及び自転角速度に関しWGS84値として3.986005x10¹⁴と7.2921151467x10^-5の値を採用しているが、TR8350.2では3.986004418x10¹⁴と7.292115x10^-5となっており微妙に異なる。これは古いWGS84で定義された値を使っているということなのだろうか。どちらを使っても差は殆ど出ないが、少し気持ちが悪い。まあGPS-ICD値を使うのが妥当だろう。

.....................................................................................................................................

2007/01/04

近年珍しく殆ど仕事をしなかった年末・正月だった。そのため頭が回っていない。年賀メールを書いたり、Webを巡ったりして少し頭のリハビリ。さて今年は何から始めればよいのだろう。

.....................................................................................................................................

2007/01/01

新年あけましておめでとうございます。本年も昨年同様にご愛顧よろしくお願い申し上げます。

.....................................................................................................................................

〜2006/12/31