下記のグラフは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の自動操縦飛行の動画を載せましたが、ドローン技術は凄い事になってますね。
もし新しいトピックを立ち上げた方が良いなら、どなたかお願いします。
興味深い情報をご提供いただきありがとうございます。 さっそくビデオを参考にCustom Firmware Builderを使いV4.5.0を試しました。 ARMING_BBOX_SPDというパラメータが追加されます。これは GPS速度[m/s]が設定値を超えるとARMし、下回るとDISARMします。初期値は5m/sです。 室内窓際でのテストですが起動後の衛星補足数が少ないときは、GPS位置が結構移動するためGPS速度の設定値を超えたと判断し不要なLOGファイルが多数記録されました。設定値を上げれば解決しそうですが、ストールやスピンなどで速度低下するとDISARMされるのではないかと思います。 またUAV Log Viewerで表示させた場合はEKF3よりもEKF2の方がジャンプが穏やかと言っていますがAHRS_EKF_TYPE=2にしろとは言ってません。わからないときはやってみれば良いので近いうちに試してみようと思います。
新しい動画がアップされてます。
下記のグラフは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の自動操縦飛行の動画を載せましたが、ドローン技術は凄い事になってますね。
もし新しいトピックを立ち上げた方が良いなら、どなたかお願いします。
興味深い情報をご提供いただきありがとうございます。
さっそくビデオを参考にCustom Firmware Builderを使いV4.5.0を試しました。
ARMING_BBOX_SPDというパラメータが追加されます。これは GPS速度[m/s]が設定値を超えるとARMし、下回るとDISARMします。初期値は5m/sです。
室内窓際でのテストですが起動後の衛星補足数が少ないときは、GPS位置が結構移動するためGPS速度の設定値を超えたと判断し不要なLOGファイルが多数記録されました。設定値を上げれば解決しそうですが、ストールやスピンなどで速度低下するとDISARMされるのではないかと思います。
またUAV Log Viewerで表示させた場合はEKF3よりもEKF2の方がジャンプが穏やかと言っていますがAHRS_EKF_TYPE=2にしろとは言ってません。わからないときはやってみれば良いので近いうちに試してみようと思います。
新しい動画がアップされてます。