makotan _at_ gmail dot com

MSFS A320neoでオートパイロット

こんな所にそれっぽい動画があるので、これを見ながら説明

youtu.be

 

オートパイロットの準備として、IFRを選択する(飛行機の下の選択)

高高度か低高度は好きな方でOK

出発のコースとかはなんとなく好きなやつでOKだけど、滑走路と番号は合わせること

滑走路が22なら出発は「出発(LAXA3 22)」みたいに後ろの数値と滑走路の番号を合わせる

到着も同じ感じで、アプローチは RNAVを選択(他にILSとか色々あるけどとりあえずRNAVで)

ナビログで今回のコースと速度とか高度とかをちょっと確認しておくと良いけどこれはオプション

 

離陸はオートパイロット出来ないので、パーキングブレーキ解除(十字キーの左)、throttleを最大にして加速

速度メータの所のマークが出た辺りでちょっと操縦桿を引いた(左スティックをちょっと下に)ら離陸

ちょっと高度が上がって(100ftとか)からギアを引っ込め(十字キーの右)て、フラップをあげる(十字キーの上)

そこで「AP」って書いてるスイッチをポチッと押すとランプが光る←めっちゃ重要

その後、throttleを70%くらいまで下げる(そうするとオートスロットルに切り替わるので着陸前くらいまで操作しなくて良い)

APのランプが光っていれば左スティックも触らなくて勝手に移動していってくれるので放置すればいいけど、高度だけはチョコチョコ変える必要がある

(上手くいかないときはランプの点いてる場所が同じか確認)

 

この段階まで上手くいけば、ここからコントローラー操作はしばらくないのでマウス操作になる

 

コンソールのところでフライトプラン(FPLNだっけ...?)を表示するボタンをポチッと押す

そしたら何処にどの高度で飛べって書いてるのが表示される(そのまま飛んでれば自動更新される)

表記は「場所」「時間」「高度」なので、場所と高度を見ながら飛ぶ

いまどこにいるかはレーダーっぽい画面に出てる

右上に「向かってる場所」と「距離(海里)」が出てるのでそれを参考にする

 

目標高度は初期値で5000とかで表示されてる部分

高度はコンソールのフライトプランを見つつ、適当に決める

セット方法は、マウスの真ん中でスクロールさせる感じで数値を選ぶ(この時点ではまだ変化しない)、マウスの左ボタン長押ししつつの、中央クリック(視点移動が中央クリックでそっちも発動するので2回押す)

ほっとくと目標高度に向けて一気に動くのでそれを防ぐのにV/S(垂直方向の制御)を使って一定の速度で上下する方法を使うけど、慣れるまでは一気に動かす

いずれにしろ目標高度に達すると安定するので、次の目標高度の設定とかをしておく

 

スピードの所は高度10,000までは240くらいで、10,000超えたら330とかにセットする

セット方法は高度と同じでスピード選択からの中央クリックのパターン

 

高度を上げていってるときとか、V/Sで操作してるときとかに数値を変える場合はなにもしなくても反映されたりするので、やりながら慣れる(パターンはあんまり多くない)

イメージ的には

高度だけセットするとその高度に一気に向かう(普段この動きは見た事ない)

V/Sをせっとしてから高度をせっとすると、V/Sに従ってその高度になる(時間がかかるけど普通の飛行機の挙動)

なんか挙動的に反映されないなぁ〜って思ったらセットすると反映される

 

しばらくは高度を上げていき...

フライトプランで高度を下げる感じに出始めてからゆっくり高度を下げていく

