Apollo Experience Report Guidance and Control Systems Digital Autopilot Design Development

8/8/2019 Apollo Experience Report Guidance and Control Systems Digital Autopilot Design Development

1/47

12/73- 5 mA S A T E C H N I C A L N O T E NASA TN D-7289

OI00Nh

APOLLO EXPERIENCE REPORT -GUIDANCE AND CONTROL SYSTEMSDigital Autopilot Design Development

by Willium H . Peters und Kenneth J. CoxManned Sucecm? CenterHou s t o ~ ,Texus 77058N A T I O N A L A ER ON A U T I C S A N D SPA CE A D M I N I ST R A T I ON W A SH I N G T ON , D . C. JUNE 1973


2/47


3/47

CONTENTS

Section PageSUMMARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2GENERAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Development Pr oc es s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Prefli ght Testin g and Verification . . . . . . . . . . . . . . . . . . . . . . .

COMMAND-SERVICE MODULE DIGITAL AUTOPILOT DEVELOPMENT . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .Vehicle Design ConstraintsDesign Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Design Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Design-Development Problems . . . . . . . . . . . . . . . . . . . . . . . . 10

LUNAR MODULE DIGITAL AUTOPILOT DEVELOPMENT . . . . . . . . . . . 19Vehicle Design Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . 20Design Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Design Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Design Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

FLIGHT TEST RESULTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28CONCLUDINGREMARKS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40REFERENCES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

ii i


4/47

TABLES

PageableI11

I11IVVV IVIIVZII

Figure12345678

910

529

DIGITAL AUTOPILOT TESTING MATRIX . . . . . . . . . . . . .SUMMARY OF CSM DAP DETAILED TEST OBJECTIVES . . . . 30

3132323637

SUMMARY OF LM DAP DETAILED TEST OBJECTIVES . . . .APOLLO 8 FLIGHT TEST RESULTSAPOLLO 9 FLIGHT TEST RESULTSAPOLLO 1 0 FLIGHT TEST RESULTS . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .APOLLO 9 LM FLIGHT BURN RESIDUALS . . . . . . . . . . . .APOLLO 10 LM FLIGHT BURN RESIDUALS . . . . . . . . . . .

FIGURESPage

3111 515162222

Digital autopilot developmental process . . . . . . . . . . . . . .Original CSM/LM filter mechanization . . . . . . . . . . . . . .Original guidance and control interf ace . . . . . . . . . . . . . .Alternate guidance control interface (ramp steering) . . . . . . .Final guidance and control interface (rate steering) . . . . . . .Powered-flight automatic control . . . . . . . . . . . . . . . . .Input and output varia bles of the s tat e est imator . . . . . . . . .The phase plane when the LM is in powered as cent o r wheneither of the trim-gimbal-nulling driv e ti me s is grea te rthan 2 seconds during powered descent . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .2333pollo 9 yaw data for SPS burn 5

Ascent propulsion system burn to depletion, U - a x i s phase 36lane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

iv


5/47

ACRONYMSAPSCDUCMCMCCSMDAPDO1DPSDTOEMSG&NGNCSGSOPGTSICsIMULGCLMMSCRCSRHCscsSPSTTCATVC

ascent propulsion sys temcoupling data unitcommand modulecommand module computercommand- se rv ic e moduledigital autopilotdescent orbit insertiondescent propulsion s yst emdetailed test objectiveentry monitor subsystemguidance and navigationguidance, navigation, and control syste mguidance system operations plangimbal-trim systeminterpretive computer simulatorinertial measurement unitLM guidance computerlu na r moduleManned Spacecraft Cent er

reaction control systemrotational hand controllerstabilization and control systemse rvi ce propulsion systemthrus t/trans lation controller assemblyth ru st vector control

V

1


6/47

APOLLO EXPER IENCE REPORTGUIDANCE AND CONTROL SYSTEMS-

DI G IT AL AUT OPIL OT DESIGN DEVELOPMENTBy W i l l i a m H. P e t e rs a n d K e n n e t h J. Co xM a n n e d S pa ce cr af t C e n t e r

S U M M A R Y

The development of the Apollo digital autopilots, which a r e the pr im ar y attitudecontrol systems, is summar ized for the lunar module and the command-service mod-ule. The digital autopilots provide attitude control during all phases of the Apollomission, including a backup mode fo r boost into ea rt h orbit, coasting flight, velocity-change maneuvers, lunar landing, boost into lunar orbit, docking, and entry into ear thatmosphere.The development-process functions and the essentia l information flow paths a r eidentified. Th is identification provides information on the par ticula r NASA/contractorinterface as well as the relationships between the many individual activities. A list

of pr im ar y functional requirements is presented as a prelude to the discussions ofcommand- serv ice module and lunar module digital autopilot development. Specificproblem a r e a s that existed during the design-development phase a r e discussed in detail,including the solut ions that evolved. The repor t concludes with a discussion of flighttest data f ro m the Apollo flights that are pertinent to the demonstration of p erf ormanceof these attitude control systems.

The pr im ar y conclusion concerns the benefits inherent in mechanizing controllerThis mechanization providedogic and signal-shaping dynamics in a digital computer.the flexibility nec essa ry to avoid expensive hardware changes and potential scheduledelays and provided a la rge capacity for performing complicated control- sys tem logicwith essential ly no hardware impact. The feasibility and reliability of thi s approachhave been thoroughly demonstrated by the Apollo Pr og ra m. Other significant conclu-sions include the following.1. Requir ements fo r monitoring s yst em performance can place co nstra ints on thecontrol-system design.2. The danger of prevent ing proper control computations (and subsequent actions)arises if logic branching is too sensitive to predicted plant parameters.3 . Refined analytical techniques a r e necessary to reduce the amount of relianceon la rge -s ca le simulations fo r design verification.


7/47

I N T R O D U C T I O NThe original Apollo P ro gr am concept fo r obtaining a highly reliable attitude con-tro l system fo r the command-service module (CSM) was to c ar ry sp ar e equipment andpe rform inflight maintenance i f nece ssary . Because of seve ral difficulties inherent in

thi s approach and because of a realization that redundant attitude control sys tem s couldbe provided by using baseline el ectronic equipment, on the condition that a completeattitude-controller logic could be implemented in the guidance and navigation (G&N)computer, a decision was made to us e digital autopilots. A t that time, only limit edflight experience using digital control sys tem s existed. Because it wa s not known at thetime whether CSM/lunar module (LM) powered-flight attitude cont rol could be accom-. plished by digital computer logic, a para llel development of a technological backupexisted. This alt erna te approach would have relied on the digital comp uter only to pro-vide backup attitude information. Subsequent stud ies demonstra ted the feasibility ofusing digital autopilot (DAP) cont rol fo r thi s phas e of flight, and the technological back-up was dropped.

A broad overview of the Apollo DAP development pr oc es s and spec ific prob lemareas encountered during development of the Apollo digital autopilo ts are discussed.The first sect ions of the re po rt are applicable to all the DAP designs that were u sedduring different pha ses of the mission. In later sections, the material is separatedinto discussions re lating to the CSM DAP and the LM DAP. The discus sion placesemphasis on t h e CSM and LM thr ust v ector control (TVC) DAP, because mor e pro ble mswe re associated with the development of t he digital con tro lle rs f or powered flight thanwith the development of those for coast ing flight and entry .The control sy ste ms that are the subject of this report have been described indetail elsewhere (refs. 1 to 4), and the material presen ted herein is desc ripti ve only tothe point of illu strat ing g ro s s concepts or particular design problems. The problem

discussions are written for the control- sys tem engineer, but they do not necess arilyrequ ir e an intimate knowledge of the Apollo controlsy st em designs.

GENERALBefore the specific DAP designs are discussed by mission phase, general com-ments that a r e applicable fo r all the CSM and LM control-system developments will bepresented. Topics that will be treated are the NASA and co ntr act or functions and as-pect s of the developmental proc ess, the gene ral DAP functional requ ireme nts, and thepreflight testing and verification philosophy used in the design development.

D e v e l o p m e n t P m e s sThe significant elements of the developmental pr oc es s are diagramed in figure 1.Much of the developmental activity involved the block labeled "Modifications, " as indi-cated by the numerous interface loops. The flexibility f o r incorporating design modifi-catio ns into a digital control syste m in a straightforward , easy, and inexpensive

manner (compared to changes in conventional hardwa re s yst ems ), and also at a later2

rI


8/47

2. Alternate compensation design.Stroke-test-signal design

Development and use ofIndependent design andsoftware verificationt Iope manufact ur ing ISoftware milestone

Cmeetings

Flight testI1 ,Postf l ight analyses 1 I

Figure 1. - Digital autopilotdevelopmental process.

date in the developmental program thanwould normally be allowed, gives the de-signer free dom in the fo rm of extended de-velopmental ti me and the type of changesthat will be tole rated at a particu lar pointin the developmental schedule.The activities diag ramed in figure 1depict the NASA functions on the left and

the contractor functions on the right. Sucha representation is not exact, however, f or .the flow lines repres ent only approximatelythe interactions that actually occurred. Inthe paragraphs that follow, some of thesignificant blocks in fi gure 1 a r e discussedin some detail.

