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

パスワード:


パスワード紛失

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

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

もっと...

「フライト・コードラント」(航空四分儀)を完成

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

なし 「フライト・コードラント」(航空四分儀)を完成

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
depth:
49
前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 | 投稿日時 2011-5-4 8:32 | 最終変更
hide  長老 居住地: 兵庫県  投稿数: 634
hideです。
大変長らく、ご無沙汰を致しました。
 私事で恐縮ながらここ1年ほど、深夜を中心に約12時間、食事にも立てず端末の前でサンドイッチを食べるのがやっと、というハードな職場におりました。最近は震災の影響も加わり、正直こりゃ倒れてしまうと心配した矢先、幸い今月から希望の持ち場へ異動になって、心からホッとしました。晴れて本連載へ、復帰させていただきます。

 3月以来、長距離を飛んだり書いたりは無理でしたが、その間に少しずつ、前回お話しました天文航法用の「子午儀」を改良して機能を拡張し、すっきりと小型化しました。3月9日にアップロードした「子午線への挑戦」の画像と、今回お目に掛ける装置を比べていただけますと幸いです(^^;)。
具体的な改良点は、以下の通りです。
(1)垂直カーソルに精密目盛りを設け、天体の高度角を直読できるようにした。
(2)このカーソルは従来、常に真南を指して、天体の南中を示す仕組みだったが、
   マウス操作による視点移動を自動追尾し、常にビューの中心を指すようにした。
(3)新たに方位目盛りリングを新設。常に真方位を指すため、垂直カーソルとの
   交点を見れば、天体方位が直読できる。
(4)従来の子午儀は直径が60僂發△辰燭、新装置は24僂泙脳型化。
   (あまり小さくすると、ビュー機能の視界制限により、カーソルが写らなくなる)
 …こうして新型の天測装置は、internal propertiesを開くことなく、天体の高度角・方位角を一発で読めるようになり、使い心地が極めてよくなりました。
 最小目盛りはそれぞれ0.1度ですが、ズーム機能でどアップにして、理科実験の常識通りに「目盛りの10分の1まで目測」しますと、internal propertiesのデータと比較して、100分の1度の単位が少し怪しいかな、というくらいの精度が出ます。ほぼ1分角(60分の1度)の分解能を実現しており、今も売られている上質な六分儀のスペック(国産TAMAYA製は、マイクロメーターの副尺を使うと0.2分角)に比べますと、さすがに少し見劣りするものの、以前ご紹介いただいた、FlightGear用のバブル・セクスタント(結局まだ使い方が分からず残念)とは同レベルで、距離に置き換えると1マイル以内の誤差ですから、フライトシミュレーターでは、十二分に役立つと思われます。

 この装置は、四分円(quadrant=国内表記は「コードラント」が主流?)の高度角目盛りを持ち、大航海時代に使われた「四分儀」と原理的にそっくりです。蛇足ながら…四分儀は、のちに可動式と固定式の鏡を付けて、測定角度を2倍に拡大してファインダーに導くよう改良され、八分円(オクタント)の形になり、八分儀と呼ばれました。さらに最大角度120度まで測れるよう、六分円(セクスタント)とした改良型が作られて、六分儀となった次第です。こうした歴史にちなんで、私はこの改良計器を「フライト・コードラント」(航空四分儀)と呼ぶことにしました。以下に少々、改良の経緯などをご紹介します。

