(But it requires a high tank pressure compared to Armadillo and Unreasonable and can’t be throttled as far down as Armadillo’s design. Building solid tanks is evidently harder than one should think, judging from yours and Unreasonable’s experience — and some of Armadillo’s early experience. James Bauer put his tank welding guide up on their site, though, so if nothing else, one should be able to learn from that.)

The engines require higher tank pressure because we chose to design a higher pressure engine. At the time, based on our best understanding of the problem and where we were going, it seemed like a reasonable place to start. As it is, we didn’t have any problem making the cooling work, in spite of the more demanding heat flux environment. The limit we ran into with throttling wasn’t that the engine itself couldn’t throttle further, just that precision valve position control at the low throttle point was beyond the resolution of our valve system at the time. Had we ran the engine blowdown-mode (which they can just fine), the lower supply pressure towards the end would’ve allowed us to throttle down much further, by moving the required valve Cv back towards the middle of its range, instead of right on the very edge. But for our first several vehicles, we didn’t need a 10:1 throttle range, so we stopped pushing when we had a system that had already exceeded our expectations and requirements.

The tanks issue is a big part of why we’re going with lower pressure engines for this next iteration. As for how hard it is to get good tanks, we have a single data point with a flakey supplier (and an overly trusting project engineer–myself). If we had had more resources (and more importantly, more time) to do the iterations on the tanks that we wanted, we could probably have gotten a solid process down without too many attempts. But by lowering the engine pressure like we’re planning, it brings us back to similar operating pressure to Armadillo, Paragon, XCOR and the others, which greatly reduces the technical risk.

“actually making CAD models” – Armadillo does that, too. I think John Carmack finally stopped writing g-code by hand and let the CAD program generate it CAD models do not make Armadillo slower, they make them faster because they couple them with their CNC machines. They make as many parts as possible themselves on such a machine or they use off the shelf parts.

When we were up in the Bay Area we had access to an old CNC Mill and a manual lathe. While we still had some of the more complex parts made by outside suppliers, we did a lot of the simpler parts ourselves. And you’ll get no argument from me that being able to in-source more stuff in the future will definitely help speed up iterations.

If you can build a couple of freshly designed engines in a week or two, why bother making models?

There are various reasons why making models helps things out. Fitup is one of them. Mass properties for developing and testing control algorithms is another. Reproducability and keeping a good record of design decisions is another.

Basically, there are some things with engine design that are more qualitative (ie how do I make this interface work, what sort of connector should I use here, etc.), while there are other parts that are more quantitative (how many cooling grooves, what profile, what specific dimensions, etc). While some things on an engine are very amenable to just iterating as fast as you can, other parts of engine design are much faster if you balance those iterations with modeling and analysis (followed by more hardware testing to make sure that your models were close enough). There are definite times during our engine development, where things would’ve gone faster with a good in-house machine shop. There are other times that if we had taken the purely guessing approach it would’ve taken us three times as long and worked half as well.

“taking data,” – they get lots of data. They also often post it on their site. As do the Breeds and “Jack Crossfire”, a guy who plays with autonomous helicopter flight.

I should have said that I think we have a much more thorough and systematic approach to doing subsystem testing.

“There really are some things for VTVL systems that really push you towards more formal processes” – If it is anything like building software, and I believe it is, then one should be really careful with formal processes when one enters uncharted territory. Some of the things under the “formal processes” umbrella are useful no matter what and just helps finding problems earlier or helps keeping them out. Others are about planning a lot in advance before building it. That works fine for things that have been tried many times before (if the organization also has tried them before). It usually fails spectacularly when there is too much new stuff (even if it IS something that has been done a million times before and it’s just something new for the organization). The smartest thing to do in such cases is to take smaller steps so one can adjust course more often and learn more. And one should test a lot along the way and gather lots of data.