The technical interchange meetingsproved an invaluable extension of the tech-nical monitoring function for trackin g thedevelopmental stat us and fo r planning fu tureemphasis on the existing problems. Theguidance sy st em operations plan (GSOP)constituted the pr im ar y control documenta-tion, and the GSOP eview function providedthe checkpoint for as sur ing that detailed re-quirements would be implemented.The bit- by-bit simulations we re digital programs that caused a general-purposecomputer to function like the airbo rne computer har dware and provided detailed diag-nostic information on flight software coding problems. The hybrid simulations coupledactual flight-type hardware into computer simulations of s pacecraft dynamics. The in-dependent design and software verification consisted primar ily of simulations per -formed at the NASA Manned Spacecraf t Center (MSC) and the spacecraf t cont rac torlabo rato ries , whe re both bit-by-bit and hybrid simulations we re used.A f t e r the software had been developed sufficiently that the schedule required con-figura tion control, software milestone meetings gradually replaced technical-interchange meetings. Beyond this point, design-improvement changes were allowedonly if justifiable to the software configuration control board.

Fu nct ona Requ emen sA comprehensive and realis tic se t of quantitative requirements for any complexsubsystem is difficult to list at the onset of a developmental program. Th is difficultyis caused pr im ar il y by an initial lack of knowledge concerning all the interactions be-tween the pa rt ic ul ar su bsystem and the total system environment with which the sub-sys tem must ultimately be compatible. However, the quantitative requirements thatgradua lly evolve during the developmental process are primaril y design details that

3


9/47

can be considered subordinate to a set of mo re basic functional requirements. Thehierarchy of functional requir ements f o r the Apollo command module (CM), CSM,CSM/LM, LM/CSM, LM-descent, and LM-ascent control sy st em s are as follows.1. Maintenance of att itude orientation sufficiently nea r a commanded orientationduring accumulation of velocity from a rocket-engine burn, during coast ing flight, andduring entry into the ea rt h atmosp here2. Provision of acceptable thrus t-impu lse economy. Th is requi remen t imp lie soperation within the constrain ts of the total reaction-control propellant available3. Provision of an attitude-control loop responsive enough to prevent dynamicinterference with the guidance scheme4. Provision of compensation fo r rigid-body motion, including time-varyinggains to provide fo r inerti a changes as a result of propellan t consumption o r stage -configuration changes5. Provision of compensation fo r thrus t-vec tor misalinement and other distu rb-

anc e torques6. Provision of compensation for propellant-sloshing and structural-bendingresonances, a requirement implying operation within the constraints of st ructural loadlimits7. Provision of stability marg ins of suffi cient magnitude to guarantee the sta-bility of guidance long-period modes, attitude short-per iod modes, prope llant- sloshingresonances, and structural - bending resonan ces8. Provision of acceptable performa nce in convergence from la rg e transient sand in the steady-state limit cycles9. Maintenance of attitude er r o r s and vehicle r a t e s within bounds compatiblewith effective crew monitoring of succe ssful pe rfo rmance

10. Provision of a capability for switching to a redundant controller in ca se ofa malfunctionThe te rm s "sufficiently nea r, '' "acceptable, and so on wer e not specifi ed quantita-tively in all cas es. However, the requi rem ent s we re closely monitored by cognizantNASA engineers during the developmental phase, and requi rement s fo r design improve-ments were negotiated on several occasions.

P r e f l i g h t T e s tin g a n d V e r i f ic a t i o nThe primary objectives of preflight testing wer e to validate the control-systemperformance during nominal, off-nominal, fai lur e, and mission-rel ated conditions.The types of simulation facil ities used included the engineering digital simulator, theinterpretive computer simulato r (ICs), and the hybrid simu lator.

4


10/47

Engineering digital simul ato rs wer e used during the initial developmental andmodification pha ses to provide dynamic validation and perf ormance evaluation of thefunctional design under a broad spe ct rum of mission conditions. The bit-by-bit IC smodeled the detailed computer c har act eri sti cs and was used to verify the pro per tr an s-lation of the functional designs into software progr ams t hat wer e compatible with theflight-computer chara cteris tics and other interfacing software prog rams. Pa ra me te rstudi es asso ciated with off -nominal perfo rmanc e general ly cannot be run efficiently onthe ICs. However, nominal perfo rmanc e verification was conducted on a mission-by-mission basis. The hybrid simulators were used to verify hardware/software inter -fa ce s and to provide overal l system-perfo rmance validation. With respect to the digi-tal autopilots, both the design-validation and mission-verification testi ng pr og ra mswere conducted on hybrid simulators. A l l flight control modes wer e tested for bothnominal and off-nominal conditions. The types of testing a r e listed in table I.

TABLE I. - DIGITAL AUTOPILOT TESTING M A T R M

Flight modeCoasting

Powered

Test conditionLimit-cycle characterieticsTransient behavior (acquisition and recovery )Manual/automatic attitude maneuverTranslation/ullage maneuverOff-nominal performance fiet failures, massmismatches, restarts, thrust

misalinements)

Stability/controllability characteristicsInitial start transient performance(misalinement)Tran sient behavior (acquisition and recove ry)Limit-cycle characteristicsOff-nominal performance (actuator degrada-tions, failures, ma ss mismatches,restarts, degraded thrust)

5


11/47

In addition to t he t esting outlined in table I, special test conditions included(1)control-mode-switching transients, (2) structural loads and structural-stabilityevaluation with je t fa ilu re s and off-nominal bending data, and (3) powered-flight tran-sient s for hardover actuator failures. The control sys tem s wer e subjected to realis-tic flight-environment testing, which included evaluation of the ef fects of propellan tshift and engine-mount compliance. Throughout the Apollo Prog ram , verification-runmat ric es for both ICs and hybrid-simulator testing were extensive.

COMMAND-SERV ICE MODULE D IG I T A L A U TO P I OT DEVELOPMENTThe CSM DAP provides stabi lizati on and cont rol of t he CSM during both coasting. and powered flight. The CM DAP, on the othe r hand, is requi red to provide stabiliza-tion and control of the CM only during coasting flight. The development of the specif icdesigns is reviewed by first outlining the vehicle design c onstr aints and d iscussing thedesign philosophy. Lat er, brief design descr iptions are given to provide general back-ground; then significant design-development problems are discussed.

V e h i c l e D e s ig n C o n s t r a in t sThe basic Apollo vehicle configuration and controlsy st em ha rdware configura-

tion were established in advance of t he bulk of the detailed digital-control-system designwork. This ea rl y development of configurations for ce d the evolution of detai led digital-control-system designs that we re subject to the cons traint s imposed by (1) ehiclestructure, (2) ropulsive devices, (3) total reaction-control propellant, (4) ervicemodule engine actua tors, and (5) digital computer.in the sections that follow. Each constraint will be discussedVehicle str uctur e. - The primar y constraints imposed by the stru cture we re the

potential instabilities of propellant-sloshing and flexible-body resonances during main-engine operation and a potential for excessive str uct ura l loads because of reaction-jettorque pulses. The excessive structural load s wer e primarily the result of a failure-mode situation whereby excessive energy could be tran sfe rr ed to the st ruc tur al r eso-nances without a class ical control-system instability. Thi s condition was due to thefact that the disturbance torque pr ese nt with a failed-on reaction-jet thruster was equalto the net restoring torque presen t when the control torque was applied. The resultingth ru st er duty cycle would be 0. 5 and could conceivably contain high energy at thebending-resonance frequency.Propulsive devices. - The reaction-jet t hru ste rs had a duty-cycle constraint, aminimum tolerable "ontime" command of 14 milliseconds, and sizable pulse-on and

pulse-off delays.pellant tanks arranged so that considerable lateral movement of the vehicle cen ter ofma ss occurred during a main-engine burn. Also, the engine throat wa s cooled by anablative material that could erode i n such a manner that thrust-vector alinement rela-tive to the engine centerline could change with time during a burn. These SPS problemswe re both jer k disturbances. Several engine, engine-actuator, and str uct ura l chara c-te ris tic s contributed to a substantial uncertainty in the initial thrust-vector alinement

The serv ice propulsion sys tem (SPS) had four long, cylindrical pro-

6

I1


12/47

rela tive to the total vehicle cente r of mass. This alinement uncertainty produced aninitial acceleration disturbance.Total reaction-control propellant. - The total impuls e capacity of the reac tion-control propellants caused initial concern to the controlsy st em designers because nomethod fo r accurately predicting analytically the effects of zero-g propellant-sloshdynamics existed. Fo r example, the residua l kinetic energy in the SPS propellantsaf te r main-engine shutdown might requi re substantial amounts of reaction-cont rol-propellant expenditure to damp attitude motions resulting fr om the propellant fo rc eson the tank walls. Fortunately, flight test results indicated that this expenditure wasof no ser ious consequence, probably because attitude-erro r pertu rbati ons were filteredby the control-logic dead band. Considerable effort was expended on ze ro -g slo shmodels, but no tenable models evolved that were substantia ted by Apollo flight resu lt s.

gr ee s of f ree dom that would be required for a rea lis tic model, which would make there su lt s al most entirely dependent on numerous initial conditions that cannot bedeter mined.

The pri mar y problem is caused by the long time constants involved and the many de-

Service module engine actuators. - The SPS engine actuators w ere electromechan-ical devices (motors, gear s, and jackscrews) that had torque and rate limits. In addi-tion, the engine was not mas s balanced, and therefore a potential dynamic interactionexist ed between s tructu ral bending and TVC. This interaction is a type of dynamiccoupling re fe rr ed to in reference 5 as "dog-wags-tail. ''

