Acceleration

These last few days I've been indulging my nerdy streak and experimenting with Accelerate-Stop distance calculations. A while back I wrote a blog (found here) regarding Accelerate-Stop distances and the balanced field length of the Twin Comanche. That exercise came about as a result of a lack of Accelerate-Stop distance charts in my Twin Comanche flight manual, so I made my own. An Accelerate-Stop distance chart simply a chart that the pilot can use to determine the total distance required to accelerate to Vr (rotation speed), and then retard the throttles and stop using maximum braking. This distance changes depending on the field elevation, temperature, weight of the aircraft, and winds. These charts give a good indicator of the length of runway one would need to safely stop if they experienced an engine failure during the take-off roll.

I have recently been tinkering with an application that allows me to develop Apps for my Android Phone, called App Inventor. Its really quite fun, and while it does have some limitations on designing the user interface, it is really quite powerful on the functionality side. So I set out to design an Accelerate-Stop distance calculator for the Navajo. The Navajo does have proper Accelerate-Stop charts, but the challenge was in the ability to create a formula based on the variables present in paper chart in the flight manual. It ended up not being that hard, and after a day I managed to find a formula that produced results within +/- 50 ft of what the flight manual charts spit out. It took another hour to design and code a really simple app on my phone that makes use of the formula, allowing the user to input density altitude, loaded aircraft weight, and headwind component, and it makes the calculation. So now I have an app on my phone that can calculate Accelerate-Stop distances for a Piper Navajo.

I can't leave it at that however. That's way too easy. So here is the problem to solve: Accelerate-stop charts give a good reference, but they don't really have the flexibility of real-world operations. At least no more than just giving you a good idea. It still leaves room for ambiguity. In real life usually we're operating out of runways much longer than what is needed according to the Accel-Stop charts. For example here in France the runway is 5000 ft. So lets say for example that for the given day I check the accel-stop distance, and the chart (or my phone app) tells me the Accel-stop distance for that particular day is 3100 ft. So that means we can have an engine failure at Vr, and still stop with 1900 ft to spare. So if an engine quits on takeoff, up until Vr our go/no-go decision is a no brainer - we cut the power and stop. BUT, what if the engine fails AFTER Vr?

In theory we would clean the airplane up, continue climbing and return for a landing. But isn't that a waste of some really good extra runway? What if we still had the space to land and stop? Wouldn't that be a safer option than trying to climb out and fly an entire circuit on a single engine? Remember this is a light twin - climb performance will be extremely crippled on one engine. So how do we know if we have the space? An Accel-stop chart can't give you that answer, and that's a pretty tough decision to make in the chaos and confusion of a failed engine on takeoff.

This tough decision at a critical time is EXACTLY what every aircraft manufacturer and operator is trying to eliminate. In fact this is why manufacturers of large transport category aircraft do things a little differently than an Accel-Stop distance chart. Rather than using a chart that is only good up until one specific airspeed, they use charts/computers that do things the other way around. In addition to the normal variables like winds, temperature, and weight, the pilot will also input the length of runway he has to work with, and the computer program (or chart) will output an airspeed specific to those conditions (V1 - or takeoff decision speed). Below that airspeed, the pilot will have enough space to reject the takeoff and stop, above, he can be confident he has the space to fly away. There is no ambiguity with this method as its not based on one specific airspeed. If the runway is longer, takeoff decision speed (V1) increases to account for that extra length.

So that is the challenge for me. Create a computer program that rather than OUTPUTTING a distance like the Accel-Stop chart, it allows me INPUT the length we have to work with, and OUTPUT the takeoff decision speed that corresponds to that runway length (and the other variables). Easier said that done. I'm still working on it, but it has been a fascinating exercise so far. This is where math comes in, so I may lose the interest of a lot of my readers here, but if you're the kind of person who finds joy in applying math to real life, you'll LOVE this. The key to this whole solution is the kinematics formula of:

V = √2DA where

V = velocity (or our magic decision speed - V1)

D = distance

A = rate of acceleration

I get so excited when physics can be applied to real world scenarios!!

