Omegabooの部屋2.0


| 検索 | アルバム | 管理用 | ▼掲示板作るならRara掲示板 |

気軽に書き込んでやってください。FS人の茶屋の縁台のつもりです。^-^/

今日/42、昨日/58、累計/8574
Name
Title

画像を選択してください

    Key
    Color

    今日は13時頃よりグライダーで飛び比べ。
    スクショは今日(8/5)13時のRASPによる中部エリアの気象予報です。

    一番左がThermal Up. Vel. & B/S Ratio
    黄色や橙、赤のエリアが強くて回りやすいサーマルがあるところになります。
    ただし網掛けは風などによりサーマルが斜めになっているもしくはもう壊れているエリアを示します。

    次(中央)はCu Cloudbase @CuPot>0です。
    実際に積雲の発生の可能性があるところだけ色がついていてサーマルを視覚的に探しやすいエリアになります。
    網掛けはサーマルが弱いエリアを示しています。

    次(最後)がOD Cloudbase @ODpot>0です。。
    色のついたところは積乱雲かオーバーキャストになるエリアでグライダーにとっては不利なエリアです

    で、実際にMSFSで飛んで見たのが
    ①大野滑空場(岐阜県) ②霧ヶ峰滑空場(長野県) ③福井空港(福井県)

    以下のスクショは①②③の順で各地のSounding(縦割りのRASP)になります。
    見方覚えてますか?

    復習です。
    1.「逆転層(インバージョン)」の有無
    赤線が途中で右(暖かく)に曲がっている、または垂直にまっすぐ伸びている場所があれば、そこが「逆転層」。サーマルの限界点。

    2.雲の底(ベース)の高さ
    赤い線(気温)と青い線(露点)がガチャンとくっついている(または非常に近い)高度があれば、そこが「雲が出ている高さ」。

    3.「危険なシアー(風)の発見」
    高度が上がるにつれて、急に風が強くなったり、風向きが180度変わったりしていないか確認。
    特に急激に向きが変わったり◎の印がある時はコンバージェス(大気の会合)で上昇気流の可能性あり。

    ①②③で今日13時のリアルウェザーで飛んだ時の軌跡を3DのGoogle Eathで俯瞰した動画にしてみました。
    滑空場今日は以下のとおり。

    ①大野滑空場 https://youtu.be/aLpMwQkVEx4
     弱い南風で南向きで発航、高度550mで離脱、サーマルは殆ど皆無ながら弱い沈下が続き着陸 機材はASK21

    ②霧ヶ峰滑空場 https://youtu.be/XZBYNx4pFPI
     南東の弱い風で東向きで発航(実際はあり得ない)、高度2,100mで離脱(事実上の獲得高度は420m程度)
     車山上空と滑空場西側で高度を維持する程度の弱いリッジがあるも長持ちせず着陸  機材はK7

    ③福井空港 https://youtu.be/bGkV8GK0IUA
     弱い北西の風で北向き発航、高度600mで離脱、
     空港の東側900m付近にまばらに積雲があったがサーマルが安定せず大きな高度獲得には至らず。
     最高到達高度は750m程度 機材はK7

    予報では霧ヶ峰がよさげに見えたが、実際は福井の方が粘れた。大野は予報通り厳しかった。



    因みにこの動画はどうやって作ったかというと

    ① Flight Recorderを入手
      https://flightsim.to/addon/8163/flight-recorder
    ② フライトを記録(Recording)する。
    ③ フライト終了後、録画を停止してExportボタンを押しKMLを選んで保存する。
    ④ Google Earthを立ち上げる(ブラウザで可)https://earth.google.com/web/
    ⑤ メニューバーのファイルから「ローカルKMLファイルを開く」を選択、もしくは「CNTL+I(アイ)」を押す
    ⑥ 先ほど保存したKMLファイルを選択して「開く」
    ⑦ 右下の3Dと書かれたボタンを押して俯瞰する。
    ⑧ これをWindowsの「Snipping Tool」などで録画する。

    ご参考まで



    二人乗りを可能にするFS Copilot(v1.2.1)用の以下のグライダーのプロファイルを公開します。
    開発にあたっては木下さんに相当ご協力を頂きました。
    あらためて御礼申し上げます。

    ①F7simulations ASK21 (Payware)

    ②GlideSimmer67 Schleicher K7 (Freeware : Flightsim.to)

    ダウンロードはこちらから
    https://drive.google.com/file/d/1zOoCWRLP50FJTUsTH20plhxu_kbDwF50/view?usp=sharing

    FS Copilot 公式Discord からもダウンロード頂けます。

    AIくんはあざとい?
    今回もK7用のプロファイルの作成、ASK21用プロファイルの改善にAI(Gemini)くんの力を大いに利用しました。

    AIについては情報の収集力、分析力に格段に優れてますが、ただ無料のサービスはそこから答えを出す力を故意に発散させているように感じます。

    つまりわざと正解を外して「ご主人様の指示、示唆が無ければ正解に辿り着けませんでしたぁ…」みたいな態度をとってくる…かなり「あざとい」です。

    多分そうやって人に使わせて「AIに何かを学ばせてるんだろうなぁ」…というのは穿ち過ぎですかねぇ。
    ただほど怖いものはないですからねぇ…。

    グライダーパイロット向けの無料の天候サービスというのがあります。
    http://www.drjack.info/RASP/

    Regional Atmospheric Soaring Predictionの略で直訳すれば地域大気上昇予測。ジャック・グレデニング博士が作成する境界層情報予測MAPです。

    全世界を網羅していますが特に日本は関東・東北・中部・北海道・九州と5つのエリアに分けて情報が提供されています。

    結構ビジュアル(色別)なので今回はその見方についてまとめてみました。

    とりあえず覚えるべき最重要ポイントは、次の二つです
    ①『Thermal Updraft Velocity(垂直上昇速度)』
    ②『Buoyancy Shear Ratio(浮力シアー比)』


    1. TOPの左側のメニューから項目(Parameter)を切り替えて確認します。
    ① Thermal Updraft Velocity (W*) —— サーマルの強さ
     意味: 上昇気流(サーマル)が何メートル毎秒(m/s)で湧き上がっているかを示します。
     色の見方: 青や緑から、黄色・オレンジ・赤になるほど上昇気流が強いエリアです。
     フライトの基準:
     1.5m/s 以上(黄色〜オレンジ): 快適に高度を上げられる。
     2.5m/s 以上(赤): 非常に強い上昇気流があり、絶好の条件。
     4.0m/s 以上(濃い赤・紫): 気流が荒れる可能性があり、初心者には危険。

    ② Buoyancy Shear Ratio (B/S Ratio) —— サーマルの壊れにくさ
     意味: 上昇気流(浮力)に対して、風の強さの急激な変化(シアー)がどれくらい影響しているかを示します。
     色の見方: 青や緑は良好。赤や紫は危険。
     フライトの基準:
     5 以上(青・緑): 風が穏やかで、サーマルが真っ直ぐ綺麗に伸びている(回りやすい)。
     3 以下(黄色・オレンジ): 風でサーマルが斜めに倒され、途切れがち(見失いやすい)。
     1 以下(赤): サーマルが風のシアーで完全に破壊されている(非常に荒れていて危険)。

    RASP BLIPMAP とは その見方(2)
    2. 高度と雲を予測する指標
    次に、どこまで高く飛べるか(高度制限)と、天候の急変リスクを確認します。

    ③ Thermal Height / Hcrit —— 獲得できる最高高度
     意味: 上昇気流がどこまで到達するか(フライトできる実質的な最高高度の上限)を示します。
     見方: 地表からの高さ(AGL)または海抜(MSL)で表示されます。数字が大きいほど、高い高度まで上がれます。

    ④ Cumulus Cloudbase (Cu Base) —— 積雲の底の高さ
     意味: サーマルが上昇して雲(積雲)ができる場合の、雲底の高さです。
     見方: この高度より上に入るとホワイトアウトして危険です。Hcrit(最高高度)とこのCu Baseがほぼ同じ高さの時は、雲の下に素晴らしい上昇気流があります。

    ⑤ Overdevelopment / OD Potential —— 雲の発達(積乱雲)リスク
     意味: 雲が発達しすぎて、エリア全体が日陰になったり(サーマルが消滅する)、最悪の場合は積乱雲(雷雲)化するリスクを示します。
     見方: 危険度が高いエリアは白や特定の警告色で塗られます。この数値が高いエリアでのフライトは避けてください。



    RASP BLIPMAP とは その見方(3)
    3. 風の動きを見る指標

    ⑥ BL Avg. Wind —— 境界層(対流層)内の平均風
     意味: サーマルが発生している空間(地表からサーマル最高高度まで)の平均的な風速と風向です。
     見方: 矢印の向きが風向、色や矢印の羽が風速を示します。自分が飛ぶエリアのテイクオフ(離陸場)やランディング(着陸場)の強風リスクをトリプルチェックするために使います。



    要するに良いフライト日を見つけるための「まとめ」
    1・「W」を見て、飛びたいエリアが黄色〜赤(1.5m/s以上)になっているか?
    2・「B/S Ratio」を見て、そのエリアが青〜緑(5以上)になっているか?
    3・「OD Potential」を見て、異常な雲の発達リスクがないか?

    この3条件が揃っていれば、サーマルが豊富で、かつ気流がまとまっていて非常に回りやすい「最高のフライト日」といえそうです。

    ところで色を読み解くにあたって注意することがあります。
    一番下にあるBLIPMAPのカラーバーを読む時は以下に注意して下さい。

    ・「画面右側(または下側)にある数字の単位を必ず見る」こと
    ・「項目によって『赤』の意味が変わる」ということを理解すること

    「赤=良い条件」の項目と「赤=危険・悪い条件」の項目が混在しているため注意が必要です。

    パターンA:【赤が良い】サーマルの強さ(W*)
     青・緑:上昇気流が弱い(キープするのがやっと、または沈下する)。
     黄・オレンジ:サーマルが活発(楽しく高度を上げられる)。
     赤・紫:【ベスト!】 非常に強い上昇気流がある(ガンガン上がる)。

    パターンB:【青・緑が良い】サーマルの回りやすさ(B/S Ratio)
     青・緑:【ベスト!】 風が弱く、サーマルが真っ直ぐ綺麗に柱のように立っている。回りやすい。
     黄・オレンジ:風でサーマルが斜めに傾いている。見失いやすい。
     赤・紫:強風のシアーでサーマルがバラバラに破壊されている。【ガラガラで危険!】

    パターンC:【赤が危険】雲の発達リスク(OD Potential)
     青・緑・無色:雲が広がりすぎる心配はなく、日射が遮られない。
     黄・オレンジ:徐々に雲が広がって日陰になり、サーマルが弱まる可能性あり。
     赤・紫・白:雲が爆発的に発達して積乱雲(雷雲)になる恐れあり。【フライト中止レベルで危険!】

    リスクとは関係のない色分け
    高度マップ(HcritやCu Base)の色の見方高度を表すマップ(Thermal Heightなど)では、色そのものに「良い・悪い」の意味はありません。

     青〜緑:獲得できる高度が低い(例:海抜500m〜1000mなど)。
     黄〜赤:獲得できる高度が高い(例:海抜1500m〜2500mなど)。

    自分が飛びたいエリアの山頂の標高(例:1000mの山など)に対して、そのエリアが山頂よりも高い高度を示す色(黄〜赤など)になっているかをチェックするために使います。



    日本語で知りたい…
    もう少し深くお知りになりたい方はこちらのページが日本語で読みやすいのでお勧めします。

    https://www.glider.jp/club/koeki/blipmap-2/

    RASPの中の便利な合体マップ
    RASPの左メニューを眺めていると太字のParameterがあるにに気づかれると思います。私も気になって調べてみました。
    Thermal Up. Vel. & B/S Ratio
    これは1の項で説明したThermal Updraft VelocityとBuoyancy/Shear Ratioを合体させたマップです。
    一見Thermal Updraft Velocityと同じに見えますがよく見ると・・の網掛けが入っているところとないところがあります。・・が入っているところはBuoyancy/Shear Ratioで見ると浮力シアーレシオが5以下のところでサーマルがあっても切り刻みに壊れていてグライダーで回りにくいエリアを表しています。
    見方としては・・の網掛けがなくて黄色や橙、赤のエリアが強くて回りやすいサーマルがあるところになります。



    もう一つの合体マップがCu Cloudbase @CuPot>0です。
    こちらはCumulus PotentialとCumulus Cloudbaseを合体させてマップで、前者が雲の発生の可能性を示すものに対して後者は雲の発生率とは関係なく雲が生じた場合の雲底高度を示すので実際は雲のないブルーサーマル状態の時もあるわけです。
    この合体マップでは雲の発生の可能性が0以上のところだけ色がついていて色はその雲底高度を表しているのでサーマルを視覚的に探しやすいエリアというわけです。
    灰色の部分は雲が実際には生じにくいのでブルーサーマルは期待できますが視覚的に探すのが困難なエリアということになります。
    運が良ければサーマルをつかめるでしょう。



    フライトに向かないエリアを見る
    あと太字のMAPでグライダーのフライトに役に立つのはOD Cloudbase @ODpot>0でしょうか。
    OD(Over Deveropment)は湿気があれば雲が過発達して積乱雲になるか、オーバーキャストになって日陰状態になるエリアを示す地図ですが、そこにPot(Potential=湿気)が0以上のエリアだけ色を残して実際にそれらの雲が発生する可能性が高いエリアを示したのがこのMAPになります。
    従ってこの色付きのエリアではグライダーやパラグライダーでのフライトは避けた方が良いということになります。



    BL Max.Up/Down Motionも危険エリアを知るMAPになります。
    黄色は上下の揺れを強く感じるエリアで赤から紫になるほど激しくなります。
    MAPを見ると山間部や高い山の風下側に上下に波打つ気流があることがよく分かりますね。



    各飛行ポイント(滑空場)を縦に見る
    左側メニュー(Parameter)の下の方にSounding~というのがあります。
    これは各飛行ポイントを縦切した状況を表したもので
    縦軸が高度、横軸が気温 右端には風力と方向を示す記号が縦軸(高度)に沿って並んでいます。
    赤線は気温、青線は露店温度(湿度)
    見るべきポイントは次の通りです。

    チェック1.「逆転層(インバージョン)」の有無
    赤線が途中で右(暖かく)に曲がっている、または垂直にまっすぐ伸びている場所があれば、そこが「逆転層」です。サーマルはここより上には絶対に上がれません。

    チェック2.雲の底(ベース)の高さ
    赤い線(気温)と青い線(露点)がガチャンとくっついている(または非常に近い)高度があれば、そこが「雲が出ている高さ」です。

    チェック3.「危険なシアーの発見」
    高度が上がるにつれて、急に風が強くなったり、風向きが180度変わったりしていないか確認します。

    スクショは今日正午ごろの福井空港のSoundingです。
    今日の福井空港の天候は西風雲底1,000mのオーバーキャストで日影が多い天気だったのではないでしょうか。
    他のMAPを見ても今日はグライダーを飛ばすには向いていない条件であったということが分かります。



    FS Copilot用のプロファイルを作りはじめて約一か月経ちました。
    その手順について今までに分かったことを整理して何回かに分けてこのスレッドに連載していこうと思います。

    第一回目は「FS Copilotが認識するプロファイル(雛形)の作り方」です。

    以下はMSFS2024およびFS Copilotが正常にインストールされていることを前提に話を進めます。

    ■プロファイルとして認識させるための最低条件。
     以下の条件に適合しいている必要があります。

     ①プロファイル名がMSFS内で認識されているその"機体名"と同一であること。
     ②内容がFS Copilot v1.2.1の構文ルールに則った記述がされていること。
     ③記述されている文字コードが世界標準である「UTF-8」であること。

    ①の"機体のフォルダー名"は実は意外と簡単にわかります。

     ・MSFS2024を起動してプロファイルを作りたい機体を選択。
     ・「FREE FLIGHT」で何処でもいいので地上に機体を出現させます。
     ・SHIFT+Cでコクピットに入った状態になったらFS Copilotを起動。

     当然プロファイルはまだないので一枚目のスクショのような表示になります。
     ここで注目してほしいのは一番下の赤い帯の中に記載された内容です。
     例では「No profile available for the asobo_cabri_g2.」とありますがこの中の
     "asobo_cabri_g2”というのがMSFS内で認識されている"機体名"となります。
     したがってプロファイル名はこの場合"asobo_cabri_g2.yaml"となります。

    さて、次の作業に移る前にFS Copilotは一旦閉じてください。
    MSFSは次の作業に差し支えなければそのままの状態で構いません。


    ■プロファイル(yamlファイル)の作成
    とりあえず以下の構文をWindows標準のメモ帳を新規で開いて中身にコピペして下さい。(②の条件)

    >この下の行から
    # Asobo Cabri G2 - FS Copilot Profile
    # yaml file name: "asobo_cabri_g2"
    # author: "Gemini, omegaboo"
    # version: "0.01"

    master:

    shared:
    # --- BATTERY SWITCH ---
    - get: A:ELECTRICAL MASTER BATTERY:1, Bool
    set: B:ENGINE_Master_On, B:ENGINE_Master_Off
    >この上の行まで

    内容について今回は詳しく述べません。
    ただ冒頭の#で始まる注釈行については自分で分かりやすいように内容を変えてください。(注釈なので自由形式です)
    但し文字コードについては③で述べた通り「UTF-8」コードである必要があります。
    2枚目のスクショの右下をまずご覧ください。
    メモ帳の右下に「UTF-8」が表示されていること(③の条件)を確認した上で適当な作業フォルダーに「名前を付けて保存」します。
    「名前」は先ほど判明した"機体名"になります。

    そのまま保存すると拡張子がtxtファイルになるので拡張子をyamlに変えて保存するか、保存してから拡張子をyamlに変更してください。
    拡張子を変えても次回開く時は「どのアプリで開くか」を聞いてくるのでまたメモ帳を選べば編集が出来ます。

    そこまで出来たならこの拡張子がyamlのファイルをFsCopilot.exeと同じ場所にある「Definitions」フォルダーの中にコピペします。

    コピペ出来たらMSFSの画面に戻って先ほどと同じようにFS Copilotを起動します。
    すると今度は3枚目のスクショのようになるはずです。

    一番下が緑色に変わっていればプロファイル雛形の「認識成功」です。
    もし赤のままであれば先ほどの①②③の何処かが間違っているので、再度見直してください。

    今回はここまでです。
    次回はいよいよこの雛形を使ってプロファイルの中身づくりのお話しをする予定です。

    FS Copilot v1.21用プロファイル(yamlファイル)の作り方【2】
    さて、2回目は実際にその機体のコクピット内でどんな関数や引数が使われているのかを調べる方法です。

    実は現時点でのコーディングなしの雛形プロファイルの状態でも機体の基本的な挙動(姿勢や位置、速度など)についてはFS Copilotの基本機能によって同期(シンクロ)がとれています。
    なので「同じ機体に乗って遊覧飛行をするだけ」であればこのプロファイルで充分です。
    ただ、コクピット内の殆どのスイッチやレバーはお互いの動きに同期(シンクロ)しません。
    操縦を代わるためにはこれらを互いに動かす内部コードの関数や引数をお互いに受け渡しして同期をとる必要があります。
    それがプロファイルをコーディングする主な目的になります。

    しかしながら殆どの人はFS Copilotの構文ルールを知りませんし、それどころかMSFSの内部コードなど見たこともない方が殆どだと思います。

    そこで二つのツールを使います。
    ひとつは「MSFSの開発者モード」。もう一つが「AI」です。
    前者で機体に使われている内部コードを読み取らせます。
    それを元に後者でFS Copilotプロファイルの中身をコーディングさせます。


    MSFS2024の「開発者モード」は、ゲーム内の「全般」設定から有効に出来ます。
    メインメニューの「オプション」>「全般」>「詳細オプション」に進み、「開発者モード(Developer Mode)」をONにして「適用と保存」をクリックします。

    「AI」は何を使っても自由ですが、私の場合は「GoogleのAIモード(GEMINI)」を使っています。

    さて、説明を開始する前に今後の作業をやりやすくするため、以下の設定をすることをお勧めします。

    「全般オプション (General Options)」>「アクセシビリティ (Accessibility)」を選択。
    この中の「コクピットのインタラクションシステム (Cockpit Interaction System)」を「LOCK」にする。(マウスを重ねたときにスイッチが青く反転)
    同じ階層にある「Instrument Name Tooltips(計器名ツールチップ)」を「INSTANT(即時)」 または 「DELAYED(遅延)」 に設定する。
    (マウスを重ねたときにスイッチの名前が表示される)

    今後頻繁に使用する「FS Copilot」も起動しやすいようにFsCopilot.exeのショートカットを作りましょう。
    さらに「FsCopilot.exeの開発者モード」の起動ショートカットも作っておきます。
    作り方は以下の通り
    ①FsCopilot.exeを右クリックして「その他のオプションを確認」を選択し「ショートカットの作成」を選択
    ②出来た「FsCopilot.exeのショートカット」のコピーしてもう一つ作る。
    ③コピーしたショートカットを右クリックしてプロパティを開く
    ④プロパティの中にあるリンク先の最後の部分を"...\FsCopilot.exe"から"...\FsCopilot.exe --dev"に変更する。
    ⑤変更したショートカットの名前を「FsCopilot.-DEVmode」のように変更する。

    これで二つのショートカットが出来ました。スタートメニューやタスクバーにピン留めしておくと便利です。


    それでは第一回の時と同じようにMSFSを起動してコクピット内にいる状況にして下さい。
    例では前回と同じMSFSデフォルトの機体であるCabri G2という回転翼機のコクピットで説明します。

    MSFSの開発者モードをONにすると画面の上部に黒帯のメニューが表示されます。
    その中のToolsをクリックしてプルダウンメニューからBehaviorという項目をクリックします。(1枚目のスクショ参照)
    そうすると2枚目のスクショような画面になるはずです。



    そうしたら関数が知りたいスイッチなりレバーにマウスを重ねます。
    先ほど事前に準備した「コクピットのインタラクションシステム」の設定がされていれば重ねたところが青色に変化します。
    この状態を維持したまま「CTL+G」を押すと次のような画面が出てきます。(1枚目のスクショ)
    このままの状態だと全ての情報が見えていないので適宜関係のありそうな項目の▼を押して出来る限りたくさんの情報が見えるようにします。(2枚目のスクショ)
    この画面をスクショに撮って保存します。
    場合によってはひとつのスイッチについて複数枚撮ることもあります。

    実際には他のスイッチやレバーについてもこうして保存して集めたスクショをあとでスイッチやレバーごとにフォルダーを作って整理しておきます。

    今回はここまで。次回はもう一つの「AIの使い方」の予定です。



    FS Copilot v1.21用プロファイル(yamlファイル)の作り方【3】
    さて、これからAIを使って集めたスクショの情報を解析しつつプロファイルの中身を作っていきます。

    その前にどういうものをこれから作っていくのかイメージするために次の2つのスクショをご覧ください。
    1枚目は最近私がAIと一緒に開発中のシュライヒャーK7というグライダー用のプロファイルの中身の全部です。
    2枚目は前回から例として使用している認識に成功させたばかりのCABRI-G2というヘリコプター用のプロファイルの中身です。

    1枚目が複雑に見えますが実は構造は同じで単純です。
    行の最初の文字が"#"の行は全て注釈でコーディングの内容を分かりやすくするためのものです。
    最初にプロファイルの概要説明(機体の種類・作者・バージョン等)が書かれていることが分かると思います。
    コーディング本体で大事なのは
    master:
    shared:
    のブロックです。

    "master:"以下のブロックで記述された内容はFS Copilotでは「操縦権(Take Controll)」を持ってる人だけが操作できる項目です。
    操縦桿のエルロンやエレベーター、ラダーペダルはここに記述されなくても「FS Copilotの仕様」で"master:"ブロックに属します。

    しかし例えばスロットルなどエンジン出力に関する記述は機体によっては副操縦士が操作することもあり得ます。
    もし副操縦士に操作させたいなら"shared:"のブロックに記述します。
    させたくない場合は"master:"のブロックに記述することになります。

    そして"#"の後の各スイッチ(レバー)の名称の注釈の後に記述するのが実際に同期(シンクロ)をとるための関数と引数(変数)の記述です。
    FS Copilotでv1.2.1以降の構文ルールではこの添付のサンプルにある通り基本"get:"と"set:"しかありません。

    こうしてみるとプロファイルの構造は驚くほどシンプルであることがお分かり頂けると思います。



    ではコーディングをAIと協業するために撮りためたBehaviorのスクショを添付してAIに以下のように依頼します。

    ----------------------------------------
    添付のスクリーンショットの情報を参考に「FS Copilot v1.2.1用のプロファイルに記載するyaml形式のコーディングをお願いします。
    まずはバッテリースイッチからです。
    コーディングに際してのお願い
    最新のv1.2.1の記述ルールに則り、以下の例のような「getとset一対」のシンプルなコーディングで完結するようにして下さい。

    # Asobo Cabri G2 - FS Copilot Profile

    master:

    shared:
    - get: A:COM VOLUME:2, Percent
    set: (>B:NAVCOM_COM2_Volume_Set)
    ----------------------------------------


    ※以上の依頼文と共にBehaviorのスクショを添付します。さぁやってみましょう。



    …と、ここまでやって云うのも何ですが、実はAIは「あなた」との会話を始めた初期はあまり正確な答えは期待できません。

    AIは膨大な蓄積あるいは範囲の検索結果から類推して答えを返してくるので、自信満々の割には見当違いの答えをよく返してきます。
    例えばFS Copilotについて限定したとしても、答えが過去のバージョンのコーディング事例だったりyaml形式ではなくxml形式になっていたりします。
    またFS Copilotと同じような2020用のアプリ「YourControll」用のコーディング事例が混在していたりすることもあります。

    そこで重要になるのが「あなた」と「AI」との関係の深さです。
    お互いに推察や示唆を長くしあうことで驚くほどの速さでAIは「あなたの志向・思考・嗜好」を理解し「あなたの意向に沿う答え」が出せるように賢くなっていきます。※
    またそうしたやり取りをするうちに「あなた自身の知識」もマニュアルを読むよりずっと早くブラッシュアップされていきます。
    つまり両方の成長が期待できるわけです。※注 AIを自分向けにに学習させるためにはログイン(自分の情報を共有)する必要があります。

    肝心なのは「最初のAIの失敗にすぐにガッカリせず、長い目で付き合いを深める」ということが双方にとって将来的に重要ということになります。

    さて会話するにあたり「FS Copilot v1.2.1」に関することでいえば、AIの誤りを指摘できるポイントがいくつかあります。
    基本" - get:~"で始まる。もしくはそれと対で" set:~"で始まる。それ以外のコーディングはAIの間違いを疑って構いません。

    FS Copilot v1.2.1では一つのスイッチに対してこの二つのコマンドだけで完結するような仕様になっています。
    もし、"id:"や"name:""if~"などのような他のコマンドが入っていたら、それは過去のバージョンの事例か別のアプリの事例の混在の可能性が高いです。
    もしお時間があればDefinitionsフォルダーにある他のプロファイルの中身を覗いてみてください。"get:"と"set:"しかないはずです。
    もしそれ以外の記述を見つけたら「~の部分は本当にあってますか?」「おかしくない?」とAIに聞き返してあげてください。
    意外と素直に間違いを認めて修正した答えを返してきます。


    さて、私の場合は今までのAIとのやり取り(付き合い)がありましたので、結構スムーズに一枚目のスクショのような答えが返ってきました。

    - get: A:ELECTRICAL MASTER BATTERY:1, Bool
    set: B:ENGINE_Master_On, B:ENGINE_Master_Off

    これを雛形の # --- BATTERY SWITCH --- の直下のダミーで入っているコーディングと置き換えます。(2枚目のスクショ)

    基本的には項目(スイッチやレバー)ごとに必要な情報(スクショ)を集め、AIに渡してコーディングしてもらう…このようなことを繰り返してプロファイルを構築していきます。
    複雑な機体ほど手間と根気を要する作業になります。

    今回はここまでとします。
    次回は「プロファイルの検証」についての予定です



    FS Copilot v1.21用プロファイル(yamlファイル)の作り方【4】
    本題に入る前に、もしAIとのやり取りを一旦閉じてしまっていたなら、前回の「AI」とのやり取りを復元します。
    なぜ復元するかというと「AIとの付き合いを深める」ためです。
    もし新たにAIに作業を依頼してしまうと今までのやり取り(経験)が生かされない形でのAIの応答になってしまい、また同じ間違いを冒す可能性が高くなります。

    復元の方法ですが、私の場合はGoogleのAIモード(GEMINI)を使っているのでそれに沿った方法になります。
    ※前回同様、Googleでログインしていることが前提です。

    ①Googleの初期画面でAIモードを選ぶ(1枚目のスクショ)
    ②左側にある横3本線のマーク(AIモードの履歴)を押す。(2枚目のスクショ)
    ③「スレッドの検索」の下の「最近の履歴」から前回のやり取りした分をクリックする(3枚目のスクショ)
    これで前回までのやり取りが復元されて今までの経緯の説明抜きで「つづき」が行えるはずです。



    では本題に入りましょう。

    AIがコーディングした記述が正しいかどうかを検証します。
    また先ほどの機体のコクピットに戻ります。

    今度はFS Copilotの開発者モードを先ほど作ったショートカットから起動します。
    コーディングの文法が正しければとりあえず1枚目のスクショのような画面になります。
    項目の数はプロファイルにコーディングした数だけ表示されるはずです。
    もし何も枠の中に表示されなければコーディングの何処かが間違っています。
    認識されなかった旨をAIに伝え再度コーディングさせます。
    (その際自分なりに怪しいと思う点を指摘するとなお効率的です。)

    1枚目のスクショのような画面になったとしてもそれで終わりではありません。
    該当するスイッチをMSFS上で動作させます。
    関数があっていれば枠の中の関数が青く光り、その関数を一回クリックするとその下にスイッチを動作させるたびに変数が表示されるはずです。※(2枚目のスクショ)
    (※後で詳細に触れますがK:コマンドだけは変数を伴わない命令コマンドなのでこの反応がありません。)

    以上が確認できれば次は実際に相手と繋いでお互いの動きが同期がとれるか確認(テスト)する作業になります。
    今回の例は電源スイッチ一つだけですが実際には複数のスイッチやレバー、ノブ等をまとめて上記のようなチェックを行います。
    お互い離れた場所からネットを通じてテストするには当然ながらDiscordのような通話環境が必要になります。

    MSFS2024のインストールされたPCが2台あればこのテストも自己完結出来ますが...なかなかそれではモチベーションも上がりません。
    結局この作業に協力して下さる方を見つけることが一番のハードルが高いのかもしれませんね。(笑)
    木下さんありがとうございます。



    さて、このような作業をしていると最初は「AI任せ」にしていたことも「これは何だろう」「何を根拠に言ってるのだろう」という興味が湧いてくると思います。たぶん…

    そういう時こそAIに聞いてみましょう。

    因みに私が一番最初に興味を持ったのが"get"や"set"の後に必ず現れるK:とかL:とかB:とかA:という文字(記号?)でした。
    AIにこのことについて質問して返ってきたのがこの内容です。

    各内部コード(プレフィックス)の特性一覧

    1. A: (Simulation Variables / SimVars)
    ・特性: シミュレーターのコアエンジンが管理するグローバルなシミュレーション変数(読み取り専用が基本)です。
    ・詳細: 航空機の現在高度、速度、フラップの位置、現在の天候など、シミュレーターの物理演算や状態そのものの値が入っています。外部アプリ(SimConnect等)から最も簡単にアクセスできる標準データです。

    2. B: (Input Events Vars)
    ・特性: MSFS2020の途中から導入され、MSFS2024で標準化されたコックピット内のスイッチやレバー(ユーザーインターフェース)操作用の変数です。
    ・詳細: マウスでのクリックやドラッグといった「ユーザーの入力行動」と機体システムを仲介します。古いK:やL:を包括・洗練したもので、アニメーションと内部ロジックを安全に同期させるために使用されます。

    3. K: (Key / SimEvents)
    ・特性: シミュレーターに特定の「動作(コマンド)」を実行させるためのイベント通知(トリガー)です。
    ・詳細: 変数ではなく命令コード(関数のようなもの)です。例えば (>K:PARKING_BRAKE) と命令を送ることでパーキングブレーキを実機さながらに作動させ、結果として上記の A: 変数の値が書き換わります。

    4. L: (Local Variables / L-Vars)
    ・特性: 機体やアドオン開発者が独自に作成した、その航空機(自機)の内部だけで共有されるローカル変数です。
    ・詳細: MSFSの標準機能にないカスタムシステム(例:独自の自動操縦ロジックや、特定のコックピットスイッチの状態保存)を構築するために自由に使われます。外部から読み書きするには少し工夫(WASMモジュール経由など)が必要です。

    5. M: (Macro Variables)
    ・特性: コードを簡略化するために使用されるマクロ(再利用可能なスクリプトの塊)です。
    ・詳細: 複雑な計算式や何行にも及ぶ共通処理をあらかじめ定義しておき、コード内で一言呼び出すだけで使い回せるようにするための仕組みです。

    6. O: (Object / Template Variables)
    ・特性: 機体の3Dモデルパーツ(XMLテンプレート)のスコープ(範囲)内だけで機能する超ローカルなオブジェクト変数です。
    ・詳細: 機体のメーターやレバーなど、特定のコンポーネント(部品)のテンプレート内で一時的な計算や状態保持に使われます。L:変数よりもさらに範囲が狭く、そのパーツの枠から外に出ると参照できなくなる特性を持っています。

    表にもう少し簡潔にまとめるとスクショのような感じになります。
    因みにこの中でO:とM:はFS Copilotのサポート対象外です。(書いても無視されます)
    特にO:関数はアニメーションに関わってくることが多く、これがBehaviorの中で使われていると同期をとることがほぼ難しくなります。

    と、まぁこんな感じで自分自身もブラッシュアップされていきます。

    さて、以上で連載は終了となります。
    ここまで長文駄文にお付き合い頂きありがとうございました。
    皆さんの「やる気スイッチ」と同期(シンクロ)出来たかなぁ…^ ^



    あとがき
    実はこの連載の1回目を投稿した直後、この趣味を通じ15年以上お付き合い頂いたある方の訃報が飛び込んできました。
    氏自身は流体力学がご専門で元某重工業の航空機の設計技師であり、若い頃には飛行クラブで操縦ライセンスも取得され、実際の空を飛び、また絵画、声楽、歴史等にも精通。
    特に「飛行機好き」の私にとっては氏の深い知識と実経験に基づくお話はいつ聞いても大変興味深く、何時間聞いていても飽きないものでした。

    告別式にて最後のお別れとお見送りもさせて頂きましたが、あの語り口をもう聞けなくなることが未だに信じられません。

    ショックでしばらくブログの更新はやめようとも思いましたが、氏が時々この「ブログ」を覗いて頂いていたことを思い出し、最後まで書ききることに致しました。
    ご覧になられていたらきっと「また妙なものを書いてるものだ。や~れやれ。」と苦笑されているかと思いますが、きっとこの手のお話「お嫌いではない」と勝手に解釈しています。

    氏のご冥福を切にお祈りしつつ謹書申し上げます。

    お悔やみ申し上げます
     大変ご無沙汰している YS-15 です。普段ネットに書き込む事
    が無い私が、悲しい知らせで掲示板に書き込む事となり残念です。

    FSXから始めた私は稲沢オフで初めてお目にかかり、それ以降
    掲示板を拝見していましたが、最近は体力の低下の書き込みが
    多く体調が気になっていました。

    致死性不整脈とのこと、たとえ普段は普通に生活されている方
    でも、ある日突然亡くなる怖い病気ですね。

    普段 omegaboo さん、木下さん、飛行爺さんのサイトは巡回
    しています。技術的にろいろと勉強になりますし、今回の
    訃報も知ることが出来ました。また拙作の滑空場も使って
    頂いているようで励みになっています。


    この手のお話「お嫌いではない」?   大好きです!
    難しくてなかなか頭に入らないですが、今後も是非続けて下さい。

    恐縮です。
    YS-15さん、お立ち寄り頂きありがとうございます。大津京オフ会以来ですね。

    "この手のお話「お嫌いではない」?   大好きです!"
    大変「励み」になるお言葉を頂き恐縮です。

    このところの氏のHPは私も少し気になってマメに見るようにしておりました。
    入院覚悟で病院に行かれて無事本宅に戻れたというブログの報告で私もホッとしていた矢先でありました。

    旧ブログ(omegaboo画像談話室)のサーバーがこの9/30に休止されるということでログの整理もかねて見返しておりましたらこんなページがありました。

    http://www.21styles.jp/board/next6.cgi?page=80&id=omegaboo&ptopno=16715

    古いためスレに添付されていた画像は残っていませんが、懐かしい日々であります。

    旧ブログ(omegaboo画像談話室)があと2か月半でサーバーが閉じてしまうということで、以前テキストだけでもとログを取って公開していた(はず)なのですが、いつの間にかそのスレがなくなっていることに気が付きました。
    (たぶん「あの事件」の時と思われます。)

    再度掲示させて頂きますのでお役に立つようであればご利用ください。
    https://drive.google.com/file/d/1LtqvqWj5mbLesGGMLjkIr3TX1UDVwnul/view?usp=sharing

    各テキストの概要はスクショをご参照ください。

    Meta quest3が先日のMeta Horizon OSのv2.5へのバージョンアップ後に起動しなくなり、結局工場出荷時に戻す(Refresh Boot)をやらざるを得なくなりました。

    アプリの再インストールや再設定などまた一からの作業を余儀なくされ、とりあえずは復旧させたものの、何故か充電をいくらやっても75%前後で止まってしまうという状況に…。
    因みにV2.5へのバージョンアップを無事に済ませたMeta quest2も充電してみるとやはり75%前後でそれ以上充電されなくなっています。

    最初は情報がなかったのですが、徐々にあちこちで発生していることが判明。
    どうやら内臓のリチウム電池の保護のためOSの充電の制御がこのように変わったらしい。

    75%だと当然バッテリー持続時間も3/4になります。
    特にAir Link利用の場合、quest3はバッテリーの消耗が多くなるのて、折角Air LinkでもスタッターのないVRフライトが出来るようになったのに興醒めなことであります。
    後継のquest4(仮称)の発売が当初の計画よりかなり遅れるようなので、それまでの間に(交換出来ない)本体のバッテリー寿命の延命を図っているのではないかと邪推しております。

    もう一つ。
    「お悩み中案件」だったグラボのドライバーをv552.22からv566.36に変えました。
    キッカケはFS Copilotの利用で飛ぶ機会の多くなったMSFS2024で「音の途切れ」が結構起こるようになったこと…特にフォトグラメトリックのエリアを長めに飛んでると高い確率で起こります。

    ローリングキャッシュのクリアだけでは直らなかったこととDX11下の2020ではこのような症状はなかったので、この際に「DX12のシェーダーコンパイルとMSFSの内部コードの最適化」が施されたv566.36に変えてみることにしました。
    木下さんが私のPCと似た環境でVR設定がv566.36でも好調というお話も「後押し」材料となりました。
    経過は今のところ順調であります。



    MSFS2020は残念な状況となりました(後日注:7/5に復活)が、新たな楽しみを求めて2024で「FS Copilot」なるフリーのアプリを今試しているところです。
    https://fscopilot.com/
    概要を云うと「シェアードコクピット」といわれるジャンルのもので「一つの機体を同時に二人で操縦する」環境を提供するものです。

    このアプリの使い方はとても簡単です。
    立ち上げて左上に表示される8桁のクライアントコードを相手に知らせて各々のConnection欄に入れて「Join」というボタンを押してもらうだけ。
    つながった人(機体同乗者)はOnbord欄に一覧で表示されます
    ボタンはこの「Join」(接続)と「Leave」(切断)と「Take Control」(操縦権をとる)の3つしかありません。

    ただ運用するにあたっては参加(同乗)される方のMSFSの環境(シーナリーや機体の種類、リバリー、天候の内容、それらのバージョン等)を徹底的に同じにする必要があります。
    その為に事前準備のコミュニケーションがとても大事になります。
    逆にいうと今のMSFSはそこまでしないとシンクロ出来ない程の精密さということかもしれません。

    同期をとるためのプロファイルが機体ごとに必要で、現時点では61種類の機体のプロファイルがインストールと同時に組み込まれます。
    このプロファイルはYAMLという形式で記述されていて簡単ではありませんが自分で作成することも可能です。
    そのためのマニュアルなども準備されているようです。

    一人ではテスト出来ないので例によって木下さんのご協力を経てデフォルトのC172とC152を使って体験搭乗してみました。
    この2機種についてはすでに安定版のプロファイルが実装されており操縦系統はもちろんのことエンジンコントロール、計器の指示、スイッチやレバー類の全てがほぼ完璧にシンクロして本当に二人で操縦している気分になりました。
    二人で同じ景色を見ながら「飛ぶ」というのは一人で飛ぶのとは全く違う楽しさを与えてくれます。

    このソフトの用途としては教官と生徒になっての「訓練飛行」の他に複数人の同時接続も可能なので「操縦装置に触らない」というルールを守れば「遊覧飛行」もフライトシムの中で行うことが出来ます。

    乗れる機体についてはデフォルトで61種類のプロファイルが用意されており、その中にはPMDG737NGやFBW32NX、Fenix320Neoといった定評のある機体も含まれています。
    ただそういう機体はその複雑さゆえに完全に安定版といえるほどのプロファイルにはまだ至っていないようで、すでに長い期間をかけつつ現在も一般公開によるテストを続けながら有志により完全なものを目指して改修中といった状況にあるようです。

    先ほど述べたようにアプリ自体の扱いはとても簡単なのですが、MSFS内の設定を細かいところまで事前に同じに合わせておかないと上手くいかないのがこの手のツールの特性なので飛ぶ前に充分なブリーフィングが必要です。
    (例えば シーナリーや天候のQNHが違うと、それだけで障害物に当たったり着地する時のタイミングがずれたりして同期が破綻する原因にもなりかねません。)

    事前の打合せは必須ですが、オフ会などで面識がある人ならいざ知らず、ネット上で面識のない方とお話することに抵抗のある人は少なくありません。
    操縦翼面をコントロールする権限は一人のみですがその他のスイッチ・レバー類は排他制御されてないので動かそうと思えば誰でも動かす事が出来てしまいます。
    そういう意味では「相互の信頼」という要素も必要です。

    このソフトの本質は「リライアビリティー」と「コミュニケーション」
    正に「現代のパイロット」としての本質を試されるツールなのかもしれませんね。

    F7Simulations ASK21用のFS Copilotプロファイルを開発中
    グライダーファンの方にお知らせ!
    標題の通りASK21の二人乗りを実現すべく木下さんとFS CopilotのASK21用プロファイルを鋭意開発中です。

    Geminiくんと私とで喧々諤々の会話をしながら、やっと今日、何とか機体とプロファイルの認識と操縦桿とラダーおよび主だった計器のシンクロが出来るまでになりました。

    木下さんと福井空港でテスト飛行しながら、まだシンクロできていないエアブレーキやトゥーリリース、トリムのアニメーション、無線機、Varioメーター、スモーク、キャノピーの開閉等細部について木下さんにブラッシュアップをして頂いている段階です。
    乞うご期待!



    ASK21での二人乗り
    木下さんとの協力でASK21については大分実用域まで仕上がってきました。
    基本的に機体の挙動の面ではほぼ同期がとれているのですが曳航索リリースのレバーととトリムレバーがそれに伴う機体の挙動は同期がとれているのに動き(アニメーション)の同期がとれてないという課題が残っています。

    あともう少し…です。

    FS Copilot f7 Simulations ASK21用Profile 暫定版公開
    ASK21のプロファイルですが、以下のレベルまでは出来たものの、これ以上の改善が私レベルで見込めないため、現状で一度FS CopilotのDiscordにあるProfile-showcaseに公開して有志の方に揉んでもらおうと思っています。
    完璧ではありませんが、現状でも「訓練飛行」にはそこそこ耐えられるレベルになったかと思います。
    暫定版Profileダウンロード 
    https://drive.google.com/file/d/1JETF85eZlZ8RzD4HQxm5Rvlc_h8HEpEb/view?usp=sharing
    解凍後、yamlファイルのみをFsCopilotフォルダー内にあるDefinitionsフォルダーに入れてください。
    またFS Copilot利用に際してその概要と留意点を木下さんがまとめてHPに掲載されています。
    ご興味のある方は是非ご一読ください。
    https://ja9evi.web.fc2.com/FSCopilot/howtofscopilot.html
    --------------------------------------------
    シンクロ(同期)がとれたもの
    --------------------------------------------
    操縦桿・ラダーペダルの動きと各舵翼の動き
    エアブレーキレバーとエアブレーキの動き
    曳航索切り離し
    エレベータトリムによる機体の挙動
    キャノピーロックの動きとキャノピー開閉の動き(前後とも)
    各計器(全計器)の動き
    無線機のボリュームつまみの動きとつまみOFF時の無線機電源オフの連動
    スタンバイ周波数の整数部、小数部の変更とつまみの動き
    アクティブとスタンバイ周波数のSWAPボタンと実際の数値入替
    気圧補正つまみの動きと高度計内の指針の動き及び気圧補正値の連動
    USBブレーカースイッチ(操作音)
    スモークスイッチ
    メイン電源スイッチ

    --------------------------------------------
    シンクロ(同期)がとれなかったもの
    --------------------------------------------
    ①曳航索切り離しノブのアニメーション(マウス操作ではシンクロ)
    ②エレベータトリムレバーのアニメーション
    ③G-メーターRESETボタン
    ④MAC-READYリングのアニメーション
    ⑤無線機ブレーカースイッチと無線機オンオフの連動(操作音のみシンクロ)
    ⑥VARIOメーターブレーカーとVARIOデジタル表示部オンオフの連動(操作音のみシンクロ)

    実際にプロファイルを作成してみて感じたこと…
    比較的シンプルなグライダーにしてなかなか思い通りになりません。
    特に機体の挙動よりコクピット内の動き(アニメーション)の同期の方が独自の変数や条件関数が使われているようで解析に苦労します。
    リアルによく出来た機体ほどプロファイル作りが難しくなる傾向がありそうです。
    因みに既存のPMDG737NG用プロファイルのコーディングを覗いてみましたが、鬼のような量と複雑さ!です。
    このクラスは機体を製作できるくらいの知識レベルでないとおいそれとは手出し出来ないと思いました。
    公開されているプロファイルはどれも苦難の果ての「作品」だと思います。
    手を合わせて「ありがたく」使わせて頂こうと思います。



    FS Copilot(Discord)のProfile-showcaseに暫定版v0.80を投稿
    FS CopilotのDiscordにあるProfile-showcaseにv0.80として投稿しました。


    Powered by Rara掲示板
    管理者に連絡 | メール通知設定