Mavros: Réitérer les conversions de trames entre NED et ENU

Peut-être que quelqu'un peut commenter l'état actuel ? Je manque de temps pour passer au crible le code actuellement, mais je serais heureux de revoir les transformations.

@LorenzMeier Voir PR # 208.

@LorenzMeier En fait, c'est la convention actuelle que nous utilisons :

NED fixe → ROS ENU : (xyz)→(x -y -z) ou (wxyz)→(x -y -zw)
local NED → ROS ENU : (xyz)→(yx -z) ou (wxyz)→(yx -zw)

Je ne peux pas vérifier l'exactitude de ce diagramme, mais c'est ce que je pense que nous faisons maintenant.

Oui c'est mon schéma. Je peux le confirmer, et je l'ai utilisé et expliqué sur ma thèse.

Note : Cette conversion est ce que nous avons convenu il y a quelques mois et j'ai pu la confirmer sur Rviz.

Le problème n'est pas la conversion réelle, mais plutôt l'utilisation d'une certaine conversion.

je regarde ça :
http://wiki.ros.org/geometry/CoordinateFrameConventions et
http://www.ros.org/reps/rep-0103.html

Il y a un certain nombre de problèmes avec le graphique (et s'il représente l'orientation, le code) :

• ROS est toujours droitier. Le graphique ENU (rangée du bas) est gaucher, ce qui n'est pas correct.
• ROS utilise ENU. ENU signifie est-nord-haut, donc l'axe X pointe vers l' EST et le cap zéro degré est le long de l'axe Y .

Par conséquent, il n'y a pas de différence entre la trame corporelle et la trame mondiale à rotation zéro, et la conversion entre NED et ENU est la même pour les deux trames, en utilisant respectivement la référence globale/locale.

Je suis principalement d'accord avec ce que @LorenzMeier a dit. Cependant, à moins que je ne me trompe, chaque cadre de coordonnées dans le graphique ci-dessus, à l'exception de celui en bas à droite, est un système de coordonnées gaucher. Peut-être avez-vous mal étiqueté les axes x et y dans la légende des graphiques ?

En dehors de cela, je suis d'accord pour dire que la conversion de ENU en NED est la même, que ce soit pour le châssis au sol ou le châssis. Sur le cadre du corps, le nom ENU ou NED n'a pas beaucoup de sens, mais la conversion du cadre de coordonnées utilisé dans ROS en FCU devrait toujours être le même, je pense.

Je n'ai pas encore vérifié la méthode de conversion que @mhkabir a publiée ci-dessus. Je pense que nous devons d'abord obtenir le bon graphique avant de faire le calcul

@thedinuka Cela vous genre , selon ce qui vous semble correct. ;)

J'ai le fichier d'origine, je peux le modifier puis en envoyer un nouveau (pas besoin d'utiliser de la peinture @mhkabir). La chose à propos de la main droite et de la main gauche semble juste. Mais j'ai encore des doutes par rapport au fait d'avoir deux conversions différentes, et quand j'ai fait cette image cette fois-là, je les avais aussi. Nous devons donc probablement vérifier le code, car d'après mes souvenirs, la plupart des implémentations utilisent les conversions ci-dessus.

En attendant la version modifiée du graphique par @TSC21 , j'y ai réfléchi un peu plus et cela semble plus compliqué que je ne le pensais au départ. Je suis plutôt d'accord avec @TSC21. Il y a deux paires différentes de transformations de coordonnées auxquelles nous devons penser.

1) Transformation de la convention ROS du cadre fixe du corps à la convention Pixhawk du cadre fixe du corps.
2) Passer de la convention ROS du cadre fixe à la Terre à la convention Pixhawk du cadre fixe à la terre.

