High Altitude Apogee Detection (100K ft)

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

AllDigital

Well-Known Member
TRF Supporter
Joined
Jun 14, 2013
Messages
616
Reaction score
751
Location
SoCal
My son and I have been working on a flight computer for a few years and continue to refine it, sharing our experience with student groups and maybe open sourcing it at some point. We've flown it a few dozen times between 15K-30K feet, but long term we want to put it on a sustainer to >100K feet. We still use commercial altimeters (currently) for safety, but we have very reliable data to capture launch, max accel/thrust, motor burn-out, apogee, fore/aft separation, descent, landing, GPS tracking, and more. For Apogee, we are primarily relying on the barometer. We used to also use tilt detection, but we've had a few flights where the rocket went to 70+ degrees in high altitude winds, while continuing to climb 2K feet, so we don't trust tilt (passively monitoring our apogee logic). We have very reliable 9DoF data calibrated and going through Kalman Filters (using an EM7180 processor), but our attempts to use integrated accelerometer data to calculate apogee have proven unreliable (too early or too late), even when staying within the limits of the accelerometer (500Hz sampling). We have also tried combining the accelerometer readings after motor burn-out, subtracting for gravity, and watching for convergence to (near) zero, but that only works about 50% of the time, as spin or thrashing at apogee creates too much noise on one or more axis.

I've read a dozen previous threads on the topic and it doesn't look like there is a silver bullet, but I'd be interested if anyone has a reliable formula they are using (without giving away any commercial trade secrets). We know we can always use a timer, but we are looking for something more accurate. We can also make a timer better by sampling velocity/angle at lower altitudes and calculating apogee time/altitude, before the barometer cuts out (quadratic regression). Integrating GPS is another option, but regaining lock and getting quality readings is not very precise at apogee, although it is more reliable than we expected.

After a few dozen tests with different rockets, I've been surprised at the amount of instability "at the top" with a some flights. Is it plausible that a (stable) rocket could do a full 180 degree flip well before apogee? Not that tilt is a reliable measure of apogee (it could drop straight back down without tilting), but is it reliable to assume that a 180 degree flip has passed apogee?

Thanks for any ideas and feedback,

Mike
 
There is no real secret. The RDAS Compact did a very good job using the ADXL150 with a 10 bit ADC. Modern accels perform better of course. But as always, details matter. I can't tell you where you are going wrong without more information.

Of course at that altitude, the air is so thin that it doesn't really alter the deployment forces that much if you are off by 10's of seconds.
 
This video show one of Jim Jarvis's doing some not so straight...maybe end to end flying...for the last 35K of it's flight..



Tony
 
There is no real secret. The RDAS Compact did a very good job using the ADXL150 with a 10 bit ADC. Modern accels perform better of course. But as always, details matter. I can't tell you where you are going wrong without more information.

Of course at that altitude, the air is so thin that it doesn't really alter the deployment forces that much if you are off by 10's of seconds.

Yup, Down low under 10k it’s nice to get the apogee deployment to occur at the most lowest velocity on the ascent. If way up high in a vacuum, no air to stress the apogee harness. Took me awhile to realize that. Like David says, can be off by 10’s of seconds and probably won’t matter much at 100k. (Probably 50k wouldn’t matter either.)
Kurt Savegnago
 
monitoring our apogee logic). We have very reliable 9DoF data calibrated and going through Kalman Filters (using an EM7180 processor), but our attempts to use integrated accelerometer data to calculate apogee have proven unreliable (too early or too late), even when staying within the limits of the accelerometer (500Hz sampling).

What do you consider too early or too late? I have gotten reasonable accurate apogee deployments using accelerometer integration only on customer flights in the 60-80K foot range as verified by one-board video. When I say reasonable accurate I mean apogee detection often within a second of true apogee.

How far are you off?
Is your error biased (always late or early)?
I get nervous when someone says "calibrated IMU". How was it calibrated?
How are you doing the numerical integration of the acceleration?
How are you using Kalman filters?
How are you accounting for gravity in your integration to velocity?
 
Even if the apogee value derived by integrating the filtered accelerometer value doesn't agree 100% with the apogee derived from your filtered baro value, the inflection points that indicate apogee should be close, assuming a fairly nominal flight profile. If your flight profile is not nominal, you probably won't get anywhere near 100K, so you might want to let the baro handle your deployments under 50K or so.
 
