Paul’s AVC postmortem….

In the end it did not go as well as I would have liked.  On 6 official attempts I only completed one lap.

I thought I was pretty close to ready; The car was following complex arced paths well…

This picture is from testing Wednesday The black and pink arcs are on top of one another.

The big change that enabled this precision was to add 200 msec of position prediction to the turn algorithm. IE star turning 200 msec early (200mse seems to be the command to actual steer servo is in new position latency)

As you can see the difference between the black actual path and "pinl desired path is insignificant.

In addition, with nice straight building walls the laser scanner was correctly finding the walls and correcting both the horizontal offset and accumulated heading errors against the walls.

When I left for Denver on Thursday I had three software bits unfinished….
I’d done testing and analysis on all three, but they were incomplete.
1)Obstacle avoidance.

2)Stop at the stop sign/pedestrian.

3)Hoop Location.

So Early Friday morning I wrote my  barrel  avoidance code and got to start testing on the actual course Thursday…. By 3PM I had my barrel code working the car was going through the barrel section mostly avoiding the barrels 5/6 times or so….The car was a bit too large and the barrels were a bit tight so I really needed to go slow and turn sharply. To make this happen I turned the steering gain way up for  any time the car was in barrel avoidance mode.

Here is a picture and video of the zigzag path through the barrels..


I then took some data to figure out how to detect the cross walk the pedestrian walked on and thus stop at the stop sign. In testing this chunk of code it worked one time in four or five and I worked on this code until 7:30 pm where I discovered my error…. I was using a static variable to indicate that I’d already done  the stop and to not do it again…So the code worked after a clean reset, but not a test restart…

Once I fixed that I was reliably stopping at the pedestrian..

I put every thing together and did a full run where everything worked.  Then the course closed at 8pm and I was done for the day. I had one issue remaining. The start line was too high it high centered the car, so I had to start behind the start line and get a running start and jump over the start line.
This basically added 50 to 70” to the path as the wheels spun.  I did a hack and added in 70” to the path in code.  I’ll test this in the 2 hours of testing Saturday morning…

Saturday Race Day #1, 

Its cold in Denver and I’m there when the course opens for practice and rather than use my 70” hack I manually record a new track path starting 24” behind the start and use that recording  to layout a new path.

I do a test run and the car crashes into the hay bales straight ahead…. And breacks the 3D printed bracket that held the LIDAR and electronics…  I brought spres of every 3D printed object on the car (6 parts) except the one bracket, because that was not on car #2, that was metal on car #1.
So with one hour and 15 till race start  I’ve got to get the 2^nd car ready, it was 100% complete except I had not wired the start switch  so I put both cars in the back of the retal SUV and drive back to the hotel… (about ¼ mi) When I get there I discover the back gate of the SUV had not closed and neither car was in the car.  I went back and found both cars lying in the road, otherwise undamaged.

I brought them back to the room  and wired in the start switch on car #2 (I’d planned to do that Saturday afternoon after day one was done. Rules were I ran one car on Sat, and a different one on Sunday.

I now have 15 min till practice is over and 30 min till my heat starts and  car #2 had not yet been turned on in Co. I run  the test and it impacts into the same hay bale that broke the previous  car. And I remember that my extra 70” hack was still in place, I remove it and get in one last run it gets tied up in the barrels, I’m not sure why this is not working….

Saturday Heat 1:
I’d planned to spend the morning fine tuning the path to center it up on the course and perfect it. Alas I spent the morning soldering switches and removing my 70” hack.  

Run one it gets a tiny bit hung up in barrels, but otherwise does the first half of the course, its supposed to go just inside the ramp, alas the lack of track tuning it hits the ramp/jump and goes off the edge of the ram, causing it to turn a bit and impact the hay bales on the other side. End of heat 1.

Saturday Testing between heat 1 and heat 2.

The car is now acting unreliable. IT runs sometimes, and other times it just wanders off course in random ways.  A couple of times when I try to gain manual control with the RC receiver it won’t steer….
In trouble shooting this power cycling always seems to fix this… I’m wondering if I have a hardware problem.  Out of 3 or so test runs one works, one is random and one gets hung up in the barrels…

