Boosted Orbital Tether and Orbital Runway upgrades

SLAM: debunk creationism, pseudoscience, and superstitions. Discuss logic and morality.

Moderators: Alyrium Denryle, SCRawl, Thanas

User avatar
Lord Revan
Emperor's Hand
Posts: 10385
Joined: 2004-05-20 02:23pm
Location: Zone:classified

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby Lord Revan » 2017-02-02 04:25am

There's a reason why I said Lecroix's "applied pessimism" isn't really accurate for engineering, since a pessimist would look at problem and give up, an engineer looks at problem and tries to solve that problem and if it's not possible to solve it make it so that if that problem becomes relevant it's not a disaster.

To use planes as an example, sure planes can crash and kill thousands but engineers worked so that crashes that bad are really, really rare as long as regulations are obeyed. So planes aren't semi-uncontrolble missiles just waiting to kill scores of people at a moment's notice but rather such crashes are very rare and hundreds if not thousands of planes fly every year without killing a single person due to a crash. A airplane is not an example of a system where you had massive amounts of "if things go according to plan", quite the opposite in fact.
I may be an idiot, but I'm a tolerated idiot
"I think you completely missed the point of sigs. They're supposed to be completely homegrown in the fertile hydroponics lab of your mind, dried in your closet, rolled, and smoked...
Oh wait, that's marijuana..."Einhander Sn0m4n

Simon_Jester
Emperor's Hand
Posts: 28661
Joined: 2009-05-23 07:29pm

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby Simon_Jester » 2017-02-02 06:47am

Well, the point is that the engineering mindset is pessimism but a particular kind of pessimism.

There's a kind of optimism that imagines a thing happening, and imagines how fine and good it would be if that thing happened, and then just assumes that the universe will be kind enough to permit the good outcome to happen.

Good engineering logic is exactly the opposite of that mindset.

Rudyard Kipling wrote:THE Sons of Mary seldom bother, for they have inherited that good part;
But the Sons of Martha favour their Mother of the careful soul and the troubled heart.
And because she lost her temper once, and because she was rude to the Lord her Guest,
Her Sons must wait upon Mary's Sons, world without end, reprieve, or rest.

It is their care in all the ages to take the buffet and cushion the shock.
It is their care that the gear engages; it is their care that the switches lock.
It is their care that the wheels run truly; it is their care to embark and entrain,
Tally, transport, and deliver duly the Sons of Mary by land and main.

They say to mountains, " Be ye removèd" They say to the lesser floods " Be dry."
Under their rods are the rocks reprovèd - they are not afraid of that which is high.
Then do the hill tops shake to the summit - then is the bed of the deep laid bare,
That the Sons of Mary may overcome it, pleasantly sleeping and unaware.

They finger death at their gloves' end where they piece and repiece the living wires.
He rears against the gates they tend: they feed him hungry behind their fires.
Early at dawn, ere men see clear, they stumble into his terrible stall,
And hale him forth like a haltered steer, and goad and turn him till evenfall.

To these from birth is Belief forbidden; from these till death is Relief afar.
They are concerned with matters hidden - under the earthline their altars are
The secret fountains to follow up, waters withdrawn to restore to the mouth,
And gather the floods as in a cup, and pour them again at a city's drouth.

They do not preach that their God will rouse them a little before the nuts work loose.
They do not teach that His Pity allows them to leave their job when they damn-well choose.
As in the thronged and the lighted ways, so in the dark and the desert they stand,
Wary and watchful all their days that their brethren's days may be long in the land.

Raise ye the stone or cleave the wood to make a path more fair or flat;
Lo, it is black already with blood some Son of Martha spilled for that !
Not as a ladder from earth to Heaven, not as a witness to any creed,
But simple service simply given to his own kind in their common need.

And the Sons of Mary smile and are blessèd - they know the angels are on their side.
They know in them is the Grace confessèd, and for them are the Mercies multiplied.
They sit at the Feet - they hear the Word - they see how truly the Promise runs.
They have cast their burden upon the Lord, and - the Lord He lays it on Martha's Sons !
Basically, a good engineer thinks like one of Kipling's "Sons of Martha."

The key idea is to be careful, to assume that literally nothing will work unless one has taken great pains to ensure that it actually does work. "They do not preach that their God will rouse them a little before the nuts work loose."

This is very much the mindset applied to aerospace engineering. It's not "what is the worst outcome I can imagine?" It's "What is a failure mode of this system? What could break? How do I prevent it? Do I need to monitor and maintain the system? Can I design it to be immune to this failure mode? Can I install a backup or create an emergency plan that allows me to 'survive' this failure mode without anything seriously unpleasant happening?"

No design is ever complete, or even remotely close to complete, without that.
This space dedicated to Vasily Arkhipov

User avatar
Lord Revan
Emperor's Hand
Posts: 10385
Joined: 2004-05-20 02:23pm
Location: Zone:classified

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby Lord Revan » 2017-02-02 07:39am

I'd say that saying "better safe then sorry" encapsulates the engineering mindset quite well. It would nice if things worked perfectly however it's better to have plans for when things fail and not need those plans to not have plans and need them.
I may be an idiot, but I'm a tolerated idiot
"I think you completely missed the point of sigs. They're supposed to be completely homegrown in the fertile hydroponics lab of your mind, dried in your closet, rolled, and smoked...
Oh wait, that's marijuana..."Einhander Sn0m4n

User avatar
matterbeam
Youngling
Posts: 80
Joined: 2016-04-04 08:52pm
Contact:

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby matterbeam » 2017-02-02 08:20am

Zeropoint wrote:Then . . . why all this fuss about the hypersonic tether catch system?


An indirect way of saying that reliable or zero-propellant orbital launch systems have already been devised and designed. I'm not trying to re-invent the wheel. I want something that is best suited to today's materials and capabilities.

Every iteration of your idea gets more and more complicated, expensive, heavy, and failure-prone. It's getting WORSE the more you think about it.


No.

[quote=Simon_Jester"]If there's a difference in orbital inclination between the station and the payload, then at the top of its ballistic arc, the payload is moving laterally relative to the station at every point along its arc. It's not just "running towards" the station, it's also a crossing target. This complicates the capture process. It also means you'll have to carefully re-orient the catching hardware (which is designed to capture things moving in specified directions) for each operation.[/quote]

A 30 degree inclination at capture translates to a 4000 to 3800m/s additional relative velocity from 200km to 1000km altitude.

It also requires that the tether use a combination of lateral tension and rotating ability to absorb lateral forces that are not fully brakes by the flywheels. This favours a 'step-down' pulley-train tether where braking forces increase with each pulley up the line, thereby distributing lateral forces all along the tether. With a properly oriented tether, these can be a small fraction of the linear forces.

On the other hand, a BOT with the ability to handle +/- 30 degree inclinations can cover a third of the world's surface area.

Hint: this is an example of the problem. You're seeing "in the best case scenario, the ability to use the catcher to do plane changes exists." And you're letting that blind you to "this would significantly complicate the process of orbital 'rendezvous' between the payload and catcher, and introduce an extra variable element to a system that must be very, very precisely controlled to work at all."


Best case scenario: The tether can rotate to perfectly cancel out the apparent diagonal motion of the payload.
Worst case scenario: A collision at 10km/s instead of 7.5km/s.

If we use the gas-brake-and-hook design, we are not increasing the rendezvous complexity on the payload's end, as the drone that guides the hook into the gas tube needed a two-axis precision anyways.
The launch booster puts payloads in a near-vertical trajectory, so it does not matter which inclination is it fired from. A second-stage orbital tether that pulls payloads in low orbit into higher orbits can encounter inclined payloads. However, would you agree that if the payload is already in space, then it is very much easier to move into a 1km max distance intercept with the tether? They can try several times a day with no unpredictable forces like atmospheric drag.

You're leaving huge margins of error in the thing that matters least: the mass of the station. Making the station more massive doesn't deter you from marketing this idea, because you're already committed to orbiting thousands of tons of station components before you see a dime of savings on launch costs. Given how you're actually going about this, in your eyes the acceptable maximum price of the station itself looks to be pretty firmly pegged at "infinity dollars." Or you wouldn't be approaching the problem this way at all.


I've included margins in the maximum stresses the parts can handle, which I think is the critical point. The extra mass the station requires is a side-effect.

The initial BOT can be very small. Subsequent launches have a much higher equivalent payload capacity, so thousands of tons into orbit is actually hundreds of tons using cheaper rockets, or tens of tons if high-strength flywheels are used instead of basic steel. Considering that the smaller BOT can send up regular satellites into orbit in between building blocks for a larger BOT, it will pay for itself.

Also, the orbital launch tether is the most extreme tether, the heaviest, suffering the hardest forces and being the most expensive.

We can devise a 'third stage' tether-and-flywheel system where a payload, already in low orbit, is boosted into geostationary transfer orbit for free. The payload docks slowly and safely with the tether. The tether is spun to a rim velocity X. A flywheel is spun at the hub. When the tether is connected to the hub, it is drawn in. Radius is reduced, so velocity increases. At the desired velocity, release the payload. For example, a 50km radius tether with 1000m/s tip velocity, can be pulled into a 20km orbit around the flywheel at a rate of 500m/s, allowing the payload to be released at 2500m/s. This halves the required mass in low orbit. A 10 ton payload suffers between 2.5 and 17.6G.

1) You have designed systems that fail catastrophically if a single component fails or partially fails. Say, a stuck maneuvering thruster on the ballistic payload that interferes with its ability to be at exactly the right centimeter at exactly the right millisecond. It's not good enough to just rotate the payload and use the other thrusters or something, because there isn't time. You can't take a few extra minutes to get the approach vector right.


The pulleys are redundant. The brakes are redundant. The tether(s) are redundant. The payload's manoeuvring system has backups. There are multiple flywheels.

I agree the skip-rope design was a bit too hard, requiring the payload to have an accuracy about a thousand times better than an ASAT weapon tested in 1958 (http://designation-systems.net/dusrm/app4/ws-199.html).

Hopefully, the gas brake system only requires and accuracy about 6-7 times better.

What do you mean by getting the approach vector right? The payload can correct its trajectory all the way up to intercept?

2) You have designed systems that cannot possibly work as intended if there is a deviation from plan. That is, if all the major elements of the system function as intended, but there is a delay in the rocket engines firing, so that a rocket launches a second later than it should. Or if a thunderstorm causes a delay in the launch countdown. Or if there's a "red light" on the tether capture system equipment and the ground control team wants a few minutes to check over the equipment diagnostics before okaying the system for a 'catch.'


Yes, if the payload is in the wrong place at the wrong time and every safety measure meant to push it out of the way of the tether if a deviation is detected all fail, then it will be destroyed. If the payload misses the tether, it will fall back down to Earth and hit the atmosphere at a velocity of about 1000-1500m/s. If the tether snaps all redundant cables, then the payload will leave on a suborbital trajectory and hit the atmosphere at up to orbital velocity. If more than 75% of brakes fail, then the remaining brakes will not be able to handle the payload and it would have to be released into a suborbital trajectory. If more than 75% of pulley wheels seize up, then the brakes cannot perform an emergency braking manoeuvre at up to 4x the intended acceleration (12 to 27G). For every flywheel that fails, braking must compensate for the lost kinetic energy.
Google + : matterbeamTSF

Hard SF blog: ToughSF

MetaSeed: Worldbuilding and Game Design discussion

Simon_Jester
Emperor's Hand
Posts: 28661
Joined: 2009-05-23 07:29pm

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby Simon_Jester » 2017-02-02 08:39am

Lord Revan wrote:I'd say that saying "better safe then sorry" encapsulates the engineering mindset quite well. It would nice if things worked perfectly however it's better to have plans for when things fail and not need those plans to not have plans and need them.
That and, of course, recognizing that if a thing cannot be designed with plans for failure built into the design, it probably shouldn't be designed at all.

We avoid horrible worst case scenarios like "planes routinely crash into cities killing thousands" precisely by making sure that planes are designed to respond to common mechanical failures by not crashing, and by designing them so they are unlikely to crash in the first place.

If we instead designed planes with a "wouldn't it be nice if this worked" mindset, they would crash and kill far more often than they do in real life.

matterbeam wrote:
Zeropoint wrote:Then . . . why all this fuss about the hypersonic tether catch system?
An indirect way of saying that reliable or zero-propellant orbital launch systems have already been devised and designed. I'm not trying to re-invent the wheel. I want something that is best suited to today's materials and capabilities.
The problem is that by changing these designs, in a real sense you are reinventing the wheel. You're trying to replace designs for a 'wheel' with completely different things of your own imagination. And you're often not noticing until it's pointed out to you that the wheel you've just proposed to build is in fact a square wheel.

Every iteration of your idea gets more and more complicated, expensive, heavy, and failure-prone. It's getting WORSE the more you think about it.
No.
Honestly... yes. Your first iteration ("payload grabs tether") would actually WORK if you could just build a sufficiently reliable and powerful set of brakes. That was the ONLY truly challenging problem with the design. Granted, it might be an insurmountable problem, granted, the idea might not actually be very profitable even if it worked. But at least there was only one fundamental flaw in the design, one that we could have conceivably figured out a way to directly fix. Or that would work if the brakes were made from some indestructible super-material or something.

All the subsequent designs are far more sensitive to problems like "what if the payload arrives 100 milliseconds late" or "what if something breaks." They are not designs that could be made to work just by having very strong or tough materials.

Hint: this is an example of the problem. You're seeing "in the best case scenario, the ability to use the catcher to do plane changes exists." And you're letting that blind you to "this would significantly complicate the process of orbital 'rendezvous' between the payload and catcher, and introduce an extra variable element to a system that must be very, very precisely controlled to work at all."
Best case scenario: The tether can rotate to perfectly cancel out the apparent diagonal motion of the payload.
Worst case scenario: A collision at 10km/s instead of 7.5km/s.
No no no.

This isn't about "how much more destructive would a crash be." This is about "how likely is it that we will somehow not succeed?" Has changing the system in this way made it harder to accomplish the goal, by creating more variables that have to be controlled for, more things that have to go exactly according to plan for the system to work?

I'm not even ready to discuss the idea with the light gas gun. What I'm trying to get you to do is at least acknowledge me on this very important point, that we need as a matter of routine practice to stop and think "are the complications I'm adding going to make it more likely that a failure in some part of the system or some step of the process will prevent overall mission success?"

I've included margins in the maximum stresses the parts can handle, which I think is the critical point. The extra mass the station requires is a side-effect.
Bulking up the station's parts is the least of your worries.

Your really big worry here is payload guidance and making the catch process reliable enough that people are willing to risk expensive payloads on it. One of the things that delayed the rise of commercial rocketry was the reliability issue- it took years before we could build rockets that would launch correctly 90% or more of the time without blowing up.

If your system cannot catch its payloads 99% of the time or better (to pick an arbitrary but reasonable number)... People are going to be reluctant to launch an expensive payload into space on an expensive suborbital rocket hoping that you will be able to hold up your end of the bargain by catching the payload.

And yet, due to practical factors like guidance and timing, it is very hard for you to ensure that your system will catch its payloads reliably. This is a totally separate issue from "can you build the system," which I'm not even trying to evaluate right now because your system changes so rapidly that it's hard to be clear on which of several proposed systems you're really talking about anymore.

We can devise a 'third stage' tether-and-flywheel system where a payload, already in low orbit, is boosted into geostationary transfer orbit for free. The payload docks slowly and safely with the tether. The tether is spun to a rim velocity X. A flywheel is spun at the hub. When the tether is connected to the hub, it is drawn in. Radius is reduced, so velocity increases. At the desired velocity, release the payload. For example, a 50km radius tether with 1000m/s tip velocity, can be pulled into a 20km orbit around the flywheel at a rate of 500m/s, allowing the payload to be released at 2500m/s. This halves the required mass in low orbit. A 10 ton payload suffers between 2.5 and 17.6G.
Now see, that is a type of system that realistically works, and is more in line with what others have already suggested.

