Active Altitude Control

The Rocketry Forum

Help Support The Rocketry Forum:

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

diyaerospace

Well-Known Member
Joined
Sep 21, 2021
Messages
217
Reaction score
108
Hello!

Me and some of my friends started working on a rocket that will use a variable drag brake system to control its altitude.
My idea for this was to use a pressure sensor to read the altitude of the rocket in real time and compare it to the rocket's ideal altitude. I will model the ideal altitude as an array in the flight software, calculating the ideal altitude will be done by looking at altitude points at certain time steps in rocksim. Using the difference in the actual and ideal altitude I can generate an error, and I plan to use a proportional control algorithm to generate angles for the drag brakes.

I have started writing a simulation in Arduino to model the rocket's flight and calculate the ideal gain for the control system. I will use a software in the loop test to validate the flight software before I fly it on this rocket. We plan to have our first launch in early October.

Here are some issues I have encountered with my Arduino simulation. (I have solved a lot of these, I just thought it would be cool to share things to watch out for)

1) Drag equation
Since my whole system depends on drag force I have to precisely model drag in my simulation. The equation on the NASA website doesn't work for me. The rocket flies way higher and its coasting time is far too high. I found this equation that works a lot better for me.
https://www.grc.nasa.gov/www/k-12/rocket/termvr.html
2)Cd changes
In most model rockets the coefficient of drag is a constant. But because we change the rocket's frontal area, the Cd also changes. I am still working on this aspect of the simulation.

Feedback would be appreciated,
Walter
 
Interesting idea.

Since Drag is dependent on Velocity how are you determining the Velocity? Differential Altitude?
There are two problems with using Altitude for velocity:
1- differential calculation becomes very noisy and then needs filtering.
2- It calculates the Vertical velocity not the true velocity ( flight not perfectly straight up).

Possibly you can include an Accelerometer and to use to calculate velocity. This fixes the two issues above:
1- Velocity is the integral of acceleration which is much less noisy.
2- Calculate True Velocity.
 
Last edited:
Interesting. Is there an application for this, or is it just an interesting challenge?
The equation on the NASA website doesn't work for me. The rocket flies way higher and its coasting time is far too high. I found this equation that works a lot better for me.
https://www.grc.nasa.gov/www/k-12/rocket/termvr.html
You say the NASA equation wasn't working, but then the source you cite as 'working' is also NASA. Just curious, but what was the non-working equation?
2)Cd changes
In most model rockets the coefficient of drag is a constant. But because we change the rocket's frontal area, the Cd also changes. I am still working on this aspect of the simulation.

If you have the rocket, and ability to control the drag, it seems as though a few flight tests should produce the data needed to model this, right? I think the fact that you're using feedback control means you don't need to get this exactly right, anyway. Are you using Kalman filtering on the altitude/velocity data?
 
I have long pondered such a system. Here's a very quick description of what I envisioned.

1) A simple drag brake that is either deployed or not, all or nothing. It is only for deployment during coast phase.

2) Model the flight of the rocket with the brake deployed, either by simulation or, preferably, by empirical measurement. Derive a curve of velocity vs. distance to apogee. Store this in your flight computer.

3) During flight: once you enter the coast phase, track velocity and altitude, and derive distance to desired apogee. As soon as the values intersect the curve created in step 2, deploy the air brakes.

That's it.

There are ways to enhance this but as a first pass I believe it would work very well and be fairly straightforward to implement.
 
Interesting idea.

Since Drag is dependent on Velocity how are you determining the Velocity? Differential Altitude?
There are two problems with using Altitude for velocity:
1- differential calculation becomes very noisy and then needs filtering.
2- It calculates the Vertical velocity not the true velocity ( flight not perfectly straight up).

Possibly you can include an Accelerometer and to use to calculate velocity. This fixes the two issues above:
1- Velocity is the integral of acceleration which is much less noisy.
2- Calculate True Velocity.
I believe you are talking about calculating drag in real life not in the simulation. I don't think the rocket needs to know drag during the flight. What do you think?

For the simulation, I integrate the motor thrust into acceleration, then into velocity, then I use velocity to calculate drag.
 
Yes, on a real flight.

An Accelerometer is also very good for measuring the actual drag and calculate the Cd of the rocket. Due to many variables in construction, Sims are a guess at what the Cd will be. Can also be used the measure the drag of your Air Brakes.
Tim at Apogee has written a a paper on the method to do the calculations. Works very well.

