Boosted Orbital Tether and Orbital Runway upgrades

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

Moderators: Alyrium Denryle, SCRawl, Thanas

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

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby matterbeam » 2017-01-30 10:19am

LaCroix wrote:I'm not sure if I'm getting it right, but did you change the proposal from "sub-orbital rocket clamps onto a multi-km long super-rope dangling in space with a 7km/s perpendicular relative speed" to "Suborbital rocket flies into a multi-ton docking clamp/holding cage that is moving perpendicular at 7km/s relative speed"?

The first one is at least moderately possible, for you grab hold and a at least in one direction very big target, and can slowly tighten that hold while the rope flys by for a few seconds.
The second one means if you succeed with the rendevouz, you are hit by an object of roughly equal mass traveling at 7km/s relatively to you. That's not docking, that's crashing.


It's "sub-orbital rocket docks with a swinging cage at 0m/s relative velocity then gradually stopped by commerically-availabe Zylon tether'.

The cage is at the end of rope, like a playground swing. The swing is 10km long. The tip velocity is 7334m/s, equal to the incoming spacecraft.
Google + : matterbeamTSF

Hard SF blog: ToughSF

MetaSeed: Worldbuilding and Game Design discussion

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

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby LaCroix » 2017-01-30 10:41am

matterbeam wrote:
LaCroix wrote:I'm not sure if I'm getting it right, but did you change the proposal from "sub-orbital rocket clamps onto a multi-km long super-rope dangling in space with a 7km/s perpendicular relative speed" to "Suborbital rocket flies into a multi-ton docking clamp/holding cage that is moving perpendicular at 7km/s relative speed"?

The first one is at least moderately possible, for you grab hold and a at least in one direction very big target, and can slowly tighten that hold while the rope flys by for a few seconds.
The second one means if you succeed with the rendevouz, you are hit by an object of roughly equal mass traveling at 7km/s relatively to you. That's not docking, that's crashing.


It's "sub-orbital rocket docks with a swinging cage at 0m/s relative velocity then gradually stopped by commerically-availabe Zylon tether'.

The cage is at the end of rope, like a playground swing. The swing is 10km long. The tip velocity is 7334m/s, equal to the incoming spacecraft.


Your station is moving in orbit. The payload is launched up vertically, which means we do have a relative speed of 7km/s to each other, perpendicular. How do you want to "swing" the cage to make it stay still?
The only way this could work out is that you deploy the cage and then boost it out to a the exact opposite speed the station has, and then use thrust to keep it hovering against gravity, so it stays at it's position while the suborbital vessel docks with it. Like the experiment of shooting a ball out ofthe back of your car with a gun to make it hang in the air that the mythbusters did once.

If the swing is only 10km long, and if you had instant accelleration in order to cancel the velocities ( a huge railgun?) , you only have 10/7 - roughly 1.4 seconds for the docking before the swing gets yanked away... That's a tight schedule.

Oh, and it gets yanked away by the pull of a 7km/s moving object(with some dampening by the braking cable and pulleys, but I doubt the desire to stay motionless of a ~300 ton cable will be very lenient towards a ~10 ton object at the other end). Be the gods with whatever happens to be in the cage's vicinity at that 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-01-30 12:13pm

LaCroix wrote:Your station is moving in orbit. The payload is launched up vertically, which means we do have a relative speed of 7km/s to each other, perpendicular. How do you want to "swing" the cage to make it stay still?
The only way this could work out is that you deploy the cage and then boost it out to a the exact opposite speed the station has, and then use thrust to keep it hovering against gravity, so it stays at it's position while the suborbital vessel docks with it. Like the experiment of shooting a ball out ofthe back of your car with a gun to make it hang in the air that the mythbusters did once.

If the swing is only 10km long, and if you had instant accelleration in order to cancel the velocities ( a huge railgun?) , you only have 10/7 - roughly 1.4 seconds for the docking before the swing gets yanked away... That's a tight schedule.

Oh, and it gets yanked away by the pull of a 7km/s moving object(with some dampening by the braking cable and pulleys, but I doubt the desire to stay motionless of a ~300 ton cable will be very lenient towards a ~10 ton object at the other end). Be the gods with whatever happens to be in the cage's vicinity at that time.


The cage swings in a vertical circle. It is synchronized to meet the spacecraft just as the latter reaches the tip of its arc.

Here's an illustration:

Image
Google + : matterbeamTSF

Hard SF blog: ToughSF

MetaSeed: Worldbuilding and Game Design discussion

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

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby LaCroix » 2017-01-30 12:32pm

Thought you would do it that way - it creates even more problems. You now have a weed trimmer at the end of a floppy noodle loop.
The timing is even worse than my cannon harpoon proposal - in your version, you don't have 1.4 seconds to hook up. You have very tiny fractions of a second. For the rope will be at 0 relative speed only at excactly 1 point of the loop. Even a few m/s relative motion will make docking nigh impossible. At 10km skip rope lenght, the cage is traveling along a 31km circumference. Every 4.25 seconds. it will only be at the perfect spot for exactly 1/7300 second. Giving you a 2 meter margin of error (the mechanism can attach even if you are 1m misaligned, you must time the whole shebang to a 1/2430 of a second.

Still - assuming you make that one in a million shot and have everything work out. You got a loop in the tether. With a non-trivial mass rotating in it. Very fast. This is not going to end well, for a free floating loop will contact with it at one time or another, especially once you try changing the angular momentum of the payload. E.g. at docking - adding 10tons to that circling rope will make it fly... pretty much in between the 0m/s arrow and it's original trajectory, pulling the center point with it. This will make everything spaz out, the loop will either be pulled tout, or it will wobble...
Last edited by LaCroix on 2017-01-30 12:36pm, edited 1 time in total.
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.

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

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby Simon_Jester » 2017-01-30 12:33pm

Matterbeam? That flight profile is BEGGING for the payload to miss and collide with the cage at a relative velocity of several hundred meters per second, because if your timing is off by a fraction of a second, the relative velocities aren't zero anymore. Think about what happens if that red parabola you drew were a little higher. This, if anything, manages to make your millisecond-millimeter precision even more demanding. And you have literally never addressed how unrealistic it is for you to assume spacecraft can be positioned that precisely after a rocket launch that punches them through the atmosphere at thousands of kilometers per hour.

I mean hell, how do you even know you're on course to that standard of precision? Navigational systems like GPS are only accurate to a few meters. And there's no time to slow down and dock visually because the payload and cage are moving at high relative speeds, especially in this scenario where the cage is only at rest relative to the payload for extremely brief times during each rotational cycle.

Also... that cage and tether are under 5400 gravities of acceleration while spinning, given that they're spinning in a ten kilometer radius circle at the stated speed relative to the hub. And they're going to be doing this for an extremely long time. Destructive stresses, or warping of the cage framework, are likely.

You DO know about centripetal acceleration, right?

Your payload is going to be subjected to roughly 5400 gravities of acceleration; while there ARE objects built to withstand that for VERY short amounts of time, they're called 'artillery shells' and the vast majority of their mass is a solid hunk of metal for this exact reason. Plus, they only handle those accelerations for a small fraction of a second. I'm not seeing a way to avoid much longer exposers here.

