全体的に綺麗にまとまっています。 トップビューやサイドビューからも、まとまりの良さが分かります。 45度上昇スナップの位置に注意ですね。
話は変わりますが、今、色々なトップビュー画像を集めているところで、近いうちにここに載せる予定です。 トップビューを見ると、どんな練習をしなくてはいけないかが良く分かります。
それと、Facebook関連ですが、韓国の人が「F3Aのオンライン大会」を開催したいと言っています。 演技は、AMAスポーツマン2022/23となっています。 初めての事なので反応があるかどうか。
8月21日のフライトです。
予選が始まりました。 まだ始まったばかりなので正式な順位ではないですが、22日の結果です。 Preliminary Results Monday 22nd August (NON OFFICIAL)
TakJP様 「POS（緑線）の当該値の前後1.1秒の移動平均値」です。どうやってもジャンプした個所から遡ってスムーズな軌跡が描けなかったのとGPS値を参考にしてしまうとbinファイルから手を付けることになるのでシンプルに考えました。ジャンプしてないように見えれば良い訳けですから。 ２０年ほど前にVB6でバイナリファイルを触ったことがある程度の素人ですが最近の言語を検索しているとLUAかPythonが出てくるのでardupilotでも使えそうなLUAを試そうかと思っていましたがお勧めはPythonですか、ちょっと考えなおしてみます。今後もアドバス頂けましたらうれしいです。
soramon様 ジャンプ前後の飛行軌跡の修正について、大変貴重なアイデアを頂きありがとうございました。貴殿がお考えの移動平均は、POS（緑線）の当該値の前後1.1秒の移動平均値と考えて宜しいでしょうか。単純移動平均及び加重移動平均を含めて検討してみます。 データの取り扱いについてですが、データ数が大変多いのでEXCEL等で取り扱うのは大変かもしれません。Plotterで作成されるJSONファイルはその名の通り、JSON形式で記述されたデータですのでPython等での取り扱いは比較的容易です。私はPythonでプログラムを組んでデータを一括編集しています。Pythonには様々な統計解析のライブラリーが充実していますので、データの解析も自分でプログラムを組む必要は無く、対応するモジュールをImportすれば良いので、大変楽に解析ができます。統計解析にはお勧めのプログラミング言語です。 解析の結果が出ましたら、また報告させて頂きますので、ご検討の程宜しくお願い致します。
Soramon様 とんでもありません。 ご質問ありがとうございました。
皆様 今回の機能追加の内容は表示後３日経過したため削除させていただきました。 本情報の推測からフライトコーチを改造された場合は自己責任となります。 ご了承をお願いいたします。
moon様 ご回答ありがとうございます。 ジャンプしまくる原因のヒントにならないかとピント外れの質問になってしまい申し訳ありませんでした。
TakJP様 スムージング処理をにわか検索して試しましたが思い描くラインになりません。身の丈を考えてEKFを尊重する案も無かったことにして単純移動平均で描いたのが以下のグラフです。赤点線が当初案、紫が単純移動平均です。平均時間は前後1.1秒（合計2.2秒)の移動平均にしています。実際には機速や旋回半径と滑らかさの妥協点を探すことになります。
フリーのEXCELもどきではLOGデータは重すぎて固まるのでLOGデータからGPSの経度データだけを抜き取りGPSデータを少しずらしてPOSデータとしていますので本物のデータではありませんがご容赦ください。
以前TakJP様からご教示いただいたJSONファイルのNED座標データをそれぞれ単純移動平均するだけでそれらしいリボン図になれば大変都合が良さそうです。 テストしようとEXCELもどきでJSONファイルを読ませたら改行マークが無いためか何もできません。 ファイル操作となると荷が重いのでテストは断念しています。
このトピックの最初の記事を少し手直ししました。 パソコン操作でプロッターの動きが説明通りにならなかった場合は、ブラウザのキャッシュをカラにしてから、もう一度再チャレンジしてみてください。
soramon様 ご指摘の通り、このままですとジャンプ位置でリボン図が折れ曲がりますね。何か良い方法はないでしょうか。
TakJP様 私の考えはTakJP様のグラフで示されたイメージの通りです。しかしグラフ化してみるとリボン図がパキッと折れ曲がりますね。漸近する方法に工夫が要りますね。
soramon様 早速コメントを頂き、ありがとうございました。また、JSONファイルの修正についてご共感頂き、ありがとうございます。ただし、私は「ジャンプはJSONファイルから修正できる」とは申し上げておりません。「JSONファイルから修正したい」という立場です。 さて、ご提案の修正方法についてですが、まだ良く理解できておりません。下図の赤い破線のように、ある変化率以下の直線あるいは曲線でPOSの位置情報（緑線）を近似すると言うことでしょうか。恐縮ですが、ご教授頂ければ幸いです。
難しい演技ですが、これも、トップビューでコースが「ヘの字形」に曲がっていないのが良いですね。
今日のフライトです。
TakJP様 わたしも昨日５フライトした中の１フライトにジャンプが発生しました。しかも３ヶ所も発生していました。 ということでジャンプ問題を真剣に考え始めたところですがTakJP様が兼ねてからご提案されているジャンプはJSONファイルから修正できるという考えには共感しておりました。
FlightCoachはスムーズな軌跡を描くため位置の連続性が重要ですがArdupilotにとっては位置の連続性は関係なく自動飛行のために現在の正確な位置こそが重要なはずです。 EKFの中身は全く理解していないので単なる妄想ですが、TakJP様やmoon様が調査されたように値が突然ジャンプすることがあることからこれまで積分などで得たPOSの位置情報よりGPSの位置情報の方が信頼できる判断し一気に修正することがあるのではないかと思います。 これは即ちEKFはジャンプ前までのGPSは信頼できないと判断していたことになります。 そこでジャンプを修正する場合は、POSのジャンプ後の値が正しい（EKFを尊重して）としてそこから過去に遡って(GPSは無視して)POSのラインと一致するまで変化率制限などを使い収束させるのは如何でしょうか。
Soramon様
分かりずらい文章で申し訳ございませんでした。 ご不明な点に対しては以下のとおりです。 今後も何なりとお問合せ願います。
Q:ARMING_REQUIREは変更(0⇒1)されたのでしょうか？ A:今回は変更はしていません。変更すると、SDカードへの書き込みが禁止されるので。 簡単な機能追加により、任意位置でのSD書込みが正常に開始するかを確認するためです。
Q:あるいはLOG_DISARMED=1にしてArmせずにログ記録しているのでしょうか？ A:ARMING_REQUIRE=0にしていますので自動的にArmします。従ってすぐにログ記録モードになります。しかし、今回の機能追加により、機能の操作によりカードに書き込みを開始していると思います。
Q:それとも他にArm中にOLEDの状態表示をさせる方法があるのでしょうか？ A:Arming_checkのボックスを指定すれば、OLEDに表示されます。例えば、Soramon様が言われた1054ではGPSの状況等が表示されます。他は早くて読めません。 前にもお伝えしましたが、私の状況では異常等のアラームは一切表示されません。 このため、Ａrmのみの表示を確認しています。
Q:FC起動数秒後に外部からSD書込み開始した場合、ログファイルは途中から書込まれるのですか、それともFCのバッファにある程度残っていてログファイルの先頭部のFMTやPARMなども記録されるのですか？ A: ログファイルは、スイッチによる動作を行った時点から書き込まれていると思います。 ログファイルの先頭部のFMTやPARMなども記録されています。GPS値、POS値を見ても、上記の情報は書き込まれているように見えます。 他のログ情報にも違和感は感じません。 FCのバッファにある程度残っていてログファイル、、これは私には良くわかりません。 どのようなファイルが残っているかは、不勉強で申し訳なしです。
moon様 以前投稿したようにARMING_REQUIRE=0だと起動後数秒でOLEDの表示が >>>ARMED!<<< となり状態を確認できないと思いますが ARMING_REQUIREは変更(0⇒1)されたのでしょうか？ この場合は自動ArmしませんがArmはどのような方法で行っているのですか。 あるいはLOG_DISARMED=1にしてArmせずにログ記録しているのでしょうか？ それとも他にArm中にOLEDの状態表示をさせる方法があるのでしょうか？ ご教示いただければありがたいです。
もう一つですが、FC起動数秒後に外部からSD書込み開始した場合、ログファイルは途中から書込まれるのですか、それともFCのバッファにある程度残っていてログファイルの先頭部のFMTやPARMなども記録されるのですか？
Soramon様、皆様
Soramon様のシステムを参考にして、自分なりにフライトコーチにマイクロSDカードへの書込み制御を追加しました。 どうせ作ってもと躊躇していたところにSoramon様の素晴らしい情報、奮起せざる得ませんでした。感謝申し上げます。
プロッタへの表示100%OKです。また、少ない誤差レベルで飛行機位置を取得しています。動作確認も済み目標機能に問題なく第一目標（次回は電子制御化）を達成しました。
使用方法は、F.Cのシステムが安定（LED点滅->点灯）を確認、GPS捕捉（LEDが点滅開始）の確認を行います。その後、任意の時間経過後（最低5秒程度）にスライドスイッチをＯＮします。この動作によりマイクロＳＤカードへのデータ書き込みを開始します。
今回は、機能確認用としメカ部品のみを使用した最小の部品構成としました。 取り付け後のフライトコーチの写真を添付します。
今回得られた各時点でのデータを添付します。 プロッタ上でのOrigin位置の高度とプロッタ表示の成功率を表したものです。 Denkado様の言われた、Origin位置の高度が高い場合にプロッタ表示ＮＧの傾向がある感じがする、、の検証も考慮しました。以前(ノーマル時)はプロッタ上への表示成功率は61％程度、Origin位置の高度は比較的高めです。 OLED追加後の表示成功率は100％、Origin位置高度は少し低下が見られますが高めです。 OLED+マイクロＳＤ書込み制御では、表示成功率は100％、Origin位置高度に大幅な低下が見られます。 また、Denkado様の感じたプロッタ表示ＮＧの傾向について、データからもOrigin位置の高度が関係しているように思えます。
フライトコーチ導入後は50m制限に縛られ最短コースでの離陸を迫られていました。 これからは通常の離陸コースを滑走して離陸できそうです。 ありがとうございました。
オリジンが50m以上離れているとリボン図が表示されないのですが、soramonさんが裏技を教えてくれました。 これで、これまでエラー表示で諦めていたフライトを見る事ができます。
TakJP様
最小二乗法から始まり、カルマンフィルタ、、各種近似法がありますが、私には難しく殆ど理解していません。 ドローンは各種センサーの組合せの最新技術、それを使用したフライトコーチ、利用できる私たちは恵まれています。 計算方法含め近似して予想するのは非常に難しく、まだ万全ではないのだと思います。 より良くなることを願うのみです。
今後とも、解析の方法等を提供を頂ければ助かります。頭の活性化、知識向上になります。 また、ハード面でのジャンプ対策があればご教示を頂ければと思います。
リカバリに十分対応できます、ありがとうございました。 ご教示の方法で（サイトをマニュアルとして再設定後、Copy Originを押し、Submitを押す）表示されました。 左に60度位ずれていますが、十分に見ることができます。 BINファイルの位置情報を書き換えましたが、いまだに表示NGは解消されないので助かりました。
なるほど。 やってみたら、見られなかったフライトが表示できました。 soramonさんありがとうございます。
moon様、soramon様 いろいろと貴重な情報ありがとうございます。 私がLOGファイルやJSONファイルの解析を始めたのは、Plotterによる飛行軌跡のジャンプを何とか修正したいと思ったからです。皆さんがご指摘のように、ジャンプがいつ何時発生するのか、今の段階では予測するのが非常に困難です。であるならば、ジャンプが起こるのを前提に、LOGファイルを解析してジャンプ前後のデータをなるべく正常な値に近づけ、その結果を基にJSONファイルを書き換えてジャンプを修正しようと考えました。しかし、LOGファイルを解析すればするほど、この試みが困難なことが分かってきました。Plotterによる飛行軌跡のジャンプは、moon様ご指摘の通り、予測値と実際値のズレが限界を超えたときに発生していると思われます。今は拡張カルマンフィルターによる予測方法を良く理解しないと先に進めない状況です。 私が思い違いをしているところ、あるいはこうした方が良いよ、と言うようなことがございましたらご教示頂ければ幸いです。
再び「オリジンが50m以上ずれていて見られない」件ですがFlight Plotterに「Copy Origin」の機能があるのでこれを使うとPilotとCenterがOrigin座標となりとりあえずリボンは表示されます。このままだとリボン図の方向がコースからひどく狂いますが、Centerを 通常Pilot位置から1000m以上前方に設定すれば離着陸位置はちょっと怪しいですがパターンの確認には何とか使えるようです。
沢山の貴重な情報ありがとうございます。 TakJP様が言われている通り、ジャンプの発生は、事象（主要因）によって予測計算値と実際値に乖離が始まり、 乖離が限界を超えた際に起きているように見えます。 今後とも、解析方法等のアドバイス頂ければ助かります。
TakJP様 お忙しいところ早々のご回答ありがとうございます。 緯度経度と思ってみていましたが、NED座標なるものがあること教えていただき大変勉強になりました。さらに先ほどのグラフが貴飛行場の前後左右方向に変換されていることを知り感服するばかりです。
soramon様 ご回答が遅れ、申し訳ございません。コメントがたくさんあり、ご質問を見逃しておりました。 さて、"time"はFlight Controllerが起動してからの経過時間で単位はマイクロ秒、JSONファイルで扱っている座標系はArduPilotで扱っている"NED"座標系です。"N"はNorth、"E"はEast、"D"はDownで、右手系です。高度"D"は下向きですので、通常はマイナスです。N,E,Dの単位は全て"m"です。原点は多分Originの位置です。ArduPilot & NED Frameで検索するとWEBサイトが沢山出てきますので、詳細はそちらを参照して下さい。 私の投稿しましたグラフのxyz座標系はPlotterで表示される座標系です。Pilot位置を原点とする座標系でy軸はPilotとCenterを結んだ線ですので、JSONのNED座標系を回転及び移動してxyz座標系に変換しています。 以上、ご回答になりましたでしょうか。
TakJP様、皆様 JSONファイルを開いてみたのですが数値が何を意味するのか分からずにいます。 {"time":215925738,"N":61.32136154174805,"E":26.48275375366211,"D":-10.169696807861328,・・・ ●"time":215925738 ってLOGファイルの TimeUSに対応しているの？ ●"N"＝North とすると数値(61.321・・)は何？、 ●"E"＝East とすると数値(26.482・・)は何？ ●"D":-10.169696807861328って何？ ・・・ など私には歯が立ちません。 ご存じであればご教示していただけるとありがたいです。
moon様 詳細なご検討を頂き、ありがとうございます。 私の場合も、Plotterではジャンプが表示されるのに、Mission Plannerで作成されたKMZファイルではジャンプが表示されない症状を経験致しました（Facebookに投稿済み）。不思議に思い、KMZファイルを解析しましたところ、KMZファイルに記載されている位置情報はLOGファイルのPOSの位置情報（JSONファイルの位置情報と同じ）と同じでした。ただし、Google Earthで表示されている位置情報はPOSの数分の一でした。つまり、Google Earthは記載の位置情報を間引いて表示していることになります。ジャンプが表示されないのは、間引く際に何らかの補正を行っているためと思われます。なお、私のフライトでは、高度に関しては先の投稿グラフのz軸（高度）の変化のように、ジャンプ時以外でもGPSとPOSによる高度が異なる場合もあることから、POS-AltはBarometerの値を採用しているものと思っていました。 また、ジャンプが発生する10秒以上前からGPSの位置情報とPOSの位置情報がズレていることから、moon様ご指摘のように、ジャンプの発生にはGPSによる位置情報のエラーばかりではなく、IMUの姿勢情報も何らかの影響を及ぼしているのかもしれません。 もう少し詳細に検討する必要がありそうです。
誤記を訂正します。 POS-Alt（赤->緑線）は矢印以降から乖離が始まり、その後にGPS-Alt（緑→赤線）に近くなります。 失礼しました。
ジャンプに至る解析情報、ありがとうございます。 大変参考になります。
長文で申し訳ございません。 上の投稿、私のトライアングルの背面での抜け部分でのジャンプ現象について解析結果です。
ミッションプランナのLOG解析を私も利用しました。 解析結果を見ると、GPS-Alt（GPSによる高度値）とPOS-Alt（計算による高度値）の差の部分で生じています。（下段の上、下図を参照ください）
ジャンプしたフライトをGoogle Earth ProによるGPS航跡で見てもジャンプ現象は見られません。 TakJP様のご教示のように、プロッタ表示ではPOS-Altを使用していると思います。 POS-Alt等の計算は予測する計算方式、計算での予測が各種センサーからの実値と近似できない場合にジャンプが発生するように思えます。
LOG解析のコメント表示として、EKF3 IMU0 yaw aligned to GPS velocity が出ています。 「EKF3 IMU0ヨーをGPS速度に合わせた」は、拡張カルマンフィルタでのヨー軸の速度計算をGPSの速度に合わせたの意味と思います。 確かにジャンプする際に、このコメント以降はヨー軸の方向（正面の川の方向）にほぼ水平移動しています。
今回のジャンプの原因、45度降下から背面で抜ける際に予想外のヨー軸の動きを検知、予測値と合致できなかったのが原因かも知れません。 LOG解析での上記コメントはドローンの自動操縦での落下原因の一つ、WEB上に沢山の情報記載がありました。
下段はLOG解析結果です。 GPS-Alt（赤線）とPOS-Alt（緑線）を示します。 上図はジャンプした際のもの、下図は通常時のものです。
上図は、矢印部分がトライアングルでの背面抜け部分です。 POS-Alt（赤線）は矢印以降から乖離が始まり、その後にGPS-Alt（緑線）に近くなります。 乖離している期間は大きくヨー軸方向にジャンプしています。
下図は、通常時の上図と同演技のものです。 演技中はGPS-AltとPOS-Altはほぼ一致しています。 最終演技終了後の水平飛行時にGPS高度とPOS高度が乖離していますが、 コメント表示はありません。プロッタ上にもジャンプ現象は見られません。
大変失礼しました。 Soramon様と思いましたが、万一を考え敢えて先程の宛先にしました。
度々のアドバイスありがとうございます。 Originから50m越えプロッタ表示がNGは、最も困った問題です。 Soramon様はこの悩みを解消されているようで羨ましい限りです。 飛行場の飛行機位置は、後方に沢山の比較的高い木があります。 したがって、後方のGPS電波状況はお世辞にも良いとは言えません。
お問い合わせの、フライトコーチのプロッタにフライト結果を表示するのに三つの条件があるようです。
1) Origin位置は、パイロット位置（操縦者位置、三角形のホームベース位置）から50m以内の GPSの捕捉値を使用し、それ以降のデータをSDカードに記憶する。 2) 飛行機はOrigin位置（GPS初期捕捉値）から50m以内で、高度10mを確保することがMUST。 3) 飛行機は操縦者位置から50m以内の水平なところに置く必要がある。
上記の条件を守れない場合、プロッタ上ではBINファイル読み込み後に「Origin位置から50m越えた」とテロップが出ます。その際のOrigin位置は0.00xx,0.0,0.0で表示されます。 これが表示されるとプロッタに航跡表示は不可能です。
上記条件が設定されていますので、実質的に無理が生じます。 GPS捕捉は３Ｄ値です。平面ばかりでなく縦方向の距離も含みます。Origin位置捕捉後、飛行機位置までのGPS捕捉データ（跡）が上空から渦をまいて降りて来る場合があります。
直線では10m程度でも渦を巻いた捕捉跡等では50m近くになる場合もあります。これは、実際にGoogle Earth proでのGPS情報（航跡）を見ると様々な動きが見られます。 最悪は、操縦者位置から最も遠い50m位置をOrigin位置と認識した場合、操縦者位置に飛行機を置いたとしても飛行機を1m動かしただけで合計51mの距離となりNGです。
また、GPS初期捕捉後も暫くはGPS位置が安定しないでフラフラしている場面もあります。 例えば、ミッションプランナーのGPS位置表示において、家二軒分の数十m程度移動することもあります。ですので、Origin位置が操縦者位置のすぐ近くとしても、なにもしない（飛行機の移動を伴わず）状況でも50mを越す場面も出てしまうことも予想されます。
以上により、飛行機位置でのGPS捕捉開始をしたい、、、これが希望です。 上記の３条件を守りながら、飛行機位置をOriginとして利用できればと考えています。
追記、 飛行場でのGPS捕捉数は最低でも9ケ位です。 OLEDのGPS 3D、Status 9との表示を確認しました。 Denkado様の飛行機位置は衛星10ケの操縦者位置と思います。同クラブのため代弁します。 因みに、私の飛行機位置は常にセンター右後方の木陰です。最悪の電波状況の所です。
ご協力に感謝いたします。 長文、失礼しました。
私の場合、オリジンのズレを確認するため電源ONはパイロット位置にしています。 50mオーバーのエラーについては、その時のオリジンの座標を見ると、高度が違っている場合もありますね。 飛行可能の判断については、GPSモジュールのLED点滅だけが頼りです。
Plotterで使用されている座標系を用いて、Mission Plannerで作成されたLOGファイル上の、GPSの位置情報、およびPOSの位置情報並びにFlight Coachで作成されるJSONファイルの位置情報を比較したグラフを添付致します。 グラフの横軸はFlight Controllerが起動してからの経過時間、x軸はPlotter座標の右手方向、y軸は奥手方向、z軸は高さ方向で、原点はPilotの位置です(右手系)。図中のGPSはLOGファイルのGPS、MPはLOGファイルのPOS、FCはJSONファイルを示しています。なおグラフにおいて、MPとFCの値は重なっていますので、MPの値（赤線）は表示されていません。このことから、Flight Coachはその位置情報にLOGファイルのPOSの値を用いているものと思われます。 グラフを見ますと、ジャンプが発生する約30秒ほど前からGPSの値とMP及びFCの値はズレてきており、ジャンプによってそのズレが解消されているように見えます（高さ方向はその後も少しズレていますが）。私のフライトデータでは、他のジャンプの際も同じような傾向です。ジャンプ前のいつ頃からズレ始めるかは、それぞれのジャンプによって異なり、私のフライトでは大体10～30秒前からズレ始めています。GPSの信号は0.2秒毎に受信されていますので、かなりの回数GPSのデータとMP及びFCの値がズレていることになります。 以上の考察によれば、GPSのデータとPOS及びJSONファイルのデータがかなりの期間ズレていることから、Mission PlannerがGPSのエラーをどのように補正しているのか、そのアルゴリズムが分からないと、LOGファイル並びにJSONファイルを用いてジャンプエラーを修正するのはかなり難しいと思われます。
先ほどはハンドルネームを入れ忘れました。 さて５０ｍ問題ですが、denkadou様のログ(P23_388.bin)を参考にして推察してみました。 Flight Plotterはログファイル(.bin)のORIGNを基準にして５０ｍ判断を行っていると思います。 いつORIGNが確定するのか情報を持ち合わせませんがログから推察するにAHRS_GPS_MINSATS=5である衛星数(NStas)が５になった直後当たりでORIGNが記録されています。 もうしばらくログのGPS項目を見ていくと時間経過とともに衛星数が増え位置や高度も移動していき衛星数１０個当たりで安定しているようです。これをMAPで示すと図のようになります。つまり実際の機体位置とORIGIN位置がずれていると思われます。（denkadou様 実際の機体の位置はどの辺だったのでしょうか？）
このログでは１５ｍのずれなので５０ｍ問題は発生していませんが、ORIGN確定時の位置精度がもっと悪いときに問題が発生するのではないでしょうか？ ORIGN確定とAHRS_GPS_MINSATSが関連していればAHRS_GPS_MINSATS=10程度にすれば解決するかもしれません。しかし状況にもよりますが衛星１０個補足までは結構時間がかかります。上の例では169秒かかっています。問題は「いつ飛行可能となったのかが分かるか？」 です。 私の場合起動後数秒でARMのブザーがなりLEDも連続点灯となるだけで数分後の飛行可能の判断がつきませんでした。 飛行可能な判断のためにPrearmチェックを有効にしたかったのですがARMING_REQUIRE=1にしないとうまくいきませんでした。そのためSBUSなど変な細工が必要になりました。 皆さんは飛行可能の判断をどうされていますか？
本日は晴れ間が少なく、昨日同様に上空全体に高い雲、湿気は60%オーバーと思います。
飛行場、昨日同様に一人ぼっちです。本日も８フライト、所要時間１時間半です。 昨日同様にプロッタ上で全フライトが見られました。今日は少しのジャンプも無しです。 OLED設置直前までワーストでは50%程度から最低1回は必ず50m飛びでNG、 全フライトを見たことの記憶すらありません。
不思議です、このままの状態で、50m飛びがいつ発生するか確認予定です。
物理的に変えたのはF.C上にOLEDを乗せて動作させたこと、ミッシュンプランナーでOLEDのArming関連を設定したことのみ。これらの変更は関係はしないと思いますが。ただし、天気等の環境は異なります。
上の投稿者様
アドバイス感謝いたします。 今の設定は、ARMING_REQUIRE=0です、ご指摘のとおり、イニシャライズ後にArmedに即座になります。 家での初期動作チェックにおいて、ARMING_CHECK欄のボックスにチェックを入れて有効にしましたが、特にエラー発生もなく変化を感じないので、今は初期確認用としてデフォルトの無効にしています。 チェックを入れての確認は、今後となりますが飛行場でしてみたいと思います。
moon様 ARMING_REQUIRE=0だとイニシャライズ後問答無用でArmedになるようです。 せめてARMING_CHECKが有効であればよいのですが私の設定が悪いのでしょうか？ またArm中はOLEDの表示が>>>ARMED!<<<となり何も確認できないと思います。
エラーは大別して2つの種類があります。 １つは、オリジンが50m以上離れていると表示され、リボン図が全く再現されないもの。 もう１つは、リボン図が再生されても途中でジャンプしてしまうものです。
前者の原因はGPSの誤差や狂いから来るものでしょう。 普段のリボン図の結果を見ていても、オリジンが実際の位置と離れている事が良くあります。 この事から、「パイロット位置」や「センター位置」の座標はGoogle MapやGoogle Earthで調べた方が良い事になります。 後者のジャンプは機体が垂直姿勢になったときに良く見られるので、GPSやコンパスが働き難いときに誤差修正が入るのでしょう。 これについては他のトピックで取り上げられているところです。
Solamon様、皆様
良いものを教えて頂き感謝申し上げます。 ご教示頂いたOLEDを動作設定し、OLEDのみの動作確認のため 8回フライトしました。 次回は、目的のSDカード書込みの任意化を外部スイッチを使用して行う予定です。
本日、各フライト全てF.Cへの電源投入後５秒以下でInitialize->Armed！でした。 あまりに早くArmed！となるので表示内容を読むのが大変でした。
本日は晴れ間はなく上空全体に高い雲があります、湿気は60%オーバーと思います。 OLED表示にAHRS not healthy等はありませんでした。 なんと、今日は珍しく50m越えによるプロッタ表示NGが一回もありませんでした。 全フライトでプロッタ表示が見られるのは数か月ぶりです。
しかし、８回フライトにおいて６回目のフライト中に大きなジャンプ現象が一回ありました。 トライアングルの終わりの45度降下から背面で抜けた時に飛行機が後退、その後、川の上に大きくジャンプしました。今まで経験がありません。写真を添付します。 両フライト、正面距離100m前後を飛ばしています。 考えられるハード面でのジャンプ対策も実施していますが、なにかが足りないようです。 （上図：大きくジャンプ、下図：通常）
2022/08/10の「続く‥ 」 より
ここからが飛行場へ行っての話になります。 初めての場所や、コールド・スタート（その日の最初のフライト）ではGPSロックに時間がかかり、中には20分ほど必要なものもあります。
・マイクロSDカードをセットして
・パイロット位置から50m以内の任意の場所で電源を入れます。 （その位置がオリジンとなります。GPS電波障害を避けるため車やテント、崖などから離れて）
・数分待ってロック合図のLED点滅開始を確認してからフライトします。
・プロッタにリボン図が描かれる条件の１つとして、F3A飛行の場合は10m以上の高度が必要です。
・着陸後は、「電源を切ってから」カードを抜き、パソコンに挿し替えます。
・ブックマークしておいたプロッターで目的のBINファイルを開きます。（屋外のオフラインでもキャッシュで動きます） データに関する注意画面が出る事がありますが、OKを押して進みます。
選択画面(Schedule and Site Selection)のSchedule欄では「F3A FAI」の中の「P25」や「F25」、あるいはスポーツマン等の場合は「F3A FAI」の中の「Generic」を選びます。「F3A FAI」を選ぶことによって、リボン図を再生する時の背景がパターン面となります。
パターンフライトの場合、BINファイルを開く時は必ず「F3A FAI」の中の演技を選ぶ様にします。 「IMAC」の中から選んでしまうと、F3Aのパターン面になりません。
・選択画面下のSelect Site欄では飛行場の場所を指定します。 飛行場を登録してあると、自動的に入力されていたり、あるいは、選択して呼び出す事ができます。
未登録の場所の場合は「manual」とし、このタイミングでメモしておいた「パイロット位置」と「センター位置」の座標を手動で入力します。
とりあえずデータの成否を確認するだけなら、コメント41の方法も有ります。
慣れて来たら、Mapページにあるボタンからカスタムサイトを作って、「.f3a」ファイルをP.Cに保存しておくと、F3AZoneボタンを使っての座標入力が簡単になります。 方法は、「manual」にしたときにF3AZoneボタンが現れるので、それを押して「.f3a」ファイルを選択するだけで、座標の数値が入力されます。 これらは一度入力すると、次からはキャッシュによって自動で再現されます。 （別の飛行場に行った場合やキャッシュクリアした時は、また座標入力が必要）
・入力後、下にスクロールしてSubmitを押すと、3Dリボン図が出てきます。
ーーーーーーーーーーーーーーーー 以上が、3Dリボン図を再現するまでの手順です。
もしプロッターの動きが悪くなった場合は、一旦ブラウザのキャッシュをカラにしてから再チャレンジしてみてください。
それと、使用上の注意点ですが、フライトコーチのデータロギングは100%成功する訳ではありません。 エラーの原因は、機体によるものから、地形、GPS電波など色々考えられます。 高度の低いGPS衛星もあるので、電源ONは車から離れた場所で行います。 衛星チェックアプリを使えばGPSの電波状態を確認できますが、グラフは絶えず変化しているので、普段の状態を経験しておく必要があります。
自分達にできる対策の１つは「電源を入れて待つ」事です。
待機時間が短かった事例。関連記事→コメント76 ユニットによっては、コールドスタートや再フライトでのGPSロックに10~20分かかるものもあります。 その場合は、マイクロSDカードを入れずにフライト開始のかなり前から通電しておき、飛行する時に電源を入れ直してその時にカードをセットする様にすると良いかもしれません。 ここで一番大事なのは「GPSのLED点滅の確認」で、コントローラーのLEDではありません。
リボン図が現れたらそれがゴールではありません。 続いてコメント34にある様に「リボンの区切りを修正」する必要があります。 これを、演技を見直す時の習慣にすると良いでしょう。
JUN TAUEさんが解説動画を作ってくれました。
全体的に綺麗にまとまっています。
トップビューやサイドビューからも、まとまりの良さが分かります。
45度上昇スナップの位置に注意ですね。
話は変わりますが、今、色々なトップビュー画像を集めているところで、近いうちにここに載せる予定です。
トップビューを見ると、どんな練習をしなくてはいけないかが良く分かります。
それと、Facebook関連ですが、韓国の人が「F3Aのオンライン大会」を開催したいと言っています。
演技は、AMAスポーツマン2022/23となっています。
初めての事なので反応があるかどうか。
8月21日のフライトです。
予選が始まりました。
まだ始まったばかりなので正式な順位ではないですが、22日の結果です。
Preliminary Results Monday 22nd August (NON OFFICIAL)
TakJP様
「POS（緑線）の当該値の前後1.1秒の移動平均値」です。どうやってもジャンプした個所から遡ってスムーズな軌跡が描けなかったのとGPS値を参考にしてしまうとbinファイルから手を付けることになるのでシンプルに考えました。ジャンプしてないように見えれば良い訳けですから。
２０年ほど前にVB6でバイナリファイルを触ったことがある程度の素人ですが最近の言語を検索しているとLUAかPythonが出てくるのでardupilotでも使えそうなLUAを試そうかと思っていましたがお勧めはPythonですか、ちょっと考えなおしてみます。今後もアドバス頂けましたらうれしいです。
soramon様
ジャンプ前後の飛行軌跡の修正について、大変貴重なアイデアを頂きありがとうございました。貴殿がお考えの移動平均は、POS（緑線）の当該値の前後1.1秒の移動平均値と考えて宜しいでしょうか。単純移動平均及び加重移動平均を含めて検討してみます。
データの取り扱いについてですが、データ数が大変多いのでEXCEL等で取り扱うのは大変かもしれません。Plotterで作成されるJSONファイルはその名の通り、JSON形式で記述されたデータですのでPython等での取り扱いは比較的容易です。私はPythonでプログラムを組んでデータを一括編集しています。Pythonには様々な統計解析のライブラリーが充実していますので、データの解析も自分でプログラムを組む必要は無く、対応するモジュールをImportすれば良いので、大変楽に解析ができます。統計解析にはお勧めのプログラミング言語です。
解析の結果が出ましたら、また報告させて頂きますので、ご検討の程宜しくお願い致します。
Soramon様
とんでもありません。
ご質問ありがとうございました。
皆様
今回の機能追加の内容は表示後３日経過したため削除させていただきました。
本情報の推測からフライトコーチを改造された場合は自己責任となります。
ご了承をお願いいたします。
moon様
ご回答ありがとうございます。
ジャンプしまくる原因のヒントにならないかとピント外れの質問になってしまい申し訳ありませんでした。
TakJP様
スムージング処理をにわか検索して試しましたが思い描くラインになりません。身の丈を考えてEKFを尊重する案も無かったことにして単純移動平均で描いたのが以下のグラフです。赤点線が当初案、紫が単純移動平均です。平均時間は前後1.1秒（合計2.2秒)の移動平均にしています。実際には機速や旋回半径と滑らかさの妥協点を探すことになります。
フリーのEXCELもどきではLOGデータは重すぎて固まるのでLOGデータからGPSの経度データだけを抜き取りGPSデータを少しずらしてPOSデータとしていますので本物のデータではありませんがご容赦ください。
以前TakJP様からご教示いただいたJSONファイルのNED座標データをそれぞれ単純移動平均するだけでそれらしいリボン図になれば大変都合が良さそうです。
テストしようとEXCELもどきでJSONファイルを読ませたら改行マークが無いためか何もできません。
ファイル操作となると荷が重いのでテストは断念しています。
このトピックの最初の記事を少し手直ししました。
パソコン操作でプロッターの動きが説明通りにならなかった場合は、ブラウザのキャッシュをカラにしてから、もう一度再チャレンジしてみてください。
soramon様
ご指摘の通り、このままですとジャンプ位置でリボン図が折れ曲がりますね。何か良い方法はないでしょうか。
TakJP様
私の考えはTakJP様のグラフで示されたイメージの通りです。しかしグラフ化してみるとリボン図がパキッと折れ曲がりますね。漸近する方法に工夫が要りますね。
soramon様
早速コメントを頂き、ありがとうございました。また、JSONファイルの修正についてご共感頂き、ありがとうございます。ただし、私は「ジャンプはJSONファイルから修正できる」とは申し上げておりません。「JSONファイルから修正したい」という立場です。
さて、ご提案の修正方法についてですが、まだ良く理解できておりません。下図の赤い破線のように、ある変化率以下の直線あるいは曲線でPOSの位置情報（緑線）を近似すると言うことでしょうか。恐縮ですが、ご教授頂ければ幸いです。
難しい演技ですが、これも、トップビューでコースが「ヘの字形」に曲がっていないのが良いですね。
今日のフライトです。
TakJP様
わたしも昨日５フライトした中の１フライトにジャンプが発生しました。しかも３ヶ所も発生していました。
ということでジャンプ問題を真剣に考え始めたところですがTakJP様が兼ねてからご提案されているジャンプはJSONファイルから修正できるという考えには共感しておりました。
FlightCoachはスムーズな軌跡を描くため位置の連続性が重要ですがArdupilotにとっては位置の連続性は関係なく自動飛行のために現在の正確な位置こそが重要なはずです。
EKFの中身は全く理解していないので単なる妄想ですが、TakJP様やmoon様が調査されたように値が突然ジャンプすることがあることからこれまで積分などで得たPOSの位置情報よりGPSの位置情報の方が信頼できる判断し一気に修正することがあるのではないかと思います。
これは即ちEKFはジャンプ前までのGPSは信頼できないと判断していたことになります。
そこでジャンプを修正する場合は、POSのジャンプ後の値が正しい（EKFを尊重して）としてそこから過去に遡って(GPSは無視して)POSのラインと一致するまで変化率制限などを使い収束させるのは如何でしょうか。
Soramon様
分かりずらい文章で申し訳ございませんでした。
ご不明な点に対しては以下のとおりです。
今後も何なりとお問合せ願います。
Q:ARMING_REQUIREは変更(0⇒1)されたのでしょうか？
A:今回は変更はしていません。変更すると、SDカードへの書き込みが禁止されるので。
簡単な機能追加により、任意位置でのSD書込みが正常に開始するかを確認するためです。
Q:あるいはLOG_DISARMED=1にしてArmせずにログ記録しているのでしょうか？
A:ARMING_REQUIRE=0にしていますので自動的にArmします。従ってすぐにログ記録モードになります。しかし、今回の機能追加により、機能の操作によりカードに書き込みを開始していると思います。
Q:それとも他にArm中にOLEDの状態表示をさせる方法があるのでしょうか？
A:Arming_checkのボックスを指定すれば、OLEDに表示されます。例えば、Soramon様が言われた1054ではGPSの状況等が表示されます。他は早くて読めません。
前にもお伝えしましたが、私の状況では異常等のアラームは一切表示されません。
このため、Ａrmのみの表示を確認しています。
Q:FC起動数秒後に外部からSD書込み開始した場合、ログファイルは途中から書込まれるのですか、それともFCのバッファにある程度残っていてログファイルの先頭部のFMTやPARMなども記録されるのですか？
A: ログファイルは、スイッチによる動作を行った時点から書き込まれていると思います。
ログファイルの先頭部のFMTやPARMなども記録されています。GPS値、POS値を見ても、上記の情報は書き込まれているように見えます。
他のログ情報にも違和感は感じません。
FCのバッファにある程度残っていてログファイル、、これは私には良くわかりません。
どのようなファイルが残っているかは、不勉強で申し訳なしです。
moon様
以前投稿したようにARMING_REQUIRE=0だと起動後数秒でOLEDの表示が
>>>ARMED!<<< となり状態を確認できないと思いますが
ARMING_REQUIREは変更(0⇒1)されたのでしょうか？
この場合は自動ArmしませんがArmはどのような方法で行っているのですか。
あるいはLOG_DISARMED=1にしてArmせずにログ記録しているのでしょうか？
それとも他にArm中にOLEDの状態表示をさせる方法があるのでしょうか？
ご教示いただければありがたいです。
もう一つですが、FC起動数秒後に外部からSD書込み開始した場合、ログファイルは途中から書込まれるのですか、それともFCのバッファにある程度残っていてログファイルの先頭部のFMTやPARMなども記録されるのですか？
Soramon様、皆様
Soramon様のシステムを参考にして、自分なりにフライトコーチにマイクロSDカードへの書込み制御を追加しました。
どうせ作ってもと躊躇していたところにSoramon様の素晴らしい情報、奮起せざる得ませんでした。感謝申し上げます。
プロッタへの表示100%OKです。また、少ない誤差レベルで飛行機位置を取得しています。動作確認も済み目標機能に問題なく第一目標（次回は電子制御化）を達成しました。
使用方法は、F.Cのシステムが安定（LED点滅->点灯）を確認、GPS捕捉（LEDが点滅開始）の確認を行います。その後、任意の時間経過後（最低5秒程度）にスライドスイッチをＯＮします。この動作によりマイクロＳＤカードへのデータ書き込みを開始します。
今回は、機能確認用としメカ部品のみを使用した最小の部品構成としました。
取り付け後のフライトコーチの写真を添付します。
今回得られた各時点でのデータを添付します。
プロッタ上でのOrigin位置の高度とプロッタ表示の成功率を表したものです。
Denkado様の言われた、Origin位置の高度が高い場合にプロッタ表示ＮＧの傾向がある感じがする、、の検証も考慮しました。以前(ノーマル時)はプロッタ上への表示成功率は61％程度、Origin位置の高度は比較的高めです。
OLED追加後の表示成功率は100％、Origin位置高度は少し低下が見られますが高めです。
OLED+マイクロＳＤ書込み制御では、表示成功率は100％、Origin位置高度に大幅な低下が見られます。
また、Denkado様の感じたプロッタ表示ＮＧの傾向について、データからもOrigin位置の高度が関係しているように思えます。
フライトコーチ導入後は50m制限に縛られ最短コースでの離陸を迫られていました。
これからは通常の離陸コースを滑走して離陸できそうです。
ありがとうございました。
オリジンが50m以上離れているとリボン図が表示されないのですが、soramonさんが裏技を教えてくれました。
これで、これまでエラー表示で諦めていたフライトを見る事ができます。
TakJP様
最小二乗法から始まり、カルマンフィルタ、、各種近似法がありますが、私には難しく殆ど理解していません。
ドローンは各種センサーの組合せの最新技術、それを使用したフライトコーチ、利用できる私たちは恵まれています。
計算方法含め近似して予想するのは非常に難しく、まだ万全ではないのだと思います。
より良くなることを願うのみです。
今後とも、解析の方法等を提供を頂ければ助かります。頭の活性化、知識向上になります。
また、ハード面でのジャンプ対策があればご教示を頂ければと思います。
Soramon様
リカバリに十分対応できます、ありがとうございました。
ご教示の方法で（サイトをマニュアルとして再設定後、Copy Originを押し、Submitを押す）表示されました。
左に60度位ずれていますが、十分に見ることができます。
BINファイルの位置情報を書き換えましたが、いまだに表示NGは解消されないので助かりました。
なるほど。
やってみたら、見られなかったフライトが表示できました。
soramonさんありがとうございます。
moon様、soramon様
いろいろと貴重な情報ありがとうございます。
私がLOGファイルやJSONファイルの解析を始めたのは、Plotterによる飛行軌跡のジャンプを何とか修正したいと思ったからです。皆さんがご指摘のように、ジャンプがいつ何時発生するのか、今の段階では予測するのが非常に困難です。であるならば、ジャンプが起こるのを前提に、LOGファイルを解析してジャンプ前後のデータをなるべく正常な値に近づけ、その結果を基にJSONファイルを書き換えてジャンプを修正しようと考えました。しかし、LOGファイルを解析すればするほど、この試みが困難なことが分かってきました。Plotterによる飛行軌跡のジャンプは、moon様ご指摘の通り、予測値と実際値のズレが限界を超えたときに発生していると思われます。今は拡張カルマンフィルターによる予測方法を良く理解しないと先に進めない状況です。
私が思い違いをしているところ、あるいはこうした方が良いよ、と言うようなことがございましたらご教示頂ければ幸いです。
再び「オリジンが50m以上ずれていて見られない」件ですがFlight Plotterに「Copy Origin」の機能があるのでこれを使うとPilotとCenterがOrigin座標となりとりあえずリボンは表示されます。このままだとリボン図の方向がコースからひどく狂いますが、Centerを
通常Pilot位置から1000m以上前方に設定すれば離着陸位置はちょっと怪しいですがパターンの確認には何とか使えるようです。
TakJP様
沢山の貴重な情報ありがとうございます。
TakJP様が言われている通り、ジャンプの発生は、事象（主要因）によって予測計算値と実際値に乖離が始まり、
乖離が限界を超えた際に起きているように見えます。
今後とも、解析方法等のアドバイス頂ければ助かります。
TakJP様
お忙しいところ早々のご回答ありがとうございます。
緯度経度と思ってみていましたが、NED座標なるものがあること教えていただき大変勉強になりました。さらに先ほどのグラフが貴飛行場の前後左右方向に変換されていることを知り感服するばかりです。
soramon様
ご回答が遅れ、申し訳ございません。コメントがたくさんあり、ご質問を見逃しておりました。
さて、"time"はFlight Controllerが起動してからの経過時間で単位はマイクロ秒、JSONファイルで扱っている座標系はArduPilotで扱っている"NED"座標系です。"N"はNorth、"E"はEast、"D"はDownで、右手系です。高度"D"は下向きですので、通常はマイナスです。N,E,Dの単位は全て"m"です。原点は多分Originの位置です。ArduPilot & NED Frameで検索するとWEBサイトが沢山出てきますので、詳細はそちらを参照して下さい。
私の投稿しましたグラフのxyz座標系はPlotterで表示される座標系です。Pilot位置を原点とする座標系でy軸はPilotとCenterを結んだ線ですので、JSONのNED座標系を回転及び移動してxyz座標系に変換しています。
以上、ご回答になりましたでしょうか。
TakJP様、皆様
JSONファイルを開いてみたのですが数値が何を意味するのか分からずにいます。
{"time":215925738,"N":61.32136154174805,"E":26.48275375366211,"D":-10.169696807861328,・・・
●"time":215925738 ってLOGファイルの TimeUSに対応しているの？
●"N"＝North とすると数値(61.321・・)は何？、
●"E"＝East とすると数値(26.482・・)は何？
●"D":-10.169696807861328って何？ ・・・
など私には歯が立ちません。
ご存じであればご教示していただけるとありがたいです。
moon様
詳細なご検討を頂き、ありがとうございます。
私の場合も、Plotterではジャンプが表示されるのに、Mission Plannerで作成されたKMZファイルではジャンプが表示されない症状を経験致しました（Facebookに投稿済み）。不思議に思い、KMZファイルを解析しましたところ、KMZファイルに記載されている位置情報はLOGファイルのPOSの位置情報（JSONファイルの位置情報と同じ）と同じでした。ただし、Google Earthで表示されている位置情報はPOSの数分の一でした。つまり、Google Earthは記載の位置情報を間引いて表示していることになります。ジャンプが表示されないのは、間引く際に何らかの補正を行っているためと思われます。なお、私のフライトでは、高度に関しては先の投稿グラフのz軸（高度）の変化のように、ジャンプ時以外でもGPSとPOSによる高度が異なる場合もあることから、POS-AltはBarometerの値を採用しているものと思っていました。
また、ジャンプが発生する10秒以上前からGPSの位置情報とPOSの位置情報がズレていることから、moon様ご指摘のように、ジャンプの発生にはGPSによる位置情報のエラーばかりではなく、IMUの姿勢情報も何らかの影響を及ぼしているのかもしれません。
もう少し詳細に検討する必要がありそうです。
TakJP様
誤記を訂正します。
POS-Alt（赤->緑線）は矢印以降から乖離が始まり、その後にGPS-Alt（緑→赤線）に近くなります。
失礼しました。
TakJP様
ジャンプに至る解析情報、ありがとうございます。
大変参考になります。
長文で申し訳ございません。
上の投稿、私のトライアングルの背面での抜け部分でのジャンプ現象について解析結果です。
ミッションプランナのLOG解析を私も利用しました。
解析結果を見ると、GPS-Alt（GPSによる高度値）とPOS-Alt（計算による高度値）の差の部分で生じています。（下段の上、下図を参照ください）
ジャンプしたフライトをGoogle Earth ProによるGPS航跡で見てもジャンプ現象は見られません。
TakJP様のご教示のように、プロッタ表示ではPOS-Altを使用していると思います。
POS-Alt等の計算は予測する計算方式、計算での予測が各種センサーからの実値と近似できない場合にジャンプが発生するように思えます。
LOG解析のコメント表示として、EKF3 IMU0 yaw aligned to GPS velocity が出ています。
「EKF3 IMU0ヨーをGPS速度に合わせた」は、拡張カルマンフィルタでのヨー軸の速度計算をGPSの速度に合わせたの意味と思います。
確かにジャンプする際に、このコメント以降はヨー軸の方向（正面の川の方向）にほぼ水平移動しています。
今回のジャンプの原因、45度降下から背面で抜ける際に予想外のヨー軸の動きを検知、予測値と合致できなかったのが原因かも知れません。
LOG解析での上記コメントはドローンの自動操縦での落下原因の一つ、WEB上に沢山の情報記載がありました。
下段はLOG解析結果です。
GPS-Alt（赤線）とPOS-Alt（緑線）を示します。
上図はジャンプした際のもの、下図は通常時のものです。
上図は、矢印部分がトライアングルでの背面抜け部分です。
POS-Alt（赤線）は矢印以降から乖離が始まり、その後にGPS-Alt（緑線）に近くなります。
乖離している期間は大きくヨー軸方向にジャンプしています。
下図は、通常時の上図と同演技のものです。
演技中はGPS-AltとPOS-Altはほぼ一致しています。
最終演技終了後の水平飛行時にGPS高度とPOS高度が乖離していますが、
コメント表示はありません。プロッタ上にもジャンプ現象は見られません。
Soramon様
大変失礼しました。
Soramon様と思いましたが、万一を考え敢えて先程の宛先にしました。
度々のアドバイスありがとうございます。
Originから50m越えプロッタ表示がNGは、最も困った問題です。
Soramon様はこの悩みを解消されているようで羨ましい限りです。
飛行場の飛行機位置は、後方に沢山の比較的高い木があります。
したがって、後方のGPS電波状況はお世辞にも良いとは言えません。
お問い合わせの、フライトコーチのプロッタにフライト結果を表示するのに三つの条件があるようです。
1) Origin位置は、パイロット位置（操縦者位置、三角形のホームベース位置）から50m以内の
GPSの捕捉値を使用し、それ以降のデータをSDカードに記憶する。
2) 飛行機はOrigin位置（GPS初期捕捉値）から50m以内で、高度10mを確保することがMUST。
3) 飛行機は操縦者位置から50m以内の水平なところに置く必要がある。
上記の条件を守れない場合、プロッタ上ではBINファイル読み込み後に「Origin位置から50m越えた」とテロップが出ます。その際のOrigin位置は0.00xx,0.0,0.0で表示されます。
これが表示されるとプロッタに航跡表示は不可能です。
上記条件が設定されていますので、実質的に無理が生じます。
GPS捕捉は３Ｄ値です。平面ばかりでなく縦方向の距離も含みます。Origin位置捕捉後、飛行機位置までのGPS捕捉データ（跡）が上空から渦をまいて降りて来る場合があります。
直線では10m程度でも渦を巻いた捕捉跡等では50m近くになる場合もあります。これは、実際にGoogle Earth proでのGPS情報（航跡）を見ると様々な動きが見られます。
最悪は、操縦者位置から最も遠い50m位置をOrigin位置と認識した場合、操縦者位置に飛行機を置いたとしても飛行機を1m動かしただけで合計51mの距離となりNGです。
また、GPS初期捕捉後も暫くはGPS位置が安定しないでフラフラしている場面もあります。
例えば、ミッションプランナーのGPS位置表示において、家二軒分の数十m程度移動することもあります。ですので、Origin位置が操縦者位置のすぐ近くとしても、なにもしない（飛行機の移動を伴わず）状況でも50mを越す場面も出てしまうことも予想されます。
以上により、飛行機位置でのGPS捕捉開始をしたい、、、これが希望です。
上記の３条件を守りながら、飛行機位置をOriginとして利用できればと考えています。
追記、
飛行場でのGPS捕捉数は最低でも9ケ位です。
OLEDのGPS 3D、Status 9との表示を確認しました。
Denkado様の飛行機位置は衛星10ケの操縦者位置と思います。同クラブのため代弁します。
因みに、私の飛行機位置は常にセンター右後方の木陰です。最悪の電波状況の所です。
ご協力に感謝いたします。
長文、失礼しました。
私の場合、オリジンのズレを確認するため電源ONはパイロット位置にしています。
50mオーバーのエラーについては、その時のオリジンの座標を見ると、高度が違っている場合もありますね。
飛行可能の判断については、GPSモジュールのLED点滅だけが頼りです。
Plotterで使用されている座標系を用いて、Mission Plannerで作成されたLOGファイル上の、GPSの位置情報、およびPOSの位置情報並びにFlight Coachで作成されるJSONファイルの位置情報を比較したグラフを添付致します。
グラフの横軸はFlight Controllerが起動してからの経過時間、x軸はPlotter座標の右手方向、y軸は奥手方向、z軸は高さ方向で、原点はPilotの位置です(右手系)。図中のGPSはLOGファイルのGPS、MPはLOGファイルのPOS、FCはJSONファイルを示しています。なおグラフにおいて、MPとFCの値は重なっていますので、MPの値（赤線）は表示されていません。このことから、Flight Coachはその位置情報にLOGファイルのPOSの値を用いているものと思われます。
グラフを見ますと、ジャンプが発生する約30秒ほど前からGPSの値とMP及びFCの値はズレてきており、ジャンプによってそのズレが解消されているように見えます（高さ方向はその後も少しズレていますが）。私のフライトデータでは、他のジャンプの際も同じような傾向です。ジャンプ前のいつ頃からズレ始めるかは、それぞれのジャンプによって異なり、私のフライトでは大体10～30秒前からズレ始めています。GPSの信号は0.2秒毎に受信されていますので、かなりの回数GPSのデータとMP及びFCの値がズレていることになります。
以上の考察によれば、GPSのデータとPOS及びJSONファイルのデータがかなりの期間ズレていることから、Mission PlannerがGPSのエラーをどのように補正しているのか、そのアルゴリズムが分からないと、LOGファイル並びにJSONファイルを用いてジャンプエラーを修正するのはかなり難しいと思われます。
先ほどはハンドルネームを入れ忘れました。
さて５０ｍ問題ですが、denkadou様のログ(P23_388.bin)を参考にして推察してみました。
Flight Plotterはログファイル(.bin)のORIGNを基準にして５０ｍ判断を行っていると思います。
いつORIGNが確定するのか情報を持ち合わせませんがログから推察するにAHRS_GPS_MINSATS=5である衛星数(NStas)が５になった直後当たりでORIGNが記録されています。
もうしばらくログのGPS項目を見ていくと時間経過とともに衛星数が増え位置や高度も移動していき衛星数１０個当たりで安定しているようです。これをMAPで示すと図のようになります。つまり実際の機体位置とORIGIN位置がずれていると思われます。（denkadou様 実際の機体の位置はどの辺だったのでしょうか？）
このログでは１５ｍのずれなので５０ｍ問題は発生していませんが、ORIGN確定時の位置精度がもっと悪いときに問題が発生するのではないでしょうか？ ORIGN確定とAHRS_GPS_MINSATSが関連していればAHRS_GPS_MINSATS=10程度にすれば解決するかもしれません。しかし状況にもよりますが衛星１０個補足までは結構時間がかかります。上の例では169秒かかっています。問題は「いつ飛行可能となったのかが分かるか？」 です。
私の場合起動後数秒でARMのブザーがなりLEDも連続点灯となるだけで数分後の飛行可能の判断がつきませんでした。
飛行可能な判断のためにPrearmチェックを有効にしたかったのですがARMING_REQUIRE=1にしないとうまくいきませんでした。そのためSBUSなど変な細工が必要になりました。 皆さんは飛行可能の判断をどうされていますか？
本日は晴れ間が少なく、昨日同様に上空全体に高い雲、湿気は60%オーバーと思います。
飛行場、昨日同様に一人ぼっちです。本日も８フライト、所要時間１時間半です。
昨日同様にプロッタ上で全フライトが見られました。今日は少しのジャンプも無しです。
OLED設置直前までワーストでは50%程度から最低1回は必ず50m飛びでNG、
全フライトを見たことの記憶すらありません。
不思議です、このままの状態で、50m飛びがいつ発生するか確認予定です。
物理的に変えたのはF.C上にOLEDを乗せて動作させたこと、ミッシュンプランナーでOLEDのArming関連を設定したことのみ。これらの変更は関係はしないと思いますが。ただし、天気等の環境は異なります。
上の投稿者様
アドバイス感謝いたします。
今の設定は、ARMING_REQUIRE=0です、ご指摘のとおり、イニシャライズ後にArmedに即座になります。
家での初期動作チェックにおいて、ARMING_CHECK欄のボックスにチェックを入れて有効にしましたが、特にエラー発生もなく変化を感じないので、今は初期確認用としてデフォルトの無効にしています。
チェックを入れての確認は、今後となりますが飛行場でしてみたいと思います。
moon様
ARMING_REQUIRE=0だとイニシャライズ後問答無用でArmedになるようです。
せめてARMING_CHECKが有効であればよいのですが私の設定が悪いのでしょうか？
またArm中はOLEDの表示が>>>ARMED!<<<となり何も確認できないと思います。
エラーは大別して2つの種類があります。
１つは、オリジンが50m以上離れていると表示され、リボン図が全く再現されないもの。
もう１つは、リボン図が再生されても途中でジャンプしてしまうものです。
前者の原因はGPSの誤差や狂いから来るものでしょう。
普段のリボン図の結果を見ていても、オリジンが実際の位置と離れている事が良くあります。
この事から、「パイロット位置」や「センター位置」の座標はGoogle MapやGoogle Earthで調べた方が良い事になります。
後者のジャンプは機体が垂直姿勢になったときに良く見られるので、GPSやコンパスが働き難いときに誤差修正が入るのでしょう。
これについては他のトピックで取り上げられているところです。
Solamon様、皆様
良いものを教えて頂き感謝申し上げます。
ご教示頂いたOLEDを動作設定し、OLEDのみの動作確認のため 8回フライトしました。
次回は、目的のSDカード書込みの任意化を外部スイッチを使用して行う予定です。
本日、各フライト全てF.Cへの電源投入後５秒以下でInitialize->Armed！でした。
あまりに早くArmed！となるので表示内容を読むのが大変でした。
本日は晴れ間はなく上空全体に高い雲があります、湿気は60%オーバーと思います。
OLED表示にAHRS not healthy等はありませんでした。
なんと、今日は珍しく50m越えによるプロッタ表示NGが一回もありませんでした。
全フライトでプロッタ表示が見られるのは数か月ぶりです。
しかし、８回フライトにおいて６回目のフライト中に大きなジャンプ現象が一回ありました。
トライアングルの終わりの45度降下から背面で抜けた時に飛行機が後退、その後、川の上に大きくジャンプしました。今まで経験がありません。写真を添付します。
両フライト、正面距離100m前後を飛ばしています。
考えられるハード面でのジャンプ対策も実施していますが、なにかが足りないようです。
（上図：大きくジャンプ、下図：通常）
2022/08/10の「続く‥ 」 より
ここからが飛行場へ行っての話になります。
初めての場所や、コールド・スタート（その日の最初のフライト）ではGPSロックに時間がかかり、中には20分ほど必要なものもあります。
・マイクロSDカードをセットして
・パイロット位置から50m以内の任意の場所で電源を入れます。
（その位置がオリジンとなります。GPS電波障害を避けるため車やテント、崖などから離れて）
・数分待ってロック合図のLED点滅開始を確認してからフライトします。
・プロッタにリボン図が描かれる条件の１つとして、F3A飛行の場合は10m以上の高度が必要です。
・着陸後は、「電源を切ってから」カードを抜き、パソコンに挿し替えます。
・ブックマークしておいたプロッターで目的のBINファイルを開きます。（屋外のオフラインでもキャッシュで動きます）
データに関する注意画面が出る事がありますが、OKを押して進みます。
選択画面(Schedule and Site Selection)のSchedule欄では「F3A FAI」の中の「P25」や「F25」、あるいはスポーツマン等の場合は「F3A FAI」の中の「Generic」を選びます。「F3A FAI」を選ぶことによって、リボン図を再生する時の背景がパターン面となります。
パターンフライトの場合、BINファイルを開く時は必ず「F3A FAI」の中の演技を選ぶ様にします。
「IMAC」の中から選んでしまうと、F3Aのパターン面になりません。
・選択画面下のSelect Site欄では飛行場の場所を指定します。
飛行場を登録してあると、自動的に入力されていたり、あるいは、選択して呼び出す事ができます。
未登録の場所の場合は「manual」とし、このタイミングでメモしておいた「パイロット位置」と「センター位置」の座標を手動で入力します。
とりあえずデータの成否を確認するだけなら、コメント41の方法も有ります。
慣れて来たら、Mapページにあるボタンからカスタムサイトを作って、「.f3a」ファイルをP.Cに保存しておくと、F3AZoneボタンを使っての座標入力が簡単になります。
方法は、「manual」にしたときにF3AZoneボタンが現れるので、それを押して「.f3a」ファイルを選択するだけで、座標の数値が入力されます。
これらは一度入力すると、次からはキャッシュによって自動で再現されます。
（別の飛行場に行った場合やキャッシュクリアした時は、また座標入力が必要）
・入力後、下にスクロールしてSubmitを押すと、3Dリボン図が出てきます。
ーーーーーーーーーーーーーーーー
以上が、3Dリボン図を再現するまでの手順です。
もしプロッターの動きが悪くなった場合は、一旦ブラウザのキャッシュをカラにしてから再チャレンジしてみてください。
それと、使用上の注意点ですが、フライトコーチのデータロギングは100%成功する訳ではありません。
エラーの原因は、機体によるものから、地形、GPS電波など色々考えられます。
高度の低いGPS衛星もあるので、電源ONは車から離れた場所で行います。
衛星チェックアプリを使えばGPSの電波状態を確認できますが、グラフは絶えず変化しているので、普段の状態を経験しておく必要があります。
自分達にできる対策の１つは「電源を入れて待つ」事です。
待機時間が短かった事例。関連記事→コメント76
ユニットによっては、コールドスタートや再フライトでのGPSロックに10~20分かかるものもあります。
その場合は、マイクロSDカードを入れずにフライト開始のかなり前から通電しておき、飛行する時に電源を入れ直してその時にカードをセットする様にすると良いかもしれません。
ここで一番大事なのは「GPSのLED点滅の確認」で、コントローラーのLEDではありません。
リボン図が現れたらそれがゴールではありません。
続いてコメント34にある様に「リボンの区切りを修正」する必要があります。
これを、演技を見直す時の習慣にすると良いでしょう。
JUN TAUEさんが解説動画を作ってくれました。