オランダ天測の旅

hideです。
　前回はロンドンから、スタンプSV4複葉機を駆って日本への旅に出発し、ベルギーの首都ブリュッセルに到着したところまででした。私が旅の間に実用化をめざしている天文航法は、最初の航程では大きな誤差が出てがっかり。しかし、必死に頭を振り絞ったところ、FlightGearの「時間」に関する設定のなかに、過去５年半に一度も使ったことのない機能が、一つあることに気付きました。さっそく試したところ…なんと、緯度経度の計算精度が劇的に改善され、実用的なナビゲーションに使えるレベルまで、一気に手が届いたのです。

　このまま精度が安定するのかどうか、まだ分かりませんが、今回はブリュッセルからアントワープを経由し、オランダの首都アムステルダムへ向かうフライトを通じて、この「天文航法、大躍進！」のご報告をさせていただきます。ちなみにアムステルダムのスキポール空港は、FlightGear世界でも指折りの素晴らしい出来映えで、とても感心しました。（マイアルバムもご参照ください）
　では、旅日記を始めましょう。

●天文航法に漂う、手詰まり感：
　ブリュッセルでは出発前、天測結果が比較的安定している、ピラタスPC7改を主に使って、地上や空中で、太陽の観測と計算テストを重ねました。緯度の誤差は＋1分30秒くらい（距離にして1.5nm内外）の場合が多く、ほぼ実用レベルと呼んで良さそうです。ただ経度は相変わらず不安定で、しばしば数十分の誤差が出ました。
　以前お話ししましたように、私がFlightGearで太陽の南中高度と時刻を計る場合、機体起動時にパソコンのクロックが何時を指しているかによって、機位の計算誤差が大きく変化する…という、不思議な現象が起きていました。しかし緯度経度の誤差をグラフ化すると、常に同じパターンに収束したため、仮に誤差の原因が突き止められなくても、機械的に実験を重ねて適切な修正値を得れば、ほぼ実用レベルの精度が得られるだろう、と考えていました。例えば私の環境では、FlightGearの太陽はしばしば、南中の直前や直後に西へ約1度、瞬間的に移動（ジャンプ）しましたが、これは24時間の太陽の動きの累積誤差を、まとめて調整する機能ではないかと考えて、試しに太陽の飛んだ距離（約1度）を2で割って経度の計算結果に足すよう、Excelの天測計算シートを改良してみたところ、5月〜7月半ばのカレンダーから数日を選んで日付と時刻を合わせるサンプルデータテストでは、かなりうまく緯度・経度計算が合いました。しかしその後もテストを重ねたところ、次第にこれが見せかけの安定であったことが分かり、特に経度計算には大きなエラーが不規則に発生して、まだ何か本質的な誤差要因を、見落としていると思われました。

　正直、手詰まり感が出てきたので、気分転換にまず、フライト・コードラントの細かな改良に手を付けました。ついでに天体観測のカーソルや、方位目盛りなどの部品を体系的にグループ化し直し、グループ名と同じファイル名で個別に保存して、全部品をアッセンブリー化しました。
　オブジェクトを改造する場合は、まず3Dモデリングソフトでファイルを開き、操作を加えるべきパーツを、マウスで選択することになります。が、これが細かい作業でして…最初は、うっかり部品の位置をずらしたり、壊したりしたものです。しかし、個々のオブジェクト名やグループ名がきちんと管理してあれば、名称の入力で一発選択できます。或いはコードラントをどんどん分解して、改造する部分以外を消去してしまってから、残った部品に手を加えるのでも構いません。そして改造を終えたパーツに、保存してあったアッセンブリー部品をどんどんマージしていけば、そのつど新品のコードラントが組み上がり、作業に起因する新たな誤差や欠陥を含まない完動品が、間違いなく手に入る…という次第です。これで改良作業は非常にシステマチックになり、我ながらいいアイディアだと思いました。（開発に慣れた方々には、この種の用心はもちろん常識でしょうけれど）
　こんなことをしている間に、かなり元気が出ましたので、さっそく旅を再開。天測の誤差解明も、そのうち手がかりが見つかるだろうと思い、ともかく気分を前進モードにします。