The main CPU board on the car is a NANO54415, on this car was an old dusty first rev prototype board that I had used on many projects  So I figure there is no harm in swapping the board.
So I swap CPU boards for the spare in my electronics bag. I reprogram it with the car code, program in the course and  I’m out of testing time. Time for heat 2….

Saturday Heat 2:

I press the go button it immediately turns right into the wall and dies.

The system saves a bunch of configurable parameters in flash, one of these is use the magnetic compass, or just the bare gyro for navigation.  I’d found the bare gyro was more repeatable than the compass, but use compass defaulted to on…. So car turned right into the wall due to the compass…

Practice between heat 2 and 3 on Saturday…
This went reasonably well, I tuned the path a little bit.

Saturday Heat 3:
The car ran pretty much perfectly, it dodged the barrels well, missed the ramp, caught the hoop and almost stopped at the stop sign.  It was supposed to stop within 12” of the line, it stopped about 18” short, so while it stopped and missed the pedestrian it  it did not get the stop bonus.

This was the VERY first car to complete the entire cours at this years AVC!
One other car in a later heat also finished the course so only two cars finished on Saturday.

So I spend the afternnon bumming some aluminum angle from one of the people working oon the manned AVC car hack saw off a chunk, drill and tap add some strategic tye wraps and repair the broken bracket that died earlier this morning on Car #1.
In general the build and wireing quality of car #1 was better than Car #2 (I built #2 first) so I was feeling pretty good about Sunday and went out to dinner with my Wife and my Sister in laws. (One Sister in law flew out with us, and the other sister in law lives near Denver.).

Sunday Morning..

I woke up really early  Sunday (4am Denver time) with two things in my mind to accomplish, improve the barrel avoidance to give the car some more clearance so it does nto drag the sides, and add general purpose collision avoidance, so that it it some how looses its navigation position it will steer away from obstacles..

I code up both these changes   The course opens for testing at 8am, so I put a report screen together on the LIDAR avoidance and wander around the hallway of the hotel carrying the car and looking at how it sees and reports obstacles…it works reasonable well…. I take it out side and try it agains a wall in the parking lot, it works perfectly… even when command to steer into the wall at a 30 deg angle it will skim along just avoiding the wall. Its perfect…

Practice  Sunday morning…

On the first  run the  new barrel avoidance S/W is perfect. It doesn’t touch a barrel.
So I take a good manual course survey and set up to fine tune the route…
It starts to act really unreliable… runs some times, doesn’t run others…

Sunday heat one:
It makes a bad decision on how to go around the very first barrel and gets wedged between the
barrel and hay bale. In past times this would not have been an issue as it would push the
barrel aside a little bit and continue.   This run there is so much loose hay on the course that the car just spins its wheels on the loose hay.

So while other heats are running on the course I go out in the big empty parking lot and just run…

Something is very wrong its gotten really unreliable…

It stops  steering in manual mode even… so I unplug and re-plug the Steering servo and it comes back to life… for  about  30 seconds I do this about three times, and it comes back to life each time…
Then dies… On the last plug in I plug in the connector off by one pin and put 5V on a 3.3V pin and the  CPU  power supply dies…

I rush back to my work table reach into my spare bag pull out a new DEV board…
Oh no the boards on the Car’s have header pins soldered in for the connector, the spare had just holes, it won’t work…
So I disassemble the CPU dev board from Car #2 and put it on car #1.  I take my last spare CPU board from the useless dev board spare plug it in remount it . I also remove the steering servo from one car to the other… I’ve got both the steering servo and the dev board swapped and I have 15Min of testing before the heats start…

So lets take a break and talk about why I do this… I think its important that a company eat its own dog food. I’m doing all of this development on a new NetBurner branch  3.0 it will be our new multiplatform release, ColdFire, Arm etc… I’m using this new code to find bug and issues and improve the quality of our new release….this now bites me hard.

We changed the way that IP configuration and setup works to be all web based with no special tools. 95% of our testing has been on DHCP based LANS.  With a direct cable connection un-configured the system is supposed to use AutoIP to set up configuration. It has not been tested recently, and it no longer works…. I can’t talk to the board to download paths, or set parameters, because it has no IP address….. so I start hacking the system code to  force it to have a static IP address…

