The Blog!

It’s been a long time since the last time I wrote an update, so I figured that now as a good time to stop and take a few minutes to go over what we’ve been up to out here in Mojave. I apologize for the long delay in posting–we’ve been fairly busy over the past month or so, and as any of you who read Selenian Boondocks may have noticed, I haven’t been in much of a blogging mood lately.

Tanks, Engines, and other XA-0.2 Progress
As many of you who have been following our progress over the past year or so may remember, one of the things that contributed to us not being able to field XA-0.2 in time for the X-Prize Cup was the problems we ran into getting custom 36″ propellant tanks fabricated. One of the ideas we came up with after XA-0.1’s last flight attempt back in December, was to build a new set of engines for XA-0.2 that ran at a much reduced chamber pressure. This would allow us to also lower the required feed pressures in the propellant tanks, which would bring them closer to what others in the alt.space community (such as Armadillo and Paragon Labs) have been doing. With the amount of work we had on our plate this year, we realized that it was going to be challenging to try and orchestrate all the parts of getting the new tanks made in addition to everything else we needed to do. So, we decided to contact Paragon and Armadillo, to see if we could work out a deal to have one of them build us a set of tanks, so we could leverage their previous investments in tank manufacturing development. While Armadillo wasn’t interested at the time, Paragon was, so a few months back we signed a contract with them for the production of a prototype tank and two flight tanks.

These tanks would be made of 5383 aluminum, and since we had lowered the required feed pressures far enough, they ended up being the same thickness and size as the hemispheres Armadillo has used on their Mod and Quad vehicles. In fact the hemispheres were made at the same company (AMS Industries), so they probably came off the same spinning dies. Interestingly enough, when the hemispheres came in, all of them exhibited little or no thinning at the equator, which was much better than the results we had gotten with the other spinning shop.

After doing a little more research, we decided to change the baffle design for these tanks, and the tanks incorporated several improvements over the previous designs. Most importantly, we knew that Paragon had invested a lot of time and money into perfecting their process for welding spherical 5383 aluminum propellant tanks.

We released the order back at the start of March, and over the weekend I got an email from Kevin letting me know that the tanks were done, and had passed the proof hydrotest (at 1.5x the maximum expected operating pressure). We’re finalizing the plans for shipping the tanks out to Mojave for fitup, hopefully sometime this next week. Once we’re done making sure the design will fit correctly with our frame, we’re going to send the tanks down to a company in Burbank (Quality Precision Cleaning) and they will do a “low-cycle fatigue” test series on the tanks. Basically, we’re going to have them cycle the tanks 1000x at slightly over the planned operating pressure. Our reasoning is that since, like Armadillo, we designed the tanks for about a 2.0 FOS over the ultimate burst pressure, we may be operating the tanks close enough to their yield stress that we might have potential low-cycle fatigue issues. Most good 5000-series aluminums have yield strengths about half of their ultimate strength in the annealed condition, which means a FOS of 2.0 over burst implies an FOS of not much more than 1.0 over yield. It’s probably paranoia on my part, but I just want to make sure I don’t have a situation where we proof test a tank to 600psi, then several cycles down the road have it fail on me at 400psi. Also, I don’t think any of the other groups working on similar tanks have done a test series like this, so it’ll be useful information for everyone to have. If we were trying to bring tanks in-house, or if we were trying some material that Paragon or AMS had never worked with before, I’d probably have done a few subscale burst tests to make sure we had our process down, but since the material and thicknesses were similar enough to what Paragon has done in the past, we felt pretty good about just doing a 1.5x over MEOP proof test on each tank, and a fatigue cycle series on the first one.

Anyhow, we’re really pleased so far with our work with Paragon. Our contract work with them has been by far our smoothest experience with outsourcing. Hopefully we get the chance to work with them again in the future.

Anyhow, here is some eyecandy:

While the progress on tanks has been great, the progress on engines has been a bit slower. We now have many of the parts in for our first test engine, but we’re still waiting on some of the main components. We ended up having to switch some of the bigger parts to a different machinist last month, since our first machinist was too overloaded with work (he also does a lot of work for XCOR and several other clients). We also found out in the process that the copper material we had designated for the chamber was actually a real pain to machine. After doing some digging, we found another alloy that I had initially overlooked that looks like it will do much better for our application. In order to make sure we had a good braze-joint design and manufacturing process, our machinist made a few sample joints and had them brazed and checked. We had to do two iterations to get the design right, but we now have a design that we’re all confident with. Hopefully we’ll have some pictures to post in the near future.

In addition to the engine itself, we also needed to overhaul our testing infrastructure. We wrapped up horizontal testing in our trailer of the 500lbf engines over a year ago now, and as we were trying to get XA-0.1 debugged and working, we had little by little cannibalized some of the parts from the trailer. Also, when we got into real testing of the vehicle, we ended up removing some of the main internal pieces like the thrust frame and a lot of the plumbing in order to use the trailer as a temporary blockhouse. So, as part of getting ready to do tests, we planned on overhauling the trailer, and fixing up a lot of the minor things that had worn out over the past few years. Our original plan had been to just throw the trailer back together the way it was, with little or no modification, however as we got into doing some of the repair work we finally decided on a bit more thorough of an overhaul.

We pulled most of the plumbing and all of the wiring from the trailer, swapped a few AC solenoids for 24DC ones (so now all of our valves in the trailer run off of 24VDC), and started thoroughly cleaning things. During our early engine testing back in 2005-2006, we had found that our uninsulated LOX tank was suffering from way too rapid of boiloff, so we decided to insulate it. At the time there was no easy way to remove the tank, so the decision was made to foam it in-place. The aesthetically pleasing result had been affectionately referred to as “Pierce’s Snot Goober” ever since–anyone who had seen our trailer would know what I’m talking about. Anyhow, once we had everything else out, I realized it would be relatively easy to pull the tank and clean up the insulation, so we did. It’s a good thing too–we ended up finding lots of areas on the back and bottom that we hadn’t been able to actually get foam on. We patched those up, trimmed the foam to as close to a spherical shape as we could get, fiberglassed the whole thing, and then painted it. It isn’t perfect, but it looks a lot nicer:

