Flight Coach BBS

denkado様
飛行軌跡のジャンプが起こる際、何かの特徴があるのでしょうか。このような場合に起こりやすいとか。
私の場合は、最初のフライトを始める前に、GPSを捕捉するための時間を充分に取らなかった場合にエラーが発生するような気が致します。

同感です。
その日の初フライトとか、前のフライトから時間が経ってのフライトではGPS捕捉時間が長くなりますが、そのままフライトした時はエラーが多い感じです。
なので今では、そんな時は一旦電源を入れ直してからフライトする様にしています。
ただ、これでもエラーは発生する事があります。

それと、GPS衛星の状況を調べるアプリがあって、それによると、結構バラつきがあるんだそうです。
これはどうしようもない事なので、電源を入れる時の運次第という事なのかもしれません。

しばらくキャリブレーションをしないで使っていたので、近々やってみようと思っていた所でした。
まぁ、仲間のも同じ様な状況なので、キャリブレーションだけで解決するとは思っていないのですが。

私の場合も、GPS捕捉の時間を充分取った後でも、時々エラーが発生します。denkado様の仰有るように、電源を入れるときの運次第となると、例えば曲技審査の参考資料として使用すると言った用途に使うのは難しくなりますね。あるいは、前述したように、Flight Coachのエラー修正アルゴリズムの改良に期待するしかないのでしょうか。

データログの成功率からして、公式に使うのには無理がありますね。
複数台使うとか、1台ごとの成功率を上げる必要があります。

前出の画像と同じフライトのものです。
オリジンをクリックするとマップが開いて位置確認が出来ますが、やってみると、確かに相当離れた位置になっていました。

私は、オリジンのズレが気になるので毎回パイロット位置で電源を入れているのですが、結構誤差が大きいですね。
この辺からして、今の精度では色々と問題が出ても仕方ないのかと思っています。

現時点では、位置精度に問題がありそうですね。
飛行軌跡のジャンプの件ですが、カーボン製のキャノピーとプラスチックのキャノピーを比較しますと、カーボン製のキャノピーを用いた機体の方がエラーが出やすいように感じます。但し、エラーが出たときの機体の姿勢を見ますと、決してFlight CoachシステムのGPSアンテナとGPS衛星の間にカーボン製のキャノピーが入っているようには見えないのですが。

エラーの原因は様々でしょうが、その一因として考えられる例です。
画像は、P-23.08インメルマンの左風と右風のものです。

クロス飛行場ではこの様に、左側で、背面から垂直上昇させた時にエラーが多く発生するのです。
こんな事から、仲間内では機体側に原因があるのではなく、地形や建造物などの影響ではと考えているのです。

denkado様のご指摘のように、エラーの原因は様々ありそうです。とすると、その対処法を見つけるのはなかなか大変ですね。できるだけ多くの利用者からエラーのサンプルを集めて、それらを客観的に眺めて対処法を探るしかなさそうですね。フライトする場所あるいは周囲環境にも寄るのでしょうが。

今日もエラーが出ています。

これは、珍しく真正面の位置ですが、姿勢はやはり背面からの上昇時です。

こちらはいつもの左側で、やはり背面からの上昇時です。

それと、両方のオリジンの位置にも注目してほしいのですが、電源を入れたのはパイロット位置だったのに、結果としては10m前後のズレとなっていました。

クロス飛行場としてはこんな感じですが、他の場所での様子も知らせていただければ有難いです。

飛行軌跡のジャンプが起こった例を添付致します。
P-23.9　インバーテッド・スピンに入る手前でジャンプした例です。

P-23.15　トライアングル・ループの後半でジャンプした例です。

何れも水平方向にジャンプしています。
私の場合はオリジンの位置は毎回ほぼ正確に設定されているようです。
エラーが出る日と出ない日があるようで、出る日はほぼ毎回出ますし、出ない日は５フライトに１回ほどです。やはり、GPS衛星のその日の位置が関係しているのでしょうか。また、Flight Coachの搭載当初に比べて最近はエラーの出る回数が少なくなったような気が致します。
以上、ご報告まで。

情報ありがとうございます。
やはり、使用機器や場所などによって、エラーの出方が変わってくるみたいですね。
参考になりました。

今日こちらでは快晴でしたが、そのせいか、エラーがほとんど無くとても良い状態でした。
いつもの左側のインメルマンもOKでした。

クロス飛行場のフライトエリアです。

左側のエリアだけに水面があって、右側にはありません。
この左右差が、エラーの差に関係しているのかもしれません。

日本のRC飛行場は川の上で飛ばす事も多いので、各地の色々な情報を教えて頂ければ有難いです。

denkado様
私どもの飛行空域も、ほぼ全域川の上空になります。

全域ですか。
という事は、左右の差は無いという事ですね。

1年前のネットの話になりますが、
磐田ＲＣ掲示板で、「仰角マスク」とワード検索すると、2021/06/29の投稿に今回の件に関係する様な事が書いてあります。
飛行場によってはとてもエラーが多いところがあるそうで、その原因を考察されています。
その後どうなったのかは聞いていないのですが。