...

I'm going to be honest, one of the fundamental problems with what you're doing is that while you know how to look up an equation and apply it to a problem, you seem to keep forgetting to apply ALL the equations of ALL of physics to each system. This results in you coming up with things like "ignore the mass of the tether" and "ignore centripetal acceleration."

matterbeam wrote:
The fact that an airliner can survive these accelerations without having the wings rip off proves nothing relevant to the problem. None of this indicates that you can build a one-ton set of brakes adequate for decelerating a 15-ton mass at nine gravities for ninety seconds.
I was just trying to prove that building something to support 9G would not require so much structural support that it cuts significantly like a payload. A jet fighter is mostly empty space for equipment and fuel, and it can handle several 9G+ turns in a row. for dozens of total minutes in a single mission.
What makes you think fighter aircraft routinely do turn at nine gravities "for dozens of total minutes?"

Furthermore, you're mistaking 'mass' for 'volume,' which is an extremely basic mistake. Aircraft may have a lot of empty volume, but this isn't about volume. It's mass! Aircraft have a lot of mass devoted to holding the structure together, and in fact this is a large fraction of their total dry weight.

A real engineer could make some estimates, though they might turn out to be wrong. Then again, applying real engineering to this project would result in a lot of changes.
Ideally, the tethers and pulleys are no more or less reliable than an elevator shaft.
Ideally, tomorrow I win the lottery. Stop making assumptions that you can take a system that works at less than 10 m/s and turn it into a system that works equally reliably at 10 km/s.

Remember, this is the difference between me trying to catch a five kilogram weight you tossed at me, and a five kilogram weight you fired out of a railgun at me. "Nothing has changed except the speed," but in one scenario I grunt and catch it, and in the other scenario they're mopping me off the walls and ceiling!

If it is not moving when the impact happens, I think it'll slowly wind into a U-shape then snap at the other end and tangle. In the most extreme position, straight up from Earth between 1000 and 700km, the difference between the ends is 150m/s. It will make a full 'U' in 33 minutes. If the cable is moving, then the pulley wheels are spinning. This nearly 100 tons of gyroscope-like masses will keep it straight while it expands. I'm assuming the brakes can be remotely controlled to keep it straight for longer by differential braking.
Have you read papers on this? Have you done computer models on this?

1000km is just a nice round figure to use as a reference. If the various rendezvous problems are solved, I can easily see a 200km altitude version working to catch 7784m/s payloads instead of 7334m/s payloads. Of course, G-forces have to be quite higher so we don't have a cable trailing down into the atmosphere and dragging the whole platform down with it. 50G inert payloads would only need a 62km tether. The best thing is that you only need 2000m/s deltaV after losses to reach a 200km altitude. It would be the perfect first step towards placing a lot of rocket fuel, cheaply, in orbit.
Fifty gravities is NOT going to work with the "brake by grabbing the cable" scenario.

With the cage scenario things will still not work, because when you decelerate the cage and cable to zero relative to the Earth, they will fall into the atmosphere. The cable will be picking up the payload at atmospheric altitute, and the amount of time available for the launched rocket to 'catch' the cage is virtually zero because you still have to hit exactly the right centimeter in space, at exactly the right millisecond.

You do know that real life rocket launches aren't perfectly precise, the payload doesn't go exactly where you want it to go, and satellites have onboard maneuvering thrusters for a reason? Except here, maneuvering thrusters aren't good enough, because there isn't time for a low-powered engine to move things into position.

There is just... Matterbeam, you do realize you have like four people telling you "this will never work?" So far, every 'clever' solution you've proposed to engineer around a problem has made things worse.

Spot the pattern. Please, I'm begging you here.

A flywheel+pulley platform can work in reverse. Spin up the flywheel, hook them up to the tether with pulleys to spread out the velocity gradient between payload and flywheel rim, and you can get a free 900m/s boost in any direction. A serious attempt at free boosts while already in orbit would require a flywheel at regular intervals down the tether. Their 100m/s rim velocities would add up to incredible speeds, but they'd waste quite a bit of energy accelerating themselves.


If we go further down this route, I can see a bow-and-arrow configuration being possible. Flywheels on either ends of the virtual bow, with the tether between them. The payload is the arrow. If the flywheels have 10x the mass of both the payload and the tether, they can launch the 'arrow' to 10x the flywheel rim velocity.[/quote]Exactly how does this system accelerate anything to a velocity ten times higher than that of the moving parts in the system?

Okay, now it becomes clear that you understand this... As noted above, you just gained about 15 IQ points in my eyes.
High praise. :D
Yeah, but you're starting to lose them again by the way you keep trying to 'patch' flawed systems, without addressing the fundamental criticism that this entire proposal revolves around unrealistic assumptions like "the tether doesn't have any mass" or "I can launch a payload on an ICBM-like trajectory and be sure it is on course to a precision of centimeters and milliseconds of time."

Let me ask you a few generic questions:

1) At what moment does your (firmly suborbital) payload make contact with an object intended to accelerate it to orbital velocity?
2) What is the object in question?
3) What forces are exerted on the object, in the process of boosting the payload to orbital velocity?
4) What parts of the system need to be made unusually rugged, in order to withstand those forces?

Answering those questions makes it a lot easier to spot engineering issues with the system.


Okay then.
1) The payload is caught at the tip of its trajectory, where vertical velocity is near-zero and can be cancelled just before rendezvous by RCS.
Is the payload coming in on a vector that makes collisions with the station equipment likely, or unlikely? What will you do if your booster's launch is delayed by two seconds?

2) It is a spacecraft containing a g-hardened payload, strong RCS systems, guide rails for the cage and arrestor hook backups for docking with the cage.
So to be clear, the cage is moving at seven km/s, and the payload is moving at or near zero? LaCroix is right. That's not a 'catch,' that's a collision.

If the cage was already moving at zero km/s, then it must be on the end of a very, very long rope, and we're right back where we started. We already established that accelerating a cage down from orbital velocity to zero, while it is trailing a long rope is impossible.
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-01-31 08:00am

LaCroix wrote:Thought you would do it that way - it creates even more problems. You now have a weed trimmer at the end of a floppy noodle loop.
The timing is even worse than my cannon harpoon proposal - in your version, you don't have 1.4 seconds to hook up. You have very tiny fractions of a second. For the rope will be at 0 relative speed only at excactly 1 point of the loop. Even a few m/s relative motion will make docking nigh impossible. At 10km skip rope lenght, the cage is traveling along a 31km circumference. Every 4.25 seconds. it will only be at the perfect spot for exactly 1/7300 second. Giving you a 2 meter margin of error (the mechanism can attach even if you are 1m misaligned, you must time the whole shebang to a 1/2430 of a second.


Hmm. You might be right. Let's calculate the tolerances required:
When we consider a quarter-circle of radius 7300m/s, the horizontal velocity is given by cos(a) and the vertical velocity is given by sin(a). At a=0 degrees, horizontal is 7350 and vertical is zero. At a=20 degrees, horizontal is 6859m/s and vertical is 2496m/s. This means if the tether is intercepted at 20 degrees, the relative horizontal velocity is 441m/s and the relative vertical velocity is 2496m/s. The tether rotates at 3098 degrees per second.

