2007/01/01〜

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

2006/12/30

年末モード。掃除、買出し。

今年を振り返ると色々と新しい人と巡り会えて、勉強にもなったし楽しい年だったという気がしている。基本的に私は技術バカなので、人と議論をしたり、新しい方式をウンウン考えたり、コードを書いたりすることが多分好きなのだ。そういった事に多くの時間が使えたという意味で今年は幸せな年だったという気がする。来年はどんな年になるか分からないがまた楽しい出会いが有りますように。皆様も良いお年を。

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

2006/12/28

RTKモジュールを使った後処理基線解析プログラムrnx2rtkpの精度評価。とりあえず電子基準点を使った3.3km基線での精度及びFIX率評価1年分 (結果)。3日程推定が破綻している日があるのでこれは原因を調査して改良予定。少しFIX率が悪いのでこれも改善しよう。昨夜流して寝たのだが30s間隔1年分で22分しかかかっていない。やっぱりCは速いなあ。はやくGTの推定エンジンも全C化したい。1epoch当たりの処理時間22×60/(2880×366)=1.25ms。ただしこれにはcompact RINEXの解凍時間やファイル入出力が含まれているから実効時間は0.5ms/epoch以下のはず。ARは殆ど速度には効いていない。

せっかく30s間隔1年分のキネマ解析をしたので名大 太田さんの真似。(測位誤差 m : E-W, N-S, U-D)。条件は2004/1/1-12/31。電子基準点 三浦2 (基準点: 三浦1, 基線長: 3.3km)。2周波-キネマティック相対測位-FIX解。ARはlambda/mlambda。検定はratio test (スレッショルド=3.0)。データが抜けているのはFIXしていない所。午後から大掃除の予定なので、今年はとりあえずこれでお終い。

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

2006/12/27

覚え書き。Visual C++用コンソールアプリケーションの設定。
・新しいプロジェクト - Win32プロジェクト - アプリケーションの設定 = コンソールアプリケーション
・C/C++ - 追加のインクルードディレクトリ = includedir
・C/C++ - プリコンパイル済みヘッダーの作成/使用 = 使用しない
・リンカ - 追加のライブラリディレクトリ = libdir
・リンカ - 入力 - 追加する依存関係 = lib.lib
ずいぶん久しぶりにVisual Studioを使ったが相変わらず訳が分からない。

さすがにintel C+MKLはgcc+standard-lapack/blas に比べ2倍近く速いのだが、(補足: gccに-Oオプションをつけるのを忘れていた。-O3オプションをつけたらicc+mkl:4.0秒, gcc:5.5秒位にはなった。約6500エポック分相対測位、C2D 2.4GHz。13:46) MKLをスタティックリンクするとexeが1MBを越えてしまう。ちょっと大きすぎ。dll版もあるのだがmkl.dllの無い環境では動かないし、もう少し何とか小さくならないだろうか。

C99のisnan()やnan()をポータブルな方法で書こうと頑張ったが、難しいことが分かって結局その部分は書き直し。とりあえずこれでANSI C(89)準拠になったので、ほぼどんな環境でもコンパイルできるはず。まあ以上を読めば今日何をやっているか大体分かるはず。

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

2006/12/26

去年の年末の日記を見ていたら今年とあまり変わらないことをしていたことに気付く。この1年結構色々なことをしてきたつもりではいたのだがよく考えると大した進歩はしていない。結局人の通ってきた道を辿って追いつくのは容易でも、そこから新しい一歩を踏み出すのは大変なのだよなと改めて感じる。まあ食えている範囲においてとりあえずもう少し続けてみたいとは思う。
何となくもう仕事納めという気分になっている。ちょっと早いが。

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

2006/12/23

快晴。空気が澄んで山も綺麗。年末で色々と細かい雑事が溜まっている。とりあえず今日明日はそれらをこなす予定。

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

2006/12/22

しかし線形代数というのは実に強力なツールだなあと実感。線形の範囲で有れば複雑な方程式系を大変スッキリと表現することが出来る。LAPACKの使いこなしももう少し勉強せねば。

うーんまとまらない。1日頑張ったが納得いくコードにならない。結局スリップ検出や異常データ除外を入れないと実用にならないので汚いグチャグチャした部分が残ってしまう。この辺で妥協かなあ。でもここで妥協するなら最初から頑張らなくても良かったという気もする。段々と改良方向が迷走を始める。プログラム開発の中盤で起こりがちな事態。こういう時は大局が見えなくなっているのでいったん寝かせて別のことをした方がよい。ということでci -l *.[ch] してmake backup。

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

