Active Altitude Control

[waltr]

Did more calcu's from your data file and a Cd = 2 is reasonable.
I expect the Cd with brakes deployed to be much higher.

The Accel chip also has a Gyro. Calibrate to Zero while on pad then integrate to find angle.
This will be helpful to determine how much the air brakes cause a path change.

Mike is his post above has some very good points.
I think it is useful to use Accel, Baro and Gyro while in development of the air brake system.
Then once all is charaterized Baro only may be enough for deploying air brakes to hit target altitude.

 

[diyaerospace]

Just got two more flights done today.
Both flights had a successful ascent and recovery. They both logged data as well!

Flight 1
Jl2 data. Flight Computer
altitude: 349 ft. Baro altitude: 384 ft. Accel Altitude: 190ft
vel: 106 mph Vel: 71 mph
burn time: 1.10 seconds. Burn time: 0.9 seconds (when accel goes negative)
peak accel: 6.5G. Peak accel: 6G
average accel: 4.4G. Average accel: 4G

Flight 2
Jl2 data Flight Computer
altitude 337ft Baro altitude:347ft: Accel Altitude: 228 ft
vel: 103mph vel: 77 mph
burn time:1.13. Burn time: 0.9 (when accel goes negative)
peak accel: 6.16G Peak accel: 5.7G
average accel: 4.2G Average accel: 3.7G

PROBLEMS:
After analyzing and plotting the data there seem to be reoccurring problems. The most obvious is the low velocity and altitude. This is because of abnormally low acceleration. Some people mentioned this could be because the accelerometer doesn't capture the motor's thrust curve. The data logging rate was 39Hz. I managed to get it up to 200Hz at one point but the final flight code wouldn't allow this.

Another source of error is in the barometer. The first flight had 40ft of error while the second had 10 ft of error. Nothing was changed in the code or hardware for the barometer in between flights.
We did change the time constant that is used to integrate acceleration from 0.023 to 0.027 in between flights. This accounts for a slower data logging rate than expected.


SOLUTIONS?
The biggest problem is the low acceleration. Could this be because of a bad accelerometer? I used the LSM6DS03. Either way, a solution could be to add or multiply the acceleration by a constant during the burn to match it with the Jl2 acceleration. What do you think?
These flights have also proved that the barometer is inconsistent in it's altitude measurements, do you know why this is? I am using the bmp 388

Here are some plots of the data!



Thanks!
Walter

 

[waltr]

Looking at your data and something seems very wrong.

Partly this may be due to not knowing exactly what each column is. A header line with the data name would be handy.
A second header line with units would also be handy.

I needed to make assumptions based on the shape of the plots.
First column seems to be time but haven't figured out in what units. First assumed seconds but when doing integration of accel x (third column from right) the Vel & Alt values were way wrong. Then assumed milliseconds and still not good.
Now looks like column 7 is time in seconds. I also assume these are times based on the processor's timer and read at time of acquiring sensor data. The exact time interval between Accel samples is very important when doing the acc integration. The accuracy (Calibration) of the acc data in also very important for the integration since every small error accumulates.
Using column 7 for time in the integration of Accel X yealds Vel & Alt plots that look reasonable. The Accel X integration I did matches columns 4 & 5.

What is the 1st column? Kinda looks like altitude but not correct shape.

Just a plot of what looks like Accel X values does not seem to be correct. After burn-out the values should go negative (Drag + Gravity) then slowly increase to zero and the rocket slows and drag goes to zero. This does not happen. This 'coast' portion of the flight accel data is used to calculate Cd.
Seems the raw Accel values may be heavily filtered causing a huge lag. Are you filtering?

I do see you subtracted Earth's gravity from the Accel X values since the first 2 values are nearly zero.
However, once the rocket gets to apogee the Accel X is -10.4 which is not the expected -9.81.

What is the column with values 1441 and 988? They look like Barometric pressure except they increase during the flight. Baro pressure decreases as altitude increases. So some thing is very wrong here.
The data from your log 19NOV has correct looking pressure measurements.

Sampling rate seems fast enough to capture the thrust curve.

What I have been doing with my 10DOF sensors is log the RAW sensor data. This way I can try different methods to calculate other values after the flight.

I'll keep thinking about your data and may post again if I think of anything new.
Maybe I can have a look at your code to see what is actually happening with the data.

 