I agree the skip-rope design was a bit too hard, requiring the payload to have an accuracy about a thousand times better than an ASAT weapon tested in 1958 (http://designation-systems.net/dusrm/app4/ws-199.html).

Hopefully, the gas brake system only requires and accuracy about 6-7 times better.
Remember, one issue with ASAT missiles is that nobody in the military really minds if you need to fire two or three times to score one hit. Commercial satellite launchers aren't going to like the idea that they need to pay for three satellite launches to be sure of getting one airborne.

Furthermore, an ASAT weapon has rather 'sloppy' constraints about the exact speed and direction it's flying in when it intercepts the target. The messier and more energetic the collision between 'sat' and ASAT, the better.

Here, you need an extremely 'gentle' collision, which imposes more variables on your flight path. You can't just be going in the right direction, you must be at exactly the right speed to coast to a stop at the right instant.

What do you mean by getting the approach vector right? The payload can correct its trajectory all the way up to intercept?
There isn't much time to correct the trajectory, though. Normally, when a booster underperforms or something, as long as the payload makes it to orbit at all, you can gradually maneuver up to the desired position. It's okay if the change in velocity takes a day or more to have the desired effect, because you're already in orbit. Here, that is not the case. There's only one chance to do it right and the payload will fall back to Earth if you miss.

Then there's the totally separate issue that your payload can't correct for what happens if the rocket launch isn't exactly on time.

Yes, if the payload is in the wrong place at the wrong time and every safety measure meant to push it out of the way of the tether if a deviation is detected all fail, then it will be destroyed. If the payload misses the tether, it will fall back down to Earth and hit the atmosphere at a velocity of about 1000-1500m/s. If the tether snaps all redundant cables, then the payload will leave on a suborbital trajectory and hit the atmosphere at up to orbital velocity. If more than 75% of brakes fail, then the remaining brakes will not be able to handle the payload and it would have to be released into a suborbital trajectory. If more than 75% of pulley wheels seize up, then the brakes cannot perform an emergency braking manoeuvre at up to 4x the intended acceleration (12 to 27G). For every flywheel that fails, braking must compensate for the lost kinetic energy.
The biggest problem with the system that you can't compensate for- and this is the killer that messes up all plans of the form "loft on suborbital trajectory, we'll boost you to orbital speed once you're in space" is the part where the payload is "in the wrong place at the wrong time."
This space dedicated to Vasily Arkhipov

User avatar
LaCroix
Sith Marauder
Posts: 4086
Joined: 2004-12-21 12:14pm
Location: Vienna, Austria, Europe, Terra

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby LaCroix » 2017-02-02 09:52am

matterbeam wrote:Yes, if the payload is in the wrong place at the wrong time and every safety measure meant to push it out of the way of the tether if a deviation is detected all fail, then it will be destroyed. If the payload misses the tether, it will fall back down to Earth and hit the atmosphere at a velocity of about 1000-1500m/s.


You just covered the outcomes of 99% of the launches. Because even if your station works 100% reliable at all times, the rocket will not.

The system requires a perfect positioning. Perfect, as in "at least an order of magnitude more precise than our most advanced positioning systems". GPS is able to give you a resolution of a meter, at it's best. You would need to calculate in real time, on an ascending rocket, if it will end up in a certain cubic meter of space where the rendevous has a remote chance of working, at a certain second. (because at any point of the possible docking window of a handful seconds, at most, there is only 1 position that will work. You have to constantly scrub meeting points and aim for the next, adjusting the rocket thrust and trajectory to make sure it shows up there.

Most of the times, the ground station only knows the position of the rocket only in general terms, +/- a dozen meters in any direction during that phase. The problem? Rocket thrust fluctuates. Throttling up and down is hard, for changes in fuel flow cause temperature changes that cause changes in combustion, etc. A lot of tiny wibbly-wobbly things interacting with each other, and making any rocket ascension unpredictable. Almost to the point where it is more an art form. Usually, they need a couple of correction burns to reach the orbit they want, and these orbits are specified in kilometers above earth. Not meters or centimeters. And they don't have timing requirements of being at a very precise cooordinate at a time, even for gestationary - they aim for a couple of km empty space.

So pretty much, modern spacetravel have all the time they need to go where they need to be. Especially for things like docking. Final approach for docking takes minutes of constant corrections at very low relative speeds, and that's for two craft in the same orbit, with unlimited retries. You want to hit bullseye at first try, in a specific second, at most, with assured destruction on failure.

In the end, it doesn't matter how great your station and tether may be if you can't make the payload show up in time.

That's why HASTOL works with a hypersonic chase plane to deliver payload. All the problems with your system evaporate the moment you have a dedicated chase plane to deliver payload. it can arrive early, and then match the hook's speed and trajectory while delivering the payload. If it misses, it just returns to base for a later attempt. Even the collision risk is minimized, for they are at relative speeds close to zero during all the time.
A minute's thought suggests that the very idea of this is stupid. A more detailed examination raises the possibility that it might be an answer to the question "how could the Germans win the war after the US gets involved?" - Captain Seafort, in a thread proposing a 1942 'D-Day' in Quiberon Bay

I do archery skeet. With a Trebuchet.

User avatar
matterbeam
Youngling
Posts: 80
Joined: 2016-04-04 08:52pm
Contact:

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby matterbeam » 2017-02-02 12:25pm

Simon_Jester wrote:The problem is that by changing these designs, in a real sense you are reinventing the wheel. You're trying to replace designs for a 'wheel' with completely different things of your own imagination. And you're often not noticing until it's pointed out to you that the wheel you've just proposed to build is in fact a square wheel.


Which is why I'm discussing it on an internet forum. I think this is the right place to clean up ideas that would be outright kicked out of the door elsewhere.


Honestly... yes. Your first iteration ("payload grabs tether") would actually WORK if you could just build a sufficiently reliable and powerful set of brakes. That was the ONLY truly challenging problem with the design. Granted, it might be an insurmountable problem, granted, the idea might not actually be very profitable even if it worked. But at least there was only one fundamental flaw in the design, one that we could have conceivably figured out a way to directly fix. Or that would work if the brakes were made from some indestructible super-material or something.

All the subsequent designs are far more sensitive to problems like "what if the payload arrives 100 milliseconds late" or "what if something breaks." They are not designs that could be made to work just by having very strong or tough materials.


The first iteration required that the brakes handle a peak load of 2.154GW of heat to accelerate a 10 ton payload from 7334m/s to 0 at 3G. A carbon brake at 1000K could heat up liquid hydrogen from 21K at a sufficient rate, requiring a maximum of 183kg/s to boil off. After 83 seconds, at an average rate of 91kg/s, about 22.88 tons of liquid hydrogen would have been required, plus losses and inefficiencies. I believed it would have been too difficult to pump that amount in from the station's reserves, have the liquid reach the brakes, have the hydrogen absorb gigawatts of heat without using an extremely big apparatus, have the pump feed follow the payload, and re-capture the boiling hydrogen to make it all mass-efficient.

No no no.

This isn't about "how much more destructive would a crash be." This is about "how likely is it that we will somehow not succeed?" Has changing the system in this way made it harder to accomplish the goal, by creating more variables that have to be controlled for, more things that have to go exactly according to plan for the system to work?


I'm hoping the drone and gas brake system would increase the acceptable margins of error. Since the drone and hook are fixed-mass components, every increase in mass dedicated to the system will increase the margin of error. For example, 10% of the realistic spacecraft design described earlier (14.45 tons minus 1.5 tons in faceplate and brakes) would give a tether length of 2.8km. 15% is 4.38km. If we want the accuracy of ASAT weapons being tested 50 years ago, the payload will require 20% of its mass being dedicated to this system.

I'm not even ready to discuss the idea with the light gas gun. What I'm trying to get you to do is at least acknowledge me on this very important point, that we need as a matter of routine practice to stop and think "are the complications I'm adding going to make it more likely that a failure in some part of the system or some step of the process will prevent overall mission success?"


How would I evaluate whether some modification or new design is 'likely' to be worse than what it replaced? Some elements of my designs, such as hypervelocity braking or a reverse-gas-gun, have no real world equivalents, or at least nothing with data available online.

Your really big worry here is payload guidance and making the catch process reliable enough that people are willing to risk expensive payloads on it. One of the things that delayed the rise of commercial rocketry was the reliability issue- it took years before we could build rockets that would launch correctly 90% or more of the time without blowing up.


That's it! I'm transferring the critical failure point of each design towards things that more and more solvable by modern technology.

The first design was a simple braking wire. It was relatively easy to reach it, but required unavailable cooling methods.

The second design added a flywheel to pull on the tether in the opposite direction. It added the risk of flywheel exploding, but removed the requirement for propellants entirely.

The third design (not posted) had a bow-and-arrow configuration. Intercept is easy, no hypervelocity braking, but the payload's hook would collide with the tether at orbital velocity.

The fourth design is the skip-rotor design. No braking, no propellants, zero relative velocity intercept at the tip of the tether... but intercept precision is too high.

The fifth design I'm looking at now uses a tube of gas to brake only the small hook. Attaching the hook to a tether from the payload relaxes the intercept precision required. No braking, no propellant, low intercept precision, but it is unclear how much gas the tube would lose due to the opening for the tether. One single chamber for braking, with a uniform gas density, is each to calculate. It would be compressed into a volume 960 times smaller. This might lead to a large temperature increase. Multiple chambers are more complex, requiring a valve system with 0.1 second reaction times, and either a series of paper plates to hold the gasses, or high-strength metal plates that stack like dinner plates but do not risk being destabilized by the passage into higher-density gas. Thankfully, drag is not dependent on the pressure of the gas, so we can use high molecular mass gasses such as Argon and near-vacuum pressure.

If your system cannot catch its payloads 99% of the time or better (to pick an arbitrary but reasonable number)... People are going to be reluctant to launch an expensive payload into space on an expensive suborbital rocket hoping that you will be able to hold up your end of the bargain by catching the payload.

And yet, due to practical factors like guidance and timing, it is very hard for you to ensure that your system will catch its payloads reliably. This is a totally separate issue from "can you build the system," which I'm not even trying to evaluate right now because your system changes so rapidly that it's hard to be clear on which of several proposed systems you're really talking about anymore.


How would I go about evaluating the reliability of the various BOT designs? I do not think I will be able to gather relevant data on the various components, especially ones that do not exist yet. All I can do is reduce the forces, velocities and timings to levels where I believe that modern technology and materials are capable of handling. Putting them all together... well, I have no idea how they would react.

Now see, that is a type of system that realistically works, and is more in line with what others have already suggested.


A third-stage BOT might not be very competitive compared to extremely simple designs, such as Rotovator or near future electric rockets, that operate in the same conditions. This is why I want to 'solve' the first-stage BOT that would provide incontestable advantages over alternative options.

Remember, one issue with ASAT missiles is that nobody in the military really minds if you need to fire two or three times to score one hit. Commercial satellite launchers aren't going to like the idea that they need to pay for three satellite launches to be sure of getting one airborne.


I don't think these numbers are a fair standard for commercial spaceflight. If we followed the logic of satellites as munitions, we could force the skip-rope design to statistically work by dividing the payload into a chain of satellites that form a long string. Each point on the string tries to rendezvous with the tip of the skip-rope. They are spaced about 80m from each other. If one of them intercepts the tether and docks correctly, the entire chain can be braked into orbit.
The string has 50 seconds to extend and orient itself from the moment the booster leaves the atmosphere. At 1000km, it has seven and a half minutes.

Furthermore, an ASAT weapon has rather 'sloppy' constraints about the exact speed and direction it's flying in when it intercepts the target. The messier and more energetic the collision between 'sat' and ASAT, the better.


I've never heard of an ASAT weapon that deliberately tries to increase the collision energy! They are quite sensitive to intercept distance, as the 6-7km distance was noted back in 1958 as being just a bit too far for atomic warheads to have an effect on the satellite target. The closer the intercept, the smaller the warhead needed, and the smaller the missile required.

Here, you need an extremely 'gentle' collision, which imposes more variables on your flight path. You can't just be going in the right direction, you must be at exactly the right speed to coast to a stop at the right instant.


A 100km (!!) error in altitude is equivalent to a 30m/s difference at 200km. The reaction control systems have the capacity to correct this error 5 times over or more. I seriously doubt modern rockets regularly place their payloads in orbits with a +/-100km altitude error.

Then there's the totally separate issue that your payload can't correct for what happens if the rocket launch isn't exactly on time.


A 1 second delay in launch time is equivalent to a 7.5 km error in position at a 200km altitude. To be corrected, we'll need to calculate how long it takes to reach 200km.

Suppose a rocket needs 2000m/s to reach 200km altitude. It carries 12.95 tons in the second stage. First stage is set as 10 tons dry mass for engines, fuel tanks and return systems. 300m/s is used to overcome gravity and drag losses. Isp is 350 in vacuum, 300 at sea level, average 325. Required mass ratio 2.058, so 24.28 tons of propellant required.
It starts off with a TWR of 1.5, and ends at 3.09. Time to burnout is about 102.16 seconds, so minimum altitude at burnout is 11975m. The engines will likely be throttled down to extend how long main engine nozzle deflection can be used. Let's use the most extreme scenario anyways. It takes another 94 seconds to reach 200km altitude and intercept.

This means that for every 1 second error in launch window requires the trajectory to gain a lateral velocity of just over 73m/s. Aerodynamic forces can be used, but I do not know how much lateral velocity they can provide, especially as we do not have a reading on things such as L/d ratios.

Imagine we fit 5 more tons of propellant onto the first stage. This gives it 321m/s extra deltaV. After losses, it can compensate for a 4.4 second error. With 10 tons extra, it is 8.4 seconds, and so on. I'm guessing that aerodynamic fins can provide a lot of this for free. All in all, I do not think that the modern rocket's lack precision is too great for a 150 to 200m/s RCS to handle.

At 1000km, this requirement drops to 30m/s per second error, assuming 4000m/s vertical velocity achieved at 20km altitude.

The biggest problem with the system that you can't compensate for- and this is the killer that messes up all plans of the form "loft on suborbital trajectory, we'll boost you to orbital speed once you're in space" is the part where the payload is "in the wrong place at the wrong time."


I'm working on reducing that.
Google + : matterbeamTSF

Hard SF blog: ToughSF

MetaSeed: Worldbuilding and Game Design discussion

Simon_Jester
Emperor's Hand
Posts: 28661
Joined: 2009-05-23 07:29pm

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby Simon_Jester » 2017-02-02 03:01pm

matterbeam wrote:
Simon_Jester wrote:The problem is that by changing these designs, in a real sense you are reinventing the wheel. You're trying to replace designs for a 'wheel' with completely different things of your own imagination. And you're often not noticing until it's pointed out to you that the wheel you've just proposed to build is in fact a square wheel.
Which is why I'm discussing it on an internet forum. I think this is the right place to clean up ideas that would be outright kicked out of the door elsewhere.
Okay, but do you understand the point I'm getting at here? The key is that improving the mindset with which you design or propose designs will improve the outcomes, making you more likely to think of things that can be made to work. And more likely to not need prompting to understand why a given idea won't work.

Honestly... yes. Your first iteration ("payload grabs tether") would actually WORK if you could just build a sufficiently reliable and powerful set of brakes. That was the ONLY truly challenging problem with the design. Granted, it might be an insurmountable problem, granted, the idea might not actually be very profitable even if it worked. But at least there was only one fundamental flaw in the design, one that we could have conceivably figured out a way to directly fix. Or that would work if the brakes were made from some indestructible super-material or something.

All the subsequent designs are far more sensitive to problems like "what if the payload arrives 100 milliseconds late" or "what if something breaks." They are not designs that could be made to work just by having very strong or tough materials.


The first iteration required that the brakes handle a peak load of 2.154GW of heat to accelerate a 10 ton payload from 7334m/s to 0 at 3G. A carbon brake at 1000K could heat up liquid hydrogen from 21K at a sufficient rate, requiring a maximum of 183kg/s to boil off. After 83 seconds, at an average rate of 91kg/s, about 22.88 tons of liquid hydrogen would have been required, plus losses and inefficiencies. I believed it would have been too difficult to pump that amount in from the station's reserves, have the liquid reach the brakes, have the hydrogen absorb gigawatts of heat without using an extremely big apparatus, have the pump feed follow the payload, and re-capture the boiling hydrogen to make it all mass-efficient.
Liquid hydrogen is a very bad choice to use as a coolant, because it has a lot of volume, is very low density, and has a very low heat of vaporization. Use water instead. The amount of energy required to heat room temperature water to and beyond the boiling point is a bit over 2600 kilojoules per kilogram. Much more energy per kilogram than you can get from liquid hydrogen as a coolant.

Now, that still leaves you boiling off... wait, a thousand tons per second of boiling water if you're actually correct about that "2.154 gigawatts" figure. Casually computing the kinetic energy of the payload, it needs to end up with about 245 gigajoules of total kinetic energy... but then, that's the energy that is SUPPOSED to be physically imparted to the payload, not dissipated as heat. Come to think of it, the amount dissipated as heat might well be on the same order of magnitude, or even larger.

Plus, of course, the friction isn't just going to heat the brakes, it's going to heat the tether. And I don't know what happens when you dump THAT much heat into a strong but extremely thin tether; you might just outright vaporize it. In which case okay, yeah, this isn't as close to working as I'd imagined.

I'll note that I didn't actually expect us to be able to solve the braking problem. But the catch was, that was a design problem, it was something that there could conceivably be a way around if we had really badass materials and a good design.

The problem of the payload not being in the right meter at the right second for the 'catch' operation is NOT an engineering problem, and we cannot solve it. Not for existing rocket technology- and you've been assuming that the rocket that would boost the payload on its suborbital flight path is, essentially, the same as modern rockets.

I'm hoping the drone and gas brake system would increase the acceptable margins of error. Since the drone and hook are fixed-mass components, every increase in mass dedicated to the system will increase the margin of error. For example, 10% of the realistic spacecraft design described earlier (14.45 tons minus 1.5 tons in faceplate and brakes) would give a tether length of 2.8km. 15% is 4.38km. If we want the accuracy of ASAT weapons being tested 50 years ago, the payload will require 20% of its mass being dedicated to this system.
Later in this post you mention that the accuracy standard of those ASAT launches was "get within several kilometers." That standard of accuracy would be hopeless or even actively dangerous here, you'd be more likely to hit the station than to hit the target. With GPS satellites we can do better- but still not good enough to reliably hit a meter-wide target from hundreds of kilometers away WITHOUT slowing down to rendezvous carefully.

I'm not even ready to discuss the idea with the light gas gun. What I'm trying to get you to do is at least acknowledge me on this very important point, that we need as a matter of routine practice to stop and think "are the complications I'm adding going to make it more likely that a failure in some part of the system or some step of the process will prevent overall mission success?"
How would I evaluate whether some modification or new design is 'likely' to be worse than what it replaced? Some elements of my designs, such as hypervelocity braking or a reverse-gas-gun, have no real world equivalents, or at least nothing with data available online.
With hypervelocity braking you can at least take existing brakes that exert a known braking force and extrapolate. With railguns or whatever not so much. They key is to pick systems that are like things that exist, enough so that it's relevant to the comparison.

And the other issue (which has seemed like a blind spot for you so far, frankly) is procedure. You're not just designing the physical parts of this system, you're designing a plan that permits you to use them effectively. You need to have a clear understanding of what procedures are required. Adding mechanical complexity to make the procedure less complex or less fault-intolerant can be a good idea, for instance. Up to a point. Especially for a procedure that is very fault-intolerant like orbital rendezvous at extremely high speeds.

Glancing at your 'gas gun' idea, what this REALLY is, is using a piston in a cylinder as your brakes. It's a shock absorber. I'm not sure that would actually work as intended, for a couple of reasons. One is the extremely large jerk imposed on the tether and the piston. You appear to be asking the piston to move (at first) at speeds in excess of its own sound speed, which is the kind of circumstance under which stuff breaks. Stuff that you would not normally expect to break. Furthermore, the payload is subjected to thousands of gravities of acceleration at its end of the tether, accelerations comparable to being shot out of a cannon instead of launched on a rocket. And the tether is under way more force than we saw in any of the earlier designs.

It doesn't do you any good to launch ten tons of satellite instead of 2.5 tons if you then have to take what WAS a 2.5 ton satellite and bulk it up to ten tons again so that it can physically survive the accelerations of being caught into orbit.

Furthermore, the whole thing needs to withstand extremely high chamber pressures or it'll rupture. And that would be Very Bad (TM). The individual barrel segments may be extremely short in order to keep them from being too heavy to launch at all. That in turn means that there are a lot of joins between the barrel segments of the gas-gun shock absorber, which in turn means a lot of mechanical points of failure.

Your really big worry here is payload guidance and making the catch process reliable enough that people are willing to risk expensive payloads on it. One of the things that delayed the rise of commercial rocketry was the reliability issue- it took years before we could build rockets that would launch correctly 90% or more of the time without blowing up.
That's it! I'm transferring the critical failure point of each design towards things that more and more solvable by modern technology.

The first design was a simple braking wire. It was relatively easy to reach it, but required unavailable cooling methods.

The second design added a flywheel to pull on the tether in the opposite direction. It added the risk of flywheel exploding, but removed the requirement for propellants entirely.

The third design (not posted) had a bow-and-arrow configuration. Intercept is easy, no hypervelocity braking, but the payload's hook would collide with the tether at orbital velocity.

The fourth design is the skip-rotor design. No braking, no propellants, zero relative velocity intercept at the tip of the tether... but intercept precision is too high.

The fifth design I'm looking at now uses a tube of gas to brake only the small hook. Attaching the hook to a tether from the payload relaxes the intercept precision required. No braking, no propellant, low intercept precision, but it is unclear how much gas the tube would lose due to the opening for the tether. One single chamber for braking, with a uniform gas density, is each to calculate. It would be compressed into a volume 960 times smaller. This might lead to a large temperature increase. Multiple chambers are more complex, requiring a valve system with 0.1 second reaction times, and either a series of paper plates to hold the gasses, or high-strength metal plates that stack like dinner plates but do not risk being destabilized by the passage into higher-density gas. Thankfully, drag is not dependent on the pressure of the gas, so we can use high molecular mass gasses such as Argon and near-vacuum pressure.
Problem- this will have one of the same problems as a previous design.

Either:

1) The hook still collides with the tether at orbital velocity, which will probably destroy the hook, the tether, or both, due to the friction-heating issues we discussed earlier.