2006/12/21

一昨日、昨日書いた件につき誤解があるといけないので補足。AmbiguityのFIX率は通常検定基準(統計的な信頼度水準)に拠って大きく異なる。すなわち原理的にミスFIXを0には出来ないので、ミスFIXをどの程度許容するかによってFIX率は全く異なる。従ってこの点を抜きにしたFIX率の値に意味はない。一昨日、昨日の結果は割といい加減な検定方法で検定基準もかなり甘くした結果である (甘くしないと全然FIXしないので)。まあ一つの参考例ということでFIX率についてはあまり真面目にとらないで下さい (実用的な検定基準でFIX率をもっと上げると言うのが一つの技術目標でもある)。
世の中の解析ソフトには、(多分検定基準を甘くしているせいで) FIX率は良いがその代わりミスFIXも多く、実用には非常に使いにくいというものも存在する様だ。

結局まずsingle-diffrenceで全部書いてからdouble-differenceへの変換行列を導入すればプログラムが非常にエレガントになることに気付く。covarianceもsingle-differenceは非対角項が出てこないし。よしこれで何とか250行に収まるか。何だかパズルを解いている様な気分。(でも以上を読んで内容が分かる人は殆どいないだろうなあ)

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

2006/12/20

昨日と同じデータの解析結果で街中。高さ成分も入れて表示。ビルの谷間ではマルチパスの影響か上下に100m以上飛んでいる解もある。相当厳しい条件。さてこれを何とかするのは可能なのだろうか。

RTKプログラム(開発中)の出力例 (赤:FIX解, 橙:Float解, 緑:単独測位解) (拡大)

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

2006/12/19

Google Earth KML 2.0 Tutorial
GPS測位結果をGoogle Earthで取り扱えるkmlファイルに変換してあげるとGoogle Earth上にウエイポイントや移動パスを表示することが出来る。Google Earthの座標系はWGS84の様で測位結果の緯度/経度/高度をそのままxmlファイルに落としてあげればよい。Google Earthの都市部画像は主に航空写真を使っている様で撮像角度の影響か数m〜10数mの誤差が出るが、既知点(ランドマーク)座標が分かっていればその点の画像ずれから有る程度の位置調整が可能。この方法で狭い範囲で有れば大体1m近くの精度まで合わせられる。これを使って開発中のRTKプログラムの出力結果を評価中だが、結果が実際の地球上にプロットされるのを見るのは大変面白い。プログラムに標準でkml出力機能をつけようか思案中。

RTKプログラム(開発中)の出力例 (赤:FIX解, 橙:Float解, 緑:単独測位解) (拡大) (観測データは海洋大 久保先生から頂きました)

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

2006/12/18

基準衛星切り替えのいらない定式化をちょっと応用するとゼロ差観測方程式系でARが可能となる。相対測位では精密暦は使用しないことが多いが、後処理でIGS Finalの様な高品質プロダクトを使わないのは勿体ない。衛星時計を含んだ精密暦を使いARも入れた相対測位は原理的には最も精度が出るはずの測位法である。(実はGIPSY-PPP+後処理ARはこれに近い)。研究ネタを書いてしまうのもなんだが一応この辺を当面の目標にしている。

江島, グーグルが無敵でないことはエンジニアだけが知っている, CNET Japan
測位と関係ない話題。Web界隈の技術者には怪しげな人間が多いわけで内容についてはパス。ただ以下のフレーズが面白かったので取り上げた。

>> それがどんなに先鋭的な専門分野であれ、口には出さずとも同等以上にわか
>> ってる奴はつねに100人はいる。それを論文にまとめたりブログに書いたりでき
>> るやつが10人ぐらいいて、本気でそれの実現に自分の人生を賭けるやつは1人
>> しかいないっていうだけのことさ。

自分が今やっていることについては100人はいないなと思っただけ。

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

2006/12/17

2周波を入れたら250行を越えてしまった。Cだと悩ましいインデックス操作とかも入れざるを得ないし、シンプルで美しいコードがどんどん汚いコードに浸食されていく。基準衛星切り替えがいらないのはいいのだがAR用に結局2重差にする必要があるのでこれだけで30行も食っている。少し性能が落ちるのを覚悟で簡素化するか。