+/-20m/s: 0.156 degrees. 0.1 milliseconds.

+/-50m/s: 0.39 degrees. 0.26 milliseconds.

+/-100m/s: 0.78 degrees. 0.5 milliseconds.

+/- 500m/s: 3.9 degrees. 2.6 milliseconds.

It doesn't seem like a realistic tolerance level.

Let's calculate in the other direction. How long does the tether need to be to afford a reasonable level of tolerance? If we have a 100km tether swing, perimeter is 628.3km. Tip velocity of 7300m/s means that one rotation gets completed in 86 seconds, or 4.182 degrees per second. 100m/s tolerance still only gives us 187ms intercept window. Still not enough.

Let's calculate tether loads now. A Zylon tether with a tip velocity of 7300m/s and a tensile strength of 5400MPa can support itself up to a loop radius of R.
Centripetal force C is M*V^2/R. We'll take the 17.37mm 0.369kg/m tether from the design above. V is fixed at 7300m. So we have C=0.369*2*R*7300^2/R. Following the maths, Centripetal force will always be a total of 39.33MN. To get the tensile strength required, we divide by the surface area of the wire.

If we want a 1000km skip-rope for minimum mass, it must survive 53.29N/kg mass. A 1kg/m rope of Zylon can support 3461kN of force over 0.000641m^2 of sectional area. This means a 1000 ton rope can support the load with 98.46% of its tensile strength to spare. A 307kg rope can do the same with 50% of its tensile strength to spare. Surprising figures, to say the least. A 307kg 1000km rope masses only 0.3g per meter, but can support 1066kN of force, so won't be able to hold onto the spaceship afterwards. Three of them will be able to. I'll leave this alone for now, until I can back this up.

A 1000km skip-rope gives a full minute intercept window before relative velocity exceeds 100m/s.

Still - assuming you make that one in a million shot and have everything work out. You got a loop in the tether. With a non-trivial mass rotating in it. Very fast. This is not going to end well, for a free floating loop will contact with it at one time or another, especially once you try changing the angular momentum of the payload. E.g. at docking - adding 10tons to that circling rope will make it fly... pretty much in between the 0m/s arrow and it's original trajectory, pulling the center point with it. This will make everything spaz out, the loop will either be pulled tout, or it will wobble...


After latching on, the cage and tether are released to fly off in whatever direction they choose to. They are attached to the train of pulleys, brakes and flywheels to slow them down.
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-01-31 11:21am

It seems the critical point of the orbital runway design is how the spacecraft docks with the tether.

I've been thinking about it, and the skip-rope idea is not sound. You'd need massive lengths of tether to rotate at high velocity just to achieve a few second window for docking at low relative velocity. Sure, the process that follows is mechanically easy, with low velocities and low forces distributed over long lengths of tether, but the rendezvous is hard.

A rotovator, the traditional rotating tether, is very big and still assumes very small windows for capture.

How about... at the point of capture.... the tether is let go. It would fly out at the same direction as the spacecraft, at the same relative velocity, like a broken string releasing a ball. From the perspective of the spacecraft, the tether comes around and 'drops' the cage in front of it.

Of course we want to capture and brake the payload into orbit.

So the cage is attached to a tether that reels out with the cage. The entire reel has to be kept at the tip of the rotating tether so that it has the same potential energy. If it was spooled out from the center of the rotating tether, it would slow down the released section.

A 100km spool of 'leash' tether would provide a neat 14 second window for docking. It would mass about 37 tons.

The advantages lie in the long rendezvous window, the propellantless docking of otherwise high relative velocity components, and no need for huge spinning sections.
The disadvantage of such a system is that you are adding a lot of mass to the system. With a 37 ton mass at the end of a 10km cradle, you'd need another 37 tons at the other end, and ... apparently it takes 1319 tons of Zylon to hold them together at a 20km radius.

I have just discovered the concept of specific velocity.


You DO know about centripetal acceleration, right?


Centrifuges regularly go harder for longer, so I didn't think it was concerning.

I'm going to be honest, one of the fundamental problems with what you're doing is that while you know how to look up an equation and apply it to a problem, you seem to keep forgetting to apply ALL the equations of ALL of physics to each system. This results in you coming up with things like "ignore the mass of the tether" and "ignore centripetal acceleration."


I never ignored them!



Have you read papers on this? Have you done computer models on this?


You're right. It wouldn't 'snap back', it would wobble like a snake to release tension through friction and eventually become straight according to this: https://en.wikipedia.org/wiki/Gravity-gradient_stabilization

Fifty gravities is NOT going to work with the "brake by grabbing the cable" scenario.


Certainly. It would amount to dissipating 1.2GW of heat.

With the cage scenario things will still not work, because when you decelerate the cage and cable to zero relative to the Earth, they will fall into the atmosphere. The cable will be picking up the payload at atmospheric altitute, and the amount of time available for the launched rocket to 'catch' the cage is virtually zero because you still have to hit exactly the right centimeter in space, at exactly the right millisecond.


It takes 14 seconds to fall about a kilometer. Its not a very tiny window. You're correct about the millisecond, but a millisecond at orbital velocity is still a comfortable 7.3m+

There is just... Matterbeam, you do realize you have like four people telling you "this will never work?" So far, every 'clever' solution you've proposed to engineer around a problem has made things worse.

Spot the pattern. Please, I'm begging you here.


Begging for what? That I stop throwing ideas at the problem until I lose interest or solve it? Thta would make for a very dull forum.

Exactly how does this system accelerate anything to a velocity ten times higher than that of the moving parts in the system?


Like galileo's cannon. The momentum of large masses is transferred to a small mass.


So to be clear, the cage is moving at seven km/s, and the payload is moving at or near zero? LaCroix is right. That's not a 'catch,' that's a collision.

If the cage was already moving at zero km/s, then it must be on the end of a very, very long rope, and we're right back where we started. We already established that accelerating a cage down from orbital velocity to zero, while it is trailing a long rope is impossible.


Cage is moving at 0m/s relative to the spacecraft at capture.
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-01-31 11:29am

A word: Tillotson Two-Tier Tether. Tether tip velocities work like rockets and deltaV, and they too can be staged.
Google + : matterbeamTSF

Hard SF blog: ToughSF

MetaSeed: Worldbuilding and Game Design discussion

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

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby LaCroix » 2017-01-31 11:29am

matterbeam wrote:*snip*
A 1000km skip-rope gives a full minute intercept window before relative velocity exceeds 100m/s.



1. With 100m/s, you are two magnitudes of order above feasible. According to real world experience, docking requires relative velocities <1m/s in order to be done, especially if done via remote control. The rope would need to be much longer.
2. 1000km skip rope would indeed be a weed whacker, for it would touch ground. (Station at 1000km orbit) - The station needs to be higher. Higher station = faster station. Faster station = longer rope needed.
Congratulations - You are now caught in the rocket fuel paradoxon, but with rope length, for a change.
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
LaCroix
Sith Marauder
Posts: 4100
Joined: 2004-12-21 12:14pm
Location: Vienna, Austria, Europe, Terra

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby LaCroix » 2017-01-31 11:53am

