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

パスワード:


パスワード紛失

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

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

もっと...
トップ > ユーザー >各種設定について >手探り航法・旅日記（その２）

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

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

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

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

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

　この装置は、四分円（quadrant＝国内表記は「コードラント」が主流？）の高度角目盛りを持ち、大航海時代に使われた「四分儀」と原理的にそっくりです。蛇足ながら…四分儀は、のちに可動式と固定式の鏡を付けて、測定角度を２倍に拡大してファインダーに導くよう改良され、八分円（オクタント）の形になり、八分儀と呼ばれました。さらに最大角度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を読み取ることですね。パスをたどるのが面倒ですが、もし画面の一部分に、これらの数値が常にデジタル表示されたら、恐ろしく便利になると思います。さっそく、
（１）HUDの機能定義ファイルを見つけて改造する。
（２）燃費計算ツールのffe.nasを参考に、小さなウィンドウを開く。
（３）フレームレートの表示機能を参考に、ドラッグ可能な数字を表示する。
（４）カーソルと一体の小型計器盤を作り、デジタル角度表示器とカーソル旋回ボタンを組み込む。
（５）internal properties/sim/time/sun-angle-rad という太陽角度のデータを転用する。
などのアプローチを検討しました。
　しかし（１）〜（３）は、私の技術ではとても無理と判明。（４）は思考実験だけで、かなり面倒に思えて断念。（５）のデータは、90度から高度角を引いた、天文学で言う「頂距」（天頂から目標の天体までの角度）をラジアンで表したものと分かりましたが、他の測定方法と比較したところ、0.2％も誤差があって、とても航法には使えません。そういえば…FlightGearでは、ビルの色彩を夜間照明タイプに切り替えるための引き金として、この変数が使われていますね。ともかく、いずれの方法もダメとなりますと、あとは馬鹿正直に精密な目盛りを作って、組み込むしかあるまいと腹をくくりました。

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

投稿ツリー

  条件検索へ

 検索

高度な検索
 新しい登録ユーザ
bcgame1pOG 2024-4-25
bcgame1nQc 2024-4-25
ejoxa 2024-4-25
anodada 2024-4-25
yxakeqac 2024-4-25
hdfbdbsgr 2024-4-25
ihyvuki 2024-4-25
igogeny 2024-4-25
obasehu 2024-4-25
eguzi 2024-4-25
 最近の画像(画像付)
自作１１機目 F/A-18... (2022-5-27)
自作１１機目 F/A-18...
飛んでみる八尾空港 (2022-4-10)
飛んでみる八尾空港
作ってみる八尾空港 (2022-4-2)
作ってみる八尾空港
F117 nighthawk (2021-5-19)
F117 nighthawk
HiTouchさん宛の画像... (2020-11-8)
HiTouchさん宛の画像...
Powered by XOOPS Cube 2.1© 2001-2006 XOOPS Cube Project
Theme designed by OCEAN-NET