Accel vs Barro Altitude on my Featherweight

The Rocketry Forum

Help Support The Rocketry Forum:

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

HaackIt

Well-Known Member
Joined
Jul 25, 2012
Messages
169
Reaction score
1
I launched my featherweight today for the first time. I haven't finished my dual deploy rocket so I threw it in the nosecone of my 4" Nike Smoke and used it to deploy my main chute at apogee. Here's the graph:

nike_j1520.jpg

The barometer shows my maximum altitude as 5126 ft, and my accelerometer shows 5708 ft. The nosecone is black it was pretty warm in there - it was in the 60's outside today and in the 90's inside the cone. I was wondering if this is the source of the difference. Which number should I assume is closer to reality?

For those wondering why the barometer shows the altitude increasing faster than the accelerometer early in the launch, I think it is because my vent ports are just behind the widest part of the Nike nose cone so it would have been a lower pressure area while moving quickly.
 
Forgot to mention. This is a Madcow 4" Nike Smoke on a CTI J1520.
 
The accel is the distance traveled archs included baro is the actual altitude. Use the baro.
 
Which number should I assume is closer to reality?

To compute position from the acceleration, you have to integrate the data twice. What this means is for each sample interval (400 samples/second), you measure the acceleration at the start of the interval and at the end of the interval (subtracting out acceleration due to gravity as the first 1G is just counteracting that). Compute the average acceleration over that interval ((start_accel + end_accel) / 2), multiply it by the length of the interval (2.5ms) to get the speed increase is over that interval. Do that for every measurement in the flight and by keeping a running sum, you have speed data. Now take the speed data and do the same operation to it, ((start_speed + end_speed) / 2) * 2.5ms, to get the change in position. Compute the running total of those changes in position and now you have position.

The problem with this is that it assumes you can measure acceleration exactly, and that the rocket is flying exacly vertical. If you have a tiny constant error in your acceleration measurements, you'll add that error to every change in speed, and that error in the speed will get added to every change in position effectively compounding the error, so a constant acceleration error yields a quadratic error in position. Double the time of flight and you get twice the error in speed and four times the error in position.

The effect of flying at an angle is more complicated, but effectively boils down to the limitation of the measurements. We're measuring only axial acceleration and assuming that is the only force acting on the rocket. In fact, as the rocket arcs over, a portion of the force of gravity is pulling the rocket sideways, which our axial measurements aren't including. We further assume that the axial acceleration is all vertical, when in fact the more it tilts over, the less of that acceleration is pushing the rocket higher. Tilt over horizontal and we'll still get impressive acceleration numbers, which when integrated twice to get position will say that the rocket moved a long ways. That's true, but it hasn't exactly gone up very far...

Meanwhile, our barometric sensor is happily sensing the atmosphere and computing the pressure along the flight. Of course, during boost and across mach transitions, the readings will be very inaccurate. The vent holes will limit how fast the pressure can change during high speed flight, so you get barometric altitude lagging the true altitude. And, across mach transitions, you get all kinds of crazy noise which can generate false apogee events if big enough. However, as the rocket approaches apogee, all of the sources of barometric sensor noise quiet down and you're getting very accurate pressure readings. Because we can directly convert pressure to altitude, each measurement is independent of all other measurements, and so there's no cumulative error; each reading has a constant error bounds, so the readings at apogee are just as accurate as those at the ground. Nor does the barometer care what path you took along the flight; it's just measuring vertical position.

The resulting accuracy of the system depends on the accuracy of the barometric sensor and the atmospheric model. The Raven3 uses one of the best sensors available, and is amazingly accurate; at sea-level, this sensor can measure changes as small as 8 inches. For low flights, as long as the atmospheric model is reasonably precise, any errors in position caused by local temperature or air pressure differences will tend to cancel out between the ground and apogee measurements, making the reported height much more accurate than either altitude measurement. To improve the accuracy of the height values, you can download the raw pressure data and go as the national weather service for temperature and pressure data up through the atmosphere at the time of your flight from the nearest weather station.

You can build a full inertial navigation system which couples three accelerometers with three gyroscopes. The gyroscopes let you measure changes in orientation so that you can adjust your computations, while the accelerometers compute position changes in all directions. That solves the tilting-over part of the problem, but you're still left with constant errors compounding into larger and larger errors in position, velocity and orientation.
 
Back
Top