Random misc stuff...

Lots of little things....

It looks like the Fuel in 20Kg lots is about 50% lower cost.
If one eventually gets to ton quantities then its down to 18% of the present cost.
So all of that is good news....

I've been thinking that I was going to have to manufacturer my own quick disconnects.
Everything I'd found was either too big, to heavy or to expensive.. (often all three)

After a help me beg on Arocket a friend pointed me at some things on E-bay that eventually led me to these...

They are Aluminum, with viton and stainless internals. Off the shelf and not too expensive. The Really cool part is the rocket side is only 49gm!

They are available from multiple places look for FBM3314 and FBM1153. The only way they could possible be better is if they were AN fittings rather than pipe, and availible in multiple sizes. (For all of you that don't do high pressure plumbing, please realize pipe threads are horrible.)

In Pauls  pantheon of pliumbing....

• Last choice is pipe thread.
• AN flare fittings are ok to pretty good. Probably not good enough for directly hazardous materials near people. 
• Swageloc are good, but both pricey and heavy.
• The Big boys use stainless and all orbital welded connections...

That's it for Today....

Two chemists walk into a bar, the first one says I'll have H20, the second one says I'll have H2O too... he dies....

Anyone that has followed my rocketry stuff for awhile knows I like H2O2.
(See comments on H2O2 at the very end of this post)
Both  Beal and the British Black Arrow group did some really cool stuff with H2O2.

So I've been thinking about engine cycles....

A:Regen Cat Pack 

 is what I have been running for the past few years. H2O2 comes in cools the engine, goes through a CAT pack and then ignites the fuel injected below the cat pack.
This works reasonably well, it has the following drawbacks...
1)CAT pack limits the H2O2 concentration to about 85%.
2)The CAT pack has a lot of pressure drop.
3)Cat Packs wear out or get contaminated.
4)They are some what expensive (Pure or plated silver screens)

B normal chamber with hypergol (or not)fuel.

I've been given some evidence of an available decent performance hypergol for H2O2.

I've not tested it or fired it personally. (Hypergol means fuel and oxidizer light on contact)
Its basically a traditional regen rocket motor. It needs a traditional injector, so not sure if I'll build a pintile(My fireing) , or a shower head (my fireing)` I've build and fired both with Lox Alcohol before I switched to H2O2.

This allows one to run to 100% H2O2 and to reduce the pressure drop.

The primary drawback is the fuel in small quantities from a chemical supplier is about $425 a liter.
The O:F is 4.9 so  the fuel for a full Class 2 burn is about $1300  For a full Class 3 burn that is 27K, its starting to hurt.... The H2O2 for the same class 3 burn is  $4500 so not totally out of the ballpark..

There has been an experiment that I've wanted to run for a very long time. I've wanted to try and run a wet, no catpack H2O2 engine. I've always wondered how to get it lit.  I think that at some point In testing I'll set up to use the Expensive Hypergol to light the motor, much like TEA/TEB is used in Lox RP engines and see if it continues to run well once the hypergol slug is gone.

C Odd choices....

There is some literature in the world talking about H2O2 gas generators with partial pre-decomposition and thermal decomposition of the full flow. This is the schematic of what I Imagine this might look like....  The H2O2 combines with a small amount of the hypergol to get warm, but not enough to "Burn" all the oxidizer....(This could also be part of the H2O2 flow goes through a cat pack to get hot)  This then enters into a stack of inconel screens, sort of like a cat pack, but not chemically active, its just a place to warm up and cause thermal decomposition...

Before thinking about the hypergol I'd planned to run this test with a silver cat pack and 100% peroxide, the silver cat pack would quickly melt and die, but probably not before getting the inconel screens hot enough to do thermal decomposition.... It seems the screens to do decomposition must get to and maintain at least 600C.

The big drawback to all the thermal decomposition schemes is that hot H2O2 vapor can detonate if it does not decompose.

Why am I posting all this stuff to the blog...

• One of the primary goals for Unreasonable Rocket , from the very beginning is to excite people to try and do cool rocketry things themselves. It does not take NASA levels of $$.
• I'm pretty much doing this project by myself in my Garage and at FAR. Last time I did this my Son was helping me, now I'm doing it solo. So using this as a portal to interact with people and maybe inspire people to help with the project is part of the blogging. 
• Trying to establish a habit of keeping the world up to date, I've set up a Patreon account (I've not turned it on yet) and when I do my first firing in this development cycle and have cool video to share I'm going to turn it on.  (If you think I should activate it now say so...)
  
  If you want notification of new posts here, I will be announcing them on twitter. I'm @unrocket