On the IPA side, we had previously had some propellant loading issues. Basically if we loaded the tank too full, insufficient ullage could cause fairly large pressure fluctuations at the beginning of the run. We had worked around the problem for a while by having a sight gage when filling the tank, but that was a bit of a kludge. While we had everything out, we pulled the top fitting going into the IPA tank, and welded on an “ullage tube”. This tube basically makes sure that you can’t easily fill the tank above a certain level. This should make our lives a bit easier.

In addition to cleaning up the trailer, and doing some maintenance and repair to the wiring and plumbing, we also decided to make one other big change to the setup. Previously, we had been using a PLC on the trailer to run the engine tests. We had used one on the igniter, and XCOR swears by them, so at the time it seemed like a good idea. The reality though was that since our engines need to be actively throttled, this ended up costing us a lot of time the first time around. So we decided that this time around, we were going to replace the PLC with the engine computer from the vehicle (the OFMS or On-board Flight Management System). This will require a little more work up-front, but should allow us to test a lot closer to how we intend to fly. Basically, from the computer’s point of view the trailer is just a tipped-over XA-0.1B with only one engine installed, no hinge actuator, and no ACS inputs. This will allow us to test out the OFMS a lot sooner than if we waited until after the engines were done.

Anyhow, we’ve still got a lot of work left to go on XA-0.2, but as you can see we’ve been slowly making a lot of progress.

New Faces, Personnel Changes, and Interns
Back in January we announced that we were trying to hire engineers and technicians to try and flesh out our staff. Part of this was precipitated by the fact that Ian Moore and Pierce Nichols both left MSS back in January. Ian moved back up to the Bay Area to be with his significant other (can’t blame him she’s a good match), and took a job as a Testing Engineer for Northrop Grumman Marine. Pierce took a job with Jacobs’ doing work for the AFRL rocket test facilities in Edwards. Pierce still stops in occasionally, and Ian has stayed in the loop, but for personal reasons it was time for both of them to move on. They were good coworkers, and it was tough to let them go, but it also has ended up freeing up enough resources for us to diversify our skillset a bit compared to our old team, and our newest employees have proven to be excellent additions to the team.

You’ve already seen several postings from Ben Brockert here on the MSS blog, and if you went to Space Access this year, you probably got to speak with him (and he probably tried to sell you our igniter). Ben’s a talented technician, with a real eye for detail. He’s the kind of guy that if he doesn’t know how to do something, he’ll go read up on it and surprise you the next day. We first met him last fall, when he stopped in at our shop looking for a job. He had decided that he wanted to get involved in the industry, so he had packed up his stuff into a van, left Iowa, and came out to Mojave looking for work. Fortunately we were able to hire him before anyone else did. Just to give you an idea what kind of person Ben is, I’ll share this anecdote: Back when we were working on the igniter cart upgrade, we got to the point where we were getting the DAQ system back up and running. I realized that with Pierce and Ian gone, neither Dave or I really know how to program LabView. I came in that Monday expecting to have to spend all of that week and most of the next getting up-to-speed on LabView. You can imagine my surprise when I found out that Ben had taken the books home over the weekend, read up on them, and then came in and already had a basic LabView VI running by the time I got there Monday. Over the past few months since he’s started he’s become our resident welder, bracket maker, electronics tech, photographer, and the list goes on.

Our other addition to the MSS team is Ian Garcia, our new GN&C dude. Ian joins us from Draper Labs out in Boston, where he did GN&C work on various programs including simulation work for RpK’s K-1 vehicle, as well as navigation work including work with GPS systems. He was also involved in Draper’s ALHAT work for NASA. Ian has also been a great addition to the team, and I’ve learned a lot about GN&C systems just from talking with him. He started at the beginning of April, right after Space Access, and has been doing a lot of work with Dave on vehicle simulation, hardware in the loop testing, and other GN&C related projects. Since we have had two other people named Ian involved with MSS, Ben had originally suggested calling Ian Garcia “IIIan” (pronounced Three-An), but he got overruled.

Here’s the current Mojave crew next to our XA-0.1B frame. Ben is in the back on the right, with Ian Garcia in front of him.:

Also, in addition to full-time hires, we’ll also be adding two interns to our numbers this summer: Richard Bell, and Wayne Neumaier Jr. Richard is joining us from University of Colorado, Boulder. Wayne is joining us from University of Illinois Urbana-Champaign. They’ll be starting next Tuesday, so we’ll probably introduce them next week, once we have pictures we can add.

While we’ve now filled our GN&C position, one of our Technician/Fabricator positions, and both of our summer internship slots, we’re still looking for people to fill some other positions, you can read more about them here. Ben will be putting up a post soon with more details on the Fall internships slots for college students looking to get involved in this community.

Igniter Sale and other Business Stuff
We wanted to bring some hardware to Space Access this year, so Ben brought our new igniter to show around. As he deadpanned during our presentation there “Yes, it is an igniter in my pocket, and I’m happy to see you.” One of the people there at the conference was sufficiently interested, that he contacted us about purchasing one, and in the end, he ended up buying an igniter and spark driver system from us. We just shipped the igniter yesterday after putting it through its paces. It was actually kind of fun writing a product user’s guide for an item that we were actually selling to someone. It may be a while before we get far enough along on a website overhaul to have a page with our rocket components that we’re selling, but if anyone is interested in the meantime, the price we’re offering is $1936.00 for one igniter, with valves and associated orifices, spark driver unit, ignition detection unit, user’s guide, and qualification tests. In the future, as we up do upgrades to the igniter (including testing it with different fuel combinations), we will offer those upgraded systems for sale as well.

