Flight Coach BBS

なるほど。
やってみたら、見られなかったフライトが表示できました。
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前後を飛ばしています。
考えられるハード面でのジャンプ対策も実施していますが、なにかが足りないようです。
（上図：大きくジャンプ、下図：通常）

（2024.2.25修正）

2022/08/10の「続く‥ 」 より

ここからが飛行場へ行っての話になります。
初めての場所や、コールド・スタート（その日の最初のフライト）ではGPSロックに時間がかかります。

・マイクロSDカードをセットして、

・パイロット位置から50m以内の任意の場所で電源を入れます。
　（その位置がオリジンとなります。GPS電波障害を避けるため車やテント、崖などから離れて）

・数分待ってロック合図のLED点滅変化を確認してからフライトします。

・プロッタにリボン図が描かれる条件の１つとして、F3A飛行の場合は10m以上の高度が必要です。

・着陸後は、「電源を切ってから」カードを抜き、パソコンに挿し替えます。

・ブックマークしておいたプロッターで目的のBINファイルを開きます。（屋外のオフラインでもキャッシュで動きます）

・最初にデータに関する注意画面が出る事がありますが、（2024.2.25修正）

OKを押すと選択画面(Schedule and Site Selection)となります。
そこのSchedule欄では「F3A」の中の、（どれでも構いませんが）例えば「P25」や「Generic」を入れます。これによって、リボン図を再生する時の背景がパターン面となります。

・下のSelect Site欄では飛行場の場所を指定します。
飛行場を登録してあると、自動的に入力されていたり、あるいは、選択して呼び出す事ができます。

未登録の場所の場合は「manual」とし、このタイミングでメモしておいた「パイロット位置」と「センター位置」の座標を手動で入力します。

慣れて来たら、Mapページにあるボタンからカスタムサイトを作って、「.f3a」ファイルをP.Cに保存しておくと、F3AZoneボタンを使っての座標入力が簡単になります。
方法は、「manual」にしたときにF3AZoneボタンが現れるので、それを押して「.f3a」ファイルを選択するだけで、座標の数値が入力されます。
これらは一度入力すると、次からはキャッシュによって自動で再現されます。
（別の飛行場に行った場合やキャッシュクリアした時は、また座標入力が必要）

・入力後にSubmitを押すと、3Dリボン図が出てきます。

ーーーーーーーーーーーーーーーー
以上が、3Dリボン図を再現するまでの手順です。

もしプロッターの動きが悪くなった場合は、一旦ブラウザのキャッシュをカラにしてから再チャレンジしてみてください。

それと、使用上の注意点ですが、フライトコーチのデータロギングは100%成功する訳ではありません。
エラーの原因は、機体によるものから、地形、GPS電波など色々考えられます。
高度の低いGPS衛星もあるので、電源ONは車から離れた場所が良いでしょう。
衛星チェックアプリを使えばGPSの電波状態が確認できます。
ただ、グラフは絶えず変化しているので、普段の状態を経験しておく必要があります。

自分達にできる対策の１つは「電源を入れて待つ」事です。
何分待てとは一概に言えませんが、連続フライトなら待ち時間は僅かですし、間が開くとロックの合図が遅くなるので、そういった失敗と成功の経験が必要なところだとも思います。

現在の私の使用状況ですが、
以前は飛行する時だけフライトコーチの電源をONとしていたのを、今では、飛行場に着いて機体を準備する時に、真っ先に電源を入れる様にしています。
この段階では、まだマイクロSDカードは入っていません。
そのままの状態を維持し、飛行する段になった時に改めて電源を入れ直し、その時にカードもセットします。
こうする様になってから、1フライト目でもエラーの発生が少なくなっている様に感じています。

また、あるユーザーさんからは、
「地形によると思われるエラーが発生していたが、滑走路で電源を入れた後、垂直尾翼を持ち上げて360°方向転換をしてからフライトするようにしたら問題が解決」
との情報もあります。

それと、基本的な事ですが、GPSアンテナ等の機器には性能差があって、エラーの出方にも違いがあります。

リボン図が現れたらそれがゴールではありません。
続いてコメント34にある様に「リボンの区切りを修正」する必要があります。
これを、演技を見直す時の習慣にすると良いでしょう。

投稿ありがとうございます。
画面が見やすくて良さそうですね。

