Estimator altitude error

[zfurman56]

I'm having an issue with the estimator altitude - it exhibits large deviation from baro altitude. This is flying on a somewhat unusual platform - a mid-power model rocket. It only shows up on some flights. This is a Pixracer, with EKF2_HGT_MODE set to zero (baro is primary altitude source).

The issue looks like this: (I flipped and offset the estimator z position such that it matches up with the baro)

Here's another flight, without the issue:

Here's the log for the flight with the issue. Here's the log for the flight without the issue.

Looking at the estimator innovations, it appears that the estimator is having serious issues reconciling the sensors, to the point of rejecting baro measurements. For example, hgt_test_ratio approaches 15 on rocket ascent. I suspected it may be an excess vibe issue, but the vibe metrics are very low - I don't think rockets have the same high energy tonal harmonics that motors or props would. Is it possible this is due to something other than vibe? I'm also investigating incorrect baro delay and low design baro sampling rate (compared to inertial sensors).

[RomanBapst]

@zfurman56 Hi Zach, very interesting log file, never seen one from a rocket before. I just had a quick look at both of your logs and have the following comments:

1) I think you can see the problem in both logs, however, a height reset only occurred in one of them. 2) The vertical velocity innovations have the opposite sign to the vertical height innovations. It actually looks like the gps vertical velocity measurements don't get up to speed. Are you sure that the gps receiver you are using is suited for this kind of application? 3) In this case a replay logfile would be very nice since it would allow us to tune the estimator offline and you could do stuff like disabling gps velocity fusion... You can find instructions of how to use the replay tool here https://dev.px4.io/advanced-replay.html I think @priseborough has a lot of experience with rockets, maybe he can also help.

[zfurman56]

We're currently using a Ublox M8N GPS, set to maximum dynamics (which is unfortunately "4g", but it's not a hard limit, and it's not clear what the exact effect is on GPS output). Do you have a recommendation of a better GPS with a larger dynamics range? In terms of replay logs, we're hoping to fly again next weekend, so we should be able to get a replay log then.

[priseborough]

Unless the baro is sensing pressure via a properly placed static pressure port, it will be unusable at high speed due to positional errors.

[priseborough]

The accelerometer is limited to 16g internally, and because of the effect of filtering, for short burn time model rocket motors this can be exceeded even if the output is not saturated. your g's are peaking at over 13 post filtering, so I would not be surprised if the IMU accel is saturating. Try a lower peak thrust, longer burn time motor with the same impulse.

[zfurman56]

@priseborough Thanks for the quick reply. The baro is placed in a chamber with four small holes as pressure ports (fairly standard for model rockets). The delay should be around 50 ms and the noise should be plus or minus a foot.

The engine we're currently using is the AeroTech F52. As you can see, the peak thrust is about 80 Newtons. Our rocket currently weighs 620 grams, so a quick calculation tells us that the peak acceleration should be about 130 m/s^2. This matches the acceleration observed in the data. I doubt accelerometer saturation is the problem - it has happened before in previous launches, until the accel range was set to 16g - and the symptoms look different. I suspect high acceleration over such short time intervals may be causing this problem, however. Here's a log from an earlier flight with a lower peak thrust engine, for comparison. We did in fact try to find engines with the same impulse but longer burn time, but for altitude reasons. Our search was eventually unsuccessful - we're limited to engines with an impulse no higher than 80 Ns (class F engines), and we're very close to that limit, making engines with the thrust and impulse we want hard to find.

[priseborough]

Further Observations

Structural dynamics can produce high frequency vibration on motor ignition that can clip the IMU's internal 16g limit, so the IMU can still be saturating internally as you are operating close to sensor limits. All position, height and velocity innovations fail innovation checks immediately after motor ignition. Spin rate on boost is high given the scale factor errors that the MEMS gyros have . There is a negative g transient at motor burnout which causes a 15m step change in baro height On the flight with the issue, chute opening does saturate the IMU.

Things to try

1) Stop sending GPS and baro data to the EKF during the boost phase 2) soften the shock cord 3) reduce launch spin rate 4) shock mount the IMU

[zfurman56]

@tumbili I'm trying to get a replay log tomorrow, but I'm not sure what exactly I'm supposed to change to get a replay log. You linked me to the documentation for replay here: https://dev.px4.io/advanced-replay.html. But the instructions there seem to indicate that the topics are logged at full rate by default, and that no changes need to be made to get a replay log. And replay appears to work with the logs we gathered from last week. What am I missing here?

[RomanBapst]

@zfurman56 I was referring to the old depriciated replay method. You should be able to run a replay on your log file. Just follow the instructions.

[priseborough]

This issue has gone stale and is a low priority use case.