●スタンプSV4のふるさとへ：
　例によって、航法計画からご覧に入れます。
◎ブリュッセル国際空港EBBR　偏差ゼロ
　　　▼355度17nm
◎アントワープ空港EBAW　偏差ゼロ
　　　▼344度17nm
◎Woensdrecht空港EHWO　偏差ゼロ
　　　▼7度30nm
◎ロッテルダム空港EHRD　偏差ゼロ
　　　▼30度25nm
◎アムステルダム・スキポール空港EHAM　偏差ゼロ

　このコースの特色は、たまたま磁気偏差が存在しないこと。つまり磁気コンパスで読んだ針路が、換算なしに、そのまんま真方位になるという、実にありがた〜い区間です(^^;)。
　toshiさんのお陰で先日、晴れてリアルウエザー機能が復活しまして、この日は風向不定の2Kt微風、雲なしという上天気。スタンプSV4を満タンにしてUTC-1100時に離陸。ぐるりと旋回し、ブリュッセルをあとにします。ABN（飛行場灯台）が周囲に10カ所くらい見え、改めてヨーロッパの空港の多さに感心しました。長期にわたり「先進国」であり続けた社会の、インフラの厚みを感じます。
　ブリュッセルは、戦前から60年代まで続いた長編マンガ「タンタンの冒険」シリーズの、発祥の地。実際に訪れたことはありませんが、小学生時代と大人になってからと、このマンガに二度惚れした私としては、軽い親近感を覚える街です。タンタンは、高校1年くらいの気さくな少年で、職業はジャーナリスト。愛犬と世界中（や月世界）を旅して回るのですが、さんざん冒険や謎解きを楽しむ一方で、ほとんど記事を書いた気配がないのは、うらやましい限りです。（そういえば「美味しんぼ」の山岡士郎記者も、「ご飯を食べるだけで、ご飯が食べられる」という特技の持ち主ですね）(^^;)

　…広く平らな、美しい耕作地の上を、のんびり3000ftでたどります。Atlas画面を、フライト非連動で地図代わりに広げ、あちこちの街やABNを目印に、ラフな地文航法を続けまして、間もなくアントワープに到着しました。大きな川の河口にひらけた、風光明媚な小都会です。
　ご存じ「フランダースの犬」の舞台ですけれども、私にとっては、どちらかと言えば…旅の相棒・SV4の製造元「スタンプ・エ・ヴェルトンゲン」社があったところかな。実世界の空港には、同社の博物館があって、HPも開かれています。
　到着時には、まだ燃料がたっぷりあったのですが、飛行中にinternal propertiesのウィンドウが開かなくなってしまい、いったん降りて再起動することにしました。機首を高く上げ、2本ある滑走路のうち芝生の方へ、純白の愛機をふんわり降ろし、北西端の小さなエプロンに入って、エンジンを停止。

　アントワープでは、日を改めて天測テストを重ねましたが、相変わらず誤差が大きいため、太陽は諦めて夜空の星を狙おうかとか、あれこれ考えました。恒星には太陽や月のような固有運動はなく、天球に事実上張り付いたままです。天球上の星の位置を示す赤経・赤緯の数値も、FlightGearでは、プラネタリウム設計のリファレンスなどにも使用されている、Yale大学天文台の恒星カタログの最新版を使い、計3140の星について小数点以下6けた（わがコードラントの、最大分解能の1万倍）まで再現しています。これらの星は天球ごと、毎年5月21日の0時に位置をリセットされ、1年に1回転するだけのようですから、太陽より正確に位置が出るかも知れません。
　しかし逆に言えば、FlightGearがそこまで高品位のデータを使っているのに、なぜ太陽の天測で1分角やそこらの測位精度が出せないのでしょう。例えば、距離や方位計算の基礎となる地球楕円体は、GPSに採用されているモデルで、海図製作用の「世界測地系」が使うものより、新しい規格のようです。地磁気データだって、非常に本格的なものを（私くらいしか航法に使いそうもない、磁気俯角に至るまで）備えています。フライトシミュレーターの設計者は、これら演算の基礎となる各種データの有効数字を、多分同じレベルに揃えるでしょうから、太陽の動きだけ不正確というのは、どうも不自然です。ならば、私の天測や計算は一体…どこが、どう間違っているのか？ 計測工学とか精度管理の知識はないものの、２〜３日にわたって、そんなことを考えていました。