[diyaerospace]

Partly this may be due to not knowing exactly what each column is. A header line with the data name would be handy.
A second header line with units would also be handy.

My bad, the flight computer prints out a header line when it is turned on. I removed the pad idle section to make the data less redundant. Here are the colums:
Barometric Altitude(m) Systemstate Errorselftest. Accel Velocity(mph) Accel Altitude(ft). Time since startup(seconds). Time since launch(seconds). Amount of loops run since startup. AccelX Accely Accelz

Just a plot of what looks like Accel X values does not seem to be correct. After burn-out the values should go negative (Drag + Gravity) then slowly increase to zero and the rocket slows and drag goes to zero. This does not happen. This 'coast' portion of the flight accel data is used to calculate Cd.
Seems the raw Accel values may be heavily filtered causing a huge lag. Are you filtering?

I am not filtering and the lsm6s library I am using to interface with the accelerometer does not have any filtering.
I attached graphs of both flights and the acceleration does go negative(-14) at burnout before returning to -10.4 around apogee.
The acceleration seems consistently low during the burn. I will run SITL tests to see what adding constants to the acceleration will do.

Thanks,
Walter

 

[waltr]

Thanks for the column headings. Now they make sense.
Doing units in feet, mph and meters (m/s/s) gets confusing. Try to stay with everything in Metric. This also makes calculations easier.

