Flight Coach BBS

BBSへの書き込みありがとうございます。
私は専門的な知識が無いので良くわからないのですが、
著作権等に関わって来る可能性のある内容については、修正や削除のご配慮を頂きたいと思っています。
その結果をみて、このトピックの取り扱いを決めさせて頂きます。

前回投稿しました方法と同様に、リボン図のジャンプの状況として、ジャンプ時刻までは正常な値で、ジャンプした後徐々に正常な値に漸近すると判断される場合に限って、ジャンプ時の値とジャンプ後数秒後の値を直線で結び、これに移動平均操作を施しました。前回のケースで、パラメータを吟味して与えた結果ジャンプのあったループのリボン図が下記のようになりました。移動平均したままですと多少凹凸が残りますので、前回と同様カルマン平滑化操作で凹凸を取り除きました。修正前のリボン図と合わせて示します。



　今回は前出のパラメータを吟味する前のリボン図と比較してかなり滑らかになり、不自然なところはありません。また、ジャンプ後の飛行軌跡もジャンプ前の飛行軌跡に沿った形になり、ジャンプ前後の移動平均操作を行った前出の場合と比較してジャンプの影響が見られず、実際にフライトした時の印象から判断してより実際に近い飛行軌跡になっているものと思われます。ただし、ジャンプ後の位置情報について直線近似後移動平均操作を行っていますので、その修正精度につきましては保証できません。ジャンプ前後の領域で飛行軌跡に大きな変化をもたらすようなプロポ操作を行った場合は、参考程度にお考え頂ければと思います。
　このように、ジャンプ時刻までは正常な値で、ジャンプした後徐々に正常な値に漸近すると判断される場合に限れば、今回の修正方法は有用な方法であると考えます。

離陸前の待機場所で敢えて充分時間を取っていると思えたので、不思議だなと思い質問しました。
引き続き試行してみます、ありがとうございました。

今日のフライトです。

このファイルは、たまたま携帯に保存してあったBINファイルをテストに使っただけなので、意味はありません。
普通に開いて、ジャンプエラーもありませんでした。
確かに140mとはなっていますね。特に気にしていませんでした。
8月のファイルなのに、この日付は今日になっていますね。
原因は良く分かりません。

そうでしたか。
私の場合、無効にしたり強制停止にしたり色々やっていて、アプリのアイコンが一旦消えた後に、再度有効にしたら上記の様になっていました。
理由は分かりませんが、とにかく良く動きます。
エッジもやってみましたが、同じ様に動いています。

スレ違いですが、上の9/3のjsonファイルのフライトデータのoriginが高度が140mになっています。
今日の初回のコールド状態でのものでしょうか？　　また、このフライトでのジャンプ等のデータ異常は無かったでしょうか？　質問ばかりで申し訳ございません。

情報ありがとうございます。
試行しましたが、アンドロイド携帯のクロームのバージョン（私のは105.xx）では残念ながら固まったままです。
キャッシュを消してもNGでした。
気が付いた点があれば、またご教示願います。
因みにiPhone8にマイクロソフトのエッジでチャレンジ、結果はプロッタが固まったままNGでした。

確かに、アンドロイドのChromeで、V2.2.1Hに自動更新されたら動かなくなってしまいました。
その後、何をしたか覚えてないのですが、再度Chromeを有効にしたら、プロッターが動く様になってました。
前よりサクサク動いて調子いいです。

正規版のV2.2.1Hに自動更新され、なんとアンドロイド携帯までiPhone8同様にNGでした。
飛行場で見られないのはストレスでしたが、今日クラブ員からエッジ上ではOKの話がありました。
確認したところ、アンドロイド携帯のエッジ上でのプロッタ動作OKです。
やっと飛行場でプロッタが見れます。

