Friday, November 20, 2015

motor design...

Here is a quick note about the Motor we are going to fire on Saturday...

The Grey is the 3D printed motor.
The Light Blue is the part I turned and machined (4 times)
The Gold is the peroxide going down the cooling passages...
The Red is the peroxide coming back up the cooling passages... (The gold and red connect at the right end of this drawing.
The Green is the Catalyst pack that turns the oxidizer from liquid to Steam and hot Oxygen.
The Yellow in the band around the middle and in (two shown) the four fuel injectors that inject fuel just below the cat pack.

Thursday, November 12, 2015

Jet Packs... aerodynamics questions and thoughts....

If you follow such things the Jet pack from  was subject to all geek discussion last week. Today I say an article here:

This describes the controls of the jet pack.....

Notice that the only video we have seen is of it flying somewhat low over water. This means in the mind of the designer its not safe over anything hard.

There is pitch and yaw control, but no roll control other than weight shift.
To me this means that the output from the two jet engines must be really closely matched.
Loose either  engine to something as simple as an air bubble in a fuel line and your spinning wildly out of control.

So how would you build a safe useful jet pack?

Minor expected faults won't kill you.
Single engine, sensor or actuator failures wont kill you.

Able to fly at whatever altitude fuel will allow over any surface.

In my mind a safe useful jetpack would have the following:

Flyby wire artificial stability.
Engine out failure recovery from any altitude.
Safe escape from and single engine,sensor  battery or actuator failure.

This implies to me multiple engines with some kind of thrust vector control.
You need enough  control authority to maintain stability with one engine out.
You need enough control authority to maintain stability with one actuator or motor in hard over failure.

You don't have to always land, you can have failure induce a rapid climb to an altitude that ballistic parachute can deploy. (300 ft or so)

Rather than two motors I would think at least two per side. This means that if you loose an engine on one side all of the the other engines must have enough control authority to keep thrusting through the center of mass.  If the control authority point is above the CG (like their jetpack) then the gimbal on the good side will have to point toward the passengers legs, probably frying them.  To me this imples that the jet point of thrust vector control must be below the CG. IE the jets must move down on the human.  Then the thrust vector to compensate for rolling (or pitching) moment from a failure on the other side would point away from the pilot.  It also implies that each side have enough thrust so that if 1 motor fails it can hold up its side......

So I see something like 3, 4, or 5  smaller motors per side.

With 5 motors a side I believe you might be able to control the vehicle with just thrust throttling...

If you need thrust vectoring then a flap that you can deploy into the exhaust stream that deflects it in the  direction of the semi circle away from the pilot.

In thinking about things one of the scariest failures would be bearing failure where the motor dumps all its built up momentum in the free flying vehicle as its thrust goes away.....

I just don't see how the Jetpackaviation jet pack we have all recently seen could be made "safe" for flight over hard surfaces.

Some random observations:

From their images JB-8 was more of a flying sled. Its real clear that the JB-8 used two TT-100 247lb thrust jets, the same as the sonix jet uses.  These are about 50K each.

Its also clear that the JB-9 uses two smaller engines... AMT Nike motors.(24K Euro each)  I wonder if the motors  counter-rotate, or if they don't how much rolling moment pitch changes make given the gyro coupling.... since the  designer and test pilot are both helicopter pilots they will be very familiar with the 90 gyro force motion phase shift....

In looking at the middle of their three videos the "Gopro" one that they are using standard box stock RC turbine ECU displays for the engines mounted on the stick grips, these displays are on the tether flight video, but not the NY harbor one... or the promotional jet pack pictures.

On the tether flight video one can clearly see a large LIPO battery pack connected to the engine ECU under the cover.

Also in the NY harbor video there looks like an added frame to keep the tether training cable from getting wound around the pilots head....

Needless to say I want one...

P.S. I want to see their blooper reel...
Edited to add info on what motors they are using.

Monday, July 20, 2015

GPS on several fronts...

This week end I flew an open source Piksi GPS on an HPR to see if it could be made to keep
lock at high acceleration without any imu aiding. I modified the tracking constants of the piksi software .(actually used # defined for wide bandwidth tracking already in the latest software)

It lost lock at boost, got lock again at apogee (strong winds at FAR apogee horizontal V was 204knots!)  This pulled the electronics bay out of the vehicle when the drogue deployed at that speed.  Fortunately its a sturdy rocket and it survived a no main chute deploy with minor damage.

There were some issues I think I set the lock detection too too optimistic and it tracked some noise...
I will fly a Piksi again recording the Raw RF some time in early Aug.
(I'm also going to change out the TCXO for one with lower G sensitivity see discussion below)

On a 2nd GPS front PSAS flew a software GPS receiver on their rocket on Sunday.
They gathered raw data, but they don't have the full GPS solution working yet.
They posted the following graph

It shows doppler shift in the tracked sats.
I actually question that a little bit...

Doppler is what makes a trains whistle change tone as if goes past.
If you change the velocity with respect to a radio transmitter the frequency will shift.

There is another effect that can also effect this data... the RF system on a GPS uses a very precise clock (usually a TXCO)  in the receiver.  That clock may have acceleration sensitivity.
IE the frequency of this oscillator may vary with applied acceleration...

I'm somewhat suspicious that the graph above shows this more than Doppler shift.
I have not looked up the orbits of the gps sats at the time of flight or the position of PSAS flight, but I'll make some assumptions...

The GPS sats are scattered randomly about, ie some are almost straight up and some are at the horizon.  If the rocket flies straight up one would expect a bigger doppler shift for the sat straight over head and much less shift for the sats at the horizon as their relative velocity changes less.
Also if the rocket turns into the wind and has some horizontal velocity one might even expect a doppler shift in the other direction for the sat you are flying toward/away from.

However if the frequency shift is due to g effects on the reference clock one would expect all the doppler shifts to move the same direction....

So it looks like they got a shift of about 1400 hz  at 1.5Ghz that would be a velocity of  140 m/sec or so... at 1.5 Ghz. So the magnitude is withing the realm of possibility...

(The graph also shows an overshoot at the end of the rocket burn this is the acceleration changing direction from the perspective of the GPS receiver.)

There are vendors that specifically sell clock oscillators with low G sensitivity...

Given their data the PSAS should be able to determine this.
With a full GPS solution derived from the data (they have not done this yet)
They will get position velocity and time....
They also have sample of data precisely clocked out via their reference oscillator...
The difference between the time in the solution and the time via their local clock can
be measured and will give an idea of clock drift.

They can also calculate the expected doppler between them and the individual sats and see how that compares with the   measured doppler any difference is clock error...

All of these data extractions require they get a full solution running....

There is a quick and dirty test they can do with just what they have...

Run their gps sampler system on the ground with a fixed  stationary antenna...

Now take the GPS board and orient it it differently in the 1g gravity field.
6 combinations IE board component side up, component side down, tipped on its end, pointing up, down right left....

 and generate the doppler graph above...  if the doppler shifts with orientation of the sampler board then they probably need a more stable clock.

  At  bare minimum this test will show them what axis has the lowest clock sensitivity....

In any case I really applaud what the PSAS guys are doing!

Monday, July 06, 2015


Over the last two weeks John and I have built and failed 10 or so short tank samples.
We have a tank solution... fully allocated with fittings and end caps we have a MR of about
15 at 795 PSI burst. (16 at 500 psi)

Now we have to put together the tooling to make flight length tanks , ie longer than the samples.

I did a 3d printed regen motor design and sent off to have a SLS nylon version printed to evaluate.
That should be here today.

Not sure if I want to put gimbal at the nozzle (as test print) or up at the top of the motor...
Been busy....

Tuesday, June 16, 2015

Tanks again

I finished fabricating all the parts for the tank test V2.
I should be able to assemble and test this evening.
This is a short piece of test carbon tube with reinforced ends for additional load bearing,
The end caps are 0.075" domes with AN-8 o-ring ports on them.  The outside of the dome had to be cut with two different cutting tools, so you can see a line/step of about 0.010" where I changed tools.

Update I put it all together and hydro tested it this evening.
It failed at about 850PSI.  The bag and end caps leaked profusely until about 300psi when the o-rings seated. At 500 PSI it held pressure with zero leakage.  The primary failure seemed to be a radial  split down the center.


Wednesday, June 10, 2015

Slightly OT How to get from old world to new world (parts and vendors)

Twenty years ago everything slightly technical came through a distributor that provided technical support.  Today the internet is a source of that support, so what function does the distributor provide?

I was looking to buy some tooling for my lathe. (Names not included to protect the innocent)
I found the exact thing I wanted where a vendor had a nice description of how to use the tool and had captured the exact thing I was looking for...

I emailed the vendor, they entered my information in their system and one of their technical people provided me with a quote and some nice technical information on the proper usage of the part....

So far we are happy everything is golden....

The problem is there was no way to order the part.  On their website their was a list of 29 distributors for their stuff in CA.  I called one at 2:15 pm they said the factory is closed I can't get you delivery info.... I'll call you back on Wedensday.... After some more searching I found no on-line vendor for this "Exactly what I wanted part"  So I went to MSC direct and figured out what I needed to order to do the job, probably not as well as the part I wanted, but I placed the order  at 4:59 pm.

Today I received a call back from the distributor at 1:15 pm saying the part was not in stock.
I got the parts from MSC delivered to my house (UPS ground from NV) at 1:57pm.

So here is a vendor with good marketing an a quality product that failed to make the sale.
Why?  They aren't stupid they know this process is killing them why no online ordering or stock check?

They are a successful company that was actually profitable and doing well before the internet.  100% of their revenue comes via distribution and if they open an online store they kill all their distributors and loose most of their existing business flow.   If they offer their product line through some existing on-line distributor they upset all of their existing customers. Its sad, but they are trapped.

In my day to day life I see a lot of these....

Its one of the things that's changing in the world,  it takes a lot less people to run a few centralized where houses set up to ship quickly than it does to have a real human at a distributor in every city.

Just this past weekend our dryer died, in years past this would have involved a drive down to the appliance parts store in Chula Vista on Monday morning..... This time I ordered a new dryer belt from amazon Saturday at 9PM and had it at 9:30am Monday morning.

The internet and automation is going to eat a lot more jobs before its done. Its not just automation replacing specific workers, its a new structure of doing business that is decimating a whole layer in the supply chain that used to employ millions of people.  May you live in interesting times...

Tuesday, June 09, 2015


One of the failings of silver ball was that I never got an accurate hardware in the loop simulator running.
On this project I'm not going to make the same error. 

After evaluating a number of possible solutions I've decided to use JSBSim  and I've secured the assistance of the 
Jon Berndt,  Development coordinator and chief architect for the JSBSIM, in getting that done. (I've made an arrangement where he will help me get started for a consulting fee, his time permitting)

One of my questions to him was:

>A details question.... I realize that JSBSim was built to be a flight simulator.
>I'm trying to repurpose it as a rocket simulator....

>Internally you seem to use ECEF coordinates.... I have not dug deep enough to figure out 
>if you model the inertial effects of a rotating earth...
>will one see a performance difference between an equatorial launch and aa polar launch?

>If I have a vehicle attached to the surface of the earth will it show the rotation rates of 0, or will it show the 
>the rotations rates one would see in an Earth centered inertial frame?

His answer greatly increased my confidence that I made the correct selection...
And, yes, JSBSim had a full overhaul of its EOM many years ago for full and complete EOM. It was the only non-NASA sim used in a large check case development effort that is published here:

The EOM integration takes place in ECI, full rotation effects are factored in and – yes – you would see the benefit from an equatorial launch compared to a higher-latitude launch. It is a full, vehicle simulator that can model anything from a rocket to a ball to a blimp to a sub/supersonic aircraft.

The vehicle sitting on the launch pad should show no Earth relative motion, but should show a translation and rotation relative to inertial. This was one aspect that was compared across NASA sims and JSBSim in the check case effort, and the comparison effort investigated tiny differences to make sure we were all on the same page and using the same Earth rotation rate. At this stage, I am very confident in JSBSim. That’s one nice thing about open source and broad use: the more people use it in different ways, the better the development effort goes, and the more robust the code becomes.

The simulator in general is designed to be data driven via external XML files. So one can model things like autopilot loops etc...I really want this to be a hardware in loop simulator so one of the modifications I'm asking Jon to help me put my c/c++ code into  the control loop. Eventually this will entail me taking the current state, simulating the IMU and GPS outputs feeding it into flight avionics and then taking the response from the flight avionics and giving it back to the sim to have it operate on the commanded changes.