OR:

2) The hook matches velocity with the payload and "latches on..." (imposing very tight constraints on exactly when it is fired and with what velocity)... But that does you no good unless the hook is attached to the tether. In which case you have to accelerate the tether by several kilometers per second, which is way more than you can reasonably accomplish.

[qutoe]
If your system cannot catch its payloads 99% of the time or better (to pick an arbitrary but reasonable number)... People are going to be reluctant to launch an expensive payload into space on an expensive suborbital rocket hoping that you will be able to hold up your end of the bargain by catching the payload.

And yet, due to practical factors like guidance and timing, it is very hard for you to ensure that your system will catch its payloads reliably. This is a totally separate issue from "can you build the system," which I'm not even trying to evaluate right now because your system changes so rapidly that it's hard to be clear on which of several proposed systems you're really talking about anymore.
How would I go about evaluating the reliability of the various BOT designs? I do not think I will be able to gather relevant data on the various components, especially ones that do not exist yet. All I can do is reduce the forces, velocities and timings to levels where I believe that modern technology and materials are capable of handling. Putting them all together... well, I have no idea how they would react. [/quote]The really serious problems aren't related to the physical mechanical parts of the station and their reliability, unless you propose to dump so much force or energy into the payload that it would destroy payloads.

The really serious problems here are related to the precision required of orbital rendezvous.

Remember, one issue with ASAT missiles is that nobody in the military really minds if you need to fire two or three times to score one hit. Commercial satellite launchers aren't going to like the idea that they need to pay for three satellite launches to be sure of getting one airborne.
I don't think these numbers are a fair standard for commercial spaceflight. If we followed the logic of satellites as munitions, we could force the skip-rope design to statistically work by dividing the payload into a chain of satellites that form a long string. Each point on the string tries to rendezvous with the tip of the skip-rope. They are spaced about 80m from each other. If one of them intercepts the tether and docks correctly, the entire chain can be braked into orbit.
The string has 50 seconds to extend and orient itself from the moment the booster leaves the atmosphere. At 1000km, it has seven and a half minutes.
Fifty seconds is not a lot of time for spacecraft maneuvers. And screwing up during those fifty seconds of rushed maneuver results in failure, the probable loss of the whole string, and maybe a collision that damages the station.

Even seven and a half minutes isn't that much time by spacecraft operation standards. It is not, for example, enough time for ground control to have a conversation among themselves over whether or not the payload is on target, except in the crudest and fastest possible terms.

Plus, any serious failure in the system now results in the loss of a string of payloads instead of just one. And to launch the string of payloads, you need a first-stage booster rocket so large that it could probably launch any one of the payloads just by adding a high-Isp second stage... which in turn means that you're effectively in competition with one of your own products (the booster rocket you need for your plan to work).

Furthermore, an ASAT weapon has rather 'sloppy' constraints about the exact speed and direction it's flying in when it intercepts the target. The messier and more energetic the collision between 'sat' and ASAT, the better.
I've never heard of an ASAT weapon that deliberately tries to increase the collision energy! They are quite sensitive to intercept distance, as the 6-7km distance was noted back in 1958 as being just a bit too far for atomic warheads to have an effect on the satellite target. The closer the intercept, the smaller the warhead needed, and the smaller the missile required.
Wait... have you been thinking in terms of needing to get within kilometers of your target? Uh... no, the precision requirement here is on the order of one meter. Probably less than one meter.

A 100km (!!) error in altitude is equivalent to a 30m/s difference at 200km. The reaction control systems have the capacity to correct this error 5 times over or more. I seriously doubt modern rockets regularly place their payloads in orbits with a +/-100km altitude error.
Not seeing how your math works out. If you're crossing that distance at several kilometers per second, then 200 kilometers is, say, 30 seconds (or something on that same order of magnitude). In which case a 30 m/s burn changes your point of impact/rendezvous/whatever by about ONE kilometer, not a hundred.

Another issue is the precision of the reaction controls themselves- it's not obvious that you can actually control the velocity of the payload to a precision of millimeters per second, using thrusters designed to impart delta-v measured in meters per second. Especially not when you are literally doing this on the fly in a tremendous rush.

Then there's the totally separate issue that your payload can't correct for what happens if the rocket launch isn't exactly on time.
A 1 second delay in launch time is equivalent to a 7.5 km error in position at a 200km altitude. To be corrected, we'll need to calculate how long it takes to reach 200km.

Suppose a rocket needs 2000m/s to reach 200km altitude. It carries 12.95 tons in the second stage. First stage is set as 10 tons dry mass for engines, fuel tanks and return systems. 300m/s is used to overcome gravity and drag losses. Isp is 350 in vacuum, 300 at sea level, average 325. Required mass ratio 2.058, so 24.28 tons of propellant required.
It starts off with a TWR of 1.5, and ends at 3.09. Time to burnout is about 102.16 seconds, so minimum altitude at burnout is 11975m. The engines will likely be throttled down to extend how long main engine nozzle deflection can be used. Let's use the most extreme scenario anyways. It takes another 94 seconds to reach 200km altitude and intercept.
All of this requires the constraint LaCroix said- you're talking about extremely rapid corrections with very little time to make sure the corrections have been assessed correctly. Maneuvers like this in orbit tend to be gradual and conservative, with lots of time to perform calculations in advance. Here? You don't have that luxury, because your payload will reach the top of its trajectory within a matter of minutes.

Any course corrections have to be done FAST, which is very much the enemy of doing them accurately and reliably.

Imagine trying to be the person responsible for controlling this rendezvous in real time. How would you feel during the process? Remember, you have minutes to get everything right, your instruments only measure the movement of the payload to a precision of, oh, ten meters of distance in space, and maybe a meter per second of velocity at best. And you have to hit exactly the right meter at exactly the right millisecond.
This space dedicated to Vasily Arkhipov

Adam Reynolds
Jedi Council Member
Posts: 2137
Joined: 2004-03-27 04:51am

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby Adam Reynolds » 2017-02-02 04:14pm

This really seems to be one of those ideas that seems interesting in theory but utterly impractical in reality. Not unlike Orion Drives in that sense, in which the engineering problems with implementing the concept make it impractical to the point at which it is not built. Especially when ion drives can accomplish much the same thing more effectively.

Something to always consider with ideas like this is the question of why no one has bothered with it yet. While a case like nuclear power has non-technical reasons it is not in wider service, something like this has less such excuses.

User avatar
Lord Revan
Emperor's Hand
Posts: 10385
Joined: 2004-05-20 02:23pm
Location: Zone:classified

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby Lord Revan » 2017-02-02 06:17pm

"why hasn't anyone tried this or at least seriously suggested trying this" is actually a very good question to ask since if no-one hasn't suggested trying something there's a high chance that it's not as viable as you might think at first glance.
I may be an idiot, but I'm a tolerated idiot
"I think you completely missed the point of sigs. They're supposed to be completely homegrown in the fertile hydroponics lab of your mind, dried in your closet, rolled, and smoked...
Oh wait, that's marijuana..."Einhander Sn0m4n

User avatar
Zeropoint
Jedi Knight
Posts: 581
Joined: 2013-09-14 01:49am

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby Zeropoint » 2017-02-02 06:29pm

Matterbeam, I would suggest that you get a copy of Kerbal Space Program and play around with it. After you've managed to put things into orbit and get them back, and make things meet up in orbit, you'll understand the problems involved better than you would by just looking at figures and equations.

For one thing, you'll gain a new appreciation for proper staging techniques. If you can get a 2.5 ton payload and tons of specialized catch equipment to a suborbital space trajectory with a single stage, you can almost certainly get that same payload to orbit with a two or three stage stack at the same tech level. Staging boosts the total delta-v more than you'd expect.
I'm a cis-het white male, and I oppose racism, sexism, homophobia, and transphobia. I support treating all humans equally.

When fascism came to America, it was wrapped in the flag and carrying a cross.

That which will not bend must break and that which can be destroyed by truth should never be spared its demise.

User avatar
matterbeam
Youngling
Posts: 80
Joined: 2016-04-04 08:52pm
Contact:

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby matterbeam » 2017-02-03 03:45pm

Simon_Jester wrote:Okay, but do you understand the point I'm getting at here? The key is that improving the mindset with which you design or propose designs will improve the outcomes, making you more likely to think of things that can be made to work. And more likely to not need prompting to understand why a given idea won't work.


I promise to work on it, but also realize that changing the way you think about things is what people do for a living. Off-loading the error-checking process is the basis for discussion, after all, otherwise no-one will ever post anything except fully formed ideas they've worked months on using expert help and research.

Liquid hydrogen is a very bad choice to use as a coolant, because it has a lot of volume, is very low density, and has a very low heat of vaporization. Use water instead. The amount of energy required to heat room temperature water to and beyond the boiling point is a bit over 2600 kilojoules per kilogram. Much more energy per kilogram than you can get from liquid hydrogen as a coolant.


Boiling hydrogen from liquid to gas requires 445kJ/kg. Heating it further provides 14.5kJ/kg/K. In actual practise, heat capacity increases with temperature, but we'll use the minimum amount. 445+ 1000*14.5 = 14.9MJ/kg.

Total amount required, considering that the kinetic energy you need to burn off decreases with your velocity, is 22.88 tons. Heating water up from near-freezing to water vapour requires 2.7MJ/kg. Heating the vapour up to 1000K gives another 1.1MJ/kg, however it will start dissociating into aggressive oxygen atoms at low pressures.

Now, that still leaves you boiling off... wait, a thousand tons per second of boiling water if you're actually correct about that "2.154 gigawatts" figure. Casually computing the kinetic energy of the payload, it needs to end up with about 245 gigajoules of total kinetic energy... but then, that's the energy that is SUPPOSED to be physically imparted to the payload, not dissipated as heat. Come to think of it, the amount dissipated as heat might well be on the same order of magnitude, or even larger.


2.154GW is the peak value, sustained in the first few seconds. I'm assuming every bit of kinetic energy has to be absorbed by the brakes.

Plus, of course, the friction isn't just going to heat the brakes, it's going to heat the tether. And I don't know what happens when you dump THAT much heat into a strong but extremely thin tether; you might just outright vaporize it. In which case okay, yeah, this isn't as close to working as I'd imagined.


Let's consider solely the first second of braking. I'll the reference 10 ton payload at 1000km intercepted at 7334m/s and accelrated at 3G.
It slows down from 7334 to 7301m/s, removing an average of 2.943MJ per meter of tether. How much is absorbed into the tether material? How much is absorbed by the rail material? If we assume half-half and ignore that this will halve our cooling requirements, the tether will absorb 1.47MJ/m. With a 300% margin and 3G tension, 1m of Zylon masses 225g/m. Its heat capacity is between 0 and 1.5kJ/kg/K between 0 and 450K, and trails off to 1.75kJ/kg/K afterwards.

