[Editor’s Note: I was recently pinged by a friend on NASASpaceFlight.com about an “UnCrasher” lunar lander architecture concept I had written about a few years ago. I went to point him to a blog post on the idea, when I found that I never actually got around to writing it up officially. So, I found some time over the weekend to start some spreadsheets to refresh my memory on the concept (and to explore it a bit more rigorously), and decided now was as good a time as any to write it up.]
What In the World is an “UnCrasher” Stage?
What I’m calling an “UnCrasher” architecture is a semi-reusable two-stage approach for delivering payloads to the lunar surface from a lunar orbital rendezvous point or a facility/depot, either in lunar orbit or at one of the Earth-Moon Lagrange points. The system consists of three parts: the lunar surface payload, the lander, and the reusable “UnCrasher Stage”. The UnCrasher Stage would be a lightly modified high-performance upper stage (basically a Centaur or DCSS upper stage with some kits added to them) that would propel the lander and payload from the starting assembly point to lunar orbit, and then would perform a significant fraction of the descent burns to slow the lander and payload down from lunar orbital velocities. Staging could occur with as little as say 200m/s of delta-V left for the landing. After staging, the lander would continue on to the lunar surface, and the UnCrasher would relight, and perform a boostback maneuver to accelerate itself first back into lunar orbit, and then maneuver from there back to the starting point in preparation for future missions.
The name “UnCrasher” is basically a play on “Crasher” stages, which have been proposed in the past, but which expend their deorbit stage immediately after separation, letting it crash safely into the lunar surface at some significant distance downrange of the landing target. One way of thinking about it is that the UnCrasher concept is basically a lunar version of what Elon’s trying to do with the F9R first stage, but in many ways it’s even simpler, and should be even more amenable to low-maintenance gas-and-go reuse. Unlike a reusable earth-to-orbit launcher first stage, the UnCrasher never has to fly through an atmosphere supersonically, and doesn’t get exposed to dust or debris kicked up from landing plumes. Plus, in-space stages can use much more benign rocket combustion cycles like the Expander Cycle used on the RL-10. In many ways when you think about all the architectural elements you’d likely have in a Cis-Lunar transportation network, the UnCrasher stage will probably be the easiest one to reuse.
Genesis of the UnCrasher Architecture Concept
To be honest, I don’t have great documentation on the circumstances in which I invented this concept, and like most good concepts in aerospace, I’m probably not the only one to independently invent the idea. But I think the genesis came from debates with DIRECT supporters who at the time were claiming that you needed a launcher with a much bigger Payload Fairing than the ones flying on EELVs in order to do significant lunar landing missions. ULA had already proposed their Dual Thrust-Axis Lander concept (which Masten is now working with them to prototype, under the name “XEUS”), which would have placed a series of landing thrusters and legs mounted on the side of a Centaur stage, enabling it to land horizontally after the Centaur main propulsion system had done most of the braking from Lunar Orbit. I had also seen several concepts for “Crasher” architectures over the years. This was also right around the time that Masten and XCOR signed an MOU to jointly market a LOX/Methane lunar lander. I don’t think they ever found any serious customers, but at the time I was investigating a wide range of different ideas. I wanted something that could enable reuse of in-space elements, and that could minimize the development costs of unique elements in the architecture–the more you could repurpose a flight-proven system like Centaur or DCSS, the less development cost it would take to get you to an actual lander capability. Some day I may dig up some old notes that provide a better backstory, but that should do for now.
UnCrasher Performance Analysis/Methodology
As I said in the Editor’s Note up front, I decided to do some spreadsheets to get a better idea of how such an UnCrasher would perform. I’m pretty sure I ran the numbers on this idea on a less detailed basis a few years ago when I first came up with the idea, but I couldn’t find the files anymore, so I started from scratch. In my second, and more useful, spreadsheet, I did an analysis of an IML2-constrained UnCrasher architecture. If you’re morbidly curious enough to want to follow-along, here’s a link to a copy of the spreadsheet.
Here’s a quick overview of my methodology:
- I started with some high-level stats on the Centaur-based UnCrasher stage. In addition to the actual dry mass of the Single-Engine Centaur, I added about 450kg of “kits” to cover things like an Integral Vehicle Fluids system, long-duration passive insulation, a multi-use resettable separation system, a few small Sticky Booms™ to bring things together, long-range comms, etc. I wasn’t trying to go for super-high fidelity, but more to gain a decent first-pass understanding of how the system behaves. This analysis can be used as a starting point for more detailed analyses later–I just wanted to see if the idea was worth anything.
- I also created some high-level parameters for the lander. I assumed a LOX/CH4 propulsion system with a 360s Isp, and a 80% pmf for the lander–ie of the non-payload part of the landing system, 80% of the remaining mass was propellant and 20% was structure. This is a tiny bit better than the Apollo LEM Descent Stage, but a number I figured was realistic.
- I assumed that the total required Delta-V from L2 to the lunar surface was 2600m/s. This is only an approximation though, which depends a ton on how fast of a transit you want to do, what your T/W ratio is at various points, etc. To do this analysis for real you’d likely want to use at least a 3DOF simulator, but for this time around I decided to use the “cookbook” values.
- For the actual analysis section, I created several rows, each with a given “marginal Initial Mass in L2” (mIML2) which included all the marginal mass you would need to do a given cargo mission, including the UnCrasher propellant, the lander and its propellant, and the payload. I didn’t include the dry mass of the UnCrasher, because it would be reused several times.
- I then guessed an optimal “assist Delta-V” for the UnCrasher stage for each mIML2 row. This assist Delta-V is the portion of the ~2600m/s from EML-2 to the lunar surface that would be provided by the UnCrasher. This also happens to be the amount of Delta-V the UnCrasher needs to provide post-staging to boost itself back to EML-2. This term was the variable which would be adjusted to optimize the payload performance to the lunar surface.
- I then calculated for each row how much UnCrasher propellant would be needed for each of those two trip-legs. The descent leg is a function of the UnCrasher dry mass, the mIML2, and the UnCrasher assist Delta-V and Isp. The ascent leg is a function of the UnCrasher dry mass, and the assist Delta-V and Isp.
- Once I knew how much of the mIML2 for each row was tied-up in the UnCrasher propellant, I subtracted that from the mIML2 to calculate how much mass was left for the lander and payload.
- I took the total lander/payload gross mass, and the remaining Delta-V required for the lander, and used them to calculate how much lander propellant was needed to perform the landing maneuver. I then used the pmf to calculate the lander dry mass.
- Payload was what was left after accounting for the UnCrasher propellant, and the lander propellant and dry mass.
- I then iterated on the assist Delta-V for each row until I had maximized the lander payload. [Note (9:37MDT 9/4/2013): After publishing this, I finally figured out how to activate the Solver function in Excel–much easier, and should enable multi-variable optimizations.]
As you can see, this was a pretty simplistic analysis, but good for getting a high-level overview of system behavior. One of these days I’ll need to relearn Matlab well enough to use it for analyses like these, as the manual iterations on the assist Delta-V column was a royal pain in the neck. Or, I could have done all the math algebraically to come up with the landed payload with the assist Delta-V as the variable, and then taken the first derivative of that equation and solved for the zero points. But I didn’t have a whiteboard handy, and the spreadsheet was quicker for me than trying to set something fancier up.
So, what did I learn? Quite a bit actually.
Surprising Result #1: Optimal Assist Delta-V vs. mIML2 Regimes
I figured a priori that there would probably be three regimes once I ran this and charted the results. I figured the first regime (starting with the smallest mIML2) would start out with the optimal assist Delta-V at some relatively low but non-zero number, which would ramp up gradually with mIML2. The second regime would be when the optimal assist Delta-V hit some arbitrary maximum value–I picked 2400m/s, which would leave only 200m/s for the lander itself. Then I figured there would be a third regime that would kick in once a full UnCrasher propellant load could no longer deliver 2400m/s of assist Delta-V to the lander and payload.
It turns out there were four regimes, as can be seen from this chart:
In addition to the three regimes I predicted, there was a fourth regime that existed below approximately 4700kg mIML2 (for this set of UnCrasher and lander parameters). Below this threshold, it turned out that the optimal assist Delta-V was zero–ie using a Centaur-sized UnCrasher to provide any Delta-V actually decreased the payload to the lunar surface. I’m not 100% sure I understand why this is, but my guess is it has something to do with the fact that when you have say 2000kg of mIML2, spending any of it to accelerate and decelerate the ~2700kg Centaur stage just didn’t provide any benefit.
Two other things to point out–the transition between regime 2 and 3 was at ~32500kg mIML2, and the transition from regime 3 to regime 4 (the point where assist delta-V was Centaur prop-load limited) was at about 42500kg.
Surprising Result #2: Payload Benefit of an UnCrasher
The second analysis I did was to analyze for each mIML2 point what the payload of a single stage LOX/CH4 lander would be if no UnCrasher stage was used. This allows us to compare how useful the UnCrasher stage is compared to just having a lander fly from EML-2.
The results were non-trivial, but more modest than I would’ve thought–the maximum benefit was around 36%, and over most of the range it was closer to 30%. Nothing to sneeze at, mind you! But not some big multiplier:
The biggest benefits were in the regime where the UnCrasher was providing the max 2400m/s of assist delta-V.
Surprising Result #3: Lander Dry Mass Benefit of the UnCrasher
With the previous result being positive, but not particularly overwhelming, I was curious if the UnCrasher gave much of a benefit in lander dry mass compared to the previously mentioned single-stage lander without an UnCrasher. Dry mass is often a good figure of merit for both the cost of developing a system, and the cost of producing one. Also, since I used the same pmf for all the landers, the propellant also scaled linearly with the dry mass.
A couple things to notice:
- For the single stage lander, the dry mass is a linear function of mIML2. This isn’t particularly surprising.
- In all three regimes where the UnCrasher is net-useful, the dry mass of the lander is drastically lower than that of the single-stage lander. The most extreme case being in regime 3, where the UnCrasher-assisted lander masses only 5% (!!!) of the mass of the single-stage lander.
- The lander mass actually starts decreasing in regime 2 and 3 compared to the high end of the first regime (where the UnCrasher didn’t improve the landed payload).
- At the transition point between regime 2 and 3 (where the assist Delta-V was “saturated” at 2400m/s), the lander dry mass for a 14.7 tonne payload is only 220kg. (!!!)
- At the transition point between regime 3 and 4 (the point where the UnCrasher stage is now fully-loaded), the lander dry mass for a 20 tonne payload is only about 300kg.
- My guess is that in these most extreme cases, the lander pmf model probably breaks down, and may need a payload-mass driven term to account for structure. But even then this is pretty impressive.
The reason for this behavior is pretty clear–as the UnCrasher stage kicks in, it lowers the delta-V the lander needs to provide to as little as 200m/s. That’s just not a lot of propulsion system that you need at that point. In fact, the right approach may be to take the payload, and just have attachment points for landing-gear/propulsion modules at four corners (sort of like DTAL, but with the payload instead of the Centaur becoming the backbone). Would definitely make it a lot easier to get cargo unloaded without having a multi-story lander parked underneath the payload… It’s also worth noting that the landed payload is likely not very sensitive to the lander pmf at this point. Even if the lander pmf dropped to 20% instead of 80%, that would only cut into the delivered payload by about 20%ish.
Basically using an UnCrasher (or Crasher) approach enables the actual lunar lander to be a lot lighter and smaller than would be possible using other approaches. 220kg dry mass (with 880kg prop) is actually really close to the dry and wet masses of the LOX/CH4 SuperMods that Armadillo Aerospace was flying a few years back. Because the payload isn’t very dry-mass sensitive, this indicates that at least for one-way cargo landers, an UnCrasher approach may enable low-cost firms like the Masten/XCOR teams of the world to deliver useable lunar landers. I’d love to see a Masten/XCOR XEUS derivative that could land an ISS module on the lunar surface…
And yes, before someone asks, you could do just about as well with storables. Heck, the UnCrasher does enough of the lifting that you could probably do monoprop peroxide for the lander. This was a really interesting finding for me, though I’d love to have someone check my math.
One Last Observation: Altair LSAM Comparison
One other fun observation I noticed around 1am last night while finishing up this analysis. At the point of minimum lander dry mass (32500kg of mIML2), the payload on the surface is 14.75 tonnes. This is almost identical to the planned cargo landing capacity of the Altair Lunar Surface Access Module that was part of the cancelled Constellation program. Out of curiosity, I backed out an estimate for the net TLI injection mass for that much mIML2 (I feared it might be a lot more than cargo LSAM’s ~49tonnes). My BOTE gave me around 37 tonnes, or about 75% of the TLI injection requirement for LSAM. So not only does it lower the cargo lander size down to something that a small company could realistically build for non billions of dollars, but it’s also significantly more efficient in terms of TLI injection mass (and hence Initial Mass in LEO–IMLEO). Admittedly, the error bars on this calculation are bigger. You’d really need to do a more detailed architectural analysis than I want to do for free to know for sure. But this approach looks really promising.
I can see three fruitful next steps for analysis:
- Running an analysis for an UnCrasher dropping off a lander that goes down to the surface, and then returns itself to EML-2 (ie something like what a manned lander would do). It’d be interesting to see if the regimes shift around with that, and how payloads compare vs. say a two-stage LOX/CH4 lander that stages on the lunar surface like the old LEM did.
- Running an analysis that combined an UnCrasher drop-off, and an UnCrasher pickup on the way back to EML-2 (possibly even “suborbitally”). My gut says that an UnCrasher pickup *might* help. Might be worth running two analyses–one that has the UnCrasher carry all of the propellant for all four of its legs from the start. And another where it leaves the pickup legs’ propellant at the EML-2 depot until it gets back from the dropoff mission. This one will be tricky as it’s likely a multi-variable optimization. Might require relearning Matlab a bit.
- Running a more detailed analysis on the transportation network between LEO and EML-2, including boiloff losses, more accurate masses for the various “kits” needed, etc. This would provide a more end-to-end architecture analysis that would allow you to show how badly this would thrash traditional approaches both on development and operations costs.
[Update 11:35pm MDT 9/4/13: Here’s an updated spreadsheet now that I figured out how to activate this version of Excel’s solver function. I’ve added a new worksheet (here) for Crasher cargo landers, and updated all three charts to add a comparison between Crashers and UnCrashers. Big takeaways are that Crashers have a wider “sweet spot” of maximum available assist Delta-V, and have slightly better performance than UnCrashers, but only about 5-10%ish. I could definitely see using them in certain circumstances like when you have an UnCrasher that’s ready for retirement, or when you really need that last little bit of payload margin. One other takeaway is that I really need to come up with a good way of capturing the non-propellants-driven portion of a lander’s dry mass, because I’m pretty sure that’s going to dominate during the “regime 3” area of maximum UnCrasher assist Delta-V.]