Hi Keith,
thank you for your quick response!
thank you for your quick response!
>One of the many reasons we discourage the use of the apogee detection
>delay value.
Unfortunately someone at Esrange had the idea to rate the ejection of parachutes an "influence on flight stability".
I agree that this does not necessarily make sense, but I don't make these rules, I only have to stick to them...
This sounds as if apogee lockout would be a easy solution, if those rules actually apply to us (this is not a hundred percent sure yet, and we will certainly not do so if we are allowed to).
>delay value.
Unfortunately someone at Esrange had the idea to rate the ejection of parachutes an "influence on flight stability".
I agree that this does not necessarily make sense, but I don't make these rules, I only have to stick to them...
This sounds as if apogee lockout would be a easy solution, if those rules actually apply to us (this is not a hundred percent sure yet, and we will certainly not do so if we are allowed to).
>TeleMega uses a sensor-fusing Kalman filter to compute height, speed and
>acceleration using both the barometric and acceleration sensors.
Ok, sounds good. But this means the gyro sensor is not involved in apogee computation, right?
Speed is probably computed by integrating acceleration, while apogee will be at the zero point of the first derivative of the acceleration, right?
I guess I should have another look at the code, but I tried before and did not find what I was looking for...I'll have a closer look on it over the holidays :-)
>It automatically transitions from baro+accel to accel-only when speeds
>are high enough that mach effects may cause the baro sensor to report
>inaccurate values, or when the computed height is above the range of the
>barometric sensor.
Very cool!
>We continue to collect and analyse GPS logs from various flights to see
>if there's some way we can reliably incorporate those into the Kalman
>filter. However, the logs we've seen have been very inconsistent, with
>no obvious way to discern 'good' data from 'bad' data.
One other point is that for launch sites at high latitudes GPS is very unreliable due to the GPS satellites only having 55° inclination. Just saying...
>acceleration using both the barometric and acceleration sensors.
Ok, sounds good. But this means the gyro sensor is not involved in apogee computation, right?
Speed is probably computed by integrating acceleration, while apogee will be at the zero point of the first derivative of the acceleration, right?
I guess I should have another look at the code, but I tried before and did not find what I was looking for...I'll have a closer look on it over the holidays :-)
>It automatically transitions from baro+accel to accel-only when speeds
>are high enough that mach effects may cause the baro sensor to report
>inaccurate values, or when the computed height is above the range of the
>barometric sensor.
Very cool!
>We continue to collect and analyse GPS logs from various flights to see
>if there's some way we can reliably incorporate those into the Kalman
>filter. However, the logs we've seen have been very inconsistent, with
>no obvious way to discern 'good' data from 'bad' data.
One other point is that for launch sites at high latitudes GPS is very unreliable due to the GPS satellites only having 55° inclination. Just saying...
73s,
Andreas
Andreas
_______________________________________________ altusmetrum mailing list [email protected] http://lists.gag.com/mailman/listinfo/altusmetrum