●解決のカギは「Time match real」：
　空間的な座標系に、大きな誤差要因がないとすれば、残る要素は「時間」でしょうか。そういえば、一つだけ忘れていた選択肢がありました。FlightGearを、実世界の時刻で動かすことです。
　私はこれまで常に、FlightGearのAdvanced Options のTime設定を「Time of day」にセットしていました。休日や空き時間に、現実世界の時刻に縛られることなく、任意の時間帯を選んで飛びたいからですが、未知の理由により、或いはこれが天体の動きを不正確にしているのかも知れません。Time設定欄の一番上にある「Time match real」を、一度くらい試すべきではないのか…。
　その場合、仮に帰宅後の夜中に起動すれば、もちろん日本の空港は真っ暗ですし、こっちが朝でも「旅先」のヨーロッパは夜半、といった不都合が起きます。しかし、パソコン側でクロック設定を変えれば、起動時刻を任意に選んだり、起動後に機内の時刻を調整することも可能ですから、実際はフライトには、何の不都合もないはずです。そして結果的には、これが大当たりでした。

　まずピラタスPC7改で「Time match real」に設定し、起動後のクロック修正で、アントワープを正午付近の時刻にして、地上で太陽の南中観測テストをしたら、緯度経度とも5nm以内の誤差になりました。「ジャンプ」現象は特に見られないので、ジャンプを前提に設けた修正値もゼロにして、非常にすっきり計算がまとまりました。
　緯度経度の計算には、観測した太陽の高度角と南中時刻に加えて、太陽の均時差（日周運動と標準時の時間差）および視赤緯（天球における緯度）の値が必要で、これは以前ご紹介しましたように、理科年表から拾っています。理科年表にはUTCの0時の数値しか載っていませんが、「Time of day」モードのフライトでは、0時の数値だけで一応計算が成立したので、多少疑問に思いながらも放置していました。いっぽう、本物の「天測暦」（海上保安庁発行）には、観測時刻ごとの数値が得られるように、案分計算のテーブルが付いています。そこで私のExcel計算表にも、翌日のUTC-0時の均時差と視赤緯を入力して、クロックの現在時刻で案分する機能を加えました。これで最終的な緯度経度の計算値が、さらに正確になるはずです。
　もうひとつ…フライト・コードラントを使って、太陽を機体の横に見て天測するとき、できるだけ機体が水平になる方が、正確に観測しやすい（視点を自動追尾する高度角目盛りカーソルが、より正確に画面中央を指す）ので、オートパイロットで飛行中に、適切なトリム設定となる速度を求めました。すると高度8000ftでは219KIAS、10000ftでは218KIASになることが分かりました。20000ftおよび30000ftでも、ほぼ同一の数値ですが、いずれも指示対気速度なので、もちろん高空に行くほど、真大気（つまり対地）速度は上がります。

●ついに、道が開ける。
　…これらの手段を利用し、ピラタスPC7改のコードラントを使って、飛行中に試験天測したところ、緯度経度計算のベスト記録は、
　　　実測値＝北緯51度6分32秒-東経3度10分48秒
　　　正　解＝北緯51度6分30.4秒-東経3度3分47.8秒
　　　誤　差＝緯度は＋1.6秒角（距離にして49m）。経度は約7分角（この緯度では5.4nm）
…でした。私としては驚異的な結果で、特に緯度は天文航法への挑戦を始めて以来、まったく類例のない、ほとんど10年前の携帯GPS機に迫る精度となり、2年10カ月の苦労が報われたと思いました。

