Active Altitude Control

[Alan15578]

A Wind tunnel as Grog6 described is the standard way Aerodynamic drag is measured.

NO, but yes to a decent university or professional wind tunnel.

I do not fly HPR, but I always thought active control of a retro rocket would be a great feature for staying under the waiver limit.

 

[diyaerospace]

1- Is the Accelerometer outputs properly calibrated? There is typically some offset that needs to be subtracted from each reading.

Possibly, how would I determine this?

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.

I believe the Jolly Logic altimeter two has an accelerometer.

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.

The flight was definitely not perfectly vertical. Because of the pitch angle after burnout the deceleration is felt on all three axis. However, to find velocity only the vertical axis is used. How would I integrated 3 axis acceleration to get "true" vertical acceleration?

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.

The simmed CG was 0.55, although that seems to low. The rocket is 56mm in diameter but has "draggy features" ie drag brakes stick out a little in the closed position. Could the motor have underperformed? Simulated acceleration was 7.5G, alt was 550ft. We used an E30T motor.

What data did you use for the Velocity and Acceleration?

The flight computer uses barometric altitude and integrates accelerometers for velocity and altitude (I plan on using a complementary filter to fuse barometric and accelerometer based altitude readings)

Thanks for your help!

 

[waltr]

Accelerometer calibration is pretty easy.
Set the Accel so the axis of interest is perfectly vertical. Ideally it would read 9.81 m/s/s, the Earths gravity. Take a lot of samples (100 or more) and average to remove noise.
Flip the Accelermoeter 180 degrees and take samples and average. Ideally one set of measurements is 9.81m/s/s and the other -9.81m/s/s. More likely one is reading high and the other low. This would be due to offset error. For example let say you get 9.0 and -10.62.
Calculate the difference of the magnitudes, |-10.62| - |9.0| = 1.62.
Divide by 2 = 0.81. Since the negative is larger the offset error is -0.81. Subtract this from every measurement made. 9.0 - (-0.81) = 9.81 and -10.62 - (-.81) = 9.81.
This is most like the largest error however there may also be a gain error.
Now say the two averaged measurements are 8..9 and -10.52.
Offset error is the same, -0.81. however when subtracting the offset error we get +9.71 & -9.71 instead of 9.81. This is a gain error. The calculate and apply:
First calculate the actually 'gain' : 9.71/9.81 = 0.9898 which means the 'gain' is low.
To apply divide the offset corrected value by the 'gain' error. 9.71/0.9898 = 9.81 a value that matches the Earth's gravity.

I have done the measurements and calculated the corrections and put them into a file. These are then read by the code that does the calibrations to the raw data. If the on-board process is doing the calculations then these correction can be in the embedded processor code.

When you integrate the Accel measurements each tiny error adds up in time. This is why a good calibration is very important.

Have you logged all the RAW data? If so then you can do corrections, integrations, etc Post Flight and find what worked or not in the calibration and math.

 

[waltr]

Which Jolly Logic altimeter?
The 'One' is Baro only. The "Two" has a Baro +64g accelerometer. The "Three" I'm not sure of but description implies a GPS.

This takes us back to your accelerometer.
With all three Accel axis calibrated and start with the 3-axis measurements while the rocket is still on the rod/rail. You can calculate the launch tilt angle.
Then using the 3-axis Acc data upon launching and Trig you can calculate the 'vertical' component of the flight. I have not gone through how to do this yet.
This is what the JL Alt 2 must do since the orientation of the JL2 is not fixed to the rocket's axis.

Last, there can still be a non-match of Acc, Vel & Alt between the two systems. All measurement and systems have errors. If the Values between two systems are close, a few %, then we typically consider all is good.

 

[waltr]

Here is a paper about Barometric Adjustment to vertical Accelerometer measurements:
And an Excel worksheet example of doing the calculations:

Very good read and an excellent derivation of equations.

 

[waltr]

Drag Cd is interesting and we tend to simply believe what the Sim program calculates.
Your 'air-brake' method does relie on knowing the Cd with and without the air brakes applied so obtaining this important.
A Good wind tunnel is one way but a good wind tunnel is not easy to build or get to use.

Tim's method of using the Deacceleration actually is an interesting method and possibly now due to the accelerometer chips available to us. It does require the Accelerometer to to calibrated to obtain accurate measurements.

Did you get the full NARAM R&D paper or the earlier version Tim published in the Apogee newsletter?

 

[diyaerospace]