Took a closer look at the AccX data during coast and this looks ok (I didn't see this at first look). Then measured the slope of Acc/V^2 (for Cd calcu) and got 0.0034 on flight 1 & 0.0046 on flight 2 which compares ok to 0.0022 on the 19Nov flight.

The peak acceleration is a little lower than the 19Nov flight but other wise very close and can be accounted for in motor to motor variations.

The values I get integrating the Acc are
19nov 27Nov #1 27Nov #2
max AccX 70 69.8 66.8 m/s/s
max Vel 36.8 39.2 34 m/s
max Alt 86 88.4 67 m

The 27nov #2 has lower values than the other two flights but not by much. This is again probably variation between motors or did flight #2 have the air-brakes deployed?
The Slope to get Cd is high on flight #2.

The shape of your Baro Altitude does not look right nor does it come close to matching the Acc Alt.
This could be due to how you are venting the sensor payload bay.
The shape of Baro Alt on the 19 nov flight looks ok. It also matches the Acc Alt until a little after burn-out. This may be due to Accel X readings not calibrated and/or the flight is not Straight up (acc Alt assumes straight up)..

You did mention a change to Baro venting and looks like it went to wrong way.

Most of this is looking good. Needs some tweaking and more test flights.

 

[waltr]

I just put the Accel X data (motor thrust) for the three flight onto one plot. Since the first flight was sampled slower I added blank data (gaps in the plot) so the timing of the motor burns match up and we can compare the motors.

Note the the motor thrust on flight 3 is lower which matches the max velocity and altitude we get.
Also, remember that the 19nov flight the accel data shoed a big spike then drop and then thrust back up.
This could be caused by various reasons. One is igniter placement and amount of pryogen on the igniter. These composit motor can be hard to light properly and even when we do everything right each motor can behave differently.

This is one reason the TARC Target Altitude is a tough challenge. It really is Rocket Science.

 

[diyaerospace]

Hello!

The values I get integrating the Acc are
19nov 27Nov #1 27Nov #2
max AccX 70 69.8 66.8 m/s/s
max Vel 36.8 39.2 34 m/s
max Alt 86 88.4 67 m

How did you get these?
The acceleration is higher than the recorded acceleration on the flight computer and Jl2. The velocity and altitude are smaller than Jl2 data but are larger than the flight computer's data.

The 27nov #2 has lower values than the other two flights but not by much. This is again probably variation between motors or did flight #2 have the air-brakes deployed?
The Slope to get Cd is high on flight #2.

Flight 2 and 3 had air brakes deployed. Flight 1 had the air brakes in the stowed position but they still hung out as shown in the video.

The shape of your Baro Altitude does not look right nor does it come close to matching the Acc Alt.
This could be due to how you are venting the sensor payload bay.
The shape of Baro Alt on the 19 nov flight looks ok. It also matches the Acc Alt until a little after burn-out. This may be due to Accel X readings not calibrated and/or the flight is not Straight up (acc Alt assumes straight up)..

For flight 1 and 2 I tried to reduce air turbulence by covering large holes and only leaving small vent holes. Should I try adding more vent holes?

My current plan to fix the flight computer's low acceleration is to add or multiply the values by a constant during the burn to get them to match Jl2 data. This had some obvious drawbacks, does anyone have another idea?


On another note I have been running simulations on what a controlled flight would look like. The results are pretty good. currently have about 5 ft of error with 5 percent motor deviation. The biggest variable is cd and frontal area. Both of these are measurable. I am still figuring out how to mix rocksim and flight data to estimate the Cd. The frontal area with drag brakes stowed is 0.36 square ft and 0.55 square ft with them open.

Thanks a lot for you insight!

 

[diyaerospace]

Maybe I can have a look at your code to see what is actually happening with the data.

Sure!
It is written in the Arduino IDE. How do you want me to send it to you? ie give Arduino files or send txt file with code.

 

[waltr]

How did you get these?
The acceleration is higher than the recorded acceleration on the flight computer and Jl2. The velocity and altitude are smaller than Jl2 data but are larger than the flight computer's data.

The AccX are from your data. The V & alt are integrating your Acc X data.
I did add back in the 9.8m/s/s to the 27nov flights.

Flight 2 and 3 had air brakes deployed. Flight 1 had the air brakes in the stowed position but they still hung out as shown in the video.

That explains the Cd slope differences, 0.0022 for 19Nov then 0.0034 & 0.0046 for 27Nov.

For flight 1 and 2 I tried to reduce air turbulence by covering large holes and only leaving small vent holes. Should I try adding more vent holes?

The Baro altitude from the 19Nov flight looks ok, at least the shape. I'd take the vents back to how they were then.
I have not been able to cone up with an explanation of why the the Baro Alt data has that shape. The internal pressure drops too quickly upon launch then increases (or decreases too slow) sometime after burnout.
If you use tape to cover holes and the tape come partly off this could cause air flow into the sensor bay.
Search this forum for Dual Deploy Ebays and how the vent holes are done. There is a ton of posts about this.

I guess the JL Alt2 is also inside this payload bay. It also needs vent holes that do not affect the bays pressure due to air speed. If the venting to the JL Alt2 is bad then its Baro data is garbage.

My current plan to fix the flight computer's low acceleration is to add or multiply the values by a constant during the burn to get them to match Jl2 data. This had some obvious drawbacks, does anyone have another idea?

Not sure if I would trust the JLAlt2's Max accel value since I do not know how it gets it. Ideally, it should only use Accel data until burn-out to report max acceleration of the rocket. However, it could report the Acceleration due to the ejection charge. This is clear in your Acc data as a large spike at 3-4 second after launch. This can easily be greater than the motor acceleration.

Have you done an accelerometer calibration (at least a check) by getting reading with Accelerometer Not moving and on all three axis on both directions (6 measurements)? Each should give a value of + or - 9.81m/s/s.
I know the MPU6050 Accel chip does not and needs both an offset and gain calibration to get good values. Remember you are integrating the acc data so each tiny error adds up.
I ordered (should be here today) a couple of LSM6DSOX breakout boards from Adafruit. After getting code to setup and read these First thing is check values against Earth's Gravity.

If your code is one file then post as a .txt file will work. If more then put the files into a .ZIP and post.

I can post to you the Python code I use to calibrate the raw data I log.

 

[diyaerospace]

I did add back in the 9.8m/s/s to the 27nov flights.

You told me to subtract gravity during the flight.

That explains the Cd slope differences, 0.0022 for 19Nov then 0.0034 & 0.0046 for 27Nov.

Ran some rocksim simulations and the cd for flight 1(with brakes open) is 3. For flight 2 it is3.75(also with brakes open). The larger value for flight 2 is due to the motor underperforming. Should I trust the Cd of 3? Rocksim predicts a Cd of 10 with the drag brakes open but this doesn't seem to be accurate.

The coefficient of drag with the drag brakes closed is around 0.55 - 1.2. I cut sections of the airframe out so the drag brakes will go inside the airframe instead of hanging out which I think resulted in the high Cd on flight 1.




I will give an update after I run more tests!

If your code is one file then post as a .txt file will work. If more then put the files into a .ZIP and post.

I attached a txt of the code. The State Estimator function deals with integrating accelerometers.
Let me know if you have any questions and thanks for your help!

 

[diyaerospace]

I am a bit confused on how to calculate frontal area of the rocket for drag calculations. Should I be using frontal area of the body tube (just a circle) of lateral surface area of the nose cone. Option 1 results in 0.4 sq ft and 0.6 sq ft with brakes open. Option 2 results in 0.95 square ft with brakes closed.

Thanks,
Walter

 

[waltr]

I am a bit confused on how to calculate frontal area of the rocket for drag calculations. Should I be using frontal area of the body tube (just a circle) of lateral surface area of the nose cone. Option 1 results in 0.4 sq ft and 0.6 sq ft with brakes open. Option 2 results in 0.95 square ft with brakes closed.

Thanks,
Walter

I have just used diameter to calc area.
Tim in his NARAM report says:
A = projected area of the object - Typically this is the cross-section area at the base of the nose cone, or the largest diameter of the rocket.

Do you have the NARAM 54 report from Tim Van Milligan?

You told me to subtract gravity during the flight.

Just to do an apples to apples comparison in that list.
When integrating the Accelerometer to Velocity Earth's Gravity must be subtracted.

Ran some rocksim simulations and the cd for flight 1(with brakes open) is 3. For flight 2 it is3.75(also with brakes open). The larger value for flight 2 is due to the motor underperforming. Should I trust the Cd of 3? Rocksim predicts a Cd of 10 with the drag brakes open but this doesn't seem to be accurate.

If the rocket exterior is the same then the Cd is the same independent of motor.

Got the LSM6DSOX today, wired and mod'ed my logger code for this sensor. All working.
Quick check on Accelerometer reading referenced to Earth.
X: 9.959, -9.911
Y: 9.882, -9.835
Z: 10.055, -9.701
These will require both Offset and Gain calibration and corrections.

Thanks for the code. I'll take a look.

 

[waltr]

I attached a txt of the code. The State Estimator function deals with integrating accelerometers.
Let me know if you have any questions and thanks for your help!

There is "._TARC flight 3.rtf" file in the zip you posted. don't think this is the Ardiuno file (*.ino).

 

[diyaerospace]

There is "._TARC flight 3.rtf" file in the zip you posted. don't think this is the Ardiuno file (*.ino).

I save the flight code in a .txt file before flying. I sent the code that flew on flight 2 and 3. Do you want the current version I am working on now?

 

[diyaerospace]

I have been running some Software In The Loop testing on the integration of acceleration and the results do not look good

My goal with these tests is to figure out a constant to add to the acceleration the calculated velocity will match the Jl2's velocity. I do this by running the software on acceleration data from last flight and observing the result.
Mathematically, in order to get the acceleration values to match I would have to add 4.5 m/s/s during the motor's thrust. However, when I run the simulation the results are far to small.
On the second flight with the brakes open the "fixed" acceleration produces velocity measurements with a peak of 88 mph and a peak altitude of 285ft. These do not match the Jl2's data.
In order to get the velocity and altitude to match I would have to add a full G to the acceleration.
Is this reasonable?

The sensor was somewhat calibrated with only 0.05m/s/s of error. This cannot cause the grossly off results in the simulation and flight.


All these problems come from poor acceleration measurements from the sensor I am using, LSM6DS03 (built in on the Arduino Nano 33 iot). I will go over some previous flight data when I used an MPU 6050 to see if the results are better.
I am considering using the BNO055 to fix the poor acceleration measurements as it is a much higher quality sensor. You get what you pay for

https://www.amazon.com/Adafruit-Absolute-Orientation-Fusion-Breakout/dp/B017PEIGIG/ref=asc_df_B017PEIGIG?tag=bingshoppinga-20&linkCode=df0&hvadid=80333120120460&hvnetw=o&hvqmt=e&hvbmt=be&hvdev=c&hvlocint=&hvlocphy=&hvtargid=pla-4583932699562077&psc=1

What does everyone think?
Walter

 

[boatgeek]

I'm going to take a few steps back--hopefully these questions will be helpful.

-How is your AV bay vented? You should have at least three clean holes, each at least 1/8" in diameter.
-Are your JL2 and your Arduino board secured in your AV bay? If they can move around, it might cause some issues with getting different data.
-If possible, align the circuit boards parallel to rocket centerline. This may be superstition, but I've felt like doing that gives more reliable altitude measurements since the pressure sensor diaphragm isn't affected by the rocket's acceleration.
-If you're competing in TARC, the JL2 isn't an approved altimeter. The Pnut (which is approved) will give you data files through the entire flight with altitude and derived velocity. That might be a more useful altimeter to compare against since you can look at a whole suite of altitude data instead of a single point.

 

[AllDigital]

Walter,

I applaud your efforts. Mastering these sensors the first time is never easy, but you are on the right path and getting close.

I took a look at the raw data you posted for the last two flights. I haven't gone through them thoroughly, but enough to have some early observations and some questions...

Observations:
1) You are sampling at about 39 Hz most of the time -- that is "good enough" for now, but something in your code at launch is slowing way down to 6hz (.15 ms) at the most critical time off the pad. You might be losing critical accelerometer data at that time creating a gap.
2) Your ejection pyro in both flights is firing early -- well before actual apogee, based on the accelerometer data. That early deployment can definitely cause discrepancies in total altitude data. You might want to experiment with a motor delay that fires after apogee.