soramon様
ゼロから始めてもうプログラムが組めるとは、感服致しました。私の場合は、プログラムが組めるようになるには学び始めてから半年以上かかりました。Pythonには、移動平均やカルマンフィルターなどのデータ解析や辞書型データのJSON型データへの変換などのモジュールが揃っていますので、プログラミングが楽になります。
　さて、ジャンプ場所の特定ですが、私の場合は当該時刻の移動距離と前時刻の移動距離の比が閾値を超えた場合としました。データ間の時間間隔が一定ですので、soramon様の場合と同じことになりますね。ところで、私のフライトデータでは、JSONファイルの位置情報の移動平均を取った場合ジャンプ位置前後のデータの影響が残ってしまい、不自然な飛行軌跡となっていました。そこで、ジャンプ時刻までは正常な値で、ジャンプした後徐々に正常な値に漸近するようなケースに限って、ジャンプ時の値とジャンプ後数秒後の値を直線で結び、これに移動平均操作を施しました。ジャンプ後何秒後の値を直線で結ぶかはリボン図を見て適切な値を与える必要があります。このような操作を行った結果を下図に示します。なお、細かな凹凸はカルマン平滑化法で取り除きました。

　修正後のリボン図に直線部分が少し残ってしまいました。移動平均する個数やジャンプ後の直線近似するデータ数などのパラメータをもう少し吟味する必要があります。このケースでは、ジャンプ後はジャンプ前の飛行軌跡に沿った飛行軌跡になりますので、適切なパラメータさえ与えることができれば、私のケースではこの修正方法は妥当と思われます。NED座標のN値の時間変化も示します。この手法の考え方が分かるかと思います。今回のケースのようにジャンプ後に正常な値に漸近するようなケースには、この修正方法は有用ではないでしょうか。

　次に変換ソフトの一般公開についてですが、私は少し懸念を持っています。といいますのは、soramon様や私が行っている方法は、Flight Coachが作成したJSONファイルを書き換えて使用していますので、著作権に抵触する可能性があるのでは、と思っています。修正の考え方を公開するのは問題ないと思いますが、その手法をプログラミングしたものを一般公開するには、少なくともFlight Coachの作成者の了解を得る必要があるのではないでしょうか。著作権につきましては、私は素人ですので慎重になりすぎているのかもしれません。この分野に詳しい方がおられましたらご教示頂ければ幸いです。

確かに、これまでのところフライトコーチの普及はそれほど速く無い感じですね。
実際に使っているのを間近で見たら驚くと思うのですが。
そういうチャンスや情報が少ないのでしょうか。
それとも、パソコンに関連するという事で、取っ付き難い感じがするのでしょうか。
いずれにしても、普及するのは間違いないと思うのですが。

TakJP 様
アドバイスしていただいたPythonで自動変換プログラムを書いてみました。
JSONファイルから、3軸それぞれの位置移動を2回微分して加速度をもとめそのベクトルの大きさが閾値（機体の移動・旋回性能？）を超えたところをジャンプ場所として自動抽出しました。
自動抽出したジャンプ場所を中心に１００データの区間をサンプル数３１個の移動平均を２回実施しました。ここでTakJP 様と同様に移動平均区間の開始と終了個所で多少不自然さが残ったので、全域をサンプル数１１個の移動平均を行ったものが以下のものになります。

Python便利ですね。素人でもJSONファイルの読み書きができました。アドバイスありがとうございました。

冬場と違って草木が茂っているこの時期は必需品ですね。
iSearchingアプリですが、最初、別のものを入れたら反応が良くなかったので、変えてみます。

キャノピー落下、、落とし物探しに大いに役立ちました。

==========忘れ物（落とし物）防止TAG============

本日朝一番のフライト、ミュゼットBPのキャノピーをラッチしないで落下させてしまいました。
落下した所は飛行コースです、背丈以上の草木がびっしりの場所です。
でも、10分程で無事（軽傷）キャノピー&フライトコーチを回収できました。
前回の3日間探した経験を生かし、ブルーツースの忘れ物（落とし物）防止TAGをキャノピーに取り付け、待機電流が小さいので常時ＯＮにしていました。

落下地点まで行き落下物のアプリの位置情報を確認、情報に従い近づくとブザーを鳴らすかアプリが質問してきます。
ブザーを鳴らすと1～2ｍ先で音が聞こえ草下の地表に落ちていました。カタログ上は位置情報は10m範囲ですが、見通しが良ければ50m位の実力がありました。
先週も他の方が同様なことがありました、まだ見つけられずです。
キャノピー落下は私自身は三度目の経験です。自分は間違わないは思い込み、、誰もが経験することですから落下時に対しての対応は必要かも知れません。