Once we’ve got the bugs worked out of it, we also plan on offering our 750lbf engine both by itself as well as in a full 2-axis gimballed module. While I know a lot of groups have talked about selling custom engines, we figured it might be interesting to see if anyone was interested in buying off the shelf. It’s going to be a learning experience of course, making the engine ready for sale off-the-shelf like this, and there are going to be restrictions (for instance we’ll probably be only selling to US entities, unless we get enough demand to justify jumping through all the hoops to get ITAR approval), but we figure it’s a worthwhile exercise for the industry.

In addition to the hardware sales, once we have our test stand back up and working consistently, we’re plan on offering people access to the test stand for engine and engine component development purposes. As currently designed, the stand can support engines up to about 2000-2500lbf thrust, and has run tanks capable of holding about 20 gallons each of liquid oxygen and hydrocarbon based fuel, with feed pressures of up to 650psi. The stand has fairly significant data acquisition capabilities (lots of analog I/O, flow meters, load cells, thermocouples, etc). We’re not yet setup for handling a cryogenic fuel, but the upgrades can be made if we have someone willing to pay for them. Pricing will depend fairly strongly on what the specific project is, but if you’re interested in testing liquid fueled rocket engines inexpensively, drop us a line.

Lastly, as previously mentioned, we’re actively working on one other joint project, with the possibility of adding another one later this year. We’ll hopefully be able to say something about those projects once they’re further along.

XA-0.1B Frame, Engine Repairs, OFMS/GFMS, and Actuator Upgrades
As you can see from the picture earlier, we finished the XA-0.1B frame earlier in the month. We chose the “cop magnet yellow” color for our frame because we were looking for a light color that wouldn’t get as hot in the Mojave sun. We got both tanks mounted, and all of the pneumatically actuated valves. We had to shift focus for a few days to get our sold igniter tested, documented, and out the door, but starting again on Tuesday when the interns arrive, we’ll be completing the plumbing and starting into the electrical work. We’re reusing a lot of the valves and regulators from XA-0.1, testing as we go to make sure things are still working fine. The good news is that almost all of the plumbing survived intact, so we’ve only had to purchase a few components (mostly upgrades not replacements). I’m definitely looking forward to doing the plumbing on XA-0.2. With the new tanks that I designed and Paragon built, we’ll be able to simplify the plumbing quite a bit, so it won’t look so much like a flying pile of aluminum spaghetti.

When the structure failed on our last flight attempt of XA-0.1, the vehicle dropped from about 5 feet, landing on one of the engine modules. We took the damaged module off a few weeks ago, to survey the carnage, and found that most of the components were still in ok condition. The engine itself took a beating, with both trunnions being sheared off, and the IPA and LOX inlet tubes getting mangled. However after some cleanup work, it looks like there’s a good chance the weld repair we’re going to have done on it this next week will go off without a hitch. These engines have proven to be extremely robust, and have served us very well. Once we have it welded back together, we’ll reassemble it, and make sure its leak tight. One of the things I had made for the new set of engines is a “hydrotest plug” that we can fit up into the nozzle and hold on with a gear puller. It’ll allow us to do leak checks, and for the lower pressure engines, we can even hydrotest the setup. The ability to do quick and easy leak checks is important for rocket engines, because leaks (particularly fuel leaks) can lead to really bad days. The new nozzles are much bigger, but have the same half angle, so we should be able to use them for both sets of engines. After the engine is leak tight we’ll rebuild the frame, and fix the throttle valve actuator that got bent.

While Ben and I have been having fun with the igniter, the trailer, the frame, and other hardware stuff, Dave has been working full-time on an upgrade to our vehicle computers. As mentioned back in our January update, we’ve decided to revisit the idea of distributed computing for our engines. At least as implemented on XA-0.1, we realized that while we had lots of extra failure points, at least we didn’t have any real redundancy. Hmm… So for now, we’ve decided to pull all of the smarts in to a single central engine computer. This computer runs on a much more capable PC/104 based stack, and runs not only the engine sequencing, but also all of the vehicle valving (such as the tank pressurization and venting, prevalves, etc), and the range safety soft-abort/hard-abort functions. We’ll still have a separate ACS computer for now, because we’re using the fact that they’re separate computers for safety and redundancy purposes. We’ve had all the computer hardware in-house for a while, and Dave has been coding, running unit tests on different components, and making the Hardware-in-the-Loop simulator, among other things.

In addition to the On-board Flight Management System, we also have a Ground Flight Management System (GFMS). This system is the pilot interface. It is what sends commands to the OFMS when to open and close certain valves, when to start the engine firing sequence, and what to do from there. Dave had written the original code for this, but with all of the work that needed to be done on the OFMS, one of our angel investors who’s been more and more involved with us as of late stepped in to help with the GFMS code. His background was in computer programming and software development, and he had previously been working with Dave on making a simulator for the vehicle to try and figure out what happened when XA-0.1 crashed last year. In addition to more thoroughly testing the interfaces between the three computers (GFMS, OFMS, and ACS), our colleague has been overhauling the GFMS code. Cleaning it up, adding new functionality, and really helping out a lot. One of the changes they’ve implemented is automating the checklists. The vehicle has certain states it can be in, and it isn’t allowed to pass from one state to the next until certain items have been checked off. While we had used a checklist before, there was nothing to actually physically prevent one from getting ahead of oneself. Now, the checklist will be right there at the pilot’s finger tips, and we’re hoping that as we debug this list, this new tool will help streamline operations and improve ground safety at the same time. We’ll need to make sure that the system works correctly and doesn’t introduce any new error modes, however I have pretty high confidence that Dave, Ian, and our other colleague can make the code solid and reliable in the end. Aerospace isn’t the only industry where software mistakes can cost lives or livelihoods. In addition to automating the checklist, we’re also in the process of figuring out exactly how to handle both pilot inputs, and guidance scripting. Once we have the Hardware in the Loop testing setup a bit further along, we’ll start testing the GFMS and OFMS more thoroughly. I’m looking forward to seeing all these pieces come together over the next several weeks. Ironically, while I had originally expected the computer stuff to take the longest time, there’s a non-zero chance they’ll be waiting on me, Ben, and the interns for getting the hardware done.

