Let's see your Arduino-based flight computers!

[cfb_rolley]

Ahoy! So, for the last 12 months I've been slowly teaching myself how to code and have been working on my own flight computer utilising an Arduino Nano, BMP280 barometer, MPU6050 imu, and a micro SD card reader on the back side for data logging. It's also got a buzzer and a single ignition channel for an ejection charge. So far, it's done around 30 flights and I'm getting some great data back from low and mid power flights, but I want to take it a little further.

So, let's see some other Arduino flight computers! What does yours do? What sensors are you using? Are you doing any onboard calculations for velocity or other things? Do you think there's things I can do better? Whatever it is, I think they're pretty rad and I'd like to learn from you!

 

[Church]

Looks great! I'm just get around to starting my own and am planning to build one along the same lines as what you have there.
I'm also planning on integrating GPS at some point with a transmitter to send back location data to assist with tracking and recovery. Might give LoRa a try.

 

[Approx]

Here is a little board my brother and I made. It works great but I am still struggling to get event detection software working right. Pressure sensor only and two channels of pyro. It is pretty tiny. That is a bt60 av bay.

 

[Velocity Aerospace]

This is something I really want to get into. My dream is to have tvc rockets with dual deploy, cameras, and GPS. Considering I've only programmed a simple rock paper scissors game in python, I'm a long ways away. Baby steps are in order. I may just start with single or dual deploy and work my way up. I started watching a video on arduino this morning, so we'll see how it goes.

 

[Jean-Pierre]

Love adding Arduinos to rocketry! Here is my simple altimeter which I call the TinyTimeter as nod to both the ATTiny chip and my favorite rocket, the WAC Corporal.

 

[Voyager1]

Here is a little board my brother and I made. It works great but I am still struggling to get event detection software working right. Pressure sensor only and two channels of pyro. It is pretty tiny. That is a bt60 av bay.

View attachment 596984

That’s a neat little board. What processor are you using?

 

[Aeva]

Here's my adafruit feather 32u4 (I'm moving to arm cortext m0 arduinos in the same form factor though). It has altimeter, accelerometer, magnometer, a relay, and a LoRa transmitter. It works extremely well in my opinion. Next I want to add GPS. Here is a video of it on one of my rockets:

 

[Aeva]

This is something I really want to get into. My dream is to have tvc rockets with dual deploy, cameras, and GPS. Considering I've only programmed a simple rock paper scissors game in python, I'm a long ways away. Baby steps are in order. I may just start with single or dual deploy and work my way up. I started watching a video on arduino this morning, so we'll see how it goes.