matterbeam wrote:Begging for what? That I stop throwing ideas at the problem until I lose interest or solve it? Thta would make for a very dull forum.


You are solving the wrong problem.

You are trying to save a (relatively) minuscule amount of fuel used to circularize to orbit (doing a proper gravity turn with a two stage rocket vs straight up rocket and the fuel you need to put the station back where it belongs), while continuing to use a HUGE amount of fuel (and a BIG rocket engine) to bring the payload to the tether. And increase the complexity from "shoot the damn thing up" to the need for chirurgical precision to not lose the payload, and that whole shebang has to be serviced in space. That will cut a lot into efficiency, for the crew needed to be up there in case things get bad or just operate/service it will need a very expensive manned mission in regular intervals.

Such a system will not work out. Even at best, you are only looking at a 20-30% reduction in cost.

You should use your creative efforts to devise a system lifting the payload out of the deeper gravity well. That is where the cost occurrs. You would reduce cost by three to four digit percentages.
If your system would pay out such benefits, people would jump for joy to be able to implement it.
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.

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

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby Simon_Jester » 2017-01-31 03:11pm

matterbeam wrote:
You DO know about centripetal acceleration, right?
Centrifuges regularly go harder for longer, so I didn't think it was concerning.
I'm going to be honest, one of the fundamental problems with what you're doing is that while you know how to look up an equation and apply it to a problem, you seem to keep forgetting to apply ALL the equations of ALL of physics to each system. This results in you coming up with things like "ignore the mass of the tether" and "ignore centripetal acceleration."
I never ignored them!
Okay. This. This right here. This is a big part of your problem. Let me explain how this all fits together.

See, you seem like a reasonably smart cookie. You know algebra, you know to use formulas competently. That's promising. But you have a serious problem- you don't think at all like an engineer. Not even an amateur one. That's very much a FIXABLE problem, as long as you're aware of it and working on it. Have a growth mindset.

I'm going to try to point out the area where growth is called for.

For example, three pieces of reasoning I've heard you say in this thread are:

1) We can build a one-ton set of brakes that can exert thirty times the force required to bring a semi tractor-trailer to a screeching halt, because airplane parts are designed to withstand 9G or 16G accelerations!
2) We can brake a capture cage to be at rest relative to the Earth to catch the payload, then reel it back in with the tether!
3) We can whirl a cage and/or payload around on the end of a multikilometer tether at hundreds or thousands of gravities for an extended time, because centrifuges run at those accelerations!

Now, you have since spotted and corrected each of these individual mistakes. That's good, that's a good first step. You're have attained the first level of "think like an engineer." Many people never reach that level. But while you have reached a good place, you're not finished, you aren't even at the place you want to be yet. You're on the road to this beautiful city, but you're not in the city. You're at the rest stop on the highway that offers interesting knick-knacks for tourists and overpriced vending machine snacks.

The second step is to correct the underlying problem that leads you to make mistakes like this in the first place. Then, you will be able to operate at a much higher and finer level of ability than you could ever do now, when you're relying on extended debate with others to point out each individual error instead of catching them yourself automatically. You'll still make mistakes when you reach the second level- but you'll make a lot less of them, and it will be easier for you to retain the interest and respect of people who have themselves attained the second level. Or even higher levels, like real rocket scientists.

So here is how to progress. The new lesson is:

Consider every part of the system, in detail, on its own merits. I'll explain more below.



Let's look at the unifying pattern that led to the three mistakes I cited above. This is a very common pattern that I've typically seen at, oh, the undergraduate level. It is not hard to correct the problem. Consider:

(1) is a case where you made an assumption using a faulty analogy. You saw that a certain kind of machinery had a number of the type you wanted (a g-force rating). You assumed that you could easily transfer this desirable property to another kind of machinery (a set of brakes). And that once this was done, it would not be hard to give the new machine the performance you wanted.

What you should have done is tried to find a closely analogous system. The wing spar of an airplane is not analogous to brakes gripping a cable. Look at what I did- I looked for another example of brakes exerting intense force. I thought of trucks trying to stop on a highway. Once you have an analogous system in mind, then your comparisons start to matter, because there are enough similarities that you can learn something from the comparison. Instead of trying to compare "slam on the brakes" to airplane wing spars, or the near-instantaneous acceleration an airplane cabin experiences during a crash, both of which have nothing to do with the engineering problem you're trying to solve.

Now, imagine if you had done this automatically, without prompting, because you've practiced asking yourself "okay, this is the system I want to build, what is an analogous system with known performance?" Instead of just looking for a magic number ("has anyone ever built anything that can withstand X gravities of acceleration?"), you would automatically start to look for the equivalent system. You would have found something like my analogy- you already had the basics in play because you'd looked up the racecar brakes! And you would have stopped to consider what force these brakes exert, to achieve what acceleration upon what mass.

A little arithmetic would have told you that (for instance) applying ~30m/s of delta-V to a 40-ton mass within 11 seconds with brakes requires pretty much exactly the set of brakes found on modern tractor-trailer trucks. Or that applying This would in turn have indicated that applying 200 times as much delta-V, to one third the mass, in only nine times the amount of time, would take brakes considerably stronger and bulkier than those of the truck. In other words, brakes heavier than one ton, and very possibly not brakes that could fit into the relatively small payload.

You might also have looked up the brakes on Formula One cars- but you would have learned something from researching them for a few minutes: Formula One racecars rely on aerodynamics and air-cooling to assist in braking! I found this within 30-60 seconds of opening the Wikipedia article and looking for the 'brakes' section. Obviously, this is a huge difference between a racecar and a payload in outer space. Which tends to undermine the analogy. This is why I used the 'truck' example instead, because truck brakes do not rely so heavily on aerodynamic forces or rapid air-cooling of brakes that would otherwise heat up enough to melt. Correspondingly, they are bulkier.

The trick is, if you want to move to the second level, you can (and should) do this kind of thing automatically, in the middle of setting up your own proposal. Asking yourself the question "would this work?" is a huge timesaver and makes people who operate at a high level much more interested in talking to you.
_________________________________

In case (2), you had a similar mistake in some ways, but different in others.

Whereas in (1), you had a problem in that you needed a performance number, and seized on the first system to provide the number whether it was similar enough to be a good comparison or not...

In (2), you had a problem in that you needed a machine to fill a specific role, and seized on the first system that could do that job, without fully evaluating whether or not it would be effective to try.

So you apparently did not consider, at first, that just accelerating the cage to match velocity with the payload wouldn't do the job- that you'd still have to accelerate the hundreds of tons of tether!

The obvious thing to do is to carefully assess each part of your system. You say "Okay, I have a very light cage and it can be accelerated to high speed easily. Well and good. Then what? Well, the cage has to be reeled back in, which means the cage is attached to the tether... wait... that means the tether has to be going at the same speed as the cage! How much does the tether weigh anyhow?"