プロッターでBINファイルを開くときの話ですが、
選択画面が出たら、Schedule欄では「F3A」の中の、（どれでも構いませんが）例えば「P23」を入れてみてください。
「F3A」にする事でグリッド線がパターン用になって、飛行コースが明確になります。

携帯スマホとして使ってるHUAWEI MediaPad M5 を使ってます。フライトデータをSDカードUSBアダプターからロードして飛行場で直ぐにチェック出来るので、自分の飛行の癖をチェック出来るので大変便利です。OSはAndroid ver.9 ですが、今までトラブった事は殆んどなく、画面も8inchと大きいので大変見易いです。

Soramon様
早速のご教示ありがとうございます。
非常に参考になります。

私もお教えいただいたものと同じF.Cを使用しています。
写真を見て素晴らしい工作、設置方法、およびシステム作りに驚きです。
プロッタ表示NGを無くすため、Origin位置＝飛行機位置を得るArmingができるか確認してみます。

moon様
発生当時のFCはMiniPixでしたがお嫁に行ったので現在はomnibusF4Pro類似品です。

PICでSBUS信号を作りタイマーまたは押し釦で右ラダーと左ラダーが出せるようにしています。起動後30秒したら右ラダーを自動で30秒間出しているので早いときは駐機場所でログを開始しますが狭い飛行場なので50m以内です。Arm後も押し釦でDisarmや再Armができるので離陸直前にログ開始させることは可能だと思います。

Soramon様
解析結果ありがとうございます。大変お手数をお掛けしました。
気圧計の異常ではなくAHRSの不安定さが原因となっていることを認識できました。

お聞きしたいことがあります。都合の良い時にお答えをいただければ助かります。
1)F.Cは何をお使いでしょうか。
2)Soramon様の対策方法では、SDカード書込み開始は必ず飛行機の置き場所、言い換えればプロッタ上に表示されるOrigin位置は飛行機位置で記憶されると思いますが如何でしょうか？　Origin位置＝飛行機位置とすると、従来から悩んでいた50m越えによるプロッタ表示NGを無くす（軽減する）ことが可能と思われますので。

お願いばかりで申し訳ございませんが、よろしくお願いいたします。

F-25ですね。
通すだけでも大変ですが、練習、練習です。

良く纏ってます。
トライアングルは形が良かったですね。
あとはロールの位置に注意です。

これも今日です。混雑してます。

今日のフライトです。

moon様
異常なデータの場合、GPS-Altと比較するとPOS-Altが時々急変しています（図１）。

これに伴いORGN-Altが更新（図２）されておりプロッタ表示上のゼロ点がリセットされジャンプしているのだと思います。
また10ｍ以下は表示されないため10m以下は張り付いているようです。
POS-Altの急変の原因はよくわからないのですが、現在は同じ機材で正常であるため気圧計の異常などでは無くAHRSなどが安定しない状態で飛行させたためEKFの位置推定が狂ってたのではないかと思っています。

なお私のFCはARMING_CHECK=0(無し)とするとFCイニシャライズの数秒はLEDが「速い点滅」をしその後ただちに「ゆっくり点滅」になります。その後GPSが3D-FIXしてもLEDの点灯状態は変化しないのでいつ３D-FIXしたのかわかりません。まして「AHRS not healthy」が発生するなんて気が付きませんでした。
ARMING_CHECK=1054にしたことで、FCイニシャライズの数秒はLEDが「速い点滅」。Prearm failedの時は「２回点滅」。Prearm OKで「ゆっくり点滅」になるので飛行可能なタイミングが分かるようになりました。

Soramo様　--> Soramon様   失礼しました。

Soramo様　
見たこともないデータ、異常の回数の多さにも驚きました。

「AHRS not healthy」の表示は、ミッションプランナー上でファーム書き換え以降の各種設定中に表示されることもありました、しかし、各種設定を終了後はこの表示を見たことがありません。
IMUと地磁気センサ（コンパス）を組み合わせたもの、AHRS(Attitude Heading Reference System)、日本語は「姿勢方位基準装置が不健康とは、、、、？。
不思議なのは、異常なリボン図から、飛行高度が10m以下で表示される横線での表示がたくさんあるように見えることです。
離陸時は高度10mを超えた部分から表示されているので、高度計の異常？　よほど気圧差の激しい場所、もしくは、本来のAHRSの異常、このような経験もなく不思議な現象です。
OLEDによるGPS情報等の表示、私も利用させていただきます。
情報ありがとうございます。早速アマゾンで注文しました。

