Larry Curcio
Well-Known Member
- Joined
- Mar 5, 2009
- Messages
- 538
- Reaction score
- 3
Greetings from Left Field. Sorry to be irrelevant but...
Back in 2009, I found formulas that give very nice speed estimates from combined accelerometer and altimeter data. These are documented here:
https://www.rocketryplanet.com/images/pdf/Barometric-Adjustment-of-Inertial-Flight-Data.pdf
(One version is in the main body of the text; the other is in Appendix D, the WGA approximation. The WGA is the simpler of the two, and its a very good approximation.) I call these estimates Barometrically-Adjusted Speed Estimates, or BASE estimates.
Whereas BASE estimates are robust, estimates of trajectory sines have been problematic. I had two ways of estimating those with barometric data and inertial data combined, and both involved numerical differentiation of barometric data. The most straightforward formula was simply
SineTheta = VY/BASE
Where SineTheta is the sine of the trajectory angle, VY is the vertical velocity (from numerically-differentiated barometric data), and BASE is the barometrically-adjusted speed estimate at the same point.
Numerical differentiation is a mathematical problem constructed in Hell, and its not worth more than a bit part in prime time. Between that and aerodynamic effects at the static port, trajectory sines were mostly pretty ratty. (To be clear, they could be better if everyone collected barometric data more carefully. Some were very good, but one cannot rely on good barometric data.)
The software for the differentiating protocols was too big to imbed in onboard instrumentation, and associated apogee-detection algorithms were not materially different from purely barometric algorithms. Numerical differentiation also demanded that the barometric data be decimated effectively discarding information. What is needed is a formula for sine that:
1) Doesnt involve numerical differentiation;
2) Relies more heavily on the inertial data than on the barometric data, while using both;
3) Can be used in a new apogee-detection algorithm; and
4) Can use all the data
I think I may have one of those.
From the formula just given,
VY = BASE*SineTheta
But also,
VY = VYLast + R*DeltaT*SineTheta g*DeltaT
Where VYLast is VY at the previous sampling point, R is the accelerometer reading, DetatT is the sampling interval, and g is gravitational acceleration.
Setting the formulas equal to each other and solving for trajectory angle sine,
SineTheta = [VYLast g*DeltaT]/[Base R*DeltaT]
So the algorithm is
1) Do Inertial Analysis on the Launch Rod
2) VYLast = Inertial VY from Launch Rod
3) SineTheta = [VYLast g*DeltaT]/[Base R*DeltaT]
4) VY = Base*SineTheta
5) VYLast = VY
6) Goto 3
Note that the only use of barometric data, here, is in the computation of the BASE values.
The denominator of the sine formula has a potential low-speed singularity, and it will normally be negative in the first data point, because of the influence of gravity. Its therefore best to start at some VYLast other than zero, and thats why one must use launch rod speed to prime everything. Heres the algorithm:
RodSpeed = RodSpeedLast +R*DeltaT g*Sin(LaunchAngle)*DeltaT
Length = LengthLast + RodSpeed*DeltatT
Stop at launch rod length or something short of it, if you dont know the exact value. Since one knows the rod angle at least approximately, this formula is much more reliable than inertial free-flight formulas. Its wholly empirical, in fact.
These sine curves correspond well to the old barometrically-adjusted curves and to off-vertical ballistic inertial analysis curves. They are prettier than the old barometrically adjusted curves and only slightly less smooth than the ballistic analysis curves (because of stair stepping in the barometric data.)
The apogee-detect algorithm is to deploy when the sign of the sine turns negative.
Although mach speeds can cause barometric anomalies:
1) They will likely not cause the sine to flip sign (Gotta verify this); and
2) The WGA is a barometric point-wise correction. Cumulative errors from past barometric anomalies do not pertain.
In fact, I have data sets that show that supersonic flights do not all have huge anomalies. (This contradicts a statement I made in the paper, BTW. While Im at it, turns out a method I rejected in the paper, The Brute Force Method, is objectively wrong.) But... one cannot rely on this.
At any rate, I expect to supply an Excel VBA program in a few days.
The attached graphs are from the program as it stands. Empirical sine is from the method above. Ballistic sine is from off-vertical analysis of pure inertial data under the assumption of a ballistic trajectory. A launch angle was backtracked in the ballistic method to fit the data no such accommodation was made for the present analysis method.
The integrated altitude is integrated from the VY above. The barometric graph is from temperature-corrected barometric data. Altitudes are in feet.
BASE values used were from the WGA approximation.
Regards,
-LarryC
Back in 2009, I found formulas that give very nice speed estimates from combined accelerometer and altimeter data. These are documented here:
https://www.rocketryplanet.com/images/pdf/Barometric-Adjustment-of-Inertial-Flight-Data.pdf
(One version is in the main body of the text; the other is in Appendix D, the WGA approximation. The WGA is the simpler of the two, and its a very good approximation.) I call these estimates Barometrically-Adjusted Speed Estimates, or BASE estimates.
Whereas BASE estimates are robust, estimates of trajectory sines have been problematic. I had two ways of estimating those with barometric data and inertial data combined, and both involved numerical differentiation of barometric data. The most straightforward formula was simply
SineTheta = VY/BASE
Where SineTheta is the sine of the trajectory angle, VY is the vertical velocity (from numerically-differentiated barometric data), and BASE is the barometrically-adjusted speed estimate at the same point.
Numerical differentiation is a mathematical problem constructed in Hell, and its not worth more than a bit part in prime time. Between that and aerodynamic effects at the static port, trajectory sines were mostly pretty ratty. (To be clear, they could be better if everyone collected barometric data more carefully. Some were very good, but one cannot rely on good barometric data.)
The software for the differentiating protocols was too big to imbed in onboard instrumentation, and associated apogee-detection algorithms were not materially different from purely barometric algorithms. Numerical differentiation also demanded that the barometric data be decimated effectively discarding information. What is needed is a formula for sine that:
1) Doesnt involve numerical differentiation;
2) Relies more heavily on the inertial data than on the barometric data, while using both;
3) Can be used in a new apogee-detection algorithm; and
4) Can use all the data
I think I may have one of those.
From the formula just given,
VY = BASE*SineTheta
But also,
VY = VYLast + R*DeltaT*SineTheta g*DeltaT
Where VYLast is VY at the previous sampling point, R is the accelerometer reading, DetatT is the sampling interval, and g is gravitational acceleration.
Setting the formulas equal to each other and solving for trajectory angle sine,
SineTheta = [VYLast g*DeltaT]/[Base R*DeltaT]
So the algorithm is
1) Do Inertial Analysis on the Launch Rod
2) VYLast = Inertial VY from Launch Rod
3) SineTheta = [VYLast g*DeltaT]/[Base R*DeltaT]
4) VY = Base*SineTheta
5) VYLast = VY
6) Goto 3
Note that the only use of barometric data, here, is in the computation of the BASE values.
The denominator of the sine formula has a potential low-speed singularity, and it will normally be negative in the first data point, because of the influence of gravity. Its therefore best to start at some VYLast other than zero, and thats why one must use launch rod speed to prime everything. Heres the algorithm:
RodSpeed = RodSpeedLast +R*DeltaT g*Sin(LaunchAngle)*DeltaT
Length = LengthLast + RodSpeed*DeltatT
Stop at launch rod length or something short of it, if you dont know the exact value. Since one knows the rod angle at least approximately, this formula is much more reliable than inertial free-flight formulas. Its wholly empirical, in fact.
These sine curves correspond well to the old barometrically-adjusted curves and to off-vertical ballistic inertial analysis curves. They are prettier than the old barometrically adjusted curves and only slightly less smooth than the ballistic analysis curves (because of stair stepping in the barometric data.)
The apogee-detect algorithm is to deploy when the sign of the sine turns negative.
Although mach speeds can cause barometric anomalies:
1) They will likely not cause the sine to flip sign (Gotta verify this); and
2) The WGA is a barometric point-wise correction. Cumulative errors from past barometric anomalies do not pertain.
In fact, I have data sets that show that supersonic flights do not all have huge anomalies. (This contradicts a statement I made in the paper, BTW. While Im at it, turns out a method I rejected in the paper, The Brute Force Method, is objectively wrong.) But... one cannot rely on this.
At any rate, I expect to supply an Excel VBA program in a few days.
The attached graphs are from the program as it stands. Empirical sine is from the method above. Ballistic sine is from off-vertical analysis of pure inertial data under the assumption of a ballistic trajectory. A launch angle was backtracked in the ballistic method to fit the data no such accommodation was made for the present analysis method.
The integrated altitude is integrated from the VY above. The barometric graph is from temperature-corrected barometric data. Altitudes are in feet.
BASE values used were from the WGA approximation.
Regards,
-LarryC