I’ll get more pictures of some of this stuff as time and ITAR considerations permit.

One of the other things that precipitated the move to a central engine computer for XA-0.1B, instead of just trying to patch up what we already had for XA-0.1 and get flying ASAP, was our work on the valve and hinge actuation schemes. I haven’t been very happy with our valve actuation scheme for a while. We spent a lot of time trying to reduce the response time latency on our valves a year and a half ago, but had never been able to get anywhere near what we wanted. We were seeing response times well over a quarter of a second, even after everything we could try, so we finally figured that was the best we could get, and we decided to see what we could do with that. Back in the fall, Ian and I decided to spend a bit of time and put together a dynamic analysis of our engine, taking into account stuff like valve response time, the different fluid resistances, inertance, capacitance, etc. The big takeaway we got from that was that even in the absolute worst case, the fluid delays accounted for well under 50ms of the command-to-thrust-change lag. At that point, we had assumed that for one reason or another, our valve just wasn’t starting to move very quickly. We had speculated at that point that it must have been the amount of time it took to ramp up the current to the valve before it had enough torque to overcome the valve stiction. We thought about other actuation schemes that didn’t involve as much seal drag, but at the time we didn’t really have the resources to pursue those. Based on that information, we figured that for electromechanical ball valves we had nearly reached their limits, and that therefore it was going to be very hard to do vehicle control via differential throttling alone.

I ended up getting into a little bit of an argument with John Carmack (who BTW is a great guy, and has been very helpful over the years to what we’ve been trying to do here at MSS) about whether he would be able to fly their 4-pack MOD design with differential throttling only. During the argument, it came out that John thought his dynamic throttling was reacting much faster than ours was, and he agreed to log some data at some point in the future to prove it. True to his word, he did. What the data showed was that his valves were moving within 5ms of being commanded, and the chamber pressure was starting to rise within 50ms. Within 100ms the throttle change was mostly done. At about the same time as this, I had looked up the KZCO valves John was using, and one of the illustrations showed the actuator driving his valves looked like it is probably the same brush DC gearmotor we are using. Armed with all of this data, we realized that we had probably misunderstood where the valve motion lag was coming from, so we took a couple of days, and hooked up a bunch of data acquisition (with the help of our friend John Bergmans of Bergmans Mechatronics). What we found was that the valve controller boards we were using operated differently from the way I had thought, and had lots of inherent lag in them. When we totalled up all the different lags, we realized that if we had a direct-drive H-bridge type system, that we could probably get similar response times to what John is getting (which shouldn’t be too surprising as that’s more or less what Armadillo does). We decided to do a quick proof of concept test with some off-the-shelf H-bridges. While we were waiting for the H-bridges to arrive, Dave made a first pass at a simulator for the system, just to make sure he had some sort of intuition about what effects mattered. One of the things he found was that with the 8-bit AVR microcontrollers we were using previously, there was no way he could get such a closed loop system to work. The resolution was just so low that you tended to get a lot of overshoot. This was probably part of why we hadn’t gone with direct H-bridge control when we first investigated the idea over a year ago. Fortunately, at this point, since we were going to a much higher capability A/D setup with our new OFMS computer (all 12 and 16 bit), this was no longer a problem. We’ve done a few more integration tests with the OFMS as the code has developed, and we’re now to the point where we should be able to test position servoing in the next few days. After we’ve got that debugged, we’ll have to wait for either the trailer or the vehicle to get far enough along for us to try out a couple of dynamic throttling algorithms in the real world, but we should at least be able to try a few things out on Dave’s Hardware-in-the-Loop simulator.

In addition to the valve lag, the stepper motor setup we had for the engine hinge was also showing quite a bit of lag. It took enough time for the “acceleration” circuitry to ramp up to enough force, that we were seeing fairly serious lags in this system too. After a bit of thinking, we’re also looking at swapping out our Ultramotion Digit actuators for slightly modified Bugs (modified to be the same length as the Digits so we can just swap them out directly). Bugs are Brush DC, so we can drive them with the same H-bridge setup we’ll be using for the valves. We’ll also be able to use the same basic position servoing algorithms that Dave is working on now for the valves. By switching to direct H-bridge control, we may see as much as an order of magnitude lower lag on our hinge actuation, while possibly doubling the slew rate. With less lag and faster slew, it should make controls a lot easier and more linear. With the throttle valve upgrades, we’re also hoping to see response lags several times faster than what we have right now. Between these two changes, I’m a lot more confident in us having a robust TVC setup.