Hello!
Here is an update. I have realized that I forgot to make vent holes for the Jolly Logic Altimeter. The BMP 388 pressure sensor is positioned near a hole (about 0.5 by 0.5 inches wide). This would likely cause air turbulence which may render the readings useless.
The only piece of data that I have now is the measured velocity by the Jolly Logic altimeter. My plan is the "fix" the flight computer's velocity data with the methods in the paper Waltr posted. I can run software in the loop tests to validate said data and determine motor performance. Then I can make an educated guess of the Cd.
Does the Jolly Logic altimeter measure upward velocity or velocity on the vertical axis of the rocket?

Thanks,
Walter

 

[waltr]

Still do not know Which Jolly Logic Altimeter you are using, the 1, 2 or 3?

 

[diyaerospace]

Still do not know Which Jolly Logic Altimeter you are using, the 1, 2 or 3?

Jolly Logic Altimeter 2

 

[waltr]

Ok. I just read through the JL2 manual. Pretty nice unit for what it does.
Seems the Acc is used mainly to detect events and to get a time between events.

You can use these times and compare against your data.
It also record Peak Acc, Vel & Alt. Manual implies peak Acc is during thrust and peak Vel is at burn-out. If it gives a Time at these peak values then you can check to see when these event happened make sense.

The data from your sensor and the JL2 do match pretty close. on Alt & Vel. Acc of the two was a bit different.
How did you get the 8G acceleration? Is this value during Motor BURN? or some peak value from anywhere during the flight?

The JL2 acceleration of 6.3G sounds reasonable.
What motor did you use and what is the launch weight of the rocket.
You should also be able to get the peak accel from the sim.

 

[diyaerospace]

The JL2 acceleration of 6.3G sounds reasonable.
What motor did you use and what is the launch weight of the rocket.
You should also be able to get the peak accel from the sim.

Weight of the rocket was around 600 grams.
simed peak acceleration was 7.1G.
We used an Aerotech E30T motor.
The 8G of acceleration was logged during the motor burn, where peak thrust occured.

Quick question, should I be subtracting the force of gravity from the vertical acceleration during flight?

Thanks,
Walter

 

[waltr]

Weight of the rocket was around 600 grams.
simed peak acceleration was 7.1G.
We used an Aerotech E30T motor.
The 8G of acceleration was logged during the motor burn, where peak thrust occured.

Quick question, should I be subtracting the force of gravity from the vertical acceleration during flight?

Thanks,
Walter

Yes, subtract Earth gravity value during flight.

If you didn't then the 8g is 7g which matches your sim and closer the the JL2 value.

 

[diyaerospace]

Thanks!
Do anyone know if the JL2 measures vertical velocity or velocity that the rocket is traveling in?

 

[diyaerospace]

I have been running some Software In the Loop Testing to figure out how to process the accelerometer data. When I subtract the force of gravity and multiply by sin of the launch angle the result is far to low. (about 75 mph) This is due to accelerometer data that is to low. The JL2 reports 4.1G average, 6.3G peak, and 1.16 second burn time. My flight computer reports, 3.6G average, 7.1G peak, and 1.16 second burn time. Does anyone what could be causing these differences?

Thanks,
Walter

Flight computer reported thrust curve:

 

[boatgeek]

A few questions/comments:
It would be helpful if you plotted all of your data (including accelerations with horizontal lines showing what the JL2 reported) and included a time scale on the X axis.

You probably need a shorter time step, at least for initial debugging. It looks like your entire boost is happening in a single time step, which isn't going to help your predictions.

How close is your integrated velocity curve to your actual measured altitude?

In the long run, what you're looking for is good correlation between altitude measurements from the flight computer and from whatever altimeter you will be using to demonstrate that you hit a particular altitude. If this is a competition, your goal isn't so much to hit an absolute altitude as it is to hit an altitude as measured by your reference. At a bare minimum, your JL2 and your flight computer need to be in the same compartment of the rocket and not too near any vents.

 

[waltr]

I agree with boatgeek, looks like you are not sampling fast enough to follow the motor thrust curve.

In the data logger I use I sample at 50 times per second. I would prefer 100-200 sps but code will not do this.
I get a nice thrust curve for the Accel data and it looks like what is published in ThrustCurve.com for the motor used.
I also get very reasonable Velocity and distance from integrating the corrected accel data.

Not sure what you are trying to calculate with the SIN of the launch angle. Also, are you using the angle from Vertical? The Sin of this angle should be very small.

