New Hiring, New Engine, and XA-0.1 Replacement Plans
It’s the beginning of a new year, and there are many changes afoot at MSS, so I figured it was about time for a bit of an update. A lot of people were curious about what direction we would end up taking after we damaged our vehicle last month, so I wanted to discuss some of our plans for this year.
MSS Now Hiring
One of the biggest changes that we’re undergoing at the moment is an effort to augment the core team here at MSS. We haven’t had any real changes to our core team since early 2005, but situations change over time, and we’ve been recognizing the need to expand and diversify our skillset as a team. Basically, we came to the conclusion early last year that there are a couple of areas that we really need to have someone in-house with solid expertise in, particularly Guidance, Navigation and Control. We’ve updated our careers page with more details, but I’d like to go into some of the reasoning for why we’re looking to fill some of these positions.
GN&C Engineer(This position has been filled)
Even though we’ve been working with outside groups to provide us with expertise in this area, we’ve long since come to the conclusion that having someone in-house who has a good understanding of controls engineering is very important. Having someone with real experience in that area is critical to properly specifying and designing actuators and other subsystems. A lot of the control systems related challenges we’ve had to fight through over the past year and a half came from not knowing what to expect, “failure to overcommunicate” when it came to specifications, and just the general learning curve of figuring out what data was important and how to actually verify that things were performing the way you expect them to. Quite frankly, the basic rocket propulsion part of our vehicle has been the easy part. Now, we’ve actually learned a lot of these things by now (the hard way), but we’d like to have someone on board who can work with us when we sit down to do a new vehicle, and make some models to predict the kind of specifications we’ll need for throttle valves, gimbal response etc. We’d also like to be able to have someone on board who knows what they’re doing controls-wise so we can make modifications to our flight code as we do flight testing, to speed up the iteration cycle. GN&C really ends up being the heart and soul of a VTVL rocket system, and not having anyone in-house who even “speaks the language” is a situation we’d like to change. If anyone reading this happens to either have experience in Multiple Input, Multiple Output control systems (particularly in an aerospace or aviation environment), or to know someone who does, they can find more information about the specifics of what we’re looking for here.
Senior Engineer/Project Manager
Several months back, we had a good friend (and competitor) of ours drop by for a visit while he was in the area. One of the things he brought up got me thinking a lot about the various approaches there are to building an engineering team. Our friend’s company pretty much only hires people with 10+ years worth of experience in aerospace engineering. His philosophy was that sure you have to pay them a lot more, but you’re getting a solid engineer, a known quantity, someone you can depend on. There’s some truth to his philosophy, and his company has been making good progress. On the other side of the spectrum, we have some other friends whose company doesn’t have a single person who had previously done professional rocketry. I’m not even sure if a single one of them had ever fired a liquid rocket before they started their company. But they’ve also been very successful over the years, and have earned a good reputation in the industry. We’re probably a lot closer to the latter than the former. I’m not sure of this, but as far as the entrepreneurial space launch community goes, we may have the youngest engineering team overall. Dave’s the only one who works here full-time that’s older than 30. I’m the only one who ever worked for an aerospace company before this job (and that was just as a contract proposal writer/patent writer), though Pierce and Dave had both built and flown peroxide monopropellant amateur rockets.
All told, both ends of the spectrum have drawbacks as well as benefits. The more I’ve thought about this, the more I’ve come to the conclusion that like many things in life, the best option is probably somewhere between the two extremes. I had a chance recently to meet some of the members of the propulsion team for another major alt.space company, and I think they do a really good job of this. While they have some very experienced industry veterans heading up the department, the younger engineers outnumber them about 3 to 1. The younger engineers get a great mentoring environment, while adding a lot of enthusiasm, new ideas and approaches, and excitement to the mix. Having at least some experienced engineers on board also helps make it so the younger engineers don’t have to learn all of their lessons the hard way. Before I had met that propulsion team, I had already been leaning towards the belief that the best way to organize an engineering group is to have a balance of some more experienced engineers along with a larger number of younger engineers, but now I’m pretty much convinced.
Especially since we’re now starting into some more complicated projects for some of our customers, we’ve decided that as part of the restructuring of our team, we’d like to bring on a Senior Engineer/Project Manager. Someone who’s been in industry a bit longer (though not necessarily the launch vehicle industry–there are several other hardware related industries that would also provide useful experience), who may have a broader depth of knowledge, and who has more experience with managing complex projects than any of us do. You can find more details about the specifics we’re looking for here.
Office Manager/Accountant
On the business operations side of things, we’ve decided to bring on an office manager to take some of the weight off of Dave, so he can focus more on the engineering side of things. Trying to be the President, CEO, “Speaker to Regulators”, Accountant, Office Manager, Ground Controls Programmer, Pilot, Network Engineer and Janitor all at the same time is a little bit more than you should leave on any one person’s plate for too long. More details on that position can be found here.
Technician/Fabricator
The last position we’re currently looking to fill is for a technician/fabricator. Ian’s been doing a lot of our fabrication work, but we’d like to bring on some additional help whose sole focus is this area. Basically we’re looking for someone with an attention to detail and who has good shop skills and the willingness to learn new skills and techniques. Prior experience in a machine shop, or as a welder/fabricator, an auto or airplane mechanic, or other related technical backgrounds is strongly desired. More details here.
Technical Plans: XVT-750LIT-1 and XA-0.2
On the technical side, we thought long and hard after XA-0.1 was damaged last month. Our first inclination was to just patch her back up and get her back in action. It would’ve only taken 1-2 weeks to get back into shape, but the more we thought of it, the more we agreed that it was time to move on. One of the issues that has been plaguing us with XA-0.1 for over a year was that due to a “failure to overcommunicate” we selected a throttle valve concept and hinge actuation system that didn’t have adequate response characteristics for controlling a multi-engine vehicle like ours. The response characteristics would’ve been adequate for a single engine vehicle like some of the ones Armadillo has made, but that would’ve required redesigning both the engine and the vehicle as a whole (and would led away from our long-term path), so we tried to just see if we could make the system work in spite of the actuators. However, after this last flight, we realized we had finally reached a point where it no longer made sense to keep trying to force XA-0.1 to work, and that instead it would be better to take all of the lessons learned and move on to a new vehicle.
XA-0.2
For the new vehicle we narrowed down the options to three main alternative approaches:
- Build a subscale vehicle using smaller engines with much faster actuators and a more symmetrical vehicle arrangement with an inline tank configuration.
- Build another XA-0.1 scale vehicle, but with some improvements such as an inline tank configuration, engines closer to the centerline, wider baseline landing gear, and much faster throttle and gimbal response.
- Finish XA-0.2 but with upgraded engines, throttle valves, and hinge actuators.
We decided to go with the third option for several reasons. First off, bigger vehicles that are more symmetrical are easier to control than smaller vehicles. The much higher inertial matrices make the vehicle less sensitive to perturbations, which greatly relaxes the requirements for response time on the valves and gimbals. The fact that XA-0.2 has the engines closer to the inside, and the landing gear further out doesn’t hurt either. Second, we had already built a lot of the hardware for XA-0.2 by the time we stopped work due to the tanks problem, and we had already put the design through an external design review, so we had at least some validation from an experienced team, that our concept and approach was on the right track. Third, we have a customer that wants to use XA-0.2 this year, and if we built another vehicle first, we might not be able to deliver in time. Fourth, XA-0.2 was the only option that actually moves us forward towards our eventual goal of fielding XA-1.0.
There are a couple of changes in the works already for XA-0.2 compared to the original design we were building for the X-Prize Cup. First off, we’re going with a centralized engine computer for this vehicle. We realized that with the vehicle we had, we had lots of computers, but no real redundancy. If any of the engine computers (or the vehicle computers) had died, we would’ve lost the vehicle anyway. We’ll still probably have valve and hinge control boards as well as a sensor muxer board down on the individual engine modules, but all the main smarts will be run off of the same PC-104 stack that runs the vehicle Onboard Flight Management System (that controls the shutoff valves, vent valves, ground ops, and range safety). The other big change is that we’re going to rework the entire engine design.
XVT-750LIT
One of the quirks of the original XA-0.2 design was that since we were using the original 500lbf engines, the vehicle would only have enough thrust to take off with a half-load of propellant. That would’ve still given us about 120-150s worth of flight time, but in order to get enough thrust to take off with a full propellant load we were going to need either a fifth engine, or to upthrust all of the engines (what we were then calling XA-0.2B). Since we were going to need to redesign the valves and actuators anyway, and since there were still one or two remaining squawks with the engine design that we wanted to fix, we decided that now would be a good time to upthrust the engine, and roll in all the lessons learned from our previous engines.
We’re in the process of releasing the prototype for production. Our performance goals are to achieve a 50% increase in thrust compared to our previous engines (ie 750lbf) at a much lower chamber pressure (250psi vs. 550psi), all without increasing the weight by more than 50%. We’ll take a slight Isp hit due to the lower pressure, but it will also make our tanks a lot easier. In fact, it brings our tanks down to a similar pressure range to what have been done by Armadillo and Paragon. And this time around we’re optimizing the expansion ratio for lower altitude flights, since our near-term projects are mostly low-altitude missions. What this means is that in spite of having a lower peak Isp, if we hit our targets we should still have almost as good of a mission-averaged Isp for long hovering missions (such as the Lunar Lander Challenge). The engine design also features a more compact igniter style, a new chamber/igniter interface, and at least as of this moment is only predicted to weigh less than a pound more than our existing engines. The design is a scaled version of our previous engine, so we have pretty high expectations of it working well for us. Here’s what the engine looks like (minus external plumbing):
We need to get the trailer rehabilitated before we can start testing, but we’ll probably be doing that while this new design is out for machining. We’ll post more details as we have them.
Contracts and Other News
We recently finished sending off the final report for our first commercial contract, which involved doing a design review on a 6-axis Solid Rocket Test Stand designed and built by the Florida Institute of Technology (in conjunction with Space Florida). This stand is to allow students and other groups to test solid motors up to 10klbf, with a really good DAQ system. We’re talking forces and torques at high enough resolution to measure any sort of combustion instability issue you could think of. We look forward to working with these guys again in the future.