(In hind site I could have used the local IPV6 configured address and solved my problem, but I did not think about that at the time.) This takes me about 15 minutes to hack in a solution and get the board to boot with a static IP… (This bug will be fixed before release)  Now they are calling my heat I’m out of time… I program in the path, the config settings and run to the race track. The car has not even run 1 inch since I swapped the steer servo and the brains… I’m hoping the servo center is close enough that  the steer PID loop can correct….

Sunday Heat 2:

The run is almost perfect…
The car goes through the barrels and does not touch anything, it just misses the hoop by about 3 inches, but it detects the pedestrian, and does an absolutely perfect stop at the stoip sign, wiatsfor the path to be clear and continues…

It drives all the way around the course to the finish line and stops 3” too short.


It had been programmed to go about 3 ft past the finish line, alas with all the hay on the course it got 39” of wheel slip and was 3” short. If it had gone 4” farther it would have been the hi scoring run of the entire event.  This was just crushingly demoralizing…

Between heat 2 and heat 3. 
I extend the stop zone by 8 feet and do a practice run, its perfect…
I turn the speed up 50% and run it again, its perfect….
I park the car and spend the next hour packing up all my stuff into the SUV and getting ready to go home. I don’t touch the car….

With everything packed in the SUV, the only thing left to do is run the last heat and go home. Having not finished the first two heats I’m no longer in the running to place, I’m half tempted to head out before running the last heat. I stay.

Sunday Heat 3.
I press the go button the car accelerates hard about 30 ft and then just stops.
When I walk up the speed controller if flashing a red fault light, either it got to hot (its cool to the touch) or I ran the car battery down to much… (more likely) my AVC is done.

Final thoughts:
1)The car was too big for how tight the barrels were. The barrels were much tighter this AVC than previous AVC;s. I’d chose the chassis to be able to go insanely fast, I needed rugged more than speed, the lack of ground clearance and wide stance were both issues.  The Slick tires just don’t work well in straw. The car would be superior on smooth dry pavement, not so much on the AVC course.

2)When I turned the steer servo gain way up for the barrels I was driving the steer servo too hard and it was overheating and shutting down. A normal RC driver does not continuously drive the servo stop to stop hard, when it barrel following mode I was doing just that and the servo over temped and died.
Adding in the hyper sensitive obstacle avoidance only made this problem worse… as the car might change its steering direction mind significantly at 50Hz.

3)I was not really ready, I should  have had my spares more ready, had a spare for ALL 3D printed parts, had the wireing done on Car #2. Have tested the barrel mode enough to show the steering servo flaw etc….

Conclusion: 

Projects with a hard unmoving deadline are painful.

For general info:

How to evaluate a Launcher Startup.

This post started as a 7 tweet tweet book . Several people asked me to put it together in a way that can be permanently linked. This is the result.

I'm assuming there is a valid business case. The business concept with  cost estimates and identified customers etc... needs to work before any of this matters.  I assume that any business evaluation will include the business fundamentals. I personally believe that a low cost dedicated nanosat launcher makes business sense and I have personally worked on  such a business plan. I see a lot of launcher startups being funded so I must assume that others agree the business case might work.

What I see looking out at the world is a complete failure in technical evaluation of the various launcher startups.  I'm trying to provide a rough guide for technical evaluation of a launcher startup.

To state the obvious, the first goal of any launcher  company will be to get payloads into orbit,

that is the hard part of the business. Added services, responsiveness, cool features etc... are all irrelevant until you have a vehicle getting to orbit.

So what does it take to get to orbit and how does that differ from getting to space?

The official line of space is 100Km or 328K ft. In the scale of the earth a tiny distance.  Suborbital vehicles, like Space Ship 1, and Blue Origin's New Shepard are suborbital. They go to space, but they do not go into orbit. This may be useful as a tourist vehicle, and for limited scientific experiments, but its not really relevant if you are trying to build an orbital vehicle.

The potential energy necessary to get to space (straight up) is (approximately)

Pe=m*g*h

where m is mass, g is acceleration due to gravity and h is height. So for one kg  

1*9.81*100,000m = 981,000 nm of energy.

The minimum speed to be in orbit is around 7500 m/sec

Ke=0.5*m*v^2   

so for the same 1 Kg in orbit we add an additional

0.5*7500*7500=28,125,000N-m of energy.

So the total is ~ 29,106,000 NM or 29 times the energy of a suborbital vehicle.