Bien qu'il existe de la documentation à la fois du côté ROS et du côté Pixhawk sur la convention utilisée pour le cadre de coordonnées fixé au corps, je n'ai pas pu trouver d'informations spécifiques sur la convention utilisée du côté Pixhawk sur le cadre de coordonnées inertielle (ou fixe terrestre). Si je devais faire une supposition, je dirais que du côté de Pixhawk, en l'absence de GPS, le cadre de coordonnées Earth Fixed s'aligne sur l'orientation initiale du cadre fixe du corps, mais je ne suis pas sûr à 100% si c'est le cas. Donc, pour éviter toute erreur et confusion, je vais, pour l'instant, ne considérer que le châssis fixe du corps.

En m'appuyant sur la documentation [1] pour ROS et [2] pour Pixhawk, j'ai réalisé le schéma suivant.

Une fois que nous avons vérifié, confirmé et accepté les diagrammes du cadre de coordonnées pour (1) et (2) ci-dessus, les calculs pour effectuer les transformations réelles du côté mavros sont très simples.

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

Veuillez également consulter #148 (conversion de covariation).

Cela peut aider ros-infrastructure/rep#95

Avons-nous fini par arriver quelque part avec ça? Les conversions actuelles des cadres ENU/NED, corps/monde sont-elles correctes ? Je pose cette question car nous devons répéter la possibilité que
@vooon , @mhkabir , @tonybaltovski , @thedinuka ping !

@thedinuka Ça me va bien.

Si je devais faire une supposition, je dirais que du côté de Pixhawk, en l'absence de > GPS, le cadre de coordonnées Earth Fixed s'aligne sur l'orientation initiale du > cadre fixe du corps

En fait, pas besoin de GPS. Nous avons déjà une référence mondiale en lacet du mag. Cela devrait signifier une rotation du cadre EF à l'aide de ce lacet.

Salut,
Je remapper le sujet de mocap_optitrack à vision_pose/pose dans mavros. cependant le mav ne peut pas voler correctement, donc je change le code suivant
vision_position_estimate(stamp.toNSec() / 1000,
position.y(), position.x(), -position.z(),
roulis, -tangage, -lacet); // ??? Vérifiez s'il vous plaît!
à
vision_position_estimate(stamp.toNSec() / 1000,
position.y(), position.x(), -position.z(),
roulis, -tangage, -lacet + 1,57) );
c'est-à-dire changer -yaw en -yaw + 1,57.
lors de la conversion du cadre du corps de ENU à NED, mavros utilise désormais
(xyz)-->(x,-y,-z)
(w,x,y,z)-->(x,-y,-z,w), donc on obtient
ENU ---> NED
rouler ----> rouler
pas ----->-pas
lacet ----->-lacet.
Cependant, je pense que nous nous trompons sur le fait que le lacet est basé sur l'axe x dans le cadre du monde (lorsque x dans le cadre du corps est avec x dans le cadre du monde, le lacet est égal à 0) et a une rotation de 90 degrés. nous devrions donc faire -yaw + 1,57. c'est à dire
ENU ---> NED
rouler ----> rouler
pas ----->-pas
lacet ----->-lacet+1,57.
après l'avoir changé, le mav peut voler correctement. donc je pense que d'autres plugins sont aussi comme ça.

@congleetea qui semble légitime. Pouvez-vous s'il vous plaît appliquer les mêmes transformations aux plugins de point de consigne et voir quel est le résultat ? De plus, les données provenant du sujet local_position sont-elles correctement orientées sans que vous appliquiez la même conversion ?

Veuillez également consulter #148 (conversion de covariation).

Nous devons également en tenir compte.

Le PR n°317 modifie les conversions.

j'ai testé cette conversation

NED(Pixhawk)->ENU(ROS)
(X,Y,Z)->(X,-Y,-Z)

ENU(ROS)->NED(Pixhawk)
(X,Y,Z)->(X,-Y,-Z)

Cela fonctionne bien à la fois en rviz et en vraie aventure.

@supermice qui confirme #317 alors merci ! :)