Fin Guidance for Atmospheric Rockets

Mistake: Don't use Imperial! lol

OK, the biggest single issue that's hit me so far is the unit system I'm using. For the FEM stuff (so far) I was using imperial (you know pounds, foot-pounds, inches, etc. etc.). Well this is a huge mistake as I'm going a long because as I factor things in like velocities (that I want to measure in miles per hour) with inches for the rocket, with foot-pounds for torque, with forces that I really want to use newtons for, I'm quickly becoming a big fan of the Metric system.

The effect of using imperial especially in the guidance firmware is astonishing in the negative. When a good 10% of my coding is just used to calculate arcane conversion factors between feet, miles and inches, and I don't even know what my forces are measured in...maybe in pounds per inches squared. Using metric is very nice in that just sticking with the base units, there are no conversion factors at all. Its kind of funny working in small fractions when working in meters, but I don't have to be wasting my time deriving silly conversion factors.

As long as I stick with kilograms, meters and newtons, I know that the numbers my code is pumping out are all good! Oh, and radians...the computers like the ole radians.

The unfortunate effect is I have a tonne of FEM pseudo-code in imperial that I'll have to throw out. I can convert some of it, but its easier to just re-code in metric, but my guidance code is going to look a lot better I'll tell you that right now.

MinGW and GCC

MinGW is really cool. It runs under Windows perfectly and since its GCC (UNIX C/C++) I can just transfer it too a UNIX-based SBC without any porting at all. It just runs.

Philosophically, I think that writing code fully procedural in base C language is the way to go (no C++). We can't have any glitches in the final product, and there is so much complicated stuff going on behind the scenes with OOP code, strange memory allocations, loading dynamic libraries at weird times, too much you can't say “this will work perfectly every time”. Procedural, statically linked base C code doesn't have any issues at all so for reliability's sake I'm recommending this.

Current Status

Have the FEM pseudo-code utility already coded in C. Unfortunately, I have to throw out hours of work in the actual FEM model to do the conversion over to metric units. Still have to write the FEM model render-er utility (the program that converts the SHELL and RECT pseudo-code over to a true FEM array).

Computed the memory size of the FEM array: 11 Megabytes. With today's 32-bit operating systems, this is perfect AND still small enough to get results in a few seconds to a few minutes.

The guidance firmware uses a 9 x 20 array that accepts massaged data directly from the FEM utilities. This is something that I call semi-dynamic where the actual flight computer on board the rocket uses a highly-simplified FEM model that it can crunch multiple times every second. It computes the moments of inertia, the torques and various forces dynamically and allows such advanced features as the C of G shifting as the propellant burns. It just recalculates the mass, the changing aerodynamics on the fly so minimizing approximations and kludges we have to perform with linear equations. Its a nice mixture of numeric analysis and equations.

Thoughts

I'm starting to get to that phase where I realize I have to watch what I publish and say in regards to legality. Thought I think the weaponization potential of a fin-guided rocket is minimal (the government I think is much more concerned about gimbaled and action-reaction systems), I'm realizing that if you can build one of these things well that more than the FAA would be curious about my activities at some point.

With this in mind, remember that to get your hands on one of these units, I'd need minimum your physical address and a copy of your drivers license and limit sales and distribution to just here in the States. I'm taking about the physical units themselves, so I have something to show whoever comes a knocking. Trust me, back in the day I knew the ATF and postal guys pretty well lol.

Anyways, here is a dump from the guidance software to show you what it figures out (running in single-step mode with simulated data):

---------------------------------------------------------
initializing system...
end of system initialization...

Mass of Rocket: 4500.000000 lbs

Center of Gravity of Rocket: 96.000000 inches from bottom

Moment of Inertia on X Axis: 41488875.000000
Moment of Inertia on Y Axis: 41488875.000000
Moment of Inertia on Z Axis: 51217920.000000

feeding the fin_deflection function with the following sets of fin deflection results in the following angular accelerations along the X-Y-Z axis

Slow yaw right
fin1=0.100000, fin2=0.000000, fin3=-0.100000, fin4=0.000000, velocity=250.000000==> accel_x=0.000000, accel_y=0.389816, accel_z=0.000000

Slow Pitch forward
fin1=0.000000, fin2=0.100000, fin3=0.000000, fin4=-0.100000, velocity=250.000000==> accel_x=0.389816, accel_y=0.000000, accel_z=0.000000

Slow Roll clockwise
fin1=0.100000, fin2=0.100000, fin3=0.100000, fin4=0.100000, velocity=250.000000==> accel_x=0.000000, accel_y=0.000000, accel_z=0.175427

returning control back to operating system...

----------------------------------------------------------------

Numbers still have problems but qualitatively it pitches and rolls in the right directions what looks like a plausible rate; just where I'm at in the process.

Thoughts

Do I think AM/EX and HPR guys would be interested in what I'm working on?

Well, there are really 2 forms of this question. One, can I find a few guys here in Arizona that will let me cut 4 holes in their fav bird and install some hobby servos so I can test the darn thing. And two, would there be enough of a market that if I could get a little turn-key flight control system together that it would be worth my while to distribute it through a hobby shop?