So if a space company says we have gotten to space and we will be in orbit real soon now; realize it's like an airline company offering you a ride from San Francisco to New York City, yet the farthest their plane has ever flown is from SFO to Sacramento.

So what does it take to actually get to orbit:

1. Mass Fraction (Hard)
2. Motor performance (Hard)
3. Guidance (Medium Hard and getting easier)
4. Regulatory approval (Medium Hard)

Mass Fraction.

Mass fraction is the ratio of propellant mass to empty weight. For example a 2L coke bottle has a mass fraction of about 40.  I.e., the bottle full of coke weights 40 times what it weighs empty.

This is a good mental model for a rocket, the mass ration of the upgraded Falcon 9 is estimated to be 25:1.

Any orbital vehicle using chemical propulsion will look like a big tank.

So when evaluating a potential launcher company you need to ask what is the Mass Fraction of hardware you have on hand and can show me.  When evaluating this don't accept paper numbers, insist on knowing what the numbers are for the hardware on hand.

Motor Performance.

Rocket motors (assuming they work at all) have one major and two minor performance parameters.

• ISP. It's usually stated in seconds. IE a motor with an ISP of 300 will make 300lb sec of thrust for one lb of propellant.Orbital vehicles have had rocket motors varying in ISP from 220 (shuttle big solids) to 450 (high stress staged combustion Lox/H2 SSME) Lox RP1 motors are in the 300 to 330 range.
• Thrust to Weight: What is the ratio of motor weight to motor thrust. If the rocket motor is accounted for in the Mass Fraction of the overall vehicle, this is sort of irrelevant. Its also a bit hard to score as the value varies depending on where you draw the line between the rocket motor and the rest of the vehicle. The Main propellant valves for instance, do they belong to the tank or the Motor?
• Burn Duration: The rocket motor need to last long enough to get you to orbit. This is not really relevant to most liquids, but for small solids, it's really hard to increase this number due to the physics of solid propellant burning and insulation requirements.

I've marked this part of the four fundamentals as Hard.  I'd actually score the motor as Medium hard, but getting all the instrumentation and test together to optimize and really know what your motor is really doing pushes this into the hard category.  

Guidance

The rocket needs to go where you want it to go. You'll also have to convince the regulatory agencies that you really do have control of where it's going so it won't be a hazard. As computer simulations get better and better getting this part right gets easier. It's really easy to have the simulation right, and have errors in the vehicle where the actuator direction is backwards or the simulation inertia scale is wrong lbs/kg anyone?

So, does the rocket company have a plan to verify and reality check the hardware with the simulation without destroying the rocket?  I test flew my hovering rockets under a forklift so I could discover guidance errors without destroying the vehicle. The difference between this video and this video is the sign of a single term in the guidance equations.

Regulatory

If you're in the U.S. you are going to have to get FAA permission to launch your vehicle.

Where you launch from and how you mitigate risk to the general public are a big part of this process.

It's not really that hard, it just must be planned for in the development of the vehicle. It's not something you can just "Stick OK" a completed vehicle if you have given zero thought to things like ranges, range safety and EC (expected casualty)  The FAA is going to care about what the rocket parts can hit if things do not go to plan. That's why I've always given very little credence to inland spaceports like the one in NM or Odessa as a place for orbital launches. If you launch from NM you're going to stage somewhere over the densely populated parts of Tx. Short of a planet wide emergency,  like in Seveneves, it's never going to be allowed.

Putting it all together with the rocket equation

The rocket equation   

Delta V= ln(MI/MF)*ISP*g

MI initial stage mass, ie the weight of everything....including upper stages and propellant

MF final stage mass ie the weight of everything minus all the burned propellant.

ISP the Motor ISP number. (Not really a fixed number improves with altitude)

g 9.81 m/sec acceleration due to gravity.....

Calculate this Delta V for each stage in the vehicle.

The Mass of the fully fueled stages above the one you are calculating Dv for must be included in both the initial and final weights.

Once you have calculated ALL of the stage Dv and added them up, if the number is > 9000m/sec then you have a chance at getting to orbit. This number will vary somewhat with the vehicle acceleration profile and size. I personally like this paper "How Small can a launch vehicle be" for evaluating concepts as a first order check.

If the number is not yet to 9000m/sec and the plan to fix mass fraction and ISP to get to 9000m/sec is not the number one issue for EVERY technical person working on the vehicle, I would be doubtful they will succeed.

