A lot of good stuff today. Editor/publisher Jeff Foust has a report on this past week and weekend’s ISDC in Chicago, with a focus on space entrepreneurs and the new NASA direction. A young Belgian engineering student says that NASA needs to take a lesson from LEGO in developing space architectures (I agree). Alan Stern says that any SpaceX setbacks this week should not, and likely will not be permanent. Finally, James McLane says that we should do Apollo to Mars. I demur in comments.
34 thoughts on “The Space Review Today”
Comments are closed.
Your last link is a duplicate of your third link.
I like the LEGO article and agree with the approach. That seems the approach SpaceX is using with their booster systems.
I can’t resist reposting my comment at The Space Review, to Scott Pace’s exhortation as reported by Jeff:
Continuing to fund Ares 1 would not be “press to MECO” as Scott suggests, but rather more akin to “Challenger…go at throttle up”.
I’d be happier about Space X’s prospects if Musk wasn’t reported to be out of cash.
Lego space
In a fiction piece on a defunct blog of mine (provider terminated w/o notice) I envisioned a Lego like spaceship. Seven clustered BA330 are a single brick (or mix and match train car.) Nine Merlin engines in a framework are another. Standardized fuel tanks w/integral frame another. To make a ship, add as many of each as the mission requires. All pieces less than 20 tons.
What will you say if SpaceX’s test rocket fails?
One down, 16 to go before crew.
if only one human begins to live on Mars (and the first missions must be one-way trips only) there will be no thought of ever abandoning the colony.
Generally agree. Most mission plans seem to have 4 to 6 crew. I think a dozen would make more sense even if we have to send three ships instead of one to do it (it’s a lot cheaper per ship to make three rather than one.) Once there, a dozen people should stay permanently (not a few months of flags and feets/feats.)
if Musk wasn’t reported to be out of cash.
Paul, it’s a divorce case.
Cash strapped SpaceX?
“One small divorce for (a) man, one giant disaster for mankind.”
It would not be the first time a divorce has set back human advancement. No bitterness here, eh? Been there, done that.
I hope Elon is exaggerating his cash issues for the court case.
Elon’s personal cash issues aren’t really relevant. What’s important is SpaceX’ liquidity. They claim to be in good shape. For now.
I wonder how many versions of the cross country wagon there were before they hit on the Conestoga wagon. And how many copycats came afterward. Surely there were many families in these inferior wagons that only made it a few hundred miles before they gave out. They likely piled on the working wagons driven by others and pressed on. If politicians on either side of the isle use their influence to stop private enterprise from beginning this adventure it will be the responsibility of each and every person here to get the word out just how important this is to the future of space travel, and vote the bums out.
Hey, this guy gets it! Cheers, jjs!
I agree with the Lego article. I wrote much the same thing last week. He suggested a common propulsion system as a Lego block. I like that idea – but perhaps even better is a common interface between a propulsion system and the rest of the spaceship. That way, you can use chemical rockets or ion beam rockets or nuclear thermal rockets, or perhaps even solar sail propulsion, each with a common interface to the rest of the system. Then anyone can make propulsion systems that use that common interface.
Same goes for a common interface for loading or unloading at a propellant depot. Ever notice that all gas pump nozzles are the same? (at least for normal traffic) And all cars and motorbikes and RVs and trucks can use that nozzle – no coincidence, and essential if multiple suppliers and customers are to use a depot. Maybe, as with terrestrial gas stations, the “filling the gas station” and “filling a car” process will have different interfaces.
Same goes for a common interface between spaceship modules and perhaps an external framework – itself module with common interfaces between parts. Anchor points here and here and here and over there, etc.
Same goes for a common interface between habitable modules – nodes, airlocks, docking ports, what-have-you.
@Ken, I like your idea of sending more than one ship on a Mars mission. Send two or three rather than one big one with enough capacity on any two to take the crew of the third in the event of catastrophe. … Each ship has a crew of four with a capacity of six. Thus if one fails, the crew splits to the other two.
perhaps even better is a common interface between…
I read Ed’s article right after he wrote it. Now I realize why the concept seemed so familiar. I guess it’s one of those things that’s so obvious, mentioning it is neglected; but of course the interface is standardized. That’s the primary concept of Lego bricks. Ed was smart enough to make it explicit. I thought it was a great article.
Thanks LoboSolo, that’s just what I had in mind.
Oh, one other thing. If you send 3 Lego ships and a system fails on one or some other system on another… you could reconfigure them to produce 2 ships from the 3. So it’s not just crew that could be redistributed.
Let’s say each ship has a seven segment habitation module and 3 by 9 engine modules, and several fuel tanks each.
Let’s say a habitat segment gets punctured beyond repair somehow (not likely, but just for argument.) Consumables should give you room so it’s not a big issue.
One of the other ships has a hard start on a maneuver and loses all nine engines of one module (it was a big explosion and the Kevlar only worked partially) also taking out a few fuel tanks with fuel. Now you need to lose mass and reconfigure, but the mission is still good. You now have two good ships with plenty of fuel and spare parts floating nearby.
Then anyone can make propulsion systems that use that common interface.
In the work of fiction I wrote, our hero, coming back from the belt (avoiding pirates near ceres) to his Mars home gets an engine module upgrade from kerosene/Lox to water/nuke just before taking a transport contract to Ganymede. He sells the kerosene/lox engine module to a local shuttle operator that had a habitat/hotel module in mars orbit. He also adds two habitat modules, one of which is owned by a scientific expedition.
He also contracts with a pusher ship to add initial impulse for the jupiter trip.
All possible because of standardized interfaces.
Lego bricks are meant to be small, how would new space do space “bricks”?
I am picking around 300-500lb for the first generation new space RLVs, and I think the space “bricks” should probably be developed around that. Design dinosaur bricks and we may well end up with dinosaur space Lego. Many smaller bricks could of course still be launched on larger expendable launch vehicles, and this might be a good back up launch option – let the market decide.
300-500lb is sufficient to launch ISS sized inflatable modules – if they are assembled in orbit (shield shell, redundant 1atm pressure shells, furnishings, life support, etc.). With clip/zip together pressure shells it is actually possible to go much bigger than this.
If one is going to develop a Lego approach to space, then it should probably be done the new space way. I suspect it would be much more responsive, flexible, and cheaper than the old space way and it would provide a market for first generation new space RLVs.
Lego bricks are meant to be small
Lego bricks come in different sizes.
The primary quality is they can fit together and be reassembled. They could actually be designed various sizes as long as they can fit together. Smaller means more can be launched at a time, but also means more time spent putting something together.
Various bricks may have natural sizes. An engine module is pretty much whatever size it needs to be. Fuel tanks may vary considerably.
Ken-
I’ve looked into water/nuke engines. Gave up when I saw how low the Isp was unless you dissociate the H2O and eat up your reactor. Were you just assuming that the ability to get H2O plentifully would make up for that shortfall or was I incorrect in my reading of the material I found? If you don’t want to post here, please contact me through my website.
Various bricks may have natural sizes. An engine module is pretty much whatever size it needs to be. Fuel tanks may vary considerably.
You may have seen in the original article that Lego had to reemphasize on smaller more standardized bricks that enabled greater creativity and move away from the larger more unique pieces. Lego is meant to be, well, Lego, this seemed to be the main point of the article.
Tom, I just figured storing water is simple and you have plenty of time to produce Lox/Hydrogen to refill fuel tanks if you have the power which a suitable reactor could provide for years.
Not being an engineer, I have no idea if it’s really practical.
Fuel rods were a trade item in my stories. In general use everywhere in the solar system. A teenage orphan on Deimos became first officer (all others were passengers) for our hero and would typically handle them when traded in my story.
Pete, I understand that. I even left a comment there that, “You only need a four sided universal docking node.” But reality will determine what works best. My opinion is that a unit should be made small, but no smaller than may be required. For example… you might make small habitat parts that could be assembled in whatever size you need… or you can build a complete unit, including internal devices like dual life support, that has standard interconnects. In either case, you could add parts to make larger habitats. A medium size would be a single Bigelow module for example. I considered a cluster of seven, six identical around a central module to itself be a single brick. It just seemed to me that beyond lunar trips 2000 cubic meters would be a good unit size. I just can’t see traveling a long distance in a 100 cubic meter can. Trips beyond mars would need more space and multiple of 2000 c.m. seemed good to me. Obviously I’ve taken Pournelle’s travel in style from a step farther out to heart.
In my story, a single habitat module was taken apart to provide seven habitats for different families on various moons of jupiter. I can see the use and advantages of smaller parts but went that way in my story.
Water was a basic currency found everywhere in my story as well.
From newletter…
SpaceX is now targeting Friday, June 4th for its first test launch attempt of the Falcon 9 launch vehicle.
A medium size would be a single Bigelow module for example. I considered a cluster of seven, six identical around a central module to itself be a single brick. It just seemed to me that beyond lunar trips 2000 cubic meters would be a good unit size.
I agree, with inflatable systems volume is relatively cheap (mass is not) and there is little point in being cramped. Fundamental Lego bricks want to be small in mass, they do not necessarily need to be small in size. The Lego approach can help with ever larger volumes, as there is no immediate limit to how big one can build – it just takes more bricks.
The Bigelow module is around 22 ton, perhaps only 2 ton of which is the shell (pressure vessel and shielding). That 2 ton scales roughly with volume, the other 20 ton presumably scales mostly with number of people, so doubling the volume per person need only cost another say 10% in mass.
Considering these mass proportions, going Lego on the rest is obviously the critical part. The Bigelow module is designed as a fully furnished expandable RV, not as a cheap and light weight unfurnished inflatable shell.
Bear in mind that some things do not lend themselves well to compact packaging. Engineering involves more than just function and package, there are factors such as thermal which must also be balanced. Some things would do better spread out to improve radiative cooling and avoid overtemps due to high energy density.
Watching the construction of ISS is instructive — the modules are built down here, then hoisted into space in payload-sized “chunks” and mated in orbit, but the final system is not truly “modular”. This is very different from the sci-fi vision of the orbital shipyard where vessels are usually monolithic ni appearance (with plated hulls, etc) and constructed from scratch entirely in orbit. I should imagine that it’s more effiicient this way, both due to the costs associated with hefting raw materials into space and processing them there versus down here, and the ability of ground workers to get a lot more done quickly because they don’t have to wear bulky space suits while they do it. Machinists are much cheaper than astronauts. 😀
Slightly OT, those who have dabbled in Lego as an adult hobby are likely familiar with the “moonbase” project which sought to standardize an interface for modules which could be constructed individually and later interconnected into one giant base when their builders gathered at conventions. You can read about it here:
http://www.brickiwiki.com/page/LEGO+Moonbase
I read somewhere that Einstein commented on Occam’s Razor to the effect, “Simplify as much as possible but not further.” The same idea would apply to the “Lego block” approach to space engineering – make the modules as small as practical but no smaller. The savings and flexibility you might achieve by having large numbers of very small blocks could be overcome by the sheer number of interfaces you have to deal with.
Software engineering has used a building block approach for some time now. Back in 1985, a guy named Brad Cox wrote an interesting paper on what he called “Software Integrated Circuits.” Around 1991, Microsoft had some of that capability in Visual Basic 1.0 using components called VBX (Visual Basic Extensions). They proved very popular, so much so that other programming vendors adapted their environments to use VBXs even though they were tied to VB. In 1995, the generalized the concept so that the extensions weren’t tied to work with other languages. These units are called components. The interesting thing about components is that they can be distributed as black boxes with a well defined interface. So long as the interface doesn’t change, you can completely change the internal implementation of the functionality without having any secondary effects on the programs that use the components.
Done properly, space components could have the same capability. Define the interfaces properly and integration becomes a lot easier. Don’t let the engineers change the interfaces without damn good reason (you can add new functionality to the interface but don’t change the accepted existing functionality) but let them improve the internal implementation. This allows the blocks to evolve over time and for different companies to develop their own implementations to the accepted interfaces.
you can add new functionality to the interface but don’t change the accepted existing functionality
This is such a simple concept that I’m amazed how often, even in the software world which originated it, they fail to comply. Some companies provide components that are backward compatible and stable for twenty years, others break them with each version. Part of DLL hell was having to use old versions because the newer broke this paradigm, but the newer came with other software breaking your program that depended on the old.
SpaceX ran into this problem when a valve existed in Florida that didn’t exist in their Texas test stand. A type of thing that could lead to disaster in some cases.
Another concept central to software engineering (and probably other disciplines) is configuration management. The example of the valve on the test stand is one of a failure of configuration management between the test environment and the operational one. After it happened, SpaceX admitted the problem and stated they were taking steps to correct it. The company is still small enough to be agile but that’s a two-edged sword. Agility allows you to make changes quickly, but that also makes essential configuration management more difficult.
I’ve looked into water/nuke engines. Gave up when I saw how low the Isp was unless you dissociate the H2O and eat up your reactor.
Indeed — hot refractory materials and water do not mix well together. Reduced propellants, on the other hand, are more compatible. Hydrogen, ammonia, methane, perhaps even methanol.
In light of the Lego concept, Bigelow might want to rethink the design of the BA330. It has two integral airlocks, one at each end. It might be better if it had no airlocks at all, but rather a simple collar at each end that would attach to a separate airlock module. This way a series of module could be trained together without redundant airlocks.
Another thought… Just two Lego bricks… a four sided universal docking node… a larger round four sided universal Bigelow habitat module. Just these two universal bricks allow almost unlimited expansion. Two bricks.
You could go six sided as it’s easier to visualize, but four sided does the same thing and the pieces are cheaper. Plus 120 degrees gives you more separation than 90.
Modularity (like Lego) and open documentation enabled the dominance of the PC architecture over the Mac. More importantly, it drove a market in peripherals for PCs and PC clones, and opened a market in operating systems.
I see in the news today that Iridium has just signed a contract to purchase 72 (!) new communication satellites; any news on how they intend to launch those?
SpaceX has one of the launch contracts.
The S100 bus was more Legoish than the PC architecture. You could swap out everything and upgrade it. But I agree the openness of the PC architecture was absolutely a major part of its success.