Digital computer. - Fortunately, the computer capacity for control logic andcomputation rates did not r esu lt in significant constraints on the controlsy st em design,nor did the data quantization of the digital-to-analog conver te rs produce significantlimi t cycling. The limi t cycling that did occur during TVC w a s primarily due to aquantization-induced limit cycle in the guidance loop.

Des ign PhilosophyA s implied by previous sta tements, an original philosophy w a s that optimumreaction control sys te m (RCS) propeliant- consumption efficiency must be maintainedat all times because of a limited rotational-impulse budget. A s the total RCS propellant

budget matured, it wa s realized that the percentage of the total budget being allocatedto attitude hold was sma ll, because most of the propellants wer e requir ed for nominaltranslations and maneuvers and for emergency rese rves. Therefore, a 20-percent-above-optimum-usage ra te for attitude hold would rep res ent a penalty that barelyaff ect ed the noise level of budgeting uncertainty. Therefore, the optimum solutionscould be detuned to make them more tolerant to plant-modeling uncertainty.

Another design philosophy used with success in the development of the reaction-jet attitude-control- syst em designs for the Apollo P ro gr am w a s plant modeling. Thisphilosophy was neither the model-following adaptive technique nor cancellation compen-sation to change the plant-response character istic s, but simply the technique of basingcontrol actions on a predicted plant response. This technique provided valuable leadti me in the control loop, and this added time helped wash out the delays associated withdata sampling, transport lags, and sta te estimation. This technique is valuable for re-ducing the control- sample frequency and attendant computer-load factor . Fur ther mor e,

7


13/47

this technique is essentially trouble-free if the prediction is updated during each controlcycle and if the control cycle is small compared to significant plant and disturbance-tim e constants. Each update tends to wash out any e r r o r s made in the previous predic-tion, s o that the prediction e r r o r diminishes with the control-loop e rr or , and the finalprediction error is only that e r r o r associated with a prediction fo r a control actionlasting less than one control sample period.

Early planning budgeted approximately 20 percent of computer tim e to the controltask ; and, like most things that a r e budgeted in advance, the control computations grewto consume the budget at some points in the mission. This total-computer-budget usageoccu rred only in portions of powered flight, and, even in these case s, economies couldhave been effected, i f necessary. Some re se rv e capacity w as used to build in addition-al flexibility as a hedge against changes in requirements . An example of this reservecapacity is the ea rly u se of a seventh-order compensation filter (later changed to sixthorder) f o r control during CSM/LM-docked SPS burns , when studies had shown that afourth-order filter would suffice for the plant dynamics known at that time. The filtercoefficients wer e placed in the eras able memory, which permitted use of lower or de rfilters, if desi red.

.I

Another a r ea that could be called a design philosophy, but in rea lity concerned aspecific design requirement, was the frequency-band-pass requi remen t for the pitchand yaw attitude control sy st em s during a CSM/LM-docked SPS burn. Thi s require-ment should be as high as possible and consistent with an adequate high-frequency sta-bility margin, but disagreement occ ur red on what marg in was adequate. A conservativeapproach w a s taken initially, in which it was attempted to make the passband as low aspossible and consistent with adequate low-frequency performance. La te r, af te r aninflight test increased confidence in the structural cha rac ter ist ics and after sev era lactual flight demonstrations, the passband was increased, and the higher perfor mancegains were used for the lunar landing mission.

Des gn Desc r pt ionBecause the Apollo mis sion requi red a modular spacecra ft that operated in manydifferent configurations, seve ral s epara te and unique control proble ms occur red. Tocompr ess developmental schedules, the contr acto r assi gned different individuals theresponsibilitie s of designing mission-control pr og ra ms that would control (1)commandmodule computer (CMC) backup to a Saturn rocket boost, (2) CSM o r CSM/LM coast,(3) CSM (alone) powered, (4) CSM/LM powered, and (5)CM preentry and entry. The re-fore, each of these phases can be viewed as independent contr ol-system designs andimplementations, because li ttle prog ram coding was sh ar ed by thes e control routines.The.following material briefly de sc ri be s the control s ys tem for each of these missionphases.

. Command module computer backup to a Saturn rocket boost. - Thi s mode per-formed t h e function of clos ing the Saturn control-system att itu de- err or loop in the CSMand permitted the astronaut to perf orm a guided function manually. This procedureprovides a backup to the inertial pl atf orm in the Saturn instrument unit. The de si redattitude is computed from a polynomial function of ti me during fir st- sta ge flight, andthe resulting attitude e r ro r s a r e sent to the flight control computer in the instrumentunit. The astronaut co mpares the CMC-displayed quant ities of velocity magnitude,

8c

I


14/47

altitude, and altitude rate against predetermined des ire d values and iss ue s rate com-mands to the Saturn ins trument unit by hand-controller motion.Command- se rv ic e module o r CSM/LM coast. - The CSM coasting-flight digitalautopilots u se a digital filter algorithm to estimate attitude ra te fro m noisy platform

gimbal-angle m eas uremen ts and est ima tes of applied control effectiveness. A phase-plane switching logic is used that contains hysteresis. Control torques are availablefr om four quadrants (quads) of four reaction-jet thr ust ers . The th ru st er s in each quadprovide positive and negative for ce s that lie approximately along lines paralle l with twoof the spacecraf t body axes. Eit her pitch-plane quads o r yaw-plane quads can be speci -fied fo r roll control o r X-translation commands (or both). Fu rthe rmore, any combina--tion of quads can be spec ified as nonusable, and the DAP will attempt t o use only theremaining usable quads. Attitude dead bands and maneuver rates can be changedthrough eithe r astronaut o r ground-station commands. Hand-controller inputs a r egiven priority over automatic control and are "hot" at all times. A specified maneuverrate results from hand-controller action. Simultaneous three -axis maneuvers re sul twhen the automatic-maneuver routine is used. Thi s routine rotate s the spacec raft aboutthe single axis nor mal to the plane including the cur re nt longitudinal axis and the longi-tudinal axis at the new desir ed orien tation fo r all conditions except gimbal-lock avoid-ance. The phase-plane switching logic used during an automatic maneuver is the sameas that used for attitude hold. The position constraint c aus es the actual rate to limit-cycle about the desir ed rate. F or the CSM/coasting-flight autopilot, the cont rol sampleperiod is 100 milliseconds.

Command-service module (alone) powered. - The digital compensation filter toCSM powered flight is third ord er, with a zero-frequency gain that is initialized fro mcomputer knowledge of contro l effectiveness. During the SPS engine burn, the gain isdecremented at 10-second interv als to account fo r the in cr ea se in control power result-ing fr om reduced propellant load. The SPS engine gimbal-drive sys tem was teste d be-fore a burn and positioned at the attitude of the expected t r i m position. The cont rolsample period is 40 milliseconds.

Command- se rv ic e module/lunar module powered. - The CSM/LM attitude control-ler for powered flight was originally seventh order (later changed to sixth ord er) . Thegain is als o initialized and decremented every 10 seconds, as discussed for the CSM.In the o riginal design concept, a burn would begin with the use of a control sampleper iod of 40 miIliseconds; but, af te r 7 seconds of burn time, the gain wa s changed, andthe control s ample period was increased to 80 milliseconds. The 40-millisecond DAP(termed MOD 40) wa s originally intended for use throughout the burn, but switching tothe 80- millisecond DAP (termed MOD 80) incre ased the high-frequency stabilitymargins.

Another fe ature of the CSM and CSM/LM powered-flight digital autopilots is athrus t-alin ement tracking loop, which computes the average gimbal-position commandand returns it to gimbal command as a bias. This featu re prevents initial-thrust-alinement er ro r f rom producing a bias i n the attitude err or , which would prohibit us eof att i tude error as an indicator of prope r system per forman ce (to give the ast ron aut sreal-time monitoring information).Command module preentry and entry. - The CM digital autopilots exercised atti-tude control by selecting jets for f i ring f rom a set of six (or 12) eaction-control jets

9


15/47

on the CM.entry s o that the entry DAP had to perf or m r at e damping only for these two axes. Theentry guidance supplied commands for rotating the lift vector about the velocity vector;therefore, transformations wer e perfor med to provide attitude control about the roll-stability axis. The exoatmospheric phase of entry DAP operation provided attitudecontrol about al l three axe s, and mode switching occ urr ed as a function of mea su re dacceleration.

The CM was aerodynamically stable about the pitch and yaw ax es during

Des gn-Deve Iopmen P rob Iem sService propulsion sys tem engine-actuator performance. - During the summerof 1965, the SPS engine ac tuator w a s not meeting per for man ce specifications. Theelectromechanical (motor, gea rs, and jackscrews) actuator w a s supposed to be able toslew the SPS engine position at a steady-state rate of 0. 36 rad /sec, but the first units

delivered we re capable of only 0 . 2 rad/sec. Severe heating proble ms resulted in arequirement to reduce the maximum actuator rate even further or to subject the actua-tor to major redesign. This added requirement caused NASA and contractor personnelto tr y to find the minimum engine-actuator ra te that would be compatible with Apolloattitude-control requirements.

The factors neces sary to establish this requirement were as follows.1. The attitude-control passband requirement (set by the guidance requirement)2. Flexible-body and propellant- slosh stability (To guarantee a stability marginby an analytical pro ces s, significant nonlinearities had to be avoided. )3. Rigid-body reco very fr om la rg e trans ients4. Sound system-design principles5. Cost and schedule fa ctor s

