77
edits
Changes
Jump to navigation
Jump to search
Line 59:
Line 59: + + + + + + + + + + + +
no edit summary
The difference equation used for spaghetti is called a [https://en.wikipedia.org/wiki/Digital_biquad_filter biquad filter]. This forms a 2nd order difference equation, as it uses the last two inputs and outputs. With a biquad, we can place two poles and two zeros anywhere we want in the s-plane.
The difference equation used for spaghetti is called a [https://en.wikipedia.org/wiki/Digital_biquad_filter biquad filter]. This forms a 2nd order difference equation, as it uses the last two inputs and outputs. With a biquad, we can place two poles and two zeros anywhere we want in the s-plane.
=== Fused ascent rate estimation ===
Another thing that spaghetti implements is an estimation of ascent rate to prevent overacting when it is far away from the setpoint. "Ascent rate" for valbal is actually a tricky measurement though, because at any given time, the true ascent rate is not particularly important. The reason for this being that valbal may rise and fall with turbulence, which isn't something we really care about. Instead, we want to estimate the component of the ascent rate that is due to lift.
There are numerous way's this can be achieved, but an extremely simply method is to just lowpass filter the altitude measurements and take the derivative. Averaging works as a low pass filter, but the buffer size that you would need is too way to large unless you downsample the data, which isn't ideal. Averaging also has a few other downsides. A better way to lowpass filter in this application is to create a 2nd order lowpass filter using a biquad. This smooths out the data for us, so that when we take the derivative it will be less noisy.
However, a problem arises. Any causal lowpass filter will have what is called group delay. This means that things sent through the filter will be delayed. This is intuitive, and the same thing happens with a running average as the output responds kind of slowly to the input, and is how it reduces the noise. This becomes a problem, especially when blasting or venting which will cause sudden changes in ascent rate. If our ascent rate estimate takes too long to respond, then we can't prevent overshoots.
How do we fix this? We can add in the information that we just ballasted to our filter. The optimal way to do so would be with some gaussian distribution math, through a kalman filter. However, picking variances for this can be very handwavy, and the end result may just be an over engineered lowpass filter. So instead, w do something simpler. we want to add in the equivalent ascent rate change that we would expect from our ballasting action, but then have this amount that we added in to decay over time to zero as we know our filtered ascent rate will eventually catch up. How can we do this? Well, exponential decay like this is exactly the behavior we would get from the impulse response of a first order LTI system with a single pole on the negative real axis. We can produce this with another recurrence relation, similar to the filter. The final estimate is simply the sum of these two.
As for how to actually pick values for the filter, like quality factor and cutoff frequency, we just "play" with old data and see what works well. Same goes for the rate of exponential decay for the estimate.
=== If you think controls are cool and wanna learn more ===
=== If you think controls are cool and wanna learn more ===