It would be helpful to us if you post the raw data and what the calculation is.

 

[jadebox]

I have been running some Software In the Loop Testing to figure out how to process the accelerometer data. When I subtract the force of gravity and multiply by sin of the launch angle the result is far to low. (about 75 mph) This is due to accelerometer data that is to low. The JL2 reports 4.1G average, 6.3G peak, and 1.16 second burn time. My flight computer reports, 3.6G average, 7.1G peak, and 1.16 second burn time. Does anyone what could be causing these differences?

Thanks,
Walter

Flight computer reported thrust curve:

Make sure the signs are correct - sitting on the pad, the force of gravity should be about -9.80 m/sec^2. When you subtract that from the accelerometer data, it is the same as adding 9.80.

 

[diyaerospace]

It would be helpful to us if you post the raw data and what the calculation is.

Sure thing!
The velocity data had a sign error so it is negative. It drifts because I forgot to account for the force of gravity

 

[waltr]

Thanks. I took the last columns which look to be Time, Accel x,y,z. Copied time + Acc x to new spread sheet. Inverted the Accel x to make thrust positive. Only did point from launch until before ejection at 4 seconds.
Then integrated Accel to Vel and Vel to alt. Here is a plot and the data.
These actually look pretty good. Units are in meters.

The motor seems to have 'chuffed' then fully lit but this does happen with composites.
Peak velocity of 37.57 m/s (123f/s), max altitude of 84.5 m (277 ft).
I used 9.6m/s/s subtracted from accel since this seems to be the pre-launch accel measurement.

 

[diyaerospace]

Thanks so much for everyones help!
I would like to fly again in a few days. Here is what I have in mind for improvements.
1. Place JL2 in same compartment as the flight computer.
2. Reduce air turbulence in the airframe.
3. Increase data logging rate from 25Hz to 30Hz (To capture more of the thrust curve)
4. Subtract the force of gravity from accelerometer measurements.

I believe the integration of accelerometer data is good. So the only thing to fix is the abnormally low accelerometer measurements by increasing the code's speed. This probably lead to the low altitude and speed (85 mph 277 ft).

How does this sound?

Thanks,
Walter

 

[waltr]

Good plan.

A suggestion to help get higher sampling speed.

The .txt data file you posted has a huge amount of redundant text in it. Eliminate most of it and then the processor needs much less time to write out the data.

What I do is first line written are the column headers. Example may be:
t, acc x, acc y, acc z, pressure, alt, State, Vel, etc.
Then only write out the data without units.

I think this can reduce the amount of characters written to 1/3.

This also allows you to easily import the data file into Excel or other spreadsheet and graph any of the columns.

 

[diyaerospace]

Good plan.

A suggestion to help get higher sampling speed.

The .txt data file you posted has a huge amount of redundant text in it. Eliminate most of it and then the processor needs much less time to write out the data.

What I do is first line written are the column headers. Example may be:
t, acc x, acc y, acc z, pressure, alt, State, Vel, etc.
Then only write out the data without units.

I think this can reduce the amount of characters written to 1/3.

This also allows you to easily import the data file into Excel or other spreadsheet and graph any of the columns.

Thanks!
Now it runs at 40Hz

 

[waltr]

40sps is better.

What does your data file look like now?

Are you able to get the same graphs I posted from your data?

A calibration of the Acel would also help.
This can be done post processing by taking a lot of samples as the rocket sits on the pad. Average then calculate offset and subtract from all accel reading.
This could also be done pre-launch, sample to get a 100 reading do average and offset to subtract from 'live' reading.

The Eggtimer Proton I just got for a 2-stage has a baro and accelerometer. Once armed on the pad it requirees 3 minutes to calibrate the accelerometer before launch. So not uncommon a need to do this.

 

[diyaerospace]

40sps is better.

After some more tweaking, it now runs at 200Hz

 

[waltr]

Wow, that is a huge improvement.
Nice job.

 

[AllDigital]

Walter (@diyaerospace),

I am coming in late here, but I really like your project. There is a lot to learn to get accurate data sampling from barometers and accelerometers on a rocket, but it sounds like you are on the right path.

Have you figured out what your braking logic will look like once you have good data to meet your "mission objectives"? Simplifying that logic might help you substantially simplify your data sampling needs.