Questions:
3) In the Accelerometer X data, what is the scale you are using? The LSM6DS3 is only a 16g accelerometer. On a very small rocket, I'd assume you are exceeding 16 gees, but I don't see it in the data, so maybe not. Do you have the LSM configured for full scale (16g's)?
4) Your T+ counter (column 7?) is starting a bit late, as compared to the startup clock and accelerometer data. Are you using that for your integration rate interval or using the startup clock? Combined with #1 above this could cause a gap.
5) Why do you think your barometer altitude is incorrect (maybe I missed the post)? You got 117m on one and 108m on 2. What do you think they should be?

Suggestions:

Mastering the accelerometer integration and logging and then moving into more complicated integration with the gyro, etc. requires a LOT of iteration and testing. When I was learning, it was very slow to make changes, go to the desert and launch, and then evaluate the changes. A much faster way to iterate is to buy a Nerf football. Cut out the inside, put your board in there, and go outside and "launch" your board 20 times. Apogee at 25 feet with fast sampling is just as accurate as apogee at 300 feet or 3000 feet. This can save you a lot of time iterating, so the time in the desert is more valuable.

Also, stay away from DMPs. All of the commercial DMPs are programmed considering a horizontal vehicle (drone, car, RC airplane, etc.). Almost all of them integrate the accelerometer for Earth reference and that will give you wrong data, once the rocket leaves the pad. Keep doing what you are doing to master the accelerometer and then the gyro. You are close.