The Team

Building a new Rocket is an exercise in creativity. There is not a formula that given inputs generates a rocket. Unless the engineering team shows the ability to design, build, evaluate, and repeat in a creative way, nothing else is going to matter. Building hardware is different than building software, rockets are hardware. When you talk to the CTO/Chief engineer/Chief Wizard without notes can he tell you what his mass fractions, ISP and current achieved weight vs planned weight numbers are?

If he can't then who in his organization can? If no one can, then they are not going to succeed.

Walk through the shop and engineering, do you see a scale?  Does every engineer building a piece part know what his weight budget is and if he's going to make the weight budget?

Before XCOR failed, I personally thought about investing in their company several times, every time I got a tour of their facility, I was turned off by the complete lack of weight control. The half finished linx had many parts that look like they belonged on a truck, not a space craft. The complete lack of detailed weight control on all the minor parts spelled failure to me and I never invested for just this reason.

Eventually the team will need to learn operations, and as it grows it will need HR, middle management and all the other parts of a company. But unless it gets the creative engineering part right up front it's going to run out of $$ long before any of these things matter.

To quote from my tweet storm:

• Pretty Paint does not matter.
• Fancy Building does not matter.
• Previous Dinospace experience does not matter.
• Cool animations of a paper rocket do not matter.
• Until they have hardware that can do 9000m/sec DV, operational issues don't matter.

Why doesn't previous dinospace experience matter? Because other than SpaceX, all of the other launch providers had their creative how do we do the base design done in the 60's and 70's. The creative steely eyed missile men that made that fabulous leap to the moon and beyond are no longer part of the current dinospace environment. It's a very different thing to manage and evolve an existing system than it is to create a new one from scratch.

Please feel free to comment on errors or omissions or areas that need clarification in this post. I will try to correct, enhance and improve over the coming few weeks.

Slides from Space Access.. 2016

Here is a link to my Space Access 2016 slides..

https://www.dropbox.com/s/y13kzn5fi6omeen/SA2016.ppt?dl=0

Some pictures if you don't want to mess with PPT...

An interesting EMC tale..

I spent much of the last week doing EMC testing on a new NetBurner module, for FCC and CE qualification.  The basic process is you take a unit to the test lab and they do various emissions and immunity tests.  This happens with basically every electronic product you ever purchase.

This week we had an odd result that is worth of a write up...
Most EMC tests start with emissions testing as that is the most often failed part so get that done first.

One of the tests in the middle is Radiated Immunity...
For normal consumer products they put the unit in an RF field of about 3V per meter and sweep the frequency.  This test is done in a 3M RF chamber and in the place we test this is split into 16 parts....

Front, back,right, left  in each of vertical and horizontal polarity with two sweeps one up to 1Ghz and one from 1 Ghz to 2.7Ghz.   Your unit is supposed to remain operational during the test...
So for this new unit a Wifi /Ethernet to serial unit we put a loop back cable between the serial connections and do an ethernet ping and tcp over wifi loop back through the serial connection.
We monitor that data goes out and back and is reliable.  Running 2.4Ghz wifi we expect some packet loss when they sweep through 2.4Ghz, but the unit should recover.


The first 8 tests under 1Ghz were uneventful....
For over 1Ghz they swap out the drive antenna for a wide band horn and different amplifier.
The first 4 tests, left, right x horizontal,vertical all went well.

Then we started doing the front and back of the unit and the Wifi in the unit started acting flakey. It would loose the wifi connection and nothing I could do would make it come back. This was with the  chamber open and the signal turned off.  It seemed like physically moving the unit caused it to die.
I got through one more set, the back, leaving just the front of the unit to test and I just could not get it to work ,,,, So I aborted the testing on Tuesday and drove back to the office from the test lab in orange county.
Since moving the unit caused it to die I assumed a bad solder joint.
When I got back to the office I re-flowed the wifi module and and retested wifh while violently shaking the unit.  It worked flawlessly...

So I went back to the lab on Wednesday, EFT, surge, ESD, conducted immunity etc...
Everything worked flawlessly for the next two days. The WIFI was really solid....

This afternoon we had one test left >1Ghz radiated immunity to the front, horizontal and vertical...