●FlightGearの太陽が、正午にジャンプした:
 先ごろご紹介しました「子午儀」は、簡単に言いますと、天体が真南を通る(南中する)瞬間を捉え、グリニッジ標準時で時刻を計って経度を算出しよう、という装置です。自動的に水平を保ち、カーソルも自動で真南に向くのが、ささやかな工夫点でした。自分では気に入っていたのですが、大阪上空で何度か太陽観測テストをしたところ、厄介な現象を発見しました。
 太陽が南中する時刻は、季節によって変化します。たまたま4月に大阪湾上空でテスト中、日本標準時の正午ほぼピタリに南中したのですが、1159時59秒が1200時になったとたん、子午儀のカーソルに重なっていた太陽が、東から西にピョンとジャンプして、肝をつぶしました。距離にすれば、視直径のわずか4分の1程度ですし、南中の瞬間をどアップで観察するユーザーは、ほとんどいらっしゃらないでしょうから、あまり知られていない現象かも知れません。数時間後にテストしたところ、再現性がありました。青空に紛れている星も同様にジャンプしますので、太陽単独ではなく、天球が動いています。1日に何度も起こるのかと思いましたが、シミュレーション上の真夜中にテストしたところ、発生しませんでした。以上のことからFlightGearは、日周運動の誤差を補正するため、ローカル時間の正午に、一種の「うるう秒」を設けているのではないかと想像しています。しかし、これを書くためにいま、KSFOで現地時間の1200時に太陽を観察したところ、ジャンプは起きませんでしたので、恐らく幾つもの条件を満たす必要があるのでしょう。
 …ともかく。まれにせよ、南中の瞬間か寸前、または直後に、太陽がポンと移動することがあり得るのでは、子午儀という観測装置は成立しなくなってしまいます。天体の子午線通過を待ち受けても、その一瞬を確実に観測できる保証がないなら、こっちから積極的にカーソルを動かして天体を照準し、その時の方位を読み取るのでなくてはダメ、ということですね。さてカーソルを能動的に、任意の方角に回転させるには、どうすればいいのでしょうか…?
 最初に考えたのは、ジャイロコンパスに付いている、ヘディング・バグ(赤い針路目印)の設定値に、カーソル方位を連動させることです。実はピラタスPC7のオートパイロットは、磁気方位による針路保持機能が壊れていて、ヘディング・バグではコース設定ができないので、遊んでいるなら転用してしまえ、というわけです。カーソル方位を決めるrotateタグのなかで、方位を
   <property>autopilot/settings/heading-bug-deg</property>
と記述してみたところ、OBSつまみをクリックしたり、オートパイロットメニューから磁気針路設定をすると、カーソルの向きが変わることを確認しました。しかし太陽を照準するような、細かな動作は到底困難です。爆撃機の動力銃座が参考にならないかと、B-17などをダウンロードして調べましたが、実際に銃座が旋回する作例はみつかりませんでした。さんざん考えた末、
   <property>sim/current-view/heading-offset-deg</property>
とすれば、マウスでビュー方向をパンする動きを、カーソルが正確に追尾することに気がつきました。あとはカーソルが実際に指向した方位を、正確に読み取る機能が欲しいです。高度角の表示装置も必要ですね。
(注:以前お話ししましたように、実際の天文航法では通常、高度角のみを計って位置を算出します。この方法は原理的に複数回の測定が必要ですが、そのほかに、太陽方位や高度角観測結果を作図するため、該当地域の海図・航空図か、代用品となる位置記入用紙を手に入れなくてはなりません。これの使い方と売っている場所がまだ分かりませんので、当面はリアリティーを若干損ないますが、3年前に試みたように、太陽の高度角と同時に方位も計っておき、計算法を少しアレンジして、一発で緯度経度を算出することになりそうです)

●「忍」の一字で、精密目盛りを制作:
 さて、高度角や方位を読み取る方法ですが。最初はHUDを改造できないかと思いました。天体高度角と方位を測定する、一番簡単で正確な方法は、カメラ位置が水平で安定するヘリコプタービューを選択し、HUD中央の◇マークを太陽や星に指向して照準を決め、internal propertiesから、pitch-offset-degとheading-offset-degを読み取ることですね。パスをたどるのが面倒ですが、もし画面の一部分に、これらの数値が常にデジタル表示されたら、恐ろしく便利になると思います。さっそく、
(1)HUDの機能定義ファイルを見つけて改造する。
(2)燃費計算ツールのffe.nasを参考に、小さなウィンドウを開く。
(3)フレームレートの表示機能を参考に、ドラッグ可能な数字を表示する。
(4)カーソルと一体の小型計器盤を作り、デジタル角度表示器とカーソル旋回ボタンを組み込む。
(5)internal properties/sim/time/sun-angle-rad という太陽角度のデータを転用する。
などのアプローチを検討しました。
 しかし(1)〜(3)は、私の技術ではとても無理と判明。(4)は思考実験だけで、かなり面倒に思えて断念。(5)のデータは、90度から高度角を引いた、天文学で言う「頂距」(天頂から目標の天体までの角度)をラジアンで表したものと分かりましたが、他の測定方法と比較したところ、0.2%も誤差があって、とても航法には使えません。そういえば…FlightGearでは、ビルの色彩を夜間照明タイプに切り替えるための引き金として、この変数が使われていますね。ともかく、いずれの方法もダメとなりますと、あとは馬鹿正直に精密な目盛りを作って、組み込むしかあるまいと腹をくくりました。

