Background

As I mentioned on my Space Show appearance earlier this week, my first appearance there in January ’07 elicited a lot of discussion both on the blog, and offline. I mentioned that a guy approached me with the question along the lines of “is there a way to wrap a business case around propellant depots”. That would be Colin.

We batted around a lot of ideas over the months, and came to the conclusion that while it was probably a bit too challenging to wrap a business case around depots directly. Not unless you had the backing of a wealthy philantrocapitalist like Musk, Bezos, or Bigelow (if any of the readers happens to be such a philantrocapitalist desperately in search of ways to invest a couple hundred $M to try and one-up Elon, my email address is jongoff@gmail.com, just in case you were wondering). The problem is that making depots really pay off probably requires at least two, and possibly three miracles. And when you have to raise outside money from non-philantrocapitalistic sources, you’re only allowed at most one miracle per business plan.

So, we backed up and looked to see if we could find any businesses that enabled depots that might be profitable in themselves. The idea of prox-ops tugs seemed to fit the bill. The idea is that one of the miracles needed for a depot is the development of a good prox-op tug that could take the complexity out of bringing “dumb” propellant tankers from their delivery orbit to the depot, hooking up the transfer lines, and then sending the tankers home empty when they’re done. If you could find a way to develop such a tug (or something close enough that it was clear that you only needed to trick-out your already existing tug with some slightly different add-ons), in a way that paid for itself, that would both make you some respectable amounts of money while simultaneously making the fielding of commercial depots that much closer to reality.

The challenge is that while there are probably a half dozen companies in the US that have the technical competence to design a tug-like spacecraft, and most of them want to do so pretty badly, none of them have really tried to go after this new market entrepreneurially. Now admittedly, and to be fair, it’s got to be really hard for a large, publicly traded company to take entrepreneurial risks like that in even the best of cases. But part of the problem has been the challenge of finding some initial toehold market that you can really get into the space tug business with.

There are a couple of aspects to this problem:

1. You need a customer who has a need that’s bad enough they’d be willing to actually buy servicing from you.
2. You need a technical approach that is non-scary enough that said customer will actually be willing to let you try
3. You need a customer with money, and an approach that’s cheap enough that the value of your service to them is sufficiently less than your internal cost to develop and deliver that service that you can actually make money.

That’s a bit harder than it sounds, and at least part of the reason why nobody has actually delivered on orbital servicing using space tugs is that this is a tough nut to crack.

There are people out there who could probably benefit a lot form servicing (NRO and USAF LEO satellites, GEO comsats, etc), but their spacecraft are so expensive that they really don’t want to be the first guinea pig–second or third maybe, but they’d rather see you demonstrate your capabilities on someone else. In both cases we looked at options like just attaching the spacecraft and providing some extra maneuvering capability–not even trying to actually transfer fuel or power or anything. But the reality kept coming back to the fact that the amount of engineering work it would take to go directly after such a mission immediately would likely cost so much that you couldn’t raise the money. If you could demonstrate your capabilities on something easier first, it might be realistic to start servicing these bigger players, but that means you still need to find a toe-hold market. They’re great second markets, but not good toe-holds.

Iridium For The Win?

In the end, we started looking at the Iridium constellation, due to the collision they had with the Russian Cosmos satellite in February of 2009.

Colin hit on many of the reasons why Iridium looks like an interesting first customer for space tug servicing. But let me add a few more:

