logo
ホーム •  フォーラム •  日本語wikiトップ •  アカウント情報 •  サイト内検索 •  新規登録
 ログイン
ユーザー名:

パスワード:


パスワード紛失

新規登録
 メインメニュー
 米国サイト
 オンライン状況
21 人のユーザが現在オンラインです。 (2 人のユーザが フォーラム を参照しています。)

登録ユーザ: 0
ゲスト: 21

もっと...

太陽の誤差を追う

このトピックの投稿一覧へ

なし 太陽の誤差を追う

msg# 1.3.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1
depth:
51
前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 | 投稿日時 2011-6-6 10:28
hide  長老 居住地: 兵庫県  投稿数: 634
hideです。天文航法の続きをお届け致します。
ついに…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気泡六分儀(バブル・セクスタント=水平線の代わりに水準器を使う型)をモデル化したもので、現在はショート・エンパイア飛行艇をダウンロードすれば、副操縦士席から起動できます(しかしダイヤル類の正しいクリックポイントが分からず、うまく操作できないので、私は自分で開発した「フライト・コードラント」だけを使っています)。
 この六分儀の作者さんは、ReadMeのなかで、Alkaid と Alioth(ともに恒星名)を使って2本の位置の線を求め、その交点から緯度経度を出したところ、実際の値に対し約40キロの誤差が生じたと述べています。これは約20nmにあたりますので、私の限られた観測結果からみても、ほぼ日中にパソコンを使った場合の、誤差の範囲内に含まれると思われ、十分に納得できる数値です。私の場合、誤差の補正テストはこれからですが、例えば5月や6月の季節ですと、「パソコンのクロックを、23時ごろにセットしてから機体を起動する」という工夫をするだけでも、恐らく経度計算の誤差を、Mk9六分儀の作者さんの半分以下に出来るのではないか、と考えています。
 では以下に、少し詳しいお話をさせていただきます。

●RAFビギンヒル基地…すべては、この丘から始まった:
 正午の太陽の観測地を、経度ゼロのグリニッジ子午線上と決めましたが、フライト・コードラント(航空四分儀)を装備したピラタスPC7改をどこに駐機するか、しばし考えました。いっそのこと、グリニッジ天文台の位置ではどうでしょう。ロンドン・シティ空港(EGLC)で起動すると、グリニッジはすぐ西です。しかしロンドン都心部に向かって、都市テクスチャーの上をタキシングするのも、リアリティーを欠いて味気ないので、南方約10nm(ノーティカル・マイル=海里。たまに定義を書くことにします)にある、英国空軍のビギンヒル基地(EGKB)を起動地点に選びました。1nmほど西にグリニッジ子午線が走っており、そこいら中が牧草地や農地ですので、上がってすぐ降りて、子午線上に機体を駐めることができます。
 余談ながら。ここはバトル・オブ・ブリテンの間、ロンドン防衛の最前線でした。猛爆に遭い「地獄のビギン」と呼ばれましたが、ここやマンストン、タングメア基地などに布陣した戦闘機集団が、数では圧倒的に優勢なドイツ空軍を、海峡の向こうに押し戻したわけですね。なので私も、ご挨拶代わりにまず、スピットファイア2型で発着を試みました。
 エンジンのかけ方が少し複雑ですが、よく分かるチュートリアルがあります。この機体は、火薬カートリッジでロールスロイス・マーリンを始動することを、初めて知りました。いったん止めて再始動する場合は、パネル右下のレバーをクリックすると、2発目のカートリッジが装てんされる仕組みです。尾輪式にしては離陸が簡単、空に上がると軽快な飛行機で、機体の迷彩によく似た大地を背にクルクル回っていると、「空軍大戦略」の勇壮なマーチが聞こえてくるような気分。アプローチではなかなか減速せず、脚が狭いので接地時の安定も悪く、うわさ通り着陸は難しいですが、ハイになれる楽しい機体です。

 本題に戻りますが…太陽の観測テストは、次のようにスタートしました。
まず、ピラタスPC7改でビギンヒルを離陸し、すぐそばの経度ゼロ線上の農地に降りて、機体を真北に向けました。経線はテクスチャーの継ぎ目で、かすかに勾配があって機体が傾きますが、搭載したフライト・コードラントは自動的に水平を保ちますから、特に問題はありません。今後は観測のため、正確に同じ場所で数十回の起動を行いますので、緯度経度を詳しく記録し、さっそくビギンヒル基地に「PrimeMeridian」(本初子午線=経度の原点を意味する、グリニッジ子午線)という名称で、parking(機体起動)地点を新設しました。以後は起動ウィザードから、一発でここへ来られます。(設定方法は、5月15日付の本連載をご参照下さい)
 また同様に、明石市北部の低い丘陵にある道路にも着陸し、東経135度0分0.0秒に機体を駐めて位置を記録して、我が母港・伊丹空港に「JstMeridian」(日本標準時の子午線)という Parkingを設けました。