　次は、スタンプSV4の番です。同様に飛行テストしたところ…ダメだぁ、経度は2度も狂いました。まったく同じ計測器をコピーして使っているのに、どうしてでしょうね。特に根拠はありませんが、SV4のコードラントは上翼中央の燃料タンク上にあって、機体の中心軸よりもかなり高いことが原因かと思いまして、取り付け位置をパイロットの頭の直後に変更し、後部胴体に半分沈む形にしました。
　高度4000ftを84KIASで飛びながら太陽を追い、南中時刻を記録。高度角はコードラント内蔵のカーソル目盛りで59.89度、pitch-offset-degでは59.879度となりました。ほぼ同じなので、カーソル目盛りのデータを使って位置計算をしたところ、誤差は緯度が＋1分5秒、経度が＋1分39．9秒と、距離にして約1nm程度のずれという、大満足の測位精度を達成。天測の誤差を、秒単位まで書く日が来るとは、感動しっぱなしです。コードラントの位置変更は、大成功でした。（ピラタスPC7改でも試しましたが、逆に誤差が急増し、すぐ元に戻しました。原因は不明です）
　ピラタスPC7改とスタンプSV4には、取り付けステーの関係で、これまで別々のコードラントを積んでいたのですが、スタンプSV4の搭載位置を変更したため、部品が100％共通となりました。これをきっかけに、スタンプ側のパスをピラタスPC7改と同一に変更し、ブツ自体を完全に共有しましたので、改造のたびに両機の間で同期を取る必要がなくなり、非常にすっきりしました。

　両機でさらに何度か天測テストを重ねたところ、ばらつきはありますが、大外れは起きなくなっており、太陽の「ジャンプ現象」も確認されず、従ってこれに伴う、あまり根拠が定かでない大きな補正値を用意する、といった不自然もなくなりました。一定の自信を得ましたので、SV4で旅を再開します。

●天測結果を利用し、アムステルダムへ：
　アントワープ空港で、スタンプSV4を起動してびっくり。こりゃ、濃霧です。
視界は50メートルか、或いは100メートルか。なんで7月下旬のヨーロッパで、それも昼ひなか、海岸平野で濃い霧が出るの？と、しばらく仰天しておりました。
　METARの内容を、翻訳つきのHPで確認しますと、1010hpaで雲なし、2Ktの風、天気は霧で視程400ｍ。気温が11度と寒いので、ははぁと思い当たりました。こっちは休日の昼過ぎに離陸準備をしていますが、現地はまだ夜中なのです。不慣れな「Time match real」の落とし穴ですね。予報を見ると、やがて視程が10キロ以上に回復するそうですが、何時間も待つ手はないので、METAR非連動で再起動し、快晴に設定しました。1114時（現地1314時）に離陸。左手を、外港に向かって蛇行する川がきれいです。
　前方にはABNが３つ。一番遠いのが次の変針点ですが、少々到着が早すぎて、その後の天測に困るかも知れません。全開100Ktからスロットルを絞り、80KIASに落とします。