今度は大丈夫ですね。
日付クリックで修正できるのが、この掲示板の良い所だと思っています。
気軽に活用してください。

Denkado様
お手数をおかけしました。画像アップの再チャレンジのため改善後のリボン図を載せてみます。

私の方で、アップしておきます。

多分ボタンを押す手順が違っていて、それが保存されたままだったのかもしれません。
それにしても、本当にエラーが多いですね。

修正してみましたがサムネイルリンクがうまくできず同じ状態になるようです。
最後の画像URL(//pic.zawazawa.jp/files/flightcoach/4cb8ca238a731.png)をコピペしてブラウザで検索すれば画像が表示されるみたいです。申し訳ありませんがこれでご勘弁ください。

Soramonさん。投稿ありがとうございます。
添付画像が見えないのですが、この掲示板では、画像投稿の場合、
「画像をアップして」--「投稿内容をプレビューで確認して」--「その後で送信」
と、なっています。
日付をクリックすると修正ができますので、確認をお願いします。

初めまして、皆さんと異なる事象かもしれませんがなんらかの参考になればと思い投稿させていただきます。
私の場合は添付のようなジャンプ現象が100%発生していました。FCにOLEDを付けてエラーを観察してみると電源投入後しばらく「AHRS not healthy」などの状態になることがあります。このように何らかのエラーが発生している状態で飛行させるもしくはログ開始させることが原因ではないかと思い、FlightCoachの推奨のARMING_CHECK=0(無し)を1054(Baro,Compass,GPS lock,INS,Loggig Available)、LOG_DISARMED=1を0に変更し、これらが健全になるまでログ開始できないようにしたらジャンプ現象は無くなりました。ただし自動でログ開始しないのでFCにRC受信機（SBUS）を接続して右ラダーを15秒ぐらい出してARMする必要があります。私の場合はRC受信機をFCに接続したくないのでPICを使ってSBUS信号を作りタイマでARM(右ラダー)するようにしています。](//pic.zawazawa.jp/files/flightcoach/4cb8ca238a731.png)

TakJP様、同感です。
慣性航法の計算で補正ができればよいのですが。今回の現象のジャンプ、通常飛行でエレベータ操作により再現できる感じです。とすれば、補正を行えば、偽りの補正になって目的外になり対策は難しそうです。

私も悩んでいます。ジャンプ現象が頻発すると精神衛生上よくありません。
この頃は、ロール軸、ヨー軸が安定した状態での小さいジャンプ現象は目で補正を加えて良しとしています。

現象がGPSの測位エラーによるものか、その他のセンサ（コンパス。ジャイロ、高度計）への外乱による誤動作によるものか、私もCut＆Tryで実験飛行しています。
感覚的に感じていることは、背面からの立ち上がりでは、GPSで測位しながらのエラーか、GPSで測位できない状態でコンパスで測位予想しているかで異なると思います。
徐々にずれる現象があれば、コンパスによる測位予想のずれが慣性航法の計算と一致せず徐々に乖離するとも思えます。
感覚的な発言で申し訳なしですが、その際は大きくジャンプして正常に戻るのに時間が掛かるようにも見受けられます。

ともあれ、TakJP様、Denkado様、皆様のお力で解決に少しでも近づければと思います。

エラーにもにも色々ありますね。
１〜2ヶ所のエラーならまだしも、時にはオリジンが50m以上ずれていて全然見られない事もあります。
それが見たかったフライトだと、余計にがっかりです。

moon様ご指摘のように、GPSエラーの原因として様々な要因が考えられ、これらを全て解決するのはなかなか大変なように思われます。そこで、GPSエラーがあることを前提に、そのエラー値を前後のデータから補正できないかと考えています。補正方法をいろいろと検討しているのですが、denkado様のフライトデータのようにジャンプの前までは正常で、ジャンプ後に少しずつ実際の軌跡に戻ろうとする場合もあれば、私のフライトデータの中にはジャンプの前に少しずつ実際の軌跡からずれてきて、ジャンプによって元に戻るように見えるものもあります。その違いはどこから来るのか、もう少し検討してみる必要があります。補正の方法等について、何か良いアイデアがありましたら、ご教示頂ければ幸いです。あるいは、そもそもエラーを補正する意味が無い、とのご意見でも結構です。