●カギを握る「均時差」:
 太陽の南中時刻と高度角の測定は、できれば通年にわたって均等に、例えば毎週分のデータを取って整理したいのですが、とても無理なので、当面は観測対象を、今年の5月21日とその前後、また6月15日、10月1日など数日に絞りました。なぜこれらの日付なのかといいますと…マイアルバムにアップロードさせていただいた、「太陽の誤差を捕捉」の説明図をご覧下さい。右下に、ピンクのラインで「均時差」のグラフを入れてあります。
 均時差とは、教科書的に言いますと「視時(太陽が示す時刻。毎日異なる)から、平時(年平均を取った標準時刻)を引いた値」です。分かりやすく言いますと…地球から見た、太陽の動く速さは周期的に変化しているため、グリニッジで太陽が南中するのは、グリニッジ標準時の12時ちょうどではありません。どのくらい前後にずれているのかを、年間を通じて示したのが、均時差(標準時に対する観測値の進み遅れ)です。この値をどの程度、フライトシミュレーターが正確に再現できているかが、フライトシムの上で天文航法を行う際、経度の計算精度を、決定的に左右する要因となるはずです。
 先ほどのグラフをご覧頂けばお分かりの通り、均時差はちょっとだけ複雑な二次曲線を描いており、年間を通じて最大値と最小値のほかに、小さなピークと谷が1カ所ずつあります。今年の場合ですと、
  最大値 :11月4日の+11分26秒
  最小値 :2月12日の−14分13.3秒
  小ピーク:5月15日の+3分38.9秒
  小さな谷: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を起動。空港にビギンヒル、Parking地点に PrimeMeridian を選び、経度ゼロの畑の真ん中に機体が出現します。
 続いて、ビューをコクピットからフライト・コードラントに切り替えて、太陽が見えるまでカメラをパンアップ。メニューバーから「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本体と機体の両方で。
(その後実験して、機体の起動時間に行えばよいと判明)
clock 南中時刻    高度角 ジャンプ時刻 距離(弌傍動時太陽は通り過ぎてる。1204頃。
0時  115831時     58.62  1200時    710.94度 ローカル13時
0時07分115831時     58.83▼ここで高度角変化
0時10分115830時     58.83▼この辺で南中時刻変化
3時  115802時     58.83  1200時    67.5mm0.94度
6時  115732時     58.83  1200時    86.50.94度
9時  115702時     58.83  1200     67.5mm0.94度
1159時115634時     58.83▼子午線ジャンプはこれ以降。
12時 59秒左100.14度 58.83  1200UTC   67.5mm0.94度 子午線ジャンプ
(ジャンプがなければ、33.6秒後の120032時に南中)
    案分による12時のd値は20度10分14秒
    案分による12時の均時差は、3分25.6秒
15時 1159秒左20.02度 58.83  1200     67.5mm0.94度 子午線ジャンプ
(ジャンプがなければ、4.8秒後の120003.8時に南中)
1501時 1159秒左0.02度   58.83 子午線ジャンプ
1530時 115959時     58.83  これ以降子午線ジャンプは起きない。
18時 115934時     58.83  1200     67.5mm0.94度
21時 115904時     58.83  1200     67.5mm0.94度
2345時 115838時    58.83  1200     67.5mm0.94度

▼同じく5月21日ビギンヒル、今度はクロック設定のみJST。観測時刻はもちろんGMT。
clock 南中時刻    高度角 ジャンプ時刻 距離(弌
0時  115600時    58.62  なし(59秒でカーソル左67mm)ローカル12時にも13時にもなし。
3時  115530時    58.62  なし
6時  115501時    58.62  なし
9時  115430時    58.62  なし
9時15 115428時    58.83  なし▼9時過ぎには当日の高度角になる。
12時  115802時    58.83  なし
15時  115732時    58.83  なし
18時  115702時    58.83  なし
21時  115633時    58.83  なし
23時45 115606時    58.83  なし

●データを集計し、グラフ化する:
 約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の不便(かつロマンチック)な代用品にはとどまらず、フライトシミュレーターの、より奥深い味わいを発見する、新たな手段になりそうな予感がします。
投票数:10 平均点:0.00

投稿ツリー

  条件検索へ


 検索

高度な検索
 新しい登録ユーザ
Chaitra 2019-12-14
yvyzep 2019-12-14
abywy 2019-12-14
ykuxywon 2019-12-14
opibun 2019-12-14
asafat 2019-12-14
yxybovy 2019-12-13
idanina 2019-12-13
camiseta 2019-12-13
SarraKhan 2019-12-13
 最近の画像(画像付)
植生図を利用した北... (2019-6-16)
植生図を利用した北...
空が真っ暗に (2019-5-18)
空が真っ暗に
植生図を使用した富... (2019-4-15)
植生図を使用した富...
春の嵐METAR回復 (2019-2-23)
春の嵐METAR回復
FlightGear 2018.3.2... (2019-2-14)
FlightGear 2018.3.2...
Powered by XOOPS Cube 2.1© 2001-2006 XOOPS Cube Project
Theme designed by OCEAN-NET