Item 1 established only mild requirements for fast actuator response. Spacecraft guid-ance is primarily a low-frequency phenomenon and is fai rly insensitive to temporar ysaturation of inner-loop signals, unl ess the se lead to inner-loop insta bilit ies.The requirement for linear response to str uctur al oscillations is more difficultto ascertain but can be estimated by assum ing that only one o r two of the low-ordermodes are excited to nea r the point of stru ctu ral failu re. Thi s requirement is then

inteFpreted in t e rms of actuato r command as a function of attitude-sensor location andthe dynamic gain in the controll er. Because of the attenuation being proposed fo r theCSM/LM TVC DAP at frequencies near and above the fir st- mod e resonance, the actu-a t o r command w a s essentially independent of the bending motions.bending o r propellant-slosh resonances are phase stabilized, it is important that themaximum expected excitation not s atur at e TVC, because a large signal instability canresult.

In case s where

Item 3 proved the major constraint on the SpS-actuator ra te requirement. Ana-log simulations of CSM attitude control, using the backup control syst em and an actuat or1 0


16/47

rate limit of 0.1 rad/sec, demonstrated a large signal instability; that is, vehicle atti-tude wocld not converge properly fr om la rg e initial tumbling rat es. Additional st udi esindicated that a n actuator ra te capability of 0.15 rad /se c was desirable to avoid changesin the control- sys tem hardware.Item 4 stipulates that a designer must not overconstrain the design problem.

This requ irement implies conservatism when constraints are being adjusted, becauseall possible ramifications are difficult to predict. For the cas e under discussion, thecost and schedule implications (payoff function) were heavily weighted toward acceptingsom e ris k of l at er difficulty in other ar e a s (e. g., incurring a requirement fo r futurechanges to hardware in the backup control-system hardware). A s a result of these con-flicting factors, the minimum specification finally ag re ed upon by NASA and contractorpersonnel (0.1 rad/sec) was not conservative; however, actual delivered hardware pe r-for med considerably better than this minimum requirement. The final hardware w ascapable of s lewing the SPS engine at approximately 0.15 rad/sec, and backup control-sys tem gain s had been lowered s o that an adequately lar ge signal-stability margin wa sobtained.

Thrust-vector-control filter mechanization. - The single-axis attitude-controlloop compensation for the LM attached to the CSM was synthesized by the guidance andcontrol contractor to be a seventh-order filter. The first attempt at a digital mechani-zation of these dvnamics wa s a straightforward, recurs ive computation per formed byshifting all data by one step each coGputa-tion cycle before multiplying by the appro-pr iat e coefficients and summing. Thisprocess is shown schematically in figure 2,-1where z repres ents a delay of one com-putational interval. The gains a r e simplythe coefficients of the numerator and de-

nominator polynomials of the z-tr an sfo rmver sio n of the fil te r dynamics (ref. 6).The refe rence designates this method as"direct programing. "The straightforward approach did notwork satisfactorily for the reasons dis-

cussed in detail in reference 7. Briefly,the caus e was a re su lt of rep etitive trun-cation e r r o r in the computational process,because each intermediate resu lt had to bes tored in a finite word-length reg iste r.The effect was to shift the effective loca-tion of so me filter poles into the right halfplane, causing the filt er to be unstable.After som e study of this problem by theguidance and control contracto r, thesecond approach discussed in reference 4,called "iterative programing, " was adopt-ed. Thi s technique separa tes the factoredfo rm of the filter transfer function into aproduct of two or mor e (three in the case

Input0-

Pastinputvalue

1st

2nd

3rd

41h

51h

6th

71h

Fil ler scaling gain Filter variable gainut

Ni =Num erat or coefficientDi = Denominator coefficientK = Current f i l ter gainKn = Design-nominal gain

Figure 2. - Original CSM/LM filterrnec hanization.11


17/47

under discussion) smaller filters, implement s these, and allows the output of th e firstto be the input of the second, and s o on. The final Apollo TVC DAP filter mechaniza-tion is discussed in refe rence s 1 and 2; the earlier version, in reference 3.Plant-model deficiencies. - A straightforward synthesis of filte r dynamics neces-

sa ry for stable operation during an SPS engine burn would have been possible only ifcomplete confidence in the mathematica l model of the plant dynamics had existed . Thismodel includes not only the mathematical formulation of t he model, but also th e pro-graming of that model into the digital comp uter simulations being used to verify thefilter design. Generally, the required mathematical formulations have existed fo rso me time, but a prob lem ex ist s because of the multitude of var iab les and a desir e toeliminate unnecessary coupling te r m s to reduce simul ator complexity. This reductionresults in simplified equation sets being published in vario us re ports , and whether o rnot a specified reduced set is applicable to a specified situation is impossible to de ter-mine unless the missing ter ms are available fo r inspection and evaluation. Two exam-pl es of thi s type of prob lem that a ro se during the development of the Apollo CSM TVCDAP concerned the stability of propellant-slosh reso nanc es and a potential instabilityin the air frame and engine dynamics.

Early evaluation of the single-p lane dynamics of the Apollo CSM/LM, pe rformedindependently by MSC personnel and by a support contractor, consistently disa greedwith the guidance and control co ntra ctor res ult s regarding stability of propellant-sloshresonances. The guidance and control contractor re su lt s showed the CSM propellantsloshing to be the mo;e se ve re but with an acceptable stabil ity margin, whe rea s theothe r analyses indicated the LM propellant sloshing to be mo re se ve re and to have un-acceptable stability margins. A thorough investigation of the mode ls showed tha t cou-pling with the translati onal degre e of freed om produced th is disparity of res ult s. TheMSC and suppor t cont ractor models had both been derived under t he assumptio n thatth is coupling wa s small enough to be ignored fo r evaluation of high-frequency rotationaldynamics.Another ea rl y plant-model deficiency was the omiss ion of coupling t e r m s that ca n

give rise to a type of flut ter instability. The MSC studi es had shown that the combinedair fra me and actuator dynamics could be unstable without any attitude-controller inputsto the actuator. The energy sou rce was the thrust force , and the feedback path was in-ertial force s on the engine because of str uct ura l oscillatio ns, causing engine-gimbalingmotion. Th is effect has been te rm ed "dog-wags-tail" as opposed to the other air fra meand engine dynamic coupling known as "tail-wags-dog. 1 f Early contractor models hadomitted these term s. This coupling does reduce damping of the first two structuralresonances of the Apollo CSM/LM vehicle, but not to the point of instability. If thecoupling had reduced the damping to the point of instabilit y, then the adopted DAP f i l -t e r design approach of providing la rg e attenuation to bending s ign als (gain stabilization)would not have produced an acceptable design. Active compensa tion at the firstbending-mode frequency would have been required.

Structural-bending data.- The availability of data to be used in the models was theoverriding problem of the entire TVC DAp developmental process. The difficultiesbegan i n the spr ing of 1965 when a decision was reached that a combined CSM/LM st ru c-tural-dynamics test, which had been planned, could be eliminated f ro m the prog ram.Thi s deficiency wa s later compounded when another decision w as made to de signate theinline responsibility for definition of combined-vehicle structural dynamics to MSC12


18/47

Personnel instead of to one of the Apollo spacecraft pr im e contractors . The resu lt wasa period of confusion regarding data to define ai rf rame dynamics.The idea of an inflight dynamics tes t was proposed in October 1965. Thestructural-dynamics speci alist s had hopes of getting som e data from this tes t that couldbe used to calibra te thei r analytical models in lieu of the ground testing that had beendeleted, but the required additional telemetry measurements were not sanctioned byprogram management. A limited vers ion of the original ly planned test was performed.An MSC cont ractor . computed the first set of three-dimensional mode shap es forthe combined Apollo vehicle in February 1966, 2 years after the initial TVC control lersynthesis. This effort predicted a first-mode frequency approximately 1 octave lowerthan former predictions (roughly 1.0 hertz as opposed to 2.0 hertz). Obviously, th islower prediction ser iously degraded the confidence in the quality of any bending data i n

existence at that t ime and probably was the most significant factor in getting dynamicsground testing of the combined vehicle back into the prog ram.Ground testing was reinstated; but, because of scheduling problems, test prepa-

ration, test performance, data reduction, and other considerations, the re sul ts wer enot available until December 1968. In the interim, the detailed structural-dynamicsmodeling being performed by NASA personnel produced the first set of rea listi c three -dimensional mode shapes, part of which were made available in June 1967. Thi s essen-tial lack of cr edible bending data for the 18-month period encompassing 1966 and thefirst half of 1967 precip ita ted the next two problems.Change from MOD 40 o MOD 80. During the sum me r of 1966, just before publi-cation of the GSOP tha t would specify the software to be us ed in the first mission con-taining a CSM/LM-docked SPS engine burn (ref. 3), the guidance and control contractordecided that additional conservatism regarding the high-frequency stability margin wasrequired. (The est imates of the first bending-mode frequency existing at that tim e w a s

nearly 1 octave below the nominal first-mode frequency used in the initial DAP filtersynthesis. ) The design change that w a s implemented at that point is a good example ofthe flexibility available t o the digital- control- system designer; thi s flexibility wouldnot be available if the control-system design were being translated into hardware.

