Mavros: Reiterar las conversiones de tramas entre NED y ENU

¿Quizás alguien pueda comentar sobre el estado actual? Actualmente no tengo tiempo para examinar el código, pero me complacerá revisar las transformaciones.

@LorenzMeier Ver PR # 208.

@LorenzMeier En realidad, esta es la convención actual que usamos:

NED fijo en el cuerpo → ROS ENU: (xyz) → (x -y -z) o (wxyz) → (x -y -zw)
NED local → ROS ENU: (xyz) → (yx -z) o (wxyz) → (yx -zw)

No puedo verificar la exactitud de este diagrama, pero creo que esto es lo que estamos haciendo ahora.

Sí, ese es mi plan. Puedo confirmarlo, lo usé y expliqué en mi tesis.

Nota: Esta conversión es la que acordamos hace unos meses y pude confirmarla en Rviz.

El problema no es la conversión real, sino más bien cuándo se utiliza una determinada conversión.

Estoy mirando esto:
http://wiki.ros.org/geometry/CoordinateFrameConventions y
http://www.ros.org/reps/rep-0103.html

Hay una serie de problemas con el gráfico (y si representa la orientación, el código):

• ROS siempre es diestro. El gráfico ENU (fila inferior) es para zurdos, lo cual no es correcto.
• ROS está usando ENU. ENU significa este-norte-arriba, por lo que el eje X apunta al ESTE y el rumbo de cero grados está a lo largo del eje Y.

En consecuencia, no hay diferencia entre el marco del cuerpo y el marco mundial en rotación cero, y la conversión entre NED y ENU es la misma para ambos marcos, utilizando la referencia global / local, respectivamente.

Estoy mayormente de acuerdo con lo que ha dicho @LorenzMeier . Sin embargo, a menos que esté muy equivocado, cada cuadro de coordenadas en el gráfico anterior, excepto el de abajo a la derecha, es un sistema de coordenadas para zurdos. ¿Quizás etiquetó incorrectamente los ejes xey en la leyenda de los gráficos?

Aparte de eso, estoy de acuerdo en que la conversión de ENU a NED es la misma, ya sea para el bastidor del suelo o el bastidor de la carrocería. En el marco del cuerpo, el nombre ENU o NED no tiene mucho sentido, pero aún así, la conversión del marco de coordenadas utilizado en ROS a FCU debería ser siempre el mismo, creo.

Todavía no he comprobado el método de conversión que @mhkabir publicó anteriormente. Creo que primero tenemos que hacer bien el gráfico antes de hacer los cálculos.

@thedinuka ¿Te importaría preparar uno nuevo en Paint o algo así, de acuerdo con lo que te parezca correcto? ;)

Tengo el archivo original, puedo cambiarlo y luego enviar uno nuevo (no es necesario usar paint @mhkabir). Lo que pasa con la mano derecha y la izquierda parece correcto. Pero todavía tengo dudas en relación con tener dos conversiones diferentes, y cuando hice esa imagen esa vez, también las estaba teniendo. Entonces, probablemente necesitemos verificar el código, porque por lo que recuerdo, la mayoría de las implementaciones usan las conversiones anteriores.

Mientras esperaba la versión modificada del gráfico por @ TSC21 , pensé un poco más en esto y parece más complicado de lo que pensé inicialmente. Estoy de acuerdo con @ TSC21. Hay dos pares diferentes de transformaciones de coordenadas en las que debemos pensar.

1) Transformación de la convención ROS de marco fijo al cuerpo a la convención Pixhawk de marco fijo al cuerpo.
2) Transformación de la convención ROS del marco fijo en la Tierra a la convención Pixhawk del marco fijo en la tierra.

Si bien hay documentación tanto en el lado ROS como en el lado Pixhawk sobre la convención utilizada para el marco de coordenadas fijo del cuerpo, no pude encontrar información específica sobre la convención utilizada en el lado Pixhawk sobre el marco de coordenadas inercial (o fijo de la Tierra). Si tuviera que adivinar, diría que en el lado de Pixhawk, en ausencia de GPS, el marco de coordenadas fijo de la Tierra se alinea con la orientación inicial del marco fijo del cuerpo, pero no estoy 100% seguro de si este es el caso. Entonces, para evitar errores y confusiones, por ahora solo consideraré el marco fijo de la carrocería.

Basándome en la documentación [1] para ROS y [2] para Pixhawk, he realizado el siguiente diagrama.

Una vez que tenemos los diagramas de marco de coordenadas para (1) y (2) arriba verificados, confirmados y acordados, entonces las matemáticas para hacer las transformaciones reales en el lado de mavros son muy sencillas.

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

Consulte también el n. ° 148 (conversión de covariación).

Esto puede ayudar a ros-Infrastructure / rep # 95

¿Terminamos llegando a algún lado con esto? ¿Son correctas las conversiones actuales de ENU / NED, body / world frames? Estoy preguntando esto porque necesitamos iterar la posibilidad de que @blackcoder esté obteniendo una rotación de guiñada en la FCU al enviar los datos de visión porque estamos haciendo las cosas mal.
¡@vooon , @mhkabir , @tonybaltovski , @thedinuka ping!

@thedinuka Me parece bien.

Si tuviera que adivinar, diría que en el lado de Pixhawk, en ausencia de GPS, el marco de coordenadas fijo de la Tierra se alinea con la orientación inicial del marco fijo del cuerpo.

En realidad, no necesito GPS. Ya tenemos una referencia de guiñada global de la revista. Eso debería significar que el marco EF girado usando esta guiñada.

Hola,
Reasigyo el tema de mocap_optitrack a vision_pose / pose en mavros. sin embargo, el mav no puede volar correctamente, así que cambio el siguiente código
vision_position_estimate (sello.toNSec () / 1000,
position.y (), position.x (), -position.z (),
roll, -pitch, -yaw); // ??? ¡por favor, compruebe!
para
vision_position_estimate (sello.toNSec () / 1000,
position.y (), position.x (), -position.z (),
rollo, -pitch, -yaw + 1,57);
es decir, cambie -yaw por -yaw + 1.57.
al conversar la estructura de la carrocería de ENU a NED, los mavros ahora usan
(xyz) -> (x, -y, -z)
(w, x, y, z) -> (x, -y, -z, w), así que obtenemos
ENU ---> NED
rodar ----> rodar
tono -----> - tono
guiñada -----> - guiñada.
sin embargo, creo que nos equivocamos de que la guiñada se basa en el eje x en el marco del mundo (cuando x en el marco del cuerpo está junto con x en el marco del mundo, la guiñada es 0) y tiene una rotación de 90 grados. entonces deberíamos hacer -yaw + 1.57. es decir
ENU ---> NED
rodar ----> rodar
tono -----> - tono
guiñada -----> - guiñada + 1,57.
después de cambiarlo, el mav puede volar correctamente. así que creo que otros complementos también son así.

@congleetea que parece legítimo. ¿Puede aplicar las mismas transformaciones a los complementos de puntos de ajuste y ver cuál es el resultado? Además, ¿los datos que provienen del tema local_position vienen con la orientación correcta sin que aplique la misma conversión?

Consulte también el n. ° 148 (conversión de covariación).

También debemos tener esto en cuenta.

PR # 317 cambio de conversiones.

He probado esta conversación

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

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

Eso funciona bien tanto en rviz como en real fling.

@supermice que confirma el # 317 ¡así que gracias! :)