Thanks guys. It has been about a year, since I had a run at using the acceleration data for estimating apogee and trying to estimate altitude. Since the barometer-based apogee and altitude were sufficient, I gave up without a lot of effort. In looking back at some of that data, it looks like I had timing issues and/or noise right at launch, so I potentially lost large amounts of samples at the most important time.

@John, within a second of true apogee would be amazing. The tech I am using is based on an EM7180 SENtral co-processor to do the integration, Kalman filtering, and output quats and individual results. It is actually a pretty amazing little package that provides me with very clean and very precise yaw, pitch, roll, along with other standard 9DOF outputs. Here is a link to the packaged solution by Kris Winer: https://github.com/kriswiner/EM7180.../A.-A-Short-Survey-of-Sensor-Fusion-Solutions

The data from my past flights is not very complete, but I've got some launches coming up in a few weeks, so I will light up my SD logging with all the raw output and the results of the algorithms I'm currently using. The code from @mikec was helpful, but I think I need to accumulate more data to see how things behave.

It seems that the apogee logic should be straightforward -- correct me if I'm wrong. The simplified logic would be at launch trigger (e.g., accelerometer > .2G) I begin adding the filtered value of the z axis to a long integer for each sample and weighted for any variation in sample time increment. As it climbs through motor burn-out the integer reaches very high values, but in the coast phase it should ultimately converge back to 0 (or close) at the top. The other approach I've tried is to combine the x,y,z values after motor burn-out, and then subtract 1G for gravity and watch for convergence to near 0 at the top. The challenge with this approach is spin and thrashing at the top.

