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.
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.
I think you can get a decently accurate Cd with the airbrakes deployed by taking the Cd of the rocket without the airbrakes from you sim, multiplying it by it's frontal area, adding the surface area of the airbrakes (which you can assume to have a CD of 1). and dividing by the total surface area). Cd(total) = ( (Cd(rocket) * A(rocket) + A(airbrakes) ) / ( A(rocket) + A(airbrakes) )
 
Hello,

Just wondering if anyone has suggestions for equations to calculate drag on a model rocket. I have already unsuccessfully tried Drag Coefficient X 1/2 density X velocity squared X area.
I will use this for live simulation to find the stopping distance so it has to be fairly accurate.

Thanks,
Walter
 
Hello,

Just wondering if anyone has suggestions for equations to calculate drag on a model rocket. I have already unsuccessfully tried Drag Coefficient X 1/2 density X velocity squared X area.
I will use this for live simulation to find the stopping distance so it has to be fairly accurate.

Thanks,
Walter
How are you measuring and using area? Also how are you determining drag coefficient? The equation looks correct but it’s easy to mess these numbers up.
 
How are you measuring and using area? Also how are you determining drag coefficient? The equation looks correct but it’s easy to mess these numbers up.
I use the drag coefficient the rocksim gives me, around 0.55.
As for calculating frontal area, I guessed it at around 0.2 square meters. We will use our vehicle cad model to calculate this later. These numbers don't seem to have a huge effect on the simulation as long as they are not grossly off.
 
Oregon Episcopal School had a drag-brake rocket that worked consistently enough for them to win TARC 2021 (they also used a couple of small quadcopter motors and props to adjust their descent rate to hit the time target). They almost had two perfect scores at the (distributed) finals. One flight was perfect. The second disappeared from view of the timers behind a barn….or it would have been perfect as well. If they’d programmed for the middle of the three-second time-of-flight window, they would have had two perfect scores as well.

That same school came to the TARC finals this year and — well — the results were not nearly as good. They got to the finals, but they finished in the middle of the pack. I don’t recall either their score or their reasons for not doing as well (I was working returns, but I don’t think I actually talked to them directly as we had three pairs of returns folks running in parallel).

I also don’t know any details about their software but I suspect the discussion above is a good basis. But it also has to be mechanically reliable and repeatable. This is where an enthusiastic but software-centric team I was working with found themselves abandoning the active controls effort.

If Oregon Episcopal had won again this year, I expect there would have been some rules changes to restrict robot rockets. But they didn’t. The same school had the top two finishers this year….and they did it the old fashioned way - measure everything, do everything consistently, and practice, practice, practice.
 
Hello,

Just wondering if anyone has suggestions for equations to calculate drag on a model rocket. I have already unsuccessfully tried Drag Coefficient X 1/2 density X velocity squared X area.
I will use this for live simulation to find the stopping distance so it has to be fairly accurate.

Thanks,
Walter
I'm sure you haven't forgotten, but just in case... Don't forget the effect of gravity on deceleration, in addition to drag.

How is your current equation set unsuccessful? If all we know is that it didn't work, there's not much to go on.
 
Hello,

I got velocity estimations working and am doing some SITL to validate my model. The only hiccup I have had is how angling the sensor leads to velocity increases as the accelerometer senses the tilt. In the case of an actual flight, I can expect a few m/s of deviation. I still don't know if this is a large enough amount to lead to serious deviation from the target altitude as I am doing live simulation to find the optimum stopping distance.
I can also use differential altitude to calculate velocity and fuse the measurements to get a more accurate speed estimate.

What do you all think?
 
I think your next step is the actually fly the sensors and log the data.
Then back this 'live' data into your simulations to see how much they match and learn where and how to do corrections.

I recommend a few flights without the 'airbrakes' deployed then a few flights with the 'airbrakes' deployed. Take the Accelerometer measurements during coast to calculate the true Cd.

Also try doing the integrated acceleration to Velocity and compare to your sim.


As to tilt, the 3-axis accelerometer data (calibrated) can be used only when the rocket is on the pad to calculate tilt. Once it leaves the pad accelerometer data can NOT determine tilt since there is NO reference to Earth's gravity.
There are two methods to determine tilt while in flight:
1- integrate calibrated Gyro data to change of angle from starting reference angle.
2- compare double integrated accelerometer data (distance) to baro Altitude data. The baro give true altitude whereas the accelerometer give distance traveled. If any tilt then the accelerometer derived distance is LESS than the Baro altitude.
 
