koobas.hobune.stream
Quad rotor simulation spin between 180/-180
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.
Not enough information. Although I think this has the makings of a good question, if you had the jargon to describe it more sensibly. As it stands, we really need diagrams, videos, screenshots - something to better convey what you're attempting to communicate. The question's title itself conveys nothing helpful; it reads like nonsense and will likely be overlooked. Something like "physically realistic quad-copter orientation problem" would snare my interest!
In short, the problem you are encountering is one that is only manifesting because you're co$$anonymous$$g at this problem from the wrong direction. Pun intended! Strong, robust dynamics modeling probably shouldn't care about "euler" anything in this specific application.
Once you learn to leverage the power of vector math and better understand how to work with quaternions, this and similar problems will disappear.
In the mean time, please consider creating some diagrams to showcase what you're trying to say; maybe some code; I don't have a clear enough picture of the problem to offer any immediate advice.
I will update the question with a better description and diagram.
I was just looking into quaternions so hopefully that will help. Quad rotor gyroscopic outputs are typically in quaternions but are also converted to euler angles in some cases which is what I was trying to use.
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,
Ah I see, thank you!
I wasn't sure if there was a common solution to this but now that I know there isn't I will get researching to find an answer.
That is where my original question came into play. To use the above diagram, my logic was that if the y axis was fixed with zero pointing to the quad rotor's forward(z axis), it would always be at zero no matter what angle it is at in world space. So it would rotate 120 degrees to Target 1, then another 120 degrees to target 2, but could never pass 180 because it would always be behind it. Rotating would then be translated to force based on reducing the angle between zero and 120 rather than expanding the angle from 0 to 120 as it does without the y being fixed to the quad rotor.
I'm not sure if that makes sense lol. I'm not the best at explaining things.
What you've described isn't "wrong" exactly. The logic you've described in that comment should be achieved by finding the signed angle between the object's forward and the "desired" forward (which is a vector pointing from the vehicle to the target).
Then, the signed angle will be between 180 and -180 degrees. Nothing wrong with that. Either you are not achieving what you think you're achieving, (Debug.Log and Debug.DrawLine are invaluable...) or the problem lies elsewhere.
Using euler stuff for measurements is perfectly fine, provided you are aware of and can account for all the fiddly problems that can arise from describing an orientation in this way. It's a big bad scary topic, but once you wrap your head around what options are available for arriving at your unknowns, you'll be writing stronger, cleaner code.