The change represented a radical departure f ro m the for mer concept of a single-stage compensation fil te r with fixed dynamics and time-varying gain. The originaldesign had the filter coefficients selected fo r a sample interval of once each 40 milli-seconds (MOD 40). The new concept was, after sta rting the burn with the originallydesigned filter, to switch gains and sampling interval af ter a partial nulling of the starttransients. A thrust-misalinement-correcting inner loop was also added.The postswitch fi lte r dynamics, because of a sampling inte rval of 80 milliseconds(MOD 80), we re essentially the same as those of the MOD 40 , except that the real f re-quency where a given shaping effect would occur w as now 1 octave lower. This charac-

ter ist ic of a digital fi lt er -can be explained by reference to the relationship between realfrequency w and the fictitious w-plane frequency v. In refe rence 6, thi s relationship

138


19/47

is shown to be v = tan (wT/2) where T is the samp le period in seconds. A specificvalue of v, say vo, is uniquely related to the real frequency only through the samplinginterval. Hence

vo = tan WoTo = tan [:( 2 ) ( C T O jimpli es that the specific rea l frequency where a given amount of attenuation and phaseshi ft would occu r is shifted by the invers e of any sca le facto r C applied to the Sam-pling interval. This shift is an important flexibility that is available in a digital filterbut is not available in filters implemented by hardw are components. Hardware filtershave an inherent sense of real tim e based upon the physical and geometrical as pec tsof the hardware, whereas a digital filter is a mathematic entity and, t herefore, isinsensitive to rea l time. For this reason, extremely low frequency filtering can bedone digitally in situations where the s am e job would be impossible to pe rfo rm withhardware.

Mathematical proof that real-frequency scali ng and sample-pe riod scali ng arerelated is beyond the scope of t hi s repor t. However, a convincing argument is avail-able. Because the digital filter is synthesized in the w-plane (poles and ze ro s arr ang edto supply a specific filtering action for a spec ific value of w-plane frequency v ) andbecause the bilinear transformation into the z-plane is not a function of sampl ing in te r-val, then a given set of digital filter coefficients will provide the s am e filtering fo r agiven v regard les s of the sampling interval involved.

0

0This particula r change is listed as one of t he TVC DAP developmental pr oble msbecause the passband of the MOD 40 design (approximately 0.6 rad/sec) was already

low, and t h i s change brought the passband down to approximately 0. 3 rad/sec. Theresulting performance was significantly degraded, and a cons iderable amount of effortwas required i n tuning up the guidance and control interface and in trying to contain theattitude er r o r s within reasonable bounds. The resu lt was a n NASA direct ive to the con-tr ac to r to produce an uprated TVC design based on the assumption that the c urr ent esti-mat es of bending frequencies we re a ccu rat e within + 3 0 percent. The low-gain DAP wa sflown on the Apollo 9 mission, but the uprated design was used on all subsequentmissions.

Guidance and control interaction. - The low-gain attitude-control loop first im-plemented fo r the CSM TVC DAP would pe rm it large -pe ak-att itude- error transi ent sand steady-state offset attitudes, resulting fr o m initial-thrust-torque bias. The designchange implemented to attack this problem, still with the assumption that the low gainwas necessary f or conservatism on the high-frequency stability margin, was to add aninner loop that would extract the ave rag e commanded engine position and r etu rn t hisinformation to the engine position command as a bias. The digital filter used for thispurpo se had lar ge tim e constants to avoid interaction with the attitude short-periodmode, resulting in additional pha se lags at freque nci es that now coupled with guidance(outer-loop) performance. Also, the long tim e period re qui red to initialize properlythe thrust-position filter (i. e. , to find the t r i m position) reduced the effectiveness of

14


20/47

this approach fo r limiting the initial attitude excursions. Therefore, la rg e guidancee r r o r s that could not be completely removed in short burns could still accumulateduring the first few seconds of a burn.The thrust-misalinement correction loop was not completely ineffective . Themain purpose of the correc tion loop was to remove la rg e steady-state attitude er r o r s

required to provide acceleration trim so t h a t an attitude e r r o r could be used by a crewman to determine if the maneuver w ere progre ssing normally.Mechanization of the guidance and control inte rface can produce, o r aggravate,guidance and control interact ion problems . The evolution of the inter face used in theApollo guidance and control system is shown in figures 3 to 5. The guidance law pro-duces a desir ed acceleration-vector rat e command that is proportional to the sensedacceleration-direction er ro r. The steady-state acceleration direction is very nearlythe attitude of the vehicle longitudinal axis, but this case is not t rue when control

torques a r e being commanded. Therefore, a requirement exists to provide stable-attitude inner-loop control by using attitude-position feedback.

! Gimbalp t; 2w w- 2-l IT = 0.08- e r ro rttitudesec !setActualL imbal' T = 0.08I secI

ITran;brnp;;;,nfor platform coordinates to requiredSteering4- D AP

Transformation of gimbal errors to body coordinates

Gimbalcommand

. 0.08 I e r ro r! sec T =0.08 /I L ctualgimbalSteering D AP- IPlatform t o gimbal

Gimbal to body

Figure 3. - Original guidance and control Figure 4. - Alternate guidance and controlinterface. interface (ramp steering).The first interface mechanization performed a simple digital integra tion of theguidance-rate command (fig. 3) to for m a vehicle-attitude command. Thi s integrationcaused step changes i n the attitude command during each guidance- computation period

(2.0 seconds), and these changes caused significant interaction with propellant-sloshdynamics.The next approach was to smooth the attitude commands by performing the inte-

gration at the DAP sampl e rate (fig. 4) . This change was effective in reducing the sloshexcitation, but so me concern ar os e about the fact that gimbal-angle e r r o r s were beingsubjected to a coordinate transformation. This trans formation of incrementa l attitudee r r o r s ca st som e doubt on large-signal stability. Subsequently, the coordinate-tra nsf orm ati on problem was solved, a s shown in figur e 5, by transforming guidance-ratecommand to body coordinates whe re the command is compared with a derived body ratebefor e the integration to produce body-attitude er ro r.

1 5


21/47

II Body- ra teI o m m a n dI T = 0.08

I II ,-1 A c t u a lyCH+ gim balIIIIISteering+A PIFllatform to bodyUI M ~~ I Gimbal to body

Figure 5. - Final guidance and con trolinterface (rate steering).

Initialization. - No specific aspect ofthe CSM DAP initialization caused any hard -ships that would be cl ass ed as a problem, butenough minor changes were implemented inthis area that the subject is worthy of men-tion. In the software system, just as in thecase of hardware sys tems, the engineeringattention required of the interface betweentwo components may somet imes exceed theattention required f or the selection or de-sign of the components. The refore , muchof the software asso ciate d with the digitalautopilots per for med the following functions.

1. Permi tted c rew s election of oper-ating mode2. Permitted crew selection of

reaction-jet quads (e. g., jet quads to us efo r roll control)3. Permi tted crew selection ofmaneuvering rate

4. Per mit ted cre w selection of attitude dead bands5. Perm itted crew monitoring of m a s s and engine-trim initialization6. Per mit ted cre w change of ma ss and engine-trim initialization i f not satisfiedwith quantities in the computer7. Computed control effectiveness based upon sto re d functions of vehicle m a s sproperties, mass-properties initialization data, and the available information on whichreaction-jet motor s can be used8. Per mit ted integration of the DAP into a complete maneuver progra m9 . Provided computer restart protectionItems 1 to 6 correspond closely with the prope r configuration of s eve ral switcheson a control panel in the cockpit of a conventional aircraft, with the following exception.The flight control s yst ems of aircraft (and previous space craft ) seldom underwent thecomplete metamorphosis re qui red of the Apollo CSM DAP f o r (1)coasting-flight control

of the Saturn IVB using Saturn IVB thr ust ers , (2 ) coasting-fligh t cont rol of the CSM,(3) powered-flight control of the CSM, (4) coasting-fl igh t con trol of the CSM/LM,(5) powered-flight cont rol of the CSM/LM, and (6) en try of the CM. Th is pro blem wa ssolved through t h e us e of a special software routine designated R03. Verb 48 wouldcall thi s routine, which would succes sively cy cle through nouns 46, 47, and 48, eachdisplaying either coded octal numbers that represented switch settings o r decimal num-b er s that represented CSM mass, LM mas s, o r SPS-engine-gimbal pitch- and yaw- trim

16


22/47

settings. A s the se n umbers w er e displayed, they could be changed simply by punchingnew nu mbers into the keyboard before proceeding to t he next noun.Knowledge of the vehicle ma s s (item 7) was necess ar y because the vehicle masswas used to compute vehicle ine rti a and cont rol effectiveness. The Apollo digital auto-

pilot s successfu lly used knowledge of the expected vehic le response to a control actionto provide valuable lead information.Item 8 on the list of periphe ral software entails an external prog ram automatical-ly configuring the DAP to se lect the pro per operating mode and to provide the neces sar yinitialization data and the cor re ct sequence of commands. Fo r example, the S P Sthrusting p rogra m (P40) tas ks that affected D A P operations included (1)performance ofSP S engine gimbaling check, (2 ) selection of coasting-flight autopilot with narrow-dead-band attitude hold as engine ignition t ime approaches, (3) initiation of ullage, (4 ) com-mand of S P S thrust-ony (5) termination of ullage, (6 ) switch fr om reaction-jet controlto TVC, (7) terminat ion of thrust , and (8) reconfiguration of DAP from TVC to wide-dead-band reaction-jet control.One design change in the initialization pr oce ss that wa s made lat e in the pr ogr amshould be discussed. Originally, the TVC D A P would initialize with zero-attitudeer ro rs , regar dless of the tru e atti tude at the time. In simulations, the disturbancetorque during ullage was observed always to cause the attitude e r r o r at thrust-on to beon the or de r of 1.0" . The DAP initializa tion would wash out thi s information, and the

initial thrusting directions would be in e rr or .The guidance loop would eventually compensate if given sufficient time, but veloc-ity e r r o r s would result for short-duration burns. The faster acting attitude-controlloop would prevent these velocity e r r o r s i f the TVC D A P wer e t o be initialized with themore cor rec t atti tude reference. A change was made to initia lize t he TVC DAP withthe non-zero-attitude er ro rs , i f the configuration were CSM alone, at the expense ofaccepting an initi al engine-gimbaling and attitude transien t. The engine-gimbaling

transi ent wa s too se ve re fo r the la rg er iner ti a configuration of the CSM/LM without atechnique for ramping the er r o r in slowly. Therefore, rather than risk an unnecessarysoftware impact, the modification was made applicable to the one configuration only.Roll divergence. - During independent design-veri fication tes ting of off-nominalconditions, the roll attitude was discovered to diverge in the pres enc e of a failed-on

roll thru ster during an S P S velocity-change maneuver. This problem was caused bya combination of two separate design features. First , the time at which a new roll-cont rol pulse could follow a roll of the same polarity was intentionally constrained tobe gr ea te r than one control sample period (0. 5 second). This constra int avoided theus e of a high-frequency pulse tr ai n of smal l pulses to hold attitude agains t a disturb-anc e torque. The constraint worked quite we l l fo r sm al le r disturbances; but, in thepr es en ce of the la rg e angular-acceleration disturbance that existed with a constant100-pound th ru st acting through a 7-fOOt lever arm and acting on the small roll inertia(as small as 15 000 slug-ft ), the attitude-error limit in the control law was too smal lto prevent divergence.

2

The mechanic s of thi s phenomenon were as follows. Restoring torque th ru st er swould fire until the divergence rate was nulled, in addition to an incremental amount of

17


23/47

thrus t ontime proportional to attitude e r r o r . During the force d delay, at which time thecont rol torque could not be reapplied, the disturbance torque would add angular mo-mentum in the direction of divergence . If the restoring-control momentum impulsecould have possibly continued to grow with the increasing attitude error, a steady-statelimit-cycle condition would have been reached. Instead, the original design had a l imitpoint beyond which the increasin g attitude e r r o r no longer affected the ter minal re st or -ing momentum. Therefore, with a disturbance torque of sufficient magnitude to nullthe terminal rest oring momentum (i .e. , to r eve rt t o zero-attitude rate) in less thanhalf the jets-off delay, the attitude would diverge. Thi s problem was solved by addinghyste resi s to the phase-plane logic, so that resto ring momentum would continue togrow with increasing attitude er r o r , but the desir able featu re of partiall y nulling la rg econvergence rates w a s retained.

Command-service module RCS DAP rate-estimator gains. - Jus t before the launchof the Apollo 7 mission, the CSM deorbit burn was discovered to be incurri ng a velocitye r r o r as a res ult of a n initial thrusting e r r o r caused by the TVC DAP attitude er r o rinitialization process. (The DAP ignored attitude e r r o r existing at SPS thrus t initia-tion. ) The four-jet ullage burn that preceded the SPS engine ignition i n these simula-tions produced approximate ly 200 ft-lb of disturbance torque about the negative pitchaxis of the CSM vehicle at a tim e when the pitch inert ia was lowest (SPS propellantsne ar depletion). The resulting disturbance acceleration would produce sufficient bia sin the DAP estimated rate (with rate information being derived in a digital filter fromnoisy angular measurements ) to degrade significantly the attitude-hold capability. Theattitude dead band w a s 0 . 5 " , but the attitude e rr o r s at ignition wer e on the or de r of1 . 2 " .because slightly higher disturbance torqu es would have caus ed attitude divergence.Thi s problem w a s solved by using a two-jet ullage f or the Apollo 7 deorbit ullagemaneuver and by r aisi ng the gains in the rate-est imation filter to reduce the rate biasresulting from a given accelera tion disturbance.

-

An investigation showed that an insufficient marg in at this flight condition existed

Command-service module DAP/hand-controller inte rface. - Another significantdesign change that was implemented in the CSM coasting-flight autopilot involved theswitching logic used in response to rotational hand cont rol ler (RHC) motions. The onlyinformation available to the CMC regard ing hand-controlle r st at us is 6 bit s of an inputchannel such that proportional rate control (vehicle-ra te command proportional toamount of hand-controlle r deflection) was not possible.

The original design simply fire d jets to null a rate error, defined by the differ-ence between the estimated vehicle rate and a preselected maneuver rate, until therate er ro r was less than a small value. This small value was computed as a functionof vehicle iner tia, but the value corresponded close ly with the vehicle rate -change thatwould be expected for a minimum impuls e of contr ol torque.The disadvantages of this design we re twofold. First, f o r control about a lightinert ia axis, where the minimum impulse rate could be nearl y as large as the lowestdes ire d maneuver rate (0.05 deg/sec), per for man ce wa s unacceptable; second, unnec-es sa ry time delays and design complexity we re involved in using a different switching

logic when the hand contr oller was out of detent. The solution was to form the ratee r r o r as before, integ rate the rate er ro rs to for m an a tt itude er r or , and then use theattitude and rat e e r r or s in the s ame phase-plane switching logic that was used forattitude-hold and automatic maneuve rs.

18


24/47

Entry. - The CM DAP used during the final phase of the Apollo miss ions wa s rel-atively uncomplicated and trouble-free. The CM was aerodynamically stable in pitchand yaw deviations from the stability axes, and because the guidance sch eme did notreq uir e altera tion of the t r i m angle of atta ck, only the rate damping needed to be pro-vided about thes e axes. The guidance scheme commanded rotations about the velocityvector, and because of the low guidance gains, guidance-commanded maneuvers wer einfrequent.wer e not critical.This lack of maneuvers im plie s that the rol l attitude-control requi rements

This sta tement does not imply that the entry DAP design was trivial. The designdid have seve ral modes and interfaced with several external programs . This particulaDAP, like 'most of the other s, was developed independently by separate de signe rs. Assuch, the ent ry DAP provides another independent data point on a special-purpose dig-ital control sys tem that was us ed on the Apollo Pr og ra m and that did the job well.One asp ec t of t he entry DAP development emph asi zes the need fo r cl ose scrut inyof sim ula tor models. The amount of reaction-control propellant consumed during entryof the Apollo 7 CM wa s observed to be approximately 50 percent higher than predicted.This overconsumption was later shown to be the re su lt of an insufficient atmosphe ricmodel in the simu lato r environment. Inclusion of a real isti c wind profile in the simu-lat or produced re sul ts that m ore closely matched the flight data.

L UNAR MODULE D IG TAL AUTOP I LO T DEVELOPMENTThe LM DAP provides stabiliza tion and control of t he LM during both coastingand powered flight in t hre e configurations- escent, ascent , and docked with the CSM.During the prelim inar y spacecraft-design phase, many fundamental decisions wer e

made that impacted the control-system design. F o r the LM, th ree basi c propulsion-for ce and torque syste ms were established- CS, descent propulsion syst em (DPS),and asce nt propulsion system (APS). Char acte rist ics that influenced the control taskincluded the type of actuation system, the geometrical location and number of thr us te rso r jets , and the type of thrust- vari ation system.During DPS-powered flight, the LM DAP design provides yaw con tro l with theRCS je ts and pitch/roll attitude control with a combination of the RCS and the gimbal -t r i m syst em (GTS). The geometric al location of the RCS jets is significant in establish-ing the fundamental des ign approach.During APS-powered flight, the prim ary purpose of the RCS is to provide attitude

stabiliza tion and control. However, whenever feasible, a design requirement exists tofire only the upward-thrusting RCS jets so that velocity changes fro m the main engineare augmented. Because the APS is a nongimbaled, fixed-throttle syst em, the RCScontrol law s associated with this mode must accommodate lar ge time-variant disturb-ance torques.The RCS provides automatic or manual rotation and sm all transla tion control forall LM configu rations during coasting flight. For coasting flight, the design problem ischa rac ter ize d by the presence of low-disturbance to rques (except for a n RCS jet-on fail-ure). The LM DAP was also req uired to control the entir e Apollo spacec raft with theLM docked to the CSM, whi le performing a velocity-change maneuver using the LM DPS.

19


25/47

V e h i c l e D e s i g n C o n s t r a i n t sNumerous const rain ts influenced the LM DAP design, the most predominantclass of which re lat ed to weight rest ric tions associat ed with the lunar landing program.Weight considerations constrained the syst em design through (1) structural characteri s-

t ics of the LM/CSM - ha t is , structural-bending modes are significant; (2) propellant-sloshing dynamics- ha t is , slosh baffles were removed early in the program; and(3) unbalanced couple control- ha t is , requirements w ere established for APS-powered f l ight .

Another cla ss of const rain ts, generally identified late in the design-developmentphase, involved res tri cti ons on RCS-jet firing. These res tri cti ons included (1)duty-cycle constraints- ropulsion instabilities; (2 ) exhaust-contamination constraints-pa rt ic le s on windows or optics; and (3) thermal constraints- CS-exhaust-plumeimpingement heating.A third clas s of const raint s that influenced the design problem was asso ciat edwith propulsion-system cha rac ter ist ics . The slow- speed cha racte ris tic of the DPS

trim-gimbal actuator was establis hed fo r crew safety to avoid hardover actuator fail-ur e s during powered descent of the LM. A special g ea r dri ve was developed to restrictthe trim-gimbal-drive ra te of +O. 2 deg/sec. Unlike the classical actuator used for theCSM TVC system, the DPS actuator cannot fail at a higher driv e rate. A secondpropulsion- system constraint w as a ssoc iated with the decision to have a nongimbaledAPS engine. This decision imposed significant limit s on the allowable cen ter- of-masscha rac ter ist ics during powered ascent flight. Unfortunately, effective control of thema s s center of gravity is difficult in a program such as Apollo. Another propul sion-sys tem constraint was associated with the decision to locate the RCS je ts 4 5" from thebody axes. This geometry significantly influenced the int erac tion between the RCS mode(control axes ) and the GTS mode (body axes) during DPS-powered flight.

The fourth cl as s of const rain ts that impacted the design problem includedcomputer-oriented res tri cti ons . The LM guidance comput er (LGC) is limit ed in bothfixed and erasable mem ories ; in addition, definite timing res tri cti ons are placed uponthe progr ams required to provide the control functions.

D e s i g n PhilosophyAn important question with r esp ect to des ign philosophy was how to u se the inhe r-ent flexibility associated with a space craf t digital computer. Thi s question was signifi-cant because the LM DAP represented a first-generation DAP design development.

Emphasis was placed upon using digital capabilities such as logic (switching and branch-ing), nonlinear computations, and function generation .The concept of performance margin wa s an area of design philosophy that influ-enced DAP development. This concept emphasized the princ iple t hat the acceptabili tyof the design should be based upon per forman ce of the sys tem during ex tre me, but re-quired, degraded conditions. Acceptable perf ormance during off-nominal conditions,such as single undetected jet failu res and la rg e control-effectiveness uncertainties(thrust magnitude, ine rtia prope rtie s, thr ust misalinement, actu ator drive rates, etc. ),w a s difficult to achieve. The perf ormanc e-mar gin concept identified a general trade-off

20I


26/47


27/47

Aa

Aulopilot

calculator computations

Guidancenaviqalion1 qudtions I

SteeringT I -quationsAttitude anglesslee r ing-Coupling dalunit (CDUIangles

-

Descenl-- aws assembly SpacecraftrotationsA h ando a translation

I iestimator-I State I! CDU angles

Key:a = angular accelerationA = estimated valueai = angular velocity

Figure 6. - Powered-flight automatic control.( S l o w l y varying or constant estimator parameters)

7

Assumed RCS control effectivenessAssumed GT S control effectiveness

ked ILM-alo ne bitI-to-body increment matrixalone filter parameters

CSM-docked filter parameters

Angu ar-velocityState estimateestimatorangles (Direct

IMU gimbalmeasurement Bias-angular-of vehicle accelera tion estimateattitude)

I Trim'-gimbal activitySigned firi ng durations.number of jets selected

\ 2(Autopilot internal feedback of controlsignals from the RCS and GT S control laws1

Figure 7. - Input and output variables ofthe state estimator.

The RCS control la ws compute the re-quire ments for rotational impulses by usinginformation based upon attitude phase-planeer ro rs , control effectiveness, and phase-plane targeting logic. The se control l aw sare predictive in natur e and are related tothe c las sic al two-point boundary value prob-lem. To som e extent, th is predictive designis inherently sensitive to the uncertaintiesin control effectiveness and unmodeled dis-turbanc es. Angular-e r or / e r r o r -rate phaseplanes a r e used to establish jet-firing dura-tions in each control axis. The attitude andrate er ro rs a r e used to es tablish the est i-mated sta te location in the phase plane. Theacceleration inputs required by the RCS con-trol laws include net angular acceleration(jet acceleration plus offset acceleration)and coasting acceleration (accelerationcaused by offset alone). The bas ic shape ofthe target parabolas and switching-line

22


28/47

parabolas are set by thi s angular-acceleration information. Additional logic est ab -lishe s the intersecti on of th ese parabolas with E = 0, based upon crew-selected deadband and the magnitude of the dis turbance accelera tion.The phase-plane configuration fo r the DPS-powered-flight mode is given in fig-u r e 8. The control logic is developed by (1)dividing the phase plane into coasting and

firing zones, and (2) computing jet-firing durations fo r each zone to accomplish a de-si re d control action (i. e., null rates, drive-to-ta rget parabolas, and command mini-mum impulse).The jet-selection logic combines the required rotational impulses with the com-manded translation inputs and selec ts appropriate jet s for control action. Additionalinformation used by the jet-selection logic includes the des ire d number of jets to befi red and the identification of disabled jets . A normal jet-selection policy in the thr eetranslational and three rotational axes applies f o r nominal conditions. When a requiredjet has been disabled, an alternat e jet-selection policy is used. However, if multipleje t failures for a given control axis have occurred, a computer-program alarm islighted and an ala rm code informs the astronauts that a rotational translation failureexists.

Target parabola

Zone 5

Target parabola

Zone 1

Figure 8. - The phase plane when the LM is in powered ascent or wheneither of the trim-gimbal-nulling drive ti me s is grea ter than 2 sec-onds during powered descent.

E-t

23


29/47

Two slow-speed actuat ors a r e used to gimbal the descent engine. The controlmodes developed fo r commanding these tr im a ctuat ors are an attitude-control modeand an acceleration-nulling mode.The GTS cont rol law associated with the attitude-control mode has been developedto be a function of e r r o r s in attitude, rat e, and acceleration. The control-law equationsa r e basically a modification of a time-optimal solution. The control output commands

the sign of the change in angular acceler ation .The GTS control l aw associated with the acceleration-nulling mode is designed toregulate the offset (disturbance) acceleration fro m the descent thrust. The pr im ar ydynamic environment that causes the disturbance acceleration to change is a shiftingcenter of mass as a resu lt of propellan t depletion, DPS-engine-mount compliance, andDPS-engine ablation effects. Th is cont rol law is struc tured in the for m of a t r im-gimbal drive -time equation.

Design EvolutionThe history of the LM DAP development will be presented by discus sing thedesign-formulation phase (September 1964 to December 1966), and the SUNBURSTflight pro gra m phase (December 1966 to August 1967). Where applicable, com par isonswi l l be made to t h e SUNDANCE base line design previously d iscus sed. The significantproblems encountered will al so be discussed.Apollo 5, the first (unmanned) LM mission, w a s launched into e ar th orb it Janu-ary 22, 1968, and used the SUNBURST flight prog ram. After t his miss ion, a decisionw a s made to simplify the DAP logic, and a significant redesign of the control s yst emw a s begun, resulting in the SUNDANCE digital prog ram. This design ver sio n w a sflight-tested on the first manned LM mission (Apollo 9), launched March 3, 1969. Sub-

sequent lunar orbit al and lunar landing mi ss ions (Apollo 10 and 11)we re flown withslightly modified SUNDANCE digital autopilots in the LUMINARY flight program series.SUNBURST DAP. - Many modifications in design philosophy and in contro l-sys temimplementation occur red dur ing the design-formula tion phase of the LM DAP develop-ment. This ear ly development culminated in the design that wa s incor porat ed into thefirst LM digital flight pr og ra m (SUNBURST). Much of the mate rial pr esented is givena mor e detailed treatment in reference 4, which provides descriptions of the designsthat evolved to solve the developmental problems.Mos t of the significant problem s assoc iated with the preli min ary design wereidentified as a res ult of extensive simulation testing. The pro blem of estimat ing ra te

and acceleration when undetected je t fai lur es existed during powered descent proveddifficult. Consideration wa s given to the u se of Kalman fil te rs to estimate (from space-cr af t dynamics) which of t he 16 jets had fail ed and to adjust the control functions ac-cordingly. A second approach (subsequently implemented) was to us e the Kalman fi lt erequations only when the GTS control law was operative o r when the RCS jets we re inhib-ited. However, disabling control during powered flight f o r the tim e needed to obtain agood filter estima tion w a s considered unacceptable, and thi s technique was discarded.

24


30/47

A second problem was that convergence to minimum-impulse attitude limit-cycleoperation was not achieved by using the initial design. Design-verification studies in-dicated that thi s problem wa s caused by rate-es timation inaccurac ies and quantizationeffects. The phase-plane logic was then modified to improve the per formancecharacteristics.Significant design problems wer e identified with re spect to the Kalman filt er pe r-formance. In simulation testing, thi s estimator wa s shown to be sensiti ve to slosh dis-turbances and la rg e initial conditions. Furthe rmore, during the DPS start transient,the filter perform ance exhibited poor convergence because of engine-mount compliance,propellant shift, and initial engine mi st ri m conditions.Rate-overshoot performance wa s indicated to be a problem during coasting-flightmaneuvers. The command-maneuver logic did not account for the finite time requiredto accelera te o r decelerate to the desir ed maneuver r ate, and additional jet firing s re-sulted. To solve this problem, lag angles were provided to prevent overshoot wheninitiating o r terminating an automatic maneuver.The original LM DAP design attempted to incorporate information fr om theguidance-commanded DPS thrust into the logic for switching control from the GTS toreaction-jet control. This incorporation was thought to be necessar y because the dis-turbance acceleration would be changed, with a change in thrott le setting, because ofthe change in thrus t-force magnitude as well as a thrust-vector rotation resulting fr omengine-mount compliance. Therefore , a logic was configured whereby a sensed throttlechange of m ore than 5 percen t of full th rust would fo rc e mandatory use of re act ion-je tcontrol until thrott le activity subsided. Simulation test ing showed that er ro rs in com-puter knowledge of actual vehicle ma ss could prevent re turn to trim-gimbal control.This design discrepancy was resolved for the later flight programs by relinquishing theobjective of providing the estimation fil te r and control-mode logic with lead information

fr om the throttle commands.The perfor mance of the LM control system during the DPS-start-transient periodwa s of suff icient concern to req ui re design modifications of the SUNBURST flight pro-gr am before the Apollo 5 mission. The major problem was caused by er r o r s introducedin the open-loop drive-time equation and by the subsequent poor convergence from RCScontro l to GTS control. The ef fect of a drive-time error is to maintain a residual off-set disturbance ,torque while the sys tem is i n the RCS mode. If this offset is large, the

RCS jets converge the attitude and rate er ro rs slowly to the region in which re tur n tothe GTS control is made. During th is period, the jets must fire to combat the sustainedoffs et disturbance, and unnecessary reaction- je t propellant is consumed.Fa ct or s that significantly contribute to the e r r o r in open-loop d rive ti me are asfollows.1. Propel lant shift during ullage and the low-throttling t ime period2. Actuator and engine-mount compliance3. Uncertainties in the assumed values of mass-property variables

258\


31/47


32/47


33/47

t ime lags we re caused by a 2-second delay inherent in the ramp-steering design conceptand a computational time delay. Design modifications that we re incorporated into thelun ar landing mission prog rams included the implementation of lead compensation intothe guidance loop and a de crea se of the attitude dead band at sma ll values of t ime to go.

A computational scaling design problem occurred for the LM/CSM GTS con tro lsyste m. This gimbal control sys tem would not tr im at low thrus t leve ls because of anunderflow caused by a coding implementation. Test ing indicated tha t the powered-flightstart-transient performance was extremely sensitive to initial engine mistr ims . A re -sc al e of the coding for t h e GTS control law to eliminate the underflow c ha ra ct er is tic sresulted in an acceptable design.

The final design problem to be discu ssed w as in the ar e a of sloshing stability dur-ing DPS-powered flight. Both simulation and flight te st data res ult s have indicated thatthe LM/CSM and the LM configurations were sensi tive to sloshing dynamics duringpowered f l i g h t . Detailed analyses have demonstrated that the GTS control law alone isunstable in slosh fo r cer tain conditions. However, in thi s situation, the total controlsy st em maintains s tability because of the slosh-damping provided by the RCS controlsystem. The perfo rmanc e penalty is prima rily that of unnecessary jet firings. Fac -t o r s that influence the GTS control s yst em slo sh stability a r e (1) arge t im e lags in thera te est imato r because of the nonlinear thres hold logic, (2) the acceleration estimateterm in the GTS control l aw that is fil ter ed and does not provide effective control, and(3) large sampling lags that occur at the slosh frequencies with the GTS control lawcomputed only five ti mes pe r second.

FLIG HT TEST RESULTSThe CSM and LM flight results discussed w i l l include performan ce data from themanned and unmanned missio ns, and re su lt s to sa tisfy detailed tes t objectives (DTO's)established preflight.Typical flight data results are prese nted to indicate performance trends. The

ability to match t h e preflight-simulation-test res ult s closely with the actual flight datais dependent upon the quality of the te le me te re d data and upon the accu ra cy of t hespacecraft environment that was modeled in the simulator. In general, powered-flightmaneuvers and coasting-flight attitude mane uve rs can be closely duplicated, butattitude-hold limit-cycle behavior is mo re difficult to match i n the postflight analyticprocess.

Detailed tes t objectives were estab lished f o r the LM and CSM digital autopilots;in general, these DTO's were scheduled during the ear ly mi ssion s in an attempt toverify basic performance capabilities formally. Tab les I1 and III su mm ar iz e the DTO'S,descriptions, and results. Rather than being seg reg ate d on a mission basis, the DTO'Sare grouped into CSM and LM tests.

28


34/47

TABLE 11. - SUMMARY OF CSM DAP DETAILED TEST OBJECTIVESTitle

Guidance, navigation,and control system(GNCS) attitudecontrol

GNCS AV control

GNCS entry

Propellant sloshdamping

GNCS entry lunarreturn

TVC DAP stabilitymargin

DescriptionSet of 1 5 RCS DAP functionaltests: attitude hold (2 deadbands), automatic maneuvers(4 rates), manual maneuvers(4 rates), minimum-impulsecontroller inputs, RCS trans-lations (3 axes), and RHC in-puts in free mode

Evaluation of SPS burns for long-and short-burn velocityerrors, engine mistrims,sta rt transients, center ofgravity, tracking, and sloshdampingEvaluation of GNCS guidance forentry from earth orbit

Obtaining data on propellantslosh damping after SPS andRCS burns for RCS fuelbudgetingPerformance of GNCS entryfrom a lunar return and evalu-ation of the entry monitor sub-system (EMS) monitoring

capabilityStroking te st

RemarksOne 3.6" automatic t ri m maneuvew a s recordedOne maximum-dead-band attitudehold w a s performed for lessthan 5 minutesThe stabilization and control sys-tem (SCS) control w a s used inall other RCS activity exceptfour ullagesOne long SPS burn and five shortburns were performed and allobjectives were met

Accurate guidance was achieved,and control was as expectedexcept in the transonic regionNo unusual slosh amplitudes werenoted

Excellent agreement between G&Iand EMS data was indicatedNominal G&N performance was

achievedSuccessfully accomplished

29


35/47

TABLE IJI.- SUMMARY OF LM DAP DETAILED TEST OBJECTIVES

TitleGNCS attitude stabilizationand control during coastperiods

LM GNCS/DAP perform-ance and thrustperformance

GNCS attitude/translationcontrol

GNCS-controlled APSburn

GNCS undocked DPSperformance

30I

c

DescriptionDemonstration of RCS attitudestabilization using the GNCSfor attitude referenceVerification of simple attitude andtranslation commands and atti-tude hold at minimum and maxi-mum dead bandsPerformance of a medium-durationDPS firing to include manual

throttling with CSM and LMdocked and short-duration DPSburn with undocked LMDemonstration of RCS translationand attitude control of the stagedLM using automatic and manualGNCS control

Performance of a GNCS/DAP-controlled long-duration APSburnFlight test objective 1 -

Evaluation of the capability ofGNCS to execute DPS high-thrust undocked maneuver

Objective verifiedCoasting-attitude hold(maximum dead band)Attitude maneuversTranslat ion commands

Docked DPS burnShort DPS insertion burn

Automatic -attitudemaneuverAttitude hold of stagedLM (maximum andminimum dead bands)Manual rotational andtranslational com-

mands (staged LM)Automatic translationAPS burn to depletion

DPS phasing burnDO1 burn

Flight test objective 2 -hraluation of the capability ofGNCS to execute the descentorbit insertion (DOI)maneuver


36/47

Command-service module TVC DAP performance data. - Apollo 7 w a s the firstmanned Apollo flight to use a DAP. This flight consisted of t he Apollo CSM only. (Adifferent digital filter is requ ired when the LM is attached. ) The flight contained eightmain engine burns. Five bu rns oc cu rr ed under TVC DAP control for the ent ire burn,and a sixth occ urr ed that was initiated by the prim ary control system, with a switch toa backup manual control mode after 35.8 seconds. Two bu rn s we re minimum-impulseburns, and th re e bur ns ranged between 7.8 and 10.9 seconds in duration. Thr ust mis-t r im at the beginning of t hese bu rns wa s le s s than 0.2" in all cas es, and peak attitudee rr o rs (except roll) were all less than 0.5" during DAP control.

Peakpitch o ryaw error,

TotalAV,ft/sec deg24.8 0.4944

3000.0 .4504134.8 .16343520.0 .3955

Tab les IV to VI a r e presented to summarize the significant flight test resul ts forthe TVC DAP fr om the Apollo 8 o 10 missions, respectively. Data fr om the Apollo 7and 11 missions a r e omitted because thes e flights we re si mil ar to the Apollo 8 and 10missions, respectively .

AV resid uals before nulling,ft/sec'

x 2 z4.4 -0.1 0.1-1.4 0 .2(4 (4 (4-.5 . 4 -. 1

The Apollo 8 unar flight used essentially the s am e control s ys te ms that wereused by the Apol lo 7 mission with equally good resu lts. The Apollo 8 mission providedadditional flight experience, especially in the ar ea of long-duration burns. Control-sy st em dynamics interaction with guidance performance w as insignificant for the CSM-only configuration. However, th is interaction was not insignificant for the CSM/LMconfiguration, as use d o

Apollo Experience Report Guidance and Control Systems Digital Autopilot Design Development

Documents

Transcript of Apollo Experience Report Guidance and Control Systems Digital Autopilot Design Development