denkado様
貴重な情報を頂き、どうもありがとうございます。
私の場合は、LogファイルをMission Plannerで調べてみますと、Plotterによる軌跡がエラーとなる時刻に限って、Logファイルの'Pos'のRelOriginAltつまりOriginとの相対高度がエラーとなっています。その他の緯度、経度、高度は正常と思われる値ですので、Mission Plannerは滑らかな飛行軌跡を描くものと思われます。一方、Plotterはその他の機体の姿勢や加速度、角速度も加味して軌跡や姿勢を計算しているために飛行軌跡が不連続になってしまうのでしょうか.
もう少し検討してみます。

カルマンフィルターとか言われても分からないのですが、
経験上エラーが発生するのは垂直姿勢が多いと感じています。

こちらはJUN TAUEさんの動画ですが、こういう動画を見ても、垂直時の方向が定まっていないのが分かります。
コンパスが働かなくなるタイミングでしょうか。
0324YZK
0:50では私が良く体験するのと同じ様なエラーも起こっています。

下記のグラフはGPSの捕捉数（赤線）とGPSの水平方向精度HDop（数値が小さいほど高精度、2以下が推奨、緑線）並びにPlotterによりエラーが発生した位置（青線）を表しています。

３回目のエラーはGPSの捕捉数がほぼ０（HDopがほぼ100、垂直の緑線）の線とほぼ一致していますが、１，２回目のエラーではそれらの線から10～15秒程度遅れています。したがって、GPSのエラーとPlotterによる飛行軌跡のジャンプは必ずしも一致しないことになります。
飛行軌跡のジャンプの原因について、Flight Coachの作成者に問い合わせたのですが、「エラーのほとんどはカルマンフィルターによるもので、その改善は難しい」との回答でした。したがって、エラーを解決するには、FCの設定の際にインプットするPramsの中のカルマンフィルターの設定に関するパラメータ（例えば、EK*など）の値に最適値があるのかもしれませんね。

中々、素人ではどうしようもない領域の事なので、取りあえずは使って行く上で良い方法を探るしか無さそうですね。

以前、垂直姿勢でジャンプが多いと書きましたが、この例では珍しくハンプティの下降時に起こっています。

ただ、良く見ると、その前の演技の垂直上昇から異常が出始めていて、そういったズレをここで修正した様です。
カルマンフィルターの計算と実際がかけ離れすぎた結果のジャンプなんでしょうね。

どんなところでジャンプが多いのか、是非色々な方々の例を紹介していただけたらと思います。

下記グラフは、Plotterのグラフでエラーがないと思われるフライトのLOGファイルのGPSの捕捉数（赤線）とGPSのHDop（緑線）を表示したものです。

このグラフを見ますと、全領域で捕捉数は7以上、HDopはほぼ0となっています。また、前述したLOGファイル中の"Pos"項中のRelOriginAltにもエラーが発生していません。したがって、飛行軌跡にジャンプが現れる原因の一つにGPSのエラーがあるのかもしれません。ただし、GPSエラーが発生する時刻と、Plotter上でエラーが発生する時刻が必ずしも一致しないのは、denkado様が仰有るようにカルマンフィルターによる推定が関係しているのかもしれません。
ところで、私のフライトデータに限ったことかもしれませんが、飛行軌跡にジャンプが発生したJSONファイル中のエラー箇所を、ある程度特定することができます。そこで、エラーの発生を未然に防ぐのが難しいのであれば、得られたJSONファイル中のエラーデータを、前後の時刻の正常なデータから計算あるいは補完して、修正することが可能ではないかと考えています。このようなエラーの修正に意味があるのかどうか、皆さんのご意見を頂ければ幸いです。

前述のJSONファイルの修正について補足致します。
　前述の修正法をFlight Coachの開発者に提案しましたところ、下記のような回答を得ました。「エラー前後の各種データをArdupilot（Flight Coachで用いているFCのファームウェア）側がどのように計算あるいは推定しているのか分からない。したがって、エラー前後の時刻のデータを用いてエラー時刻の軌跡を推定することは可能かもしれないが、その精度は疑問である。」
　このようなことから、Plotterによる飛行軌跡のジャンプを少なくするためには、やはり元々のGPSなどによるエラーを少なくするしかなさそうですね。

なるほど。
そんな修正ができる可能性もあるんですね。

ところで、前から疑問に思っていたのですが、
機体が背面になった時も、GPSやコンパスは正常に機能しているのでしょうか。

私の所で一番ジャンプエラーがあるのは、背面飛行後の垂直上昇なので、背面飛行時のデータ精度も疑っているのです。

もうご存じかと思いますが、私が行っている各曲技の際の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
　この方法以外に、もっと簡便に確認できる方法があるかもしれません。また、上述の文章中に私が勘違いをしている箇所があるかもしれません。もしお気づきの点がございましたら、ご指摘頂ければ幸いです。
　長文、失礼致しました。

私など全く知らない世界の話なので、感心するばかりです。

見ても分からないのですが、試しにWebサイトのMission Planner Home（ミッションプランナーホーム）
に行ってみたので、足跡だけは残しておきます。
Diagnosing problems using Logs（ログを使用して問題を診断する）

今日のブログには、P-23の自動操縦飛行の動画を載せましたが、ドローン技術は凄い事になってますね。

もし新しいトピックを立ち上げた方が良いなら、どなたかお願いします。

新しい動画がアップされてます。