Lunar Hoverslam

I suggested in the middle of a couple of recent posts that the hoverslam techniques pioneered by SpaceX with the Falcon9 be used for Lunar landings. It was a kind of throwaway thought along with several other suggestions. As I think about it though, it seems to me that there might be a serious possible schedule and reliability gain from adapting the technique to Lunar development. That’s why I’m putting it up as a separate post.

I didn’t think hoverslam was a viable technique until it had been demonstrated. I was wrong. Now that it has been demonstrated multiple times, it may be time to see if there are more applications in which it might give an advantage. Lunar landings being the application under discussion recently, I want to lay out a few possibilities.

First thing would be a discussion with the team that is already using the technique in operational vehicles. From the outside looking in, it appears that hoverslam is a software solution to landings that was previously considered a hardware development problem. If this thought is accurate, then it may not be necessary to develop engines and control systems that allow an empty tank vehicle to hover in 1/6 gee. It seems that it is a requirement to bring velocity to zero at the instant that altitude is zero with thrust/weight being far less relevant than most of us previously thought possible. It seems that the SpaceX team is landing with thrust/weight levels of well over two on Earth, which would be well over a dozen at the Lunar surface.

If a Lunar lander is at 20 tons at touchdown, then the hovering that most of us consider a requirement would need engines capable of throttling to  3 tons for a gentle descent at very low velocities. The experience of Apollo 11 finding a clear landing area validates this opinion. This is however, not 1969. The Lunar surface is not only far better known now, but any potential landing sites could be imaged to near centimeter precision at relatively low cost. So hovering while making sure of a clear landing zone may not be a requirement. Navigation to the clear areas is also much less of a challenge than a half century ago. So it may be possible to go straight in to a site on near side without even orbiting first. It may be possible to land that 20 ton vehicle with engines that will only throttle down to 50 or 60 tons.

Doug believes that getting funding authorities to sign off on Lunar hoverslam would be a nonstarter. He is right unless the technique is fully validated just as it was on Earth/barge. I suggest the first step would be an RFI to SpaceX to confirm that it would or would not be possible to use the technique in this manner. If the answer is affirmative, then a test mission could be envisioned. For a test mission, perhaps an upper stage of the Falcon9 could be refueled by a Facon9 tanker in Earth orbit to validate tanker technology as well before sending it on to the Lunar surface.

The Falcon9 upper stage with one refueling should be able to place well over 5 tons on the Lunar surface during the test mission if the concept is valid. Depending on the flight backlog and the interest of both NASA and SpaceX, this could fly by Q4 2018. I doubt any other system could land a comparable payload in anything close to that time frame regardless of interest. Cost would be for two Falcon9s plus payload and Lunar operations. 5 tons in useable condition on the Lunar surface would go a long way towards convincing a funding authority to further use the technique for unmanned payloads.

Central to acceptance of the concept would be the failure modes. Obviously a high enough speed impact would destroy the stage and cargo. Hitting a rock with a landing leg and tipping over could be almost eliminated with a good survey and navigation. A sideways vector on landing that tipped the stage over should not be a factor with the current experience level. The most likely failure modes would seem to be engine failure at altitude from fuel depletion, and excess velocity at touchdown from software or navigation error.

Payloads on the first flight(s) should be very robust as well as being useful so that good work can be done even with a less than successful landing. During an excessive velocity landing, the stage propellant tanks provide a crumple zone if done right. An impact at 100 m/s (200 mph) in the vertical orientation could subject the payload to under 10 gees which is survivable to most hardware. It should be expected that the first payload may have to cut its’ way out of the wreckage before deploying solar panels and starting the primary mission. If the stage soft lands but with a side component that tips it over in the 1/6 gee, the payload should also see less than 10 gees.

The spectacular failures we saw from the early Falcon9 barging attempts were almost all from residual propellant exploding. Though technically not detonations, the burns were fast enough that most of us would call it a good boom. The vertical and horizontal vectors on most of the early Falcon9 barging attempts would have been payload survivable without the propellant reactions on impact. In the vacuum at the Lunar surface there would be no reaction from residual propellants in a crash other than fast evaporation and site contamination. All of those spectacular RUDs on the barge would have been stage lost and payload delivered on the Lunar surface.