Oh, I agree with you full-heartedly there. I think you misunderstood what I meant. There are companies out there that think that you can just design your suborbital vehicle all in one go, run it through a traditional aerospace design process, and that testing is really just proving your design works as advertised. We’re not one of those companies. There’s a reason why we’re doing incremental test vehicles–it’s to learn along the way what works and what doesn’t. That still doesn’t mean that things like design reviews, some documentation, checklists, etc. don’t have a proper place. Also, to clarify, most of our “design reviews” are small, informal things. Basically the guy who was designing a part or system will call everyone over for a few minutes to go over what he did before getting the new part made. This includes going over assumptions, any analyses done, having others look over the drawings to try and catch missing details, allowing them to ask questions and critique the design a bit, etc. Not some formal meeting where we have a two hour power point presentation. We’ve done one external design review (with a group that had relevant experience), and it was very informative and useful. But most of the “formality” we have is still on the very informal level.

That’s why software projects that do “big bang integration” usually fail hard. The way to go is “continuous” integration – by which is not meant “integrate every 5 minutes” but something like “integrate every day” or at least every week.

Sometimes that’s feasible, other times (most times by my experience) it’s not. But we do try to do the integration testing in an incremental fashion. It’s a lot easier to have a daily build, when the worst crash you get is just electrons. With hardware projects, it’s often hard to break iterations down into “reintegrateable” chunks like you can with software.

Congratulations! That’s very good news How much of your engine can you make in-house on that mill?

Well, once we get a lot more experience…we could probably do almost all of it. Some of the cuts would be easier on a lathe than a mill, and some of the other processes we don’t have anyone in-house with the experience–yet. But eventually, I think we’ll have most of our engine manufacturing in-house, at least for our current design approach.

~Jon

I believe you are right about that!

(But it requires a high tank pressure compared to Armadillo and Unreasonable and can’t be throttled as far down as Armadillo’s design. Building solid tanks is evidently harder than one should think, judging from yours and Unreasonable’s experience — and some of Armadillo’s early experience. James Bauer put his tank welding guide up on their site, though, so if nothing else, one should be able to learn from that.)

“actually making CAD models” – Armadillo does that, too. I think John Carmack finally stopped writing g-code by hand and let the CAD program generate it CAD models do not make Armadillo slower, they make them faster because they couple them with their CNC machines. They make as many parts as possible themselves on such a machine or they use off the shelf parts.

If you can build a couple of freshly designed engines in a week or two, why bother making models?

“taking data,” – they get lots of data. They also often post it on their site. As do the Breeds and “Jack Crossfire”, a guy who plays with autonomous helicopter flight.

“There really are some things for VTVL systems that really push you towards more formal processes” – If it is anything like building software, and I believe it is, then one should be really careful with formal processes when one enters uncharted territory. Some of the things under the “formal processes” umbrella are useful no matter what and just helps finding problems earlier or helps keeping them out. Others are about planning a lot in advance before building it. That works fine for things that have been tried many times before (iff the organization also has tried them before). It usually fails spectacularly when there is too much new stuff (even if it IS something that has been done a million times before and it’s just something new for the organization). The smartest thing to do in such cases is to take smaller steps so one can adjust course more often and learn more. And one should test a lot along the way and gather lots of data.

The development model should look like a (fast-moving) spiral rather than a waterfall. And there should be lots of “scouting” experiments. Flexibility becomes more important than planning for the future – and the most flexible part of a program is the one that isn’t there.

And finally, systems integration is usually harder than building even the hardest module of the design. That’s why software projects that do “big bang integration” usually fail hard. The way to go is “continuous” integration – by which is not meant “integrate every 5 minutes” but something like “integrate every day” or at least every week.

Look at the Jack Crossfire guy: http://www.rcgroups.com/forums/member.php?u=115141 he had his first helicopter with measurement devices + computer + RC + autopilot up in July 2007 (or perhaps a bit earlier) after starting from scratch in September 2006 without even knowing how to fly an RC helicopter. It still wasn’t really smooth and stable when it crashed around New Years… Along the way, he had trouble with things like heavy components vibrating themselves or the circuit boards asunder, voltage regulators changing their output due to resistors getting hot => bad analog measurements, the typical Americans-don’t-know-how-to-solder problem, oxidizing traces on his PCBs, GPS’s that vibrate too much (Armadillo also had that problem), RC/video antennas that interfered with the GPS’s, GPS’s that were disturbed by the metal on the helicopter, and much, much more.

It is very hard to avoid all such problems in a planning stage.

“Also, we actually have had a CNC mill on its way for a while, we just weren’t going to bring it up until it was in-house.”