画像は、忘れ物防止TAG、アプリ、ブザー画面、位置情報です。
ご参考まで、

なるほど。
良く分かりました。

soramon様
既に使われているのですね！
フライト・コーチ、せっかく良いアイテムなので、機材の入手が困難になってきていたり
価格が高騰していたりで厳しい状況ですよね。手軽に入手できて、もっと普及すればいいの
ですが。
途中、つまづいたら色々と教えて下さい。

いえ、流石にガバナー効果のみでは減速はできず、スロットルコントロール
していて、上空での最低回転数を3000rpmにしてあります。ガバナーESCには
スロットルで指示した回転数を維持できることに期待しました。ノーマルESC
の方はスロットルを下げた際の回転数は測れていませんが、ブレーキ設定を
行っていないので風圧でかなり空転していると思います。

ポルコ様
自分も同じFCを使用しています。なおardupilotなどで紹介されているジャンパ一やダイオード撤去は実施せずに使用しています。パッシブブザーを付けるとMiniPix同様のサウンドが出るのでお勧めです。

感じも大事ですが、数字が出ていれば十分参考になります。
それで、
ループ中のスロットル操作は、両方とも全く無しですか。

参考になるか？ですが、小型機にガバナーESCを積み正宙返りを行った結果を
自分のブログに掲載しました。
https://rcairplane.exblog.jp/241566336/
下降時のブレーキ効果は大型機が有利と漠然と考えていましたが、重量の軽い
小型機の方が効果が出やすいのかもしれないと思いました。

落下スピードは、パワー次第で決まる垂直上昇性能と違って、基本的な機体の特性を知る良い目安になります。
色々な機体の状況も知りたいので、是非、情報を書き込んでみてください。
画像なしで結構です。

「どんな状態のとき何km/hだったか」、せっかく取ったフライトコーチのデータですから、見直すだけでもしてみましょう。

前の方が最後の演技に入ったら、起動して待機するように運用して様子をみてみることにしました

とりあえず

フルサイズをもう１機紹介しておきます。4例目です。

自然の摂理に反して、スピードグラフが右肩下がりになっています。
最低速、最高速、という呼び方にも合わなくなってしまいましたが、他と合わせた場所に表示しました。
機体　：例1----例2---例3---例4---(BP)
入口　：115----97---129---139---(65) km/h
最低速：108----96---119--<140>--(61) km/h
最高速：156---144---122--<120>--(98) km/h
出口　：150---130---108----88---(84) km/h
増加分：35-----33,  ➖21,  ➖51---(19) km/h
割合　：1.30--1.34--0.84---0.63--(1.3)
時間　：6.2----6.7----8.2---7.5---(6.0) sec

例3はリボンのカット位置が悪かったので、実際は7秒台ですね。

これらはフライトデータだけなので、機材については不明です。
こういったスピードで飛んでいる、といった程度に見てください。
もし実例があれば、公開していただけると有難いです。

モーターとESCの仕様も書き加えて頂けると良いと思います。
最後の例はコントラ+ガバナーESCでしょうか？
ベルトダウン+ESCのブレーキ設定？

フルサイズ機3例目です。

スピードグラフが平らになっていて、出口では逆に入口よりも遅くなっています。
機体　：例1----例2---例3---(BP)
入口　：115----97---129---(65) km/h
最低速：108----96---119---(61) km/h
最高速：156---144---122---(98) km/h
出口　：150---130---108---(84) km/h
増加分：35-----33-- ➖21---(19) km/h
割合　：1.30--1.34--0.84---(1.3)
時間　：6.2----6.7----8.2----(6.0) sec

こちらはフルサイズ機の2例です。


分かりやすい様に、両方のスピードや所要時間などを書き出しておきましょう。
割合＝出口／入口で、3番目はミュゼットBPの補正値です。

入口　：115---97---(65) km/h
最低速：108---96---(61) km/h
最高速：156---144---(98) km/h
出口　：150---130---(84) km/h
増加分：35----33----(19) km/h
割合　：1.30--1.34--(1.3)
時間　：6.2---6.7---(6.0) sec

いくつか調べていると、中にはこんなフライトもありました。

