Kalman Filter Question

[watheyak]

I've had a fair bit of success putting altimeters in nosecones. In those cases it was a Featherweight Raven with the static ports near the base of the nosecone. Now I would like to move the altimeter farther forward, as far forward as it will go into the tip of the nosecone. In this scenario the static port(s) will be angled into the relative wind causing ram air to increase the pressure inside the av-bay as velocity increases.

In my limited understanding of how a Kalman filter works, would it still be able to prevent untimely deployment if the accelerometer is showing increasing velocity but the barometric sensor is showing increasing pressure (descent) during the boost phase? As I understand it, this situation would not agree with the predictive model so the baro sensor would be ignored until everything made sense. Would my assumption hold true if the velocity during boost reaches Mach 3+ and possibly exceeds the high pressure limit on the baro sensor?

I have read David Schultz' paper here https://home.earthlink.net/~david.schultz/rnd/2004/KalmanApogeeII.pdf paying attention to the Error Summary section. It doesn't exactly address sensor disagreement at opposite extremes as would be in this case.

The candidates for altimeters in this situation are a Telemetrum, AIM XTRA, or a Raven 3/Beeline GPS, in that order. There are many other great candidates but they wont fit.

This subject has been discussed quite a bit here on TRF and elsewhere, but I would like to continue further since none of the other discussions deal with this particular placement or this velocity. I'd also feel much more comfortable about this decision with some help and input from the world at large here on TRF.

Thanks

 

[mikec]

The Raven doesn't use a Kalman filter anyway. I would avoid this scenario if at all possible, but if you have to do it, I would use accelerometer apogee instead of barometic, assuming your Raven has a well-behaved accelerometer.

I have no idea what a Telemetrum would do in this situation.

 

[watheyak]

The Raven doesn't use a Kalman filter anyway.

Oh that's right. I ran across a post of yours from February explaining its behavior in greater detail. The Raven is probably a poor choice if I go this direction.

Thanks Mike.

 

[jderimig]

Without knowing the specific Kalman filter implementation its hard to say whether it will help with your application.

A basic Kalman filter compensates for the random noise or errors of the sensors by using the dynamic model. It doesn't compensate for a "process" error or a sustained bias in the readings of the sensor. In your case you would introducing a "process" error in the calculation of altitude and by extension apogee detection by design.

If the Kalman filter were formulated so that the Kalman gain matrix was not constant then it could address your implementation. For example during the high speed portion of the flight the Kalman gains would be set for high trust of the accelerometer sensor and low trust of the baro sensor. Near apogee when velocity is low then trust can be shifted back to the baro sensor.

 

[mikec]

The Raven is probably a poor choice if I go this direction.

I'm wondering if you really need the static ports where you say. I've had nose-cone arrangements where the ports were down in the NC shoulder but there was a vent path up to where the altimeter was.

I've had pretty good luck with Raven accelerometer apogee but I guess I've been lucky with the accelerometers I've gotten. I fly a test flight to assess the bias before doing anything extreme.

 

[GregGleason]

As an aside to the filter's namesake:

https://hungarytoday.hu/news/renowned-hungarian-scientis-rudolf-kalman-dies-aged-86-46732



Greg

 

[mpitfield]

I'm wondering if you really need the static ports where you say. I've had nose-cone arrangements where the ports were down in the NC shoulder but there was a vent path up to where the altimeter was.

I've had pretty good luck with Raven accelerometer apogee but I guess I've been lucky with the accelerometers I've gotten. I fly a test flight to assess the bias before doing anything extreme.

x2, I was wondering why you had to shift your ports forward. Are you sealing the altimeter portion from the rest of the nosecone? If not, and this is just a guess based on similar experiences, I would say locating the altimeter at the top of the nosecone with the sampling holes where you have previously had them should be fine.

I have 3 nosecone AV bays all retrofitted and the sampling holes are all about an inch or so just below the shoulder, and the altimeters are mounted about half way forward. All of these AV bays have had flights on them and not one has failed due to the relationship of sampling holes and location of the altimeter.

 

[watheyak]

Thanks John for the explanation, that cleared up quite a bit. Any plans for a MARSA Mini?

The main reason for putting the electronics in the tip was for better space management. The parachute and associated harness will also be in the nosecone and would pack better into the fat end. The av-bay would be sealed from that area.

I am molding the nosecone myself so adding a vent path to the inside surface would be a pretty easy thing do. Based on the comments here I think that's how I'll do it.

Thanks everyone for the input and suggestions. Getting out of my own way usually does the trick!

 

[SpaceManMat]

No reason why you cannot but ports on a NC, been done with record setting flights.

 

[keithp]

The candidates for altimeters in this situation are a Telemetrum, ...

I'd work harder to avoid this -- you're going to get completely crazy pressure readings, especially across mach transitions which will likely fool even the hardiest of Kalman filter implementations. I've got a data record from one TeleMetrum flight with this configuration and the apogee charge came out as the rocket slowed down back through mach. Not pretty. I'm trying to adapt the code to handle this case correctly, but it's nearly impossible when you also want to use the baro sensor above mach to support flights above 100k' where you often don't get subsonic until you're out of pressure sensor range.

One possible thing to consider is sticking the static port down below the nose shoulder and then routing the pressure up to the nose through a tube or other channel.

If you do fly like this, I'd love to get the data file...

 

[cerving]

A Kalman filter will get you the best possible aggregated data from your sensors, but the altimeter still needs to have some logic to throw out obviously bogus data, and deployments should be predicated on having consistently good data up to the point of triggering. Preventing parachute deployments during mach transitions really isn't that hard if you just wait until you've slowed down for awhile, that's what Eggtimer altimeters do. I can't speak for Featherweight, but I'd be very surprised if they didn't have similar logic or functionality, given the amount of time they've been around.

 

[mikec]

I can't speak for Featherweight, but I'd be very surprised if they didn't have similar logic or functionality...

The Raven mach immunity is done using the velocity estimate from the accelerometer, not from any processing of barometer data.

 

[jderimig]

A Kalman filter will get you the best possible aggregated data from your sensors, but the altimeter still needs to have some logic to throw out obviously bogus data,

A nitpick for sure but a Kalman filter can accomplish the above without the need of any external to the KF additional logic.

The baro sensor data during a mach transition is not bogus, the pressure actually did that. But the pressure-altitude model is bogus during that phase. You simply program the KF to trust the dynamic model more and pressure-model less as you approach mach.

 

[cerving]

A nitpick for sure but a Kalman filter can accomplish the above without the need of any external to the KF additional logic.

The baro sensor data during a mach transition is not bogus, the pressure actually did that. But the pressure-altitude model is bogus during that phase. You simply program the KF to trust the dynamic model more and pressure-model less as you approach mach.

Yes, during mach transition the DERIVED value from the baro is wrong, not the baro data itself. Changing the weightings of the sensors dynamically is making an adjustment based on data values that you know aren't likely to be correct based on the model, so it's just another mechanism for ensuring that the derived values are good. It's no different than increasing the weight of the baro as you slow down and approach apogee (assuming that you're not so high that you're outside the range of the baro) because the baro's data will be better that the accelerometer's at low velocities.