*Comments on H2O2 aka hydrogen peroxide.

The hydrogen peroxide that sits in your medicine cabinet and that you put on your cuts is 3 to 5%. Meaning its 5% H2O2 and 95% water, The H2O2 were talking about here is at least 85%.

This high strength peroxide decomposes exo-thermally to steam and hot oxygen.
Any concentration above 72% has enough energy to full vaporize the water content and is thus a hazard as it can make lots of hot gas quickly.

This decomposition needs some thing to induce it, heat, or a catalyst chemical.

• Thermal decomposition.
• Metal reusable catalysts (silver, platinum)
• Consumable Catalysts like the permanganates, etc...

With 85% you can run it through a silver catalyst (CAT Pack) for a very long time.
At 90% long term use will melt /degrade silver. Above 90% Silver does not last very long at all as the decomposing H2O2 melts it away, 98,99 or 100% has a more energy and higher performance as a rocket oxidizer.

Starting with the basics...
What is the tank layout?

For control authority you really want the center of gravity (CG) as far forward as possible.

So I sketched up the 5 tank layouts shown above...
I fully accounted for the weights and moments for all the fittings down tubes, up tubes etc...
for the full rocket...I estimated engine and gimbal weights base don stuff I've already fired...

I wrote a C++ program where I could instantiate parts, add them to the rocket, then run the tank to depletion and  calculate the CG....

I modeled #1, #4 and #5  #1 has the farthest forward CG, but was heaviest. If I ballast #4 by adding nose weight until it matches #1 then the CG is farther forward with #4 at the same weight at the extremes of  the flight. 

#1 goes from  152 to 255 cm from the front.
#4 ballasted to the same weight goes from  233 to 251 cm.
Its much simpler to build and the nose ballast can become more recovery gear bigger batteries, better telemetry etc...

As an added benefit #4 is much simpler to build and cleaner aerodynamically with no external feed tubes. I could do #4 with internal feed tubes, but then all the bulkheads become 5 axis machining projects, where for #4 they are all basic lathe parts.


I've simulated this rocket 3 ways...
My own written from scratch  simulator in C/C++.
Using RAS Aero II
Using OpenRocket...


All of the results agree and all say I have enough margin to cross the von-carmen line with a class 2 rocket... It will be interesting to see if  I can build it as light as I think I can.

That's all for now...

All the things.....
A stream of thoughts on the task at hand...

Starting at the front of the vehicle....


In front of the vehicle, aka airspace...

To start with FAR has a standing waiver for all class 2 rockets to at least 50Kft.

Once its time to exceed that altitude I strongly suspect that waivers requested from the FAA
with only the required class 2 information will be rejected as this vehicle will have performance capabilities that exceed what was envisioned for class 2. The next launch location after FAR will depend heavily on what the FAA is going to want for a waiver.
Possible locations: Black Rock, Space port in NM, offshore either in the pacific or in the gulf.


The nose cone
Before I shut down this effort last time, I made some 4" nose cone patterns and John Newman made some molds. So he has all the tooling to make a nice light mixed glass/carbon  nose cone for this.
The nose cone has dual requirements, it needs to handle the peak impact temperature and also be radio transparent for GPS and telemetry.

The primary electronics GNC board.
NetBurner is about to release a new module based on the Microchip arm Cortex M7. I will repackage the core electronics from our new module into a GNC/autopilot.   Basic features will be:

• Cortex M7 cpu with hardware floating point.
• GPS, will use Ublox until we exceed the ITAR limits.After the ITAR limits become a problem I may switch to the SDR GPS I've test flown, or one of several other GPS solutions I've got working beyond ITAR on the GPS simulator.(I have a LabSat GNSS simulator)
• Integrated IMU 
• Barometer
• Pyro drive electronics.
• Telemetry Radio (Probably an xbee socket)
• LIN communications channel.
• CAN communications channel.
• I2C communications channel to talk to :Digikey 223-1507-5-ND pressure sensor.
• SDIO/SPI interface to SD card interface.

Black Box