Ultimately, you likely will need an accelerometer with a higher range than 16 gees.

-Mike

 

[waltr]

Boatgeek & Alldigital,
I agree fully on those suggestions.

But he may be fine with a 16g acc. So far his rocket/motor does about 6G acceleration. This is for a TARC rocket so acceleration does not need to be high. Most recommend a TTW of 5:1 which is 5G's. If this was for a HPR doing altitude or speed records then a high G accelerometer would be needed.

I have wondered, but haven't asked yet, about the time interval of the sampling and use in doing the integration.
I haven't gotten a copy of the source code to see what he actually does.

Try ploting the Baro Altitude from his 27 nov flights and the Acc Altitude. The shape of the baro altitude is wrong and may be explained by how the vent holes are done.

 

[waltr]

I save the flight code in a .txt file before flying. I sent the code that flew on flight 2 and 3. Do you want the current version I am working on now?

Look at the contents of the ZIP file you posted. It does not contain a TXT file with the source code.

 

[boatgeek]

But he may be fine with a 16g acc. So far his rocket/motor does about 6G acceleration. This is for a TARC rocket so acceleration does not need to be high. Most recommend a TTW of 5:1 which is 5G's. If this was for a HPR doing altitude or speed records then a high G accelerometer would be needed.

16G accelerometer limits should be fine. Even the sportiest TARC rockets (say 550g liftoff weight on an F70) top out at 12-13G.

 

[AllDigital]

Try ploting the Baro Altitude from his 27 nov flights and the Acc Altitude. The shape of the baro altitude is wrong and may be explained by how the vent holes are done.