You did eventually think to do this, but not before you'd already presented the idea to others. It is a good idea to try to perform this step automatically, first, to avoid awkwardness. Think through ALL the parts of your system, and ALL the implications that basic physics has on what those parts will and will not be able to do. Don't wait for other people to ask straightforward questions like "wait, did you account for the mass of the tether?" Do the due diligence yourself.
________________________________

Now, with the centrifuge thing in (3) you are combining the mistakes of (1) and (2).

On the one hand, you're assuming tiny ultra-high speed lab centrifuges are analogous to huge multi-kilometer tether centrifuges. And that if samples of chemicals that are being spun around in a centrifuge on the ground can survive hundreds or thousands of gravities, so can a physical structure that you have tried to make as light as reasonably possible.

On the other hand, you seized on the 'spinning tether rotary capture' idea without stopping to think through all the steps in the process first.

This is, I repeat, a problem you can fix- if you cultivate the mindset others have discussed, of seriously considering possible failure points and not just the "what if everything goes exactly according to plan" scenario. And the mindset of checking each separate part of the system not just for "will it serve my purpose if nothing breaks or goes wrong," but "will the forces exerted on this part cause it to fail?"

With the cage scenario things will still not work, because when you decelerate the cage and cable to zero relative to the Earth, they will fall into the atmosphere. The cable will be picking up the payload at atmospheric altitute, and the amount of time available for the launched rocket to 'catch' the cage is virtually zero because you still have to hit exactly the right centimeter in space, at exactly the right millisecond.
It takes 14 seconds to fall about a kilometer. Its not a very tiny window. You're correct about the millisecond, but a millisecond at orbital velocity is still a comfortable 7.3m+
The problem is that you can't guarantee the payload will be in the right place at the right time. Real rocket launches often result in the payload being hundreds or thousands of meters off course, and the launch can easily be delayed by seconds- or minutes, or hours, or even days.

For this to work, you need your suborbital payload to be in exactly the right orbital plane and launch at exactly the right moment, for nothing to go wrong on the rocket, and so on. Because if anything goes wrong at any point, you can't just correct by gently nudging the satellite from its 'unsatisfactory' orbit to a better one, the way real satellite payloads do. You have no way to recover from even the slightest problem with the launch, because you don't get to stop and try again- the station is passing the payload at 7 km/s.

Exactly how does this system accelerate anything to a velocity ten times higher than that of the moving parts in the system?
Like galileo's cannon. The momentum of large masses is transferred to a small mass.
How, mechanically? Galileo's cannon transfers momentum by an elastic collision between two rubber balls or similar objects. How does your device transfer the momentum?

Cage is moving at 0m/s relative to the spacecraft at capture.
Then how is the cage accelerated? What object exerts what force on the cage to change its velocity?
This space dedicated to Vasily Arkhipov

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

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby LaCroix » 2017-01-31 07:43pm

In layman's terms - you are too optimistic.

1. An engineer should be a person who takes the most reliable tech known to work, and then adopt it to his needs. Pragmatism is a keyword. "I got this brand new concept" is almost an anathema to them. It's the reason we don't have magnetic bearings in bicycles and everywhere. Too complicated, more points of failure, more cost, little improvement. Whatever works with the least chance of failure, least cost and component count will be used. And if he needs to employ a new, unproven technology, or a new combination of things, he will double or triple the usual safety margin, just to be sure. (which are usually already tripling the needed values). And he will shy away from using more than one new concept (or new applications for known concepts) in any application at one time. Mad genious science has a place - in comic books.

2. Don't look for "how things work" - look for "how will it fail". Engineering is basically applied pessimism. When an engineer looks at a new project design, he doesn't think about how it will be if everythig works fine. His thoughts are of doom and crashing - how will it most likely fail, what would be the worst failure, what will be the parts you need to replace the most due to wear. By assuming the machine will fail at every possible point of failure, and in the worst possible way, you can design it in a way that will make it work with little to no unpredicted failures, and can be easily repaired if a predictable failure occurs (called service - replacing parts that have finite lifespans) .
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
LaCroix
Sith Marauder
Posts: 4100
Joined: 2004-12-21 12:14pm
Location: Vienna, Austria, Europe, Terra

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby LaCroix » 2017-01-31 08:12pm

Simon_Jester wrote:
Cage is moving at 0m/s relative to the spacecraft at capture.
Then how is the cage accelerated? What object exerts what force on the cage to change its velocity?


Picking up that thread...

The problem is that the cage is only at 0m/s relative speed for 1/7300 of a second during capture while the swings direction is in opposition to the swing's central axis' forward motion (following the station at 7300m/s).

So theoretically, everything stands perfectly still for a moment, and all is right in the world.

The problem is that we do have (10 ton cage spinning at the swing rope at 7300m/s) 266.45 GJ of kinetic energy in the cage to be imparted on the now docked payload (currently at rest). Pretty much the energy that was used by the first stage to bring it to the orbital apogee. (That's ignoring the swing rope weight - I lumped it into the 10 ton cage weight for simplicity's sake). And that is ignoring the fact that the swing axis is moving at 7km/s, as well. (Ignoring it, assuming the pulley/brake thingy will actually work and shield the swing/payload system from most of these forces).

Since the weight is suddenly doubled after docking, but the energy wants to remain the same, the whole system will be slowed down to about 5160m/s. 2140m/s speed loss. I can't even attempt to calculate the time it will take to slow that down (elasticity of materials, other factors, my lack of education in that field) to compute the acellerations we are dealing with, but since we're pretty much talking about microseconds in terms of positioning here, and km/s absolute speeds, I feel that this won't be pretty.

My general assumption is that half the kinetic energy will be transfered to the payload, pretty much instantly, and 130 plus change GJ (~30 tons TNT equivalent) rip it apart, along with the cage.
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
Lord Revan
Emperor's Hand
Posts: 10430
Joined: 2004-05-20 02:23pm
Location: Zone:classified

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby Lord Revan » 2017-02-01 04:06am

LaCroix wrote:2. Don't look for "how things work" - look for "how will it fail". Engineering is basically applied pessimism. When an engineer looks at a new project design, he doesn't think about how it will be if everythig works fine. His thoughts are of doom and crashing - how will it most likely fail, what would be the worst failure, what will be the parts you need to replace the most due to wear. By assuming the machine will fail at every possible point of failure, and in the worst possible way, you can design it in a way that will make it work with little to no unpredicted failures, and can be easily repaired if a predictable failure occurs (called service - replacing parts that have finite lifespans) .

This is very important, when things fail and they will fail the laws of physics are remorseless and merciless. While I'd say the applied pessimism is tad too negative way to describe engineering it's not totally incorrect either, the basic point stands, there's a reason why Murphy's law was invented by an engineer.

In fact the orginal purpose of Murphy's law was to teach to always check your failure points and account for them failing, from an engineering point of view if there's even a single "if all things go as planned" it's bad plan, look for every possible realistic failure point no matter how unlikely you think they would be and then you figure out how to make it that if that failure happens at very least it won't be catastrophic. When engineers get lazy about checking failure points you get things like that one bridge in US that broke due to mildly high winds.
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-01 05:14am