For example, if you are using the brakes to hit a specific altitude (e.g., TARC or FAR 51025) then the barometer data might be all you need. You can get reliable altitude and speed from a pressure sensor (barometer) to build braking logic around. An accelerometer will give you a more precise and more responsive velocity, but I'm not sure if that is really required. A gyro might tell you if you are upside down, but that requires a massive level of computation and likely isn't needed if the objective is just to hit an altitude goal.

I've done over 100 launches with our custom flight computer capturing baro data, accelerometer data, gyro data, etc. The barometer I use samples at about 40 hz and on the way up, I report speed every 500ms as the average altitude differential of the last 20 samples. On the way down, I average over a four second period, since barometers can be much more noisy. That said, with the raw sample data you can choose any filter or average method to fit your needs.

If I use a flight I did last Saturday as an example... The flight went to 5665 feet, but if I was trying to hit 5000 feet using air brakes then I would probably set up logic to kick in around 4000 or 4500 feet (depending on how strong those brakes were). At 4500 feet, 11 seconds into the flight, I can see I am going 303fps and I've decelerated from 364fps a second earlier. So, I am clearly going to overshoot 5000 feet (apply brakes). On a smaller faster rocket you will need to sample your speed real-time with some type of trailing filter, but the concept is the same. I personally would get the setup working with just the baro and then move to integrate the accelerometer as a more precise next step (unless I'm missing something).

Attached is raw data from my flight on Saturday. Sometimes it helps just to have good raw data when you are trying to model or work out your own data sampling needs.

Mike

 

[diyaerospace]

Walter (@diyaerospace),

I am coming in late here, but I really like your project. There is a lot to learn to get accurate data sampling from barometers and accelerometers on a rocket, but it sounds like you are on the right path.

Have you figured out what your braking logic will look like once you have good data to meet your "mission objectives"? Simplifying that logic might help you substantially simplify your data sampling needs.

For example, if you are using the brakes to hit a specific altitude (e.g., TARC or FAR 51025) then the barometer data might be all you need. You can get reliable altitude and speed from a pressure sensor (barometer) to build braking logic around. An accelerometer will give you a more precise and more responsive velocity, but I'm not sure if that is really required. A gyro might tell you if you are upside down, but that requires a massive level of computation and likely isn't needed if the objective is just to hit an altitude goal.

I've done over 100 launches with our custom flight computer capturing baro data, accelerometer data, gyro data, etc. The barometer I use samples at about 40 hz and on the way up, I report speed every 500ms as the average altitude differential of the last 20 samples. On the way down, I average over a four second period, since barometers can be much more noisy. That said, with the raw sample data you can choose any filter or average method to fit your needs.

If I use a flight I did last Saturday as an example... The flight went to 5665 feet, but if I was trying to hit 5000 feet using air brakes then I would probably set up logic to kick in around 4000 or 4500 feet (depending on how strong those brakes were). At 4500 feet, 11 seconds into the flight, I can see I am going 303fps and I've decelerated from 364fps a second earlier. So, I am clearly going to overshoot 5000 feet (apply brakes). On a smaller faster rocket you will need to sample your speed real-time with some type of trailing filter, but the concept is the same. I personally would get the setup working with just the baro and then move to integrate the accelerometer as a more precise next step (unless I'm missing something).

Attached is raw data from my flight on Saturday. Sometimes it helps just to have good raw data when you are trying to model or work out your own data sampling needs.

Mike

Have you figured out what your braking logic will look like once you have good data to meet your "mission objectives"? Simplifying that logic might help you substantially simplify your data sampling needs.

I plan on using a proportional controller to control the rocket to a precise altitude by comparing calculated and measured altitude with a barometer and accelerometer to where we should be. I have a simulation to simulate this and the results are not to bad.

If I use a flight I did last Saturday as an example... The flight went to 5665 feet, but if I was trying to hit 5000 feet using air brakes then I would probably set up logic to kick in around 4000 or 4500 feet (depending on how strong those brakes were).

Someone else suggested this and I ran the simulations and the results are not very good. The problem is that there are to many variables and you loose all control after the drag brakes are deployed.

Thanks for the suggestions!
Walter

 

[diyaerospace]

I made a video on our launches!

 

[waltr]

Nice video and now I can see how your air-brakes are done.

Since they rotate what does that do the the rocket's trajectory?

Is that Lucerne Lake?

 

[diyaerospace]

Since they rotate what does that do the the rocket's trajectory?

Don't know yet. I plan to fly again this Sunday to find Cd with drag brakes open.

Is that Lucerne Lake?

Yes