Active Altitude Control

[diyaerospace]

Hello everyone!

I have another idea to get our rocket to 850ft. As the rocket ascends we can deploy the parachute using some non-pyrotechnic method as we get close to 850 ft. If stopping distances(distance from when the parachute is deployed to when the rocket reaches apogee) is correlated with speed at the time of deployment it shouldn't be to difficult.

What do you think?

 

[boatgeek]

Hello everyone!

I have another idea to get our rocket to 850ft. As the rocket ascends we can deploy the parachute using some non-pyrotechnic method as we get close to 850 ft. If stopping distances(distance from when the parachute is deployed to when the rocket reaches apogee) is correlated with speed at the time of deployment it shouldn't be to difficult.

What do you think?

It might not be a bad idea to have two systems running in parallel so that if one doesn't work in practice, you can switch to the other. For either one, you'll need a reliable altitude measurement in your control system. That means that you'll need to work out the bugs you've seen so far for either one.

 

[AllDigital]

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

Yes. It looks like the Adafruit library you are using is taking the raw output of the sensor (in gees) and multiplying times the gravity constant. So, dividing by 9.80665 (Adafruit's constant) get's you back to the raw accelerometer output. Here is the line from their library:

accX = rawAccX * accel_scale * SENSORS_GRAVITY_STANDARD / 1000;

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?

Below is your "flight one" data reorganized. I anchored off of the startup clock and used that to derive the "T+ clock" (launch clock), assuming 0 was when your baro started to climb. In this view, you don't get your first aX reading until 300ms into flight (the 60.47) and your velocity integration still shows zero. This might not matter much in the grand scheme, depending on how much punch you had initially, but you do a great job at integrating every 20-30ms after. In accelerometer time that is also considered too slow. 100hz integration would give you a more accurate view of what is going on. Your writing to the SD card is what slows down your loop, specifically the open and close times to the SD file. One trick is to sample the accelerometer 100+ times a second (while integrating), but only log the output to SD 10-15 times a second. Alternatively, If you open, but do not close the file on the pad you can write to SD at over a thousand lines a second (with the right SD cards), but you risk losing everything if you reset or power out before closing the file. So, a trick is to set a timer to do a "close and then open" of the SD file every five seconds, allowing you to sample and log extremely fast.

I have another idea to get our rocket to 850ft. As the rocket ascends we can deploy the parachute using some non-pyrotechnic method as we get close to 850 ft. If stopping distances(distance from when the parachute is deployed to when the rocket reaches apogee) is correlated with speed at the time of deployment it shouldn't be to difficult.

What do you think?

From a flight computer and a rocket build perspective this approach is 10X more simple. You will learn a lot more along the way trying to implement air brakes, but if you just want to achieve the objective with the more reliable approach just eject the chute (and make sure your rigging is solid).

-Mike

 

[diyaerospace]

One trick is to sample the accelerometer 100+ times a second (while integrating), but only log the output to SD 10-15 times a second.

Done.

I ran some tests on the barometer. I stuffed the flight computer and Jl2 into an old soccer ball and tossed it up. The results are as follows.
Jl2 Barometer
20ft. 19.65ft
19ft. 20.11 ft
21ft. 22.3 ft
23 ft. 24.6 ft


Thanks for all you helpful suggestions. I have two altimeters ready for flight on some high power rockets on Saturday. (datalogging only)

 

[waltr]

Another method to get fast loops is run the I2C (wire) bus with a faster clock.
Add the following line before first initializing any sensor. Then the sensor reads will take 1/4 of the time as the default of 100kHz.

 Wire.setClock(400000);   // run I2C clock at 400kHz

It is possible that you can run the I2C bus at faster clock rates. You would need to try faster clocks and check to ensure the sensor are returning good data.

Good test with the soccer ball.
Here is a plot of the JL2 & Baro. The Baro is higher on all but one measurement. The difference also seems to increase with altitude. Wondering how much difference there will be at 500 or 1000 feet.

 

[diyaerospace]

Getting ready for some more flights, here is what I am changing.

1. I increased the loop rate on the pad from 10Hz to 31Hz. This should allow the rocket to start integrating faster and avoid losing the first 200-300ms of the thrust curve. Data logging rate during the flight will be 46Hz.

2.Proper barometer venting

3. I have two flights planned for Saturday, on the first one I will use the approach I mentioned in #1. For the second flight I increased the loop time to 100 Hz by decreasing the data logging rate to 20Hz(Thanks to AllDigital for suggesting this).

 

[AllDigital]

Sounds like you have a good plan for the flights. Good luck.

I've got a lot more suggestions once you get things stable. I believe the Nano 33 board you are using supports multiple threads (loops). A best practice is to run three concurrent multi-threaded loops, instead of timers. On one loop you put your I2C sensor sampling (wire start, barometer, accelerometer, gyro). On one loop you put your SD logging. and on your main loop you do all your housekeeping (launch detect, fire events, etc). You use shared global variables for your logging and event logic between the different threads/loops. This is much cleaner than trying to construct a bunch of timers. If threading works well on your board you should be able to sample at 400 hz and not have the SD logging interrupt the sampling and integration. When it works it is really elegant. Another suggestion is to use the difference in microseconds instead of milliseconds as your time interval for integration. Your arm processor on that board should support and it will give you much better accuracy when integrating.

I have not used that specific board, but here is a general page I found for running multi-threaded loops on a Nano 33:

https://www.digikey.com/en/maker/blogs/2022/how-to-write-multi-threaded-arduino-programs
-Mike

 

[waltr]

Did you increase the I2C (wire) clock rate?

Otherwise plans sounds good.

Mike, Good suggestions to leverage the power in that processor.

 

[diyaerospace]

Did you increase the I2C (wire) clock rate?

yep!

 

[waltr]

yep!

good.
Looking forward to seeing results from next test flights.

 

[diyaerospace]

Just got two more flights done on L1 rockets. Both recovered successfully and recorded data, this means that I have more data that I will post later and now am Junior L1 certified!

During the certification process I spoke with my mentor about our plans for TARC. He informed us that in order for our rocket to be allowed to compete my PCB design must be manufactured by our team. This does align with the TARC rules which state, "If custom 3-D printed parts or circuit boards are used in a rocket, these must be designed and fabricated by student team members only."

I am somewhat confused by this. Does this not allow us to get the boards made by a PCB fabricator? Are we allowed to use my flight computer because I assembled/soldered it together myself? Can we use breakout boards and microcontrollers in the flight computer design?(Arduino nano, Adafruit BMP 388, Micro sD card slot+)

Thanks for your help,
Walter

 

[boatgeek]

Just got two more flights done on L1 rockets. Both recovered successfully and recorded data, this means that I have more data that I will post later and now am Junior L1 certified!

During the certification process I spoke with my mentor about our plans for TARC. He informed us that in order for our rocket to be allowed to compete my PCB design must be manufactured by our team. This does align with the TARC rules which state, "If custom 3-D printed parts or circuit boards are used in a rocket, these must be designed and fabricated by student team members only."

I am somewhat confused by this. Does this not allow us to get the boards made by a PCB fabricator? Are we allowed to use my flight computer because I assembled/soldered it together myself? Can we use breakout boards and microcontrollers in the flight computer design?(Arduino nano, Adafruit BMP 388, Micro sD card slot+)

Thanks for your help,
Walter

You should check with the TARC organizers. They will get back to you fairly quickly. My understanding is that yes, everything you use in the TARC rocket must be either bought off the shelf or made from parts bought off the shelf.

I have seen teams custom make circuit boards from the circuit board sheet that has a solid copper sheet on one side. They traced out the lines and then dissolved off the copper they didn’t need with an unpleasant chemical. You could also get the boards that are just the through holes on the right pitch and make traces with wire or solder bridges.

You can use breakout boards and any other parts you can buy off the shelf. You just have to make the custom stuff.

 

[waltr]

Congrats on Jr L1 cert.

I do not know how to interpret the TARC rules for custom PCBs.
I have made PCBs but only simple single sided. For processors, etc I would not be making the PCB since these typically require at least two sides with plated through vias but send out the design to be fabricated.
For the data logger I have used Adafruit breakout boards just because they are so easy to use.
As boatgeek suggests, check with the TARC organizers.

Looking forward to see the data.

 

[diyaerospace]

Here is the data from the two flights yesterday!

FLIGHT 1
Jl2. Flight computer
2123 ft Baro 2230 ft Accel Altitude 1723 ft
353 mph. 290 ft
10.3G accel 11 G
8.8G average accel. 7.4G


Flight 1 has a similar problem to the previous flights in that the acceleration readings are two low. I am pretty sure that this is because the first reading is not integrated and because the code runs at 20Hz when on the pad before increasing to 50Hz in the air. The 20Hz is a problem because it is unable to catch the beginning of the thrust curve.
The barometric altitude seems in the right shape but to high.



Flight 2 only had a Jl1 onboard. This means we only have altitude as a control. There also wasn't any barometer on the flight computer.
Somehow an acceleration was felt on the pad that caused an ironies state transition from the pad idle state to the launch state. This does mean that we avoided the problem on the previous flight as the flight computer was integrating before the rocket launched. I think this could have been caused by other rockets launching next to ours. (It was a club launch). This renders the acceleration based altitude useless without post processing that I have not done yet. However, the velocity data can still be salvaged. It drifted 20 mph on the pad over a few minutes. By subtracting this from the final velocity estimate we can get the "true" velocity.
The integration rate was 110Hz

FLIGHT 2
Jl1. Flight Computer
1367 ft Accel Altitude N/A
Top speed 200 mph
Accel 9.1G
Average speed 110 Average speed 108


This data doesn't tell us much about the integration of the acceleration because the Jl1 doesn't measure speed. I decided to compare the average speed instead, here is how I did it.

To find average speed you need distance and time. Distance was the 1367 ft measured by the Jl1. I used video of the launch to find that apogee occurred around 8.4 seconds into the flight.

1367/8.4 = 163 ft per second

Convert to mph
163 * 0.68 = 110 mph

To find the average velocity measured by the flight computer I summed all the velocity measurements during flight and divided by the amount of loops run by the flight computer to get 108 mph. Pretty close!


Flight two was very valuable as it conformed that we need to be integrating while on the pad. I plan to do this by gathering a velocity and altitude offset every second or two while on the pad and subtracting that to keep the values relatively close to zero.


Column lists.
Baro Altitude, Systemstate, Error check, Barometric speed, Velocity speed, Accel Altitude, Time since startup, Time since launch, #loops run, Accelx, Accely, Accelz

 

[AllDigital]

Hi Walter,

Good job on the launches. Getting real data is always exciting, but also frustrating when it doesn't add up as expected.

I looked at your data and then went back to look at your (old) code you had posted. I think there are a few different things going on, so it is important to strip things down to the most basic levels and then build up from there.

First, regarding the barometer. Your barometer and the control barometer (in this case the JL2) should match pretty close given your sampling rate, but they are still off by over 100 feet. The JL2 is reliable, but it doesn't give you detailed data and it isn't the altimeter you will be using for TARC, so I would swap it out for your TARC altimeter if you can (a PNut?). A Perfectflite will give you 20hz data logging to compare. I don't have the BMP388 library you are using, but I pulled down a BMP388_DEV.h library from GitHub and it looks like the altitude formula incorporates a temperature adjustment. 99% of all the commercial altimeters will only use the standard formula and won't incorporate temperature and/or it is assumed that the pressure reading in the altimeter already corrects for temperature. My flight computer used to be about 5% off of commercial altimeters, but when I removed temperature adjustment it fell within feet of all the commercial altimeters. Here is the line I found in the GitHub library (confirm in your library):

altitude = ((float)powf(sea_level_pressure / pressure, 0.190223f) - 1.0f) * (temperature + 273.15f) / 0.0065f; // Calculate the altitude in metres

Second, with regards to the accelerometer, I think the overall issue is your level of precision. Accelerometer integration requires a lot of precision combined with fast sampling. I had trouble following your code, so I have a few questions... Did you bench calibrate your accelerometer for offsets? In your code you subtract 9.5, why 9.5 vs. the gravity constant (9.80665)? Also, your code uses .024 as a static time interval. Are you not calculating your actual time interval? (e.g., dt = (micros() - lastMicros)/1000000) The combination of not integrating early and small errors in calculation will have a big impact.

Reliable launch detect can be tricky. You are using a simple check for > 3g's, which should be ok, as long as your computer gets turned on while the rocket is on the rail and steady. BTW, is your code correct... I think it should be if((accelx / 9.81) > 3 && system state < 0).

If you are sampling faster than you are logging another trick is to log the average x value. Say you sample ten x values then you log to SD, you sum them and keep a counter, then divide and log and then zero the counter. The values can be extremely different, but with the average you will have an accurate view for post analysis.

One more suggestion... you have a lot of serial.prints in your code. These are huge time sucks, since serial is slow, so surround them with a flag you can turn off for your launch build and turn on for bench debugging.

-Mike

 

[diyaerospace]

My flight computer used to be about 5% off of commercial altimeters, but when I removed temperature adjustment it fell within feet of all the commercial altimeters.

Thanks, will take a look at it!

In your code you subtract 9.5, why 9.5 vs. the gravity constant (9.80665)?

I subtract 9.5 to get values on the pad close to zero. The accelerometer is not perfect so when perfectly vertical it reads 9.5 m/s/s.

Are you not calculating your actual time interval?

For the December 10th flights, yes.

BTW, is your code correct... I think it should be if((accelx / 9.81) > 3 && system state < 0).

I account for the force of gravity by subtracting 9.81. I believe you are thinking of converting m/s/s to g's which would be done by dividing by 9.81.

I will also look at the other suggestions you mentioned.


Thanks,
Walter

 

[waltr]

I agree with all that Mike (alldigial) posted.
I have been using the Adafruit library for the BMP288 (and now the BMP290) baro chip. There are also a bunch of Factory Compensation values stored in the chip. These most be read out, converted to float and then used on every BMP2xx temperature and pressure reading,

The Baro's Altitude graph still does not look right. It is VERY Rare to have discontinuities (kinks) in pressure derived altitude. Only time I seen that is when Ejection Charge blows into the Baro chips compartment or total wrong vents holes that cause internal pressure changes from external source like wind or air speed.
The rocket has Mass and therefore Momentum so will not change speed quickly and altitude is integral of speed which changes slower. The Alt curve should be smooth.

The Accelerometer should be measured to obtain Calibration correction values in the lab (home).
Then code in the Accel offset and gain corrections and apply to each reading before subtracting Earth's G, etc.
The data sheet does say that mounting the chip (soldering) can change the factory calibration but is then stable. I have done this with the Accel chips I use and have gotten very good Accel, Veloc & distance integrating the Accel sensor.

I haven't seen your new code that obtain 'real' time intervals. Does this have enough precision (should be to at least 100us or better)?

One more suggestion... you have a lot of serial.prints in your code. These are huge time sucks, since serial is slow, so surround them with a flag you can turn off for your launch build and turn on for bench debugging.

Absolutely a good idea.

A good way to do this is with compiler directives.

#define debug_out   // comment out to remove excess print statements

#ifdef debug_out
serial.prints(output value);
#endif

The Bigger picture:
All this data and code is great learning. However, for your finial goal of deploying air brakes I think the Baro Altitude will do the job.
Right now you have unknowns indicated by different measurement methods not matching. These do need to be addressed.
Have you considered a vacuum chamber to test Baro verse JL2? This would allow you to run many, many tests without going out and launching.

Accelerometer testing is harder. Best might be your soccer ball. Launching the soccer ball could be done with a lever (seesaw style) by placing ball on lower end and jumping on the high end.

 

[diyaerospace]

My flight computer used to be about 5% off of commercial altimeters, but when I removed temperature adjustment it fell within feet of all the commercial altimeters. Here is the line I found in the GitHub library (confirm in your library):

altitude = ((float)powf(sea_level_pressure / pressure, 0.190223f) - 1.0f) * (temperature + 273.15f) / 0.0065f; // Calculate the altitude in metres

I am using the BMP 388 library. I am unsure of how to undo the temperature correction. Can someone give me some guidance?

Thanks,
Walter

 

[waltr]

Which BMP288 library? There are many available.
Look at the source code to verify it actually does this calculation. I always download a libraries source from Github just so I can look and see what the library function actually do.
You could edit the library code to remove the temperature correction. Just drop the second term.
There is a function that returns the Pressure. Then write your own function to calculate Altitude.

I think you do read and log the Pressure. If so then try using the log data the calculate altitude from the pressure and see if the value is better.
I do log the BPM Pressure, Temperature and Altitude which allows re-calculating to check equation, function, etc.
At one time there was an error in Adafruit's BPM library. This has been corrected but means that errors can exist in libraries you find.


Had another thought for testing your Baro/Altimeter with air flow.
Strap the rocket onto the top of your car, start logging BMP data and drive around at different speeds. Also do this with the ebay face different directions, up, to right, etc then have different air flow.
The Altitude should not change much, unless you drive hills, but should be very smooth.
I do remember seeing in your videos the electronics bay being open. This may be causing bad baro/alt data.

 

[diyaerospace]

Here is an update,
I previously pitched the idea of deploying the parachute when the rocket gets close to the target altitude and the extra drag will cause it to stop.
This has the advantage of simplicity and seems more straight forward with less to go wrong. Drag brakes are made more difficult when the rocket is weathercocking and starts to slow down around apogee.
I used rocksim to get some estimates on the stopping distance if the parachute were deployed at different speeds. An oversimplification of the software would be:

if current_altitude + stopping_distance = target_altitude
deploy chutes!

This method still requires accurate velocity and altitude measurements. I made a python script to calculate differential altitude based on barometer data from past flights. The results are not good, the data is jumpy and far to high. So now the only way forward is the accelerometer which I am already working to improve.

Thanks,
Walter

 

[waltr]

Ok, you have a plan.

Yes, deriving Velocity from Baro altitude will be noisy since Velocity is a differential of altitude, slope of altitude curve. Any small error in altitude becomes a larger error in velocity.
Whereas, deriving Velocity from Acceleration is an integration which averages two sample thus reducing the error noise.

if current_altitude + stopping_distance = target_altitude
deploy chutes!

The Stopping distance will be a function of Velocity. You will need to derive an equation of stopping distance verse velocity.

Will you be a servo to deploy the chute?
Pyrotechnics is out due to TARC rules.

 

[boatgeek]

Another option you could consider is using the servo mechanism to separate the rocket but continue to use motor eject to deploy the parachute. That reduces the risk of zippering the rocket on a high-ish speed deployment.

If you're using the baro system, you need to be able to compare against your flight altimeter (as opposed to the JL2). Do you have a vacuum test setup available to you? Making one of those will probably save you a LOT of time and expense vs. flying.

 

[BEC]

I’ve only just skimmed this thread since my last post, but I just wanted to refer to something I found when looking for something else in my back magazine stack:

There is an article about an Arduino-based TARC rocket altitude control system in the May/June 2016 issue of the NAR’s magazine Sport Rocketry. If you are an NAR member, you can access this via the nar.org web site. It doesn’t go into too much detail about the code driving the braking flaps other than to describe the basic approach, but it also shows some details on the mechanical design that might be of value.

 

[waltr]

Interesting article in Sport Mag.

When looking at the plot in the article I realized maybe why Walter's Baro/Altitude has a 'kink' just at burn-out where the slope suddenly decreases.
I think this is the air-brakes deploying, maybe from de-acceleration and not commanded.

However, if this is real, increasing altitude changes rate, then the Acceler/Alt should also show this.
Mmmm.......

 

[diyaerospace]

Will you be a servo to deploy the chute?
Pyrotechnics is out due to TARC rules.

We are working on a method to use rubber bands and a servo to separate the rocket. Similar to what is shown in this video.

I am also wondering if it would be possible to use C02 cartridges to separate the rocket. Could a 12 gram servo with a thin nail attached to the arm puncture a cartridge?

 

[waltr]

We are working on a method to use rubber bands and a servo to separate the rocket. Similar to what is shown in this video.

I am also wondering if it would be possible to use C02 cartridges to separate the rocket. Could a 12 gram servo with a thin nail attached to the arm puncture a cartridge?

Probably a servo with not puncture a CO2 cartridge.
Probably better to have the cartridge punctured upon installing then the servo can open a valve.
Look into how this is done on pellet and paintball guns also look up CO2 ejection systems for rockets to see how they work..

 

[diyaerospace]

Hello!

Sorry for not posting in a long time I got some stuff done though!
I finished designing the new parachute deployment mechanism. It used rubber band that compress a piston and a servo to release the mechanism.

I also finished a new flight simulation that works pretty well. Results with the parachute deployment approach only show a few feet of error.

Hopefully we can fly in a few weeks.

 

[waltr]

Progress sounds good.

 

[diyaerospace]

I found this in the TARC rules...

"The two sections must separate after apogee and recover separately, both by parachute"

Does this mean we can't use our method of deploying the parachute before apogee to add drag?

 

[waltr]

Don't know TARC rules but why can't you just deploy with two parachutes on each section before apogee.