I suggest that this concept be considered at some low level to see if there is any merit to it. If there is, it could speed up Lunar development by several years and save a few Dirksens.

The following two tabs change content below.
johnhare

johnhare

I do construction for a living and aerospace as an occasional hobby. I am an inventor and a bit of an entrepreneur. I've been self employed since the 1980s and working in concrete since the 1970s. When I grow up, I want to work with rockets and spacecraft. I did a stupid rocket trick a few decades back and decided not to try another hot fire without adult supervision. Haven't located much of that as we are all big kids when working with our passions.
johnhare

Latest posts by johnhare (see all)

This entry was posted in Uncategorized. Bookmark the permalink.

25 Responses to Lunar Hoverslam

  1. Egad says:

    Is it known what F9 uses for an altimeter? Do they do everything with augmented GPS, or is there a radar or other supplementary altimeter?

  2. jccooper says:

    F9 has radar altimeter and GPS and probably also involves some INS. The landing pads were recently coated with an iron-bearing paint (you can see the rust colored clouds kicked up in recent landings) to make the radar altimeter work better.

  3. Andrew Swallow says:

    Within 3 years Lunar CATALYST will have supplied NASA with a choice of lunar landers. As a proof of concept NASA could buy one and reprogram it to perform a Lunar hoverslam. The small lander would be at TRL 9 and applying the hoverslam landing procedure to a large lander at TRL 5/6.

  4. peterh says:

    With the ability to throttle to T/W less than 1 you have some luxury in last second adjustments in landing point. With a hover-slam landing you need to know coming in that you have a good landing point, and =exactly= where you are relative to it. I don’t see how that would be possible without a prepared and precisely mapped landing point, ideally with navigation beacons. So not a viable option for a first landing on the moon. But potentially attractive for later visits to a site that a earlier crew has prepared.

  5. Bob Steinke says:

    I’m beginning to wonder about what the purpose and benefit of hoverslam would be in this context. I can see three reasons to do a hoverslam:

    1) You have an existing system that can’t throttle below T/W of 1.

    This is the situation that SpaceX found themselves in, and they made it work. If we want to get a jump on things by using some existing stages, then ok, but if we are designing new stages this isn’t a constraint.

    2) It’s harder to develop a propulsion system that can throttle so low.

    Based on the experience of Armadillo and Masten, I’m not sure this is true. Being in vacuum where you can never be overexpanded makes it even easier. And if you design for this from the start you can create system flexibility such as multiple combustion chambers that you can turn some off.

    3) Minimize gravity losses

    Hoverslam does minimize gravity losses by reducing the amount of time you spend thrusting, but on the moon, gravity losses are just 1.6 m/s^2. If you hover for 30 seconds, that’s 50 m/s. Not too much added on to the 1600 m/s delta-v from lunar orbit. If you top up on LOX/LH2 propellant (Ve 4400 m/s) from a depot in lunar orbit your mass ratio goes from 1.44 to 1.46. If you develop a lander with deep throttling, you can still do a hoverslam landing if you need that extra slice of performance for one particular payload while keeping more safety margin for most payloads.

    If you want to do a crash program with existing stages you shouldn’t let T/W greater than 1 deter you, but if you are designing new stages I don’t see any reason not to make them capable of throttling below T/W of 1. Then hoverslam is a solution in search of a problem.

  6. TheRadicalModerate says:

    This is ultimately a control problem. Your structural guys give you a survivable maximum velocity for your vehicle, and the control system has to produce a solution that stays within that velocity envelope at a particular point in space.

    That requires being able to bound the error of the eighteen degrees of freedom associated with the vehicle’s translational and rotational position, velocity, and acceleration. On Earth, the sources of error are considerably different from those on the Moon.

    1) Radar altimetry yields only an average value for the z-axis distance and speed. The smoother the surface, the more accurate the values. On Earth, the surfaces are pretty close to perfectly smooth, although a barge landing has a “roughness” associated with the pitching of the deck. (I suspect that the ASDS can send information about the pitching to the vehicle to null most of this out.) On the Moon, the roughness of the landing site could be significant, leading to errors in both z-axis position and velocity.

    2) The x and y components of position and velocity on Earth can be determined via some combination of inertial, optical, GPS, and fixed beacons surrounding the landing area. On the Moon, they can only be determined inertially and optically, and dust at touchdown will make the latter difficult.

    3) Finally, there’s the error associated with the throttling outputs, which in turn lead to acceleration errors. A given z-axis thrust error results in a larger acceleration error in lower gravity, and the error will become even worse as the thrust drops.

    Ultimately, it’s the accumulation of these errors that dictates whether you can hoverslam on the Moon. They dictate the possible range of velocities at which you can reach the surface. Remember: gravity may be lower, but inertia isn’t. The buckling force for a given vehicle is determined solely by how fast it hits the ground, not how much the wreckage weighs when it finally comes to rest.

  7. johnhare john hare says:

    Bob, I think you nailed it pretty well. I see it as mostly #1 with some possible #2 or new systems. I see it as having some possibility to “run what you brung” instead of endless development cycles to target a particular capability. If software could get a Centaur or Antares stage on the ground with payload intact NOW instead of whenever, then there could be a significant advance of the timetables.

    TRM, it would be fairly easy to set up site reflectors, transponders and such. Delivery could be on precursor vehicles learning the unaided technique for use on unimproved sites.

  8. TheRadicalModerate says:

    John, prepared landing sites make perfectly good sense for non-exploration missions (e.g. to a base that’s being built up), but they seem kinda weird if you’re off trying to find the best place for a base, or just doing a one-off science mission to a particular surface feature.

    That’s pretty much been my skepticism around using BFS for lunar exploration: It’s way too top-heavy to do a small-payload hoverslam to unprepared ground, but it works fine if you can deliver 50 t to a prepared landing site. Not only does it give you the full gamut of navigational aids needed to get the errors within spec, but you can then hit T/W=1 with two Raptors at about 20% throttle. I just don’t see it on unprepared ground.

  9. johnhare john hare says:

    I finally realized that I should have figured and added a few more numbers in the post. The 100 m/s survivable impact that I mentioned in the post would imply that engine stop at zero velocity would be over 3 kilometers above ground level. Just over 60 seconds of acceleration at Lunar levels to hit the 100 m/s averaging 50 m/s for that altitude. That would imply a navigational issue well beyond what most of us would consider likely. The other way of getting that velocity impact is engine cut off while still descending with substantial velocity. So 100 m/s impact would be from massive navigational error, engine cut off error while still moving fast, or fuel depletion.

    I do agree that landing huge reusable vehicles under high risk conditions should be a non-starter. I see first landings at un surveyed locations as restricted to expendable, though not necessarily disposable vehicles. Payload limits are likely something under 20 tons for a barely modified existing stage. Recommending BFS for high risk landings on unprepared sites should lead to unscheduled unemployment of the parties involved.

    More realistic numbers for the concerns that most of us have involve lack of accurate feedback from the landing zone. Uneven ground and believable altitude errors bring the impact numbers way down. For early landings, it seems likely that high quality orbital survey could almost eliminate targeting a high hazard spot with large boulders and holes big enough to cause tip over. If this thought is wrong though, and the payload is at the top of a 20 meter (+-66 feet) vehicle, then 5 seconds of acceleration would give an impact of around 8 m/s or about 16 mph. Should be survivable by any payload with some minor planning for possible mishap. Equivalent of a 3.3 meter (11 foot) fall on Earth. Unpleasant but survivable.

    Early engine shut off at zero velocity at 20 meters would give that 8 m/s impact on the landing gear which should result in zero damage on a robust system. 80 meter altitude shut off error would be a 16 m/s impact which would more likely cause some damage. I think most would agree that an 80 meter altitude error is unlikely even on a totally new site.

    Engine cut off while still falling at significant velocity would be the largest worry to me. A control error or fuel depletion while moving could give impacts well above that survivable by any realistic vehicle. This would affect any landing system and not just the hoverslam.

  10. TheRadicalModerate says:

    I’m a lot less concerned about the payload than I am about the vehicle. If the vehicle is sufficiently pranged, the payload is undeployable, whether it survived or not.

    I haven’t run the numbers, but my guess is that it’s a lot better to have a low-structural coefficient vehicle with an engine that’s capable of T/W<=1 than it is to have a high-structural-coefficient vehicle that has to survive a hoverslam.

    I'm not competent to compute the Euler buckling loads on a pressurized tank, but remember that you're basically converting the kinetic energy of the vehicle at touchdown/impact to some force, using a stopping distance comprised of some amount of compression of the lunar surface and some amount of compressive strain distributed throughout the vehicle.

    Just to give you some idea of the naive forces involved on a 20 tonne vehicle at some example impact velocities and compressive distances:

    1 m/s, 1 cm compressive distance: 1 MN
    1 m/s, 10 cm compressive distance: 100 kN
    15 m/s, 1 cm compressive distance: 225 MN
    15 m/s, 10 cm compressive distance: 23 MN

    Odds are that you can think of this as nearly a pure Euler buckling problem. If you exceed the Euler load during impact, tankage is going to fail laterally, which is going to generate wreckage from which it's highly unlikely that the payload will emerge intact.

  11. TheRadicalModerate says:

    John, one other thing: Remember that the essence of these kinds of control problems is to make sure that the various sources of error damp themselves out, rather than amplifying and causing oscillations. It’s been a long time since college, but IIRC you tend to have fairly sharp thresholds on the level of errors you can tolerate before your system becomes over-controlled. Once that’s happened, the point where the engine shuts down in the state space is unlikely to be in the survivable range.

  12. johnhare john hare says:

    Your 15 m/s would require a 70 meter free fall. An engine cut out at that altitude is a problem that has nothing to do with landing mode.

  13. Andrew Swallow says:

    Hi John Hare, If the BFR goes into orbit it can drop a probe on the proposed landing site and on the next orbit home in on the probe. Cubesats have shown that a radio and camera can mass less than 1kg. The delta-v is about 1.87 km/s.

  14. TheRadicalModerate says:

    “Your 15 m/s would require a 70 meter free fall. An engine cut out at that altitude is a problem that has nothing to do with landing mode.”

    Unless you wind up with a positive velocity–from which there’s no way to recover if T/W>1, short of cutting the engine as soon as it’s detected. It’s all about the errors.

  15. johnhare john hare says:

    It took me about 15 seconds to figure out how a competent team would have programed the vehicle to recover from the positive vertical velocity at altitude. Care to try again?

  16. Paul451 says:

    John,

    “the stage propellant tanks provide a crumple zone if done right. An impact at 100 m/s (200 mph)”

    No. Except for bulk-mass, no cargo is going to survive a 200+ MPH impact. A fuel tank isn’t a “crumple zone”, it won’t deform in a controlled way. The cargo will simply punch it’s own hole straight through and slam into the thrust-frame/engines.

    “It took me about 15 seconds to figure out how a competent team would have programed the vehicle to recover from the positive vertical velocity”

    I assume you meant to use sideways motion to cause cosine losses large enough to reduce the vertical acceleration below T/W=1. However, that merely adds to the complexity of landing that, by definition, you’ve already borked.

    I’m not sure why you’re so adamantly against having the capacity to hover. SpaceX has Raptor, by any reasonable margin. If they were being funded to do a lunar lander before BFR was ready, they’d develop a lander around Raptor. RL-10 can throttle, so a lander based on Centaur will be able to hover.

    Having hover-capability doesn’t mean the lander is going to hang above the ground for minutes at a time. It just means you “hoverslam” with a target altitude well above the ground, then taper your deceleration as you get close enough verify the accuracy of your landing. It’s just that the final deceleration is less than the main deceleration. It would be a rare landing that an actual “hover” occurred (zero velocity at altitude.)

  17. TheRadicalModerate says:

    OK, I’ll bite. I can think of three things you can do:

    1) Per Paul above, you can slew the vehicle to get to effective T/W<1 to kill the velocity. But if you assume that min T/W=2 (which is about what the F9 S1 has) then you'd have to pitch to 30° off of vertical, then figure out a way to precess to remain over your landing site.

    2) You can shut the engine down, then try a restart. Probably reasonable for a pressure-fed engine, not so much for a turbo-fed one. And for both of them, you'd have to assume very large command errors at startup–not exactly what you want during terminal control.

    3) You can abort.

    Also, note that you're not necessarily looking at positive velocity at altitude. You can wind up with positive velocity at any location where the engines are still on–including sitting on the ground.

    Obviously, you’d program a shutdown the moment you detected a positive velocity. But my whole point is that your control precision is dictated by your measurement and command errors. If you’ve got a good measurement system (as F9 does on Earth), then this isn’t an issue. But if you’re 1 m off the surface and you get an altimetry dropout from dust, you’re stuck with whatever rates you detect when the altimetry kicks back in. (Note that a rate requires at least two reliable measurements of altitude or a clean doppler return.) 15 m/s is probably a bit extreme, but 8 isn’t, and that’ll still generate forces well over 1 MN.

  18. Bob Steinke says:

    If the strategy is to shut down the engine and restart, and you need a certain amount of time to do that, and to get that time you boost back to a safe altitude, then you’ve got to have reserve propellant for that so you might as well spend that propellant hovering.

  19. johnhare john hare says:

    As far as I can tell, most people seem to miss the point that hoverslam would be a way of getting around waiting for a vehicle with hover capability. Obviously it is better to have one that can hover and shift around when the vehicles that can come available. It should be equally obvious that waiting for that capability can add years to the schedule. If it is important to go, then using a capability that exists makes sense. I don’t understand people adamantly opposed to using technology that exists, even if it’s not optimum.

  20. DougSpace says:

    If we care about the sustainable development of the Moon to the point of starting settlement then how does a Falcon hoverslam fit into that? Could the Falcon be refueled from the lunar ice and reused? My Plan for Sustainable Space Development envisions the development of a reusable lunar lander that could serve as the foundation for ongoing, cost-effective development. This lander could be the modification of a Centaur upper stage to land belly down (e.g. the Xeus). Since the Centaur already exists it’s development wouldn’t take long. And besides, for sustainable lunar development we need to develop the ice-harvesting telerobots and the UniHab. So we have the time necessary to develop a proper, reusable lander.

  21. johnhare johnhare says:

    Actually, I didn’t specify Falcons doing the hoverslam. ATK, Lockmart, Russia, China, Japan, India, Brasil, ESA, Israel, and others I have certainly forgotten may wish to place a payload on the Lunar surface. If they can accomplish that with landing legs and a software purchase instead of a lander program, it sounds like a win. A NASA centric development may spec the Centaur. Other players may not be willing or able to jump through the hoops. There’s another tool in the toolbox now and some will use it if they both wish to do something Lunar, and are not part of the approved in crowd. For a serious development effort, several players and approaches are needed.

  22. TheRadicalModerate says:

    John, could you enumerate some of the actual vehicles you think could be modified to do this that wouldn’t be able to hover? Seems like the set of engines you could use vastly exceeds the set of existing vehicles. Engineering the vehicle to the engine would seem like a pretty obvious thing to do.

    As for the Centaur, RL10’s are already deeply throttleable, so I don’t really see the need to do a hoverslam if you want to land one tail-down. Seems like getting down into the 10 kN range would be easy (AJR has demonstrated well below this), so with a 2.3 t Centaur dry mass, you’d be able to hover a 3.9 t payload. (I’m pretty sure that an existing Centaur SEC, fully fueled in LEO, could get that size payload to the lunar surface. I get about 6200 m/s delta-v to the lunar surface needed, and the Centaur should have about 6500 m/s.)

  23. johnhare John hare says:

    Every restartable upper stage in the world can now become lunar capable without having to deal with the rl10.

  24. Paul451 says:

    John,
    There are no landing-capable upper-stages as of yet. And it takes more than welding on a few legs and writing some software. There’s not a single upper-stage in the world that has the prox-ops package necessary to do a landing. [Nor are there refuelable upper-stages yet.]

    Whatever base vehicle you start with, you will need a program to turn it into a lander. Whether that’s ULA, SpaceX, ESA, ISRO, or the Russians. (Although I wouldn’t trust Fregat at the moment.)

    If you insist on “existing” technology rather than “waiting”, surely Centaur-as-Xeus is the only option? At least they’re part way into the development. But it’s the one you’re outright rejecting. Why?

  25. johnhare john hare says:

    Paul,
    I haven’t been rejecting Centaur/Xeus as an option. I have been rejecting the idea that there is only one way to get the job done. One thing I think should be clear from history in general and spaceflight in particular is that depending on a single vehicle or technology is far more expensive and risky than having backups available. The backup plan, technology, and even hardware does not have to be up to the standards of the primary. Without options though, you get the decades long, get it perfect, development programs. Or you have multi-year stand downs after one accident.

Leave a Reply

Your email address will not be published. Required fields are marked *