Do we know what the sim'd altitude should be for the Nov 27 flights? Was there another "ride along" commercial altimeter? The plot for his bare data doesn't look too unusual for me (see below). The accelerometer altitude integration looks way under scale, but only in comparison to the altimeter data.

Yep, the 16gee should be fine for now -- it clearly isn't topping out in his data.

 

[waltr]

Alldigital,
Not sure which columns you plotted above of Walter's data.
He did use various units so the data is hard to compare. He did post what the units are.

The Baro Alt is meters but accel integrated Vel is mph & integrated alt is in feet. I created in Excel two new columns and converted mph to m/s and feet to m. Now can do direct comparisons.
Then plotted his integrated Alt & vel and the Baro alt. Plot attached.
The acc integrated alt shape looks good but the Baro alt has a sharp change at burn-out.
Acc Alt apogee is 69meters, Baro apogee is 107 but is still going up whereas the Acc Alt has peaked and going down.

 

[AllDigital]

Alldigital,
Not sure which columns you plotted above of Walter's data.
He did use various units so the data is hard to compare. He did post what the units are.

Oh, yeah. I thought I plotted Flight 1 baro altitude (m) and accelerometer altitude converted to meters (from feet). I just double-checked and the accelerometer data was off. Here is the correct graph that looks like your two plot lines above:



I see the same baro bump after motor burn-out, but that is not unusual, especially if there is more drag on the rocket.

I was really only focusing on three raw values - time, baro altitude, and accel-X (assuming accelerometer X is the "Z" up axis). If the raw values are captured well and trusted then everything else can be derived and/or validated by formula. Knowing the expected or sim'd altitude would validate the barometer. Knowing the scale of aX would allow us to do rough integration for accelerometer altitude. Time and altitude give us velocity/speed

Is aX factored by 10? (e.g., the first "60.47" in flight one is actually 6.047 g's?)

 

[waltr]

Here a is plot of Baro Alt, Accel, Acc AVel and Acc Alt from my data logger. This was an F67 motor in an 800gram rocket. Acceleration peaked at 82m/s/s (8.3G).
The AccAlt is 10 meters greater than Baro alt and a non-vertical flight would account for this.
Note then shapes of the two altitude curves. Both are smooth even at motor burn-out. which is quite a sharp cut-off.

 

[diyaerospace]

-How is your AV bay vented? You should have at least three clean holes, each at least 1/8" in diameter.

That might be why the baro altitude had the wrong shape. I only had one vent hole
Both altimeters are secured and aligned with the center of the rocket.

Look at the contents of the ZIP file you posted. It does not contain a TXT file with the source code.

When I unzip the file it contains a .txt file of the code the flew on flight 2 and 3. I will post it again.

Do we know what the sim'd altitude should be for the Nov 27 flights? Was there another "ride along" commercial altimeter?

The simed altitude was 181 for Nov 27. There wasn't another ride along altimeter

Is aX factored by 10? (e.g., the first "60.47" in flight one is actually 6.047 g's?)

Yes, the units are in m/s/s so 60 m/s/s would be roughly 6 gees.

If the raw values are captured well and trusted then everything else can be derived and/or validated by formula.

The estimated altitude and velocity from the Nov 27 flights are grossly off. I mentioned that this is due to incorrect raw data from the accelerometers. I asked if using a higher quality accelerometer or adding 10 m/s/s of force during the motors burn would solve this.



Thanks for your help!

 

[boatgeek]

That might be why the baro altitude had the wrong shape. I only had one vent hole
Both altimeters are secured and aligned with the center of the rocket.
...

Thanks for your help!

At least that's an easy fix!

 

[waltr]

When I unzip the file it contains a .txt file of the code the flew on flight 2 and 3. I will post it again.

I tried the zip again and it has an .rtf file . Had tried opening in a editor but no good. This time I simply double clicked on it and it opens in Microsoft Word and is readable.
Sorry and no need to re-post.

First thing I see is the I2C is running at the default 100kHz clock. The Sensor will easily run at 400kHz.
Add following line before doing *.begin_I2C:
Wire.setClock(400000);

You may experiment with high I2C clock rates to see if they will work.
This will reduce the time it take to read data from the sensors.

You have a function "float recalibrate_sensor()". This does NOT recalibrate the sensor. It only re-inits them.
Also inside this function you have a number of Switch/Case that only gets what the sensors are set to and don't even print out the result. This are not needed (I know they are in the Adafruit examples).
Just do a ".set" for each sensor setup you need only once when they are first initialized.

.Is this the integration code"

float Estimate_state() {
f++;
velocity_new = (accelx - 9.5) * 0.024 + velocity_new;
accel_altitude = accel_altitude + velocity_new * 0.024;
}

This is not quite right. A better way is:

 velocity_new = ((accelx_new + accelx_old))/2 - 9.81) * Time_step + velocity_old
accel_altitude_new =  ((velocity_new + velocity_old)/2) * Time_step+accel_altitude;

by adding old & new accel and dividing by 2 gets the average acceleration between the two samples.
Then use the Actual Time difference between the samples. Remember that any little error keeps adding up.
Looks like the function "millis(); returns a time. Read this when you read the sensors.

// read sensors
time_old = time_new;
time_new = millis();
Time_step = (time_new - time_old)/1000;  // time_step in seconds

Now the Time_step is the actual time between samples.

 

[AllDigital]

Walter,

I think your sensors and libraries are fine, but your integration math is off and to get more accurate you will need to speed up sampling, variable precision, baro avBay ports, and other optimizations.

I took your flight one data and reversed the aX data back to raw gee values. I then calculated the altitude in a simplistic two step formula in the attached XLS (columns N,O,P). My altitude track is much closer to your baro altitude track. I suspect the accelerometer data is "late", because it is missing valuable data in the first 300ms of flight and the baro comes up slightly lower, because 1) they always do and 2) slower response times due to single port.