Congratulations! That’s very good news How much of your engine can you make inhouse on that mill?

There really are some things for VTVL systems that really push you towards more formal processes–actually making CAD models, doing a little FEA on critical areas, having design reviews, taking data, making models etc. Rapid prototyping helps, but it’s just a tool, and sometimes it isn’t the right tool for the job.

Also, we actually have had a CNC mill on its way for a while, we just weren’t going to bring it up until it was in-house.

~Jon

That’s very good news!

I hope you will also implement some of the Lean ideas. 5S seems to be a good place to start:
o sort – get rid of non-essential items, make sure most frequently used items are close by
o store/straighten/set in order – a place for everything and everything in its place
o shine – keep things clean so you can tell when problems occur
o standardize
o sustain

http://en.wikipedia.org/wiki/5S_(methodology)

Just compare the pictures of your shop floor with some from (dare I say it?) Armadillo. Another example would be this wooden board that gathers in one place all the control valves for fluids and gases used during flight preparation:
http://media.armadilloaerospace.com/2007_07_14/controlBoard1.jpg

Notice how they don’t overdesign it on paper first and then send it out for review. Instead, they flew without it first, noticed things were messy and clumsy, decided to experiment with such a board AND THEN THEY MADE A PROTOTYPE IN WOOD. Only then would they consider building a metal one.

Modularity is another thing I hope you will give more thought to. Going back a couple of blog posts, you talk about how you had to work hard and crawl all over the vehicle for a couple of days to implement what seemed like a simple change. Is XA-0.2 going to be more modular? Are there more things that can be replaced within 15 minutes? Armadillo (again) has these nice two electronics box they could swap in and out. They could test with one of them while the other one was being repaired or upgraded, and they could swap them out for debugging, to see if that improved anything.

I know that I could talk a lot about Armadillo but they do seem to have better vehicles and it’s not just down to John Carmack’s money or their hard work (they work less than you do, don’t they?). They explicitly wanted faster cycles and less advance planning right from the start (because nobody really knew how to build small and cheap rockets – and they still quite don’t). They also somehow happened to get a good mix of abilities in-house early on and they produce lots of stuff themselves. A CNC milling machine and a lathe seem to be very good things to have, too. The Paul Breeds have both and have used them extensively:
http://unreasonablerocket.blogspot.com/2006_11_01_archive.html

The in-house CNC machines are one of the ways both the Breeds and Armadillo have shortened their cycles.

There is one area in which I think it is possible to do much better than those two teams: paranoia. It seems like they trust that things will work out more than they should have. For example, Armadillo did try lots of back to back 180s flights – but never so close together as they did on the contest day. And before that, they had barely tested their landing.

-Peter Lund, armchair rocket scientist and monday morning quarterback

Now that you have realized this, I’ve changed my evaluation of you. You might end up flying after all

Thanks. Honestly, going into this, we thought that both the rocket engine and the GN&C were going to be the hard parts. It turns out that the rocket engine itself has been relatively straightforward, the TVC actuation systems less so, and the GN&C has by far been the hardest.

Yup. I think having James Bauer on board really helped Armadillo. Have you given careful, considered thought to how you might speed up your iterations (perhaps, but not necessarily, by doing less in each iteration)? It seems to be a good idea no matter what one is trying to do — and it certainly seems to be one of Armadillo’s tricks. Or Toyota’s, for that matter.

That’s a good question that probably deserves a longer answer than I can do in comments. One thing we’re doing that should help is gradually bringing more of the manufacturing in-house. We’re in the process of doing that, which should at least speed up hardware iterations such as future engine revs.

~Jon

~Jon

~Jon

“Quite frankly, the basic rocket propulsion part of our vehicle has been the easy part.”

Now that you have realized this, I’ve changed my evaluation of you. You might end up flying after all

“The last position we’re currently looking to fill is for a technician/fabricator.”

Yup. I think having James Bauer on board really helped Armadillo.

Have you given careful, considered thought to how you might speed up your iterations (perhaps, but not necessarily, by doing less in each iteration)? It seems to be a good idea no matter what one is trying to do — and it certainly seems to be one of Armadillo’s tricks. Or Toyota’s, for that matter.