• Iridium provides a large number of identical servicing targets.  Which means that you can design the servicing hardware once, and provide dozens of missions, reusing hardware, software, and experience.
• Not only does losing satellites start cutting into Iridium’s ability to retain and grow their customer base, but satellite losses that turn into more debris could actually make it harder to successfully replace the current constellation.  They really need to keep those orbits clean enough that they can continue to use them.
• While they really don’t want to lose many satellites, the fact that they do have some spares means that they can actually afford to take more risks on something like orbital servicing [Note: an article in Space News yesterday indicated that they felt they could still survive as a business if at least 36 of their satellites were still available when Iridium Next starts launching].  The bar is a lot lower than it would be with $1B NRO satellites, or GEO comsats that are bringing in hundreds of $M/yr/satellite.
• The government has a huge interest both in Iridium continuing to exist, and in Iridium not having more of their satellites become collision targets.  At Iridium’s altitude and inclination, debris from any collision is going to increase the danger to just about all LEO orbits of interest.  Remember, unlike GEO where all the satellites are going in the same direction at nearly the same speed, LEO orbits all tend to cross each other.  It wouldn’t take too many repeats of the Cosmos collision to start really making a big mess.  So the government might have a legitimate reason to help try and encourage ventures like this.
• With Iridium’s satellites getting old, the odds of one or more of them running out of propellant or having its batteries die before it can be disposed of is probably not insignificant.
• The LEO environment is a lot easier to design an initial tug for, and a lot easier to affordably reach.  Not to mention you can probably get away with a smaller spacecraft.  All of these lower the amount of investment you need to raise up front.
• Iridium actually has enough revenue that they might be able to afford a sufficiently low-cost servicing option.
• Their only other option is really to count “hope” as an operating plan. The analysis I linked to above indicates that they think they can survive as-is, but having an orbital servicing option that allows them to continue at full capacity might still be very interesting to them.

What the NRO Doesn't Want to See a Repeat Of

How Best to Be Of Service?

So, we started looking at various options of servicing the Iridium satellites.  Our initial idea was to provide a small tug for each of the satellites.  If a debris conjunction appeared likely, or if the satellite’s attitude control system failed, or if the satellite ran out of propellant, the helper tug would take over, and either help the Iridium craft dodge the debris, or provide station keeping or end-of-life disposal services. While such an approach would eliminate the complexity of actually doing anything to the Iridium satellite other than just grabbing it, it would entail trying to make 66 small spacecraft cheap enough that you could launch them, hook them up, and perform their missions all for a price-point Iridium could afford…which quite frankly seemed unlikely.

We also looked at the idea of having only a handful of tugs (1-3) that would sit around in standby, and if an event came up, it would rapidly maneuver to the Iridium satellite in danger, rescue it, and then go back to standby mode.  While this cut down on the number of tugs you needed drastically, now the propulsion requirements goes way up.   Especially if you can’t put one in each orbital plane.  Switching from plane to plane requires a plane change if you have to do it in a hurry, and that can be crazy expensive from a delta-V standpoint (a 6o degree plane change done the quick way could cost you almost as much delta-V as it took to get into orbit).  You could also do ground based “rescue tugs” that could only launch on need…but once again none of these approaches was really realistic either from a launch frequency, propellant usage, or total cost standpoint.

What we finally settled-on was the idea of just refueling the satellites themselves.  If you did that, you could use one or maybe at most two or three tugs to do the whole job.  Plane changing between two planes with the same inclination can be done relatively cheaply if you have a lot of time.  You just go into either an elliptical orbit, or a circular orbit of different radius, and then your nodal regression rate will be either faster or slower than the Iridium satellite planes.  If you can be patient, you’ll eventually catch up with the next orbital plane.  Moving from satellite to satellite within a plane also requires some tricky maneuvers, but if you have time, they don’t have to use a lot of propellant.  One option we batted around was launching a little “mini-depot” (really mostly a dumb tank with some transfer systems and docking ports) into an elliptical orbit that would drift from plane to plane.  That way you wouldn’t have to accelerate and decelerate the whole propellant load each time you went into one of your drifting orbits.

The end result was that by doing it this way, you could cut down drastically on the number of launches, not have to be anywhere near as rushed, and cut down on the number of satellites.

For the paper one of the things we were going to do was analyze the different trajectories to figure out how much propellant it really took to move from satellite to satellite in a given plane (given various allowable travel times), as well as how much propellant it took to move between planes.  Once you know that, you can start getting a better handle on how many launches you would need, how long things would take, etc., which would start enabling you to get a realistic cost estimate for at least the marginal cost of the servicing.