Building Blocks
One of the keys I’ve noticed for awhile to Armadillo’s ability to rapidly field new vehicles is that they’ve had all of their basic building blocks in place for several years now. Before I had even met Dave and Pierce, they already had actuator control schemes similar to what they’re using right now. I’m sure they’ve improved it incrementally since then, but that basic solution has already been figured out and solved for a while. Same with the flight control systems. On our side, I can say that we’ve got a solid building block with our engines. While we intend to upgrade them over the next several iterations, our basic design has worked robustly, with excellent performance now for several years. While progress has appeared to be slow over the past few months, we’re finally getting to the point where I feel we will soon have good building blocks in place for our actuator systems, our vehicle computers, and hopefully our flight control systems as well. With those building blocks in place, we can focus on the last building block, which is getting much better in-house fabrication capabilities. As we get those in place, I expect to see progress accelerate greatly. It remains to be seen if we’ll get all of that wrapped up in time to compete this year in the Lunar Lander Challenge, but at least I know we’re getting on a much more solid technical footing and that Masten Space Systems is going to be in this for the long-haul.

Earlier this week I did my shortest investment pitch yet. The official length was 1 minute 40 seconds. This was part of an event in Atlanta called Startup Riot put on by the amazing Sanjay Parekh. Out of the 55 companies presenting, ours was one of the shortest. When pitching a space company you either end up very short or very long since explaining the details of the business generally requires non-trivial background material.

A little over a year ago we pitched at a New York Angels event and was limited to 5 minutes. In retrospect it would have been better to not try and cover ALL of the information possible in 5 minutes. Instead I should have slowed things down, even if it meant leaving a minute “on the table”.

For me this event was a particularly good one since it represents a growing community of entrepreneurs in the Atlanta area. Starting up any technology business can be a lonely and exhausting thing if you don’t have a support network of others who are going through the same thing. For the longest time Atlanta’s entrepreneurial community has been very disjointed and uncoordinated. Events such as Startup Riot, Startup Drinks, Startup Weekend, BarCamp Atlanta, and even Geeks and Guns (my little contribution) help create a sense of community and support that makes all of our jobs a tad bit easier and more enjoyable.

Just wanted to post a short note letting people know that we’ve now selected two interns for this summer, and therefore will no longer be taking applications for this summer. However, due to a surprising amount of interest in the possibility of internships for this Fall, we’ve decided to go ahead and offer two internship positions for the fall. We don’t yet have precise dates, but these would likely start sometime in August, and run through sometime in November, depending on when people are available. We will be releasing further information on these Fall internships in the coming days, including the deadline for submitting applications, when we’ll be running phone interviews, and when we’ll announce our internship selection.

April 2008 already. That means we have been around for four years and we’re still kicking. More importantly, we are still progressing. The coming year looks like it will be exciting. But before I get to what we are planning for next several months, let’s go back a few months to set the stage.

Back in June we started flight testing of XA-0.1. We found a lot of issues with the hardware and just how much of a pain multiple engines can be. I have developed a lot more respect for Russian rockets that use a lot of engines. For nearly six months we tried getting a controlled flight and we found lots of little subtle things that could make a big difference. In December this attempt at flight occurred:

XA-0.1 R.I.P.
After the crash we started taking a very close look at everything, and I mean everything. Not just the technical details, but our processes, staffing, and everything else. One of the things that we decided to change was the balance between analysis and build it, try it. We have always thought that NASA and the prime contractors concentrated too much on the analysis. We still think they over-analyze things, but we have shifted towards spending more time making sure things have a chance of working before we build it and try it. One of the things we did was set up a more accurate vehicle model and 6DoF simulator for getting a better handle on control laws and system interactions.

Once we set our course adjustments into motion we took another look at how to make XA-0.2 even better. We turned down the pressures required in the engines and tanks, and turned up the engine thrust. We found a new tank fabricator, and designed new engines. The XA-0.2 design lost weight and gained performance. Currently we are waiting for delivery of various long lead time components (like tanks!).

We are not just sitting around waiting for parts to come in. We have found a number of ways to improve various sub-systems and decided that we want to verify those on a flight vehicle before XA-0.2 is ready for them. So, let me introduce XA-0.1B

As you can tell, there are still some details missing, but enough of the important things for fit up are on there and we are cutting and welding the steel frame as I write this. And yes steel frame. It is strong and easy to work with. For XA-0.1B we do not care much about flight time or delta-v, we care about moments of inertia and the ability to control orientation and position.

To sum up, we have a lot of work ahead of us - building and testing XA-0.1B, testing a new engine, and building and testing XA-0.2.

Masten Space Systems will be out in force at Space Access ‘08 in Phoenix later this week. Almost everyone involved with the company will be there, and a number of us will be presenting:

• at 4:50 pm on Friday, Dave Masten will be giving the general Masten Space Systems update.
• at 8 pm on Friday, the Space Propellant Depots Panel will be led by Jon Goff
• at 8 pm on Thursday, our un-indicted co-conspirator Ian Kluft will be on the panel Paths to Rocket Piloting
• at 4 pm on Friday, I (Ben Brockert) will be giving a brief presentation on Students for the Exploration and Development
  of Space
• and, at 4:20 on Thursday, Ian Kluft will be talking about the Stratofox Aerospace Tracking Team.

It looks like it will be an interesting conference. Say hello if you’re there and you read this blog.

We’ll have an update here about MSS’s progress and future direction after we get back.

If you’re not bored with the igniter stuff yet, I think you will be by the end of this video. The igniter is not the only thing we’re working on, but I spent a day running it through qualification last week and it’s something I can share right now. It currently has 632 firings and 1578 seconds of cumulative fire time, and has shown the ability to operate correctly under a wide variety of operating conditions. It has officially passed its qualification testing and is ready to be used on the 750lb thrust engine.

Over the weekend I learned LabVIEW and wrote a virtual instrument to do data acquisition on the igniter cart, and calibrated the pressure transducers earlier this week. Today we ran the igniter three more times, so we can start dialing in the correct nozzle throat diameter and orifice sizes. As expected, the igniter chamber pressure is bit more than double the final desired value. Here are the promised Mach diamond photos. Still not as good as they should be, but you can kind of see the first glowing spot in the flames.

