Fix issue with angle wrap-around

[rengels]

The 0.8 factor was sub-optimal.

Let's assume an angular velocity of 0.32PI per calls of update.
Then a wrap-around will produce a change of 2PI - 0.32PI, that's 0.7*2PI
So it won't be detected as a wrap-around of the angle at all and
thus the number of full rotations will be off, as will be the
velocity.

The perfect number is 0.5.

[runger1101001]

This has been something I have noticed for a while, and has been bothering me also. Thanks for reporting it!

I agree with your conclusion that the best check would be for 0.5 x 2PI, or just PI radians of difference.
But I don’t agree with your maths: 0.32PI rad/update would result in a difference of 1.68xPI, which is > 2PI x 0.8, so would still be detected as a wrap-around.

I also don’t think it’s a real-world problem, TBH, since following your example, assuming we have a very slow update frequency of only 1kHz, then 0.32PI rad/update would mean a real world speed of 320PI rad/s, > 9000RPM. But going 9000RPM with only 1kHz update rate is a very unreasonable expectation, it won’t happen IRL…

So to reach such speeds you’d expect maybe 30kHz or at least 10kHz update rate, in which case you’ll be far from the 0.32PI rad/update again…

So I think this topic is only a theoretical problem, not a real one. If you’re coming close to missing the wrap-around, then it’s your iteration speed that needs to improve, not the 0.8 vs 0.5 factor….

[rengels]

Thanks for the fast feedback and sorry, there were some spaces missing:
"
Let's assume an angular velocity of 0.3 * 2PI per calls of update.
Then a wrap-around will produce a change of 2PI - 0.3 * 2PI, that's 0.7 * 2PI
"

I understand your point, and it's correct. In real world it's unlikely to be noticed.
On the other hand it's a wrong, unexplained magic number. So why not fix it.