So 1.47MJ will heat 1 meter of that Zylon tether to a temperature of 3036K. If the brake pads are 4.5m long, it will heat up to 673K. This is the temperature at will Zylong loses 25% of its strength. References: http://www.toyobo-global.com/seihin/kc/ ... hnical.pdf. A 9G acceleration requires 13.5m long pads. It is survivable.

I'll note that I didn't actually expect us to be able to solve the braking problem. But the catch was, that was a design problem, it was something that there could conceivably be a way around if we had really badass materials and a good design.


Long brake pads spread the heat across the surface of the brakes and the tether. This allows the brake pads and tether to survive several GW braking energies. The heat absorbed has to be removed by some kind of coolant though, and that masses a lot.

The problem of the payload not being in the right meter at the right second for the 'catch' operation is NOT an engineering problem, and we cannot solve it. Not for existing rocket technology- and you've been assuming that the rocket that would boost the payload on its suborbital flight path is, essentially, the same as modern rockets.


I wonder if 2000m/s can be handled by current non-rocket launch systems.

Later in this post you mention that the accuracy standard of those ASAT launches was "get within several kilometers." That standard of accuracy would be hopeless or even actively dangerous here, you'd be more likely to hit the station than to hit the target. With GPS satellites we can do better- but still not good enough to reliably hit a meter-wide target from hundreds of kilometers away WITHOUT slowing down to rendezvous carefully.


That's ASAT technology from 1958. I suppose its improved since then. GPS satellites are a terrible option for guidance, you'd use an onboard millimeter radar, either on the station or the payload, reporting to each other.

With hypervelocity braking you can at least take existing brakes that exert a known braking force and extrapolate. With railguns or whatever not so much. They key is to pick systems that are like things that exist, enough so that it's relevant to the comparison.


A 1kg projectile at 7.33km/s is only 26MJ. These railgun energies have already been achieved and surpassed. If we need a more lightweight solution, a Voitenko compressor or a light gas gun could serve at the cost of propellant.

Glancing at your 'gas gun' idea, what this REALLY is, is using a piston in a cylinder as your brakes. It's a shock absorber. I'm not sure that would actually work as intended, for a couple of reasons. One is the extremely large jerk imposed on the tether and the piston. You appear to be asking the piston to move (at first) at speeds in excess of its own sound speed, which is the kind of circumstance under which stuff breaks. Stuff that you would not normally expect to break. Furthermore, the payload is subjected to thousands of gravities of acceleration at its end of the tether, accelerations comparable to being shot out of a cannon instead of launched on a rocket. And the tether is under way more force than we saw in any of the earlier designs.


If the 'cylinder' is accelerated to match the velocity of the hook, the jerk is near-nil. Also, the tether is accelerated at a gradient. If I push the tip of a wire sideways, it is displaced less and less up its length. When I wrote '29m/s^2 gradient', it means that ever meter further from the hook, the acceleration felt by the tether is 3G lower. Simulating the whole tether on Excel, I found the peak forces (m*a) were halfway up the tether and equal to 2.72MN, well within design constraints.

Furthermore, the whole thing needs to withstand extremely high chamber pressures or it'll rupture. And that would be Very Bad (TM). The individual barrel segments may be extremely short in order to keep them from being too heavy to launch at all. That in turn means that there are a lot of joins between the barrel segments of the gas-gun shock absorber, which in turn means a lot of mechanical points of failure.


The pressure involved are quite low. I have not accounted for increasing temperature and pressure creating a back-force that further brakes the projectile. Since these values depend on the above, Excel just throws me a 'circular equation' error.
....
(a few hours later)
....
I made some mistakes, I'll correct them. I forgot to integrate the increasing gas pressure as the stage is compressed correctly.

For the 3000G version, gas density begins at 0.000995kg/m^3.
A 28kg 3.14m^2 object travelling at 7334m/s through this gas, with a drag coefficient of 1, experiences 84kN of force.
This produces 30000m/s^2 of acceleration.
0.24 second later, it has slowed down to 134m/s and is released after 0.24 seconds.
Gas density should increase to 2.98kg/m^3, or 2994 times. The projectile has travelled 864m.
However, the compression ratio 1 millisecond beforehand suggests that gas density would only increase 120 times. This means that a single-chamber design cannot be used.

11.54 chambers require a compression ratio of 2. They cannot be all of equal length. If a chamber of length X is compressed halfway, and then the valve opens to the next chamber of length Y, the 'gas length' is equal to X/2+Y. I'll come back to this, but I'll assume that all chambers are 7.48m long and compress down to 3.73m.

What's the maximum pressure and temperature in the multi-chamber tube? We'll consider two gasses: Hydrogen and argon. Hydrogen has higher pressures but lower temperatures, argon the opposite.

The first chamber has about 26.8g of gas. In hydrogen, this is 26.8mol, in argon, this is 0.67mol. Hydrogen is kept at 30K, for a pressure of 284Pa in 23.5m^3. Argon is at 90K and a pressure of 15.9Pa. The first chamber slows down the craft by 660m/s and absorbs 129MJ of energy. Hydrogen gas reaches a temperature of about 104.7 million K according to this table: http://www.engineeringtoolbox.com/hydrogen-d_976.html. This suggests that the first stage be 'open' instead of encapsulated in a cylinder. Argon would reach 9 million K. The second stage reduces velocity by 300m/s, releasing 54.8MJ into 29.6g of gas, heating it up several million K too... This further suggests that there be a buffer zone of about 15-30m before the main gun where hydrogen gas is ejected into the path of the incoming hook and heatshield.

The final chamber experiences the highest pressures and the lowest temperatures, up to 70kg of gas at 0.74 to 1.5MPa for hydrogen, 55.7kPa to 111.4kPa for argon.

The total amount of gas is only 164kg! Considering these amounts, there is no need to really enclose them inside a tube. Airbags that burst in space, with low temperatures keeping the gasses together while the hook ploughs through them at hypersonic speed, maybe the best solution.

1) The hook still collides with the tether at orbital velocity, which will probably destroy the hook, the tether, or both, due to the friction-heating issues we discussed earlier.

OR:

2) The hook matches velocity with the payload and "latches on..." (imposing very tight constraints on exactly when it is fired and with what velocity)... But that does you no good unless the hook is attached to the tether. In which case you have to accelerate the tether by several kilometers per second, which is way more than you can reasonably accomplish.


Having a drone manoeuvre a small mass instead of the entire payload being moved might improve precision and intercept accuracy. The hook is attached to the tether. Unless a catastrophic failure occurs, the tether is not entirely accelerated to orbital velocity, but at a gradient from tip to payload.

[qutoe]The really serious problems here are related to the precision required of orbital rendezvous.[/quote]

That sounds like a technological maturity problem to me.

Fifty seconds is not a lot of time for spacecraft maneuvers. And screwing up during those fifty seconds of rushed maneuver results in failure, the probable loss of the whole string, and maybe a collision that damages the station.

Even seven and a half minutes isn't that much time by spacecraft operation standards. It is not, for example, enough time for ground control to have a conversation among themselves over whether or not the payload is on target, except in the crudest and fastest possible terms.


150m/s in 50 seconds is a tiny acceleration minimum requirement of 3m/s^2. I don't think these are rushed manoeuvres. 7.5m minutes is quite enough, considering that the burn time on the Falcon 9 first stage is 3 minutes. Based on this livestream of the Iridium1 mission (http://www.spacex.com/webcast) I see that time from launch to SECO-1 is about 9 minutes. I think your impression is prolonged by the 43 minute wait for SECO-2 and the orbital insertion manoeuvre.

Plus, any serious failure in the system now results in the loss of a string of payloads instead of just one. And to launch the string of payloads, you need a first-stage booster rocket so large that it could probably launch any one of the payloads just by adding a high-Isp second stage... which in turn means that you're effectively in competition with one of your own products (the booster rocket you need for your plan to work).


I was thinking of a string of microsatellites, which would have the same mass as a bundle and a tether. So the payload 'lost' would be equivalent. Using a 100-spoke skip-rope design, a 10% chance of success can be turned into 65% with 10 attempts over the course of 8.6 seconds and 6.27km tether length. A base 30% chance would become 97% success.

Wait... have you been thinking in terms of needing to get within kilometers of your target? Uh... no, the precision requirement here is on the order of one meter. Probably less than one meter.


The accuracy requirement is 'staged'. The payload is positioned within a few km of the tether, and the drone is positioned within a few meters. However, the drone starts out at a much smaller separation and in a vacuum, with a much smaller payload to position. Magnetic aids that funnel the hook into position might reduce the precision requirements even further.

Not seeing how your math works out. If you're crossing that distance at several kilometers per second, then 200 kilometers is, say, 30 seconds (or something on that same order of magnitude). In which case a 30 m/s burn changes your point of impact/rendezvous/whatever by about ONE kilometer, not a hundred.


I was thinking vertical error, you were thinking horizontal error, hence our different results.

Another issue is the precision of the reaction controls themselves- it's not obvious that you can actually control the velocity of the payload to a precision of millimeters per second, using thrusters designed to impart delta-v measured in meters per second. Especially not when you are literally doing this on the fly in a tremendous rush.