Servicing Challenges

The one other big question mark was what it would take to service the satellites once you got to them.

The Iridium satellites weren’t made for servicing.  The propellant inlets are capped with the caps safety-wired on.  And the whole assembly is likely covered up with MMOD protection or MLI.  I tried to get a good look at the one Iridium satellite they had up in the Air and Space Museum while we were out in DC for the NGLLC awards ceremony last year, but the area where I”m pretty sure the fueling interface was at was somewhere you couldn’t readily see.  I was sorely tempted to see if I could sneak up onto one of the displays nearby to get a peek, but chickened out. Anyhow, the net result is you’re going to need to do some stuff that would take about 15 seconds for a dude on the ground to do, but is going to be annoyingly complex to do on orbit.  I won’t go into details, just to avoid pissing off the ITAR gnomes, but suffice it to say this is not a trivial task.

There’s also the challenge that propellant isn’t the only thing that these satellites need.  Batteries and solar panels wear out.  While the latest and greatest solar panels are a lot better than what Iridium was launched with, you still need to find a way to couple that power into the satellite itself without hurting it.  Do you collect the power and then just beam it onto the other solar panels (might work if it’s just the solar panel efficiency that’s dropping)?  Or is there some sort of power umbilical used for the satellite on the launcher that could be reconnected to to provide both power, and a backup battery?  How do you attach it all?  Once again, I have some ideas, but I think I’ll leave things at that.

Real Life Getting in The Way

So, we had some starting ideas, and a basic approach.  We were still unsure if we actually wanted to jump on this idea as a real business, but we were interested in at least seeing where the analysis went. We pulled together a team to write the AIAA paper to investigate the idea.  I can’t remember for sure, but I think Colin was planning on using this paper as part of his MBA that he’s been working on.  And then life got messy and complicated, and in the end we had to back out of the paper.  But we wanted to put these thoughts up here to spur people’s thinking. If someone is going to provide this service for Iridium, the clock is ticking.  Even a fast-paced spacecraft development project is going to take probably 2-3 years, and there’s really not too much longer that you can delay and still be of use to Iridium.  Basically, we wanted to get the idea out into public to see if someone could find a way to run with it.

Technology Lock-in
One of the most interesting points made in the paper was how often technology can get locked-in by early decisions in a field, often made in situations of very limited data.  As documented in the paper, the engineers developing the Apollo docking  system admitted that “The selection of a docking system for the Apollo Program was based on limited knowledge because experience with actual hardware in space or from ground-based docking simulations was almost nonexistent.”  These early conceptual downselects, in this case with only a few half-scale air-bearing experiments to provide any data at all, often are not revisited in future developments.  This puts us in a situation where hasty decisions made early-on, based more on “engineering judgment” end up getting stuck with for many decades after the fact.   While this paper was focused on rendezvous and docking techniques, there are plenty of other examples of similar technology lock-ins in aerospace and elsewhere in industry.

Illustration of Boom Rendezvous
I found the following illustration, pulled from a NASA presentation given by Kirk Sorensen of MSFC (one of Joseph’s coconspirators on many topics including air launch, MXER tethers, and Thorium Liquid Flouride Reactors), to be the best illustration of the concept:

Much like modern mid-air refueling of helicopters and jets, a low-inertia connection is made at the end of booms extended from both vehicles, instead of trying to actively fly the two vehicles into each other.   In this case, the boom is on the order of 10-100m long, giving plenty of space to avoid collisions while hooking up the booms.

Boom Design Concept

The preferred approach for the extendable boom was to use a system like the Bi-STEM, which has been manufactured by Northrop-Grumman for in-space applications for decades:

The Bi-STEM system is sort of like a pair of tape-measures.  The coils of spring-steel form into arcs as they are spooled out, and their ends are interlocked, creating a tube that can be actively lengthened and shortened using electric motors or the spools.  A polymer tether can be easily run down the center of the assembly, adding greatly to the system’s tensile strength:

