TakJP様 再試行ありがとうございました。
soramon様 フライト全域で移動平均した結果を下図に示します。 これは１回移動平均操作をした結果で、前回の投稿でお示しした結果とほぼ同等です。ジャンプの入口でリボン図が折れ曲がっています。また、フライト全体を見ますと、全体的に飛行軌跡が滑らかとなっています。 次にこの図は全域での移動平均操作を２回実施した結果で、今度はリボン図の折れ曲がりは見られず滑らかなループになっています。全体を見ますと、更に飛行軌跡は滑らかとなっており、曲技の角は取れてＲのようになっています。例えば、トライアングルの三角形は角が取れてループのようになります。 これは、NED座標のNの時間変化を修正のあるなしで比較したもので、修正無しより１回目の修正、更に２回目の修正で角が取れて変化が滑らかになる様子が分かります。 以上の解析から、もしリボン図のジャンプを、JSONファイル上のNED座標値の移動平均で修正する場合は、修正はジャンプの前後に限る方が良いと思います。 以上、ご報告でした。
プロッターが更新されて、V2.2.0Hになりました。 私のMacの場合、Chromeだと動きますが、Safariではキャッシュを空にしても相変わらずダメでした。
飛行場で直ぐにフライトチェックできるのが良いですね。 周りの人も気にしてくれるかもしれません。
スマホやタブレットで再生するの、まるで意識していませんでした。 さっそく8000円で入手したBlackview tab6（カーナビ用に購入）で 試したらバッチリ動きました。アニメーションも味のある速度で動き バッチリです。飛行場にPCを持ち込むのが面倒と思っていたので 助かります(^^)
TakJP様 変換ありがとうございます。ジャンプ地点の前後のみではなくジャンプ位置を特定せずにフライト全域で移動平均するイメージでした。この場合、正常なリボン図も鈍るので滑らかさの妥協点を探すことになります （機速や旋回半径と関係ありそうです）。 当方もpythonをかじり始めましたが未だ辞書型って何？といったところで停滞中です。 ご無理を言って恐縮ですが全域移動平均のリボン図を試して頂けると嬉しいです。
また、TakJP様が以前仰っていたようにEKF_パラメータでフィルタの調整ができそうですが、カルマンフィルターの知識が無い上に翻訳機の問題なのかパラメータの意味と効果が良く分かりません。ジャンプの再現性もほぼ無いのでこちらは手がついていません。
トップビューを羅列してみます。 こうしてみると、何をしたら良いのかが分かってきますね。
soramon様 貴殿のご提案による単純移動平均を用いたJSONファイルの修正ができましたので、ご報告致します。下図に、修正前のリボントレースと単純移動平均による修正後のそれを示します。 以前のGPSの値を用いた修正の場合と比較して、ジャンプ前後の飛行軌跡は少し滑らかになりました。しかし、データの修正開始位置において飛行軌跡が折れ曲がっています。また、ジャンプの状況によって、データ修正の開始及び終了位置や単純移動平均するデータ数を適切に選ぶ必要があり、少し厄介です。今回、単純移動平均したデータ数は前後2秒（データ数50個）で、ジャンプ前の4秒からジャンプ後の2.8秒間を補正しています。 また、下図は修正したデータを示しており、縦軸はJSONファイルにおけるNED座標のN(m)です。黒線が修正する前で赤線が修正後の値を示しています。データ修正の入口のところで赤線が折れ曲がっており、リボントレースもこの位置で折れ曲がっています。 今後はカルマンフィルターによる補正なども考えてみたいと思います。以上、ご検討頂ければ幸いです。
全体的に綺麗にまとまっています。 トップビューやサイドビューからも、まとまりの良さが分かります。 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ケの操縦者位置と思います。同クラブのため代弁します。 因みに、私の飛行機位置は常にセンター右後方の木陰です。最悪の電波状況の所です。
ご協力に感謝いたします。 長文、失礼しました。
TakJP様
再試行ありがとうございました。
soramon様
フライト全域で移動平均した結果を下図に示します。
これは１回移動平均操作をした結果で、前回の投稿でお示しした結果とほぼ同等です。ジャンプの入口でリボン図が折れ曲がっています。また、フライト全体を見ますと、全体的に飛行軌跡が滑らかとなっています。
次にこの図は全域での移動平均操作を２回実施した結果で、今度はリボン図の折れ曲がりは見られず滑らかなループになっています。全体を見ますと、更に飛行軌跡は滑らかとなっており、曲技の角は取れてＲのようになっています。例えば、トライアングルの三角形は角が取れてループのようになります。
これは、NED座標のNの時間変化を修正のあるなしで比較したもので、修正無しより１回目の修正、更に２回目の修正で角が取れて変化が滑らかになる様子が分かります。
以上の解析から、もしリボン図のジャンプを、JSONファイル上のNED座標値の移動平均で修正する場合は、修正はジャンプの前後に限る方が良いと思います。
以上、ご報告でした。
プロッターが更新されて、V2.2.0Hになりました。
私のMacの場合、Chromeだと動きますが、Safariではキャッシュを空にしても相変わらずダメでした。
飛行場で直ぐにフライトチェックできるのが良いですね。
周りの人も気にしてくれるかもしれません。
スマホやタブレットで再生するの、まるで意識していませんでした。
さっそく8000円で入手したBlackview tab6（カーナビ用に購入）で
試したらバッチリ動きました。アニメーションも味のある速度で動き
バッチリです。飛行場にPCを持ち込むのが面倒と思っていたので
助かります(^^)
TakJP様
変換ありがとうございます。ジャンプ地点の前後のみではなくジャンプ位置を特定せずにフライト全域で移動平均するイメージでした。この場合、正常なリボン図も鈍るので滑らかさの妥協点を探すことになります
（機速や旋回半径と関係ありそうです）。
当方もpythonをかじり始めましたが未だ辞書型って何？といったところで停滞中です。
ご無理を言って恐縮ですが全域移動平均のリボン図を試して頂けると嬉しいです。
また、TakJP様が以前仰っていたようにEKF_パラメータでフィルタの調整ができそうですが、カルマンフィルターの知識が無い上に翻訳機の問題なのかパラメータの意味と効果が良く分かりません。ジャンプの再現性もほぼ無いのでこちらは手がついていません。
トップビューを羅列してみます。
こうしてみると、何をしたら良いのかが分かってきますね。
soramon様
貴殿のご提案による単純移動平均を用いたJSONファイルの修正ができましたので、ご報告致します。下図に、修正前のリボントレースと単純移動平均による修正後のそれを示します。
以前のGPSの値を用いた修正の場合と比較して、ジャンプ前後の飛行軌跡は少し滑らかになりました。しかし、データの修正開始位置において飛行軌跡が折れ曲がっています。また、ジャンプの状況によって、データ修正の開始及び終了位置や単純移動平均するデータ数を適切に選ぶ必要があり、少し厄介です。今回、単純移動平均したデータ数は前後2秒（データ数50個）で、ジャンプ前の4秒からジャンプ後の2.8秒間を補正しています。
また、下図は修正したデータを示しており、縦軸はJSONファイルにおけるNED座標のN(m)です。黒線が修正する前で赤線が修正後の値を示しています。データ修正の入口のところで赤線が折れ曲がっており、リボントレースもこの位置で折れ曲がっています。
今後はカルマンフィルターによる補正なども考えてみたいと思います。以上、ご検討頂ければ幸いです。
全体的に綺麗にまとまっています。
トップビューやサイドビューからも、まとまりの良さが分かります。
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ケの操縦者位置と思います。同クラブのため代弁します。
因みに、私の飛行機位置は常にセンター右後方の木陰です。最悪の電波状況の所です。
ご協力に感謝いたします。
長文、失礼しました。