Wondering how you are going to do the mechanics of the air brakes.
 
Last edited:
Yes, on a real flight.

An Accelerometer is also very good for measuring the actual drag and calculate the Cd of the rocket. Due to many variables in construction, Sims are a guess at what the Cd will be. Can also be used the measure the drag of your Air Brakes.
Tim at Apogee has written a a paper on the method to do the calculations. Works very well.

Wondering how you are going to do the mechanics of the air brakes.
For the mechanics, we plan on using a linear actuator to push 3 flaps out evenly. It's going to be 3d printed and we are working on a CAD right now.
 
I would approach this from a different direction. You're most interested in stopping at a particular altitude. With 3-4 test flights and deploying the drag brakes at different times, you could get a pretty reliable curve of stopping distance vs. initial speed. From there, it should be pretty straightforward to use your Arduino to determine when you want to deploy the drag brakes. A little refinement in the code would then allow you to back off or increase braking power as needed to hit the altitude exactly.

Good luck at TARC!
 
I would approach this from a different direction. You're most interested in stopping at a particular altitude. With 3-4 test flights and deploying the drag brakes at different times, you could get a pretty reliable curve of stopping distance vs. initial speed. From there, it should be pretty straightforward to use your Arduino to determine when you want to deploy the drag brakes. A little refinement in the code would then allow you to back off or increase braking power as needed to hit the altitude exactly.

Good luck at TARC!
That's pretty close (or perhaps identical) to what I proposed above. At minimum, it seems like an appropriate starting point because it should be very simple to execute.
 
That's pretty close (or perhaps identical) to what I proposed above. At minimum, it seems like an appropriate starting point because it should be very simple to execute.
Sigh. That’s what I get for not fully reading the comments while I have my hand up for teacher to call on me. :D
 
Have seen several similar systems used at the TARC finals, with variable success. But if TARC is your goal, definitely worth working on. Good luck.
 
I have long pondered such a system. Here's a very quick description of what I envisioned.

1) A simple drag brake that is either deployed or not, all or nothing. It is only for deployment during coast phase.

2) Model the flight of the rocket with the brake deployed, either by simulation or, preferably, by empirical measurement. Derive a curve of velocity vs. distance to apogee. Store this in your flight computer.

3) During flight: once you enter the coast phase, track velocity and altitude, and derive distance to desired apogee. As soon as the values intersect the curve created in step 2, deploy the air brakes.

That's it.

There are ways to enhance this but as a first pass I believe it would work very well and be fairly straightforward to implement.
Sorry, it took me so long to get to your reply,

I am a little confused about the logic for determining the correct altitude to deploy the air brakes in an actual flight. You model the flight of the rocket with the air brakes deploying at an altitude that gives your apogee at the target apogee.

In an actual flight when the rocket reaches the altitude in the simulation that the air brakes are deployed does the rocket deploy the air brakes?
If so this seems a little susceptible to weather cocking as I do not simulate that.

Thanks for your help,
Walter
 
I have seen airbrake-equipped rockets at TARC launches. The concept is feasible.

Whether or not it’ll be tolerant enough of the many variables encountered in rocket flight to give you a degree of success is beyond my ability to determine. Nor am I really in a good position to recommend mathematical models.

Still, your project is interesting enough for me to keep an eye on. Good luck!
 
(Hopefully not stepping on Neil again)

I see this as a three variable problem:
A = current altitude
V = current upward velocity (note discussions above about off-vertical flights and the need to smooth out velocity)
D = stopping distance at your current velocity. I would guess that this is a polynomial function of V with a power of 1 or perhaps 2. You can probably get close to the right equation using drag coefficients, but I would expect you’ll need to refine the model with several test flights. Don’t neglect the importance of designing your drag mechanism to deploy quickly and cleanly.

When A + D = target altitude, your Arduino would trigger a servo that deploys the drag mechanism. In your function of D, you will want to take processing and deployment time into account.
 
That’s agreed with what’s in my head. The only change I would make is to make heavier use of empirical measurements to figure out the function of A, V, and D.

I admit I didn’t take A into account in my thinking. That complicated it a bit… although I’m not sure how large the effect is if you consider that you’ll usually be deploying the brakes at roughly the same altitude. If you’re switching between launch locations at vastly different altitudes, though, that could make a big difference.
 
I will try running neil's idea in my sim and see if that will work for our setup. For calculating stopping distance on an actual flight could I run live simulations on the flight software?