The unit fired right up and worked flawlessly....
We finished the horizontal test, the drive was off no signal...
The test technician went into the chamber and rotated the drive horn from Horizontal to Vertical...
WIFI died. I rebooted the unit and nothing I did could make wifi work...
So I asked them to turn off their amplifier.... and the wifi  came back to life...
(This is with the drive to the AMP turned off)  Amp on wifi dead, amp off wifi works....

We then rotated the drive antenna back to horizontal and turned the amp on...
Wifi worked.... we rotated the  feed horn wifi died...

The strange part is when the tests were actually running IE they were driving RF energy in to the AMP and out the antenna at our unit WIFI worked flawlessly. It only died when the test set was idle.

The WIFI antenna on our unit could be rotated to vertical or horizontal, so as long as that antenna was  of opposite polarity to the test antenna everything worked....

What is even stranger is we could be dead and idle and turn on the test IE drive energy and things worked....

So we did the last test with the WIFI antenna horizontal..

The whole time our unit could scan for the WIFI router and recieve fine, when it tried to transmit things died...
So what is going on?  The only theory I have is that our WIFI signal was coupling into the amplifier and causing some king of feedback, ie like Microphone squeal...

The guys running the EMC lab have been doing this for 30 years and they have never seen anything like it... It was a strange Day...

Accelerated GPS musings....

GPS L1 is at 1575.42 Mhz.

The normal GPS CA code chip period is  1msec.

Most GPS systems integrate for one or more whole Chip intervals dump the results and repeat.

The hardware typically has a numerical controlled oscillator (NCO) that represents the satellite frequency that is integrated over this time.

So if we integrate a 1575.42 Mhz signal for 1 msec, how far off can our frequency be before our
phase error is 180 degrees at the end of 1 msec?  its about 500hz....
(Which is why the tong or FTP search bins for finding the inital GPS are at 250Hz or so.)

Most tracking implementations have single value of Frequency driving the NCO....
If you want things to work well then your phase error over one period should be less than 45 degrees... (where Tan is linear)  so that is a frequency error of about ~125Hz or a Velocity error of
12 m/sec.   So for 1 msec of Acceleration that is a  1200 G, so it should be

Flight of 12 19 15

Some background on GPS.... this post is chronologically challenged as it flips back and forth)

I have three approaches to getting the GPS to work.
They are somewhat related.....

1)Use a Swift navigation PIKSI with custom firmware.
I've flown this unit with stock firmware twice, and with custom firmware once.
Flight 1 Stock firmware, lost lock at ~5 gee, marginal GPS in all cases.
Flight 2 Custom firmware with wide open GPS tracking loops... over did it as the units were tracking sats that were not there.....
Flight 3a) (12/19/15)
Newer version of Stock firmware GPS performance much improved, still lost lock at 6 gee, but recovered at burnout...
flight 3b)Same flight different piksi hooked up to intel compute stick to log RAW signals from the front end.

2)Use a RTL SDR dongle with GNSS-SDR and write custom firmware..
Thanks to some help from a follower/friend I have this runnign on the ground with my survey grade 35DB trimble antenna, but not with the flight weight antennas, I'm waingin for some low nosie amps to make this work wiht the flight weight antennas.


3)Build my own GPS with full IMU tight integration.
This will use the same Maxim GPS front end as Piksi, but with the Zynq CPU.
I have all the prototype pieces in work....

After action...

Thursday, Friday and Saturday I had a bad sore throat and cold.
On Thursday I determined that the RTL-SDR was not going to work without the LNA I did not have.
So I switched to trying to record the raw signals from the piksi...
After napping much of the day Friday to get better I finished the Piksi raw record  about midnight Friday.

Saturday I got up at 4:45 rechecked that everything was working, packed all the stuff into the car and drove to the airport.  I took off about 7am in the 182 Headed to FAR , I landed on the private dirt road next to FAR at about 8:15.