LaCroix wrote:2. 1000km skip rope would indeed be a weed whacker, for it would touch ground. (Station at 1000km orbit) - The station needs to be higher. Higher station = faster station. Faster station = longer rope needed.
Congratulations - You are now caught in the rocket fuel paradoxon, but with rope length, for a change.


It could be placed at an altitude of 1200km. Higher station is slower station, as it has lower orbital velocity.

The rope taper ratio is equivalent to the rocket equation, but its proportional to the velocity, not the square of velocity.
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-01 05:20am

LaCroix wrote:You are solving the wrong problem.
You are trying to save a (relatively) minuscule amount of fuel used to circularize to orbit (doing a proper gravity turn with a two stage rocket vs straight up rocket and the fuel you need to put the station back where it belongs), while continuing to use a HUGE amount of fuel (and a BIG rocket engine) to bring the payload to the tether. And increase the complexity from "shoot the damn thing up" to the need for chirurgical precision to not lose the payload, and that whole shebang has to be serviced in space. That will cut a lot into efficiency, for the crew needed to be up there in case things get bad or just operate/service it will need a very expensive manned mission in regular intervals.


The core concept of catching a payload and dragging it into orbit using a pulley-train expanding tether and a flywheel kinetic energy sink is sound. At 1000km, it increases the amount in orbit by 4x. At 200km, it is 8x. The savings are actually greater in practise, as you will be boosting payloads to further orbits using flywheel slings, or catching higher orbit vehicles and placing them into a lower orbit or suborbital trajectory for free. We easily get 10-15x savings over the course of a full space mission.

The problem now is taking full advantage of that core concept.

You should use your creative efforts to devise a system lifting the payload out of the deeper gravity well. That is where the cost occurrs. You would reduce cost by three to four digit percentages.
If your system would pay out such benefits, people would jump for joy to be able to implement it.


SkyHook already exists. HASTOL already exists. The space elevator exists.
Google + : matterbeamTSF

Hard SF blog: ToughSF

MetaSeed: Worldbuilding and Game Design discussion

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

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby LaCroix » 2017-02-01 08:59am

Skyhook was a precursor to HASTOL, pretty much a free- floating space elevator. It was discarded and replaced by HASTOL-Like concepts for simplicity. Rotating the whole thing to lift the payload is less of a hassle than having an elevator run along the cable.

Your latest proposal is basically just HASTOL, but with two seperate components, as the rotating tether is now trailing on a pulley system to reel the payload in. Which means you need to accelerate and decelerate the spinning tether, redeploy it, and the payload is only lifted to the staion's orbit. HAstol would lift it into a higher orbit by design. (capture at orbit - tether, release at orbit + tether)

Your initial design was pretty much a skyhook, but with a pure vertical launch instead of a ballistic trajectory approach of a manned aircraft that can match the tether speed for a period of time., which would help by increasing the hang-time, docking window lenght, and the payload initial velocity, as well as allowing a safe recoery in case of docking failure. Change your initial plan from a pure vertical to a hypersonic chase craft, and it would work much better, and withouth these pulleys and brakes.

That is the problem with all your proposals - Using a pretty much stationary payload at time of docking, and the pulley system to not tear it apart in the following brutal acceleration, you only made it more complicated. We have relatively little gain in fuel consuption each cycle, with but with added complexity that will cause lost payloads and additional service missions. Remove the pulley system, use the chase craft, and your inital proposal becomes Skyhook, and your second one turns into HASTOR.

You were so adamantly working on making a shiny, but unnecessary complicated part of your system work that you were ignoring that if you replaced it with something relatively simple, your system would work fine.

That's why engineers decided to do HASTOL like they proposed. Occam's razor is sharp.
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.

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

Re: Boosted Orbital Tether and Orbital Runway upgrades

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

matterbeam wrote:
LaCroix wrote:You are solving the wrong problem.
You are trying to save a (relatively) minuscule amount of fuel used to circularize to orbit (doing a proper gravity turn with a two stage rocket vs straight up rocket and the fuel you need to put the station back where it belongs), while continuing to use a HUGE amount of fuel (and a BIG rocket engine) to bring the payload to the tether. And increase the complexity from "shoot the damn thing up" to the need for chirurgical precision to not lose the payload, and that whole shebang has to be serviced in space. That will cut a lot into efficiency, for the crew needed to be up there in case things get bad or just operate/service it will need a very expensive manned mission in regular intervals.


The core concept of catching a payload and dragging it into orbit using a pulley-train expanding tether and a flywheel kinetic energy sink is sound. At 1000km, it increases the amount in orbit by 4x. At 200km, it is 8x. The savings are actually greater in practise, as you will be boosting payloads to further orbits using flywheel slings, or catching higher orbit vehicles and placing them into a lower orbit or suborbital trajectory for free. We easily get 10-15x savings over the course of a full space mission.
You know, if we start launching large numbers of these stations with big trailing 100-kilometer tethers... Heck, we've got catcher stations, presumably multiple catcher stations because they can't all service the same launch facilities at the same time and have to be in an orbital inclination that lets them catch payloads from the places the rockets fly out of, then we've got slings that boost from orbit...

That's a lot of very long ropes spinning around in space. It becomes increasingly likely that we'll see on-orbit collisions of tethers. Or severe restrictions on when the system can and cannot operate, out of fear of hitting stations and satellites with the tether.

Also, literally everything Revan and LaCroix said.

The problem now is taking full advantage of that core concept.
The trick is to do so by minimizing the disadvantages of the system (like exposing objects in space to extremely brutal mechanical accelerations and forces).

You've been trying to make your idea 'do more work' by imparting ALL the delta-V and by designing the system with no margin for error. This is not a practical approach to designing things that work.

What is practical, is thinking in terms of "being fully aware of the parts of my system that present the greatest challenges, how do I modify the system to reduce the challenges?" But to do that, you have to anticipate the challenges and identify likely failure points in your system, where you are doing things that are difficult (like surviving very high accelerations for very long times) or even impossible (like trying to launch a suborbital rocket on a ballistic trajectory so precisely that it winds up in exactly the right centimeter of space on exactly the right vector at exactly the right millisecond).
This space dedicated to Vasily Arkhipov

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-01 08:21pm

The elephant in the room for this idea is that it's all designed around saving rocket fuel. This is a bad idea; rocket fuel is cheap. Rockets are expensive, and traditional rocket launches require building rockets and using them only once. That's why, here in the real world, we see SpaceX focusing on reusable rocket stages. When you can re-use the whole launch stack, launches are cheap and a low payload ratio is a nuisance, not a deal-breaker.
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-01 08:46pm

Simon_Jester wrote:You might also have looked up the brakes on Formula One cars- but you would have learned something from researching them for a few minutes: Formula One racecars rely on aerodynamics and air-cooling to assist in braking! I found this within 30-60 seconds of opening the Wikipedia article and looking for the 'brakes' section. Obviously, this is a huge difference between a racecar and a payload in outer space. Which tends to undermine the analogy. This is why I used the 'truck' example instead, because truck brakes do not rely so heavily on aerodynamic forces or rapid air-cooling of brakes that would otherwise heat up enough to melt. Correspondingly, they are bulkier.

