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?