Started prepping the HPR for the flight using one of John Newmans ~M experimental motors.
one of the Altimeters failed the deployment charge conductivity test, took me about 2 hours to find the broken wire down inside the avionics module.  Launched the rocket at 11:07:26  It went to ~12K ft. The GPS experiments and batteries added a lot of weight to the nose cone and I did not upgrade the main chute retention nylon bolts. So when the drouge deployed at appogee the main also deployed.   After driving around in  the desert on the quad for an hour gave up looking for the rocket and switched to the airplane.... it took us about 5 min in the 182 to find the rocket. It was 4 miles from launch and withing 25 ft of a paved road.  So we landed back at FAR and Ted took me to get the rocket in his jeep.  Kind of fun to ride in a really capable off road vehicle...  The rocket barely fit in the jeep and on the way back to far we jumped over a rock pile the rocket came loose and broke Ted's window ;-(  When people try to budget projects like this and understand costs no one puts things like Jeep windows in the budget.....

Once back at FAR I took the GPS modules out of the nose cone, I  packed up and flew to Oceanside...(OKB) The flying club I'm part of had its Christmas party Saturday afternoon and I had promised I'd give breezy rides, so I left the 182 at OKB and took the Breezy to CRQ... it was too cold and I had no breezy ride takers.... so I took the breezy back to
OKB put it away and flew the 182 back to CRQ unpacked and drove home.  I got home about 6 pm and went to bed early. It was a long day...

Saturday I downloaded the data from the GPS modules.  The SBP format file  from the first Piksi is here: SBP format Datafile The SBP format is defined here https://github.com/swift-nav/libsbp/blob/master/docs/sbp.pdf

Decoding that the Piksi with the current stock firmware lost lock at about 6 gee and regained lock at burn out.

The second piksi was recording raw RF from the front end via the intel compute stick... from time to time it had a FPGA fifo error and the sampler would restart.... inside this zip file are a bunch of raw data files.  The file ending in 110731 has the first 4 seconds of flight. The File 110822 has the balance of the boost phase.  

These dat files are supposed to run in the swift nav peregrine software GPS receiver, alas my linux fu is not working and I'm unable to get peregrine working as it looks like swift has moved its library python bindings from a separate module into the libswiftnav, alas that integrated version python will not build on my VM....
If anyone wants to play with this you can find info on peregrine here: Peregrine

That's all for now. I'll update when I manage to get some info from the raw data.

After Action report...

So this was  a FAR weekend.
I had intended to do three tests, only got one done.

I fired the 3D printed motor with larger diameter plumbing on the main valve and a turbine flow meter so I can measure C* and ISP.

Results are mixed....
The test stand I'm using is an amalgamation of an old test stand and a bunch of valves from the silver ball.  In short it is a mess. I worked on making it better this week. (largely why I only got one of my tests done)  We hydroed the basic structure and tested the relief valve a few weeks ago, and all of that is solid.  The new valves and arrangements form the main outlet to the motor are solid.

The valves for the fuel side and the pressurization system are 100% Silver ball leftovers.
They largely worked two weeks ago when we ran it, this weekend two of the fuel side valves were frozen and the actuators died.  I had one spare actuator with me so I replaced the fuel valve actuator and changed the fuel side vent to manual operations.

The 2nd deficiency of the system is that all the wiring is an unreliable mess. I hope to clean that up repackage the electronics and make it all a solid solution before I use the stand again.
I  left the test stand at FAR but brought all the valves and sensors home.
The actuators are all dynamixel RX-64, 18V actuators  run off a 5 cell lipo and an ac power supply to keep things topped up.  I have a nice 40V  13.8V AC powered supply, thinking about trading the RX-64 for MX-64 that would be happy running at 13.8V. This is a $1K decision, I need to sleep on that.

My old sureflow pump for loading oxidizer died this year. I bought an air powered diaphram pump from McMaster car to replace it as the model of sureflow pump is not longer made.

The problem with this pump is that is really pulses, the flow is not smooth so hoses jump around and do unpredictable things.  I mounted the pump to a 3 hp roll around aircompressor and added a remote dead man switch activated valve to turn the pump on/off.  I also changed the loading procedure form opening the top of the tank to having a separate valve and a hard connection on the bottom for fueling, no ladders involved. These changes mostly worked as designed and I'm happy with them. much less risk drama in oxidizer loading.  I need to do something similar for the fuel side and will do so.  I still have hope that I can find a good steady electric self priming oxidizer pump..... I've ordered a couple of candidates, we will see how they turn out.

