High Altitude Apogee Detection (100K ft)

[jderimig]

Oh, I missed the "raw" part of your message. If I compare the raw Z from the EM7180 to the Y of the ADXL they seem to track pretty close. In this graph, all I did was invert the raw Y in the ADXL (because Y- is up). Where do you see the discrepancy between the two?

Comparing the EM linZ and ADXL Y columns

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

 

[AllDigital]

Comparing the EM linZ and ADXL Y columns

EM linZ has gravity removed. ADXL Y does not have gravity removed. The apples-to-apples comparison would be between EM-Z and ADXL Y. In the log I was averaging EM-Z (about 25 samples in each log entry), but for the ADXL I was just logging point in time, so the EM-Z is more accurate than ADXL Y.

 

[mikec]

It should be possible to take your raw data and see if the effects of single-precision float were affecting the results. I'm too lazy to work it out, but obviously running at a high sample rate will affect things. I did my integration in single-precision at 50 Hz and didn't see anything obviously wrong, but I wasn't doing anything mission-critical.

 

[jderimig]

It should be possible to take your raw data and see if the effects of single-precision float were affecting the results. I'm too lazy to work it out, but obviously running at a high sample rate will affect things. I did my integration in single-precision at 50 Hz and didn't see anything obviously wrong, but I wasn't doing anything mission-critical.

I may be mistaken but if you are compiling GCC ARM everything is double even if you declare float. But like I said high probability I am mistaken.

 

[jderimig]

EM linZ has gravity removed. ADXL Y does not have gravity removed. The apples-to-apples comparison would be between EM-Z and ADXL Y. In the log I was averaging EM-Z (about 25 samples in each log entry), but for the ADXL I was just logging point in time, so the EM-Z is more accurate than ADXL Y.

To test your integration you can find what level of gravity offset you would need to get the apogee timing right with your data. See how far off it is from 1. It doesn't have to be 1.0000, in fact, as mentioned in a previous post, 1.000 offset is not the optimal choice.

 

[mikec]

I may be mistaken but if you are compiling GCC ARM everything is double even if you declare float.

Fair point. The calculations are usually done in double unless perhaps you go to special lengths to define constants as float, etc, but if you spill back to memory if you declare float then there's a conversion. You'd have to check the assembly output to be sure.

My code was running on classic Arduino which is single-precision only.

 

[UhClem]

I may be mistaken but if you are compiling GCC ARM everything is double even if you declare float. But like I said high probability I am mistaken.

Implementation dependent. The Cortex M4 ARM used in the Teensy 3.6 has single precision floating point hardware support that is very fast so the compiler options are set for single precision floats.

 

[AllDigital]

To test your integration you can find what level of gravity offset you would need to get the apogee timing right with your data. See how far off it is from 1. It doesn't have to be 1.0000, in fact, as mentioned in a previous post, 1.000 offset is not the optimal choice.

I think I have found the issue...

Using the logged data, I was able to model velocity in Excel for the ADXL. First, I baselined it by modeling velocity using "average Lin Z" and using my log timestamp (in only 0.000 precision) to determine rate. That baseline was accurate compared to the onboard 500hz calculated velocity within half a second (crossing zero). very, very close.

I know that my average Linear Z data has exactly 1G subtracted from the raw values, so I adjusted the G offset by subtracting values, until velocity lined up with apogee. In this model my G offset would need to be .842G to peg the timing of apogee.

I then went back to my log files and looked at 20 minutes of data, before launch (not in the file I posted). When I averaged the resting "average Lin Z" it was actually .174G, instead of 0. If I add this discrepancy in bias to the .842 I land at 1.016G.

So, I think the smoking gun is the bias offset error. As David (@UhClem ) points out above, I should be calculating that while sitting on the pad, instead of depending on my calibration at home. The ADXL375 is incredibly noisy, but when sitting on the pad sampling at 500hz it becomes clear exactly what the bias should be to remove gravity.

In the meantime, I will also switch my floats over to doubles. I am using an ESP32, so the default float is single precision. I am not sure that it mattered here, but just in case I'll switch to double precision and see if I get a performance drop.

Thanks,

Mike

 

[AllDigital]

A quick update... I did a launch to 15K feet this weekend, using the updated code that corrects the offset on the pad using large samples. With my "very noisy" 200 Gee ADXL accelerometer, I was able to call apogee within .1 second of the barometer and the commercial altimeters on board. I will continue to test and refine, but to the question in my original post, It seems to me like the accelerometer could be a reliable source or input when estimating beyond a barometers reach.

Since I've ditched my EM7180, my next project is tracking accurate tilt during flight using the the gyro (and accelerometer on the ground) in a new LSM6DSO32.

Thanks to everyone that helped me get the accelerometer code to accurate.