　眼下にはメルヘン風の、美しい田園地帯が続きます。途中で1回、シーナリーの描画異常が起きて大地が消えましたが、幸いにも復帰しました。やがてライン川の河口地帯に差し掛かり、一番北寄りの支流の両側が、ぎっしりビル街で覆われているのを視認。ロッテルダムです。世界屈指の港湾都市ですが、周囲にすぐ田園地帯が広がっているのは、うらやましい。さて、Excelの計算表を起動し、きょうとあすの太陽視赤緯と均時差を入力。コードラントを南天へ回して、天測の準備を進めました。
　…太陽の南中時刻は、1147時49秒。高度角は58.54度。機位を計算すると、北緯51度56分14秒、東経4度38分50秒と出ました。HUDを点灯し、正解の緯度経度表示を見ないように気をつけながら、画面をキャプチャーしておきます。
　Atlas画面（航空図の代用で、今回は終始フライト非連動）を起動し、算出した緯度経度に＋マークを合わせ、ここにフリーウェア「斜めものさし」のゼロ点を置き、マウスポインタをスキポール空港の滑走路交差点に合わせます。「斜めものさし」が持っている、マウスポインタの位置表示機能によって、空港への針路と距離（縮尺は設定自在）が簡単に直読できる…という、私のフライトではお馴染みの光景。答は8.3度23nmでしたが、これまでの試験観測によると、SV4のフライト・コードラントを使った場合は、東へ約10分の経度誤差が出る公算が大です。
　誤差というものは、コンスタントであれば、補正は簡単です。算出した機位を、機械的に西へ10分ずらしてコースを引き直すと、新たな答は21.7度25nmでした。実は機体のすぐ左前下方に、空港が一つ見えており、この位置から判断しても、いま得た修正値はほぼ正しいと思われます。さっそく変針し、所要時間を計算すると18分45秒。アムステルダム到着は、1206時になりそうです。

●スキポール空港、ばんざい：
　1151時、不意に大きな衝撃を受けて機体が蛇行。お馴染みの「地形データの継ぎ目」現象かな。ちょっとドキドキしながら視線を前方に戻すと、左前方の北海沿いに、巨大な砂浜が見えてきました。九十九里浜みたいな雰囲気です。内陸には、平らな農地に小さな湖が点在して、箱庭のような風景。真正面にはドンピシャリ、スキポールのABNが点滅しています。
　1205時41秒、予定より30秒くらい早く、狙った滑走路交点の左アビーム（真横）を通過。あとで調べたら、1.5nmの誤差で済んでおり、コクピットから右下を見た印象は「まさに、目の前」でした。なにぶん飛行距離が短いので、的中して当たり前ですが(^^;)…とうとうフライトシミュレーターで、天測を頼りに引いたコースが、ちゃんと当たったかと思うと、非常に嬉しいです。

　スキポールは、FlightGearのヨーロッパでも指折りの、詳細に作り込まれた空港で、つくづく出来映えに感心しました。セントレアもすごいけど、ここは非常に広い敷地に、多彩な施設が並んでいて、独特の迫力と実感があります。廃物旅客機を転用したらしい、消火訓練施設まで見つかって驚きました。極めて多数の機体が駐機しているのも、特色の一つです。さすがにKLMが中心ですが、機種も会社もかなり種類があって色とりどり。非常に楽しい空港です。
　1217時、KLMジャンボの鼻先にある、ボーディングブリッジにすり寄って駐機。燃料残は92.3Lbs（15.4gal）で、満タンの142Lbs（27gal）のうち57％が残っていました。たった72nmしか飛んでいないのですから、当然ですね。なにぶんSV4は鈍足で、他機とは諸事、感覚が違います(^^;)。ちなみに燃費は6.2nm/galでした。あまりよくありませんが、スキポールに降りてからのタキシングが非常に長かったのも、原因の一つでしょう。
　着陸後、ロッテルダム上空で行った天測の誤差を出したところ、緯度が＋23.7秒、経度が＋11分24秒でした。経度誤差を＋10分と見なして機械的に修正し、最終的に経度誤差を1分24秒に圧縮したのは、正しい判断だったわけです。船の航法でも、例えば「器差」（六分儀の固有誤差）は、ミラーを再調整したりしない限り等しいので、観測のたびに一定の修正値を足し引きします。ともあれ今回は、なかなか感慨深いフライトになりました。

■追伸■　またMETAR受信のproxy環境が変化したようです。現在は、下記の状態でうまく受信中です。
　　　　　58.19.176.201:8080