Flight Coach BBS

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

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

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

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

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

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

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

Solamon様、皆様

良いものを教えて頂き感謝申し上げます。
ご教示頂いたOLEDを動作設定し、OLEDのみの動作確認のため 8回フライトしました。
次回は、目的のSDカード書込みの任意化を外部スイッチを使用して行う予定です。

本日、各フライト全てF.Cへの電源投入後５秒以下でInitialize->Armed！でした。
あまりに早くArmed！となるので表示内容を読むのが大変でした。

本日は晴れ間はなく上空全体に高い雲があります、湿気は60%オーバーと思います。
OLED表示にAHRS not healthy等はありませんでした。
なんと、今日は珍しく50m越えによるプロッタ表示NGが一回もありませんでした。
全フライトでプロッタ表示が見られるのは数か月ぶりです。

しかし、８回フライトにおいて６回目のフライト中に大きなジャンプ現象が一回ありました。
トライアングルの終わりの45度降下から背面で抜けた時に飛行機が後退、その後、川の上に大きくジャンプしました。今まで経験がありません。写真を添付します。
両フライト、正面距離100m前後を飛ばしています。
考えられるハード面でのジャンプ対策も実施していますが、なにかが足りないようです。
（上図：大きくジャンプ、下図：通常）

moon様
ARMING_REQUIRE=0だとイニシャライズ後問答無用でArmedになるようです。
せめてARMING_CHECKが有効であればよいのですが私の設定が悪いのでしょうか？
またArm中はOLEDの表示が>>>ARMED!<<<となり何も確認できないと思います。

本日は晴れ間が少なく、昨日同様に上空全体に高い雲、湿気は60%オーバーと思います。

飛行場、昨日同様に一人ぼっちです。本日も８フライト、所要時間１時間半です。
昨日同様にプロッタ上で全フライトが見られました。今日は少しのジャンプも無しです。
OLED設置直前までワーストでは50%程度から最低1回は必ず50m飛びでNG、
全フライトを見たことの記憶すらありません。

不思議です、このままの状態で、50m飛びがいつ発生するか確認予定です。

物理的に変えたのはF.C上にOLEDを乗せて動作させたこと、ミッシュンプランナーでOLEDのArming関連を設定したことのみ。これらの変更は関係はしないと思いますが。ただし、天気等の環境は異なります。

上の投稿者様

アドバイス感謝いたします。
今の設定は、ARMING_REQUIRE=0です、ご指摘のとおり、イニシャライズ後にArmedに即座になります。
家での初期動作チェックにおいて、ARMING_CHECK欄のボックスにチェックを入れて有効にしましたが、特にエラー発生もなく変化を感じないので、今は初期確認用としてデフォルトの無効にしています。
チェックを入れての確認は、今後となりますが飛行場でしてみたいと思います。

先ほどはハンドルネームを入れ忘れました。
さて５０ｍ問題ですが、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など変な細工が必要になりました。　皆さんは飛行可能の判断をどうされていますか？

　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ファイルを用いてジャンプエラーを修正するのはかなり難しいと思われます。

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ケの操縦者位置と思います。同クラブのため代弁します。
因みに、私の飛行機位置は常にセンター右後方の木陰です。最悪の電波状況の所です。

ご協力に感謝いたします。
長文、失礼しました。

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高度が乖離していますが、
コメント表示はありません。プロッタ上にもジャンプ現象は見られません。

TakJP様

誤記を訂正します。
POS-Alt（赤->緑線）は矢印以降から乖離が始まり、その後にGPS-Alt（緑→赤線）に近くなります。
失礼しました。

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の姿勢情報も何らかの影響を及ぼしているのかもしれません。
　もう少し詳細に検討する必要がありそうです。

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様
お忙しいところ早々のご回答ありがとうございます。
緯度経度と思ってみていましたが、NED座標なるものがあること教えていただき大変勉強になりました。さらに先ほどのグラフが貴飛行場の前後左右方向に変換されていることを知り感服するばかりです。

TakJP様

沢山の貴重な情報ありがとうございます。
TakJP様が言われている通り、ジャンプの発生は、事象（主要因）によって予測計算値と実際値に乖離が始まり、
乖離が限界を超えた際に起きているように見えます。
今後とも、解析方法等のアドバイス頂ければ助かります。

再び「オリジンが50m以上ずれていて見られない」件ですがFlight Plotterに「Copy Origin」の機能があるのでこれを使うとPilotとCenterがOrigin座標となりとりあえずリボンは表示されます。このままだとリボン図の方向がコースからひどく狂いますが、Centerを
通常Pilot位置から1000m以上前方に設定すれば離着陸位置はちょっと怪しいですがパターンの確認には何とか使えるようです。

moon様、soramon様
いろいろと貴重な情報ありがとうございます。
　私がLOGファイルやJSONファイルの解析を始めたのは、Plotterによる飛行軌跡のジャンプを何とか修正したいと思ったからです。皆さんがご指摘のように、ジャンプがいつ何時発生するのか、今の段階では予測するのが非常に困難です。であるならば、ジャンプが起こるのを前提に、LOGファイルを解析してジャンプ前後のデータをなるべく正常な値に近づけ、その結果を基にJSONファイルを書き換えてジャンプを修正しようと考えました。しかし、LOGファイルを解析すればするほど、この試みが困難なことが分かってきました。Plotterによる飛行軌跡のジャンプは、moon様ご指摘の通り、予測値と実際値のズレが限界を超えたときに発生していると思われます。今は拡張カルマンフィルターによる予測方法を良く理解しないと先に進めない状況です。
　私が思い違いをしているところ、あるいはこうした方が良いよ、と言うようなことがございましたらご教示頂ければ幸いです。

Soramon様

リカバリに十分対応できます、ありがとうございました。
ご教示の方法で（サイトをマニュアルとして再設定後、Copy Originを押し、Submitを押す）表示されました。
左に60度位ずれていますが、十分に見ることができます。
BINファイルの位置情報を書き換えましたが、いまだに表示NGは解消されないので助かりました。

TakJP様

最小二乗法から始まり、カルマンフィルタ、、各種近似法がありますが、私には難しく殆ど理解していません。
ドローンは各種センサーの組合せの最新技術、それを使用したフライトコーチ、利用できる私たちは恵まれています。
計算方法含め近似して予想するのは非常に難しく、まだ万全ではないのだと思います。
より良くなることを願うのみです。

今後とも、解析の方法等を提供を頂ければ助かります。頭の活性化、知識向上になります。
また、ハード面でのジャンプ対策があればご教示を頂ければと思います。

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制限に縛られ最短コースでの離陸を迫られていました。
これからは通常の離陸コースを滑走して離陸できそうです。
ありがとうございました。

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様
ご回答ありがとうございます。
ジャンプしまくる原因のヒントにならないかとピント外れの質問になってしまい申し訳ありませんでした。

Soramon様
とんでもありません。
ご質問ありがとうございました。

皆様
今回の機能追加の内容は表示後３日経過したため削除させていただきました。
本情報の推測からフライトコーチを改造された場合は自己責任となります。
ご了承をお願いいたします。

ミュゼット（単葉）の飛行高度について。
視点の高さを200mにして見ると、F-25のスクエア・バーチカル・エイトの上部がちょうどこの高さ(200m)でした。

視点の高さについては、見たい高度の「グリッド線が水平」になる様に画像を移動させているだけです。
例えば200mの高度ならこんな感じです。

飛行コースの奥行きが関連するので、例えば、ジャッジビューがこんな感じだったとしても、

この実際の高度は260m以上でした。