もっと色々な飛行場での様子を知りたいですね。 エラーの発生状況を知らせて頂けるとありがたいです。
Denkado様のプロッタ上の飛行機のジャンプ現象の短時間のみズレの要因、この考えもあると思います。
TakJP様の提供データを拝見、GPSのマルチパス（反射波）による測位誤差が要因とも思えます。 背面飛行中は、GPSアンテナは下方向を向いています。GPS等の衛星は上空と見える範囲の水平方向にあるので、測位は地上からの反射波、水平に近い方向からの直接波で行われると思います。もしくは地上からの反射波、上空からの直接波で測位すると考えられます。前者、後者において、その反射波、直接波を受信した際に生じる測位誤差と思われます。 これが要因であれば対策は難しそうです。
飛行航路の左側には川があり砂利敷もあるので、上空からの衛星の反射波が生じやすいと思います。特に天気が良く、雲が高いときは衛星の電波状態が良く反射波は増えると考えます。反対に、湿気があり曇りのときは反射波は少なく現象は生じずらいとも思います。
大きくハズレかも知れません、その際はご容赦ください。
構成品を実際に手にするまでが、大変な事ですね。 同じ物でも、ルートによって価格は異なるでしょうし。
価格は商品の判断基準として一人歩きしてしまうし、不安定な供給品に対して簡単に値段をつける訳にもいかないので、ネットショップDenkadoでは、フライトコーチの価格を表示していません。 まぁ、それだけだと怪しい感じもするので、一応、現在の「タイプ2」に関しては、高級サーボ並みという風にしています。 実際のところ、部品の仕入れから、試作、組み立て、調整、解説書作りと、１つの商品として作り上げて行くのは、手間がかかるものですね。
こういった解析から、原因や対策が見えてくるといいですね。
denkado様のBINファイルをMission Plannerで解析した結果を添付致します。 図はLOGファイルに記録された、緯度、経度、高度を示しています。また、飛行軌跡のジャンプ位置も合わせて示しています。 ジャンプによって、緯度が減少（南に移動）、経度が増加（東に移動）、高度は変化無し、しています。また、denkado様のご指摘のように、曲線の傾向からジャンプ前はほぼ正常で、ジャンプ後にそのずれた分をその後の飛行で徐々に取り戻しているように見えます。
性能面、軽量で手頃さも兼ねた一番右を次期フライトコーチ機材用の候補としていました。 でも一年もしないで生産中止、在庫確保もままならない状態で流通から消え後継機種の情報もありません。 いつかは後継機種が出ると信じ、しばらくは我慢です。
denkado様 BINファイルをお送り頂き、ありがとうございました。 ダウンロードして確かめましたところ、私のフライトデータで見られた、ジャンプ時のLOGファイル中の"POS"のエラー表示"NaN"が見られません。この違いは、フライト開始時のキャリブレーションあるいはFCのファームウェアの違いによるものでしょうか。 となると、JASONファイル中のジャンプエラー時刻の特定の方法を別途考える必要がありますね。私のフライトデータでは、LOGファイル中の"POS"項のエラー表示"NaN"を探せばジャンプエラー時刻の特定ができたのですが、これとは別な特定方法を考える必要があります。
これだけ並ぶと壮観ですね。
データ解析となると全然分かりません。 このフライトのBINファイルをGoogleドライブにアップしてみましたが、役に立つなら使ってください。 P23_388.BIN
Line-up of Flight Coach devices
ミュゼット用に製作したフライトコーチです。 製作等のご参考になれば幸いです。
半導体不足、侵攻等の世界情勢のため、フライトコントローラ（F.C）の入手が難しくなりました。 下記搭載のF.Cは生産中止、流通在庫も無い状況です。 右端 ：MATEKSYS社製 M9N-F4-3100 (最新GPSとの一体型F.C) 重量約47g 右から二つ目：Holybro社製 Pixhawk4 mini + 同社M8N GPS 重量約80g 右から三つ目：Holybro社製 Pixhawk MINI + 同社M8N GPS 重量約60g
左から四つ目までが、いま辛うじて入手できるF.Cです。 左から四つ目：RadioLink社製 Mini pix + 同社TS100(MINI M8N) GPS 重量約53g
主に左から三つ目までをDenkado様にお取り扱いを頂いています。 ご購入頂いた皆様に御礼を申し上げます。
了解致しました。ご回答頂き、ありがとうございました。 私のフライトデータで、Mission PlannerによるLOGファイルを見てみますと、４回（時刻）ほど連続して位置データ"POS"にNaNのエラー表示がされた直後、飛行軌跡がジャンプしています。なお、GPSの受信は５回に１回ですので、４回の位置データのエラーは同じGPSからの受信データを用いて計算（推定）したものと思われます。これがどのようなことを意味しているのか、検討する必要があります。
そうですね。 他の場合でも、直前までは正しい感じです。
早速ご回答頂き、ありがとうございました。 飛行軌跡のズレの傾向は、他のジャンプエラーの際も同様でしょうか。
リボン図を色々な方向から見ての感想ですが、ジャンプの直前までは正常の様です。 ジャンプで横方向にずれ、そのずれた分をその後の飛行で徐々に取り戻している感じです。
JSONファイルをダウンロードさせて頂きました。 インメルマンターンの途中で飛行軌跡のジャンプが発生していますが、ジャンプの前と後でどちらの飛行軌跡が実際の軌跡に合っていそうでしょうか。ジャンプの前で飛行軌跡が既にずれていてジャンプによって実際の軌跡に戻るのか、あるいはジャンプによって軌跡がずれたためその後実際の軌跡からずれて少しずつ本来の軌跡に戻るのか、あるいは前後とも実際の軌跡からずれているのか、この何れとお感じでしょうか。 見た目で結構ですので、ご感想をお聞かせ頂ければ幸いです。
このフライトのjsonファイルをGoogleドライブにアップしました。 P23_388.json
以下はその再生手順です。 リンクをクリックすると勝手にファイルが開いて数字や記号が表示されるかもしれませんが、ウインド外枠にあるダウンロードマークでファイルのダウンロードと保存ができます。
3Dリボン図の再現はプロッターで行います。 プロッターは頻繁に更新されるので、過去に開いた事がある場合はキャッシュとして残っている古いバージョンを見ている可能性があります。 時々はプロッターを立ち上げる前に、PCなら［Shift］＋［Ctrl］＋［R］キーで再読み込みをしたり、機種によってはブラウザのキャッシュを空にすることをお勧めします。 新しいプロッターを立ち上げたら、緑色のOpen JSONボタンを押して、先ほどダウンロードしたP23_388.jsonを選ぶと、リボン図が再現されます。
赤い三角の「再生ボタン」が、アニメーションのスタート・ストップです。 他人のフライトを見ても驚きはしませんが、自分のフライトを客観的に見るというのには感動があるものです。 そして、間違いに気づくのです。 ここがフライトコーチを利用する上での一番大事な所。
Fパターンなので中々のものです。
今日のフライトです。斜めです。
トップビューの、飛行コースの曲がりが無くて良かったですね。
今日のフライトです。最後にジャンプしました。
今日のブログには、P-23の自動操縦飛行の動画を載せましたが、ドローン技術は凄い事になってますね。
私など全く知らない世界の話なので、感心するばかりです。
見ても分からないのですが、試しにWebサイトのMission Planner Home（ミッションプランナーホーム） に行ってみたので、足跡だけは残しておきます。 Diagnosing problems using Logs（ログを使用して問題を診断する）
もうご存じかと思いますが、私が行っている各曲技の際のGPSの捕捉数あるいはHDopの値を確認する方法を説明させて頂きます。 まず、JSONファイルをエディター等で確認します（JSONファイルはテキスト形式ですのでメモ帳などで確認可）。JSONファイルの初めの方に、各演技の名前、そのスタートの番号と終了の番号が記入されています。この番号は"data"以降に記載されているデータセット("time", "N"～"yaw")の、記録がスタートしてからの順番を表しておりスタート時は０です。"data"中の"time"はTimeUSで、FCが起動してからの経過時間(usec)を表しており、データセットは40msec毎(25Hz)に記録されています。したがって、最初のデータセット中の"time"の値が演技スタート時のTimeUS_org(usec)を表していることになります。一方、各演技のTimeUSはその演技のスタートの番号N_startと終了の番号N_stopから次式で与えられます。 TimeUS_start = TimeUS_org + N_start x 40,000 TimeUS_stop = TimeUS_org + N_stop x 40,000 (unit:usec) 次に、Mission Plannerを立ち上げます。トップページで、"DataFlash Logs"のタブ（右端）をクリック。現れたアイコンの中から、"Convert .Bin to .Log"をクリック。次に、解析したいBINファイルを選択すると、BINファイルのあったフォルダーにLOGファイルが作成されます。LOGファイルはテキスト形式なので、エディターで内容を確認可能。このLOGファイル中の左端の列がパラメータの名前、次の列がTimeUS(usec)で、３番目の列以降がパラメータの値を示しています。GPS項は左の列から、TimeUS, Status, GMS, GWk, NSats, HDop, Lat, Lng, Alt, Spd, GCrs, VZ, Yaw, Uを表しており、この中でNSatsが捕捉数を、HDopが水平方向の精度を表しています。JSONファイルから得た各演技のスタートと終了のTimeUSとこのLOGファイルから、各演技中のGPSの状態を知ることができます。なお、GPSからのデータは0.2sec毎(5Hz)に更新されますので、その間の位置データ("Pos")は何らかの方法で補完しているものと思われます。 また、Mission Plannerのトップページで"DataFlash Logs"のタブをクリックした際に表示される"Review a Log"をクリックし、表示したいBINファイルを選択すれば、下図のようにGPSの状態をグラフで確認することもできます。グラフに表示するデータはグラフ右側のメニューから選択します。 私はこのようにして、各演技の際のGPSの捕捉数あるいはHDopの値を確認しています。詳しくは、下記を参照して下さい。 https://ardupilot.org/planner/docs/common-downloading-and-analyzing-data-logs-in-mission-planner.html?highlight=log この方法以外に、もっと簡便に確認できる方法があるかもしれません。また、上述の文章中に私が勘違いをしている箇所があるかもしれません。もしお気づきの点がございましたら、ご指摘頂ければ幸いです。 長文、失礼致しました。
なるほど。 そんな修正ができる可能性もあるんですね。
ところで、前から疑問に思っていたのですが、 機体が背面になった時も、GPSやコンパスは正常に機能しているのでしょうか。
私の所で一番ジャンプエラーがあるのは、背面飛行後の垂直上昇なので、背面飛行時のデータ精度も疑っているのです。
画像のアップロードと投稿ボタンが別なので、ちょっと戸惑いますね。 まあ、「プレビュー」ボタンで確認したり、或いは間違ったら何度でも修正できるので、 これからも投稿お願いします。
ところで、プロッターを見る時の技術的な話ですが、 今回のような、上から見たトップビュー画面については、目の位置に気をつける必要があります。
この画面では、目の位置が175mコース上空となっているので、75〜100mコースを飛んでいるOreka80を「斜めから見ている」事になります。
プロッターの操作方法はデバイスによって異なるので上手く説明しきれませんが、右クリックやシフトボタンを押しながらドラッグをして、画像全体をスライドさせる事が必要です。 回転では無く、スライドです。
ブログ記事の下の方に、飛行コースと目の位置の関係が載っています。 2022/02/22 プロッターリボン図の見方 微妙な事かもしれませんが、こんなちょっとした事でも、ラインの印象は変わって来るものです。
前述のJSONファイルの修正について補足致します。 前述の修正法をFlight Coachの開発者に提案しましたところ、下記のような回答を得ました。「エラー前後の各種データをArdupilot（Flight Coachで用いているFCのファームウェア）側がどのように計算あるいは推定しているのか分からない。したがって、エラー前後の時刻のデータを用いてエラー時刻の軌跡を推定することは可能かもしれないが、その精度は疑問である。」 このようなことから、Plotterによる飛行軌跡のジャンプを少なくするためには、やはり元々のGPSなどによるエラーを少なくするしかなさそうですね。
下記グラフは、Plotterのグラフでエラーがないと思われるフライトのLOGファイルのGPSの捕捉数（赤線）とGPSのHDop（緑線）を表示したものです。 このグラフを見ますと、全領域で捕捉数は7以上、HDopはほぼ0となっています。また、前述したLOGファイル中の"Pos"項中のRelOriginAltにもエラーが発生していません。したがって、飛行軌跡にジャンプが現れる原因の一つにGPSのエラーがあるのかもしれません。ただし、GPSエラーが発生する時刻と、Plotter上でエラーが発生する時刻が必ずしも一致しないのは、denkado様が仰有るようにカルマンフィルターによる推定が関係しているのかもしれません。 ところで、私のフライトデータに限ったことかもしれませんが、飛行軌跡にジャンプが発生したJSONファイル中のエラー箇所を、ある程度特定することができます。そこで、エラーの発生を未然に防ぐのが難しいのであれば、得られたJSONファイル中のエラーデータを、前後の時刻の正常なデータから計算あるいは補完して、修正することが可能ではないかと考えています。このようなエラーの修正に意味があるのかどうか、皆さんのご意見を頂ければ幸いです。
うまくできました(^^;
あれ？ 画像の貼り付け方がわからない....
中々、素人ではどうしようもない領域の事なので、取りあえずは使って行く上で良い方法を探るしか無さそうですね。
以前、垂直姿勢でジャンプが多いと書きましたが、この例では珍しくハンプティの下降時に起こっています。 ただ、良く見ると、その前の演技の垂直上昇から異常が出始めていて、そういったズレをここで修正した様です。 カルマンフィルターの計算と実際がかけ離れすぎた結果のジャンプなんでしょうね。
どんなところでジャンプが多いのか、是非色々な方々の例を紹介していただけたらと思います。
下記のグラフはGPSの捕捉数（赤線）とGPSの水平方向精度HDop（数値が小さいほど高精度、2以下が推奨、緑線）並びにPlotterによりエラーが発生した位置（青線）を表しています。 ３回目のエラーはGPSの捕捉数がほぼ０（HDopがほぼ100、垂直の緑線）の線とほぼ一致していますが、１，２回目のエラーではそれらの線から10～15秒程度遅れています。したがって、GPSのエラーとPlotterによる飛行軌跡のジャンプは必ずしも一致しないことになります。 飛行軌跡のジャンプの原因について、Flight Coachの作成者に問い合わせたのですが、「エラーのほとんどはカルマンフィルターによるもので、その改善は難しい」との回答でした。したがって、エラーを解決するには、FCの設定の際にインプットするPramsの中のカルマンフィルターの設定に関するパラメータ（例えば、EK*など）の値に最適値があるのかもしれませんね。
カルマンフィルターとか言われても分からないのですが、 経験上エラーが発生するのは垂直姿勢が多いと感じています。
こちらはJUN TAUEさんの動画ですが、こういう動画を見ても、垂直時の方向が定まっていないのが分かります。 コンパスが働かなくなるタイミングでしょうか。 0324YZK 0:50では私が良く体験するのと同じ様なエラーも起こっています。
denkado様 貴重な情報を頂き、どうもありがとうございます。 私の場合は、LogファイルをMission Plannerで調べてみますと、Plotterによる軌跡がエラーとなる時刻に限って、Logファイルの'Pos'のRelOriginAltつまりOriginとの相対高度がエラーとなっています。その他の緯度、経度、高度は正常と思われる値ですので、Mission Plannerは滑らかな飛行軌跡を描くものと思われます。一方、Plotterはその他の機体の姿勢や加速度、角速度も加味して軌跡や姿勢を計算しているために飛行軌跡が不連続になってしまうのでしょうか. もう少し検討してみます。
全域ですか。 という事は、左右の差は無いという事ですね。
1年前のネットの話になりますが、 磐田ＲＣ掲示板で、「仰角マスク」とワード検索すると、2021/06/29の投稿に今回の件に関係する様な事が書いてあります。 飛行場によってはとてもエラーが多いところがあるそうで、その原因を考察されています。 その後どうなったのかは聞いていないのですが。
denkado様 私どもの飛行空域も、ほぼ全域川の上空になります。
クロス飛行場のフライトエリアです。 左側のエリアだけに水面があって、右側にはありません。 この左右差が、エラーの差に関係しているのかもしれません。
日本のRC飛行場は川の上で飛ばす事も多いので、各地の色々な情報を教えて頂ければ有難いです。
昔作ったスポーツマンのリボン図です。 今では、フライトコーチによって、自分のフライトがアニメーションの機体で再現できるんですから、夢の様な時代です。 飛行航跡3（スポーツマン）
情報ありがとうございます。 やはり、使用機器や場所などによって、エラーの出方が変わってくるみたいですね。 参考になりました。
今日こちらでは快晴でしたが、そのせいか、エラーがほとんど無くとても良い状態でした。 いつもの左側のインメルマンもOKでした。
衛星チェックというアプリです。 その時々の信号の強さがが分かるので、タイミングとか気象条件の影響があるのかどうか、チェックしてみるのも良いかもしれません。
飛行軌跡のジャンプが起こった例を添付致します。 P-23.9 インバーテッド・スピンに入る手前でジャンプした例です。 P-23.15 トライアングル・ループの後半でジャンプした例です。 何れも水平方向にジャンプしています。 私の場合はオリジンの位置は毎回ほぼ正確に設定されているようです。 エラーが出る日と出ない日があるようで、出る日はほぼ毎回出ますし、出ない日は５フライトに１回ほどです。やはり、GPS衛星のその日の位置が関係しているのでしょうか。また、Flight Coachの搭載当初に比べて最近はエラーの出る回数が少なくなったような気が致します。 以上、ご報告まで。
もっと色々な飛行場での様子を知りたいですね。
エラーの発生状況を知らせて頂けるとありがたいです。
Denkado様のプロッタ上の飛行機のジャンプ現象の短時間のみズレの要因、この考えもあると思います。
TakJP様の提供データを拝見、GPSのマルチパス（反射波）による測位誤差が要因とも思えます。
背面飛行中は、GPSアンテナは下方向を向いています。GPS等の衛星は上空と見える範囲の水平方向にあるので、測位は地上からの反射波、水平に近い方向からの直接波で行われると思います。もしくは地上からの反射波、上空からの直接波で測位すると考えられます。前者、後者において、その反射波、直接波を受信した際に生じる測位誤差と思われます。
これが要因であれば対策は難しそうです。
飛行航路の左側には川があり砂利敷もあるので、上空からの衛星の反射波が生じやすいと思います。特に天気が良く、雲が高いときは衛星の電波状態が良く反射波は増えると考えます。反対に、湿気があり曇りのときは反射波は少なく現象は生じずらいとも思います。
大きくハズレかも知れません、その際はご容赦ください。
構成品を実際に手にするまでが、大変な事ですね。
同じ物でも、ルートによって価格は異なるでしょうし。
価格は商品の判断基準として一人歩きしてしまうし、不安定な供給品に対して簡単に値段をつける訳にもいかないので、ネットショップDenkadoでは、フライトコーチの価格を表示していません。
まぁ、それだけだと怪しい感じもするので、一応、現在の「タイプ2」に関しては、高級サーボ並みという風にしています。
実際のところ、部品の仕入れから、試作、組み立て、調整、解説書作りと、１つの商品として作り上げて行くのは、手間がかかるものですね。
こういった解析から、原因や対策が見えてくるといいですね。
denkado様のBINファイルをMission Plannerで解析した結果を添付致します。
図はLOGファイルに記録された、緯度、経度、高度を示しています。また、飛行軌跡のジャンプ位置も合わせて示しています。
ジャンプによって、緯度が減少（南に移動）、経度が増加（東に移動）、高度は変化無し、しています。また、denkado様のご指摘のように、曲線の傾向からジャンプ前はほぼ正常で、ジャンプ後にそのずれた分をその後の飛行で徐々に取り戻しているように見えます。
性能面、軽量で手頃さも兼ねた一番右を次期フライトコーチ機材用の候補としていました。
でも一年もしないで生産中止、在庫確保もままならない状態で流通から消え後継機種の情報もありません。
いつかは後継機種が出ると信じ、しばらくは我慢です。
denkado様 BINファイルをお送り頂き、ありがとうございました。
ダウンロードして確かめましたところ、私のフライトデータで見られた、ジャンプ時のLOGファイル中の"POS"のエラー表示"NaN"が見られません。この違いは、フライト開始時のキャリブレーションあるいはFCのファームウェアの違いによるものでしょうか。
となると、JASONファイル中のジャンプエラー時刻の特定の方法を別途考える必要がありますね。私のフライトデータでは、LOGファイル中の"POS"項のエラー表示"NaN"を探せばジャンプエラー時刻の特定ができたのですが、これとは別な特定方法を考える必要があります。
これだけ並ぶと壮観ですね。
データ解析となると全然分かりません。
このフライトのBINファイルをGoogleドライブにアップしてみましたが、役に立つなら使ってください。
P23_388.BIN
Line-up of Flight Coach devices
ミュゼット用に製作したフライトコーチです。
製作等のご参考になれば幸いです。
半導体不足、侵攻等の世界情勢のため、フライトコントローラ（F.C）の入手が難しくなりました。
下記搭載のF.Cは生産中止、流通在庫も無い状況です。
右端 ：MATEKSYS社製 M9N-F4-3100 (最新GPSとの一体型F.C) 重量約47g
右から二つ目：Holybro社製 Pixhawk4 mini + 同社M8N GPS 重量約80g
右から三つ目：Holybro社製 Pixhawk MINI + 同社M8N GPS 重量約60g
左から四つ目までが、いま辛うじて入手できるF.Cです。
左から四つ目：RadioLink社製 Mini pix + 同社TS100(MINI M8N) GPS 重量約53g
主に左から三つ目までをDenkado様にお取り扱いを頂いています。
ご購入頂いた皆様に御礼を申し上げます。
了解致しました。ご回答頂き、ありがとうございました。
私のフライトデータで、Mission PlannerによるLOGファイルを見てみますと、４回（時刻）ほど連続して位置データ"POS"にNaNのエラー表示がされた直後、飛行軌跡がジャンプしています。なお、GPSの受信は５回に１回ですので、４回の位置データのエラーは同じGPSからの受信データを用いて計算（推定）したものと思われます。これがどのようなことを意味しているのか、検討する必要があります。
そうですね。
他の場合でも、直前までは正しい感じです。
早速ご回答頂き、ありがとうございました。
飛行軌跡のズレの傾向は、他のジャンプエラーの際も同様でしょうか。
リボン図を色々な方向から見ての感想ですが、ジャンプの直前までは正常の様です。
ジャンプで横方向にずれ、そのずれた分をその後の飛行で徐々に取り戻している感じです。
JSONファイルをダウンロードさせて頂きました。
インメルマンターンの途中で飛行軌跡のジャンプが発生していますが、ジャンプの前と後でどちらの飛行軌跡が実際の軌跡に合っていそうでしょうか。ジャンプの前で飛行軌跡が既にずれていてジャンプによって実際の軌跡に戻るのか、あるいはジャンプによって軌跡がずれたためその後実際の軌跡からずれて少しずつ本来の軌跡に戻るのか、あるいは前後とも実際の軌跡からずれているのか、この何れとお感じでしょうか。
見た目で結構ですので、ご感想をお聞かせ頂ければ幸いです。
このフライトのjsonファイルをGoogleドライブにアップしました。
P23_388.json
以下はその再生手順です。
リンクをクリックすると勝手にファイルが開いて数字や記号が表示されるかもしれませんが、ウインド外枠にあるダウンロードマークでファイルのダウンロードと保存ができます。
3Dリボン図の再現はプロッターで行います。
プロッターは頻繁に更新されるので、過去に開いた事がある場合はキャッシュとして残っている古いバージョンを見ている可能性があります。
時々はプロッターを立ち上げる前に、PCなら［Shift］＋［Ctrl］＋［R］キーで再読み込みをしたり、機種によってはブラウザのキャッシュを空にすることをお勧めします。
新しいプロッターを立ち上げたら、緑色のOpen JSONボタンを押して、先ほどダウンロードしたP23_388.jsonを選ぶと、リボン図が再現されます。
赤い三角の「再生ボタン」が、アニメーションのスタート・ストップです。
他人のフライトを見ても驚きはしませんが、自分のフライトを客観的に見るというのには感動があるものです。
そして、間違いに気づくのです。
ここがフライトコーチを利用する上での一番大事な所。
Fパターンなので中々のものです。
今日のフライトです。斜めです。
トップビューの、飛行コースの曲がりが無くて良かったですね。
今日のフライトです。最後にジャンプしました。
今日のブログには、P-23の自動操縦飛行の動画を載せましたが、ドローン技術は凄い事になってますね。
私など全く知らない世界の話なので、感心するばかりです。
見ても分からないのですが、試しにWebサイトのMission Planner Home（ミッションプランナーホーム）
に行ってみたので、足跡だけは残しておきます。
Diagnosing problems using Logs（ログを使用して問題を診断する）
もうご存じかと思いますが、私が行っている各曲技の際のGPSの捕捉数あるいはHDopの値を確認する方法を説明させて頂きます。
まず、JSONファイルをエディター等で確認します（JSONファイルはテキスト形式ですのでメモ帳などで確認可）。JSONファイルの初めの方に、各演技の名前、そのスタートの番号と終了の番号が記入されています。この番号は"data"以降に記載されているデータセット("time", "N"～"yaw")の、記録がスタートしてからの順番を表しておりスタート時は０です。"data"中の"time"はTimeUSで、FCが起動してからの経過時間(usec)を表しており、データセットは40msec毎(25Hz)に記録されています。したがって、最初のデータセット中の"time"の値が演技スタート時のTimeUS_org(usec)を表していることになります。一方、各演技のTimeUSはその演技のスタートの番号N_startと終了の番号N_stopから次式で与えられます。
TimeUS_start = TimeUS_org + N_start x 40,000
TimeUS_stop = TimeUS_org + N_stop x 40,000 (unit:usec)
次に、Mission Plannerを立ち上げます。トップページで、"DataFlash Logs"のタブ（右端）をクリック。現れたアイコンの中から、"Convert .Bin to .Log"をクリック。次に、解析したいBINファイルを選択すると、BINファイルのあったフォルダーにLOGファイルが作成されます。LOGファイルはテキスト形式なので、エディターで内容を確認可能。このLOGファイル中の左端の列がパラメータの名前、次の列がTimeUS(usec)で、３番目の列以降がパラメータの値を示しています。GPS項は左の列から、TimeUS, Status, GMS, GWk, NSats, HDop, Lat, Lng, Alt, Spd, GCrs, VZ, Yaw, Uを表しており、この中でNSatsが捕捉数を、HDopが水平方向の精度を表しています。JSONファイルから得た各演技のスタートと終了のTimeUSとこのLOGファイルから、各演技中のGPSの状態を知ることができます。なお、GPSからのデータは0.2sec毎(5Hz)に更新されますので、その間の位置データ("Pos")は何らかの方法で補完しているものと思われます。
また、Mission Plannerのトップページで"DataFlash Logs"のタブをクリックした際に表示される"Review a Log"をクリックし、表示したいBINファイルを選択すれば、下図のようにGPSの状態をグラフで確認することもできます。グラフに表示するデータはグラフ右側のメニューから選択します。
私はこのようにして、各演技の際のGPSの捕捉数あるいはHDopの値を確認しています。詳しくは、下記を参照して下さい。
https://ardupilot.org/planner/docs/common-downloading-and-analyzing-data-logs-in-mission-planner.html?highlight=log
この方法以外に、もっと簡便に確認できる方法があるかもしれません。また、上述の文章中に私が勘違いをしている箇所があるかもしれません。もしお気づきの点がございましたら、ご指摘頂ければ幸いです。
長文、失礼致しました。
なるほど。
そんな修正ができる可能性もあるんですね。
ところで、前から疑問に思っていたのですが、
機体が背面になった時も、GPSやコンパスは正常に機能しているのでしょうか。
私の所で一番ジャンプエラーがあるのは、背面飛行後の垂直上昇なので、背面飛行時のデータ精度も疑っているのです。
画像のアップロードと投稿ボタンが別なので、ちょっと戸惑いますね。
まあ、「プレビュー」ボタンで確認したり、或いは間違ったら何度でも修正できるので、
これからも投稿お願いします。
ところで、プロッターを見る時の技術的な話ですが、
今回のような、上から見たトップビュー画面については、目の位置に気をつける必要があります。
この画面では、目の位置が175mコース上空となっているので、75〜100mコースを飛んでいるOreka80を「斜めから見ている」事になります。
プロッターの操作方法はデバイスによって異なるので上手く説明しきれませんが、右クリックやシフトボタンを押しながらドラッグをして、画像全体をスライドさせる事が必要です。
回転では無く、スライドです。
ブログ記事の下の方に、飛行コースと目の位置の関係が載っています。
2022/02/22 プロッターリボン図の見方
微妙な事かもしれませんが、こんなちょっとした事でも、ラインの印象は変わって来るものです。
前述のJSONファイルの修正について補足致します。
前述の修正法をFlight Coachの開発者に提案しましたところ、下記のような回答を得ました。「エラー前後の各種データをArdupilot（Flight Coachで用いているFCのファームウェア）側がどのように計算あるいは推定しているのか分からない。したがって、エラー前後の時刻のデータを用いてエラー時刻の軌跡を推定することは可能かもしれないが、その精度は疑問である。」
このようなことから、Plotterによる飛行軌跡のジャンプを少なくするためには、やはり元々のGPSなどによるエラーを少なくするしかなさそうですね。
下記グラフは、Plotterのグラフでエラーがないと思われるフライトのLOGファイルのGPSの捕捉数（赤線）とGPSのHDop（緑線）を表示したものです。
このグラフを見ますと、全領域で捕捉数は7以上、HDopはほぼ0となっています。また、前述したLOGファイル中の"Pos"項中のRelOriginAltにもエラーが発生していません。したがって、飛行軌跡にジャンプが現れる原因の一つにGPSのエラーがあるのかもしれません。ただし、GPSエラーが発生する時刻と、Plotter上でエラーが発生する時刻が必ずしも一致しないのは、denkado様が仰有るようにカルマンフィルターによる推定が関係しているのかもしれません。
ところで、私のフライトデータに限ったことかもしれませんが、飛行軌跡にジャンプが発生したJSONファイル中のエラー箇所を、ある程度特定することができます。そこで、エラーの発生を未然に防ぐのが難しいのであれば、得られたJSONファイル中のエラーデータを、前後の時刻の正常なデータから計算あるいは補完して、修正することが可能ではないかと考えています。このようなエラーの修正に意味があるのかどうか、皆さんのご意見を頂ければ幸いです。
うまくできました(^^;
あれ？ 画像の貼り付け方がわからない....
中々、素人ではどうしようもない領域の事なので、取りあえずは使って行く上で良い方法を探るしか無さそうですね。
以前、垂直姿勢でジャンプが多いと書きましたが、この例では珍しくハンプティの下降時に起こっています。
ただ、良く見ると、その前の演技の垂直上昇から異常が出始めていて、そういったズレをここで修正した様です。
カルマンフィルターの計算と実際がかけ離れすぎた結果のジャンプなんでしょうね。
どんなところでジャンプが多いのか、是非色々な方々の例を紹介していただけたらと思います。
下記のグラフはGPSの捕捉数（赤線）とGPSの水平方向精度HDop（数値が小さいほど高精度、2以下が推奨、緑線）並びにPlotterによりエラーが発生した位置（青線）を表しています。
３回目のエラーはGPSの捕捉数がほぼ０（HDopがほぼ100、垂直の緑線）の線とほぼ一致していますが、１，２回目のエラーではそれらの線から10～15秒程度遅れています。したがって、GPSのエラーとPlotterによる飛行軌跡のジャンプは必ずしも一致しないことになります。
飛行軌跡のジャンプの原因について、Flight Coachの作成者に問い合わせたのですが、「エラーのほとんどはカルマンフィルターによるもので、その改善は難しい」との回答でした。したがって、エラーを解決するには、FCの設定の際にインプットするPramsの中のカルマンフィルターの設定に関するパラメータ（例えば、EK*など）の値に最適値があるのかもしれませんね。
カルマンフィルターとか言われても分からないのですが、
経験上エラーが発生するのは垂直姿勢が多いと感じています。
こちらはJUN TAUEさんの動画ですが、こういう動画を見ても、垂直時の方向が定まっていないのが分かります。
コンパスが働かなくなるタイミングでしょうか。
0324YZK
0:50では私が良く体験するのと同じ様なエラーも起こっています。
denkado様
貴重な情報を頂き、どうもありがとうございます。
私の場合は、LogファイルをMission Plannerで調べてみますと、Plotterによる軌跡がエラーとなる時刻に限って、Logファイルの'Pos'のRelOriginAltつまりOriginとの相対高度がエラーとなっています。その他の緯度、経度、高度は正常と思われる値ですので、Mission Plannerは滑らかな飛行軌跡を描くものと思われます。一方、Plotterはその他の機体の姿勢や加速度、角速度も加味して軌跡や姿勢を計算しているために飛行軌跡が不連続になってしまうのでしょうか.
もう少し検討してみます。
全域ですか。
という事は、左右の差は無いという事ですね。
1年前のネットの話になりますが、
磐田ＲＣ掲示板で、「仰角マスク」とワード検索すると、2021/06/29の投稿に今回の件に関係する様な事が書いてあります。
飛行場によってはとてもエラーが多いところがあるそうで、その原因を考察されています。
その後どうなったのかは聞いていないのですが。
denkado様
私どもの飛行空域も、ほぼ全域川の上空になります。
クロス飛行場のフライトエリアです。
左側のエリアだけに水面があって、右側にはありません。
この左右差が、エラーの差に関係しているのかもしれません。
日本のRC飛行場は川の上で飛ばす事も多いので、各地の色々な情報を教えて頂ければ有難いです。
昔作ったスポーツマンのリボン図です。
今では、フライトコーチによって、自分のフライトがアニメーションの機体で再現できるんですから、夢の様な時代です。
飛行航跡3（スポーツマン）
情報ありがとうございます。
やはり、使用機器や場所などによって、エラーの出方が変わってくるみたいですね。
参考になりました。
今日こちらでは快晴でしたが、そのせいか、エラーがほとんど無くとても良い状態でした。
いつもの左側のインメルマンもOKでした。
衛星チェックというアプリです。
その時々の信号の強さがが分かるので、タイミングとか気象条件の影響があるのかどうか、チェックしてみるのも良いかもしれません。
飛行軌跡のジャンプが起こった例を添付致します。
P-23.9 インバーテッド・スピンに入る手前でジャンプした例です。
P-23.15 トライアングル・ループの後半でジャンプした例です。
何れも水平方向にジャンプしています。
私の場合はオリジンの位置は毎回ほぼ正確に設定されているようです。
エラーが出る日と出ない日があるようで、出る日はほぼ毎回出ますし、出ない日は５フライトに１回ほどです。やはり、GPS衛星のその日の位置が関係しているのでしょうか。また、Flight Coachの搭載当初に比べて最近はエラーの出る回数が少なくなったような気が致します。
以上、ご報告まで。