First question: I think its a “sexy” enough of an idea that I could find a few old-timers that might be up for such a challenge. The final unit will have an integrated 6-axis gyro/accelerometer board with a Raspberry PI running ArchUNIX providing the computational power required. The good thing about a solid distribution of UNIX doing the work is that I can run the data logging in a separate process not conflicting with any of the guidance software. I have to correlate where the rocket touches down, with the guidance information loaded and audit the logged data to see that it is doing EXACTLY what I need it to do. It would only weigh about 3-4 lbs (including the servos and fins) and have a very small form factor about twice as big as the existing “flight computers” they have now.

So yeah, I think I could talk some enthusiasts into helping me test it.

Second question: I think I could release the complete turn-key system for about $500 USD retail with enough of a profit margin in there that if I sold at least a few dozen units a year to the HPR community, making me a few thou to tens of thousands a year for my trouble. Its real esoteric stuff though, the only guys interested would probably be total tinkering types. But hey, you'd never loose a rocket and it would hit exactly where you programmed it to (even taking into consideration wind velocity on parachute descent).

You'd communicate with it just like a modern personal router. Just fill in a few fields on a web interface with a tablet or laptop, and its set up ready to go. Pop in launch GPS location, the location you want to recover it at, and you'd find it there every time, even recovering from fatal spins and minor attitude problems.

OK, this doesn't pertain to fin guidance but I'm going to use this area to talk about all aspects o the DBeta's development, the guidance part being perhaps the most difficult.

Motor Design

Have a rocket motor designed for the DBeta. The specs I have for the DBeta are for it to have a nominal altitude of 30,000 feet. However, I have been having difficulty in getting local metal fabricators and machinists helping me get the specialized parts I need (apparently this is a major problem in the kit aircraft area too). This has left me with a maximum turning radius of about 12” diameter for parts.

Constructing the Cicada S-Class solid-propellant rocket motor has to be done with a maximum bulkhead (ie. An end-cap for HPR people out there) diameter of only 12 inches, a lot smaller than the original design called for. Current simulated altitude: only about 12,000 feet. Still a really cool ride (similar in altitude to the recent Copenhagen Suborbitals attempt) but I want to stick with the original goal.

Since the motors are inexpensive to build, I thought of modifying my airframe design to include 3 motors (in case you were wondering what the “structural web” and the motor mounts for 3 motors was for). However upon analysis, I can't fully ensure an asymmetrical thrust situation that would instantly sent the rocket and its occupant into a fatal spin. So there goes clustering (and a bunch of design time and drafting work).

In the motor its interesting. Most of the HPR designs use BATES configuration – no end inhibition. Now this is fine and dandy, but this bird could break mach with G's up to about 2.5G's. With a grain propellant weight of around 50 lbs (the completed motor contains 5 AP/R45/Al grains for a total of about 250 lbs) I realized with the G's its pulling, compared to the weight of the propellant, I can't just scale up HPR/AM/EX designs. My point is, can I trust every grain's propellant to stay bonded to its liner. My answer is: no. Not at these loads.

What needs to happen is the grains need to burn towards the outside (BATES with no inhibition burns both towards the outside but also shrinks the grain) so that I keep the propellant structurally in a compression-type scenario. I'm worried about the shear forces that would rip the propellant right off its liners. To do this requires end inhibition.

Problem occurred: Running Burnsim on the new configuration, it leads to a pressure ramp where there is little pressure at the beginning and a lot at the end. I'm pretty sure I have a solution though: I plan to swap out the ceramic nozzle insert with a faster ablating one, a paper-phenolic slug. As the motor runs, the pressure increases, but so does the nozzle diameter neutralizing the tenancy for higher pressure.

We looked at such possibilities as ribbing the inside of the grain liners (increasing bond area) but was left with the realization that only a chemical bond was sufficient. Also, we aren't sure of the tensile strength of the propellant (especially in shear) thinking it might crack in the axial direction if the rocket pulls too many G's. So we're running the stress compressionally and this will work.

FEM and Guidance Update

Completed transfer to metric; nice side effect is I can either work with an element size of 1cm (10 mm) that leads to a smaller array, or I can go down to 2mm which leads to a larger array but still crunch-able in DRAM.
Finished designing the code for computation of moments of inertia for the rocket. A big step for me and I might add what I found to an appendix in MRGFP.

Thinking seriously of doing away with the 200 node model and sticking with a multi-kilobyte array. It can still be crunched by the flight computer a few times per second, and I think I need the increased fidelity.

Some minor notes: even using small elements (around 5 mm), having problems resolving finer details such at the 1/8” aluminum skin that covers the DBeta. There are two tricks that we use to effectively resolve these finder structures. We can artificially in the FEM modeling increase the thickness of the skin and then normalize it by spreading the known weight of the aluminum over the increased number of elements. This allows a good resolution of it, keeping the elements at the correct positioning, but accurately too because of this kludge. In practice it works perfectly. This is a little too esoteric for MRGFP but I don't think I'm the first guy to use this approach to FEM.