Quantcast

High Altitude Apogee Detection (100K ft)

The Rocketry Forum

Help Support The Rocketry Forum:

jderimig

Sponsor
TRF Sponsor
Joined
Jan 23, 2009
Messages
3,252
Reaction score
667
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

1607452042866.png


 

Attachments

AllDigital

Well-Known Member
Joined
Jun 14, 2013
Messages
240
Reaction score
128
Location
SoCal
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

Well-Known Member
Joined
May 9, 2009
Messages
2,476
Reaction score
362
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

Sponsor
TRF Sponsor
Joined
Jan 23, 2009
Messages
3,252
Reaction score
667
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

Sponsor
TRF Sponsor
Joined
Jan 23, 2009
Messages
3,252
Reaction score
667
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

Well-Known Member
Joined
May 9, 2009
Messages
2,476
Reaction score
362
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

Well-Known Member
Joined
Feb 6, 2009
Messages
1,716
Reaction score
216
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

Well-Known Member
Joined
Jun 14, 2013
Messages
240
Reaction score
128
Location
SoCal
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

Well-Known Member
Joined
Jun 14, 2013
Messages
240
Reaction score
128
Location
SoCal
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.
 

Latest posts

Top