The firing ran well about 78 seconds. The CAT pack worked well and I got good data. The feed pressure was up about 20 psi from last time, the chamber pressure was up about 10, not sure where the other 10psi went.... motor ran at about 180 PSI target is 200. On shutdown the fuel feed pressure stayed up witht he fuel valve closed.  So I suspect that rebuilding the fuel side of the system in the mojave dust introduced enough material to clog the fuel orfices.  I've ordered a small sintered 10 micron fuel filter to add to the system.  Well see when I examine the engine this week....

I forgot to do a final last minute tightness check on all the plumbing. Got distracted by a rocket launch that required everyone under cover and for got to tighten one pressure transducer... sprayed peroxide all over everything...this part was after the main valve so was not part of the pre-fill leak check.

Then wheil disassembling things I dumped fuel all over the open ox inlet port on the motor.

So before I run it again it needs to come apart and be properly lcleaned for oxidizer service.

Things to do before next test:

Rebuild and test all the valves and actuators.

Package the electronics in a more robust manner.

Add flow meter to the fuel side.

I'll probably run another motor test the first FAR event of January that should be Jan 2nd

For the Far event on the 19th of December I'm going to try and fly my GPS experiment and test the little TJ-20A turbine as a potential first stage motor.  

I'll try and post some of the test data when I have looked at it later this week.

Paul

Working on full layout

Looking at various possible layouts for the bottom of the Third Stage.

(IE the one where weight really matters....)

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.

The big chunks...

Trying to do a minimalist amateur sputnik....
We need to build a vehicle light enough with a good enough performance to get to orbit.
We need to make sure we can make it go in the desired direction.
We need to involve the regulatory agency so we can do this legally.

How do these three base requirments break out into bigger tasks...

0)Conceptual Design...
Done:
 Spread sheet and simple performance model says 4" diameter 16" long OTRAG tube rocket can get to orbit.


1)High mass ratio Air frame...
Done:

• I have tested representative tanks with the required  mass ratio.

In process:

• I have one full size sample, I still have to test that.

To do:

• Finish Detail design of Full Airframe.
• Static test one full tube with fill drain, gimbal etc...
• Build Cluster.

2)Motors...
Done:

• Designed Motor and had it 3D printed in Aluminum.

In Process:

•   Finishing hte machined parts to go with the motor, adding cat pack and instrumentaion
•   Using old Test Stand from 2011

To Do:

•  Test Motor and refine design, iterate
• Design and test high expansion ration version.

3)Good high quality vehicle simulation for performance optimization and HIL testing.

Done:

 Selected Simulator (JBS Sim) and contracted to have a good initial model built.

In Process:

    Waiting initial model and simulation form person contracted to do the work

To Do:

   Optimize and evolve to full HIL simulator...

4)Build and Code Avionics:

Done:

 Pick an archetecture (I think 75% confidence) we will use one of the tiny  pixhawk  clones for avionics.

In Process:

  Find a light weight GPS that will work without co-com limits at high acceleration.

 We have flown Piksi on a HPR twice continue to work on that aspect.

To Do:

   Design the full code set and test in HIL

 

5)Build and test GSE..

Done:

 Conceptual GSE concept that minimizes weight on the airframe.

Uses single "Tube" to fill and pressurize remotely.

InProcess:

ToDo:

 Design airframe QD and ground GSE.

Test Concepts via static tests...

6)Regulatory:

Done Regulatory concept...

• Will do inital testing at FAR up to 50Kft.
• Then will do suborbital flights offshore.
• When time to go over 200K lb/sec or to orbit:
•      First stage constrained by physics from hitting anything.
•      2,3,4th stages made of low temperature tolerant composites, so incapable of high speed flight in the atmosphere.

In Process:

To Do:

    Start discussion with FAA for orbital licensing requirements.

Today's progress...

Spent the first half of the day cleaning the shop.... I have way too much stuff.

Then I machined the soft jaws of the three jaw chuck to grip the end of the 3D printed motors...

Then machined

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

If you follow such things the Jet pack from http://jetpackaviation.com/  was subject to all geek discussion last week. Today I say an article here:http://www.gizmag.com/jetpack-aviation-new-york-flight/40286/

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?

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

Useful:
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.
(See http://www.pbsvb.com/customer-industries/aerospace/aircraft-engines/tj-100-turbojet-engine)

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.

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...
(http://www.vectron.com/products/g_sensitivity/gsensitivity_index.htm)

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!

Progress...

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....

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.

.

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...