Low Pass filter - alternatives to using Lerp?

Hi
Need a simple low pass filter to filter a single float input. A quick search seems to indicate that Lerp is used for most solutions
ie
https://answers.unity.com/questions/865817/how-to-implement-a-low-pass-filter-for-acceleromet.html

Is there a 'better' approach that introduces less lag or latency?

 

So I'm assuming you're wanting to apply a low pass filter to level out sudden jerks in the accelerometer right?

Becuase this is what an accelerometer low pass filter should do... it eases/lerps the values towards the current acceleration so that if it was a sudden jerk... that jerk doesn't effect so much if it gets jerked back... and only effects it if the acceleration holds over a period of time.

This over time factor is what allows you to soften out the acceleration and make it less jerky.

The 't' value you pass into lerp...
the lower it is (closer to 0) the smoother but more delayed the motion (as you approach 0 you'll end up with no change in acceleration though).
The higher it is (closer to 1) the jerkier but less delayed the motion (as you approach 1 you're effectively turning off the low-pass filter).

You can't have no delay and smooth motion... You're compromising latency to get smoothness.

...

Instead of asking how to get a thing that's not that thing.

How about instead what is it you're attempting to accomplish with your low-pass filter?

 

Thanks. yes to remove the 'spikes' in incoming data (from a sensor). Would populating and average an array be any different performance wise than using a Lerp function?

 

For starters... lerp is just this equation:

Code (csharp):

1. public static float Lerp(float a, float b, float t) { return (b - a) * t + a; }

(well, technically the unity one also clamps t... that's just a quark of unity)

It acts on 2 floats.

If you have an array of the history some things come up.
1) it'll take more memory
2) it'll take more work to move values in and out of that memory
3) you'll be averaging a set of values as opposed to just 2 values meaning again more work

All of it is more work. Sure it's technically a small amount of work, but it is fundamentally more work.

So therefore it'll be less performant.

And with that said... it won't change the 'latency'. Heck, it'd probably impact it even further since you're not damping it from the last value, but the last set of values. All depending on how you treat that history. Is it an average of the history? Is it a lerp historically through the history?

Imagine if use a coefficient of 0.5.
And you have a history of [0,0.1, 0.2] and an incoming of a spike to 1.

In the lerp scenario you get lerp(0.2, 1, 0.5) = 0.6
In the historical scenario, averaged = 0.325 (more lag)
In the historical scenario, lerped by coef through history = 0 -> 0.1 = 0.05 -> 0.2 = 0.125 -> 1 = 0.5625 (more lag)

So... history is more work, and it introduces more lag.

Note this will also happen decelarating too. You'll hold onto significant acceleration for longer. Meaning that'll be harder to slow down.

 

Here's the thing.

Spikes occur because unpredicted erratic information is being picked up in real time.

The entire point of a low-pass filter is to lessen spikes by damping the impact of the spikes if they only occur for a very short period of time. But to allow them through if they are significant over a duration of time.

This is inherently laggy.

You're using historical information (the previous acceleration) to pull back on the spike in acceleration.

If you want to have the most up to date information, while ignoring erratic information... you'd essentially need to be able to predict the future!

You're effectively asking to have your cake and eat it too. You can't use latency to smooth out something, and not have latency at the same time.

 

You also have Mathf.LerpUnclamped, just pointing it out.

 

Yes, that's not Mathf.Lerp though, was my point.