(東京大阪間を飛んでも安定して飛行するのはちょっとだけ

高度11,000より下になったあたりで、スピードを240くらいに下げる(儀式)

 

っていうのを繰り返していくと...いつのまにか着陸する空港に近づいていくはず

 

着陸の一つ前の目標点くらいで速度をどんどん下げる(190とか)

(ILSの表示をオンにすると下がりすぎとかの判断も出来るけど...慣れてからで

 

着陸の一つ前の目標点を過ぎた段階で、空港の高度に目標高度を合わせつつ、V/Sも適切にセットする(下げすぎない程度なら...

 

この辺からコントローラーが必要なのでいつでも使える様に準備

 

着陸ちょっと前で速度を170とかに設定しつつ

目の前でフラップを下げる(十字キーの下)、エンジンをアイドル(一番下)まで下げる、着陸ギアを下げる(十字キーの右)

直前でさらにフラップを下げつつ

 

タイヤが地面についたら、ブレーキをかけて(Xキー)速度を下げる

着陸成功!!

 

 

色々練習した結果、こんな感じだった

慣れたら巡航中に読書したり映画見たり料理したり食事したりも出来るのでオススメ

 

最近のOSSでふと思ったこと

OSSがライセンス変更したり、某OSSを使って商売してる企業がライセンス変更に合わせてforkしたOSS作ったりをみてて

企業ベースのOSSの場合はこの辺のリスクを考えて採用する必要があるのか〜

ってふと思った

逆に、非営利団体が管理してるOSSだとライセンス変更のリスクは少なそうだけど

非営利団体が事実上の稼働停止とかするパターンもあるので

OSSの採用って難しいなって思った

 

このままOSSのライセンス変更リスクとか、セキュリティー対応する人のトラックナンバーが少ないとかの状況が続くと...なかなか厳しい...

OSSでしっかりビジネスが出来る状態が出来ると良いんだけど、難易度高いなぁ〜

(そういえば、なんか15年位前にも同じようなこと聞いたなw

MSFS Mobile Companion App

全MSFSユーザにお勧めしたいアプリ

github.com

 

ざっくりした手順

ダウンロードして

2つのファイルを指定の場所にコピペして

MSFS起動して、メインの画面が出てきた頃に

zipを解凍した後に出てくるexeを実行

ネットワーク的に許可する必要があるので許可する

コマンドラインIPアドレス:4040って出てくるのでそこにアクセス

 

そうすると...

 

MSFSと繋がって色々出来る

いちいち画面を切り替えたり見やすい場所に変えたり・・・とか全く必要が無い

ブラウザさえあれば操作出来るのでそこら辺に転がってる端末が使える

 

これは素晴らしいアプリですね

(欲を言うと切りが無いけど、十分良い

個人的には手作業でやるにはすごく面倒なシミュレーション速度変更がこんなところに!っていうのが一番の感動ポイントだったりする

これで16倍速で飛べば離陸〜着陸までの空を飛んでるだけの時間を凄く短縮出来る

(とある国を飛ぶとひたすら何も無いところが続くのでちょうど良い

アーキテクチャの天下統一は可能なのか?ってふと思った

過去から未来の全てのアーキテクチャの天下統一したアーキテクチャって実現可能なのかなぁ〜って思ったのでちょっと考えた

 

仮説-天下統一したアーキテクチャ

1. ある一つのアーキテクチャが存在する

2. そのアーキテクチャはあらゆる開発で利用可能

3. 他のアーキテクチャを選択する必要性は全くない

 

仮設-既存のアーキテクチャ

1. 既存のアーキテクチャはプロダクトのソフトウェア品質要求、コスト、流行で決まる

2. 既存のアーキテクチャで天下統一したものは無い

(参考リンク 

ソフトウェア品質 - Wikipedia

 

ということは

天下統一したアーキテクチャはソフトウェアの品質要求がどんなレベルであろうと、プロダクト開発にかかるコストも要求レベルを実現出来ることになる

=どんな品質要求でもかかる開発コストは同レベルになる

 

反論-1

数万ユーザ同時アクセスでms単位でレスポンスを返すことを要求されるプロダクトと

数ユーザ同時アクセスでs単位でレスポンスを返すことを要求されるプロダクトで

開発コストが同レベルになることは無い

 

反論-2

PoCに適したアーキテクチャと、本開発に適したアーキテクチャが同じになることは無い

 

(反論パターンは沢山作れるのでざくっと省略

 

以上の反論から

アーキテクチャの天下統一は無理がある

ただし、プロダクトの特性に合わせたある程度の最適解は同様なサービスのアーキテクチャ等から抽出可能な気がする

 

おまけ

アーキテクチャを開発手法ってやっても開発プロセスってやっても多分同じになるなぁ〜って書いた後に思った

Clean Architectureを読んで思った事

何を思ったのか、Clean Architectureを突然読み始めた

そして感じたこと

アーキテクトの人が読む本ってあんまり無かった気がするけど、これはまとまってて良いな〜

なるほど、これが有名な◎か...

アーキテクチャが開発工数とかに影響するんだから、かけれる開発コスト(と要求される開発速度)を天秤にかけるのもアーキテクトとしての大事な仕事では?

データベースはdetailかもしれないけど、データモデルは違うよなぁ〜まぁそれは別の人の仕事か...でも実装工数考えるとデータベース使う前提のシステム作るかどうかって先に決まる気がする

 

仮に工数とかが十分だったとしても個人的には◎は選ばないかもなぁ〜

でも、実装の設計レベルでは似たことをやってるw

自分的に新しい手法を見つけたときに見てるところ

こじんてきめも

 

どっからか新しい手法を見つけるところがスタート

ネット徘徊してたりすると意外と転がってる

 

見ても放置すること

適用した人の積極的コメント(たぶんこれがあるので目に入ってるので気にしない)

適用してない人の応援コメント(実は参考にならない)

 

いくつかの基準で分解する

元々どこに適用する為に作られてるのか

何の問題を改善しようとしてるのか

前提条件の有無

手法そのものの特徴

理論的背景

 

元々どこに適用する為に作られてるのか

元々の適用先がどこで、その適用先にはどんな特徴・特性があるのかをちゃんと把握する。これを大きく超えた適用は多分無理なので意外と大事

手法が2次以降の場合は可能な限りオリジナルまで辿っていく

 

何の問題を改善しようとしてるのか

大抵は類似の適用先に何らかの手法が存在してるはずなので、何の問題を改善したいのか・しようとしてるのかをちゃんと把握する

適用先+改善内容によっては積極的に取り込んだ方が良いことがある

流行っててもこれがズレてると効果が出ない

 

前提条件の有無

その手法には前提条件があるのか、ないのか(たぶんある)

前提条件をしっかり把握する(スーパーエンジニアが必要とか)

 

手法そのものの特徴

その手法そのものの特徴とか他との違いはざっくり把握しておく

大抵はこの前段階でほぼ調査終わってるはずだけど抜けてる可能性はあるので...

 

理論的背景

その手法はどんな理論を背景に作られたのか、経験則から導き出したのかなどを調べる

ここで、理論的背景を抑えないと使おうとしても上手く使えないとかが発生するので、個人的にしらない理論だとその理論から抑えないとダメなのですごく時間がかかる

後付けで理論的背景が追加される事もあるけど、それもよし

経験則から導き出したものだと、その人・環境特有な物の可能性があるので要注意

 

ここまで詳細に調べておけば

新しい手法をプロジェクトに取込たいってなったときに、手法のマッチングが出来るようになるので、場合によっては手法を修正したりする

 

まぁ何が言いたいかというと、

使って当然的に言われてる手法の○○って本来と、現実の実現方法でだいぶ根本がズレてないか?って思うことがあるので気になってるw