天文航法の続きをお届け致します。...FlightGearの太陽の動きに隠された、誤差のパターンを発見しました。全部ではないでしょうけれど、何とかシッポを捕まえました。現行のVer.2.0.0は、機体を起動する際、パソコンのクロックが指している時刻や、その設定がUTC(世界時=GMT)かJSTかによって、仮装の太陽の南中時刻や位置が微妙に変化します。本来は、FlightGearを午前中に使おうが夜中に起動しようが、シミュレーションの太陽の南中時刻は当然、常に一定で、今年の天測暦や理科年表に載っているデータから割り出した値と、正確に一致しないといけません。実際は最悪の場合、時刻にして約2分も狂うのです。南中時刻が2分も狂うと、これをもとに行った位置計算は、経度にして約30分(日本の緯度ですと、距離にして20nm弱)も狂います。言えば、太陽の南中時の高度角も、パソコンを使用する時間帯によって1日1回、不連続に変化します。これはFlightGearが、ある時刻まで前日の「均時差」(天文学的データの一種。太陽の実際の南中時刻と、平均太陽時の正午との差)を引きずってしまうからですが、当日のデータに切り替わる時間帯は、経度などによって変化します。過去の天測計算に、時々大きな誤差が出たのは、主にこれらが原因だったようです。約3年前の挑戦では、世界各地で、異なった季節・時刻に何十回天測を重ねても、誤差のパターンがまったく読めませんでした。これは、従来の天測と計算の方法が、かなり複雑だったことも原因の一つです。研究することにしました。最初は、できるだけ観測条件と計算方法を単純化するため、観測地もそのものずばり、グリニッジ子午線(経度ゼロの線)の真上とし、ついでにパソコンのクロックも、UTC(協定世界時=GMTと同一)に合わせてしまうことにしました。予備実験では、FlightGearが天体のデフォルト位置を計算するのは、FlightGear自体の起動時ではなく、機体の起動時であることが分かりましたので、パソコンのクロック設定時刻を3時間間隔で変化させながら、シミュレーション上の「noon」に機体を起動し、太陽の正確な南中時刻と高度角を測定しました。するとデータ分布に一定の傾向が感じられましたので有望と思い、クロックをJST(日本標準時)に再設定して同じ観測を行い、さらにJSTの子午線(明石市の東経135度線)を新たな観測地に選んで、同様に観測を重ねました。これらのデータをExcelに入力して緯度経度と誤差を計算し、グラフで比較したところ、いずれの場合もグラフはほぼ同一の、Z字型に近いパターンを描きました。...「ビンゴ」ですね(^^)/。誤差のパターンさえつかんだら、補正できる可能性が生まれます。誤差曲線を、完全にフラットにすることは困難でしょうが、実用上、あまり支障のない程度に抑えることは、十分に可能だと思います。皆さんもご存じのように、フライトシミュレーターで天文航法(別名・天測航法)を行う試みは以前からあり、すでにFlightGear用の六分儀が開発されています。英空軍のMk9気泡六分儀(バブル・セクスタント=水平線の代わりに水準器を使う型)をモデル化したもので、現在はショート・エンパイア飛行艇をダウンロードすれば、副操縦士席から起動できます(しかしダイヤル類の正しいクリックポイントが分からず、うまく操作できないので、私は自分で開発した「フライト・コードラント」だけを使っています)。Alioth(ともに恒星名)を使って2本の位置の線を求め、その交点から緯度経度を出したところ、実際の値に対し約40キロの誤差が生じたと述べています。これは約20nmにあたりますので、私の限られた観測結果からみても、ほぼ日中にパソコンを使った場合の、誤差の範囲内に含まれると思われ、十分に納得できる数値です。私の場合、誤差の補正テストはこれからですが、例えば5月や6月の季節ですと、「パソコンのクロックを、23時ごろにセットしてから機体を起動する」という工夫をするだけでも、恐らく経度計算の誤差を、Mk9六分儀の作者さんの半分以下に出来るのではないか、と考えています。以下に、少し詳しいお話をさせていただきます。●RAFビギンヒル基地...すべては、この丘から始まった:正午の太陽の観測地を、経度ゼロのグリニッジ子午線上と決めましたが、フライト・コードラント(航空四分儀)を装備したピラタスPC7改をどこに駐機するか、しばし考えました。こと、グリニッジ天文台の位置ではどうでしょう。ロンドン・シティ空港(EGLC)で起動すると、グリニッジはすぐ西です。ロンドン都心部に向かって、都市テクスチャーの上をタキシングするのも、リアリティーを欠いて味気ないので、南方約10nm(ノーティカル・マイル=海里。定義を書くことにします)にある、英国空軍のビギンヒル基地(EGKB)を起動地点に選びました。1nmほど西にグリニッジ子午線が走っており、そこいら中が牧草地や農地ですので、上がってすぐ降りて、子午線上に機体を駐めることができます。ここはバトル・オブ・ブリテンの間、ロンドン防衛の最前線でした。猛爆に遭い「地獄のビギン」と呼ばれましたが、ここやマンストン、タングメア基地などに布陣した戦闘機集団が、数では圧倒的に優勢なドイツ空軍を、海峡の向こうに押し戻したわけですね。私も、ご挨拶代わりにまず、スピットファイア2型で発着を試みました。エンジンのかけ方が少し複雑ですが、よく分かるチュートリアルがあります。この機体は、火薬カートリッジでロールスロイス・マーリンを始動することを、初めて知りました。止めて再始動する場合は、パネル右下のレバーをクリックすると、2発目のカートリッジが装てんされる仕組みです。尾輪式にしては離陸が簡単、空に上がると軽快な飛行機で、機体の迷彩によく似た大地を背にクルクル回っていると、「空軍大戦略」の勇壮なマーチが聞こえてくるような気分。アプローチではなかなか減速せず、脚が狭いので接地時の安定も悪く、うわさ通り着陸は難しいですが、ハイになれる楽しい機体です。本題に戻りますが...太陽の観測テストは、次のようにスタートしました。ピラタスPC7改でビギンヒルを離陸し、すぐそばの経度ゼロ線上の農地に降りて、機体を真北に向けました。経線はテクスチャーの継ぎ目で、かすかに勾配があって機体が傾きますが、搭載したフライト・コードラントは自動的に水平を保ちますから、特に問題はありません。今後は観測のため、正確に同じ場所で数十回の起動を行いますので、緯度経度を詳しく記録し、さっそくビギンヒル基地に「PrimeMeridian」(本初子午線=経度の原点を意味する、グリニッジ子午線)という名称で、parking(機体起動)地点を新設しました。以後は起動ウィザードから、一発でここへ来られます。Parkingを設けました。●カギを握る「均時差」:太陽の南中時刻と高度角の測定は、できれば通年にわたって均等に、例えば毎週分のデータを取って整理したいのですが、とても無理なので、当面は観測対象を、今年の5月21日とその前後、また6月15日、10月1日など数日に絞りました。これらの日付なのかといいますと...マイアルバムにアップロードさせていただいた、「太陽の誤差を捕捉」の説明図をご覧下さい。右下に、ピンクのラインで「均時差」のグラフを入れてあります。均時差とは、教科書的に言いますと「視時(太陽が示す時刻。毎日異なる)から、平時(年平均を取った標準時刻)を引いた値」です。分かりやすく言いますと...地球から見た、太陽の動く速さは周期的に変化しているため、グリニッジで太陽が南中するのは、グリニッジ標準時の12時ちょうどではありません。どのくらい前後にずれているのかを、年間を通じて示したのが、均時差(標準時に対する観測値の進み遅れ)です。この値をどの程度、フライトシミュレーターが正確に再現できているかが、フライトシムの上で天文航法を行う際、経度の計算精度を、決定的に左右する要因となるはずです。先ほどのグラフをご覧頂けばお分かりの通り、均時差はちょっとだけ複雑な二次曲線を描いており、年間を通じて最大値と最小値のほかに、小さなピークと谷が1カ所ずつあります。小さな谷:7月27日の−6分32.9秒となっています。これら最大値や最小値、ピークや谷の部分或いはその周辺では、FlightGearが示す南中時間などのデータに、それと分かる特色が出るのではないかと期待しました。データがどう変化するか、或いはしないかが分かれば、おのずと誤差を修正する方法が見えてくるはずですので、そうした狙いで、先ほどお話しした観測日を決めたわけです。均時差は、理科年表(ポケット版1400円、机上版2800円)に、1年分が毎日に分かれて載っています。収録しているのは、UTC午前0時の値だけです。均時差は1日当たり十数秒変化するので、実世界で精密に天文航法をする場合は、観測時刻を分単位まで特定して補正計算しますが、FlightGearではアプリ固有の誤差の方が格段に大きいので、このままでも一応は役に立ちます。(ご参考:実世界の天測では均時差の代わりに、計算に便利なように12時間を足した「E値」というデータを使います。天文航法のデータブック「天測暦」(海上保安庁が毎年発行)には、このE値とd値(デクリネーション=視赤緯:天球上の緯度に当たる値)が年間の毎日分、2時間おきに細かく収録してあります。細かい時刻補正をするため、案分計算のテーブルも付属しており、これらを眺めていると天測計算が、いかに面倒であったか、よく分かります。六分儀による天測と位置計算は現在、消滅したわけではありませんが、すでに専用のプログラム電卓があり、ずっと簡単になっています)●計測の実際:一例を挙げますと...まずWin-XPのカレンダーを開いて、タイムゾーンをUTC、日付を5月21日、時刻を午前0時にセットし、FlightGearを起動。選び、経度ゼロの畑の真ん中に機体が出現します。続いて、ビューをコクピットからフライト・コードラントに切り替えて、太陽が見えるまでカメラをパンアップ。メニューバーから「Time」を起動し、太陽がカーソル(観測のため、再び真南の位置に固定としました)の直前に来るまで、時間を巻き戻し。ここでXキーを使って、カメラの画角が「FOV=3.6」になるまでズームアップ。Timeの加速を使って、太陽をカーソルに近づけ、1倍速に落とし...太陽の中心点がカーソルに重なった瞬間、ポーズを掛けてUTC時刻表示を読み、カーソルの目盛りで高度角も記録します。太陽が、UTC時刻の正午(グリニッジ子午線上の場合。明石なら午前3時)の手前で南中した場合は、いったんポーズを外し、Time操作で時間を調節して、シミュレーション時刻をUTC1159時59秒にセット。ポーズを掛けて、マウスポインタを正確に太陽の中央に合わせます。いうと...FlightGearのシミュレーション時刻が、現地ローカルの12時になった瞬間、太陽がほぼ真南から西へ、方位にして約1度、瞬時にジャンプすることがあるからです。マウスポインタを画面に置いておけば、太陽の移動距離を物差しで測り、計算で方位角に置き換えて、正確な位置を記録できます。5月にもご紹介しましたこのジャンプは、FlightGear内部の天体の動きの誤差を1日1回、ローカル時刻の正午にまとめて或る程度、修正するための手段だと思います。後でお話ししますように、FlightGearの経度の誤差は、正午に不連続な大変化をしますので、間違いないでしょう。問題は、このジャンプが真南をはさんで起こるケースです。私は「子午線ジャンプ」と呼んでいますが...太陽がカーソルの左側から右側に一瞬で飛んでしまい、南中の瞬間が計測できません。この場合は、太陽が11時59分59秒にカーソルの何ミリ左にあるか計っておいて、仮にジャンプが起きなかったら何時何分何秒に南中したかを計算すれば、実際の南中時刻の代わりに使えることが分かりました。ややこしいお話が続きましたが、ざっとこんな手順を経て、次に一部分をご覧に入れるような、観測メモが出来上がります。煩雑な説明は省略しますが、おおよその雰囲気は、お察し頂けるかと思います。マイアルバムにアップした誤差グラフは、すべて3時間間隔でデータをプロットしていますが、実際の観測と計算では、不連続な誤差変化が、いつ起きているか...などを調べるため、数分おきに計っている部分もあります。▼5月21日ビギンヒル・GMT設定。均時差は+3分27.5秒、d値は+20度4分8秒。再起動は、FlightGear本体と機体の両方で。距離(�)起動時太陽は通り過ぎてる。58.83▼子午線ジャンプはこれ以降。これ以降子午線ジャンプは起きない。▼同じく5月21日ビギンヒル、今度はクロック設定のみJST。観測時刻はもちろんGMT。なし(59秒でカーソル左67mm)ローカル12時にも13時にもなし。なし▼9時過ぎには当日の高度角になる。なし●データを集計し、グラフ化する:約1カ月間に、ビギンヒルと明石で総計70回ほど天測しました。計算式と、太陽の南中時刻に均時差を加味して経度を出す式、それに緯度経度の誤差を算出してグラフ化する仕組みを、Excelのワークシートにまとめ。これを使って、取りあえず5月21日の観測分(クロック日付を修正し、後日計ったものが中心)のデータを、ビギンヒルと明石、それぞれUTCとJSTの合計4通りについて整理したところ、以下のような原則が見えてきました。(1)緯度の誤差は、起動時刻が異なっても基本的には変化しない。午前0時から一定時間は、誤って前日の均時差が適用されるという問題があり、かなり大きい誤差が出る。緯度の誤差は、1日1回だけ不連続な変化を起こし、以後同じ値が終日続く。クロックがUTC設定の場合と、JST設定の場合を比較すると、不連続な変化が起きる時刻が、両者の時差の9時間分だけずれる。(2)経度の誤差は、午前0時が最小で、以後正午までプラスの値を取り直線的に増加する。正午に不連続な変化を起こし、誤差の値がマイナスに転じて極小値を取り、以後は夜半まで直線的に増加する。午前0時前には再び、誤差がほぼ最小に戻る。(3)均時差が、大きな変化率で減少中の6月15日や、年間最大値の直前となる10月1日でも、グラフの形は、これとほぼ同じになる。経度の誤差の値は変化する。緯度の不連続な変化の量と、発生する時刻も変化する。...こんな次第で、まだ年間を通じ、未確認の季節変化や観測地点による変化が多々ありそうですが、基本的には非常にリニアな形で、誤差のパターンが見えてきました。●ようやく、実用テストが目前に:本連載を長くお読み下さった方はご存じのように、私は08年の秋、FlightGearによる世界一周フライトで南米を通過中、初めて天文航法に挑戦しました。当時は、かなり正確に位置が出た直後、いきなり大きな誤差が飛び出して、途方に暮れました。誤差の構造が全く見えず、いくら仮説を立てても検証するたびに覆り、まるで蜃気楼を追いかけているような気がしたものです。今回は意識的にアプローチを変え、かなりマシなところまで来れたようです。言え、実用化までには、まだ何が起きるか分かりませんが...(^^;)。この調子で天文航法が、或る程度リアルに再現できますと、GPSの不便(かつロマンチック)な代用品にはとどまらず、フライトシミュレーターの、より奥深い味わいを発見する、新たな手段になりそうな予感がします。