開始が45km/hと、かなり遅いです。
風でもあったのでしょうか。
上が遅い割に、下では速くなっています。
演技では風や操縦の影響が大きくなるので、データを比較する場合は注意が必要になります。

リボンの切り取りはRの接点から接点までを狙っているのですが、今回のは上手く合っていました。
所要時間は6.2秒です。

実際のP23.12演技で、降下スピードを調べてみます。
機体は今飛ばしているミュゼットBPです。

細かく見てみると‥
減速しながら69km/hでコーナーに進入し、Rの途中まで減速が続きます。
最低スピード61km/hになると、次は自然落下による加速です。
下のRの途中まで加速が続きますが、98km/hに到達する頃にはヘッドアップによる抵抗増加が勝ってきます。
そこからは減速し84km/hで終了、となっています。
所要時間は6.9秒となっていますが、リボン図をカットする位置がRの接点と合わなかったので、正確には6秒以下となるでしょう。

全く同感です。
MSG,のEKF3 IMU0 origin setを検知して外部への信号化ができればと考えます。
移動可能な信号となるはずです。
Origin位置がオール０でプロッタ表示NGでのLogを見ると、上記のメッセージが存在しません。
F.Cのプログラム変更をできる方がいたら可能性は高いです。
もしくは、他の方法があれば、、例えば、F.C電源投入後に最低2分のタイマーを用意するか、、等です。

貴重な情報をありがとうございます

とても参考になります

移動可能時間を知る有効で簡単な方法を見出したいです。どのくらいで妥協できるのかも。

追記
画像内記載の数字、　0,60,120秒はGPS捕捉後の時間経過を示します。

ご意見のとおりだと思います。
GPS捕捉のLED点灯後に少なくてもある程度の時間が必要と思います。
フライトコーチ電源投入後のミッションプランナでのLog（画像）を添付します。
また、Logをメモ帳のメッセージのMSGで検索すると、
MSG, 112139739, EKF3 IMU0 origin set
が出ます。
MSG,の後の数字で示す、112秒後（下６桁は秒以下のため無視）にOrigin位置を確定していると思われます。
但し、これは一例のデータです。
早ければ、数十秒～60秒以内で上記のメッセージが出る場合もあります。
一概には言えませんが、GPSが安定した状態においては、ある程度の時間経過後に飛行機を移動するのがベストと思います。

貴重な情報、ありがとうございます。
これまで、それほど待たずに飛行開始する事が多かったので、今後その辺の事も意識して結果を見る様にしてみます。

時の流れを感じますね。
F3Aは今ではほぼ電動です。

ヨーロッパの最終結果が出ました。
Final Classiffication (NEW)

日本の結果はこちら。
2022年度 F3A日本選手権 決勝

何人ものジャッジがそれぞれの目で見ているんですが、それが毎回僅差で同じ様な結果となるのが不思議なところでもあります。
特に、自分が関わったりすると、その絶妙な差に驚いたりします。
競技会はこの様な形で継続して行くかもしれませんが、そこに参加できない多くの人にとっては、機械の目が役に立つ存在になる事でしょう。

1995年のF3A世界選手権の写真を見て記憶が蘇りました。私は前年のプレ世界戦大会を遠路はるばる一泊三日の強行軍で見に行きました。
笠岡の場所の広大さ、また沢山の関係者と観客に非常に驚きました。選手たちのレンタカーはベンツ高級ワンボックスカー。日本の国力も頂点でしたが、日本国中からこの台数を集めたのかと驚きました。約28年前の懐かしい思い出です。

更新してV2.2.1Hになりました。
私のMacの場合、Chromeだと動いています。

決勝進出者10名とアンノウンパターン2つが発表されてます。
2022 FAI F3A EUROPEAN CHAMPIONSHIP
THOMASさんは14位で決勝には進めませんでした。
それにしてもアンノウンは難しいですね。
難しいパターンを2つ覚えて、それぞれ一発勝負ですから。

ーーーーーーーーーー
日本でも予選結果が発表になってました。
2022年度 F3A日本選手権 予選

ーーーーーーーーーーー
大会が重なっていたので余計に昔の事を思い出しました。
選手で参加した訳ではありませんが、色んな人の思いと力があって大会は開催されているのです。
日本では今後この様な事ができるでしょうか。
1995年F3A世界選手権の写真