High G-Force Capable Avionics Components

[Dominic Bleacher]

Hello fellow rocketeers, I have done alot in the past few months in terms of rocketry. I have been L1 and L2 certified in under a year and have flown several other hpr rocket projects including possibly the skinniest successful 15ft hpr rocket ever built. I have also been developing a TVC rocket with the goal of keeping it as simple as possible and still function (hopefully to inspire those getting into the hobby to explore some more advanced topics and not be as intimidated). My next project is to make a 4 or 5in fiberglass Mach 3 rocket for my L3 attempt. I've done a few rough OR simulations. Some simulations on an N5500 I believe (and other N class motors) have spiked up to 900-1,000G and reached about 8k-10k ft with approximately a 50+lb rocket (payload masses, material masses, and more were over-ridden and slightly overestimated for what the actual values will probably be). For the build I plan to do a minimum diameter, 4in fiberglass rocket, a 5:1 von karmin, and 3 (maybe 4) 0.25in carbon fiber fins with a tip to tip fiberglass sheeting epoxied onto the fin can.

Anyways...
Where am I going with this?
Well, I wanted to fly an experimental payload with a scratch built computer (obviously I plan to have dual redundant systems for deployment and telemetry at the bare minimum, but will most likely aim for triple or quadruple redundancies for most systems if possible). There is alot that goes into this and I plan to do several smaller scale builds with high G & high velocity flight characteristics to create the most accurate conditions possible for avionics iteration.

I want to be able to test not only the physical avionics package, but also the software. I am aware there are many strange/unexpected things that can happen when you push higher speeds and altitudes in high power rocketry. For example I read in the eggTimer manuals that when they developed their commerical avionics, they added a segment in the software that essentially ignores certain portions in the ascent of the vheicle as not to deploy the recovery system charges mid ascent. They said this was due to the fact that sometimes rapid pressure changes can trick the rocket into thinking it had reached apogee (assuming I understood this correctly). My point is, I want to test these systems on smaller scale rockets to work out all of the unexpected bugs before sticking it in a much more expensive and powerful build.

While the final OR simulation and build will probably/hopefully be a lower G force, higher altitude flight (possibly around 20k ft) and will most likely not show the insane numbers that I posted earlier from my OR simulation, I still want to build a computer that is more than physically capable to handle these more extreme flight conditions.

I'd like my pcb to have a gps, accelerometer, gyroscope, magnetometer, barometric pressure sensor, temperature sensor, some form of wireless connectivity for checking rocket status and arming pyros (it would also be nice to have live telemetry to Ground including a live camera), sd card for onboard flight data logging (maybe log to a flash chip first, then sd card after flight - depends if that is risky or not).

I also read that the readings taken from the accelerometer, gyroscope, and magnetometer can be filtered together in software to determine absolute orientation more quickly/accurately (of course, I have also read there are some flaws/complexities to this approach).

So my main reason in creating/posting this thread is to ask for suggestions on how you would approach this avionics package and software development. What computer components would you recommend for this style of flight? While an accelerometer that is built to read and handle these more extreme flight conditions may be easier to find, the other components needed to meet the desired requirements above are probably not manufactured to function in those abnormally adverse conditions. Are there any main proccesors you would reccomend that could handle all of these breakout boards fine in these conditions? Are there any other features/chips I should add? Would you recommend just sucking it up and solder pasting smaller components instead of the breakout board idea? While I have done several solder board computers, I haven't manufactured a custom layered pcb before, and certainly not for these purposes, so any advice would be much appreciated.

I thought that maybe it would be easier for the first iteration to start with components that are on breakout boards, that way I can solder the header pins of the breakout boards to the main pcb and not have to worry about solder paste and including a hoard of tiny little resistors, capacitors, and leds in my design as well. Would you recommend just sucking it up and solder pasting smaller components instead of the breakout board idea? I currently have the Fusion 360 free subscription for pcb design since Eagle is merging with Fusion 360 soon.