参考のためGT0.7.1bによるPPP解。昨日と同一データ。全てGSI F2解比較。当然だが短基線FIX解が最も良い。なおPPPは3passのsmoothing解、FIX解はforwardのみの解であることも注意。PPPの数cmの大きな変動は短基線FLOAT解でも出ているので対流圏よりはAmbiguityをFIX出来ないことが大きく効いている様に見える。雑音レベルは短基線相対測位の1.5倍位でほぼ理論通りと言える。色々な手法で解析し比較してみると見えてくるものがあって面白い。

電子基準点 三浦2 (IGS Final軌道+IGS Final/CODE時計)。2周波-キネマティック-PPP解

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

2006/12/16

日本地球惑星科学連合大会 2007年レギュラーセッション

なんと春の連合大会 測地学会のレギュラーセッションからGPSが削除されてしまった。これは結局発表者が集まらないとの判断なのだろうか。これでは応用はともかく基礎研究は出すところがないという事になる (まあ測地学一般に出せばいいのだけど)。さて日本のGPS研究はどうなってしまうのだろう。

FIX解。後は2周波を入れて検定やスリップ検出をもう少しちゃんとやって完成の予定。基準衛星切り替え不要な定式化の件、種を明かせばどうってことはないのだがここでは書かない。世にある参考書や論文で書かれているのを見たことないし、うまく動くようになるまで結構苦労しているから。

電子基準点 三浦2 (基準点: 三浦1, 基線長: 3.3km)。1周波-キネマティック-FIX解

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

2006/12/15

やっと基準衛星切り替えのいらないRTKプログラムの定式化がうまくいった。受信機時計飛び問題を解決するためだけで3日以上かかってしまった。rtkdemoとあまり変わらない様に見えるがrtkdemoでは基準衛星が落ちると測位できなくなる。下記は24Hセッション解。プログラム本体はCで150行程度。簡潔なコードを書くのは実は凄くノウハウがいる。とりあえず満足なので今日は寝る。

電子基準点 三浦2 (基準点: 三浦1, 基線長: 3.3km)。1周波-キネマティック-Float解

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

2006/12/14

やっぱり寝不足で朦朧とした頭で書いたコードは品質が悪いなあ。結局不具合対応のためにせっかく寝ないで稼いだ時間を無駄にすることになる。早寝早起、日の出前に起きて暗くなったらとっとと寝る。といった生活習慣を義務づければ世の中のプログラムバグが激減するかもしれない。

Amazonで予約していたソフトGPS受信機の参考書届く。
K.Borre et al., A Software-Defined GPS and Galileo Receiver, A Single-Frequency Approach, Birkhause, 2007
DVDが付いているの何かと思ったら、Matlabで書いたGPS受信機コードと、サンプルとして実際に受信したGPSの生信号データ (DC後8bitサンプリング) が2つついている。そのうち1つにはGIOVE-A (Galileoテストベッド) の信号が含まれている様だ。本文内容はもう少し詳細が欲しいという感じ。でも貴重な参考書だとは思う。

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

2006/12/12

一昨日書いた件。測位に限らず正しい解を得るための道筋は一つでは無いわけで、どんな解法でも正しい解が得られれば別に何でもいいとも言える。その点、既にある方法をそのまま無批判に使うというのもそれはそれで解の一つではある。でも新しいことをやろうとすると普通色々と不都合がある訳で、簡単に言えば応用範囲に限界がある。その点をきちんと自覚する必要がある。
と書きながら無批判に使っている手法に関して、頭の中に小さな棘の様に引っかかって解決できていない事項が溜まってきてしまっているのだが。

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

2006/12/10

RTKプログラムを書いていて少し脇道にそれる。conventionalな解法で前からずっとしっくりこないのは衛星差をとるための基準衛星の存在。基準衛星のせいで衛星の昇降や欠測時に切り替えが必要になる。切り替えを入れる定式化は一応出来ているのだが綺麗な解とは言い難い。切り替えが必要ない定式化は可能なはずだがARもできて美しい形式にするのが難しい。もう一寸なのだが。

ところで一般的な測位アルゴリズムでは、線形結合を作ったり、二重差、三重差(これも実は線形結合の一種)を取ったりして、観測方程式系からパラメータの数を減らして解きやすくすることが多いが、これは基本的に解の精度を落とすことにつながっていることに留意すべきである。生の観測値が持つ情報を出来るだけ沢山引き出すためには、原理的にはパラメータを消去せずに取り扱う方が良い。12/4に示した解はその一つの例である。現在使われている測位アルゴリズムにはこの点でまだまだ改良の余地が残っている。

