My AI car has trouble turning around, and I believe it is due to the gimbal lock, with the FindLookAtRotation snapping between 180 and -180. been looking for a solution for a day. heres a video showing whats happening, and a picture of my logic. Any help would be much appreciated.
My AI car has trouble turning around, and I believe it is due to the gimbal lock, with the FindLookAtRotation snapping between 180 and -180. been looking for a solution for a day. heres a video showing whats happening, and a picture of my logic. Any help would be much appreciated.
Actually, your vid looks fine.
Many questions:
-
How is Target Loc calculated
-
Why are you subtracting the forward vector?
-
Is -90 to 90 defintely the input range?
- The target location is the point on the map. In the video, it is behind the AI, and the issue is that the AI cant turn around to it.
- Because thats what the funny man in the youtube video told me to do (im not so good with maths)
- No, its -180 to 180. Heres a video attached of what the output of FindLookatRotation looks like, which is what I think the problem is:
You’re never going to be able to turn, because you’re knocking it back to 90.
How about
What’s in ‘set steering input’?
Set Steering input is a function for the wheeled vehicle movement component. Takes in a float value of -1 to 1 and turns the wheels according to it, -1 being left, 0 being none, and 1 being right.
Also im not sure what you mean when you say it wont be able to turn? turns fine as long as its not going in that direction (again making me believe this is a gimbal lock problem)
Can you try the bit of code I put up there, but set the range clamp to -180 to +180, how does that do?
Sadly, it seems to have no effect. Same thing still happens.
I want to post the solution here, in case anyone else runs into this. The solution is to not use Find Look at Rotation. Instead, I got the dot product from the right, left, and forward vectors to the point, and determined the turning direction based off those. Works great!
1 Like
Just noting that it will work with ‘look at’, also.
1 Like
But it doesnt. Look at Rotation experiences gimbal lock. There is no way around it.
It’s just a different way of using it. I have coded full 360 turning systems, only in Z, with ‘look at’. Just sayin’… 
Would you mind sharing your solution then?
I think there are many. There’s nothing intrinsically wrong with ‘look at’. It’s what people do with the output.
If ‘look at’ suffered from gimbal, this wouldn’t work ( it would snap by 180 )
Not true at all. This works because the rotation is euler. It is snapping between 180 and -180, but you dont notice it because the actor spins on an axis of 180 to -180. It does not work in my case because im am not trying to turn or set an actors location.
But that is exactly how it is supposed to work. 
Doubt it… the function just gets a direction vector and from it calculates pitch and yaw in relation to the worlds X+. It does not calculate the roll (you need 3 axis for gimbal lock).
If what you are after is awareness: you dont need to calculate left nor turn it to degrees. If dot with right vector is negative, then its on the left:
Hope it helps.
2 Likes
Your solution is certainly interesting. Also maybe it doesnt experience gimbal lock, maybe thats the wrong term for this, but the snapping was an issue for me.
Could you please expand the math expression? What is front cone?
The math expression node is really just what is typed there. The node does the rest on the inside:
What ((Acos(FrontCone)) * (180 / (PI()))) * 0.500000 is doing is converting FrontCone to radians, then to degrees and finally diving it by 2 to get the radius of the debug cone.
The math expression is exactly the same as this:
FrontCone is a float variable with a default value of 0.9 so that when comparing against dot product, anything greater than FrontCone will be considered to be in front as it is in the shared bp:
