And I understand everyone's convictions and their solid understanding on these subjects.
Do you understand that conviction in this case is born of solid understanding? As in, a professional level of understanding? As in, I can list the actual spacecraft and actual launch vehicles that I've worked on, and I can speak of their design problems not from the position of having read about them in web sites and on books, but from the position of having had to solve them myself and be on the hook for the validity of those solutions? For some of us here, space engineering was thoroughly demystified a long time ago. We don't look at these problems, or the products of their solutions, and allow the mist in our eyes to blind us to how it all actually works.
It is common for hoax claimants to think that believing in Apollo is an act of national pride, or devotion to a cause, or a knee-jerk reaction. In other words, it is common to attribute belief to an emotional need. In this case it is not true. Belief here is a matter of knowing the relevant facts and drawing logically valid conclusions from them.
And I respect everyone's position.
No, I don't think you do. You're being taught by people who actually do for a living the things you're reading about. You present questions of the sort that a reasonable student of the field would present. But when you are given the correct answers from the field, your response is, "No, I still think what I've said presents a genuine problem." If you really respected our position, you would thoroughly understand where it comes from and do more than simply repeat your concerns and demand that they be reconsidered. In many cases our answers correct the wrong assumptions and misconceptions upon which your concerns are based. When that happens, and a rationale has been given for it, you don't simply get to insist that your assumptions and misconceptions must remain in force. Yet on some of your questions that's what you're doing. It often doesn't take much "considered thought" to recognize the same wrong assumptions hoax theorists have been bringing to the table for years, and to give a proper rebuttal in the form of challenging the assumption.
First I would like to point out I meant to say positive feedback loop not negative.
Very well. Since I don't know you very well yet, I'll accept in this case that you misspoke. But be warned: if you plan to base further arguments on the premise that you are well-versed in the relevant science, and if the aim of those arguments is to suggest that Apollo was somehow staged or lied about, then the professional scientists and engineers in this forum will grant you
zero further quarter for errors of this sort. One of the ways we will know whether your premise is true is whether you can speak correctly about the underlying sciences in the correct language. I hope you realize that you can't bluff your way past this audience.
Now that we've agreed on the direction of convergence, do you wish to pursue your argument? Yes, feedback is something to beware of in any closed-loop control system. What can you tell us specifically about the lunar module's autopilot and how it handled feedback of the kind you mention? Your argument so far is merely handwaving. You raise an abstract concern, but you don't connect it to any observable circumstance or to any particular failure or omission in the design that would make your concern operative. You're begging the question that the LM DAP couldn't handle feedback.
With regards to the deflectors, I still think people should not dismiss this issue.
No one has dismissed it. Rather, they have patiently, and in suitable detail, pointed out why your proposition that the deflectors would make the LM unstable assumes things that do not hold. The effects on stability are all modeled as moments in the framework of a generalized solution. Intentional effects include those caused by steering vanes in atmospheric flight or reaction wheels and jets. Unintended causes include fuel slosh, fuel depletion, staging, the jettison of expendable components, or outside impacts. Even flexing from variations in heating creates behavior that can be modeled this way. All this just goes into the pot.
Modeling the effect of an RCS plume impinging on the plume deflector is no different. It's just another input for the overall guidance model. I walked you through a first-order modeling exercise. It's not clear whether you did any such modeling, but I'm guessing you didn't. You seem to have merely assumed that the moments it generated were significant and unplanned. I have refuted that assumption using the same principles of engineering that would have been used by the scientists and engineers designing the plume deflectors. You have not challenged those principles or my employment of them. You seem to be asking that we just set them aside and agree instead with your irrational fears.
As one poster rightly pointed out, because of the deflectors, stability required the engines to be fired in pairs.
If I'm that poster, then I made no such claim.
In the RCS configurations favored by most practical designs, sets of thrusters operating in concert or opposition offer several design advantages, although naturally at the cost of greater complexity and mass. The LM could effect very spritely yaw moments using four thrusters, or more sedate yaw moments using only two thrusters. The implied symmetry would be a requirement for a spacecraft whose mission could not tolerate translation residuals. I pointed out that the LM
can tolerate such residuals, and that in fact the effect of any such residual would be lost in the noise of all the other translational maneuvers the LM was already doing. As such, the LM can maintain yaw control with only one of its four relevant thrusters operating.
The plume deflector does not alter this dramatically. What I pointed out was that when the RCS was operated in the intended way, the effects of the deflector summed and canceled out in a particular way that was neutral to stability and guidance. It's a matter of explaining what would happen under common conditions, not insisting that those conditions had to hold. The plume deflectors did not alter whatsoever the way in which the RCS jets were commanded.
It also needed to be perfectly balanced...
Nonsense. No spacecraft is
ever flown presuming that the principal thrust operates exactly through its center of mass. You propose that you are familiar with the field, but you keep relying upon layman's misconceptions.
...according to the MIT paper, which I will find.
Yes, you do that. You have made several references to offerings in the literature that you say support your belief, but you haven't produced a single one of them.
I and others here are very familiar with the documentation from the Draper lab that lays out the generalized model of guidance and how it was specifically implemented for the lunar module. You seem to have come away from those documents with an understanding that differs markedly from that of others, and more closely resembles the simplifications laymen commonly find. Further, many of us here can also quote chapter-and-verse from such standard references as
Fundamentals of Astrodynamics and
Spacecraft Dynamics and Control, which provide alternative models (the first reference) or expand the general stability model -- at book length -- to practically any conceivable problem one could have in controlling a spacecraft (the second reference). So when you suggest that the literature supports you, we can confidently say, "No, it does not." Until you provide actual references, we cannot determine why you think they do.
Do you not think that would present a problem? Changing fuel, moving astronauts etc.
You seem to think these were problems that hadn't been faced and solved in rocketry long prior to Apollo. As I told you before, there is no sudden mystique in Apollo or its lunar module that somehow invalidates the general guidance model. Of course anything that relocates the center of mass or imposes a moment would "present a problem" for stability. But only a naive analysis would assume that there isn't a straightforward, generalized solution to all of them. No rocket scientist ever assumed his center of mass would stay put in his design. No rocket scientist ever assumed that unexpected moments would not arise. Nobody has ever designed assuming such ideal conditions. Once you relax the assumption that the center of mass will never be fixed, then you stop caring what specific things might make it change. And once you relax the assumption that the only moments will be those you command, then you stop caring what specific causes might arise. And when someone asks, "Aren't you concerned at all these special new things the lunar module had to contend with?" the answer is, "If I can model them in the standard guidance model, then no."
Also what if any of the RCS's failed? They had failed prior to A11. Yet they had no backups on these 7 flights.
Of course they did. Just perhaps not something you immediately recognize as a "backup." I'm guessing by "backup" you mean a fully-redundant set of jets in compatible locations to the primary, thrusting in generally the same directions as the primary. That's a reasonable first pass at redundancy. The problem with most laymen's attempts to second-guess Apollo designs is that they have only thought of these first-pass solutions. Or stated more generally, they think that the way they would have designed Apollo is the way any conscientious engineer would have done it. From that follows the accusation that if a design doesn't seem common-sensical in that way, it is somehow suspect.
If you've seen the error and error-rate state diagrams for a single DAP channel, you will have seen how the control laws were derived for each envelope in the diagram. The output from the control law is either "do nothing" (i.e., within the deadband) or "command rate-positive" or "command rate-negative." How the rate commands get interpreted by the RCS controller is another matter. Nominally an LM DAP command to "yaw positive, best rate" would be interpreted by the RCS controller in terms of firing four thrusters. The controller knows which thrusters are in an operable state because it has either detected their failure, or the pilot has switched a jet off. In this case, the RCS controller "knows" (i.e., has been designed) that it can execute the command with up to three of the relevant thrusters inoperative. In this highly-degraded condition, the DAP will note that the error rate is changing more slowly than usual, but as long as it is moving in the right direction to the set-point value, it will patiently wait for that to occur. The pilot will feel this simply as sluggishness in the yaw motion. Only if the RCS controller has all four yaw-relevant thrusters out will it signal an exception that would need extraordinary attention from the computer or pilot. That's an unbelievable degree of redundancy in the yaw channel.
Okay, consider the pitch channel. Again nominally, the RCS controller responds to a DAP command "pitch forward" by firing four thrusters -- two firing upward in front and two firing downward in back. This produces a forward pitch moment, and a desired pitch rate. What if one of those fails, let's say the one just outside the pilot's window. The RCS is told not to use that jet, either by its own detection or by the pilot's command. The built-in combinatorial logic then inhibits the co-pilot's side jet too. A "pitch forward" command is answered by firing the jets in the rear quads only. Ditto for left and right roll. "But," you might say," doesn't that also result in thrusting upward as an unwanted translation -- a residual?" And the answer is, "Yes, but we don't care." In the LM's case, the 800 N of accidental additional thrust is lost in the 30,000 N of thrust from the DPS along the same axis. If that were a problem, then the DPS senses a drop in the descent rate and throttles the DPS back a little to compensate.
Okay, for nits and giggles let's
also fail the downward-squirting thruster on the pilot's side. The combinatorial logic in the RCS controller does
not inhibit the companion thruster on the co-pilot's side because it "knows" (i.e., is in a combinatorial-logic state that expresses degraded operation) that it would be otherwise unable to create forward-pitch moments at all. So it goes ahead and fires that jet alone. And the layman might rightly say, "Yikes! It's so off-center it's going to throw the vehicle off-kilter." Well, yes and no. The advantage you gain by decoupling all the control channels as we do is that the last remaining control action -- our
second fallback configuration -- is still able to answer Yes when the DAP tells it to pitch forward. Even with two jets gone, we can still pitch the vehicle. "But what about the obvious left roll this will also cause?" That's the roll channel's problem. The DAP told us to pitch forward, and we have a thruster configuration that can
at least do that. The DAP is also perhaps wanting us to keep an even keel in the roll channel, so when it notices an error rate there, it will send additional "roll right" commands to the RCS controller. And depending on the situation, the thrusters that would respond to those commands might be in perfect working order. I would expect a beginning electrical engineering student to take about an hour to design the RCS controller circuit that could satisfy these constraints. In fact, a simplified version of it one of my interview questions for certain kinds of engineer.
The point is that the configuration that's already there in the LM provides a considerable amount of redundancy if you just think carefully about what you can do with it. The key, again, is the single-mindedness of the individual channel controllers. The layman's approach to designs like this is often to lump the whole control problem together into a single monolithic solution. The engineer decouples and disentangles until he's left with a set of individual problems, each of which is individually simple to understand and address.
The secret is that these cross-control scenarios, where a commanded pitch maneuver might have residual consequences in roll and/or yaw, are the rule, not the exception. Remember I said it is not possible to have a fixed RCS installation that is also ideal for all control axes. With careful mechanical design you can minimize those residuals. But the student needs to be vigorously disabused of the notion that RCS systems he will actually design and build, and which will actually fly on spacecraft, exhibit any of the abstract niceties we allude to in illustrative drawings. Even very simple commanded actions will produce "impure" patterns of thruster fire.
Now we're not disregarding the significance of degraded performance or out-of-tolerance inputs. The generalized guidance solution presumes limits on moments, whether imposed or commanded. When we can predict them, we can set reasonable design requirements. But those requirements presume what we're trying to do. Performance that's required to land safely on the Moon is allowed to be higher than other levels of performance the design can meet which are concerned merely with survival. You might, for example, need to use the LM to control the docked CSM/LM stack, something it wasn't intended to do. You can "control" it, but not very well. Certainly not well enough to do all the things you originally built the spaceship to do. But maybe well enough to get home, which is not necessarily as hard a problem. Similarly a damaged LM RCS might not be up to snuff if the requirement is to make a pinpoint landing on the Moon. But it can satisfy the requirements of getting to any stable abort orbit so that the CSM can swoop down and rescue it. Not all the engineering of Apollo went into assuring mission success at all costs. Much more of it, in fact, went into being able to recover non-fatally from missions that fail. You fly six or seven missions so that not every one of them has to succeed. And if something happens that violates a mission rule (e.g., "You must have all 16 RCS jets functioning on the LM prior to DOI") then you still have reserve capacity to get home. Not to fly loop-de-loops, but to get home.
...how did the RCS's nozzles not get torn off the Saturn on liftoff.
As previously stated, because they were in the turbulent boundary layer separation zone. They required no fairings.
...those small nozzle cups facing up not to get torn off.
How far did you take the mathematics of this concern to convince yourself it would be a problem? Did you do any calculations? Or did you just look at the picture and jump to a conclusion?
Even if they were not torn off, they could have been easily damaged or compromised.
How easily? In what kind of scenario? By what anticipated cause?
Engineering -- especially aerospace engineering -- is not merely unbridled alarmism. One doesn't provide corrections for conditions that aren't a problem, because the corrections themselves often bring parasitical problems along with them that you could avoid by simply tolerating the condition.
It's easy to find pictures of these jets. If you live near San Diego, you can see one in person. And a lucky few like me, who practice the profession, have held them and hefted them in our hands, and consequently have a very visceral understanding of how robust they are. I seriously believe I could hammer a nail with one. Ram air gets choked at the nozzle throat, so the structure behind it is relatively protected. The diaphragms of the solenoid valves are deep inside tubes leading to the thrust chamber. The only thing ram air would hit is the Inconel pre-ignition chamber, which is exceptionally robust. (That's what they make jet engine turbines out of.) And that's really the bottom line: even if the RCS jet were in the laminar flow -- which it isn't -- that's nothing compared to thermal, shock, and pressure abuse it takes simply by doing its job as a rocket motor.
So let's say that we provide a jettisonable fairing for it out of an abundance of caution. That then becomes yet another thing that has to work perfectly for the mission to proceed. The RCS jet is protected against the extremely unlikely event of its being damaged during boost, but then what if it won't pop off on command? Mission rules say you need all 16 SM RCS jets working in order to go to the Moon, because you might need full CSM maneuverability to rescue the LM, or to align yourself precisely for LOI-1,2 and TEI. So with that snafu you'd have to simply come home. That would also be true if you lost an unprotected jet on ascent, but that doesn't ever happen. That's to say, it happens seldom enough that
that's the acceptable risk, over the correct performance of an RCS shroud.
That seems quite the risk NASA took given the RCS's had no backups.
Or perhaps your assessment of risk suffers from an alarmist view of the circumstances and your inability to see the full ingenuity of the solutions these professional engineers at the tops of their careers came up with, in an industrial era dubbed the Golden Age of Aerospace.