I think your next step is the actually fly the sensors and log the data.
Then back this 'live' data into your simulations to see how much they match and learn where and how to do corrections.

I recommend a few flights without the 'airbrakes' deployed then a few flights with the 'airbrakes' deployed. Take the Accelerometer measurements during coast to calculate the true Cd.

Also try doing the integrated acceleration to Velocity and compare to your sim.


As to tilt, the 3-axis accelerometer data (calibrated) can be used only when the rocket is on the pad to calculate tilt. Once it leaves the pad accelerometer data can NOT determine tilt since there is NO reference to Earth's gravity.
There are two methods to determine tilt while in flight:
1- integrate calibrated Gyro data to change of angle from starting reference angle.
2- compare double integrated accelerometer data (distance) to baro Altitude data. The baro give true altitude whereas the accelerometer give distance traveled. If any tilt then the accelerometer derived distance is LESS than the Baro altitude.
I have already done several flights with a data logging system and the results have been mostly successful! For calculating tilt I integrate gyroscopes.
Thanks for the tip about accelerometers in flight, I will offset the accelerometers on the pad to avoid drift.
Walter
 
Ok, sounds like you are on your way.
Do get the Gryo offset from just before launch, assumes no motion, and subtract from each gryo reading. Gryos have the worst drift but mostly longish term so easy to correct.

