Mavros: NEDとENU間のフレーム変換を繰り返します

多分誰かが現在の状態についてコメントすることができますか？ 現在、コードをふるいにかける時間がありませんが、変換を確認できれば幸いです。

@LorenzMeier PR＃208を参照してください。

@LorenzMeier実際、これは私たちが使用している現在の規則です：

本体固定NED→ROSENU：（xyz）→（x-y -z）または（wxyz）→（x-y -zw）
ローカルNED→ROSENU：（xyz）→（yx-z）または（wxyz）→（yx-zw）

この図の正しさを確認することはできませんが、これは私たちが現在行っていることだと思います。

はい、それが私の計画です。 確認できたので、論文で使って説明しました。

注：この変換は数か月前に合意したものであり、Rvizで確認できました。

問題は実際の変換ではなく、特定の変換が使用された場合です。

私はこれを見ています：
http://wiki.ros.org/geometry/CoordinateFrameConventionsおよび
http://www.ros.org/reps/rep-0103.html

グラフィックにはいくつかの問題があります（そして、それが方向を表す場合は、コード）：

• ROSは常に右利きです。 ENUグラフィック（下の行）は左利きですが、これは正しくありません。
• ROSはENUを使用しています。 ENUは東北を意味するため、X軸はEASTを指し

したがって、ゼロ回転でのボディフレームとワールドフレームの間に違いはなく、NEDとENUの間の変換は、それぞれグローバル/ローカル参照を使用して、両方のフレームで同じです。

私は@LorenzMeierが言ったことにほとんど同意します。 ただし、上の図のすべての座標フレームを間違えない限り、右下の座標系は左手系の座標系です。 グラフィックの凡例でx軸とy軸のラベルを間違えたのではないでしょうか。

それとは別に、ENUからNEDへの変換は、グラウンドフレームでもボディフレームでも同じであることに同意します。 ボディフレームでは、ENUまたはNEDという名前はあまり意味がありませんが、ROSで使用される座標フレームからFCUへの変換は常に同じであると思います。

@mhkabirが上に投稿した変換方法はまだチェックしていません。 計算を行う前に、まずグラフィックを取得する必要があると考えてください

@thedinukaあなたくれませんか。 ;）

元のファイルがあり、それを変更してから新しいファイルを送信できます（paint @mhkabirを使用する必要はありません）。 右手と左手のことは正しいようです。 しかし、私はまだ2つの異なる会話を持っていることに疑問を持っています、そして私がその時にそのイメージをしたとき、私もそれらを持っていました。 したがって、おそらくコードをチェックする必要があります。私が覚えていることから、ほとんどの実装は上記の変換を使用しています。

@ TSC21によるグラフィックの修正版を待っている間、私はこれをもう少し考えました、そしてそれは私が最初に思ったより複雑に思えます。 @ TSC21に同意します。 考える必要のある座標変換の2つの異なるペアがあります。

1）本体固定フレームのROS規則から本体固定フレームのPixhawk規則への変換。
2）地球固定フレームのROS規則から地球固定フレームのPixhawk規則に変換します。

ROS側とPixhawk側の両方で、ボディ固定座標フレームに使用される規則に関するドキュメントがありますが、慣性（または地球固定）座標フレームについてPixhawk側で使用される規則に関する特定の情報を見つけることができませんでした。 推測しなければならないとしたら、Pixhawk側では、GPSがない場合、Earth Fixed座標フレームは、body-fixedフレームの初期方向と一致しますが、100％確信が持てません。これが事実です。 したがって、間違いや混乱を防ぐために、ここでは、本体の固定フレームのみを検討します。

ROSのドキュメント[1]とPixhawkのドキュメント[2]を中継して、次の図を作成しました。

上記の（1）と（2）の両方の座標フレーム図を検証、確認、同意すると、マブロス側で実際の変換を行うための計算は非常に簡単になります。

[1] http://www.ros.org/reps/rep-0103.html
[2] https://pixhawk.org/dev/know-how/frames_of_reference

＃148（共分散変換）もご覧ください。

これはros-infrastructure / rep＃95に役立つ可能性があります

これでどこかに行き着きましたか？ ENU / NED、ボディ/ワールドフレームからの現在の変換は正しいですか？ 私はこの原因を尋ねています。私たちが間違ったことをしているため、ビジョンデータを送信するときに@blackcoderがFCUでヨー回転を取得している可能性を繰り返す必要があります。
@ vooon 、 @ mhkabir 、 @ tonybaltovski 、 @ thedinuka ping！

@thedinuka私にはよさそうだ。

推測しなければならない場合、Pixhawk側では、GPSがない場合、EarthFixed座標フレームは> body-fixedフレームの初期方向と一致します。

実際にはGPSは必要ありません。 すでに雑誌からのグローバルヨーリファレンスがあります。 これは、このヨーによって使用して回転したEFフレームを意味するはずです。

やあ、
mavrosでトピックをmocap_optitrackからvision_pose / poseに再マッピングします。 ただし、mavは正しく飛行できないため、次のコードを変更します
vision_position_estimate（stamp.toNSec（）/ 1000、
position.y（）、position.x（）、-position.z（）、
ロール、-ピッチ、-ヨー）; // ??? チェックしてください！
に
vision_position_estimate（stamp.toNSec（）/ 1000、
position.y（）、position.x（）、-position.z（）、
ロール、-ピッチ、-ヨー+ 1.57）;
つまり、-yawを-yaw +1.57に変更します。
ボディフレームをENUからNEDに変換するときに、mavrosは現在
（xyz）->（x、-y、-z）
（w、x、y、z）->（x、-y、-z、w）なので、
ENU ---> NED
ロール---->ロール
ピッチ----->-ピッチ
ヨー----->-ヨー。
ただし、ヨーがワールドフレームのx軸に基づいており（ボディフレームのxがワールドフレームのxと並んでいる場合、ヨーは0）、90度回転していると誤解していると思います。 したがって、-yaw +1.57を作成する必要があります。 NS
ENU ---> NED
ロール---->ロール
ピッチ----->-ピッチ
ヨー----->-ヨー+1.57。
私がそれを変更した後、mavは正しく飛ぶことができます。 他のプラグインもこんな感じだと思います。

正当なように見えるlocal_positionトピックからのデータは、同じ変換を適用しなくても正しい方向になっていますか？

＃148（共分散変換）もご覧ください。

これも考慮に入れる必要があります。

PR＃317は変換を変更します。

私はこの会話をテストしました

NED（Pixhawk）-> ENU（ROS）
（X、Y、Z）->（X、-Y、-Z）

ENU（ROS）-> NED（Pixhawk）
（X、Y、Z）->（X、-Y、-Z）

これは、rvizと実際のフリングの両方でうまく機能します。

＃317を確認する@supermiceだからありがとう！ :)