I found manoeuvring system that uses pre-cut miniature solid rockets (http://dsspropulsion.com/wp-content/upl ... ebsite.pdf) that provide exact amounts of deltaV to the satellite. It might work here.

All of this requires the constraint LaCroix said- you're talking about extremely rapid corrections with very little time to make sure the corrections have been assessed correctly. Maneuvers like this in orbit tend to be gradual and conservative, with lots of time to perform calculations in advance. Here? You don't have that luxury, because your payload will reach the top of its trajectory within a matter of minutes.

Any course corrections have to be done FAST, which is very much the enemy of doing them accurately and reliably.


ASAT weapons do not do it slowly or gradually, and they only have one pass. Anti-ballistic missiles such as the SM-6 from Raytheon or the Exoatmospheric Kill Vehicle intercept very small targets with very good accuracy ... good enough for a kinetic kill, no nuclear warheads (http://www.raytheon.com/capabilities/products/ekv/).

I think modern technology, albeit restricted to military application, has the speed, precision and reliability to perform the tasks required to deliver the hook to the gas brakes.

Also, there is no reason why the payload could not employ several tether/hook/drone systems to get statistical odds on its sides. At a half-ton investment each, it doesn't cost that much in mass requirements.
Google + : matterbeamTSF

Hard SF blog: ToughSF

MetaSeed: Worldbuilding and Game Design discussion

User avatar
matterbeam
Youngling
Posts: 80
Joined: 2016-04-04 08:52pm
Contact:

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby matterbeam » 2017-02-03 03:48pm

Zeropoint wrote:Matterbeam, I would suggest that you get a copy of Kerbal Space Program and play around with it. After you've managed to put things into orbit and get them back, and make things meet up in orbit, you'll understand the problems involved better than you would by just looking at figures and equations.

For one thing, you'll gain a new appreciation for proper staging techniques. If you can get a 2.5 ton payload and tons of specialized catch equipment to a suborbital space trajectory with a single stage, you can almost certainly get that same payload to orbit with a two or three stage stack at the same tech level. Staging boosts the total delta-v more than you'd expect.


I have been playing KSP since the 0.90 beta, even made a few mods for it. I also played some Children of a Dead Earth, which has even more realistic orbits.

The 2.5 ton figure is not quite relevant in this case.

Adam Reynolds wrote:This really seems to be one of those ideas that seems interesting in theory but utterly impractical in reality. Not unlike Orion Drives in that sense, in which the engineering problems with implementing the concept make it impractical to the point at which it is not built. Especially when ion drives can accomplish much the same thing more effectively.

Something to always consider with ideas like this is the question of why no one has bothered with it yet. While a case like nuclear power has non-technical reasons it is not in wider service, something like this has less such excuses.


Lord Revan wrote:"why hasn't anyone tried this or at least seriously suggested trying this" is actually a very good question to ask since if no-one hasn't suggested trying something there's a high chance that it's not as viable as you might think at first glance.


This is why I have strived to restrict my materials and technological requirements to what is available today. The Orion had to handwave some issues away, such as the suspension system.

Also, saying not to bother to explore a concept because you or I can't find it on the internet is the absolute anti-thesis to interesting discussions.
Google + : matterbeamTSF

Hard SF blog: ToughSF

MetaSeed: Worldbuilding and Game Design discussion

Simon_Jester
Emperor's Hand
Posts: 28661
Joined: 2009-05-23 07:29pm

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby Simon_Jester » 2017-02-03 04:13pm

matterbeam wrote:
Simon_Jester wrote:Liquid hydrogen is a very bad choice to use as a coolant, because it has a lot of volume, is very low density, and has a very low heat of vaporization. Use water instead. The amount of energy required to heat room temperature water to and beyond the boiling point is a bit over 2600 kilojoules per kilogram. Much more energy per kilogram than you can get from liquid hydrogen as a coolant.
Boiling hydrogen from liquid to gas requires 445kJ/kg. Heating it further provides 14.5kJ/kg/K. In actual practise, heat capacity increases with temperature, but we'll use the minimum amount. 445+ 1000*14.5 = 14.9MJ/kg.
Once the liquid hydrogen has boiled, it will rapidly escape from the coolant container you put it in. Alternatively, if you're trying to confine the hydrogen in a fixed container so that it is unable to escape, you will encounter huge, rapidly increasing gas pressure that causes the coolant container to burst open and explode. The large influx of energy associated with a boiling liquid is, by definition, the energy required to take that material from a compact 'liquid' form into a diffuse 'gas' form.

Review your high school chemistry book on the meaning of "heat of vaporization."

Seriously, when using liquid coolant, after the coolant vaporizes you're done. It will no longer function effectively as a coolant. Either it will explosively blow holes in the coolant pipes, or it will safely boil off and be lost.

Total amount required, considering that the kinetic energy you need to burn off decreases with your velocity, is 22.88 tons. Heating water up from near-freezing to water vapour requires 2.7MJ/kg. Heating the vapour up to 1000K gives another 1.1MJ/kg, however it will start dissociating into aggressive oxygen atoms at low pressures.
Exactly how does heating hydrogen from 20K to 1000K absorb thirteen times more energy than heating water from 373K to 1000K? You're asserting that it does.

Also, what effect will tons of extremely hot hydrogen gas have on the interior of whatever cryogenic tank you were once containing an equal quantity of liquid hydrogen? Hydrogen can be rather corrosive, you know.

2.154GW is the peak value, sustained in the first few seconds. I'm assuming every bit of kinetic energy has to be absorbed by the brakes.
By definition, energy absorbed by the brakes as waste heat is NOT energy that goes into accelerating the payload.

Review basic thermodynamics.

Plus, of course, the friction isn't just going to heat the brakes, it's going to heat the tether. And I don't know what happens when you dump THAT much heat into a strong but extremely thin tether; you might just outright vaporize it. In which case okay, yeah, this isn't as close to working as I'd imagined.


Let's consider solely the first second of braking. I'll the reference 10 ton payload at 1000km intercepted at 7334m/s and accelrated at 3G.
It slows down from 7334 to 7301m/s, removing an average of 2.943MJ per meter of tether. How much is absorbed into the tether material? How much is absorbed by the rail material? If we assume half-half and ignore that this will halve our cooling requirements, the tether will absorb 1.47MJ/m. With a 300% margin and 3G tension, 1m of Zylon masses 225g/m. Its heat capacity is between 0 and 1.5kJ/kg/K between 0 and 450K, and trails off to 1.75kJ/kg/K afterwards.

So 1.47MJ will heat 1 meter of that Zylon tether to a temperature of 3036K. If the brake pads are 4.5m long, it will heat up to 673K. This is the temperature at will Zylong loses 25% of its strength. References: http://www.toyobo-global.com/seihin/kc/ ... hnical.pdf. A 9G acceleration requires 13.5m long pads. It is survivable.
The problem is that the heat isn't being uniformly applied to the tether, it's being applied to the surface. The interaction between the brakes and the tether doesn't just heat the tether; it ablatively melts the outermost layer. Unless Zylon is a much, much better conductor of heat than I expect.

I'll note that I didn't actually expect us to be able to solve the braking problem. But the catch was, that was a design problem, it was something that there could conceivably be a way around if we had really badass materials and a good design.
Long brake pads spread the heat across the surface of the brakes and the tether. This allows the brake pads and tether to survive several GW braking energies. The heat absorbed has to be removed by some kind of coolant though, and that masses a lot.
Yes, but this isn't a problem you're going to be able to duck out of entirely. The total quantities of mass being slung around here are too large; something is going to have to give.

The problem of the payload not being in the right meter at the right second for the 'catch' operation is NOT an engineering problem, and we cannot solve it. Not for existing rocket technology- and you've been assuming that the rocket that would boost the payload on its suborbital flight path is, essentially, the same as modern rockets.
I wonder if 2000m/s can be handled by current non-rocket launch systems.
Like what?

Furthermore, such systems are not necessarily going to be more accurate and reliable than a suborbital rocket. They might even be less so.

Later in this post you mention that the accuracy standard of those ASAT launches was "get within several kilometers." That standard of accuracy would be hopeless or even actively dangerous here, you'd be more likely to hit the station than to hit the target. With GPS satellites we can do better- but still not good enough to reliably hit a meter-wide target from hundreds of kilometers away WITHOUT slowing down to rendezvous carefully.
That's ASAT technology from 1958. I suppose its improved since then. GPS satellites are a terrible option for guidance, you'd use an onboard millimeter radar, either on the station or the payload, reporting to each other.
When the payload is launched, the station and payload are many hundreds or thousands of kilometers apart. The payload cannot acquire the station on radar until it has cleared the atmosphere (and the payload fairing is out of the way), and has had time to deploy a radar antenna, AND until the payload and station have line of sight on each other above the curve of the Earth. Given the timescales involved, that may not give them much time to track each other.

For final approach, radar will be necessary. But for tracking and ensuring that the payload is going in the right general direction, before it gets close enough for a radar lock with the station, you need a mix of other systems like ground-based radars and GPS.

Do you or do you not know the accuracy of these systems?

With hypervelocity braking you can at least take existing brakes that exert a known braking force and extrapolate. With railguns or whatever not so much. They key is to pick systems that are like things that exist, enough so that it's relevant to the comparison.
A 1kg projectile at 7.33km/s is only 26MJ. These railgun energies have already been achieved and surpassed. If we need a more lightweight solution, a Voitenko compressor or a light gas gun could serve at the cost of propellant.
The energies have been achieved, the muzzle velocities haven't. We don't know everything that's going to happen inside a light gas gun that tries to handle 7000 m/s muzzle velocities on a multi-ton payload. We can extrapolate, but that takes a more detailed analysis.

Glancing at your 'gas gun' idea, what this REALLY is, is using a piston in a cylinder as your brakes. It's a shock absorber. I'm not sure that would actually work as intended, for a couple of reasons. One is the extremely large jerk imposed on the tether and the piston. You appear to be asking the piston to move (at first) at speeds in excess of its own sound speed, which is the kind of circumstance under which stuff breaks. Stuff that you would not normally expect to break. Furthermore, the payload is subjected to thousands of gravities of acceleration at its end of the tether, accelerations comparable to being shot out of a cannon instead of launched on a rocket. And the tether is under way more force than we saw in any of the earlier designs.
If the 'cylinder' is accelerated to match the velocity of the hook, the jerk is near-nil. Also, the tether is accelerated at a gradient. If I push the tip of a wire sideways, it is displaced less and less up its length. When I wrote '29m/s^2 gradient', it means that ever meter further from the hook, the acceleration felt by the tether is 3G lower. Simulating the whole tether on Excel, I found the peak forces (m*a) were halfway up the tether and equal to 2.72MN, well within design constraints.
If the cylinder has matched velocity with the hook, what actually does the work of accelerating the payload?

Seriously, SOMETHING has to exert massive force on the payload, somewhere, at some time. You can't design around that aspect of the system, because that is the entire point of the system in the first place.

So which part of the system is it? You're the one designing this and I'm the one trying to figure out which version of your launch system you're visualizing today. But I'm not psychic and time presses, so why don't you tell me which part is undergoing extreme stress? What accelerations are being applied to the payload? What physical object is responsible for exerting the force that imparts this acceleration?

The total amount of gas is only 164kg! Considering these amounts, there is no need to really enclose them inside a tube. Airbags that burst in space, with low temperatures keeping the gasses together while the hook ploughs through them at hypersonic speed, maybe the best solution.
So to be clear, you expect to impart the desired acceleration by dragging a piston through a series of airbags. Do I have that correct?

Again, sooner or later, great force must be exerted on a multi-ton payload. You cannot finesse your way around this, because your system is useless if it does not accelerate massive payloads.

The really serious problems here are related to the precision required of orbital rendezvous.
That sounds like a technological maturity problem to me.
Yes, but not a problem that we can solve faster than we can significantly improve the state of material science. By the time it's possible to do what must happen for your tether systems to work, there will be other, better ways to accomplish the same things.

150m/s in 50 seconds is a tiny acceleration minimum requirement of 3m/s^2. I don't think these are rushed manoeuvres. 7.5m minutes is quite enough, considering that the burn time on the Falcon 9 first stage is 3 minutes. Based on this livestream of the Iridium1 mission (http://www.spacex.com/webcast) I see that time from launch to SECO-1 is about 9 minutes. I think your impression is prolonged by the 43 minute wait for SECO-2 and the orbital insertion manoeuvre.
Because those are the maneuvers that are similar to what you're doing!

The first stage burnout exists to lob the second stage and payload onto the right general trajectory. Fine control, placing the payload on the exact right trajectory, and so on- those are all done later, more gradually.

This is why, for instance, you talk about having maneuvering thrusters that can accelerate the payload at 0.3g. Hint: that is not especially realistic, for a lightweight maneuvering thruster package that can be used for fine precision control. RCS thrusters tend to have very low thrust, precisely because you need to be able to use them to control your velocity to a precision of centimeters per second for high-precision docking maneuvers.

ASAT weapons do not do it slowly or gradually, and they only have one pass. Anti-ballistic missiles such as the SM-6 from Raytheon or the Exoatmospheric Kill Vehicle intercept very small targets with very good accuracy ... good enough for a kinetic kill, no nuclear warheads (http://www.raytheon.com/capabilities/products/ekv/).

I think modern technology, albeit restricted to military application, has the speed, precision and reliability to perform the tasks required to deliver the hook to the gas brakes.
ASAT weapons also collide with the target at high speeds rather than rendezvousing gently. This is a much simpler problem.


Another issue is the precision of the reaction controls themselves- it's not obvious that you can actually control the velocity of the payload to a precision of millimeters per second, using thrusters designed to impart delta-v measured in meters per second. Especially not when you are literally doing this on the fly in a tremendous rush.
I found manoeuvring system that uses pre-cut miniature solid rockets (http://dsspropulsion.com/wp-content/upl ... ebsite.pdf) that provide exact amounts of deltaV to the satellite. It might work here.
Oh, sure, if we could predict in advance exactly what the deviations from the ideal flight path were going to crop up, and build a custom engine ahead of time to cancel those deviations out...

...Really? :roll:

I was thinking of a string of microsatellites, which would have the same mass as a bundle and a tether. So the payload 'lost' would be equivalent. Using a 100-spoke skip-rope design, a 10% chance of success can be turned into 65% with 10 attempts over the course of 8.6 seconds and 6.27km tether length. A base 30% chance would become 97% success.
I'm going to be honest, your idea is now sufficiently complex that I no longer believe this can be implemented. I can't trust your math because you routinely ignore important aspects of physical systems, completely by accident and without realizing that you have done so.

When real science and engineering people talk, they usually start from the assumption that they can trust each other's math. They still cross-check, but they can at least assume that there aren't glaring mistakes in literally every calculation.

The problem is that you've overlooked enough important things and made enough errors that I can no longer make that assumption. I can't trust you to know what you're talking about, even about basic simple things, until I've run the math myself. Which means that if you spend hours calculating something, I can't spend hours verifying it; I haven't got the time.

This is, again, why I keep pushing you to spot more of your own mistakes. Outsourcing literally all error-checking onto others places undue demands on our time and makes us disinclined to examing your proposals in detail.

I'm going to be quite honest, the next time I see you make a fundamental mistake based out of ignorance of basic scientific facts (like "heat applied to a rope by brakes hits the outside of the rope first" or "oh I forgot I need umpty tons of propellant/coolant lol"), I'm just going to give up on you entirely. I like the idea of trying to help you learn this stuff in the abstract, but I can't take the combined responsibility of being your K-12 science teacher on every one of a dozen different topics.

There is a certain "you must be this tall to enter" level of background knowledge required to talk intelligently about systems like this, and that's the case for a good reason.
This space dedicated to Vasily Arkhipov

User avatar
matterbeam
Youngling
Posts: 80
Joined: 2016-04-04 08:52pm
Contact:

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby matterbeam » 2017-02-03 08:16pm

Simon_Jester wrote:Once the liquid hydrogen has boiled, it will rapidly escape from the coolant container you put it in. Alternatively, if you're trying to confine the hydrogen in a fixed container so that it is unable to escape, you will encounter huge, rapidly increasing gas pressure that causes the coolant container to burst open and explode. The large influx of energy associated with a boiling liquid is, by definition, the energy required to take that material from a compact 'liquid' form into a diffuse 'gas' form.


I was only trying to calculate the magnitude of how bad the idea was, not trying to solve it.
I'm sure there are ways to continue heating gaseous hydrogen after the first liquid pass. I detailed some of the problems with trying to recover or contain the liquid hydrogen the first time this was mentioned, so I am not ignoring to the pressurisation issues.

Review your high school chemistry book on the meaning of "heat of vaporization."


Heat of vaporization is the enthalpy of vaporization, the energy required to boil a liquid, which is 445kJ/kg for liquid hydrogen. Why?

Seriously, when using liquid coolant, after the coolant vaporizes you're done. It will no longer function effectively as a coolant. Either it will explosively blow holes in the coolant pipes, or it will safely boil off and be lost.


I... agree? Yes?

Exactly how does heating hydrogen from 20K to 1000K absorb thirteen times more energy than heating water from 373K to 1000K? You're asserting that it does.


Yes. Liquid hydrogen absorbs 445 (some sources say 461) kJ/kg when boiling. Then, over 14.5kJ/kg/K in gaseous form. Water absorbs 2257kJ/kg when boiling, but only 1-2kJ/kg in vapor form.

Also, what effect will tons of extremely hot hydrogen gas have on the interior of whatever cryogenic tank you were once containing an equal quantity of liquid hydrogen? Hydrogen can be rather corrosive, you know.


Yes, which is why it is a bad idea that I did not develop on.

By definition, energy absorbed by the brakes as waste heat is NOT energy that goes into accelerating the payload.

Review basic thermodynamics.


In the basic runway version of the BOT, from the point of view of the station, the payload comes to rest relative to the tether. Therefore it has to remove kinetic energy as heat.

The problem is that the heat isn't being uniformly applied to the tether, it's being applied to the surface. The interaction between the brakes and the tether doesn't just heat the tether; it ablatively melts the outermost layer. Unless Zylon is a much, much better conductor of heat than I expect.


The Zylon tether required to survive the braking force of a 10 ton payload at 3G is 8.33mm thick.
If we considered this a problem we had to solve, I would propose a ribbon-shaped tether, which maximizes surface area for braking AND heat transfer. For example, it can be shaped into a rectangle 0.5mm thick and .

Heat conductivity in Zylon is hard to find, but I've read it stated as twice as good as Dyneema, which has 60-100W/m-K (http://users.mrl.illinois.edu/cahill/psu_sep13.pdf), at least at low temperatures. It can be estimated to be 120 W/m-K. At 673K, it should conduct heat at a rate of about 19.4 to 32.3MW/m^2 to its center. The 0.5mm ribbon absorbs at a rate of 323 to 538.6MW/m^2 to its center.

A 4.5m long brake pad on either side will have a surface area in contact with the ribbon-shaped tether of 0.981m^2. It distributes the heat load at a rate of 2.2GW/m^2. To bring it down to survivable levels, it needs brake pads to be more than 37.4m long.

[Yes, but this isn't a problem you're going to be able to duck out of entirely. The total quantities of mass being slung around here are too large; something is going to have to give.


Estimating the loads, the simple runway tether will require ridiculously complex or massive cooling systems and a slightly less ridiculous set of brake-skis. The airbag-brakes version has much lower forces and energies involved.

Like what? Furthermore, such systems are not necessarily going to be more accurate and reliable than a suborbital rocket. They might even be less so.


A railgun launch system would likely produce a very reliable, very predictable trajectory every time. Getting 10 tons to 2km/s requires 20GJ or more, however.

When the payload is launched, the station and payload are many hundreds or thousands of kilometers apart. The payload cannot acquire the station on radar until it has cleared the atmosphere (and the payload fairing is out of the way), and has had time to deploy a radar antenna, AND until the payload and station have line of sight on each other above the curve of the Earth. Given the timescales involved, that may not give them much time to track each other.


Radar on ground stations can track the BOT using longer wavelengths until the rendezvous is closer, from behind the horizon. If more precise radar is required, another satellite in space can provide tracking. Light-speed lag is not an issue, and radar power is well adapted to the ranges involved.

q
For final approach, radar will be necessary. But for tracking and ensuring that the payload is going in the right general direction, before it gets close enough for a radar lock with the station, you need a mix of other systems like ground-based radars and GPS.


I agree.

Do you or do you not know the accuracy of these systems?


I know that 1cm wavelength radar is pretty much un-impeded by the atmosphere and two such stations can track both the payload and the BOT target to much more accuracy than will ever be needed? Millimeter radar will be needed in space for guiding the drone and hook.

The energies have been achieved, the muzzle velocities haven't. We don't know everything that's going to happen inside a light gas gun that tries to handle 7000 m/s muzzle velocities on a multi-ton payload. We can extrapolate, but that takes a more detailed analysis.


I think there is some confusion here. The railgun/voitenko/ect high speed guns are used to accelerate the 1kg or less heatshield the hook sits on while it is ploughing through the braking gas. The energies involved are very much within our reach.

If the cylinder has matched velocity with the hook, what actually does the work of accelerating the payload?

Seriously, SOMETHING has to exert massive force on the payload, somewhere, at some time. You can't design around that aspect of the system, because that is the entire point of the system in the first place.


I think there is some confusion here. The hook sits on a heatshield for 0.24 second to slow it down enough for an arrestor wire to catch it and push bolts through the holes it has. Once the main tether is bolted with the hook, the tether-hook-payload tether forms a continuous line that is released and starts the previously described flywheel+pulley train braking process.

This two-part system makes sure that the only piece that suffers from 'harsh' forces is the solid lump of hook steel. None of the tether, brakes, flywheel, pulleys or payload have to suffer more than 3-9G depending on altitude.

So which part of the system is it? You're the one designing this and I'm the one trying to figure out which version of your launch system you're visualizing today. But I'm not psychic and time presses, so why don't you tell me which part is undergoing extreme stress? What accelerations are being applied to the payload? What physical object is responsible for exerting the force that imparts this acceleration?


I wrote down a list of the versions that I have come up with to solve each of the issues that were raised in a previous post. Would you like me to keep track of them on the OP? Here it is again:
The first design was a simple braking wire. It was relatively easy to reach it, but required unavailable cooling methods.

The second design added a flywheel to pull on the tether in the opposite direction. It added the risk of flywheel exploding, but removed the requirement for propellants entirely.

The third design (not posted) had a bow-and-arrow configuration. Intercept is easy, no hypervelocity braking, but the payload's hook would collide with the tether at orbital velocity.

The fourth design is the skip-rotor design. No braking, no propellants, zero relative velocity intercept at the tip of the tether... but intercept precision is too high.

The fifth design I'm looking at now uses a tube of gas to brake only the small hook.


So to be clear, you expect to impart the desired acceleration by dragging a piston through a series of airbags. Do I have that correct?


Yes.

Again, sooner or later, great force must be exerted on a multi-ton payload. You cannot finesse your way around this, because your system is useless if it does not accelerate massive payloads.


That's the role of the main pulley-train and brakes system.

[Yes, but not a problem that we can solve faster than we can significantly improve the state of material science. By the time it's possible to do what must happen for your tether systems to work, there will be other, better ways to accomplish the same things.


I have been putting a lot of effort into trying to devise solutions that do not require improvements in materials technology.

This is why, for instance, you talk about having maneuvering thrusters that can accelerate the payload at 0.3g. Hint: that is not especially realistic, for a lightweight maneuvering thruster package that can be used for fine precision control. RCS thrusters tend to have very low thrust, precisely because you need to be able to use them to control your velocity to a precision of centimeters per second for high-precision docking maneuvers.


0.3g is an emergency burn that burns through all available deltaV. On the main payload, this can be achieved by a 29.4kN thruster. Six of them would mass about 352kg if use the AJ190-10 like the Space Shuttle.

ASAT weapons also collide with the target at high speeds rather than rendezvousing gently. This is a much simpler problem.


Well, the entire objective behind the BOT is controlled collision, so I do not see why the capabilities of ASATs/ABMs cannot be transferred to larger payload. If a kinetic kill vehicle can collide with a small satellite, then a payload can be guided near the gas bags and the tether.

Oh, sure, if we could predict in advance exactly what the deviations from the ideal flight path were going to crop up, and build a custom engine ahead of time to cancel those deviations out...

...Really? :roll:


I don't see how you arrived to that conclusion. If the miniature solid rockets provide precisely 0.1m/s each, the only custom-building is tailoring the propellant in each successive rocket to be smaller to account for the mass lost after each burn. For example, the first solid rocket would be 10 times longer than the final rocket, so that they each provide a precise amount of deltaV per burn. I believe a modern smartphone can handle the software required to control and predict the sequence of burns required to achieve a specific velocity on 2 axes..

I'm going to be honest, your idea is now sufficiently complex that I no longer believe this can be implemented. I can't trust your math because you routinely ignore important aspects of physical systems, completely by accident and without realizing that you have done so.


Is complexity a good estimate for whether something works? An example I used before is the F1 car's 80000 parts. It is complex, but racers routinely trust their lives to it at 300km/h.

If I had to break down the current design, I'd list these components:
Payload end:
-Rocket booster
-Payload
-Payload safety and abort systems
-Payload RCS
-Payload radar
-Payload tether
-Tether drone
-Payload hook

Tether end:
-Gas release tanks
-Airbags
-Arrestor wire
-Bolt insertor and release mechanism
-Segmented Tether
-Inter-segment tether connections
-Pulleys
-Pulley brakes
-Pulley suspension
-Flywheel
-Flywheel brakes
-Flywheel/tether connection
-Electric engine
-Solar panels
-Off-axis flywheels for maneuvering
-Station Radar

When real science and engineering people talk, they usually start from the assumption that they can trust each other's math. They still cross-check, but they can at least assume that there aren't glaring mistakes in literally every calculation.


I think you'll have to back that statement up. I don't believe I'm making wild mistakes in literally every calculation.

The problem is that you've overlooked enough important things and made enough errors that I can no longer make that assumption. I can't trust you to know what you're talking about, even about basic simple things, until I've run the math myself.


Many of these 'overlooked' problems seem to result from a lack of communication, such as your confusion on whether the hook or the payload was being braked by the airbags.

Which means that if you spend hours calculating something, I can't spend hours verifying it; I haven't got the time.


I am grateful for the time you have already given. For each hour of maths, I spend two hours repeating my calculations under different assumptions and three hours doing research.

This is, again, why I keep pushing you to spot more of your own mistakes. Outsourcing literally all error-checking onto others places undue demands on our time and makes us disinclined to examing your proposals in detail.

I'm going to be quite honest, the next time I see you make a fundamental mistake based out of ignorance of basic scientific facts (like "heat applied to a rope by brakes hits the outside of the rope first" or "oh I forgot I need umpty tons of propellant/coolant lol"), I'm just going to give up on you entirely. I like the idea of trying to help you learn this stuff in the abstract, but I can't take the combined responsibility of being your K-12 science teacher on every one of a dozen different topics.


I was not formally taught to remember check thermal conductivity of a material under braking forces. I don't have the instincts that tell me that a tapering length is the solution to the maximum velocity of a rotating tether. These are things I research and come up with on my own, in my free time, so please recognize that I am trying my best, and no, they are not taught in the american K-12 science classroom.

There is a certain "you must be this tall to enter" level of background knowledge required to talk intelligently about systems like this, and that's the case for a good reason.


I'm sorry you feel this way, but I would have liked this to be stated from the beginning before 'one more mistake and I'm out' ultimatums are given.
Google + : matterbeamTSF

Hard SF blog: ToughSF

MetaSeed: Worldbuilding and Game Design discussion

User avatar
matterbeam
Youngling
Posts: 80
Joined: 2016-04-04 08:52pm
Contact:

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby matterbeam » 2017-02-03 08:29pm

Simon_Jester wrote:Once the liquid hydrogen has boiled, it will rapidly escape from the coolant container you put it in. Alternatively, if you're trying to confine the hydrogen in a fixed container so that it is unable to escape, you will encounter huge, rapidly increasing gas pressure that causes the coolant container to burst open and explode. The large influx of energy associated with a boiling liquid is, by definition, the energy required to take that material from a compact 'liquid' form into a diffuse 'gas' form.


I was only trying to calculate the magnitude of how bad the idea was, not trying to solve it.
I'm sure there are ways to continue heating gaseous hydrogen after the first liquid-to-gas pass. I mentioned some of the problems with this, and with trying to recover or contain the liquid hydrogen, in the first time this was mentioned, so I am not ignoring to the pressurization or other issues .

Review your high school chemistry book on the meaning of "heat of vaporization."


Heat of vaporization is the enthalpy of vaporization, the energy required to boil a liquid, which is 445kJ/kg for liquid hydrogen. Why?

Seriously, when using liquid coolant, after the coolant vaporizes you're done. It will no longer function effectively as a coolant. Either it will explosively blow holes in the coolant pipes, or it will safely boil off and be lost.


I... agree? Yes?

Exactly how does heating hydrogen from 20K to 1000K absorb thirteen times more energy than heating water from 373K to 1000K? You're asserting that it does.


Yes. Liquid hydrogen absorbs 445 (some sources say 461) kJ/kg when boiling. Then, over 14.5kJ/kg/K in gaseous form. Water absorbs 2257kJ/kg when boiling, but only 1-2kJ/kg in vapor form. I calculated using these figures to give a rough estimate of how much coolant is needed.

Also, what effect will tons of extremely hot hydrogen gas have on the interior of whatever cryogenic tank you were once containing an equal quantity of liquid hydrogen? Hydrogen can be rather corrosive, you know.


Yes, which is why it is a bad idea that I did not develop on.

By definition, energy absorbed by the brakes as waste heat is NOT energy that goes into accelerating the payload.

Review basic thermodynamics.


In the basic runway version of the BOT, from the point of view of the station, the payload comes to rest relative to the tether. Therefore it has to remove kinetic energy as heat.

The problem is that the heat isn't being uniformly applied to the tether, it's being applied to the surface. The interaction between the brakes and the tether doesn't just heat the tether; it ablatively melts the outermost layer. Unless Zylon is a much, much better conductor of heat than I expect.


A cylindrical Zylon tether required to survive the braking force of a 10 ton payload at 3G is 8.33mm thick.
If we considered this a problem we had to solve, I would propose a ribbon-shaped tether, which maximizes surface area for both braking and heat transfer. For example, it can be shaped into a rectangle 0.5mm thick and 10.9cm wide.

Heat conductivity in Zylon is hard to find, but I've read it stated as twice as good as Dyneema, which has 60-100W/m-K (http://users.mrl.illinois.edu/cahill/psu_sep13.pdf), at least at low temperatures. It can be estimated to be 120 W/m-K for Zylon. At 673K, it should conduct heat at a rate of about 19.4 to 32.3MW/m^2 to its center. The 0.5mm ribbon absorbs at a rate of 323 to 538.6MW/m^2 to its center. 673K is so that Zylon does not lose more than 25% of its strength.

A 4.5m long brake pad on either side will have a surface area in contact with the ribbon-shaped tether of 0.981m^2. It distributes the heat load at a rate of 2.2GW/m^2. To bring it down to survivable levels, it needs brake pads to be more than 37.4m long.

[Yes, but this isn't a problem you're going to be able to duck out of entirely. The total quantities of mass being slung around here are too large; something is going to have to give.


Estimating the loads, the simple runway tether will require ridiculously complex or massive cooling systems and a slightly less ridiculous set of brake-skis. The airbag-brakes version has much lower forces and energies involved.

Like what? Furthermore, such systems are not necessarily going to be more accurate and reliable than a suborbital rocket. They might even be less so.


A railgun launch system would likely produce a very reliable, very predictable trajectory every time. Getting 10 tons to 2km/s requires 20GJ or more, however. Hypersonic launch craft are another option, as are smaller versions of a launch loop or space fountain.

When the payload is launched, the station and payload are many hundreds or thousands of kilometers apart. The payload cannot acquire the station on radar until it has cleared the atmosphere (and the payload fairing is out of the way), and has had time to deploy a radar antenna, AND until the payload and station have line of sight on each other above the curve of the Earth. Given the timescales involved, that may not give them much time to track each other.


Radar on ground stations can track the BOT using longer wavelengths until the rendezvous is closer, from behind the horizon and through 100km or more of atmosphere. If more precise radar is required, another satellite in space can provide tracking from above, using short wavelength radar and telemetry. Light-speed lag is not an issue, and currently available radar power is well adapted to the ranges involved.

q
For final approach, radar will be necessary. But for tracking and ensuring that the payload is going in the right general direction, before it gets close enough for a radar lock with the station, you need a mix of other systems like ground-based radars and GPS.


I agree.

Do you or do you not know the accuracy of these systems?


I know that 1cm wavelength radar is pretty much un-impeded by the atmosphere and two such stations below the rendezvous site can track both the payload and the BOT target to much more accuracy than will ever be needed. Millimeter radar will be needed in space for guiding the drone and hook.

The energies have been achieved, the muzzle velocities haven't. We don't know everything that's going to happen inside a light gas gun that tries to handle 7000 m/s muzzle velocities on a multi-ton payload. We can extrapolate, but that takes a more detailed analysis.


I think there is some confusion here. The railgun/voitenko/ect high speed guns are used to accelerate the 1kg or less heatshield the hook sits on while it is ploughing through the braking gas. The energies involved are very much within our reach.

If the cylinder has matched velocity with the hook, what actually does the work of accelerating the payload?

Seriously, SOMETHING has to exert massive force on the payload, somewhere, at some time. You can't design around that aspect of the system, because that is the entire point of the system in the first place.


I think there is some confusion here. The hook sits on a heatshield for 0.24 seconds, to slow it down enough for an arrestor wire to catch it and push bolts through the holes it has. Once the main tether is bolted to the hook, the main tether/hook/payload tether forms a continuous line that is released and starts the previously described flywheel+pulley train braking process.

This two step system makes sure that the only piece that suffers from 'harsh' forces is the solid lump of hook steel. None of the tether, brakes, flywheel, pulleys or payload have to suffer more than 3-9G depending on altitude.

So which part of the system is it? You're the one designing this and I'm the one trying to figure out which version of your launch system you're visualizing today. But I'm not psychic and time presses, so why don't you tell me which part is undergoing extreme stress? What accelerations are being applied to the payload? What physical object is responsible for exerting the force that imparts this acceleration?


I wrote down a list of the versions that I have come up with to solve each of the issues that were raised, in a previous post. Would you like me to keep track of them on the OP? Here it is again:

The first design was a simple braking wire. It was relatively easy to reach it, but required unavailable cooling methods.

The second design added a flywheel to pull on the tether in the opposite direction. It added the risk of flywheel exploding, but removed the requirement for propellants entirely.

The third design (not posted) had a bow-and-arrow configuration. Intercept is easy, no hypervelocity braking, but the payload's hook would collide with the tether at orbital velocity.

The fourth design is the skip-rotor design. No braking, no propellants, zero relative velocity intercept at the tip of the tether... but intercept precision is too high.

The fifth design I'm looking at now uses a tube of gas to brake only the small hook.


This sixth design considers not using a tube at all, but a series of airbags preceded by puffs of gas.

So to be clear, you expect to impart the desired acceleration by dragging a piston through a series of airbags. Do I have that correct?


Yes.

Again, sooner or later, great force must be exerted on a multi-ton payload. You cannot finesse your way around this, because your system is useless if it does not accelerate massive payloads.


That's the role of the main pulley-train and brakes system.

[Yes, but not a problem that we can solve faster than we can significantly improve the state of material science. By the time it's possible to do what must happen for your tether systems to work, there will be other, better ways to accomplish the same things.


I have been putting a lot of effort into trying to devise solutions that do not require improvements in materials technology.

This is why, for instance, you talk about having maneuvering thrusters that can accelerate the payload at 0.3g. Hint: that is not especially realistic, for a lightweight maneuvering thruster package that can be used for fine precision control. RCS thrusters tend to have very low thrust, precisely because you need to be able to use them to control your velocity to a precision of centimeters per second for high-precision docking maneuvers.


0.3g is an emergency burn that burns through all available deltaV. On the main payload, this can be achieved by a 29.4kN thruster. Six of them would mass about 352kg if use the AJ190-10 like the Space Shuttle.

ASAT weapons also collide with the target at high speeds rather than rendezvousing gently. This is a much simpler problem.


Well, the entire objective behind the BOT is controlled collision, so I do not see why the capabilities of ASATs/ABMs cannot be transferred to larger payload. If a kinetic kill vehicle can collide with a small satellite, then a payload can be guided near the gas bags and the tether.

Oh, sure, if we could predict in advance exactly what the deviations from the ideal flight path were going to crop up, and build a custom engine ahead of time to cancel those deviations out...

...Really? :roll:


I don't see how you arrived to that conclusion. If the miniature solid rockets provide precisely 0.1m/s each, the only custom-building is tailoring the propellant in each successive rocket to be smaller to account for the mass lost after each burn. For example, the first solid rocket would be 10 times longer than the final rocket, so that they each provide a precise amount of deltaV per burn. I believe a modern smartphone can handle the software required to control and predict the sequence of burns required to achieve a specific velocity on 2 axes..

I'm going to be honest, your idea is now sufficiently complex that I no longer believe this can be implemented. I can't trust your math because you routinely ignore important aspects of physical systems, completely by accident and without realizing that you have done so.


Is complexity a good estimate for whether something works? An example I used before is the F1 car's 80000 parts. It is complex, but racers routinely trust their lives to it at 300km/h.

If I had to break down the current design, I'd list these components:
Payload end:
-Rocket booster
-Payload
-Payload safety and abort systems
-Payload RCS
-Payload radar
-Payload tether
-Tether drone
-Payload hook

Tether end:
-Gas release tanks
-Airbags
-Arrestor wire
-Bolt insertor and release mechanism
-Segmented Tether
-Inter-segment tether connections
-Pulleys
-Pulley brakes
-Pulley suspension
-Flywheel
-Flywheel brakes
-Flywheel/tether connection
-Electric engine
-Solar panels
-Off-axis flywheels for maneuvering
-Station Radar

When real science and engineering people talk, they usually start from the assumption that they can trust each other's math. They still cross-check, but they can at least assume that there aren't glaring mistakes in literally every calculation.


I think you'll have to back that statement up. I don't believe I'm making wild mistakes in literally every calculation.

The problem is that you've overlooked enough important things and made enough errors that I can no longer make that assumption. I can't trust you to know what you're talking about, even about basic simple things, until I've run the math myself.


Many of these 'overlooked' problems seem to result from a lack of communication, such as your confusion on whether the hook or the payload was being braked by the airbags.

Which means that if you spend hours calculating something, I can't spend hours verifying it; I haven't got the time.


I am grateful for the time you have already given. For each hour of maths, I spend two hours repeating my calculations under different assumptions and three hours doing research.

This is, again, why I keep pushing you to spot more of your own mistakes. Outsourcing literally all error-checking onto others places undue demands on our time and makes us disinclined to examing your proposals in detail.

I'm going to be quite honest, the next time I see you make a fundamental mistake based out of ignorance of basic scientific facts (like "heat applied to a rope by brakes hits the outside of the rope first" or "oh I forgot I need umpty tons of propellant/coolant lol"), I'm just going to give up on you entirely. I like the idea of trying to help you learn this stuff in the abstract, but I can't take the combined responsibility of being your K-12 science teacher on every one of a dozen different topics.


I was not formally taught to remember check thermal conductivity of a material under braking forces. I don't have the instincts that tell me that a tapering length is the solution to the maximum velocity of a rotating tether. These are things I research and come up with on my own, in my free time, so please recognize that I am trying my best, and no, they are not taught in the american K-12 science classroom.

There is a certain "you must be this tall to enter" level of background knowledge required to talk intelligently about systems like this, and that's the case for a good reason.


I'm sorry you feel this way, but I would have liked this to be stated from the beginning before 'one more mistake and I'm out' ultimatums are given.
Google + : matterbeamTSF

Hard SF blog: ToughSF

MetaSeed: Worldbuilding and Game Design discussion

Simon_Jester
Emperor's Hand
Posts: 28661
Joined: 2009-05-23 07:29pm

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby Simon_Jester » 2017-02-03 08:52pm

matterbeam wrote:
Simon_Jester wrote:Once the liquid hydrogen has boiled, it will rapidly escape from the coolant container you put it in. Alternatively, if you're trying to confine the hydrogen in a fixed container so that it is unable to escape, you will encounter huge, rapidly increasing gas pressure that causes the coolant container to burst open and explode. The large influx of energy associated with a boiling liquid is, by definition, the energy required to take that material from a compact 'liquid' form into a diffuse 'gas' form.
I was only trying to calculate the magnitude of how bad the idea was, not trying to solve it.
I'm sure there are ways to continue heating gaseous hydrogen after the first liquid pass. I detailed some of the problems with trying to recover or contain the liquid hydrogen the first time this was mentioned, so I am not ignoring to the pressurisation issues.
Okay, well. Protip for future reference: If you're planning to use something as a coolant, don't use liquid hydrogen. Use a substance that doesn't vaporize at around negative 250 degrees Celsius. Use something that can absorb a lot of thermal mass without boiling. Water is nearly ideal for this purpose, so if you're actually trying to make your liquid-cooled machine work, using water as a "could this possibly work" test is much more reasonable than using liquid hydrogen.

By bringing up liquid hydrogen as your choice, you create doubt as to whether you're actually trying to solve the problem, or to create a strawman example that would fail to solve the problem.

By definition, energy absorbed by the brakes as waste heat is NOT energy that goes into accelerating the payload.

Review basic thermodynamics.
In the basic runway version of the BOT, from the point of view of the station, the payload comes to rest relative to the tether. Therefore it has to remove kinetic energy as heat.
You could equally well argue that from the point of view of the ground, the payload accelerates and does not necessarily pick up any heat because it's gaining so much kinetic energy.

There is no privileged frame of reference. You can't just pick an arbitrary frame of reference and say that what happens to the energy is based on that frame alone. Energy is conserved in all frames of reference.

To figure out the amount of heat dissipated by a set of brakes, you must actually understand the mechanics of a set of brakes. There is no shortcut.

[Yes, but this isn't a problem you're going to be able to duck out of entirely. The total quantities of mass being slung around here are too large; something is going to have to give.
Estimating the loads, the simple runway tether will require ridiculously complex or massive cooling systems and a slightly less ridiculous set of brake-skis. The airbag-brakes version has much lower forces and energies involved.
That then brings us back to the question: what exerts the massive extra impulse (involving a great force for a considerable time) required to bring the payload up to orbital velocity? Be specific. Exactly which part is experiencing this force, and in what way? That is the single most important design issue for your system.

A railgun launch system would likely produce a very reliable, very predictable trajectory every time. Getting 10 tons to 2km/s requires 20GJ or more, however.
Railguns suffer barrel erosion. Barrel erosion is going to make them less than perfectly accurate.

I know that 1cm wavelength radar is pretty much un-impeded by the atmosphere and two such stations can track both the payload and the BOT target to much more accuracy than will ever be needed? Millimeter radar will be needed in space for guiding the drone and hook.
So, you do not know the accuracy to which ground control can ascertain the position of the payload, then.

Do you know the accuracy to which a millimeter approach radar set in the nose of the payload can measure the position of the station or the hook or cage or whatever? Hint: do not assume that the answer is "one millimeter" just because that's the wavelength of the radio waves!

If the cylinder has matched velocity with the hook, what actually does the work of accelerating the payload?

Seriously, SOMETHING has to exert massive force on the payload, somewhere, at some time. You can't design around that aspect of the system, because that is the entire point of the system in the first place.
I think there is some confusion here. The hook sits on a heatshield for 0.24 second to slow it down enough for an arrestor wire to catch it and push bolts through the holes it has. Once the main tether is bolted with the hook, the tether-hook-payload tether forms a continuous line that is released and starts the previously described flywheel+pulley train braking process.
In that case... doesn't the whole tether have to match velocities with the payload, and link up with the payload via a hook or whatever ? I thought we already had a system where you wanted to try that, and we concluded that it wouldn't work.

Remember, this system basically consists of three (sets of) parts that are moving relative to each other.

1) Station- orbital velocity
2) Tether- orbital velocity
3) Payload- stationary (relative to Earth)

Now, the goal is to get (3) to "orbital velocity."

This requires that the payload interact with the tether. Which means either the (3) interacts with an orbital-velocity tether (requiring superbrakes), or with a stationary tether.

The former option is basically impossible, as discussed. In the latter case, with the stationary tether, the payload doesn't have such a destructive interaction with the tether... BUT you to accelerate an extremely massive tether in order to catch the payload, because the tether starts out at orbital velocity and has to be braked back down to 'stationary' before it can be sped back UP to 'orbital velocity.'

Have you figured out a way around this yet? I'm very much not clear on how you think any of the new ideas avoids that problem.

This two-part system makes sure that the only piece that suffers from 'harsh' forces is the solid lump of hook steel. None of the tether, brakes, flywheel, pulleys or payload have to suffer more than 3-9G depending on altitude.
Then how did you match the speed of the bit on the end of the tether that catches the payload, and of the payload itself?

[Yes, but not a problem that we can solve faster than we can significantly improve the state of material science. By the time it's possible to do what must happen for your tether systems to work, there will be other, better ways to accomplish the same things.
I have been putting a lot of effort into trying to devise solutions that do not require improvements in materials technology.
I strongly suspect that this entire angle of investigation won't work without improvements in OTHER technologies. By the time those are ready, we can expect better materials by default.

This is why, for instance, you talk about having maneuvering thrusters that can accelerate the payload at 0.3g. Hint: that is not especially realistic, for a lightweight maneuvering thruster package that can be used for fine precision control. RCS thrusters tend to have very low thrust, precisely because you need to be able to use them to control your velocity to a precision of centimeters per second for high-precision docking maneuvers.


0.3g is an emergency burn that burns through all available deltaV. On the main payload, this can be achieved by a 29.4kN thruster. Six of them would mass about 352kg if use the AJ190-10 like the Space Shuttle.
How much space would they take up? What about the fuel for them? Doesn't this add considerable extra expense and parasitic mass to the payload? At what point would it be more cost-effective to just build a bigger booster and use the clustered AJ10-class rockets as the second stage of your rocket?

ASAT weapons also collide with the target at high speeds rather than rendezvousing gently. This is a much simpler problem.
Well, the entire objective behind the BOT is controlled collision, so I do not see why the capabilities of ASATs/ABMs cannot be transferred to larger payload. If a kinetic kill vehicle can collide with a small satellite, then a payload can be guided near the gas bags and the tether.
Key word, controlled collision. You need to collide in such a way that there is no deviation, exactly where and when expected.

Since this is now a system where the payload is rendezvousing with a hook or catcher system, just like your old idea about launching a cage on the end of the tether... you do need to make a zero-zero intercept with the cage. Little or no relative velocity. That is, again, a lot harder than just slamming into the hook or cage at high speed.

When real science and engineering people talk, they usually start from the assumption that they can trust each other's math. They still cross-check, but they can at least assume that there aren't glaring mistakes in literally every calculation.
I think you'll have to back that statement up. I don't believe I'm making wild mistakes in literally every calculation.
You're making very, very bad assumptions often. Not literally every time, but so often that I have to stop and think "wait, is this a sound calculation that makes sense in context, or is some very very important physical fact being ignored?"

It's kind of exhausting, and I suspect anyone else trying to provide this level of error-checking for you would be equally exhausted.

This is why a large part of the training of professional engineers revolves around learning not to make mistakes, because it reduces the amount of burden you export to the people around you trying to evaluate your designs. My own background is physics which is similar but not identical, and there's a similar culture of trying to develop a strong enough intuitive understanding of systems that one generally avoids the basic mistakes.

As systems get more complicated, the probability of being able to understand them at all becomes vanishingly small, unless each individual part of the system is being modeled and understood with high reliability. My concern is that you need to work on the reliability with which you model individual parts. Because (for instance) I strongly suspect that the latest iteration of your design is the result of you forgetting to account for the mass of the tether when calculating the acceleration required to 'hook' the payload by launching a hook on the end of the tether. Again, because that's a mistake you already made just before you started trying elaborate "bow and arrow" and "spinner" designs.

[If I'm wrong about that concern, then I honestly don't understand how you picture the process of forming a connection between the station and the payload at all.]
This space dedicated to Vasily Arkhipov

User avatar
Lord Revan
Emperor's Hand
Posts: 10385
Joined: 2004-05-20 02:23pm
Location: Zone:classified

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby Lord Revan » 2017-02-03 09:19pm

Something engineers must learn and fast is (and this relates to the "do not make mistakes" part) is that you absolutely cannot assume that laws of physics will take coffee break when it's convinient for you and have to check, double check and then triple check that you made no major errors or obmission in your work since a single mission variable or constant can turn the total thing on its head and make something that seemed like miracle to be nothing at all.

Here's a personal story from my first year in what's now called Aalto-university (at the time it was called Helsinki University of Technology) the group was to calculate this power output of hydrogen energy cell of about size of 2 playing card decks put together, now the actual output was nothing impressive (nor is it really relevant for my point) but our first calculations gave us a power output in the terawatt range over billion times the actual output and to put that into context the yearly energy output of nations is calculated is terawatthours so our first calculations implied that had we ran that powercell for few hours instead of just few minutes we could have gotten the same amount of energy out of it then a decent sized nation consumes in a year yeah that's not likely at all so we rechecked our calculations and found out that a single logarithim was mission for the formula we were orginally given (we correction was given to us but somehow we had missed but then we were first year students not fully fledged engineers) but my point is that a single missing or ignore part if your formula can have drastic effect and can twist the results into something that's not anywhere close to realistic.
I may be an idiot, but I'm a tolerated idiot
"I think you completely missed the point of sigs. They're supposed to be completely homegrown in the fertile hydroponics lab of your mind, dried in your closet, rolled, and smoked...
Oh wait, that's marijuana..."Einhander Sn0m4n

Adam Reynolds
Jedi Council Member
Posts: 2137
Joined: 2004-03-27 04:51am

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby Adam Reynolds » 2017-02-04 12:41am

matterbeam wrote:This is why I have strived to restrict my materials and technological requirements to what is available today. The Orion had to handwave some issues away, such as the suspension system.

It has nothing to do with materials science or tech level, it has to do with just about everything else from an engineering standpoint, that good engineering is about designing your system under the assumption that it will fail.

Currently Space X is getting into a trouble with reliability because they are not doing this. Having rockets that cost 1/4 of what the competition does is nice, except when they keep exploding.

Also, saying not to bother to explore a concept because you or I can't find it on the internet is the absolute anti-thesis to interesting discussions.

It doesn't mean that it automatically isn't worth discussing, but it does mean that you should ask this question and seriously think about the answer.

Simon_Jester
Emperor's Hand
Posts: 28661
Joined: 2009-05-23 07:29pm

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby Simon_Jester » 2017-02-04 03:10am

To refine what Adam is saying:

Good engineering is about designing your system under the assumption that things will not go perfectly.

Assume that your operators will have inexact information. Assume that parts will experience considerable wear and tear and need regular replacement. Assume that any system not actively being checked, doublechecked, and maintained may fail at any time and that backup options need to be available in case that happens. Even systems that are being carefully checked and maintained may fail, it's just less likely that they will fail.

Assume that your estimates for how precisely you can time and position an operation are overly optimistic. Assume bad weather interferes. Assume the operator fumbles a little. Assume a part sticks briefly. Assume the fuel quality isn't quite 100%. Assume all sorts of little details go wrong, somewhat, to a believable degree.

Then it becomes your job to say "how can I make this system work anyway?"

If the system is inherently not one that can be "failure-proofed" in the sense of making minor problems like the ones mentioned above survivable for the system... The system is not going to work. It will be found to be impossible to maintain, unsafe and unreliable to use, and so on. Because of the thousands of things that can go wrong, at least a few of them will go wrong, every time.
__________________________________

Jet passenger planes are great examples of a well-engineered system. Most of the things that can go wrong are 'covered.' The plane is carefully designed to exert no unreasonable forces on its passengers, but to survive if unreasonable forces are exerted by accident. Bad weather won't necessarily stop it from taking off, and if it does, well, "your flight has been delayed" is annoying but generally not life-threatening. Parts that can conceivably fail are generally redundant. There are mechanisms in place for operating the plane if an engine fails, or even (to a degree) if ALL engines fail. Pilots typically fly with a backup copilot so that there is someone capable of helping the pilot in an emergency. There are teams of professionals on the ground who are well able to help the pilot keep track of their position and heading if there's any confusion, to warn planes out of the airspace other planes occupy, and to help them come to a safe landing if something goes wrong.

Almost every imaginable problem that could realistically arise has been compensated for. As a result of all this, passenger air travel is an extremely safe way to travel.
_______________________________________

But if we approached the design of the overall aviation system, not just the plane itself but the way the pilots operate the plane, and the ground control, and the schedules the planes fly... If we approached all this differently, we would see different results.

If we assumed that planes MUST fly at the scheduled moment, regardless of the weather they were taking off in, flying into, or landing in the middle of, we'd have a lot more airplane crashes.

If we assumed that one pilot was enough, we'd have more airplane crashes.

If we assumed that jet engines wouldn't fail and didn't specifically design planes to survive an engine failure without harming the passengers, we'd have more airplane crashes.

If we assumed that the airplane pilots and crew could keep track of all their own navigational needs and didn't need ground control, we'd have more airplane crashes.

And if we were forced to make any one of these "simplifying" assumptions about the reliability of our system, in order for passenger aviation to work at all... passenger aviation would not work. It would be much more risky. People would die, and many people would simply refuse to fly at all, making passenger aviation not only more risky but less profitable.

Good engineering makes systems not only safe, but reliable and profitable. But it absolutely, always requires that you pay careful attention to the parts of the system that must work for you to succeed, and failure-proof them as far as possible.
This space dedicated to Vasily Arkhipov

User avatar
madd0ct0r
Sith Acolyte
Posts: 5334
Joined: 2008-03-14 07:47am

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby madd0ct0r » 2017-02-04 04:06am

This thread needs more sketches.
"Aid, trade, green technology and peace." - Hans Rosling.
"Welcome to SDN, where we can't see the forest because walking into trees repeatedly feels good, bro." - Mr Coffee

User avatar
Lord Revan
Emperor's Hand
Posts: 10385
Joined: 2004-05-20 02:23pm
Location: Zone:classified

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby Lord Revan » 2017-02-04 07:59am

Adam Reynolds wrote:
matterbeam wrote:This is why I have strived to restrict my materials and technological requirements to what is available today. The Orion had to handwave some issues away, such as the suspension system.

It has nothing to do with materials science or tech level, it has to do with just about everything else from an engineering standpoint, that good engineering is about designing your system under the assumption that it will fail.

this or more precise what Simon just said. being impersonal forces of nature the laws of physics are utterly without mercy in their application so asssuming "it'll work" is a pathway to disaster
Also, saying not to bother to explore a concept because you or I can't find it on the internet is the absolute anti-thesis to interesting discussions.

It doesn't mean that it automatically isn't worth discussing, but it does mean that you should ask this question and seriously think about the answer.
for a discussion about possible future technology to be truly intresting everything must be taken into account and asking yourself "why hasn't this been done before or not even tried?" can you lead you to see flaws in your designs that you orginally missed and lead you to either improve the design if possible or dismiss the design as unviable if you find out that flaws are so fundamental to the design that it's not possible to solve those flaws.

In essence asking yourself "why hasn't no-one tried this before?" isn't about not exploring things but rather admiting you're flawed yourself and might have made a mistake and therefore should explore reasons why others failed to do what you plan to see where the possible mistakes were.
I may be an idiot, but I'm a tolerated idiot
"I think you completely missed the point of sigs. They're supposed to be completely homegrown in the fertile hydroponics lab of your mind, dried in your closet, rolled, and smoked...
Oh wait, that's marijuana..."Einhander Sn0m4n

User avatar
matterbeam
Youngling
Posts: 80
Joined: 2016-04-04 08:52pm
Contact:

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby matterbeam » 2017-02-06 12:13pm

As requested, a diagram of the gas-brake and hook to pulley-train tether design:
Image
Image
Image
Image

Simon_Jester wrote:Okay, well. Protip for future reference: If you're planning to use something as a coolant, don't use liquid hydrogen. Use a substance that doesn't vaporize at around negative 250 degrees Celsius. Use something that can absorb a lot of thermal mass without boiling. Water is nearly ideal for this purpose, so if you're actually trying to make your liquid-cooled machine work, using water as a "could this possibly work" test is much more reasonable than using liquid hydrogen.

By bringing up liquid hydrogen as your choice, you create doubt as to whether you're actually trying to solve the problem, or to create a strawman example that would fail to solve the problem.


I was considering the mass of coolant required compared to the mass of the payload being braked. Heat capacity is highest for hydrogen, so if it doesn't pass the test, then water certainly won't, even if all mechanical and technological considerations are set aside. I agree that water is more practical and has better heat capacity per litre.

You could equally well argue that from the point of view of the ground, the payload accelerates and does not necessarily pick up any heat because it's gaining so much kinetic energy.

There is no privileged frame of reference. You can't just pick an arbitrary frame of reference and say that what happens to the energy is based on that frame alone. Energy is conserved in all frames of reference.

To figure out the amount of heat dissipated by a set of brakes, you must actually understand the mechanics of a set of brakes. There is no shortcut.


From the point of view of the spacestation, the payload is travelling at 7334m/s. It stops, and the kinetic energy it contained is dissipated as heat.

From the point of view of Earth, the space station is travelling at 7334m/s and the payload at 0m/s. After the encounter, the space station is 10 tons heavier and travelling 36m/s slower. The difference in kinetic energy is lost as heat. This is assuming 1000km altitude, 10 ton payload, 1000 ton space station, figures I usually use for theoretical calculations .

From any point other point of view or frame of reference, the total kinetic energy of the station plus payload is lower than that of the station before the encounter. Therefore, it is safe to assume that all the difference in kinetic energy is converted into heat.

That then brings us back to the question: what exerts the massive extra impulse (involving a great force for a considerable time) required to bring the payload up to orbital velocity? Be specific. Exactly which part is experiencing this force, and in what way? That is the single most important design issue for your system.


I hope the diagrams clarified this issue. I'm sorry, I am prone to not properly making sure my descriptions are clear, especially when there are many versions involved.

Railguns suffer barrel erosion. Barrel erosion is going to make them less than perfectly accurate.


The objective is to fit within the error-correcting abilities of both the payload's and drone's RCS. Railguns might be more suitable for this than rockets.

So, you do not know the accuracy to which ground control can ascertain the position of the payload, then.


I'd guess this is the sort of technical point which can only be guess-timated. I do know that there are military radar installations that can detect, track and follow a small ballistic missile's warhead across the globe, with sufficient accuracy to give a target to anti-ballistic missiles. The BOT is much bigger, and is not trying to hide or make evasive manoeuvres, so I believe this is the sort of capability we already have,.

Do you know the accuracy to which a millimeter approach radar set in the nose of the payload can measure the position of the station or the hook or cage or whatever? Hint: do not assume that the answer is "one millimeter" just because that's the wavelength of the radio waves!


I have a +/- 50cm accuracy requirement on the drone, and a +/- 1km accuracy requirement on the payload-spacecraft. However, there is no reason why the gas brake design cannot be scaled up, and the accuracy requirements scaled down.

]In that case... doesn't the whole tether have to match velocities with the payload, and link up with the payload via a hook or whatever ? I thought we already had a system where you wanted to try that, and we concluded that it wouldn't work.

Remember, this system basically consists of three (sets of) parts that are moving relative to each other.

1) Station- orbital velocity
2) Tether- orbital velocity
3) Payload- stationary (relative to Earth)

Now, the goal is to get (3) to "orbital velocity."


I tried designing a system where the smallest part of (3) had to withstand a 'hard' acceleration to allow for every other component to go through a 'soft' acceleration.

How much space would they take up? What about the fuel for them? Doesn't this add considerable extra expense and parasitic mass to the payload? At what point would it be more cost-effective to just build a bigger booster and use the clustered AJ10-class rockets as the second stage of your rocket?


I gave a generous 1 ton to the 'RCS and propellant' tab in the realistic version of the payload design, mentioned in page 2. If the RCS rocket engines require about 350kg, then there is 650kg left over for propellant. On a 12.95 ton spacecraft, it would mean a deltaV of 176m/s, which actually exceeds the first estimate of 150m/s. Building a second-stage rocket to put a 10 ton payload into orbit would be the better option if the 'parasitic mass' was 28 tons, not 2.95 tons.

Key word, controlled collision. You need to collide in such a way that there is no deviation, exactly where and when expected.


The deviation allowed in the example design is +/0.5m. Over 0.24 seconds of braking, this translates into a maximum deviation of +/-4.06m/s. Again, there is no reason why larger gas brakes cannot be used.

I think you'll have to back that statement up. I don't believe I'm making wild mistakes in literally every calculation.
You're making very, very bad assumptions often. Not literally every time, but so often that I have to stop and think "wait, is this a sound calculation that makes sense in context, or is some very very important physical fact being ignored?"

It's kind of exhausting, and I suspect anyone else trying to provide this level of error-checking for you would be equally exhausted.

This is why a large part of the training of professional engineers revolves around learning not to make mistakes, because it reduces the amount of burden you export to the people around you trying to evaluate your designs. My own background is physics which is similar but not identical, and there's a similar culture of trying to develop a strong enough intuitive understanding of systems that one generally avoids the basic mistakes.

As systems get more complicated, the probability of being able to understand them at all becomes vanishingly small, unless each individual part of the system is being modeled and understood with high reliability. My concern is that you need to work on the reliability with which you model individual parts. Because (for instance) I strongly suspect that the latest iteration of your design is the result of you forgetting to account for the mass of the tether when calculating the acceleration required to 'hook' the payload by launching a hook on the end of the tether. Again, because that's a mistake you already made just before you started trying elaborate "bow and arrow" and "spinner" designs.

[If I'm wrong about that concern, then I honestly don't understand how you picture the process of forming a connection between the station and the payload at all.][/quote]

I'll keep this in mind.
Google + : matterbeamTSF

Hard SF blog: ToughSF

MetaSeed: Worldbuilding and Game Design discussion

Simon_Jester
Emperor's Hand
Posts: 28661
Joined: 2009-05-23 07:29pm

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby Simon_Jester » 2017-02-06 01:16pm

matterbeam wrote:As requested, a diagram of the gas-brake and hook to pulley-train tether design:
[snip images]
I'm afraid this doesn't help very much. The fundamental question is: How do you connect the 'main' tether to the payload, so that the station can bring the payload up to speed by exerting force on the tether? This is a question that should not require four diagrams to answer- at worst, it should require a list with bullet points. Drawing pictures without a list and without captions is not very helpful.

So please, give me a list of all the steps it takes to go from:

1) Station and all parts associated with the station are at rest relative to each other, all moving at orbital velocity relative to the Earth, to


N) The tether connects to the payload.

Right now it seems like either your plan has "and then a miracle occurs!" somewhere between step (1) and step (N)... Or your plan is ignoring the need to accelerate a massive tether to high speed. AGAIN.

Simon_Jester wrote:Okay, well. Protip for future reference: If you're planning to use something as a coolant, don't use liquid hydrogen. Use a substance that doesn't vaporize at around negative 250 degrees Celsius. Use something that can absorb a lot of thermal mass without boiling. Water is nearly ideal for this purpose, so if you're actually trying to make your liquid-cooled machine work, using water as a "could this possibly work" test is much more reasonable than using liquid hydrogen.

By bringing up liquid hydrogen as your choice, you create doubt as to whether you're actually trying to solve the problem, or to create a strawman example that would fail to solve the problem.
I was considering the mass of coolant required compared to the mass of the payload being braked. Heat capacity is highest for hydrogen, so if it doesn't pass the test, then water certainly won't, even if all mechanical and technological considerations are set aside. I agree that water is more practical and has better heat capacity per litre.
Hydrogen does NOT have higher heat capacity WHEN USED AS A COOLANT, because it vaporizes at around -250 degrees Celsius. A liquid coolant cannot absorb more heat than it takes to vaporize the coolant, without destroying the liquid cooling system due to vapor pockets.

Do not think in terms of a number on a table for liquid hydrogen. Think "how many joules of heat will one kilogram of this substance absorb, before it is lost to vaporization?" You didn't run those numbers, and as a result your comparisons were completely useless.

If you intend to make a long term hobby out of proposing designs for technology, I really, really hope you're studying science in mathematically rigorous courses.

That then brings us back to the question: what exerts the massive extra impulse (involving a great force for a considerable time) required to bring the payload up to orbital velocity? Be specific. Exactly which part is experiencing this force, and in what way? That is the single most important design issue for your system.
I hope the diagrams clarified this issue. I'm sorry, I am prone to not properly making sure my descriptions are clear, especially when there are many versions involved.


So, you do not know the accuracy to which ground control can ascertain the position of the payload, then.
I'd guess this is the sort of technical point which can only be guess-timated. I do know that there are military radar installations that can detect, track and follow a small ballistic missile's warhead across the globe, with sufficient accuracy to give a target to anti-ballistic missiles. The BOT is much bigger, and is not trying to hide or make evasive manoeuvres, so I believe this is the sort of capability we already have.
Ballistic missile interceptors are not perfectly reliable; real life ballistic missile defense systems tend to fire multiple interceptor missiles per incoming warhead for this reason. Furthermore, with an antimissile system, it is acceptable if the interceptor "clips" the incoming warhead, or hits it at a funny angle, or otherwise doesn't stay exactly on profile. If the antimissile has to be adjusted to hit the target 100 milliseconds later, that's not a problem.

Meanwhile, you appear to have moving parts that need to slide into place or something to interlock the payload with the tether. That will NOT work unless timing and positioning are perfect.

Do you know the accuracy to which a millimeter approach radar set in the nose of the payload can measure the position of the station or the hook or cage or whatever? Hint: do not assume that the answer is "one millimeter" just because that's the wavelength of the radio waves!
I have a +/- 50cm accuracy requirement on the drone, and a +/- 1km accuracy requirement on the payload-spacecraft. However, there is no reason why the gas brake design cannot be scaled up, and the accuracy requirements scaled down.
Since the specifics are still confusing about how you expect this to work, I'm not going to comment on the detailed mechanics until you clarify the broad mechanics of how you expect this to work.

In that case... doesn't the whole tether have to match velocities with the payload, and link up with the payload via a hook or whatever ? I thought we already had a system where you wanted to try that, and we concluded that it wouldn't work.

Remember, this system basically consists of three (sets of) parts that are moving relative to each other.

1) Station- orbital velocity
2) Tether- orbital velocity
3) Payload- stationary (relative to Earth)

