I have a flying quad rotor vehicle that is flying preset path points. This is a simulation and is coded to fly using applied forces and torque just as it would in real life. That means that I can’t just rotate the object, I have to apply a force to cause the rotation.

What I’m trying to wrap my head around is how to control Yaw direction. If I set it to look at a single point, then fly a loop around the point (essentially strafing sideways around the point), using euler y angles causes it to go crazy when it goes from -180 to 180.

If there is a better way to do it than what I’m doing let me know as I’m new to this. The only constraint is that it would also have to apply to a real life coded quad rotor so I can’t use any game coding tricks to get the result.

**EDIT:**

Consider the diagram below. If the quad rotor is fixed to rotate on 0,0 it will rotate 120 degrees to get to Target 1. If it continues to rotate to Target 2 it will cross 180/-180 which will cause the motor outputs to want to spin it counterclockwise to count down from 180 to -180, rather than just make a smooth jump from 180 to -180. What’s the best practice in dealing with this?

I hope that makes a bit more sense.

Dynamics modeling should, wherever possible, avoid reliance on Euler rotations. This sounds like a manifestation of gimbal lock, which is the most egregious problem associated with reliance on Euler angles to inform decisions or drive motion.

Using a signed or unsigned angle to make certain decisions is perfectly valid, but typically this is dissociated from the mechanical workings of the vehicle. In other words, you might decide to turn right or left based on a euler angle measurement, but physically acting on that decision should be abstracted to bypass the dreaded gimbal lock phenomenon.

Without an intimate understanding of your situation and desired outcome, it’s difficult to give more specific advice. Attempting to model complex behaviors is a tall order without experience working with vector math and quaternion operations.

The best advice I can come up with here is to eliminate as many instances of reliance on Euler angles as you possibly can, especially when it comes to driving the actuators of your vehicle. The problem you need to address is: *The vehicle and input logic should never care whether its y rotation crosses the 180 degree threshold.*

Such stipulations can always be achieved with sufficient experience with vector /quaternion math. Unfortunately this is a topic which is typically best learned “the hard way” though much trial and error. Dig into the Vector3 and Quaternion documentation; have a good look at what options are available. *You need to come up with an alternative method of using your knowns to find your unknowns.*

I know this isn’t what you want to hear, but it’s the best advice I could come up with. Bypassing gimbal lock is a complicated topic, as are the maths associated with modelling 3D simulations, but there’s no “right answer” to this issue that doesn’t involve circumventing the problems with Euler-described rotation.

Best,