Run 2:

Run 3:

I haven’t insulated the pipes yet, and the humidity today in Mojave is an unusually high 32%. Even with an ambient temperature of over 70F (294 kelvin), uninsulated LOX pipes (at about -300F [90 kelvin]) grow frost:

I’m going to go drill out the nozzle now.

Edit: Drilled it out, ran it 9 more times, got a better photo:

The igniter is up to 14 runs and 35 seconds of flame time.

Masten Space Systems is looking for two technical interns for the summer of 2008. Working out of our Mojave, California facilities, you would be directly involved with a variety of interesting projects and would gain experience in working for an innovative space company. You must be a US national, and available for approximately three months from mid-May or early June through late August.

Projects you would be working on include testing state-of-the-art rocket engines, flight testing vertical take off/vertical landing rocket vehicles, fabricating and testing components for future projects, and evaluating new hardware concepts.

We are looking for people who have direct experience building, troubleshooting, and testing actual devices: people who know how to use tools and are not afraid to get their hands dirty. You do not have to have experience on a liquid fueled rocket engine, but we want people who have hardware experience, perhaps working on a car or plane, flying an amateur rocket project, or building a robot.

Specific applicable skills include:

• Mechanical assembly, especially of pressurized systems
• Machine shop skills, working with tools to make things out of metal or composites
• The ability to run an experiment, record data, and figure out what the data means
• Installing and wiring an electrical system, possibly including radio controls or computer programming
• Experience with Labview, Solidworks, and/or Matlab.

You don’t have to have all those skills, but having a variety is a plus. You must have a willingness to learn, pay attention to detail, be able to take initiative, and be open to working on a variety of different projects and experiences.

In addition, we have ongoing programs that involve rocket propulsion, mechanism design, electrical engineering, or wireless telemetry. If you have experience in one of those areas, we may assign you your own project where you will be responsible for the design and execution of a component or subsystem.

If you are interested in a fun summer, working on big rockets and unique vehicles, please send a resume to internships [at] masten-space.com. You are also welcome to send photos and/or a description of a past project you have worked on.

Masten Space Systems is a Mojave-based aerospace R&D startup that is working to create reliable and reusable rocket vehicles and components. Current company focus is on regeneratively cooled bipropellant rocket propulsion and fully reusable rocket-powered vertical takeoff and landing vehicles.

Hello, I’m Ben Brockert, the new technician and fabricator at Masten Space Systems. I started with MSS about three weeks ago. I’m originally from Iowa, where I was involved with the Iowa State Space Society and SEDS-USA. One of my major projects since I started here has been rebuilding the igniter testing cart.

The old cart had no liquid oxygen (LOX) handling capability, so we rebuilt the cart with a LOX tank in an insulated box (the LOX Box). It was built with room for expansion, so that we can easily adapt the cart for RCS engine testing in the future. The fuel side is pressurized with nitrogen and the LOX side is pressurized with helium, so this revision of the cart uses brazed joints on the LOX side to minimize leaks. Helium can get past normal joint sealing methods, the same way a sealed helium balloon will deflate after a few days. The new cart also has better containment of the test article for safety purposes.

Today we finished the last of the plumbing and ran the new igniter for the new engines. Though the new engines are 50% larger, the igniter itself is smaller and lighter than the old igniter. This represents the first hardware testing of the new engines. The LOX vaporizes in the plumbing upstream of the igniter, so the igniter runs on gaseous oxygen (GOX) and isopropyl alcohol (IPA), both at 400PSI. The flame is about six inches long and has a number of Mach diamonds in it. We’ll get photos showing them in the next week.

This is the first run. For scale, the extruded aluminum “X”s that the igniter is mounted on are one inch square.

Here is the second run. Since the igniter body has a significantly smaller thermal mass than the old design, we’ll have to be careful not to overtemp it when running it outside the engine. In a normal engine cycle, it would only need to run half as long, and would be actively cooled. It wouldn’t normally glow.

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:

1. Build a subscale vehicle using smaller engines with much faster actuators and a more symmetrical vehicle arrangement with an inline tank configuration.
2. 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.
3. 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.

XA-0.1 died during flight testing last Thursday.

The vehicle lifted off and appeared to be under control - not very good control mind you - but the control system was trying to do the right things at the right time for a bit. It climbed to about 20′ AGL when I concluded that the control wasn’t right and shut down the engines. The vehicle then fell, either hitting the tether limit or the vehicle landing gear clipping the edge of the pad. The structure broke off between the electronics bay and the rest of the vehicle. The tanks and propulsion section hit the ground, broke an engine mounting structure and broke one of the landing gear. The electronics bay was still swinging from the tether. Here is what the scene looked like as the dust cloud moved out of the way.

Note the fire on the left. This was a small bit of isopropyl alcohol that got spit out when the propellant tanks were vented.

The safety systems were flawless. The vehicle was completely depressurized and safe to approach in a matter of seconds. We of course waited minutes to make absolutely sure, but that was the other safety systems working well.

We are considering various options for moving forward. In a way the death of XA-0.1 is a relief, as it had some issues. The two options that are favored right now are either finishing XA-0.2 or building another low performance vehicle from the surviving parts. XA-0.2 is already designed and being built, but I think it is a higher risk for being damaged in flight test. Another low performance vehicle could be built fairly quickly, fix some of the known issues that we had with XA-0.1, but we’d still have to deal with the issues that we couldn’t fix.

Wow. It has been over a month since we’ve posted anything. In the last month or so we have been regrouping and re-prioritizing. We have done several more tethered flight tests, been through a few iterations of controls code, started doing hardware in the loop simulations with the control computer, and made some more progress on building XA-0.2.

