layout | date | from | serial | subject |
---|---|---|---|---|
tindallgram |
Aug 30 1966 |
FM/Deputy Chief, Mission Planning and Analysis Division |
66-FM1-100 |
Notes regarding the AS-207/208 Guidance Systems Operation Plan (GSOP) meeting with MIT |
During the week of August 15, we held a review of the AS-207/208 Guidance Systems Operation Plan (GSOP) at MIT. Some things interested me which I will pass on to you here. I will also include some of the more significant decisions--that is, direction to MIT--that were made at that time
-
It is currently planned that the astronaut will freeze the rendezvous maneuver sequence by a manual input to the computer. This will be done at about twelve minutes before each of the maneuvers, including the TPI maneuver. It serves to prevent new observational (e.g., radar) data from changing the maneuver he intends to make next. It does this by causing the computer to completely ignore all new observational data obtained between the time of his signal and the maneuver. In fact, whatever data is collected during that period is never used, even after the maneuver has been executed.
-
Logic is being introduced into the rendezvous navigation program (i.e., the orbit determination used during rendezvous) which, in effect, edits the observational data automatically. Specifically, if the change in both the computed velocity magnitude and the computed position of the spacecraft is less than some pre-established amount due to the processing of new observational data, that data is adjudged to be good and is automatically included in the solution. If the change, in either of these quantities is in excess of some larger pre-established amount, the data is not accepted (unless the crew permits it), an_ a program alarm light comes on. If the change in those quantities falls between these two limits, the data is accepted and used, but the alarm light would be lit.
-
MIT was directed not to provide a mode for utilizing Alignment Optical Telescope (AOT) data in the rendezvous navigation. This had been tentatively suggested for use in the event of a rendezvous radar failure but, based: on the likelihood that the AOT data would not be of any value, it was decided not to complicate the program to permit its use.
-
Due to fear of some ambiguity, the computer program is designed to reject radar data when the estimated range to the target exceeds 400 n.m.
-
One of MIT's questions left unresolved was whether or not an automatic sextant search pattern is required as a lunar module acquisition aid. MIT intends to make a recommendation on this.
-
The flight crew people have requested that the display of duration of time in the terminal phase between TPI and TPF be in seconds. Since this is not one of the standard time display formats, MIT was directed to retain units of hours:minutes:seconds as they proposed, unless the crew has really good reasons to provide this new format. Tom Hardy has the action.
-
As usual, there was a discussion as to the reference to be used in the display of altitude. MIT was directed to compute and display all spacecraft altitudes referenced to a spherical earth with radius equal to that of the launch pad. This reference was determined to be best, although not perfect, for rendezvous missions after what seemed to be endless months of discussion. Coordinates of landmarks used for orbit determination, however, will be referenced to the Fischer Ellipsoid.
-
As a result of the crew's dissatisfaction with the fixed heads-down attitude forced upon them during SPS maneuvers on AS-204/205, MIT proposes to eliminate that constraint in the AS-207/208 programs. The computer will display a "preferred attitude," which is heads-up, but will not automatically orient the spacecraft to that attitude. As I understand it, it will hold whatever spacecraft "roll" attitude it happens to end up with when the thruster axis is properly aligned. It is possible for the crew to manually change this attitude if it is undesirable by deactivating computer attitude control, then manually changing the attitude and reinitiating computer control, which will then hold the new attitude.
-
No minimum impulse capability is to be implemented in the LGC since there appears to be no requirement for this, whatever it is.
-
As usual, the question of navigation (i.e., orbit determination) in earth orbit came up again. We previously had directed MIT not to include this capability in the AS-207/208 mission programs since it is not required for the lunar mission. However, they, and some MSC people, feel it is desirable to provide this capability in order to obtain further experience with the process prior to going to the moon. Thus, this is still an open item. It has been agreed, in any case, that orbit determination using unknown landmarks would not be included, and, although the provision is being made for star/moon horizon measurements, they will only be used to obtain CDU angles to be transmitted on the downlink and they will not be used in the navigation program.
Norm Sears estimates that the orbit determination process should be completed within about ten seconds of accepting an observation. Also, he would like to establish a procedure whereby data points are obtained at the rate of about one per minute.
-
MIT was directed to delete the guidance reference release (GRR) signal, its function to be replaced by the lift-off signal. As I understand it, there is some controversy over this which Aaron Cohen intends to resolve at MSC.
-
One feature of this program which particularly disturbs me, and many others, is the tremendous amount of work the astronaut must perform to use the computer program. Of course, much of this comes about as a result of the trade-off to provide mission flexibility by giving the crew the capability of controlling what the computer is doing as opposed to having it perform automatically. Another specific example is the amount of data which must be input to the computer prior to making a maneuver, including such things as spacecraft weight and inertia, engine trim angles, tailoff, spacecraft configuration (docked or undocked), and level of rate response to hand controller inputs. It would certainly be desirable, if possible, to eliminate as many of these inputs as possible, either by putting them in fixed memory--if that is a reasonable thing to do--or by deleting them altogether. There is some question in my mind as to how accurately some of them can be determined by the crew, and we may find that there is no significant advantage obtained by updating them. This will be followed up.
I'm sure there was something else interesting that came up there, but I don't remember it right now.