Now, the goal is to get (3) to "orbital velocity."
I tried designing a system where the smallest part of (3) had to withstand a 'hard' acceleration to allow for every other component to go through a 'soft' acceleration.
That doesn't answer the question.

The payload must interact with the tether.

Does the payload interact with the tether when the tether is moving at orbital velocity and the payload is (approximately) at rest relative to the Earth?

Or does the payload interact with the tether when the tether is (approximately) at rest relative to the payload and the Earth?

This is a binary question; as far as I have been able to determine from a good faith effort to listen to your increasingly complicated and messy designs, there is no way to avoid the answer being one or the other. Neither answer is a pleasant one for the purposes we have in mind.

Please stop dancing around this question.

How much space would they take up? What about the fuel for them? Doesn't this add considerable extra expense and parasitic mass to the payload? At what point would it be more cost-effective to just build a bigger booster and use the clustered AJ10-class rockets as the second stage of your rocket?
I gave a generous 1 ton to the 'RCS and propellant' tab in the realistic version of the payload design, mentioned in page 2. If the RCS rocket engines require about 350kg, then there is 650kg left over for propellant. On a 12.95 ton spacecraft, it would mean a deltaV of 176m/s, which actually exceeds the first estimate of 150m/s. Building a second-stage rocket to put a 10 ton payload into orbit would be the better option if the 'parasitic mass' was 28 tons, not 2.95 tons.
The problem is that you're not just competing with the parasitic mass of the rocket payload's "link to the tether" framework. You're also competing with all the costs of running the station, maintaining it, replacing any expendable parts of the system (e.g. the gas bags) and so on. It adds up rapidly.
This space dedicated to Vasily Arkhipov