Thanks for the great ideas,
Walter
 
After thinking about how to determine the stopping distance once the brakes are deployed I think of two ways to do it.

1) You can use rocksim or open rocket to simulate Cd changes during flight and put a simple number into your flight computer as the stopping distance. The issue with this is that we rely too heavily on the simulations meaning we will likely have to tune the response with actual test flights.

2)You can run live simulations on your flight software with real altitude and velocity. Using this you can predict the stopping distance in real-time. The problem with this is that you will have to run simulations at a high frequency to be effective. My Arduino runs at 44 Mhz so I might only be able to run sims at 5Hz which may not be fast enough to be effective. I am just speculating here so if anyone with more insight could give their opinion I would appreciate it.

Thanks,
Walter
 
After thinking about how to determine the stopping distance once the brakes are deployed I think of two ways to do it.

1) You can use rocksim or open rocket to simulate Cd changes during flight and put a simple number into your flight computer as the stopping distance. The issue with this is that we rely too heavily on the simulations meaning we will likely have to tune the response with actual test flights.

2)You can run live simulations on your flight software with real altitude and velocity. Using this you can predict the stopping distance in real-time. The problem with this is that you will have to run simulations at a high frequency to be effective. My Arduino runs at 44 Mhz so I might only be able to run sims at 5Hz which may not be fast enough to be effective. I am just speculating here so if anyone with more insight could give their opinion I would appreciate it.

Thanks,
Walter
Option 1 would be a good approach for testing purposes. You know that you're going to want to trigger at *some* altitude, so you may as well just choose one and not worry about the rest of the code. If that works to reliably get the altitude you want, then that's a bonus.

Option 2 is probably more flexible in terms of dealing with flights that for whatever reason are higher or lower than the average. I wouldn't worry too much about "only" sampling at 5 Hz. If you're sampling faster than that, you likely will have much noisier data due to the precision of the sensors relative to the changes in altitude between each measurement.

If you are going to do an Option 2, make sure that you're recording the data that the Arduino is using to make decisions. That way, you can debug them when they're doing something you don't expect.
 
Yes, on a real flight.

An Accelerometer is also very good for measuring the actual drag and calculate the Cd of the rocket. Due to many variables in construction, Sims are a guess at what the Cd will be. Can also be used the measure the drag of your Air Brakes.
Tim at Apogee has written a a paper on the method to do the calculations. Works very well.

Wondering how you are going to do the mechanics of the air brakes.
Can you give me a link please?
 
The problem with using an accelerometer for drag brakes is that you basically are going to be decelerating at a relatively slow rate after the first few seconds past burnout, when the drag (which is proportional to V^2) goes way down, so it's a lot harder to tell when exactly to hit the brake. You're better off using the baro altitude and hitting the brake at a fixed baro-based altitude. You could use some kind of sensor fusion algorithm, but the baro sensor is going to be the preponderant term in that equation so you might as well just ignore the accelerometer and make the math easier.
 
The problem with using an accelerometer for drag brakes is that you basically are going to be decelerating at a relatively slow rate after the first few seconds past burnout, when the drag (which is proportional to V^2) goes way down, so it's a lot harder to tell when exactly to hit the brake. You're better off using the baro altitude and hitting the brake at a fixed baro-based altitude. You could use some kind of sensor fusion algorithm, but the baro sensor is going to be the preponderant term in that equation so you might as well just ignore the accelerometer and make the math easier.
I have an IMU and a BMP 388 sensor onboard. I will use baro altitude for the equation. Could I use differential altitude to calculate velocity or should I use the accelerometer?

Thanks,
Walter
 
Differential altitude to Velocity is noisy so filtering is required which causes other issues.
Integrating Acceleration to Velocity is much smoother (averaging is filtering) so better.

Cris, my suggestion is use Accelerometer to determine Cd of rocket without and with airbrakes deployed to predict when to apply then using Baro Altitude.

To hit a 'target altitude' one must use a altimeter and not accelerometer.
 
Hello!
Here is a quick update.
I just finished the simulation. I used the simulated altitude and acceleration to run the software in the loop testing. Here is a screenshot of that! The next steps are to run live simulation on the flight software to figure out the stopping distance with airbrakes deployed.
 

Attachments

  • Screen Shot 2022-09-21 at 4.45.24 PM.png
    Screen Shot 2022-09-21 at 4.45.24 PM.png
    36.5 KB · Views: 2
Back
Top