iPhone８でのChromeです。V2.2.1Hに自動更新され、それ以降はNGです。 画面がストップしたまま、本当にどうしたんでしょうか。 対策版を待つしかないですね。
どうしたんでしょうね。 また、変化があったら知らせてください。
情報ありがとうございます。 iPhone８でのChromeはOKです。クラブ員のiPadは本日最初はOKでした。しかし、V2.2.0Hに自動更新され画面がストップしてそれ以降はNGです。その後にChromeをインストール、でも、結果はNGでした。全部見られることを期待ですね。
カルマンフィルタを通して導き出しているのですね、きっと。
仕組みの事は分からないので気にした事も無いですが、多分、GPSや気圧センサーも共に誤差があるので、それぞれを補いながら計算しているのではないでしょうか。
素朴な疑問です。速度計測はGPSを使って移動距離と時間から割り出していると 思っていましたが、垂直降下の時などはどのようにして計測されているのでしょう？ 高度は気圧センサーですか？
機能追加と言うことではないのですね。 ありがとうございます。
4ラウンド終了して、予選の結果が発表されました。 Final Preliminary (NEW)
次は上位20名で準決勝になります。
ーーーーーーーー それと、日本では今、2022年度 F3A曲技日本選手権（８月24日～28日）が開催されてます。 結果は日本模型航空連盟のサイトで発表されます。
最初β版として発表したものが、V2.2.0Hとなって正式に公開されました。
一見大きな変化が無い様な感じですが、プロッターの3D画面操作がスムーズになり、歪みも改善されました。 それと、以前はボタン操作で色々と不都合な点があったのですが、その辺りも改善されてます。
β版は機能的に何が変わったのですか？
下図に、修正前とジャンプ域のみ単純移動平均操作を２回実施した修正後のリボン図を示します。ループの中程（修正操作の入口,赤矢印）とループの出口（修正操作の出口,赤矢印）に多少不自然さが残りますが、修正前と比較すると、修正精度は抜きにしてある程度見た目上ジャンプの修正ができたのではないかと思います。
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は解消されないので助かりました。
iPhone８でのChromeです。V2.2.1Hに自動更新され、それ以降はNGです。
画面がストップしたまま、本当にどうしたんでしょうか。
対策版を待つしかないですね。
どうしたんでしょうね。
また、変化があったら知らせてください。
情報ありがとうございます。
iPhone８でのChromeはOKです。クラブ員のiPadは本日最初はOKでした。しかし、V2.2.0Hに自動更新され画面がストップしてそれ以降はNGです。その後にChromeをインストール、でも、結果はNGでした。全部見られることを期待ですね。
カルマンフィルタを通して導き出しているのですね、きっと。
仕組みの事は分からないので気にした事も無いですが、多分、GPSや気圧センサーも共に誤差があるので、それぞれを補いながら計算しているのではないでしょうか。
素朴な疑問です。速度計測はGPSを使って移動距離と時間から割り出していると
思っていましたが、垂直降下の時などはどのようにして計測されているのでしょう？
高度は気圧センサーですか？
機能追加と言うことではないのですね。
ありがとうございます。
4ラウンド終了して、予選の結果が発表されました。
Final Preliminary (NEW)
次は上位20名で準決勝になります。
ーーーーーーーー
それと、日本では今、2022年度 F3A曲技日本選手権（８月24日～28日）が開催されてます。
結果は日本模型航空連盟のサイトで発表されます。
最初β版として発表したものが、V2.2.0Hとなって正式に公開されました。
一見大きな変化が無い様な感じですが、プロッターの3D画面操作がスムーズになり、歪みも改善されました。
それと、以前はボタン操作で色々と不都合な点があったのですが、その辺りも改善されてます。
β版は機能的に何が変わったのですか？
下図に、修正前とジャンプ域のみ単純移動平均操作を２回実施した修正後のリボン図を示します。ループの中程（修正操作の入口,赤矢印）とループの出口（修正操作の出口,赤矢印）に多少不自然さが残りますが、修正前と比較すると、修正精度は抜きにしてある程度見た目上ジャンプの修正ができたのではないかと思います。
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は解消されないので助かりました。