D is of course user-inputted, but A is going to be the magic value I need to figure out. This formula is for constant acceleration, so it doesn't COMPLETELY work out in the real world. In the real world as our velocity increases, so does air resistance to the square of velocity. This means that as we go charging down the runway, our rate of acceleration is actually diminishing as our speed increases - so how do we fit a changing rate of acceleration into the equation? The answer is to find our AVERAGE acceleration (from the point of stationary to our decision speed V1), and plug that into the equation - but how do we find that?

Well this is the fascinating challenge. I started by going to the Accel-Stop chart provided in the flight manual. This chart gives us two variables that we can use to find our average rate of acceleration - it gives us the distance of course (depending on the conditions), and it also defines the speed at which we accelerate to - which is 89 mph. The distance however is distance it takes to accelerate to 89 mph, and then decelerate back to 0, so we have to separate those two distances. There's an easy way to do this - the flight manual also provides a takeoff performance chart which gives the ground roll distance to accelerate to Vr. This is perfect, it gives us our acceleration distance right there, and we can get our deceleration portion by subtracting that from our Accel-Stop distance. Now we can calculate our average rate of acceleration for the acceleration portion, and the same for our stopping portion. We do this using this formula:

A = V^2/2D

Its the same formula as above, just solving for A instead of V. Simple. Now we have our value for rate of acceleration - so we've made some progress! Except we're not quite there because this acceleration value is only valid for one speed - the speed defined in the Accel-Stop chart. Because as you remember our rate of acceleration is going to change depending on our speed and the corresponding wind resistance. If we make our V1 speed higher than 89 mph, our average acceleration value will be less, if we make our V1 speed lower, our average acceleration will be higher. This is where it gets REALLY interesting, because some experimentation is in order, and this is where I haven't figured everything out yet, so I'm really enjoying it as a good brain challenge.

I know that I can calculate acceleration by using:

A=V/t

where t is time. So when we take-off I can time how long it takes to accelerate to a number of different speeds to get a good range of data (for example take the time as we pass through 60 mph, 70, 80, 90, and 100) and then we can plot that as a curve and extrapolate/interpolate as needed and calculate our average acceleration based off of that. OR......

I can download an app on my Android phone that records measurements using the phone's accelerometers! I found a neat app that does just that, and charts the measurements as G's on all 3 axis. 1 G equals 9.81 m/s^2, so that's easy enough to convert the G measurements into acceleration. I've been playing with this feature for the last couple flights, and I must say, it works amazingly!! The app allows me to export the data into a spreadsheet. I can then calculate velocity from the raw G readings and graph it in excel.

Check THIS out:

This is a graph of today's takeoff taken from the data collected by my phone's accelerometers, and charted as speed (mph) over time (seconds) in excel. Isn't that a beautiful curve!?! Who would have thought I'd be able to produce such a beautiful curve from real world data collected by a smartphone!! Amazing. I haven't doctored the data at all except to delete everything after the point where we were airborne. Note the takeoff roll doesn't start until 6 seconds in, because that's the time between when I started recording data and when the Captain started the takeoff roll. So our takeoff roll took roughly 27 seconds, and we were airborne at a speed of around 110 mph.

Also note the sharp increase in acceleration at very beginning (probably due to the throttles being advanced and more power being added), and then the gradual decrease in acceleration (shown as the slope of the curve) as we picked up speed and air resistance became a bigger factor. I know the phone's sensors are kicking out accurate readings because the results I achieved were bang on the money with our airspeed readings (it was a calm day). I never imagined in a million years the data would come out this clean.

Using this data I can calculate our average acceleration at ANY airspeed, which I can then use to find our distance traveled (with I think a fairly high degree of real world accuracy). Voila! We have the brain behind our computer program.

The only problem is that these acceleration values are only good until we become airborne. After which there's a whole new set of kinematics in play that I still have to figure out, but I'm fairly confident with a few more data-recording sessions in the airplane and some math I'll be able to nail it down. Once I do, its a matter of writing the computer program to process the math and solve for velocity, and bingo, we can figure out exactly what decision speed corresponds to our given runway length.

I know, I'm a nerd, but seriously, isn't it amazing when you can use math, an android smartphone, and computer programming to make something useful?