I'd suggest always logging the rawest values you can, so you can always go back and recalculate later.

I have lots of other suggestions on how to speed up sampling and logging, but I'll pass those on later. What Arduino MCU are you using?

-Mike


Blue is baro, orange is accelerometer

 

[waltr]

As for the Baro altimeters I recommend using a Vacuum chamber with both is to compare.

I just did this with the new BMP390 and an Eggtimer Quark.
Quark Alt = 2174 feet
BMP390 Alt = 2212 feet
This is a difference of 38 feet which is an error of 1.77%.
The 38 feet sounds bad but 1.77% is pretty darn good.

A vacuum chamber can be easy to make. I use an Taster Choice plastic jar with a pin hole in the lid. Then put the altimeters in the jar and put a vacuum clear hose against the lid. The plastic jar will try to collapse so eay to tell if a vacumm is inside.
The clear plastic allows seeing the LEDs, etc to know status.
I build Eggtimers for Dual Deploy and connect Xmass tree lights to the outputs. Then test with the vacuum. The two Deploy outputs should light in sequence telling me the circuit is working.
.
Thought of using this to compare two altimeters which you can do with the JLA2 and your Baro.
This will show that either the Baro altitude and code is or is not working without flying a rocket.
If it is working and the two do not agree during a flight (with an error range) then it is the installation or vents holes.

 

[diyaerospace]

Sorry it took so long for me to get to your replies.

I took your flight one data and reversed the aX data back to raw gee values.

How did you do this? From my experience converting from m/s/s to g's is as simple as dividing by 9.81.

I suspect the accelerometer data is "late", because it is missing valuable data in the first 300ms of flight

After looking closer at the data, I think you are correct. It looks like integration starts 25m/s after launch so it missis the first point of acceleration data. However, after I added this back in the max speed is only 83 mph. Doesn't match the Jl2.
You said the flight computer is missing data is the first 300ms of flight. Looking at the .txt file it only misses the first 25 or 50ms of flight. So how did you come to this conclusion?

I'd suggest always logging the rawest values you can, so you can always go back and recalculate later.

Already am.

I have lots of other suggestions on how to speed up sampling and logging, but I'll pass those on later. What Arduino MCU are you using?

I am using the Arduino nano 33 iot!

Arduino Nano 33 IoT

Arduino Nano 33 IoT allows you to build your next smart project. Ever wanted an automated house? Or a smart garden? Well, now it’s easy with the Arduino IoT Cloud compatible boards. It means: you can connect devices, visualize data, control and share your projects from anywhere in the world...

store-usa.arduino.cc