The problem with not posting updates for a while is that a lot of folks start guessing about what is going on, and the guesses are diverging rapidly from reality. So here is what all has happened since the last post.

We had outside experts do a technical review of the XA-0.2 design. The outcome was that it wasn’t perfect but it was workable and should be competitive for the NG-LLC. We got really good feedback on how to make it even better. The really good thing was that most of the concerns raised were things that we were already aware of. So, if we can get some good tanks XA-0.2 should be a good flyer. Oh, and one of the reviewers said he could fly the vehicle with one engine out using his control code, it is ugly, but it can be done.

Speaking of control code - a few people have suggested that we made a mistake outsourcing our control code. First - none of us at MSS know controls theory beyond the simplest classical control algorithms. Now we could have hired someone to be our controls engineer - and we’d have only one person who had any clue. By outsourcing we can get a team of competent engineers and therefore if one person is sick, injured, or whatever we aren’t stuck. All in all, Frontier has been pretty good. There were some issues with specifications and vehicle characterization, and that led to doing a bunch of tests where things just could not work. As we worked through the issues, Frontier has been responsive and the latest revision looks good in ground tests and basic simulation.

On to flight testing - we have had the latest control code version for about a month now, but XA-0.1 is our first prototype, so it has a few more maintenance issues than a more mature vehicle would have. We have spent the last month or so hammering on every single squawk recorded over the last several tests, and several more squawks discovered while fixing the others. I thought we would do a flight test last week, but there were a few more issues than we expected. Hopefully, we can get back to flight testing this week.

I should note that we are downright abusive with rocket engines. Over 2 hours of run-time and 700 ignitions over the past two plus years on one design. The engines have run in nice weather, rain, sleet, and dust storms with hurricane force winds. Ambient temperatures during runs have ranged from 27 deg F to over 110 deg F. All of the engines now on the vehicle have been damaged in testing, re-worked and put back into operation, some of the engines more than once. These engines do require a bit more maintenance than we like, but that is as much a matter that they are prototypes not production versions. We hope to be in a position to do a revision of the engines Real Soon(tm).

The past month has been a very busy one at Masten Space Systems. As Ian mentioned in a previous post, the timeline for getting XA-0.2 built, debugged, and flying in time for the X-Prize is fairly tight. While we designed in a little bit of slack to deal with minor delays, we unfortunately ran into a more serious delay that is going to preclude us from competing in the X-Prize Cup this year. We were informed late last week by the company spinning and welding the propellant tanks for XA-0.2, that the tanks had failed their hydrotest by a very large margin. The tanks failed right on the weld at less than half of the designed operating pressure, and it appears that a poor weld with incomplete penetration was the culprit.

Unfortunately by this time, this particular supplier was also nearly three weeks behind schedule, so there isn’t any feasible way we can have a backup plan ready to go in time for the competition.

We’ve started work on another set of tanks, using a different set of manufacturers, to allow us to complete XA-0.2 for further development testing.

We have been making an effort to post more pictures and media lately, but have not been putting up a whole lot of technical info to explain what some of the stuff is, and where we are in our progress.

So, I intend to rectify that with this post.

The basic situation is as follows: We are currently tether-testing XA-0.1 and in parallel, we are building XA-0.2.

The status with XA-0.1 is that we have all basic systems working, and have narrowed down our lack of ability to attain stable flight to the control system. We have identified what we think is the major culprit and have made a change to correct it. We will be testing that shortly, if not today.

At the risk of sounding like another NewSpace company making claims about progress based on apparently failed tests, I will say that XA 0.1 has already accomplished most of it’s goals. It is easy to forget (and we do it, too) that XA 0.1 was only designed to test several basic things, among which are:

1.) The integration of our engine systems with a third party control system.
2.) The integration of our engines with our TVC system.
3.) The design of a vehicle propellant and pressurant system.
4.) The control of vehicle propellant and pressurant systems.
4.) Pilot interface systems.
5.) Vehicle based operations, as opposed to test-stand based operations.
6.) Fundamental architecture validation.
7.) Tethered hover.

It has, thusfar, succeed in all except #7. Of course, #7 is a pretty important one and one that we would all like to see - and soon, but it is important to remember that this vehicle has accomplished the majority of what it was designed for already. Those lessons and validations have been applied to the design and development of XA-0.2.

As we make changes to the control system, we expect to accomplish #7 within the next several weeks. Providing we can do so, we are still on track for XA-0.2 being ready for the X-prize cup this year.

Regarding XA-0.2, we are on schedule with it’s construction. By the time we’re done with all of the flight testing currently planned for XA-0.1, XA-0.2 will be sufficiently assembled to allow us to swap over the propulsion and controls systems with minimal delays.

In brief, XA-0.2 is a natural progression from XA-0.1. Utilizing a lightweight frame, larger propellant tanks, and lightweight pressurization system it is a much higher performance vehicle. The dry weight of XA-0.2 is within 100 lbs of XA-0.1, but is capable of 5x the propellant load (resulting in a 100% propellant load mass ratio of 2.5) . It uses legacy electronics and propulsion hardware to facilitate a rapid transition from XA-0.1 to XA-0.2 flight testing. Among other details, it has a more favorable inertia matrix allowing easier control as compared to it’s predecessor. This combined with the legacy hardware gives us confidence in our ability to get XA-0.2 operational within a short period of time following initial success of XA-0.1.