We also have another major project and some licensing agreements in the works that we can hopefully say more about in the near future.

Great news.
I’m looking forward to seeing some flights.
Comment by Lee Valentine — 1/5/2008 @ 6:34 am
It looks as if you’re making steady progress. Do you still expect to have XA-1.0 flying by the end of this year?
Comment by Fred Fowler — 1/7/2008 @ 1:47 am
It’s great news to hear that you are expanding your team!
The new XA-0.2 design sounds like a LLC level 2 contender. Will it be a clear goal or something on side-track?
Comment by K.L. — 1/7/2008 @ 1:58 pm
Glad to hear your expanding the team and making some headway!
Comment by philip Baldwin — 1/7/2008 @ 4:53 pm
if not for the permanent US residency requirement ( ITAR ? ), i’d apply for a job
btw, it looks like your website could use some slight update on “Products” page, at least on timeline parts.
are you still sticking to that general product development outline ?
Comment by kert — 1/7/2008 @ 6:59 pm
“there are a couple of areas that we really need to have someone in-house with solid expertise in, particularly Guidance, Navigation and Control.”
“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.
Comment by Peter Lund — 1/7/2008 @ 10:52 pm
K.L.,
Yeah, XA-0.2 with the upgrades we’re doing should have more than enough performance for Level 2. However, it also happens to be the vehicle we’d want to build next even if it weren’t for the LLC. If we can get this new engine debugged and operational, and if we can get the vehicle ready to fly early enough in the year, we’ll probably take a shot at competing this year. We just don’t want to rush things and risk a revenue generating vehicle if we don’t think things are ready yet. Either way, we should have a much better feel for where we are by Space Access this year.
~Jon
Comment by jongoff — 1/7/2008 @ 11:31 pm
Kert,
Yeah we need to update that timeline. It was mostly there just to show the potential relationship between our suborbital work and more advanced markets down the road, not so much as some sort of infallible, master 10 year plan that we expect will be implemented exactly as shown. Updating those section is on our to-do list, but at a lower priority than getting new engines working, hiring some new people on, and getting our next vehicle ready.
~Jon
Comment by jongoff — 1/7/2008 @ 11:36 pm
Peter,
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
Comment by jongoff — 1/7/2008 @ 11:58 pm
“One thing we’re doing that should help is gradually bringing more of the manufacturing in-house.”
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
Comment by Peter Lund — 1/9/2008 @ 2:17 am
Peter,
Regarding 5S and other Lean tools, my undergrad degree was in Manufacturing Engineering, so you could say I’m somewhat familiar with the techniques. As for rapid prototyping, we do a lot of that as well. Some things lend themselves to just a couple quick sketches and then welding things together. Others don’t. It’s important to strike a balance on these things. Armadillo really does do some things well, and we try to trade advice/best-practices when we get a chance to meet up at conferences. But there are some real differences in approach between our companies, and at least in some cases, I feel unabashed in saying we did a better job. Such as getting a reliable regen cooled engine design.
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
Comment by jongoff — 1/9/2008 @ 7:21 am
“[...] and at least in some cases, I feel unabashed in saying we did a better job. Such as getting a reliable regen cooled engine design”
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?
Comment by Peter Lund — 1/9/2008 @ 6:13 pm
Peter,
“[…] and at least in some cases, I feel unabashed in saying we did a better job. Such as getting a reliable regen cooled engine designâ€
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.)
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
Comment by jongoff — 1/9/2008 @ 11:45 pm
[...] MSS Blog: It’s the beginning of a new year, and there are many changes afoot at MSS, so I figured it was about time for a bit of an update. A lot of people were curious about what direction we would end up taking after we damaged our vehicle last month, so I wanted to discuss some of our plans for this year. [...]
Pingback by The Space Fellowship — 1/10/2008 @ 9:42 am