I start logging when the 5 second count down starts (logger controlled through a WiFi web app. Then in post processing take an average of the gryos before ignition and use that as the offset.
 
Here is an update on my progress.

I have decided to switch back to my original approach of having a variable drag system instead of the drag brakes being on or off. This is because I am not sure how well the system will respond to changes in rocket orientation and other non-measurable factors. The deployment altitude would have to be 50-100 ft in advance and that seems like a lot of time for the actual altitude to deviate from the simulated altitude.

A variable system has the advantage of actively controlling altitude all the way up to apogee so the system is a lot more robust.
I just got the simulations to work and the results are pretty good! I had to add velocity control to my system to get altitude control to work well. I am still very happy with the results, altitude is within a few feet of the target altitude! Hopefully, the simulation matches reality.

Thanks for everyone's help!
 

Attachments

  • Screen Shot 2022-09-25 at 10.59.12 AM.png
    Screen Shot 2022-09-25 at 10.59.12 AM.png
    61 KB · Views: 1
Hello,
We are looking for a small altimeter that can record peak speed and altitude. The firefly looks good but I am concerned as I think it measures the speed with differential altitude. Since I am using peak speed to calculate Cd (and compare readings from my altimeter) the firefly needs to be somewhat accurate. What do you think, is there a better altimeter we can use?

Thanks,
Walter
 
Hello,
We are looking for a small altimeter that can record peak speed and altitude. The firefly looks good but I am concerned as I think it measures the speed with differential altitude. Since I am using peak speed to calculate Cd (and compare readings from my altimeter) the firefly needs to be somewhat accurate. What do you think, is there a better altimeter we can use?

Thanks,
Walter
If you want altitude and velocity, you probably want a Pnut. If you can solder, and Eggtimer Ion would also do the job. There are a few more out there (Flightsketch, Jolly Logic), but I don't know what availability looks like for those.
 
I believe the Pnut is also baro-only. If you want accelerometer-integrated speed, iirc the Jolly Logics are the easiest standalone option - a few of the dual-deployment altimeters have accelerometers but they tend to be on the pricey side.
 
FireFly, Pnut and Eggtimer ION are all barometric only.

There are accelerometers in Jolly Logic AltimeterTwo and Three, and FlightSketch Mini and Comp. You might be able to find an AltimeterTwo.
 
Another idea to consider is that instead of pulling accelerometer data, you could use time-altitude barometric data to interpolate a polynomial curve. Over a sufficiently long period of time (say the first 3-4 seconds after burnout), the errors in the baro-only data will average themselves out. You can then take derivatives off of the interpolated curve to get velocity and acceleration.
 
Late to the party, but I am more of a KISS principle guy anyway.

Controlled Break-Away deployment. Plan on a rocket motor and design that easily meets and exceeds deployment altitude (and time if required.). Rockets don’t decelerate instantaneously, but depending on deployment Configuration, they can slow down pretty darn fast. If your first deployment is to break the rocket into separate components (connected by elastic tethers) and each with a streamer or other high drag attachment (chutes are likely to shred or break shock cords or attachments unless you have very long and stretchy shock cords.). I may be wrong, but I am guessing that breaking the rocket into 4 or more parts, each with a streamer, it is not going to gain much altitude (maybe 30 feet) after initial deployment. I don’t know the rest of the requirements for descent time (and I don’t know how well an egg payload would survive such a rapid deceleration.). Also don’t know how consistent it would be (maybe sometimes 20 feet, sometimes 50.)

the other approach is the “if you ain’t cheating you ain’t trying” approach. Again maybe the rule makers anticipated this. If the goal is to get a payload to a certain altitude, and the Score is calculated based in the ON BOARD altimeter, eject (but maintain attachment) the part of the rocket WITH the altimeter with a long (maybe daisy chained) shock cord just shy of target altitube, maybe with a draggy fin unit and a streamer. NOT sure if rules say this segment must contain the payload. Rest of the rocket, possibly with much of the mass, is now unstable (may still carry the motor casing), is tumbling and either the ejected segment or the traveling unstable unit holds the shock cord, trailing out, bulk of rocket continues up but is slowing down, finally deploys the chute. You may need 100 feet of shock cord.

point is, if you can separate the altimeter and if required the payload from the bulk of the rocket (think @Daddyisabar tractor motors with payload and altimeter in the BACK) you can minimize the mass and maximize acceptable drag on the CRITICAL components of the rocket (I,e, the score-able segment) thus minimize (and possibly make more consistent) the altitude gain of the segment, with the long shock cord allowing the main mass of the rocket to make a more leisurely and less consistent (but who cares?) standard deployment. If your first component contains the fin unit (more mass but also much more inherent drag assuming unstable), then your remnant component will also immediately go unstable at separation and start slowing down by itself, prior to chute deploy,ent, so it won’t go far, and shock cord attachment will pull chute from upper segment prior to running out of shock cord, which will help.

point is, the ALTIMETER section upon which you are scored deploys just below target altitude, has low mass, high drag, and shouldn‘t go very far, so if your ALTIMETER is good and your ejection wiring system ignites initial deployment quickly, that section should hit (and stop near) target altitude fairly consistently. The REST of the rocket may travel another 100 feet, depending on length of shock cord, but assuming nobody is measuring from the ground, TECHNICALLY your MEASURED altitude is that of the initially deployed segment.

an additional option would be streamers attached every 10 or 20 feet on the long shock cord, so the cord itself also slows the non-scored rocket segment, may get away with shorter shock cord although need more space for multiple streamers.
 
Last edited:
Here is an update,

I have finished attaching the fins to the lower section of the rocket. I using TTW fins so they won't break off in a stupid way. I also finished recovery and am printing the drag brake system right now. The software is finished and I hope to fly in the next week or two!

Walter
 
It looks like plastic servo horns will not work for the drag brakes :( They bend and might even break off during the flight. I need some metal servo horns for the SG90 9-gram micro servos I am using.
After lots of googling, I found these: https://www.amazon.com/AGFRC-Metal-Micro-A20CLS-B13DLM/dp/B0B1V4GYH2
Do you think these will work? If anyone else has any suggestions please let me know!

Thanks,
Walter
 
It looks like plastic servo horns will not work for the drag brakes :( They bend and might even break off during the flight. I need some metal servo horns for the SG90 9-gram micro servos I am using.
After lots of googling, I found these: https://www.amazon.com/AGFRC-Metal-Micro-A20CLS-B13DLM/dp/B0B1V4GYH2
Do you think these will work? If anyone else has any suggestions please let me know!

Thanks,
Walter
Without seeing the mechanics I could not suggest what might work.
 
Without seeing the mechanics I could not suggest what might work.
My bad,

I attached an STL of the design. I printed this out and the main source of wiggle comes from the plastic servo horns. Hence my original question.

Thanks for you help,
Walter
 

Attachments

  • TARC drag brake system 2 (10).stl
    478.4 KB · Views: 0
Ok, now I see what you are trying to do. The Servo Arm and Bearings will take all the forces.
Metal arms will be better but may bend (upon landing hard).

Worth a try but buy at least two sets to have replacements on hand.

Another way will be to have the air-brake paddles on their own pivots. Then the Servo arm push them outward.
A third method is the air brake paddles on their own pivots but only one servo to push both. Use a double ended arm to push, one end traveling up the other traveling down.
 
Hello,

I am having an issue with these EMAX ES08MD II servos that I am using. When I hook them up to five volts and run a sweep sketch on them (commands servos to a value increasing by 0.1-degree increments) they behave erratically and make a buzzing noise.
I checked the voltage on the servo outputs on my flight computer and it stays at five. But when I attach a servo the output goes down to 1.5 volts. Is this the reason for the servos behaving strangely? If so, what should I do? I was thinking of feeding the servo six volts instead of five.

Thanks for your help,
Walter

 
Yes, the servos NEED 5V logic signal and a good 5V at several amps on its power leads.

How are you measuring the Servo Output signal??
It should be with an O'scope since it is digital and pulses high/low. This can not be measured with a DVM.

Also ensure the
Power is staying at 5V. Servos do draw a good amount of current.
 
Great News!
We launched our rocket twice at Lucerne Dry Lake today.
The first flight was unsuccessful because the motor shot up into the airframe and separated the vehicle on the pad.(I will post videos soon) We were able to fix the rocket and launch again. This time things went a lot better! The rocket was stable and we successfully recovered it. The onboard avionics use a barometer and accelerometer to determine altitude and velocity. The estimates were not that bad. We used a jolly logic altimeter 2 as a control.
Jolly Logic. Flight computer
altitude 354. 380
velocity 105 115
acceleration 6.3G. 8G

In the future we will need more precise estimates. I plan on using a complementary filter to fuse barometric and accelerometer altitude measurements. The 1.7G acceleration difference is enough to cause some serious issues. I don't know why the accelerometer overcompensated. What are your thoughts?
I used the Adafruit LSM6DS03


Thanks,
Walter


EDIT
Another goal of this flight was to measure Cd with drag brakes open and closed. However we were only able to fly with the drag brakes closed. Are there any ways other than flying again to find the Cd with drag brakes open?
 
Last edited:
I used the altitude back tracking method mentioned in Tim's article to find the Cd of the rocket. It is 2. Is this reasonable?
 
Years ago, I saved paper towel rolls for a few years, and used about 100 of them as the linearizer for a small wind tunnel for rockets. You use a large shop fan, some AC ductwork, and a grid of the tubes just before the rocket mounting point. The tubes kill the vortex the fan makes. I used a linkage and scales to read the force. A wind gauge gives you airspeed. It worked great for a year or so, then got disassembled to reclaim garage space. It cost me $10 for the fan, and about that for the duct tape. I found a piece of duct in a dumpster, lol. So, a $20 wind tunnel.
 
Jolly Logic. Flight computer
altitude 354. 380
velocity 105 115
acceleration 6.3G. 8G
Not too bad of a difference.

There are a few reasons the two do not match.
1- Is the Accelerometer outputs properly calibrated? There is typically some offset that needs to be subtracted from each reading.
2- The Jolly Logic is Baro only. Its reported Altitude should be pretty good in converting air pressure to Altitude. However, to obtain Velocity and then Acceleration the Altitude data is differentiated which creates noise is the data. Most alt devices first filter the alt data then different. This adds a delay and rounds peaks causing some error. The Velocity is then filtered and differentiated to get acceleration again causing more error.
So the Altitude is probably accurate, the Velocity has error and Acceleration has more error. I would not trust the Acceleration value derived from a Baro.
3- Integrating Acceleration data twice to get Altitude works well and reduces noise. However, this measures Distance Traveled NOT Altitude. If the flight is not perfectly straight up then the distance traveled is greater than the Altitude reached. The difference of 354 to 380 is 7% so these are pretty close.

I used the altitude back tracking method mentioned in Tim's article to find the Cd of the rocket. It is 2. Is this reasonable?

A Cd of 2 sounds to large. What does a sim calculate for Cd?
Most rockets I've sim'ed have Cd of 0.4 to 0.8. If the rocket has Draggy features then a Cd of 2 is possible. Just mod'ed a design to test this. Increasing fin thickness from 3mm to 13mm increased Cd from 0.7 to 1.5. So a Cd of 2 is possible.

What data did you use for the Velocity and Acceleration?
I have found the the Accel data and integrating Accel to Velocity works best.
Then plot the Acc verse V squared and find the slope. This should be a small negative value.

A Wind tunnel as Grog6 described is the standard way Aerodynamic drag is measured.
 
Last edited:
Back
Top