The XA-0.2 vehicle will be capable of approximately a 50% propellant load with legacy propulsion hardware. Further evolution of the vehicle past X-prize cup will include a 50% increase in engine thrust in order to utilize 100% propellant load for increased delta-v. This vehicle architecture will proceed through the next several iterations of the XA line, further expanding the flight and performance envelope until the architecture is no longer viable. At this point I should define architecture to mean a basic vehicle platform. Expanding the performance envelope within a given architecture would mean upgrading components without overhauling or re-designing the entire vehicle. An example would be, with XA-0.2, we can upgrade the propellant tank diameter without changing any fundamental components. This allows us to increase delta-v on an already functional vehicle without a complete re-design. While the XA-0.2 architecture is capable of enough delta-v to reach nearly 100 km, it lacks provisions for other components (specifically aerodynamic surfaces, retractable landing gear) necessary to do high altitude, high velocity flights.

If we can avoid any serious setbacks in our schedule (late vendors, accidents, etc), we will have XA-0.2 ready for competition at the X-prize cup this year. I’m not going to release our development schedule, but the time alloted for the various tasks necessary is not overly aggressive and I think gives us a high chance of success. Of course, if one of the companies manufacturing a key component decides to take 6 weeks instead of 2, for example, it will impede us significantly - however, we are being proactive about these issues and are doing everything we can to prevent delays.

And of course, a few more pictures.

One of two “fuselage” sections assembled. Weighs 33 lbs and is pretty strong…

Diamond Kevin and A+ Aaron are getting the landing gear all sorted out, and its corresponding test rig.

Just in time for my birthday…

For all of you who have been wondering what’s going on - and why things are so quiet as of late…

We have two things going on. The first is that our vehicle’s frame was breaking, badly. We decided to take the time and tear it apart and replace a lot of the aluminum members with steel. The 80-20 bolted together extrusion we used was just a poor choice and it could not handle the loads the tether was subjecting it to.

So we replaced a lot of the bolted AL with welded steel. Should be much better now.

On the more rocket-related side, we have been pouring over the data we gathered in the last few weeks trying to figure out why it won’t really fly. We think we have it now - and are taking steps to correct it. I has to do with how the control system is interfacing with the pilot.

So, as soon as we get that changed and fully tested, we will be back at it. We are hoping for good things.

Stay tuned…

Nothing really amazing here.

Just sneaking up on how high the liftoff throttle has to be. As you can see, we didn’t figure it out in any of these tests.

5 tests in a day tho, I think thats pretty good.

We discovered that it helps if your hinges are moving the way you think they are moving them. 180* out tends to cause big problems - like the vehicle inexplicably flying off the stand and stuff.

So after fixing that, we were able to do this:

Lit all 4 engines, and it just sat there. Like you think it should.

Had to shut it down before liftoff because of the IPA fire you can see. Small leak on one of the engines that we are fixing right now.

More to follow tonight, I hope.

I hope everyone had a safe and happy 4th of july. We tried to make fireworks, so to speak - but had a small IPA leak that caused us to scrub.

A brief update about where we are - we are starting to gather data on the control system in order to figure out why it’s not flying the vehicle. In the process, we noticed that one of our LOX valves was out of calibration, causing late starts on one of the engines.

We fixed that, and hoped to test yesterday but were stopped by the IPA leak. Now that we are into the holiday weekend - progress will slow down slightly. Not sure if I will have enough staff on hand today to test safely.

Well, yesterday (Friday) wrapped up our first week of tether testing. No, we aren’t flying yet (it just so happens no one in our company is named superman.) We are however, making steady progress. I would like to list the top 10 things WE think are significant victories.

Fundamental Victories:

1.) We haven’t destroyed our vehicle. Gotta start somewhere, right? Those first few unrestrained tests had a significant pucker factor. (did we size the tether right, etc)
2.) We haven’t had any engine failures. These are rocket engines - and this is always in the back of my mind. We haven’t had a credible system failure in a LONG time (and we rectified the cause of it) but it still makes me nervous.
3.) We have reliable ignition (when WE actually use the system right). Testing 4 engines at a time rapidly stacks up the number of attempted ignition events, and will expose bugs or inconstancies in those systems very quickly.
4.) All 4 engines are capable of working together, without any feed system coupling issues or anything else. The 4 engine architecture with simple feed system is not fundamentally flawed.

Less basic:

5.) We worked out some timing issues to allow a consistent 4 engine ignition.
6.) The engines are throttling as commanded
7.) The hinges are moving as commanded
8.) The vehicle is fundamentally stable. What I mean by this is we now have it to the point where merely igniting the engines does not result in a loss of control. Now, without any command inputs - it will just sit there cooking.
9.) The ACS system is fundamentally correct. It’s sense of direction and what to do about it correlates with the real world.
10.) We are back to testing and development - not troubleshooting and fabrication. The Test - Analyze - Adjust - Test cycle is one that we are pretty good at, and is so much more mentally stimulating than leak checking 2 billion AN fittings. I expect rapid progress up until our next impasse.

I have more test video from Friday, but it really just looks like the other videos. We light the engines, and it kinda shuffles around and falls off our stand. The big thing on Friday was the ACS actually over corrected for a rotation about the Y axis and actively de-hovered the vehicle, so to speak. The negative X engine started to dip early into the hover (and when I say hover, I am talking 10ths of seconds, so nothing “real”), and it throttled it up way too much, tipping the vehicle over about the Y axis and pushing the positive X engine down. An induced loss of control. At that point it hit the tether and it was all over.

So we’ve got some control system tuning to do it looks like, possibly coupled with some engine throttle tuning to make sure we aren’t giving more thrust than asked for. Monday will start another week and another phase in our vehicle testing. I’d call it phase three.

Phase One: Fundamental vehicle troubleshooting and functionality testing

Phase Two: Reliable engine ignition and fundamental stability tuning

Phase Three: Flight control system tuning and flight stability tuning

Phase Four: Engine performance tuning, envelope expansion

So, here’s hoping. On the plus side - almost all the parts of XA-0.2 have now been ordered, and assuming we can get this vehicle flying properly in the next two months, we are on schedule for the LLC this year.