User avatar
LaCroix
Sith Marauder
Posts: 4086
Joined: 2004-12-21 12:14pm
Location: Vienna, Austria, Europe, Terra

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby LaCroix » 2017-02-06 02:37pm

I'm trying to decipher your sketch...

1. The suborbital payload delivery vehicle has a tether (of what lenght?) of it's own, with a "drone" at the end to guide the tether hook. Payload and drone start at rest, station and main tether at orbital velocity

2. Unclear - Either the drone is aiming for a railgun at the end of the station tether, or the payload carries a railgun (not plausible, the weight would be too high.)
So I assume that the end of the main tether has a railgun attached, capable of firing a sizable heatshield, and a matching power supply.

3. Once the drone approaches said railgun, or better, said railgun approaches the drone trying to intercept it, the railgun fires the shield (mean the railgun must fire the shield somehow offset angle, or else the drone+tether would either collide with the back of the railgun, or need to pass trough it, either of which is not good for the payload tether's survival.). Shield becomes stationary, and the drone places the hook behind it, before high-tailing out of the way.

4. The heat shield will then be hit with a series of 'aerobreaking' (actually aeroaccellerating in this context) elements that are placed at the actual connector of the main tether. First some free floating gas, and then an unknown number of airbags of unknown size with increasingly dense gas fill.

5. The heat shield will be accellerated with the payload tether and hook hiding behind, until hitting the arrestor wires in the last element. It will then be grabbed and the tethers will be combined.

6. Tethers continue moving until tout, payload will then be acellerated by tether.

7. I suppose your pulley/flywheel thing starts working now, dampening the gforces applied to tether and payload.


Problems:

step 2&3
The distance from railgun to airbags must be 'small' to work for a couple of reasons - angle of impact for heatshield and hook with the gas bags, time at apogee for the payload at the end of the tether, weight and size of the catch mechanism
Since the drone must guide the hook to the heatshield and make contact, there will most likely be no time for the drone to vacate the premises before the heatshield's impact on gas/gasbags. It will smash into the back of the heatshield once the areobreaking is initiated. Severing it from the tether is worse than keeping it attached - less risk of impacting where you don't want to. Also - the hook must attach solidly to the heatshield, or the impact will force it away from it, making a catch unlikely. Not having a railgun and having the heatshiled already at the end of the payload makes things much easier. You need to bring a new heatshield up for each successful mission, anyway, to be discarded on the next catch, so why not use the one you lifted up, and strike the railgun out of the equation? It brings no added bonus, actually quiet the contrary, if you factor replacement rails every couple catches, other spares, the added energy need, and the increasing size of the tether end.

4
Heatshield must be big enough to protect the tether cable from the ablating material and gasses during breaking. The free floating gas cloud will hit the cable in any way. The cable must be able to withstand that, and whatever might leak around the heatshield.
You need to consider that you must deliver a new set of airbags and gas with each flight to ensure the next one will work.

6 there will be a big jerk at the time the acelleration starts (objects at rest vs objects in motion) no pulley system works inertialess.

Other:
The station certainly needs to be manned to operate that system with that many moving and to be replaced/controlled parts. Additional cost for each catch mission.
A minute's thought suggests that the very idea of this is stupid. A more detailed examination raises the possibility that it might be an answer to the question "how could the Germans win the war after the US gets involved?" - Captain Seafort, in a thread proposing a 1942 'D-Day' in Quiberon Bay

I do archery skeet. With a Trebuchet.


Return to “Science, Logic, And Morality”

Who is online

Users browsing this forum: No registered users and 3 guests