Considering ejection charges can cause pressure spikes if the avionics bay is not completely sealed from the payload bays, it might be better to start with collecting data on your first go, and no active components. That being said, the fix is to store some information about the altitude (an array of numbers, say 10 datapoints of previous altitude data) and then use mean and stddev to ignore pressure spikes (they can make your altimeter think it's lower than actually is, but should only last for a fraction of a second).


So here is a graph from my data of a F52 flight on a 3d printed rocket. The first dip is from the engine's EC. The 3D printed parts don't seal well by themselves, so it caused a spike in the altimeter data despite being in an isolated compartment separated by a bulkhead. The second one is because I had a hole for wires... it was too big, and I think that contributed to the failure of the parachute to come out. However, neither spike effected the ejection charge trigger because I used a rolling average to keep it from making a mistake from erroneous data.

 

[kjhambrick]

@Aeva --

Very nice !

What are the three altitude -vs- time traces ?

Thanks

-- kjh

 

[Aeva]

@Aeva --

Very nice !

What are the three altitude -vs- time traces ?

Thanks

-- kjh

White line is the altitude above sea level reported from the flight computer (probably not calibrated right because it's not necessary for this to work); yellow is calculated "relative height" based off the altitude data received from before launch subtracted from the current altitude, and blue/teal is the yellow line put through a kalman filter (I was experimenting with smoothing, and basically I can choose to have imprecise data that's smooth or accurate data that is occasionally erroneous at pressure spikes. I prefer the latter)

 

[Jean-Pierre]

Also put together an altimeter (barometer), GPS, and transceiver. Allows for a live stream of flight data for low/mid power flights. The measurements that depend on the GPS - so anything with a horizontal vector - aren’t that accurate. But for $20 of parts, I’ll take what I can get. And I have fun with the coding/soldering/tinkering, so why not?

 

[SparkyVT]

This one basically is a TeleMega without the smartphone app. IMU, High-G Accelerometer, GPS, high-rate data recording, live telemetry, 4 pyro outputs, tilt-inhibiting 2-stage ignition, ability to directly drive 4 servos, audible beeper, magnetic arming switch. The smaller board is for the ground station, which can receive from 2 rockets at once (sustainer & booster), record the telemetry packets, give a GPS distance to the rocket, and I'm working on a bluetooth connection.

Heres a video of it in action:



My code is open source, here:

https://github.com/SparkyVT/HPR-Rocket-Flight-Computer
It has the sensor fusion and event detection algorithms in there if you need it. We're hoping to set an N-Research altitude record with it at Airfest this year.

 

[cfb_rolley]

oh man, all of these are absolutely wicked! So glad I started this thread haha. Sparky, I’ll definitely be having a look at your code at some point because servo control, GPS and base station communication are all high up on my ambitions list for my own project

 

[SparkyVT]

oh man, all of these are absolutely wicked! So glad I started this thread haha. Sparky, I’ll definitely be having a look at your code at some point because servo control, GPS and base station communication are all high up on my ambitions list for my own project

No problem. It's all on the site. I'm constantly updating the code and will post some improvements in the next week or so. The latest version will make the tilt-inhibiting 2-stage ignition code much more portable. I'm also working on some LoRa libraries that will make telemetry at Spaceport America Cup a bit easier for the university teams.

 

[Approx]

Considering ejection charges can cause pressure spikes if the avionics bay is not completely sealed from the payload bays, it might be better to start with collecting data on your first go, and no active components. That being said, the fix is to store some information about the altitude (an array of numbers, say 10 datapoints of previous altitude data) and then use mean and stddev to ignore pressure spikes (they can make your altimeter think it's lower than actually is, but should only last for a fraction of a second).


So here is a graph from my data of a F52 flight on a 3d printed rocket. The first dip is from the engine's EC. The 3D printed parts don't seal well by themselves, so it caused a spike in the altimeter data despite being in an isolated compartment separated by a bulkhead. The second one is because I had a hole for wires... it was too big, and I think that contributed to the failure of the parachute to come out. However, neither spike effected the ejection charge trigger because I used a rolling average to keep it from making a mistake from erroneous data.

Do you recall what recovery gear that launch had? It looks like your rocket didn't decend any slower after the main ejection.

 

[Aeva]

It had a larger parachute (24" iirc), but the parachute didn't completely come out with the ejection charge, so it landed with only the 15" drogue. It was my first attempt with dual ejection, and while some things went well (the computer trigger), the parachute was still stuck in the tube up to its crash landing. I did ground test, but apparently it wasn't consistent.


As far as diagnosing it-- The current result is the nose will eject, but the parachute with the protective blanket will stop at the end of the tube. I've tried upping the charge to 1g (ridiculous; calculators suggest 0.3g) and that doesn't change the result in ground testing. I improved the seals between compartments so all of the pressure should be going into the payload tube (there is a small leak from where my rail button hole is, but I don't think it's enough to cause any issues) and while that eliminated some issues in the flight computer data spiking, it didn't resolve the parachute deployment issue. The inside has been sanded to the point of it practically slipping out. I know one other issue I have is the black powder substitute I'm using (pyrodex RS) is not typically ideal for ejection charges because of the grain size and burn time and I'm really reluctant to spend the money to get the recommended stuff at the moment because I don't know what I would do with the pyrodex RS BPS.

Here's the slowmo of a ground test failing to deploy the parachute. It's exactly what went wrong during the flight, and this is the more powerful charge. I actually warped the plastic, so now I need to reprint some parts.... ugh.

 

[Approx]

Thanks for the detail! I am in a similar boat. So far I have done 3 DD launches and of those only one was truly successful. On my last attempt I doubled what the charge calculator told me and it still wasn't enough. I am prepping for a ground test campaign now. I have Pyrodex P and it looks like I am going to need around 2 gram, which is around 4 times what the calculator said.

 

[Aeva]

That's nuts... the BP charge on the engine has been plenty for the drogue even when it is packed the same way. I'm pretty sure that's way smaller too. I guess black powder substitutes are just really underpowered as ejection charges?

I was thinking about scaling up my charge too, but you can clearly see the gasses escaping around the chute after the nosecone is ejected. Maybe I just need a better seal under the parachute and blanket? Otherwise I'm just gonna max out the cap volume and see what happens...

 

[SolarYellow]

I guess black powder substitutes are just really underpowered as ejection charges?

Smokeless powders burn much more slowly, especially when not developing the kind of pressures seen in firearms. So they tend to not be as effective in developing the nice, quick rise in pressure in the comparatively very large volume of a rocket that fine-grained 4FG black powder does. Contained in a firearm's chamber and barrel, smokeless generally has quite a bit more energy released/mass, and can develop much higher pressures than black powder.

 

[Aeva]

Smokeless powders burn much more slowly, especially when not developing the kind of pressures seen in firearms. So they tend to not be as effective in developing the nice, quick rise in pressure in the comparatively very large volume of a rocket that fine-grained 4FG black powder does. Contained in a firearm's chamber and barrel, smokeless generally has quite a bit more energy released/mass, and can develop much higher pressures than black powder.

This has me thinking... it really seems like I'm either going to be engineering a more complicated solution to maximize the pressure of the BPS, or I need to track down some 4FG black powder if I can.

 

[Approx]

The commercial ejection charge has much finer ground powder. This burns faster and hits high pressure quick. Our lesser powders burn slower and need to be tightly contained to hit high pressure before the granuals are blow away from each other. It could be you aren't closing your charge wells tightly enough. Did you pack them with dogbarf and tape them tight?

 

[Aeva]

Not dog barf, but estes wadding packed tight and just masking tape/painters tape. From the aftermath, it looks like it typically burns out over the edges of the cap, and eventually through the tape. Maybe upgrading the tape will help?

 

[kjhambrick]

Smokeless powders burn much more slowly, especially when not developing the kind of pressures seen in firearms. So they tend to not be as effective in developing the nice, quick rise in pressure in the comparatively very large volume of a rocket that fine-grained 4FG black powder does. Contained in a firearm's chamber and barrel, smokeless generally has quite a bit more energy released/mass, and can develop much higher pressures than black powder.

+1 for @SolarYellow

 

[Aeva]

Tried it with electrical tape and the result was worse. The electrical tape seems to melt quicker than the painter's tape burns. The result is less comes out than other tests I've done with 0.7g. I'll probably grab some duct tape or look into heat resistant tape... that might work a lot better.

Also, sorry, this thread has kinda been hijacked for ejection charge troubleshooting...

EC Slowmo

 

[SolarYellow]

I didn't even listen to what this guy was saying, except to ID which one is BP and which one is smokeless. Which I would have known by the results, even with the sound off. Obviously, it doesn't take several seconds for the charge of a 7.62 round to burn when the charge is contained in the case/chamber/barrel of a rifle; it drives the bullet to something in the 2500-2700 fps range, typically, so its job is done in just milliseconds.

On the other hand, Pyrodex pellets make great ignitor supplements for composite motors (when carefully and properly engineered), and this shows why.

 

[kjhambrick]

@Aeva

What @SolarYellow was saying is that Pyrodex will only develop pressure similar to 4F BP when it is ignited under pressure -- like in the barrel of a firearm.

One other thing about 4F BP is that it is typically ONLY used in the flash pan of a flintlock or matchlock firearm ( i.e. not in the barrel behind the projectile ).

You might be able to contain the pyrodex long enough to burn completely but at that point, you might as well stuff an M80 behind your 'chute

-- kjh

 

[Approx]

There are probably better people to ask since I am a dual deployment noob... but I think your container has too large a diameter. The area of the opening is too large. It depressurizes too fast. The outer edges havent burned much before the pressure drops. Is that a PVC cap or 3D preinted? can you get a smallelr tube and use that? Could even insert a section fo smaller pipe into the cap and use that. You could also try printing a cap and taping that on. That would keep the heat off the time until the pressure is even higher.

 

[Approx]

A lot of people successfully use pyrodex for charges. Like Kjham said it is just about containing it tighter/longer.

 

[kjhambrick]

A lot of people successfully use pyrodex for charges. Like Kjham said it is just about containing it tighter/longer.

Yes as long as the Pyrodex is contained in a sealed container that does not burst too quickly.

IMO, if you can get it, BP is a lot simpler

-- kjh

 

[Aeva]

There are probably better people to ask since I am a dual deployment noob... but I think your container has too large a diameter. The area of the opening is too large. It depressurizes too fast. The outer edges havent burned much before the pressure drops. Is that a PVC cap or 3D preinted? can you get a smallelr tube and use that? Could even insert a section fo smaller pipe into the cap and use that. You could also try printing a cap and taping that on. That would keep the heat off the time until the pressure is even higher.

It was a cap that apogee sells... but yeah, I'm pretty sure it's just a PVC cap. I can easily print something smaller and more contained, or modify the existing charge cap to be longer.