○精度を設計する:
 目盛りの作り方ですが。工作精度がすべてを決定しますので、仕様や作業手順を、できるだけ丁寧かつシステマティックに決めようと思いました。
 まず、最小目盛りの単位を決めます。
私の天文航法の目標精度は、初挑戦した3年前は10nmでした。これは、目的地の空港滑走路を機上から視認できる最大距離、というつもりです。FlightGear自体の天体運動の精度が、果たしてどの程度か、いまでもよく分からずにいますが…かつて最良のケースでは誤差1nmを少し割ったこともあり、今年は思い切って、コンスタントに1nmを目指したいところです。ただし実現できるかどうか、現時点ではまったくわかりません。
 ちなみに実世界の天測精度は、観測する人によって大きく異なるようで、訓練段階では優に数十nmずれることもあるそうです。若き日の石原慎太郎氏も、1963年に参加した太平洋横断ヨットレースを小説化した「星と舵」の中で、「一度相模灘で計った位置が、山梨県の甲府近い山の中に出た」と、苦笑混じりにつぶやいています。その一方で、私の大学時代、一緒に貨物船に乗った船会社員は「名人なら誤差は100mだ」と話していました。
 距離の誤差1nmは、天測誤差では1分角に当たります。従って最小目盛りもそれ以下がベターで、少なくとも1分角が欲しいです。しかしその場合は水平線から天頂までの90度に、90×60=5400本もの目盛りを打たなくてはなりません。3Dのファイルサイズは、基本的には図形の頂点(vertex)の総数で決まるでしょうが、5400本の線分を引くには10800個の頂点が必要で、「重すぎて飛べない」事態が予想されます(^^;)。なので、最小目盛りは10分の1度(6分角)にとどめ。その代わりに測定時は、どアップにして目盛りの10分の1(つまり100分の1度)まで目測することにしました。
 ところで。パネルの計器類は通常、目盛りを画像データとして持っています。私は使用可能な画像の最大サイズが、256ピクセル角だと勘違いしていたため、解像度が絶対的に足りないと思って、目盛りの画像化はまったく検討しませんでした。現実には2048ピクセル角のデータも存在しますが、やはり今回の用途には、大幅に解像力が不足しそうです。また目盛りを3Dの線分で作っておくと大幅な拡大縮小が可能で、何かとフレキシブルなため、将来にわたっても使い回しが利くと思われます。
 実際の使用場面では、3Dの目盛りはどこまでもどアップにでき、どんなサイズで画面表示しても、常に幅が1ピクセルです。まるでロジックで作られた、仮想のひも状単分子、とでもいいますか。実世界なら、太さゼロの物体なんて見えるはずはないのに、パソコン上ではちゃんと着色して使用可能。数学の世界とコンピューターの内部だけに存在しうる、誠に奇妙かつ便利なものですね。ちょっと感動しました。
 次は、目盛りの寸法と比率を決めます。
当面は恐らく太陽ばかり観測するので、高度角1度の目盛りの長さを、太陽の視直径と同じにすることにしました。理科年表(国立天文台発行)によると、太陽の視直径は約32分で、つまり0.53度。そのサインは0.009308。つまり半径30僂離ーソル上に、長さ0.279僂量楡垢蠅鮹屬韻弌太陽と同じ大きさに見えます。また目盛りは単位ごとに長さを変えて、一目で区別できないとダメです。5度は視直径の2倍、10度は視直径の4倍と決定。また角度の「分」単位は、10分目盛りが視直径の半分、5分目盛りは視直径の4分の1、1分目盛りは視直径の8分の1に決めました。制作中に多少の拡大・縮小を加えたため、実際の寸法はもう少し大きいのですが、各目盛りの長さの比はこの通りで、非常に見やすいと感じています。既存の物差しの目盛りも、こうした「倍々ゲーム」の寸法比が目立ちますが、これは一種のフラクタル図形とも考えられますね。

○ひたすら、コピペを繰り返す:
 続いて、実際にモデリングソフトを使って、どうオブジェクトを作るかです。
