Ángulos de Euler versus Cuaterniones: ¿problemas causados ??por la tensión entre el almacenamiento interno y la presentación al usuario?

Question

Los cuaterniones son posiblemente una opción apropiada para representar rotaciones de objetos internamente. Son simples y eficientes para interpolar y representan una orientación única sin ambigüedades.

Sin embargo, presentar cuaterniones en la interfaz de usuario es generalmente inapropiado: los ángulos de Euler son generalmente mucho más familiares para los usuarios, y sus valores son un poco más intuitivos y predecibles.

Los ángulos de Euler se complican a nivel de código: requieren que se almacene un orden de rotación, y componer una orientación práctica (ya sea matriz o cuaternión) usando este orden y los ángulos asociados es engorroso, por decir lo menos.

Las interpolaciones confiables se realizan de manera más conveniente utilizando la representación de cuaternión, entonces, ¿significa esto que debemos convertir constantemente entre una representación de Euler y una representación de cuaternión? ¿Es esto factible en términos de rendimiento?

¿Podemos almacenar las orientaciones como cuaterniones y convertirlas solo para mostrarlas al usuario? Esto puede no ser posible porque para cualquier orientación dada hay exactamente una representación cuaternión pero muchas representaciones de Euler. ¿Cómo 'seleccionamos' la representación de Euler que corresponde a la que originalmente definió esa orientación? Parece una tarea imposible: efectivamente hemos perdido información al convertir a un cuaternión.

¿Podríamos almacenar como ángulos de Euler y luego convertirlos a cuaterniones según sea necesario? Esto probablemente no sea escalable: la conversión de un ángulo de Euler a un cuaternión, la interpolación y luego la conversión de nuevo probablemente sea un código relativamente costoso.

¿Podríamos simplemente almacenar ambas representaciones y usar la más adecuada para cualquier situación? Un gran costo en términos de memoria (imagine curvas de animación para un esqueleto con alrededor de sesenta huesos) y mantener estos valores sincronizados podría ser costoso o al menos engorroso.

¿Alguien ha visto, usado o pensado alguna solución inteligente para este problema? ¿Seguramente las tres opciones anteriores no son las únicas? ¿Hay algún otro dominio de problema similar a este que se haya resuelto ?

Answer 1

Soy ingeniero aeroespacial; He estado usando quaternions para el control de actitud y navegación de la nave espacial durante tres décadas. Aquí hay algunos pensamientos sobre su situación:

1. Realizar cualquier tipo de proceso que cambie la orientación con los ángulos de Euler es casi imposible. Los ángulos de Euler sufren de singularidades: los ángulos cambiarán instantáneamente hasta 180 grados a medida que otros ángulos atraviesen la singularidad; Los ángulos de Euler son prácticamente imposibles de usar para rotaciones secuenciales. Los cuaterniones no sufren ninguno de estos problemas
2. Hay 12 secuencias de rotación de ángulo de Euler diferentes posibles: XYZ, XYX, XZY, etc. No hay nadie "más simple". o "derecha" Conjunto de ángulos de Euler. Para derivar un conjunto de ángulos de Euler, debe saber qué secuencia de rotación está utilizando y atenerse a ella.
3. Le sugiero que realice todas las operaciones de almacenamiento y rotación con cuaterniones y solo convierta un cuaternión en ángulos de Euler cuando se requiera la salida. Cuando haga esto, debe definir qué secuencia de rotación de Euler está utilizando.

Tengo algoritmos para todas estas operaciones y muchas más: cuaterniones hacia / desde ángulos de Euler de cualquier secuencia de rotación hacia / desde matrices de rotación (matrices de coseno de dirección), posición de coincidencia de interpolación de cuaternión, velocidad, etc. en los puntos finales o intermedios, Dinámica del cuerpo rígida y flexible y cinemática con cuaterniones.

Contácteme si puedo ayudarlo en nhughes1ster@gmail.com

Answer 2

Soy fanático de los cuaterniones. Para que funcionen, ¿podría reconsiderar su presentación al usuario? En lugar de presentar la rotación al usuario como una serie de ángulos de Euler en forma de texto, puede elegir un objeto 3D simple y aplicar la rotación del cuaternión al objeto para mostrar visualmente la rotación vigente.

Answer 3

¿Por qué no usar Quaternions en el código y convertir la Q a ángeles cuando sea necesario para mostrar?

Answer 4

Puede representar la rotación como eje + ángulo de rotación, que es esencialmente lo mismo que quaternion (hasta un signo)

Answer 5

No creo que tenga sentido usar los ángulos de Euler internamente; querrá usar los cuaterniones para todos sus cálculos y, por lo general, no podrá permitirse las conversiones que ocurren en todas partes. En cuanto a la conversión de nuevo a los ángulos de Euler para la interfaz de usuario, ¿sería tan malo si el usuario solo obtiene un ángulo que es equivalente a la entrada original pero se representa de manera diferente? Si realiza la conversión correctamente, debería terminar con el "más simple" Ángulos de Euler para cualquier cuaternión dado.

Answer 6

¿De cuántas conversiones estamos hablando? Parece que está pagando por aproximadamente dos operaciones trascendentales por conversión, que en el hardware moderno está disponible en el orden de 100 millones por segundo. Guardaría ambos, Quaternions para precisión y estética y rotaciones de euler para preservar la información del usuario. Quizás agregue una bandera para indicar cuál es el preferido para cualquier objeto dado. Además de eso, solo tiene que realizar la conversión una vez por miembro rotado. Una vez que ha calculado una matriz de transformación, su suma múltiple hasta que se quede sin vértices.