A package containing a micro SD card in foam inside some kind of crush resistant vault.
I expect the Telemetry data to be limited and this will be the primary "Product" from the flights.

Recovery Tracking:
The simplistic solution is to add a simple beeper transmitter....
The more complex solution is to use telemetry...(Probably means putting a 2nd tiny GPS on back side of nose cone so it can receive positions on the way down).

Camera
For flights with recovery I'll use a gopro session.
For flights where recovery is not expected I'll use  a 70 cm ATV TX and a atenna with gain on the ground. To simplify things, telemetry may be on the ATV audio channel.


Recovery:This vehicle is lighter when depleted that the HPR I tested all the GPS modules on.
For FAR area flights where I'm altitude limited and well withing the atmosphere I'll include the HPR recovery system I've used reliably.  This system weighs as much as the rest of the vehicle, so its not a choice for high altitude flights.

For high altitude flights I'll probably just eject  the nose cone at altitude  with a simple kevlar strap/streamer to orient the nose cone. Basically no recovery.

TanksThe notional OTRAG vehicle uses the carbon tanks that John Newman and I developed three years ago. That tanks uses a carbon sleeve with a poly bag liner and machined aluminum oring sealed end caps.   This vehicle will use 0.035 wall 6061 T6 4" tube.
I've ordered 24 ft of this tube (arrives on 11/6)
The only thing remaining to decide here is tanks closure. I have two competing concepts....
This will be the very firts hardware I build and hydro test...
In the next month I'm going to make a few 12" long tank sections to evaluate weight and closure...

Machined domes with oring groves retained by a collar screwed or flush riveted in behind the dome.

Hydro formed domes welded into the tank ends. This will probably not work as it weakens the underlying material too much, and its very hard to heat treat thin wall tanks.

Hydro formed domes welded into a collar that slips into the tank end and is itself welded to the tank.
This would involve building a heat sink that clamps on the aluminum tube trying to minimize the heat effected zone. The length of the collar would be whatever is necessary to move the weld beyond the HAZ. On a pressurized tubular tank the lengthwise stress is half the maximum stress in the other direction.   So if you can move the HAZ to the point it only effects lengthwise stress its a win.

Mid Tank Coupler.
The mid tank coupler is going to be a some what complicated piece, it will have the roll control nozzles and solenoids built in. It will also structurally join the propellant tanks to the blow down tank on the bottom of the vehicle.   The module will have its own local electronics with rate sensor and solenoid drivers. It will communicate with the primary controller on  the single LIN backbone.
Its possible that it might also be the fill and drain interface for everything.


Main propellant Valves.
Three choices here:
OTS aluminum ball valves with external drop off actuators.
This has the possible benefit that one could mount a monprop engine and do hovering stability tests under the fork lift.

Some version of my Spectra melted string actuators.

Some version of  a pyro valve.

Pyro or spectra shut off valve.


Gimbals and TVC actuators.I have a design for a gimbal with built in fluid channels. This is an intricate little piece 3D printed and post machined. All in all its probably 40 hours of fabrication, each....
Its light, compact and easy to gimbal.

The alternative is a simple rod end bearing assembly like the LLC vehicle used with flexible hoses.  This is easy to fab, but I'm concerned about its impact on the size/wt of the gimbal actuators
and actuator batteries. Pressurized flexible hoses are stiff and require strong actuators.

For actuators I'm going to use OTS brushless servos.


Rear End electronics:
Another custom electronics board.
CPU
Two axis rate sensors.
Actuator driver logic. (Probably servo or RS-485)
Pyro drive channels (at least 2)
LIN communication channel.
System simulation will determine if LIN is fast enough to communicate from main GNC to the TVC actuators, it the TVC actuators have local rate sensing. It this is too slow then inter module comm will be upgraded to CAN.

Thrust Chamber
The final thrust chamber here will be smaller and lighter than the 3D printed aluminum chambers I was testing when I stopped rockets 3 years ago.  The will otherwise be very similar to the previous efforts.  I may build a cat packed   based mono prop chamber to allow tethered hover testing of the GNC without risking the vehcile


Rear Fill and Drain
The  full OTRAG would require rear access fill and drain.
For the single tube test article mid point or top side fill and drain might be advantagous from a getting the weight forward stability stand point.