The trick is, if you want to move to the second level, you can (and should) do this kind of thing automatically, in the middle of setting up your own proposal. Asking yourself the question "would this work?" is a huge timesaver and makes people who operate at a high level much more interested in talking to you.


I see your point, and I agree. I'll exercise more due diligence.
Point 1 is due to the same reason as point 2 actually, I simply forgot to consider the braking forces from the payload's end.

Let me apply one other 'solution': collision braking. There's another, using tapered flywheels that shoot out a web of cables at orbital velocity, but I cannot find the correct maths.

What are the elements involved?

A solid-mass of high-strength steel, with holes on the sides for bolts to be inserted into. The 'hook'. Must not deform under 500K temperatures or 3000G acceleration.

A lightweight extremely high positioning accuracy drone. It uses micro-arcjet thrusters or electric solid propellant rockets for control. It must guide the hook and payload tether end into a 2m target within 14 seconds, with an accuracy of +/-0.5m/s.

An 1000m length of tether. Built out of a core of Zylon. Attached sideways to the hook. Must survive up to to 29.4m/s^2 acceleration per meter length, as a gradient between the hook and the spaceship. It is coated in graphite to help it survive hot outgassing. Peak forces are at 500m length with 2.72MN. It is tapered at a 1:1.46:1 ratio.

A 874m tube of gas, resembling a light-gas gun in reverse. Each stage holds a certain density of gas. Each gas has a 1.084x compression ratio. Actual compression is higher, but gas is bled out of a vertical slot on one side that allows the tether to pass through. High-Z gasses reduce pressure so that very little escapes per stage. Once pressure rises to 1.084x its initial amount, a valve opens to the next stage. The remaining gas is recovered. Between each stage is a heat-insulating high-strength piston/heatshield. 85*10m stages reach a 962x compression ratio. Initial gas density is 0.00985kg/m^3. Final gas density is 9.45kg/m^3. Acceleration due to drag is a constant 3000G.

A railgun accelerates the first piston/heatshield to 7300m/s. At 1kg, this costs 26MJ.

An arrestor wire system. It must catch the hook and final heatshield at 236m/s.

A bolt attachment system. High strength steel bolts are inserted through the entire width of the hook and connect it to the main platform tether.

Object masses:

Hook mass 27kg.
Drone mass 100kg, containing 50kg of propellant for 193m/s+ deltaV (2km/s exhaust).
1000m tether masses about 414kg.
Light gas gun barrels unknown mass, but considered part of the platform's inert mass. Pressure is low.
5889kg of gas at average density 1.412kg/m^3.

How it works:
It's kind of answering your 'catch a railgun round' example with a 'what if you could?'
The payload releases the drone before rendezvous. The drone is lightweight and only has to move the tip of the tether into position most of the time, so has more than 193m/s of deltaV available.

The railgun accelerates the first heatshield to 7300m/s.

The hook impacts the first plate at a relative velocity between 0.1 and 10m/s, depending on how reliable the railgun and drone are. Spring-loaded latches can be used to hold the hook at the center of the plate.

The plate enters the first gun chamber and encounters rarified gas. The drag force accelerates it at 3000G. Each stage increases density of the gas so that a continuous 3000G is achieved. The hook and the final plate are released after about 0.36 seconds, after a distance of 850m, travelling at 236m/s.

The tether is dragged through an opening in the side of the pressure chambers. Low pressures and a projectile speed faster than sound in the gas help prevent too much gas from being lost. A triggered opening of the slot can help further reduce gas losses.

The first stage contains 0.48kg of gas, which absorbs 16MJ. This is the most extreme stage. Every other stage absorbs less energy using more gas. If we use Hydrogen, temperature rises to 2406K. Later stages can use gasses such as Argon or Neon.

At the end of its run, the hook is caught by an arrestor cable and drawn into a position where bolts can be driven through its openings. In the worst case scenario, the bolts must be locked within 0.02 seconds before the hook is ripped away by the payload's tether reaching maximum extension of 1000m.

The hook, now bolted to the main tether, is released and pulls on a pulley train.

For this to work, you need your suborbital payload to be in exactly the right orbital plane and launch at exactly the right moment, for nothing to go wrong on the rocket, and so on. Because if anything goes wrong at any point, you can't just correct by gently nudging the satellite from its 'unsatisfactory' orbit to a better one, the way real satellite payloads do. You have no way to recover from even the slightest problem with the launch, because you don't get to stop and try again- the station is passing the payload at 7 km/s.


If the reverse-gas-gun capture of the hook works out a 200km orbit capture of a payload might be reasonable. This only requires 2000m/s of vertical deltaV to reach. At that low figure, various non-rocket launch systems are available, and we might expect greater accuracy from a StarTram or HASTOL than from a rocket.

The difference between 1000km and 200km altitude is 200m/s in orbital velocity. Without huge rotating tethers, a BOT can operate without much greater difficulty at very low orbits.

How, mechanically? Galileo's cannon transfers momentum by an elastic collision between two rubber balls or similar objects. How does your device transfer the momentum?


It not my design. What I understood is that tip velocity in a bow can be tip that of the edge velocity. If 1000m/s flywheels pulls on on either end of a wire, the tip will reach 4km/s. However, a staged device, using several tethers as lever arms, might reach orbital velocity as long as there is enough momentum in the system.
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-01 08:50pm

LaCroix wrote:
Simon_Jester wrote:
Cage is moving at 0m/s relative to the spacecraft at capture.
Then how is the cage accelerated? What object exerts what force on the cage to change its velocity?


Picking up that thread...

The problem is that the cage is only at 0m/s relative speed for 1/7300 of a second during capture while the swings direction is in opposition to the swing's central axis' forward motion (following the station at 7300m/s).

So theoretically, everything stands perfectly still for a moment, and all is right in the world.


Apparently, it was a major problem for the traditional Rotorvator too.

Since the weight is suddenly doubled after docking, but the energy wants to remain the same, the whole system will be slowed down to about 5160m/s. 2140m/s speed loss. I can't even attempt to calculate the time it will take to slow that down (elasticity of materials, other factors, my lack of education in that field) to compute the acellerations we are dealing with, but since we're pretty much talking about microseconds in terms of positioning here, and km/s absolute speeds, I feel that this won't be pretty.

My general assumption is that half the kinetic energy will be transfered to the payload, pretty much instantly, and 130 plus change GJ (~30 tons TNT equivalent) rip it apart, along with the cage.


The trick is to release the payload and cage, now attached to the braking tether, as soon as contact is confirmed. They'll continue in a straight line, taking energy from the flywheel at the relatively gentle rate of 9G.
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-01 09:08pm

Simon_Jester wrote:You know, if we start launching large numbers of these stations with big trailing 100-kilometer tethers... Heck, we've got catcher stations, presumably multiple catcher stations because they can't all service the same launch facilities at the same time and have to be in an orbital inclination that lets them catch payloads from the places the rockets fly out of, then we've got slings that boost from orbit...


Since the tether does not have to be aligned with the direction of travel of the BOT platform, it can catch and brake payloads from other inclinations and insert them into its own.

That's a lot of very long ropes spinning around in space. It becomes increasingly likely that we'll see on-orbit collisions of tethers. Or severe restrictions on when the system can and cannot operate, out of fear of hitting stations and satellites with the tether.