当初の想像では、例えば1度分の目盛りを作っておいて、これを2倍にコピペし、続いて4倍に再コピペ…という具合に、ほぼ倍々ゲームで作れると思いました。しかし実際に試してみると、これでは演算誤差が累積してしまうようで、かなり目盛りがずれました。電子回路で増幅率を上げると、S/N比が低下する(ノイズも増える)のと、ちょっと似た雰囲気の現象ですね。そこで、起点となるゼロ度の目盛りを自分自身の場所にコピペして、角度にして1度だけ回転させておき。次に同じゼロ度目盛りを、同様に2度だけ回転させ…という具合に、すべての目盛りの線分について、原点からそのつど回転計算を実行しました。同じことを、10分の1度目盛りについても行いましたが、45度や90度、180度の集団回転コピペの場合は、特に誤差が発生しない模様で、45度分の目盛り(総計270本)を作ってしまえば、あとはまとめてコピペで大丈夫でした。
 こうして作った高度角目盛りに、10度ごとに数字を入れました。続いて2倍にコピペし、横倒しにして180度の方位目盛りを作成。こっちも数字を入れ掛けましたが、モデリングソフトが異様に重くなり、方位目盛りの数字は解像度を最低まで落とした上、30度間隔にしました。本当は10度ごとが使いやすいのですが、やむを得ません。なお、フライト・コードラント単体のacファイルサイズは、約21MBありまして、エディタで開いてみたところ、総行数は134万9846行でした。なんだか大きすぎて、ピンと来ない数字ではあります。

○カメラ位置を、再調整:
 最後に、直径60僂△辰織ーソルと回転ドームを縮小し、直径24僂坊萃蠅靴泙靴拭L楡垢蠅寮催戮世韻鮓世┐弌直径15僂任盻淑いけそうでしたが、FlightGearのビューのカメラは、あまり近くのオブジェクトを写しません。パイロット人形の頭部やゴーグルなどが、コクピット・ビューの視界を塞がないように、距離制限が掛けてあるものと思います。従って現実には、こうしたドーム型観測装置のサイズは、24僂らいが限度で、もっと小さくすると、肝心の目盛りカーソルが見えなくなります。
 本体のサイズを変更したところ、中央にある観測用ビューのカメラ位置が合わなくなり、調整をやり直しました。回転ドーム内部に作ってある調整用のXYZ軸を、いったん全長100mに拡大し、これが一点に収れんして消えるまで、カメラの上下・前後位置を調整するわけです。最初は機体をいちいち再起動し、気が遠くなるような手間を掛けましたが、ふと馬鹿げたことをしているのに気付きまして。以後は internal propertiesの数値変更機能を使って、カメラ位置を自在に動かし、10分程度の作業で誤差を100分の1ミリ以下に追い込みました。

●取りあえずの、テストと評価:
 こんな調子で「フライト・コードラント」が完成。大阪湾上空で、internal propertiesによる高度角・方位測定結果と、目盛りで計った数値を比較してみますと、誤差は最小0.006度、最大0.02度(1.2分)の範囲に収まり、目標とした1分角をほぼ満たしました。誤差原因は、ほとんどが最小目盛り以下の目測ミスと思われますので、慣れればもう少し、精度が上がるはずです。これほど手の込んだFlightGear用の装置を作ったのは初めてですが、うまく作動して非常に嬉しいです。
 また気になるファイルサイズというか重さですが、さすがに観測用ビューで目盛りを表示しますと、フレームレートが10くらいまで落ちます。しかし、なくても差し支えのないHorizon effectとSpecular highlightを切ったところ、目盛りが見えなくなるコクピット・ビューでは、最大で60フレームを維持し、満足しています。さてこれで、計測装置は手に入りました。天測計算の勉強にも一層、力が入りそうです…。
投票数:0 平均点:0.00

投稿ツリー

  条件検索へ


 検索

高度な検索
 新しい登録ユーザ
eniwixi 2019-12-16
ucejyxyq 2019-12-15
iducig 2019-12-15
acucelim 2019-12-15
ihera 2019-12-15
mjohn 2019-12-15
eunicep 2019-12-15
Agentogel 2019-12-15
ygyhago 2019-12-15
uburisyj 2019-12-15
 最近の画像(画像付)
植生図を利用した北... (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