またARのために二重位相差を取ることが必須であるかのごとく思われることも有るがこれも正しくない。実は差を取らない観測方程式系でも原理的にARは可能である。従って線形結合も差もとらずかつアプリオリな制約や整数条件も全部入れて計算すれば今よりずっと解の精度や雑音が改善されるはずではある。と言っても誰もやらないのでちゃんとやって実証したいなあと言うのが今の目標。

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

2006/12/09

午前は某所から頂いたデータの1HzPPP解析。うーん条件が悪いのか結果が良くない。色々パラメータ調整したがあまり改善しない。
午後は講義用RTKプログラムのコーディング。見せる目的のコードはどうも格好良くエレガントにと考えすぎてなかなか進まない。でもパズルみたいでこれはこれで面白いのだが。

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

2006/12/08

GT0.6.3に結構酷いバグ発見。対応はサポート頁参照下さい。現実的にこの手のバグは多種多様な解析を行って不可解な結果を一つ一つ追っていかないと見つからない。この点では実績のある解析ソフトとの差は大きい。どう品質向上をはかるかは少し長期の戦略として考える必要がある。

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

2006/12/07

時計飛び時にちゃんと搬送波位相が飛ぶ受信機を見つけた。JPS LEGASY (IGS DLFT)。多くの受信機は時計飛び時に疑似距離のみ飛んで搬送波位相が飛ばないという明らかにおかしな仕様のデータを出力する(電子基準点は殆どこのタイプ)。現行GTでは仕方ないので前処理で時計飛び補正を入れられる様になっているのだが、このオプションをONにしていると今度は下のような(正しい)データで時計飛びをスリップと誤判定してしまう。どちらでもいいのだが統一をとってくれないと受信機毎にオプションのON/OFFを切り替えないといけない。この仕様の混乱は何とかして欲しい気がする。

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

2006/12/06

京大 平原先生、橋本先生のところを訪問。またまた少しだけ頭が整理された気がする。帰りの電車で色々とアイデアも思いついたし有意義な時間だった。貴重な時間を割いてお話を聞かせて頂いた研究者の皆さん、有り難う御座いました。

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

2006/12/05

GT0.7.1。ANTEXのazimuth角依存PCVを入れる改修。結構面倒な割に改善は微妙。

名古屋大 太田さんのところを訪問。GPSを主に地殻変動観測に使われている研究者の方々に話を伺う。現状GPS解析技術の足りないところや期待についてざっくばらんに話が出来て少しだけ頭が整理された気がする。

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

2006/12/04

GT0.7.1開発開始。まずは割と簡単で短周期ノイズに有効な改修。GT0.6.2結果と比較してノイズ低減が有効に働いていることが分かる。

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

2006/12/03

2日間休養。

今週は名古屋と京都でGPSを地震観測に使われている研究者の方々にお話をお聞きしてくる予定。せっかくここまで来たので、現実の地震研究に少しは寄与できる様、次のステップをどうするか頭を整理したいと言うのが主な目的。

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

2006/12/01

師走。月名には日本語の美しさが凝縮されている気がする。
睦月、如月、弥生、卯月、皐月、水無月、文月、葉月、長月、神無月、霜月、師走。

昨日書いた移動体GPS観測データの件、基準局用に建物屋上の固定点観測データ (同一受信機) も頂いたのだが、こちらは全くスリップは発生していない。移動体と固定点は全く状況が違うことが分かる。また別の移動体データをGraphNavで後処理解析 (短基線) した結果も頂いたが殆どFix解もFloat解も得られていない。現行では、昨日の様なスリップや欠損が頻発しているデータでちゃんと精密測位できる技術も解析ソフトも存在しない様だ。

忘れないうちにGPS地震計について昨日地震研で加藤先生や宮崎氏にお聞きした点を少しだけ。
・GPS地震計に注目している人は多いが現実に使おうとした時、フラフラとした長周期ノイズと真の地殻変動を区別できないので、なかなか使うという話にならない。
・GPSは秒〜年単位までの広範囲の時間スケールでシームレスな解が得られる点に大きなメリットがある。
・GIPSYはJPLに開発者が残っていない等の理由でここ十年くらいほとんど更新されていない。

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

〜2006/11/30