Re: Low pass filter on quaternions

Fabian Giesen <[email protected]> Mon, 29 Mar 2010 19:09:46 +0200
Newsgroups gmane.games.devel.algorithms
Message-ID <[email protected]>
On 29.03.2010 17:31, Tom Plunket wrote:
>
>> The problem is that Quaternions are not quite linear enough. Running a
>> naive filter on the axis component when the rotation is close to identity
>> (and the axis component is small) may cause excessive jitter.
>
> Since the rotation is close to zero, though, it doesn't really matter if
> your axis flips all around.  The net result is still one of very little
> rotation.
>
>> I'd also be interested in hearing from anyone who has done this in anger!
>
> Years ago, before I had any idea what quaternions meant, I just did
> IIR-style filtering on them.  You know, "add 10% of this frame's value to
> 90% of the current frame's value, and use that as the new current value."
> Despite the fact that this is horrifying to many purists, it actually
> worked out well for the application I was using it in.  Doing this with
> controller input may lead to an undesirable amount of lag, though.

I don't see any problems with this whatsoever, and don't see why 
"purists" would. Building linear combinations of quaternions (and that's 
what filters do) is a perfectly well-defined and reasonable thing to do. 
You should normalize the result before you use it though - but don't 
feed the normalized output back into IIR filters, use the unnormalized 
value there (or you introduce nonlinearities into the filter).

To be clear, the normalization isn't a hack; it's a perfectly fine 
projection operator, and normalize(w_0*q_0 + w_1*q_1 + ...) behaves 
pretty much like one would expect, except for interpolated paths not 
being constant velocity. But all other parametrizations suffer from 
other and usually more serious limitations that make them a lot less 
suitable for filtering in: spherical linear interpolation yields 
constant velocity but requires you to write linear combination betweeen 
3 or more participants as blend tree, and different ways of building 
this tree yield different results; Euler angles have gimbal lock and the 
interpolation between rotations "a" and "b" doesn't take the shortest 
path between them; taking the log of a and b, interpolating, then 
exponentiating likewise doesn't take the shortest path. The rotation 
group SO(3) is fundamentally non-flat; as a result, there's no "right" 
way to linearize rotations and interpolate/filter them, just different 
ways to get rid of the curvature with different tradeoffs.

And yes, the "axis component" is jittery if your rotation is close to 
identity, but that's perfectly reasonable. A rotation of 1e-5 radians 
around the x axis *is* similar to a rotation of 1e-5 radians around the 
axis (0.8,0.6,0), by any reasonable metric - distance of the resulting 
rotation matrix to the identity matrix in any matrix norm, relative 
error of transformed points, or plain magnitude of the angle. The axis 
for small rotations isn't jittery because of anything to do with the 
quaternion representation, it's jittery because the problem of finding 
the axis of rotation is inherently ill-posed for a transformation that's 
close to identity.

But the quaternion doesn't store (axis, angle), it stores (cos(angle/2), 
sin(angle/2)*axis), and that is perfectly well-behaved near identity.

> When this question was posed, I started wondering how they do it on mouse
> drivers, since there is no apparent lag between me moving the mouse and
> the cursor moving on the screen.  Maybe the solution there is that they
> run at a much higher sample rate?  Maybe the filtering is done in
> hardware?

Mouse driver's dont filter. The only transform applied to the input 
mickeys (=x/y deltas) is pointer ballistics (which, roughly speaking, 
makes slow mouse movements slower and fast movements faster), but 
there's no noise at all in what you get from the hardware. As long as 
the mouse doesn't move, you really do get exactly zero, every frame.

I don't know whether the hardware does any filtering or if the 
mechanisms are inherently noise-resilient (as old mechanical and 
opto-mechanical mice were), but what you get from the hardware via USB 
is already perfectly clean.

-Fabian

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
GDAlgorithms-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list