Batteries
The current plan is to have multiple batteries local to each of the the electronics bay, forward/nose cone(GNC And telemetry), mid bay (Roll control) , rear (Main Valves and TVC).
It may prove to be lighter to have a single battery and power distribution, but getting power from the front to the back in an aerodynamically clean way may be more weight than individual batteries.

Ground support equipment:The necessary transfer tanks, pumps, valves, regulators etc,,,,, to fill drain and pressurize remotely.

Tracking telemetry antenna.

Spar buoy to support offshore launches.

Simulation System...
I'd planned on using JSB sim when I had other people helping me with things...
I'm currently trying to get that environment running in a way that is useful to me...
BTW Did I ever tell you I hate XML.

That's enough for one day...


A list of random TLA's I might have used...

CAN -Controller area network,  initially developed for automotive communications
GNC - Guidance and navigation control, aka where are we pointing.
HAZ - Heat affected zone, ie a welding term
IMU - Inertial measurement unit
ITAR-International Trade in Arms Regulations aka don't sell ballistic missiles to bad guys.
LIN - Local interconnect Network. A single wire asynchronous communications protocol.
LLC- Lunar lander challenge aka the contest that started Unreasonable Rocket.
OTS- Off the Shelf,ie purchased and unmodified.
SDR- Software defined Radio
TVC- Thrust vector control.
TLA Three letter acronym.

Once more unto the breach....

I posted this to Arocket and got some questions, so I've modified this text to answer some of the questions and add additional details.

The next unreasonable year...

I'm personally at a point where I can take some time off and play with rockets again.

I don't think I can afford to do my full otrag-lite program, but I can do the next step.

So starting in the January time frame I'm going to be working at least 1./2 time on building a 

single tube demonstrator of  my otrag-lite concept.

Some changes from the base design:

Use off the shelf 6061 thin wall 4" al tube for primary tank age rather than the super light carbon tanks I developed. If I get reliable dynamic performance and recovery I might try a carbon tank at the end of the year.

The rocket is going to be 90% H2O2 with hypergolic fuel.

I've agreed to not talk about the fuel in return for being able to use it, so don't ask.

Suffice it that I've seen test data that shows it working in a test environment and RPA modeling of the propellant combination shows  good isp. Overall propellant density is 1.25. Toxcitiy is more benign than gasoline (what I had been using)

Vehicle will be blow down.

For stability reasons the tank-age will be divided in half with pressureant  below the propellant tanks.

Every possible means will be made to make it make it light weight.

IMHO the most important tool in building a high performance rocket is a precision scale.

I'm either going to do externally operated valves or pyro valves still working on that.

Vehicle will be at the class 2 limit with really long burn times, lift off thrust to weight on the order of 1.2, with burn times ~180 second`s. actively stabilized and finless.

The first version of roll control will be cold gas thrusters between the pressurization tank and the propellant tank. most likely a 3d printed Aluminum assembly. If that uses too much gas, then the next solutions tried would be some really tiny fins at the trailing edge of the vehicle and some "Blades" that deflect into the rocket nozzle.

Each area with valves and actuators will have local power and control with the coordination being either a single LIN wire or some form of short range wireless.
I believe a single layer of thin copper foil on top of a capton tape for a lin communication channel is probably lightest and lower drag than 3 or four small antennas. My big question here is if the copper tape will stretch as the rocket pressurizes.

Telemetry will be through a fiberglass patch on the nose cone.

The vehicle should be able to cross the 100 km line.

Recovery will be a balute or reinforceed balloon whose sole purpose is to prevent supersonic reentry. I expect the vehicle to be mostly destroyed on each flight. I Might separate the nose cone with camera and data log on its own very small parachute.

At this point I've secured the long lead items for the project  and I'm cleaning up my shop in preparation.

In the process of developing the design work based on previous efforts and will probably reopen this blog and start showing designs and hardware around the first of the year.

I'll do the initial testing at FAR until I have issues with their altitude limit. 

Then I will probably be looking to launch offshore.

My stretch goal is to bring evidence of flown hardware to Space Access this year.

CAD/CAM  The right tool is probably fusion 360, I tried using it for some projects it about three years ago and it was unusable on a 4K monitor. In the last few days I've updated it and it seems much better. My personal tool of choice is Rhino, as I'm really familiar with it , but I'll probably to use Fusion 360 as much as possible.

Paul

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