The whole assembly can be mounted on a gimbal or a Camfield Joint allowing full 6DOF pointing, using electric actuators.

Advantages

The main advantages of Boom Rendezvous, as detailed in the paper linked to, include:

• Greatly decreased probability of collisions during rendezvous.  Of all the possible rendezvous failures, collisions are the most likely to badly damage one or both vehicles.  Being able to greatly reduce the probability of damage due to failed docking is critical for operations like propellant depots that may require hundreds or thousands of successful docking operations over their lifetime.  With Boom Rendezvous, a missed connection goes from being a serious hazard to being the kind of thing you can easily try again, with the only risk being the ego risk of getting razzed by your fellow astronauts after the fact.
• Greatly reduced propellant requirements for the docking maneuvers.  Instead of the hunting problem often faced in current real-world docking operations, the closing is performed almost entirely by electric motors.
• Elimination of plume impingement problems.  When maneuvering two rocket-powered vehicles close together, impingement of the jets from the maneuvering vehicle on the other vehicle structures can be a severe problem.   Impinging plumes can spall off structural material or contaminate surfaces and optics.  Since all the maneuvering close-in is done using the booms, this is eliminated.
• Much lighter and simpler connection interfaces, since the booms can eliminate any remaining rotational or angular misalignments, and since the booms up close have enough compressive strength that you can very precisely control the final connection loads.  Without those extra loads, you can eliminate the heavy backing plates, shock absorbers, and guide petals common in modern docking adapters.  And without having to have those in the middle, the latching mechanisms, seals, and fluid/electrical connections can be made a lot more straightforwardly.
• Reduced sensor requirements for the rendezvous/docking.  You no longer need to know anywhere near as much about the target vehicle’s velocity and orbit, which allows you to use less sensitive, more robust sensors to make the hookup.
• Less precision required in the initial rendezvous orbit.  This may allow for the upper stage of the launch vehicle to do the rendezvous burn, allowing the payload to be much simpler and “dumber” than your typical modern prox-ops stage (like Dragon or Cygnus).  This will be important for depot operations as well, because the less smarts the tanker has to have, the lower it’s cost can be, and the more space can be left for the actual useful cargo or propellant.

Applications of Boom Rendezvous
While Boom Rendezvous has many benefits compared to the existing probe-and-drogue based docking systems in-use today, it has a few areas where it really shines:

• Rapid Rendezvous situations.  These include MXER tethers, apogee tugs, exo-atmospheric suborbital refueling, and other situations where the vehicle needs to hook-up very quickly.  Trying to do that with the high-inertial close-in maneuvering typical of today’s rendezvous and docking systems is begging for a crash.
• Depots and other space facilities.  The ability to have the actual docking with a depot occur several meters away from sunshields, tanks, and other hardware increases the odds of the depot being able to last long enough to be economically useful.  In fact, it may be possible using Boom Rendezvous for the Tanker/Tankee to offload or onload propellants without ever actually touching the depot itself.
• RLVs.  Most early-generation RLVs are likely going to be rather weight constrained.  By providing a potentially lighter docking system that doesn’t require as many demanding subsystems, more weight can be reserved for payload and recovery systems.
• Space Tugs.  Boom Rendezvous makes it a lot easier to divide the docking up into as many tugs as are necessary for safe operations.  Much like how more than one tug boat can be used when bringing a large oceanliner in to dock.

Concluding Thoughts
Boom Rendezvous and Docking is a rather promising approach that I hope sees more investigation.  The cool thing is that with the advent of suborbital vehicles, this is the kind of system that could be rapidly matured and demonstrated “in-space” for a tiny fraction of what it would cost to do with purely orbital systems.  Hopefully, the changing technological maturation situation provided by reusable suborbital launch vehicles can allow us to finally revisit hasty decisions made during Apollo.

Does this actually save you any complexity in the RCS system or avionics?  I think this may allow you to reduce the number of RCS thrusters, but I’m not sure (and don’t really have time to think it through today).

Comments?