I agree now that the spinning tether idea was poor.

The trick is to do so by minimizing the disadvantages of the system (like exposing objects in space to extremely brutal mechanical accelerations and forces).


I've been trading out mass for acceleration. A surprising fact I stumbled upon was that tether mass was independent of how hard you accelerated the payload: short and fat or long and shin weigh pretty much the same. However, very long payloads see increased losses to the number of pulleys required. So theoretically, we could have a 3G BOT platform catching 10 ton payloads at 200km altitude... over 955km. It would take over four minutes! The payload would fall to the ground unless it employed some sort of lift system. There's a 1:1 relationship between tether length and acceleration.

You've been trying to make your idea 'do more work' by imparting ALL the delta-V and by designing the system with no margin for error. This is not a practical approach to designing things that work.


I usually leave a 300% margin of error.

What is practical, is thinking in terms of "being fully aware of the parts of my system that present the greatest challenges, how do I modify the system to reduce the challenges?" But to do that, you have to anticipate the challenges and identify likely failure points in your system, where you are doing things that are difficult (like surviving very high accelerations for very long times) or even impossible (like trying to launch a suborbital rocket on a ballistic trajectory so precisely that it winds up in exactly the right centimeter of space on exactly the right vector at exactly the right millisecond).


Likely worst failure mode? Unavoidable collision and destruction of everything. But how is it we fly planes a thousand times a day, which can crash into a city and kill thousands?

I agree that the skip-rope idea was too extreme, but I'd like to focus on creating a low-energy investment, low mass requirement access to space design instead of sticking to rockets all the way to the point that we invent a material that makes space elevators useful.
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-01 09:10pm

Zeropoint wrote:The elephant in the room for this idea is that it's all designed around saving rocket fuel. This is a bad idea; rocket fuel is cheap. Rockets are expensive, and traditional rocket launches require building rockets and using them only once. That's why, here in the real world, we see SpaceX focusing on reusable rocket stages. When you can re-use the whole launch stack, launches are cheap and a low payload ratio is a nuisance, not a deal-breaker.


Smaller rockets use less engines and have smaller fuel tanks. They save more than just the mass in fuel. You can even get away with cheap Kerolox designs rather than high-performance Hydrolox.

The 200km non-human-rated BOT platform only requires 2000m/s of vertical deltaV!
Google + : matterbeamTSF

Hard SF blog: ToughSF

MetaSeed: Worldbuilding and Game Design discussion

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-01 10:52pm

Smaller rockets use less engines and have smaller fuel tanks. They save more than just the mass in fuel. You can even get away with cheap Kerolox designs rather than high-performance Hydrolox.


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

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.
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.

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

Re: Boosted Orbital Tether and Orbital Runway upgrades

Postby Simon_Jester » 2017-02-01 11:55pm

matterbeam wrote:
Simon_Jester wrote:You know, if we start launching large numbers of these stations with big trailing 100-kilometer tethers... Heck, we've got catcher stations, presumably multiple catcher stations because they can't all service the same launch facilities at the same time and have to be in an orbital inclination that lets them catch payloads from the places the rockets fly out of, then we've got slings that boost from orbit...
Since the tether does not have to be aligned with the direction of travel of the BOT platform, it can catch and brake payloads from other inclinations and insert them into its own.
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.

Which imposes extra cost in the form of delays, parts and processes that can go wrong and slam your launch window shut, and so on.

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."

You've been trying to make your idea 'do more work' by imparting ALL the delta-V and by designing the system with no margin for error. This is not a practical approach to designing things that work.
I usually leave a 300% margin of error.
Not where it matters.

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.

Where you have not left margins of error are:

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.

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.'

[Some of these specific examples are from old proposals you have since reconsidered. But that's not the point. The point is, ALL your plans have been riddled with single point failure modes, where there is no backup, no reserve capability that says "even if X goes wrong, Y will save the day."]

What is practical, is thinking in terms of "being fully aware of the parts of my system that present the greatest challenges, how do I modify the system to reduce the challenges?" But to do that, you have to anticipate the challenges and identify likely failure points in your system, where you are doing things that are difficult (like surviving very high accelerations for very long times) or even impossible (like trying to launch a suborbital rocket on a ballistic trajectory so precisely that it winds up in exactly the right centimeter of space on exactly the right vector at exactly the right millisecond).
Likely worst failure mode? Unavoidable collision and destruction of everything. But how is it we fly planes a thousand times a day, which can crash into a city and kill thousands?
That's not the case and you know it.

What is the case is that the engineer goes over the system and identifies likely failure modes. Then solves them first.

For example, when designing a plane, what is a likely failure mode? The wings might fall off. So beef up the wing spar until there's no realistic way for that to happen (that is, include a large factor of safety in the strength of the wing spar). If that means the plane idea cannot fly, the plane can't fly. One does not keep running around in circles trying to make a fundamentally unsafe idea 'work' if one cannot solve the problem that caused the safety issue.

Okay, so we're sure the wings won't fall off. Well, what else could go wrong? The engine could fail. Now, if the plane is large, the solution is "have multiple engines, so the plane can function with loss of power. But we also make sure to design planes that can glide, precisely so that if ALL engines fail (and we know they might), the pilot and passengers and cargo aren't necessarily doomed. A plane that loses all engine power may still be able to glide dozens of kilometers in search of a safe place to land.

Okay, what else could go wrong? The control systems could fail, leaving working engines and flaps to guide the plane, but no way for the pilot to control them. This is a great example of a place where engineers build REAL margins of error into a design. Because they don't just have one wire connecting the cockpit to the ailerons or the engines. They have three or four independent paths of control, sometimes using totally different systems that cannot possibly be knocked out by the same category of accident unless it's something massive like "the wing just fell off." And then they go back and insure against those accidents by beefing up the structure, and so on.

What else could happen? The pilot could get confused about navigation issues and get off course. It turns out that there's no way to fix this by building a better plane- but we solve it anyway! We solve it by making the whole system resilient and flexible, by creating a dedicated network of ground control stations that track the planes, communicate with the pilots, and help them stay on course and on schedule. This is another good example, because what's happening here is that the whole system is being made robust. It's not just about insuring against any one specific physical part breaking by making the parts beefy. It's about insuring against accidents and bad luck in general by creating systems that can come into action to save the day.

We're not looking at worst case failure scenarios, in the sense of "what is the worst possible outcome of this system malfunctioning." We're looking at weak points in the system where a failure could potentially lead to disaster, and trying to compensate for them.

That is the mindset here. That leads to successful systems like the world's passenger aviation system.

I agree that the skip-rope idea was too extreme, but I'd like to focus on creating a low-energy investment, low mass requirement access to space design instead of sticking to rockets all the way to the point that we invent a material that makes space elevators useful.
Yes, but there are a LOT of possible options for this. Your personal services brainstorming ideas for this are useful only if you are doing your brainstorming in a sensible way.
This space dedicated to Vasily Arkhipov


Return to “Science, Logic, And Morality”

Who is online

Users browsing this forum: No registered users and 4 guests