With the barometer, I can just put the sled in a vacuum chamber and simulate 20 flights in a day. It is a lot harder to simulate high altitude flights for accelerometer logic testing (although I've tried with my drone in the backyard -- not the same!).

Thanks,

Mike
 
It is a lot harder to simulate high altitude flights for accelerometer logic testing
A method I've used is to bias the 1g accelerometer reading by a constant, and then simulate the flight by holding the unit sideways, then up, then down. Crude and doesn't model sensor non-linearities, but useful to see that your events happen.

Or, you can use a smaller value for the velocity threshold and simulate launch by jerking the unit upward.

My code has launch detection logic and while it's a bit convoluted it works well in practice. You don't want to just look for one sample of accel > threshold.
 
The tech I am using is based on an EM7180 SENtral co-processor to do the integration, Kalman filtering, and output quats and individual results.
Which sounds like the accel data you are using has already been mangled by some other blob of code. Bad idea. Those blobs tend to try and "correct" various errors and if your system behaves differently than what the code authors expected ( ie. high acceleration then ballistic rocket instead of mostly 1G aircraft) the results will be wrong. Kalman filters are model based. If the model doesn't match the system, you get GIGO.

Worse, that appears to be based on the MPU9250 which does not have the range for this application. It is far too easy to exceed 16G acceleration in a rocket.

There are a few ways to test the algorithm. One is to make the code portable enough (easy with C) so that you can feed it simulated data on your PC. Another is to feed simulated sensor data to the flight hardware. That one is harder since you have to pretend to be a MPU9250 (for example) talking over a I2C (if you must) or SPI port.
 
@John, within a second of true apogee would be amazing. The tech I am using is based on an EM7180 SENtral co-processor to do the integration, Kalman filtering, and output quats and individual results. It is actually a pretty amazing little package that provides me with very clean and very precise yaw, pitch, roll, along with other standard 9DOF outputs. Here is a link to the packaged solution by Kris Winer:

As UhClem has posted, you are dealing with a black box. Apogee estimation is very simple algorithm with diminishing returns as you add sophistication.

You may have 1 or more of 3 problems:
1. Raw data bad
2. Processed data bad
3. Apogee algorithm bad

So you need to find what the root causes are.

So my first recommendation is to get some raw z-axis accelerometer data from one of your flights (as you are planning) and test apogee algorithms using Matlab, Octave or even Excel will do nicely. As UhClem has mentioned any flight where the accel exceeded 16g will result in an early apogee detection. Such flights are invalid. It would be best if you can select a relatively "straight" flight.

Do a simple acceleration trapazoidal integration and determine apogee when the integration is = 0 (vel =0). If that value is close to the observed apogee time then:
1. Raw data is good
2. Problem is in either processed data or your apogee algorithm.

If that value is way off and close to your computer's estimation then:
1. Raw data is bad or/and
2. Processor mangling processing by it is bad.

At first, keep the apogee calculation simple, do not use rotations, Kalman filters etc, just simply integrate the z-acceleration. You should be able to easily nail apogee with 15K flights with a simple accelerometer integration in well behaved flights. I recommend that be your starting point.
 
Last edited:
Thanks for the great feedback. I'll give this some focus over the next few months and see how the data pans out. I've also got an ADXL375 (+/- 200g) on board, but I have only been using it to verify max acceleration and have not been logging output or fully utilizing it yet. About half my flights exceed the EM7180/MPU9250 solution (flying sugar), but going higher will definitely peg the 16g limit. I'll capture everything I can from both. I should be able to increase my SD logging to about 10-20Hz without needing to get creative, so hopefully that will give me enough resolution to see what's going on. I also downloaded the trial version of Matlab -- this looks like an upgrade from Excel.

@John, in addition to capturing the raw data, I've currently got two algorithms set up to monitor. #1 integrates all three axis to determine velocity (x^2 + y^2 + z^2)^1/2 -- If I just observe velocity, then it goes positive at launch, peaks at max thrust, crosses zero and goes extreme negative at motor burnout and should converge to zero again at apogee. Is that right? or should I be accumulating the value of v integration into a variable (with g removed), let it go way positive during thrust and decrement during coast to get to a net zero? The former approach is indifferent to exceeding the acceleration limits, while the later exceeding the limits would result in a lot of missing positive data.
My #2 algorithm is a lot more simple and only watches the z axis, accumulating on the way up (positive during thrust and neg during coast), but it ignores x/y.

Thanks,

Mike
 
If I just observe velocity, then it goes positive at launch, peaks at max thrust, crosses zero and goes extreme negative at motor burnout and should converge to zero again at apogee. Is that right?

You are describing vertical ACCELERATION, not velocity.
Integrate acceleration to get velocity.
 
@John, in addition to capturing the raw data, I've currently got two algorithms set up to monitor. #1 integrates all three axis to determine velocity (x^2 + y^2 + z^2)^1/2 -- If I just observe velocity, then it goes positive at launch, peaks at max thrust, crosses zero and goes extreme negative at motor burnout and should converge to zero again at apogee. Is that right?

Ahhh. The magnitude of velocity doesn't go to zero at apogee, only the z-component does. Just integrate the z-axis accelerometer data subtracting 1g along the way. If sample rate is low use trapazoidal rule for the integration. That should get you a lot closer.

Also instead of Matlab you can download Octave which is an open source (free) version of it.
 
Yep, David (@UhClem) was right. I wasn't trying hard enough. My son and I spent time this weekend optimizing for data capture and modeling apogee with some backyard tests. We got a lot of good raw data from two different accelerometers and are now using it to test velocity and apogee detection (capturing and logging at 500hz).

Just to confirm, apogee is detected when z axis (linear / less g) velocity crosses from positive to negative. Correct?
 
Last edited:
Just to confirm, apogee is detected when z axis (linear / less g) velocity crosses from positive to negative. Correct?
Yes. Z-vel = 0 is detected apogee. Also launch detection algorithm is also very important. A simple 2g threshold can be triggered with a motor chuff and you will detect apogee on the pad. It needs to be more sophisticated than that and you need to include pre-trigger data in the integration.
 
Is it not the case that none of the velocities are guaranteed to be zero at apogee? (ie aligned to Rocket co-ordinate reference frame). Sure the rocket vertical velocity component in the World reference frame is zero, I guess that is the actual definition of apogee.

I would think that the only time Vz (rocket reference frame) is actually zero at apogee is for a perfectly vertical flight, where the vehicle Z axis remains aligned with the gravity vector.
Consider most flight trajectories where there is often a significant horizontal velocity component at apogee, and this often means that the Z component (along the rocket long axis) is not zero.

If you have an absolute reference on-board (maybe triaxial magnetic field sensor) then you can determine if the vehicle offset from the world reference frame and perform a transformation from the rocket reference frame to the world frame to get the world reference velocities.
 
Integrate the z-axis accelerometer value twice to get altitude, when it starts to drop then you've hit apogee. It doesn't matter what path you take because it's the z-axis... assuming that your rocket is stable.
 
Is it not the case that none of the velocities are guaranteed to be zero at apogee? (ie aligned to Rocket co-ordinate reference frame). Sure the rocket vertical velocity component in the World reference frame is zero, I guess that is the actual definition of apogee.

I would think that the only time Vz (rocket reference frame) is actually zero at apogee is for a perfectly vertical flight, where the vehicle Z axis remains aligned with the gravity vector.
Consider most flight trajectories where there is often a significant horizontal velocity component at apogee, and this often means that the Z component (along the rocket long axis) is not zero.

If you have an absolute reference on-board (maybe triaxial magnetic field sensor) then you can determine if the vehicle offset from the world reference frame and perform a transformation from the rocket reference frame to the world frame to get the world reference velocities.

Yes the assumption of vertical flight allows the most simplest of algorithms (integrate z-axis acceleration once, at V=0 call apogee). This model works well for the vast majority of flights. Even a 15-20 degree off vertical results in relatively little apogee detection error.

The next level of apogee detection improvement is to apply a little MLE in the integrating algorithm and realize that the probability of a perfectly vertical flight is approximately 0. So assuming a 1g offset during integration is approximately 100% probability of being wrong. A more optimum choice would be a value that is not -1g. Using that you can make the simple algorithm "useful" with larger values of off nominal flights.

A further improvement with minimal software complexity is to fuse a barometric reading into the integration of acceleration using a Kalman filter. If there is a significant off vertical flight the barometric data and the accelerometer derived altitude will start to diverge. An appropriately written algorithm can then decide which input to "trust" more.

And finally yes, a 6 dof IMU with an positioning engine to determine position and attitude relative to the earth frame reference can be used. But for simple apogee detection this well past the point of diminishing returns for the extra complexity invested, in my humble opinion. However such a positioning engine would be useful for other purposes.
 
A further improvement with minimal software complexity is to fuse a barometric reading into the integration of acceleration using a Kalman filter. If there is a significant off vertical flight the barometric data and the accelerometer derived altitude will start to diverge. An appropriately written algorithm can then decide which input to "trust" more.
Actually, the pressure altitude compensates for all of the drift and other errors you would normally get just using acceleration. No need to decide which to trust.

Drop the pressure altitude when you reach its limits. The acceleration is low enough at this point (you should be coasting) that the errors are small. For really high altitude flights I think that at some point you should just ignore the acceleration measurement as well and just assume it is zero. (It should be really close anyway.) This would prevent rotational acceleration from mucking it up if the air gets too thin for aerodynamic stability to keep it from swapping ends.
 
Actually, the pressure altitude compensates for all of the drift and other errors you would normally get just using acceleration. No need to decide which to trust.

Drop the pressure altitude when you reach its limits. The acceleration is low enough at this point (you should be coasting) that the errors are small. For really high altitude flights I think that at some point you should just ignore the acceleration measurement as well and just assume it is zero. (It should be really close anyway.) This would prevent rotational acceleration from mucking it up if the air gets too thin for aerodynamic stability to keep it from swapping ends.
Yes but the title of this thread is 100K apogee detection, at that level which sensor to trust might be not so straightforward. If there was significant deviation at an altitude where the baro reading can certainly be trusted then a good algorithm might be able to "correct" the acceleration input so it may be better trusted when the baro looses its trustworthiness. If you are high enough then yes, get a good estimate of Vz and solve for 0 = Vo - at to get the predicted apogee time.

The above is close to what we did for a customer's Karman Line attempt flight 2 years ago.
 
Last edited:
The extended range of the TE/Meas-Spec MS56xx baro sensors is 10 hPa, which works out to about 85,000 in the STP model (yes, it's not perfect...) If you get anywhere near that, you probably went pretty much straight up, so keeping track of both baro and accel altitudes and fading in the delta altitude values from the accelerometer while fading out the baro delta would seem to be a reasonable thing to do. If you could get the raw baro/accel data from some high alt flights, it should be pretty easy to run some different algorithms against it, and see how they compare.

Note that apogee DETECTION is a lot different than apogee CALCULATION... the former can be done pretty reliably with only a z-axis accelerometer, the latter basically requires a full 6-axis accel/gyro if you're going to do it without a baro. The reality is that very few of us will every fly anything outside the limits of a baro altimeter.
 
Last edited:
Note that apogee DETECTION is a lot different than apogee CALCULATION... the former can be done pretty reliably with only a z-axis accelerometer, the latter basically requires a full 6-axis accel/gyro if you're going to do it without a baro. The reality is that very few of us will every fly anything outside the limits of a baro altimeter.

Or a good GPS module with a good antenna that can relock before apogee.
 
Ok, I had a bit more time to look at our crude "football" test data from last weekend. As context, we put our board in a nerf football and did our best to launch it straight up 20 feet in the backyard. We just did a 10 second sample to gather raw data and had no launch or apogee logic running. On our board we had a 16g accelerometer (MPU9250 with an EM7180 front end co-processor filtering) and a 200g ADXL375 accelerometer, sampling and logging to SD at 500 Hz, along with a barometer (40 hz). This is a really crude way to test, but it helped us look at different types of "apogee" events and practice integrating the velocity with the raw data. Essentially, a really really slow and low rocket launch.

The 200g accelerometer is obviously much noisier than the 16g-filtered, but they tracked very close (as expected). We dumped the raw data into Excel and started playing. Here are some of the results and a few questions...

This is just a simple comparison of the two accelerometers raw z axis during "launch", apogee, and landing ("catch") -- the 16g (filtered) is red and the 200g is grey.
Screen Shot 2020-11-12 at 6.27.20 PM.png


This graph pulls everything together for just Accelerometer A (16g). It shows the raw z (blue), linear z (orange), barometer data (red) - although mostly useless for a spinning ball and 20' test, but a data point. The green represents our post test velocity integration, starting with the first indication of "launch". For our 500hz sampling we are using the formula v += (z accel) x (1/500), with z accel coming off the linear z (g removed and 9dof) data. Based on this graph, apogee looks clean with velocity crossing zero about midway between launch and landing.
Screen Shot 2020-11-12 at 6.27.50 PM.png

For the same test, here is the Accelerometer B data and velocity calculated post-test using raw z-axis less 1g with no filtering. In this crude side-by-side test the calculated apogee for the second accelerometer is only 45ms off from the less noisy/clean/filtered 16g accelerometer.
Screen Shot 2020-11-12 at 6.28.07 PM.png


We had a number of "football launch" tests, where the football tumbled at the top, instead of holding a spiral and keeping the pointy end up. Below is one of those tests. Interestingly, the raw z axis (grey for 200g and blue for 16g) didn't look much different, but the filtered "linear z" coming out of the EM7180/MPU9250 looked more like what I'd expect (the yellow line below). That data is filtered and 9dof integrated to the gyro and mag. If we calculate velocity off that "linear z" then calculated apogee timing (velocity crossing zero) gets pushed out too late -- we confirmed with slo mo video (240fps) it was much earlier. Again, the filtering is a black-box, so I'm not sure if I can use it. On the other hand, I am not sure how an unstable rocket tumbling or significantly tilting (happens to us) will vary the apogee detection, especially if the z axis isn't evaluated against a gyro or other data point (gps, barometer, etc).


Screen Shot 2020-11-12 at 6.26.59 PM.png

We'll keep doing some ground and bench tests to learn more, before flying to get higher resolution raw data.

thanks,

Mike
 
It sounds like you do not want to use the EM7180 until you understand what it is doing, or don't use it at all.
 
Are you sure EM7180 is not using gravity reference compensation for the gyro's and mag? Most do for terrestial applications like cell phones, HID devices, and robots. If so that is exactly what you do not want for a ballistic application where there is no gravity in the body frame.
 
It sounds like you do not want to use the EM7180 until you understand what it is doing...
Agreed. Unfortunately most of these internal processor IMUs are really badly documented and/or proprietary about what the processing is really doing. I was fairly sure that the 9650 in gyro-only calibration-off mode was doing the right thing, but a quick skim of the EM7180 user's guide doesn't fill me with confidence that such a mode is available.
 
It sounds like you do not want to use the EM7180 until you understand what it is doing, or don't use it at all.
Right. Up to this point, I was only using the EM7180 for tilt detection and launch detection. For those two functions it works fine. For tilt detection (Y,P,R) it is actually very nice to have a co-processor doing the work, but the 16g limits of the MPU9250 and the black box nature of the filtering definitely won't work for integrating velocity or calculating apogee. So, for now I am just using it as a basis of comparison with the ADXL375.
The ADXL375 seems to be working fine, but the +/-200g range seems excessive. Any suggestions on a preferred 50g accelerometer or something smaller?
 
Right. Up to this point, I was only using the EM7180 for tilt detection and launch detection. For those two functions it works fine.

Not necessarily on tilt. If the IM7180 is using the gravity reference vector to correct gyro drift (as most IMU chips do by default) then you can have an indeterminate error on the tilt reading.

Most IMU's use a variant of the Madgwick algorithm to determine attitude.
https://www.x-io.co.uk/res/doc/madgwick_internal_report.pdfIn summary the algorithm uses the observation of the gravity vector component on the x,y axes to confirm a gyro integration of tilt. If this isn't confirmed the algorithm chalks this gyro input as drift. In a rocket flight this confirmation will never happen because the gravity vector is not observable.

You will need to turn off the acceleration inputs to the IMU processing engine upon launch detect to avoid this potential filtering error.
 
Last edited:
Back
Top