Thank you for your input in advance, your wisdom/experience is much appreciated. (just don't insult my lack of high power knowledge too much ).


**(update) While I don't currently have the OR sim I referenced in the beginning of the post, it was a very rough sketch and I am certain it was flawed. I've caught on multiple occassions my barometric pressure in the sim being set completely incorrect for some reason when I never touched the value. While I don't have the original file anymore, of course I know there is no way it could come near 1000G during a prototypical ascent. I will start over on a new file and update this post with the actual values. I was more so emphasizing that I wanted recommendations for high quality computer chips acclerometers, gyros, etc. (as all were listed above), that are built to handle more extreme conditions and recommendations for what I should take into consideration for software development.

 

[cerving]

1,000 G's sounds a little high... the most I've ever heard of is 200 G's, and that was with some pretty extreme motors on a minimum diameter airframe. The highest value that you can get in a MEMS accelerometer is 400 G's, IIRC; the one that we use in the Eggtimer Proton is rated at 200 G's. Just about all SMT components can easily handle any stresses that you're going to encounter in a normal flight. Coming in ballistic at > 500 fps does not qualify as "normal", however... although I've seen some of our altimeters survive that if the airframe didn't collapse into the AV bay and mechanically trash them.

If I were you, I would use the breakout boards to test and refine your circuitry and your software, and learn Eagle or KiCad so you can design real PC boards, which you can prototype on the cheap by OshPark. Once you get into the realm of HPR (or even MPR, with G motors) you're going to find that those breakout boards are large, heavy, and fragile. The first altimeter I ever flew was like that... and it came apart at launch with only a D12 motor. Lesson learned... altimeter #2 was on a real PC board with no breakouts.

 

[jderimig]

1,000 G's sounds a little high...

Happens all the time at BALLS when I am there. Not during the up part though....

 

[kjhambrick]

My next project is to make a 4 or 5in fiberglass Mach 3 rocket for my L3 attempt. I've done a few rough OR simulations. Some simulations on an N5500 ... <<snip>> ...

@Dominic Bleacher --

Were you able to find a Loki N-5500-LW RASP .eng file somewhere ?

I was trying to follow along with my own OR Sim and there is no .eng file on ThrustCurve.org > N-5500-LW yet ...

Thanks !

-- kjh

 

[Spacedog49Krell]

1,000 G's acceleration with a rocket motor is very difficult. The action time of the motor will be <100 milliseconds. All of the micrograin rockets I've instrumented accelerated between 100-200 G's with 300-400 ms motor action times. The ground impact decelerations of the micrograin rockets ranged from 670-900 G's with durations of 16-22ms. Ground compaction being the main variable for deceleration. The shortest action motor I designed was 82 ms for the Dragon anti-tank weapon. The launch tube acceleration was between 350-400 G's.

Commercial integrated circuits are designed to withstand 10,000 G's for a few milliseconds. Project HARP produced projectile accelerations between 7,000-16,600 G's with durations up to 86 ms, but they were launched with a canon.

There are 1,000 G linear accelerometers available and newer MEMS sensors under development. Analog Devices has a 500 G MEMS sensor.

 

[Dominic Bleacher]

@Spacedog49Krell
@kjhambrick
@jderimig
@cerving

Ok, since everyone is freaking out over the simulation values which I clearly said were not accurate, let me provide another update. Upon retrieving my other computer from my other residence with the sim I referenced, the simulation was flawed like I said. The CP was incorrect and the rocket encountered a high angle of attack in the sim, which resulted in a high g-force value due to instability & failure. After re-saving the sim and properly repositioning the avionics bay, the sim ran 26G, and 32k ft on an Aerotech N3300. Since I didn't have access to my other computer that I commonly use Open Rocket on, I just made a guess of what the impulse was when typing the orignial thread post because I couldn't remember. I apologize as this seems to have upset some folks and I do appreciate the feedback, however the main point and question centered around creating this thread was about avionics. Feedback about that topic (related questions in paragraphs 5-7 of the original thread post) would be much appreciated.

Thanks again for your time.

 

[Spacedog49Krell]

Dominic,
I'm not freaked out. I just stated facts with real number values that I have recorded from my experiments. I encourage others to attempt what some may consider to be impossible. How else do we learn? We all need a visionary to push our thinking beyond what is known and recorded in books. I strive every day to come close to what my early mentor, Dr. Gerald Bull, achieved in Project HARP.

 

[cerving]

Not freaking out, just letting you know that your numbers were suspect. But it sounds like you figured that out on your own...

 

[kjhambrick]

Nor was I freaked out.

I was honestly looking for a RASP.ENG file for the newly certified Loki N5500 Grains for the CTI Pro98 6GXL case that @Alan Whitmore reported here on TRF in April.
.
If you browse the ThrustCurve.org > Loki N5500LW page, you will see that @JohnCoker has the metadata for the Loki / CTI N-5500-LW but he has no thrust curve data.

Unless I win the Super Lotto, I don't imagine I'll ever fly an N-5500-LW motor in real life.

But I do like to live vicariously thru other member's real flights, so I run OR sims for rockets that other people design and build and and fly.

I imagine if I ever want to 'fly' the new Loki N-5500-LW in Open Rocket, I'll have to make a Loki-N-5500-LW.eng file for myself and then submit it to John for ThrustCurve.org

However, now that you made me look harder at your first post, I don't believe any APCP motors exist that are capable of accelerating themselves at 1000G, and that's before adding the mass of a rocket to the picture.

But I am still not freaked out -- I live in a glass house myself, so I try to remember to throw no stones

I wish I could help you with your real mission -- I can't -- but @cerving @jderimig and @Spacedog49Krell and other Well-Known Members on TRF know what they're doing so you're in good hands.

-- kjh

EDIT: The Cesaroni 20146N5800-P looks pretty close to the new Loki N-5500-LW motor.

 

[Spacedog49Krell]

However, now that you made me look harder at your first post, I don't believe any APCP motors exist that are capable of accelerating themselves at 1000G, and that's before adding the mass of a rocket to the picture.

I wish I could help you with your real mission -- I can't -- but @cerving @jderimig and @Spacedog49Krell and other Well-Known Members on TRF know what they're doing so you're in good hands.

KJH,

You did help, by recognizing errant simulator results. The posted simulator results didn't match your known flight data. Each of your flights with the Blue Raven flight computer is producing years of potential study. I'm still extracting new information from my data that is 5 years old. Barometric data that appeared to have a small amount of noise turned out to be solar light entering the avionics bay producing a superimposed roll rate in the altimeter data, as an example.

There are several motors in the ThrustCurve list that are currently producing close to 200G launch accelerations that are wasting over 70% of potential work energy, during the first 250 milliseconds of motor action time. Harnessing that heat energy to produce work could produce launch accelerations close to 1000G's.

 

[Dominic Bleacher]

@Spacedog49Krell
@cerving
@kjhambrick
@jderimig

I would like to just briefly apologize as I realize a portion of the reply I made was a little short tempered and rude. I wasn't intending to come across that way and meant it more in a joking manner, but that still doesn't make it any better. Thank you for your support and all of the interesting feedback.

 

[Dominic Bleacher]

KJH,

You did help, by recognizing errant simulator results. The posted simulator results didn't match your known flight data. Each of your flights with the Blue Raven flight computer is producing years of potential study. I'm still extracting new information from my data that is 5 years old. Barometric data that appeared to have a small amount of noise turned out to be solar light entering the avionics bay producing a superimposed roll rate in the altimeter data, as an example.

There are several motors in the ThrustCurve list that are currently producing close to 200G launch accelerations that are wasting over 70% of potential work energy, during the first 250 milliseconds of motor action time. Harnessing that heat energy to produce work could produce launch accelerations close to 1000G's.

I especially find the statement about the solar rays interfering with the avionics bay you mentioned to be just mind boggling. Instances like those are what make a project like this very intimidating and difficult because there are alot of unexpected things that could go wrong. What other things should I expect at these speeds in terms of software errors and computer performance?


Do you know anything about the method I mentioned of combining the magnetometer, accelerometer, and gyroscope values and then filtering them to determine some sort of absolute orientation. Is that a possibility? I thought I read about it once but I don't remember. I'll look more into it.

Thanks.

 

[Spacedog49Krell]

I especially find the statement about the solar rays interfering with the avionics bay you mentioned to be just mind boggling. Instances like those are what make a project like this very intimidating and difficult because there are alot of unexpected things that could go wrong. What other things should I expect at these speeds in terms of software errors and computer performance?


Do you know anything about the method I mentioned of combining the magnetometer, accelerometer, and gyroscope values and then filtering them to determine some sort of absolute orientation. Is that a possibility? I thought I read about it once but I don't remember. I'll look more into it.

Thanks.

I've worked with Space Cup and ARC teams that required an absolute orientation for altitude control. The current ARC team I'm helping can predict and control the maximum altitude to +/- 1 meter. You will need to become familiar with Euler Angles and Quaternions. Bosch Sensortec is developing an IMU with an internal fusion orientation algorithm for accelerations up to 16G's. The current BMO055 is limited to the 4G acceleration range. Are you wanting to control the vehicle attitude or just know the attitude?

The solar light interference data showed me that I needed to paint the interior of my avionic bays flat black. The barometric sensor was light shielded, but three out of seven flights recorded some solar light interference. It was not a bad issue. When I realized what the data was revealing, roll rate, it added a new dimension of understanding to the flight dynamics analysis. Today, I use IMU's with gyros for roll rate data.

 

[jderimig]

Do you know anything about the method I mentioned of combining the magnetometer, accelerometer, and gyroscope values and then filtering them to determine some sort of absolute orientation. Is that a possibility? I thought I read about it once but I don't remember. I'll look more into it.

In flight the absolute orientation can only be determined by the gyro. The accelerometer and magnetometer is almost useless. In theory the magnetometer can be used to correct for long term gyro drift but in the time scale of a rocket flight it is not needed as the drift will be very low with a good gyro with low cross axis acceleration sensitivity. The accelerometer can be used on the pad to determine pad tilt angle, but if you do an error analysis you will find a carpenter's level is superior. If you want true orientation relative to an earth coordinate system you want to align the x-y axis of the gyro to the xy axis of the earth on the pad. The rest is good quaternion integration.

 

[Dominic Bleacher]

I've worked with Space Cup and ARC teams that required an absolute orientation for altitude control. The current ARC team I'm helping can predict and control the maximum altitude to +/- 1 meter. You will need to become familiar with Euler Angles and Quaternions. Bosch Sensortec is developing an IMU with an internal fusion orientation algorithm for accelerations up to 16G's. The current BMO055 is limited to the 4G acceleration range. Are you wanting to control the vehicle attitude or just know the attitude?

The solar light interference data showed me that I needed to paint the interior of my avionic bays flat black. The barometric sensor was light shielded, but three out of seven flights recorded some solar light interference. It was not a bad issue. When I realized what the data was revealing, roll rate, it added a new dimension of understanding to the flight dynamics analysis. Today, I use IMU's with gyros for roll rate data.

Is the ARC team you mentioned using some form of airbrake to achieve the target altitude or some othet active control method? It would be neat if I could do altitude control but I haven't really decided yet. I was more interested in hitting my target speed successfully and getting live telemetry data of the flight and what not, but active altitude control would be cool.

Also why did you paint the interior of the avionics bay black. Wouldn't black absorb more light/heat instead of white? This is still super interesting. So just to clarify, this issue didn't cause any major issues during flight, it just introduced some noise to your final data, correct?

Thanks again.

 

[kjhambrick]

@Spacedog49Krell
@cerving
@kjhambrick
@jderimig

I would like to just briefly apologize as I realize a portion of the reply I made was a little short tempered and rude. I wasn't intending to come across that way and meant it more in a joking manner, but that still doesn't make it any better. Thank you for your support and all of the interesting feedback.

No worries, @Dominic Bleacher

So ...

It bugged me that there was no thrust curve for the new Loki N-5500-LW Grains for the CTI Pro98 6GXL case.

You really got my curiosity going when you referred to that motor in an OR sim so I made a Loki-N-5500-LW.eng file for OpenRocket.

Attached.

And then I added the file to ~/.openrocket/ThrustCurve/ directory before starting OpenRocket ( that is the Linux OR $HOME ... not sure where one would put .eng files on Windows ).

Anyhow, this is a min-diameter / min-length rocket built around the CTI Pro98 6GXL case with a few motors, including the new N5500:



Not that I'll ever actually fly this rocket in real life but I DO like creating Walter Mitty Models

The .ork file is attached ... but be sure to install the .eng file before starting OR or you'll get an error about a missing thrust curve.

Whee !

-- kjh

p.s. I'll send this motor to @JohnCoker at thrustcurve.org as soon as I resolve a question or two about the motor with John and @Alan Whitmore

 

[Dominic Bleacher]

In flight the absolute orientation can only be determined by the gyro. The accelerometer and magnetometer is almost useless. In theory the magnetometer can be used to correct for long term gyro drift but in the time scale of a rocket flight it is not needed as the drift will be very low with a good gyro with low cross axis acceleration sensitivity. The accelerometer can be used on the pad to determine pad tilt angle, but if you do an error analysis you will find a carpenter's level is superior. If you want true orientation relative to an earth coordinate system you want to align the x-y axis of the gyro to the xy axis of the earth on the pad. The rest is good quaternion integration.

So for the most part, an accelerometer would just be useful for measuring acceleration in terms of g-force? What other reasons do people include accelerometers and magnetometers for or is that about it. Would you recommend integrating a magnetometer into my pcb design or leaving it out altogether?

To align the xy axis on the pad, would you just use a level I suppose or did I misread.

Finally, would you mind briefly explaining or pointing me towards some resources that explain quaternions in more detail and how to integrate them? It is still a difficult and new concept to me. All I understand so far is that I think it has to do with orientation/roll characteristics relative to an arbitrary axis or a specific earth coordinate. Still not sure if I understood that correctly though.

Thank you.

 

[kjhambrick]

In flight the absolute orientation can only be determined by the gyro. The accelerometer and magnetometer is almost useless. In theory the magnetometer can be used to correct for long term gyro drift but in the time scale of a rocket flight it is not needed as the drift will be very low with a good gyro with low cross axis acceleration sensitivity. The accelerometer can be used on the pad to determine pad tilt angle, but if you do an error analysis you will find a carpenter's level is superior. If you want true orientation relative to an earth coordinate system you want to align the x-y axis of the gyro to the xy axis of the earth on the pad. The rest is good quaternion integration.

That does it !

Now I need a digital level to measure the rail attitude in pitch / yaw directions to check the data recorded by the Blue Raven

-- kjh( and they already make fun of me for all the 'electronics' I carry out to the pad )

EDIT: And thanks for reminding me to bring a tape measure to the pad so I can measure the distance from my rail buttons to the top of the rail ( now on my check list )

 

[Dominic Bleacher]

No worries, @Dominic Bleacher

So ...

It bugged me that there was no thrust curve for the new Loki N-5500-LW Grains for the CTI Pro98 6GXL case.

You really got my curiosity going when you referred to that motor in an OR sim so I made a Loki-N-5500-LW.eng file for OpenRocket.

Attached.

And then I added the file to ~/.openrocket/ThrustCurve/ directory before starting OpenRocket ( that is the Linux OR $HOME ... not sure where one would put .eng files on Windows ).

Anyhow, this is a min-diameter / min-length rocket built around the CTI Pro98 6GXL case with a few motors, including the new N5500:

View attachment 662857

Not that I'll ever actually fly this rocket in real life but I DO like creating Walter Mitty Models

The .ork file is attached ... but be sure to install the .eng file before starting OR or you'll get an error about a missing thrust curve.

Whee !

-- kjh

That is awesome! Thank you. I believe Loki has a thrust curve for an N3800 motor on there also. I've actually never flown a motor from Loki Research. I noticed you said that the propellant is designed to fit in a CTI Pro 6GXL case. Do most of Loki Research's propellant grains also fit inside aerotech reload systems or are they unique and only work with CTI.

Thanks again

 

[kjhambrick]

KJH,

You did help, by recognizing errant simulator results. The posted simulator results didn't match your known flight data. Each of your flights with the Blue Raven flight computer is producing years of potential study. I'm still extracting new information from my data that is 5 years old. Barometric data that appeared to have a small amount of noise turned out to be solar light entering the avionics bay producing a superimposed roll rate in the altimeter data, as an example.

There are several motors in the ThrustCurve list that are currently producing close to 200G launch accelerations that are wasting over 70% of potential work energy, during the first 250 milliseconds of motor action time. Harnessing that heat energy to produce work could produce launch accelerations close to 1000G's.

This reminds me ... it would be great to have an online site where we could share flight data for any / all flight computers along with some sort of metadata to define the contents of the different file formats ...

Maybe something to keep me busy after I retire

Yes, there are some very edgy commercial motors out there aren't there

-- kjh

 

[kjhambrick]

That is awesome! Thank you. I believe Loki has a thrust curve for an N3800 motor on there also. I've actually never flown a motor from Loki Research. I noticed you said that the propellant is designed to fit in a CTI Pro 6GXL case. Do most of Loki Research's propellant grains also fit inside aerotech reload systems or are they unique and only work with CTI.

Thanks again

TMT Chairman @Alan Whitmore posts the results of his TMT certs here on TRF in the Propulsion sub-forum.

Alan posted about the new Loki N-5500-LW and two other Loki motors here: New Motors Certified, April 2024 (Loki Research)

I believe the new Loki N-5500-LW grains are a 'special case' ( no pun intended ) in that they were designed and certified for the CTI Pro98 6GXL case.

Otherwise Loki reloads: Loki Research > Products > Reload Kits are designed for Loki Research > Hardware

I don't know for sure but I don't see any available Loki 98mm hardware but I am no expert ...

I am not sure about Loki Grains in Aerotech Hardware and unless a specific combination is certified they would fall under Research / Experimental motors so that might be a Q for the TRF > Research sub-forum.

HTH

-- kjh

 

[cerving]

The magnetometer and low-G accel will help you get oriented while you're sitting on the ground, but you'll need to fuse a high-G z-axis accelerometer and the gyros to determine your altitude and position. The "up" part of hobby rocketry launches doesn't last long enough to worry about sensor drift, as long as you're using newer sensors.

Fun stuff.

 

[jderimig]

So for the most part, an accelerometer would just be useful for measuring acceleration in terms of g-force? What other reasons do people include accelerometers and magnetometers for or is that about it.

The integration and double integration of the accelerometer will give you the most accurate estimate (when implemented well) of the rocket speed and altitude while it is moving fast. Acceleration data is also useful to estimating rocket motor thrust curve, total impulse and drag coefficient versus speed. And other interesting events like motor burnout, deployment events and if you are unlucky catastrophic events.

Would you recommend integrating a magnetometer into my pcb design or leaving it out altogether?

Yes if you are recording data. You may find a useful application for it. You never know.

To align the xy axis on the pad, would you just use a level I suppose or did I misread.

To align the z-axis of the vehicle to the z-axis of the earth at time zero.

Finally, would you mind briefly explaining or pointing me towards some resources that explain quaternions in more detail and how to integrate them? It is still a difficult and new concept to me.

Are you looking to learn the deep math behind them or more utilitarian knowledge on algorithms to do the job? For a mix of both you can start here...

https://prgaero.github.io/Reports/p1a/rehmnicholas.pdf

 

[Spacedog49Krell]

Is the ARC team you mentioned using some form of airbrake to achieve the target altitude or some othet active control method? It would be neat if I could do altitude control but I haven't really decided yet. I was more interested in hitting my target speed successfully and getting live telemetry data of the flight and what not, but active altitude control would be cool.

Also why did you paint the interior of the avionics bay black. Wouldn't black absorb more light/heat instead of white? This is still super interesting. So just to clarify, this issue didn't cause any major issues during flight, it just introduced some noise to your final data, correct?

Thanks again.

A very unique "spin drag" system. Researching past ARC entries, I found three previous entries with almost identical spin systems. The original idea was to spin the rocket at 2-3 RPS for additional drag to control altitude. They are now railing the roll gyro at 8-10 RPS. I had to show them how to use the pitch and yaw gyro and accelerometer data to determine an approximate roll rate. They may need to use an LED, like Forest Mims taught me.

Black absorbs the internal reflected light. The outside of the avionics bay is silver to reflect away the visible and infrared photons. The solar light enters through an activation access port. I mount the barometric sensing aperture to face the motherboard pcb and there was still sufficient reflected light to offset the pressure sensor.

Attached is the raw altimeter data and a velocity algorithm chart that highlights the effect light has on the BMP280 sensor.

 

[Dominic Bleacher]

The integration and double integration of the accelerometer will give you the most accurate estimate (when implemented well) of the rocket speed and altitude while it is moving fast. Acceleration data is also useful to estimating rocket motor thrust curve, total impulse and drag coefficient versus speed. And other interesting events like motor burnout, deployment events and if you are unlucky catastrophic events.

Very interesting. Are there any specific chips you recommend for the tasks I want my custom pcb to be able to handle?

.... I'd like my pcb to have a gps, accelerometer, gyroscope, magnetometer, barometric pressure sensor, temperature sensor, some form of wireless connectivity for checking rocket status and arming pyros (it would also be nice to have live telemetry to Ground including a live camera), sd card for onboard flight data logging (maybe log to a flash chip first, then sd card after flight - depends if that is risky or not).

So my main reason in creating/posting this thread is to ask for suggestions on how you would approach this avionics package and software development. What computer components would you recommend for this style of flight? While an accelerometer that is built to read and handle these more extreme flight conditions may be easier to find, the other components needed to meet the desired requirements above are probably not manufactured to function in those abnormally adverse conditions. Are there any main proccesors you would reccomend that could handle all of these breakout boards fine in these conditions? Are there any other features/chips I should add? Would you recommend just sucking it up and solder pasting smaller components instead of the breakout board idea? While I have done several solder board computers, I haven't manufactured a custom layered pcb before, and certainly not for these purposes, so any advice would be much appreciated.

I am also sort of stuck as to where to start with a project this big. I've never done a custom layered pcb like this before. Are there any specific chips you recommend that are sold in both breakout board form and as an individual component that way I could test with a breakout or solder board first before getting a pcb fabricated? Is there a better approach to doing this? I guess one of my biggest concerns is also once I find what chips I want to include, I'll struggle with knowing exactly what & where to place resistors, capacitors, etc. for those chips to function properly.

Are you looking to learn the deep math behind them or more utilitarian knowledge on algorithms to do the job? For a mix of both you can start here...

https://prgaero.github.io/Reports/p1a/rehmnicholas.pdf

Very interesting read. I especially liked the graphs that show how efficient/effective the Madgwick Filter is. Do you have any other resources that describe more about how quaternions work?

Thanks.

 

[Dominic Bleacher]

A very unique "spin drag" system. Researching past ARC entries, I found three previous entries with almost identical spin systems. The original idea was to spin the rocket at 2-3 RPS for additional drag to control altitude. They are now railing the roll gyro at 8-10 RPS. I had to show them how to use the pitch and yaw gyro and accelerometer data to determine an approximate roll rate. They may need to use an LED, like Forest Mims taught me.

That is very cool. Sounds like it would be very difficult and take alot of tuning to get right especially for a high power rocket. Was this spin drag control achieved with a reaction wheel or am I misunderstanding.

Black absorbs the internal reflected light. The outside of the avionics bay is silver to reflect away the visible and infrared photons. The solar light enters through an activation access port. I mount the barometric sensing aperture to face the motherboard pcb and there was still sufficient reflected light to offset the pressure sensor.

Attached is the raw altimeter data and a velocity algorithm chart that highlights the effect light has on the BMP280 sensor.

Ah that makes much more sense now. It seems like it had more effect than what I would have expected wow. Thanks for all of the interesting info.

 

[jderimig]

I am also sort of stuck as to where to start with a project this big. I've never done a custom layered pcb like this before

I wouldn't start with a project this big if you are new to pcb design. I would start with a simple board, maybe a baro + accel dual deployment board with pyro outputs. Then put some expansion ports on the board that support UART, I2C or SPI. Get the simple board to work and programmed. Then add the other functionality as you go with expansion boards. Gyro board, GPS board, radio board etc. When you get it all the work then you can attempt to integrate it on one board.

 

[Spacedog49Krell]

That is very cool. Sounds like it would be very difficult and take alot of tuning to get right especially for a high power rocket. Was this spin drag control achieved with a reaction wheel or am I misunderstanding.



Ah that makes much more sense now. It seems like it had more effect than what I would have expected wow. Thanks for all of the interesting info.

They started with tuning, but the variability between identical power motors and atmospheric conditions revealed tuning didn't work. They had to make real time calculations for each flight. They use two canards, close to the CG, to spin the rocket. The stabilization fins create greater drag as the vehicle spins faster. They had to calculate Euler angles for off vertical flights and predict the maximum altitude after motor burnout. They had to design their own flight computer. It turned into a very complex project.


I used the barometric data as a pseudo-accelerometer for velocity data and that was the result. Shining a bright light on the sensor revealed the source of the altimeter change.

 

[Dominic Bleacher]

I wouldn't start with a project this big if you are new to pcb design. I would start with a simple board, maybe a baro + accel dual deployment board with pyro outputs. Then put some expansion ports on the board that support UART, I2C or SPI. Get the simple board to work and programmed. Then add the other functionality as you go with expansion boards. Gyro board, GPS board, radio board etc. When you get it all the work then you can attempt to integrate it on one board.

That seems like a good suggestion. Is it common practice for people to essentially copy elements on a breakout board into their pcb design? For example, the BME280 barometric pressure sensor is sold both in breakout board and indivdual sensor forms. Would you recommend just copying/integrating the resistors and capacitors that might be on the commercial breakout board into my pcb design since my final pcb design won't utilize breakout boards? The BME280 is probably less intricate of an example but I know some of the other modules such as altimeters, gps units, and especially processors from microcontrollers that do have alot of microcomponents.

Thank you

 

[Dominic Bleacher]

They started with tuning, but the variability between identical power motors and atmospheric conditions revealed tuning didn't work. They had to make real time calculations for each flight. They use two canards, close to the CG, to spin the rocket. The stabilization fins create greater drag as the vehicle spins faster. They had to calculate Euler angles for off vertical flights and predict the maximum altitude after motor burnout. They had to design their own flight computer. It turned into a very complex project.


I used the barometric data as a pseudo-accelerometer for velocity data and that was the result. Shining a bright light on the sensor revealed the source of the altimeter change.

Wow, that is extremely impressive for a university team. I recently watched the BPS Space video on roll controll with a fin tab. It was a neat summary of all the different roll control methods that can be used (including canards). Leading canards and moveable fins are especially difficult since just the slightest movement can have a massive impact on performance on the roll axis and they typically have a larger surface area interfering with the windstream compared to the smaller fin tab method.

Do you have any articles on the subject you'd recommend I check out? I am very intrigued about this topic now .




Even though I'll probably start with a smaller project more along the lines of what @jderimig said:

I wouldn't start with a project this big if you are new to pcb design. I would start with a simple board, maybe a baro + accel dual deployment board with pyro outputs. Then put some expansion ports on the board that support UART, I2C or SPI. Get the simple board to work and programmed. Then add the other functionality as you go with expansion boards. Gyro board, GPS board, radio board etc. When you get it all the work then you can attempt to integrate it on one board.

In the mean time, what sensors would you recommend overall for the bigger pcb I had planned for my Mach 3 rocket project? I'm trying to get as wide of a spread of input as possible to see the pros and cons of different approaches.

...I'd like my pcb to have a gps, accelerometer, gyroscope, magnetometer, barometric pressure sensor, temperature sensor, some form of wireless connectivity for checking rocket status and arming pyros (it would also be nice to have live telemetry to Ground including a live camera), sd card for onboard flight data logging (maybe log to a flash chip first, then sd card after flight - depends if that is risky or not).

So my main reason in creating/posting this thread is to ask for suggestions on how you would approach this avionics package and software development. What computer components would you recommend for this style of flight? While an accelerometer that is built to read and handle these more extreme flight conditions may be easier to find, the other components needed to meet the desired requirements above are probably not manufactured to function in those abnormally adverse conditions. Are there any main proccesors you would reccomend that could handle all of these breakout boards fine in these conditions? Are there any other features/chips I should add? Would you recommend just sucking it up and solder pasting smaller components instead of the breakout board idea? While I have done several solder board computers, I haven't manufactured a custom layered pcb before, and certainly not for these purposes, so any advice would be much appreciated.

I'd like to start thinking about this now so I am ready to jump right into the final board iteration once the initial smaller test pcb project is done.

Thanks again.