I 

COMPUTER SIMULATION OF ON-ORBIT 

MANNED MANEUVERING UNIT OPERATIONS 

Gary M. Stuart and Kahy D. Garcia 

Martin Marietta Aerospace 

Denver, Colorado 

Simulation of spacecraft on-orbit operations is discussed in reference to Martin 

Marietta's Space Operations Simulation laboratory's use of computer software models to 

drive a six-degree-of-freedom moving base carriage and two target gimbal systems. In 

particular, key simulation issues and related computer software models associated with 

providing real-time, man-in-the-loop simulations of the Manned Maneuvering Unit 

(MMU) are addressed with special attention given to how effectively these models and motion 

systems simulate the MMU's actual on-orbit operations. 

THE WEIGHTLESS EFFECTS of the space environment require the development of entirely 

new devices for locomotion. Since the access to space is very limited, it is necessary to 

design, build, and test these new devices within the physical constraints of earth using 

simulators. The simulation method that is discussed in this paper is the technique of using 

computer software models to drive a Moving Base Carriage (MBC) that is capable of 

providing simultaneous six-degree-of-freedom motions. This method, utilized at Martin 

Marietta's Space Operations Simulation (SOS) laboratory, provides the ability to simulate 

the operation of manned spacecraft, provides the pilot with proper three-dimensional visual 

cues, and allows training of on-orbit operations. The most effective use of this capability 

has been in designing, testing, and operational training of the Manned Maneuvering Unit 

(MMU). 

To properly evaluate the operation of a spacecraft and provide the pilot with the 

necessary training to operate it with confidence, accurate modelling of both the functional 

operation of the spacecraft and the physical laws that govern its operation are necessary. 

Due to limitations in the ability to model all aspects of a spacecraft and the space 

environment, limitations in finances to program these models, and limitations in the amount 

of computer code that can be executed in a finite amount of time, it is not feasible to model 

each variable that might affect a spacecraft's operation. Therefore, modelling is limited to 

those variables that are likely to have a significant effect on the spacecraft's operation. Once 

the modelling is complete, it is necessary to evaluate the level of simulation system fidelity, 

as compared to actual on-orbit operations, and to determine where the simulation needs 

improvement. 

The purpose of this paper is to discuss significant MMU simulation issues, the related 

models that were developed in response to these issues and how effectively these models 

simulate the MMU's actual on-orbit operations. 

MANdEDMANE-wr 

The MMU was designed for untethered astronaut extra-vehicular activity (Figure 1). It 

is a self-contained vehicle, comprised of electrical power systems, propulsion components, 

controls, and displays necessary for on-orbit flight operations. The MMU utilizes 

pressurized gaseous nitrogen, expelled through 24 fixed thrusters, to achieve six-degree- 

(NASA-CR-179904) CONFUTER SIMULATION OF N87-12245 

CN-ORBIT PlAgNED MANEUVEBI NG Ukl'l CPERATIGNS 

(Partin Faristta Aerospace) 7 F CSCL 09B 

UACldS 

~3/61 w8ai 
.I 

of-freedom maneuverability. Attitude and directional motion commands are input through 

two hand controllers. The left hand controller is used for translational commands (X, Y, and 

Z) and the right hand controller is used for rotational commands (Roll, Pitch, and Yaw). 

The hand controllers generate electrical signals that are processed by two independant 

control electronics assemblies, which then send thruster firing commands to the 

appropriate thrusters. The unit is fully redundant such that no single credible failure can 

prevent a safe return. 

A button on the rotational hand controller allows initiation of Automatic Attitude Hold 

(AAH), which uses three rate integrating gyros to maintain the MMU inertial attitude in any 

combination of rotational axes. To provide mission flexibility, two standard control modes 

are available: Normal mode, which is used for all operations of the MMU alone; and Satellite 

Stabilization mode, which is used for operations when the MMU is attached to a satellite or 

other massive payload. Satellite Stabilization mode uses an alternate thruster select logic to 

compensate for the induced large moments of inertias and the center-of-mass offset, to 

provide increased rotational control authority, and to minimize plume impingement of the 

SMUTIONSYSTEM 

Payload. 

HARDWARE - The simulation system is driven by a Gould 32/9750 computer, that 

contains software models necessary to simulate spacecraft operations. The output of these 

software models provide input to a General Electric Series Six digital servo system. This 

system controls DC servo motors that provide motion to the simulation hardware. Sensors 

on this hardware return information to the servo system to verify their position and rate. 

The entire system is classed as a second-ordered, hybrid control system (see Figure 2). 

The primary piece of simulation hardware is the man-rated, six-degree-of-freedom 

MBC (Figure 3) that moves within a Cartesian coordinate system. This device provides 

translational motion and rotational motion, along and about the three axes simultaneously. 

In addition to the MBC, a Single-Axis Gimbal (SAG) and a Three-Axis Gimbal (TAG) (Figure 

4) are used. These gimbals allow the pilot to approach and attempt docks to rotating targets. 

The SAG provides one-degree-of-freedom motion in rotation for large full-scale target 

mockups, whereas the TAG provides three-degrees-of-freedom motion in rotation for small 

full-scale and partial-scale target mockups. Because the SAG and TAG are not capable of 

translational motions, these motions are compensated for by the MBC. 

For MMU simulations, an MMU mockup is attached to the gimbal head of the MBC 

(Figure 3). The only functional hardware present on this mockup are those interfaces 

necessary for the pilot to provide input to the system, such as handcontrollers and switches, 

or to receive system information, such as gauges and lights. 

SOFTWARE - Software models are responsible for all aspects of the simulation system. 

These models simulate MMU electronics, MMU propulsion systems and the physical laws of 

space that govern the MMU's operation, and control of the simulation system and data 

recording. The control of the simulation system and data recording will not be discussed in 

this paper. The simulation of the MMU electronics, propulsion systems, and physical laws 

of space that govern the MMU's operation were divided into the following four general 

software modules: 

MMU Electrical Control and Switchina (ECSI - Monitors all MMU switches, detects 

changes in switch settings, controls switch malfunctions as initiated by the simulation 

run coordinator, and passes this information to other modules. 

MMU Control Electronics Assemblv (CEA) - Accepts handcontroller inputs (X, Y, Z, 

Roll, Pitch, and Yaw), MMU configuration and control modes, modelled gyro rates, and 

MMU CEA malfunctions as initiated by the simulation run coordinator. The output from 

this module specifies which of the MMU's twenty-four thrusters should be fired. 

MMU Prooulsion - Models the propulsion system, thruster firing times, manifold 

and regulator pressures, propellant use as a function of thruster firing time, and MMU 
propulsion malfunctions as initiated by the simulation run coordinator. Output from 

this module specifies fuel consumption and which thrusters were actually fired. 

MMU Dvnamics - Models dynamic performance of flight hardware in zero-g 

environment. Includes associated center-of-mass offsets, forces, moments, orbital 

mechanics, flexible body dynamics, MMU plume impingement effects, vehicle/target 

relative motion, and two-body contact dynamics. Output from this module is returned to 

the CEA module to provide gyro rate information and to the digital servo system to 

provide position commands for the servo mechanisms. 

Modelling all aspects of the simulation through software allows for complete flexibiity 

to modify any part of the simulation system. This provides the ability to simulate the 

operation of the MMU either in orbit or free space, start the simulation with any set of 

initial conditions desired, select the appropriate models, and insert up to three simultaneous 

malfunctions from a list of over two hundred possible choices. 

SIMULATION ISSUES 

In order to develop a valid simulation, it is necessary to assess a wide variety of issues. 

The first step is to identify which issues will not produce a noticeable effect on the 

simulation. For example, the SOS lab does not simulate atmospheric effects, the effects of 

gravity between the earth and sun or between the earth and moon, the effects of the nonspherical shape of the earth, and the effects of non-circular orbits. The next step is to 

determine which issues, of those that do produce a noticeable effect on the simulation, can be 

simulated to a high degree of fidelity within the scope of the present simulation system. In 

the MMU simulation, these include the ECS, CEA, propulsion system, forces, moments, 

orbital mechanics, and vehiclekarget relative motion. Those issues that remain cannot be 

simulated to the degree of fidelity desired. This is due to either simulation system 

limitations or lack of sufficient knowledge of the issue. The remainder of this paper 

discusses some of these simulation issues and the on-orbit experiences related to them. 

CENTER-OF-MASS OFFSET - Center-of-mass offset refers to a condition where the 

center-of-mass and center-of-thrust are not co-located. This results in translational 

commands inducing rotational motions. 

Since the position of the MMU thrusters are fixed, center-of-thrust is simple to locate 

and remains unchanged. However, the center-of-mass is dependant on the relative positions 

of MMU system components; specifically, the MMU, target attachment devices, the pilot's 

spacesuit, and the pilot's body. The exact position of the center-of-mass changes, because 

the pilot tends to float inside the spacesuit and is likely to move his arms and legs. Since the 

center-of-mass offset is dynamic, it is not possible to accurately simulate its variable 

effect on the operation of the MMU. However, it is believed that small variances in centerof-mass off set should not cause significant differences between the simulation and flight 

hardware operation. Therefore, the anticipated position of the pilot during the majority of 

the flight is defined and used for all simulation operations. 

One instance where this inaccuracy was detectable occurred during mission 41 C when 

astronaut Jam Van Hoften flew the MMU with his legs forward instead of straight down, as 

had been assumed for simulation training. 

FLEXIBLE BODY DYNAMICS - Flexible Body Dynamics (FBD) is the process in which 

various parts of a body oscillate at different frequencies due to a "forcing function" 

vibration. On the MMU, the primary oscillating components are the main body, the two 

arms, and a docking device (when attached). The primary forcing function is driven by 

thruster firing activity. 

During STS mission 51 A astronaut Dale Gardner used the MMU with the Apogee Kick 

Motor Capture Device (ACD), known as the "stinger", attached to the MMU arms to 

rendezvous and dock with a satellite. During this mission he reported significant 

sluggishness in the lateral command response while operating with AAH active and in 

Satellite Stabilization control mode. He also perceived a higher level of thruster activity in 
AAH and a higher than expected propellant usage, than during the simulated training 

missions. 

Due to this on-orbit experience, a variety of simple MMU FBD models were designed 

and tested to study their effect on the AAH system, including one model that closely 

resembled the on-orbit configuration of Dale Gardner. The data produced by these series of 

analyses indicated that FBD of the entire MMU system negatively affects the AAH control 

system by causing a higher level of thruster activity. This in turn is likely to produce an 

increase in propellant consumption as compared to a totally rigid configuration. As a result, 

a simple FBD model has been added to the simulation. To reduce this effect with the flight 

hardware, it was recommended that the AAH switching lines on the flight hardware be 

widened or removed, and that the MMU not be flown in AAH in Satellite Stabilization mode 

while not attached to a satellite.. 

*John A. Cuseo, Charles A. Dallas, and David L. Van Duzen, MMU Control Svste m Analvsis 

With Flexible Bodv Modelling (Martin Marietta Aerospace, December 13, 1985), pp. 1 - 

32. 

PLUME IMPINGEMENT - Plume impingement refers to the effect of MMU gas plumes on 

nearby objects. The simulation issue is to reproduce accurately the affect that the expelled 

gas will have on the target. As gas is expelled from the MM?: thrusters io coiiiiol its 

position and attitude, the molecules that impinge upon the target will impart forces that will 

alter its present motion. Therefore, it is necessary to train the pilots to minimize plume 

impingement so that they will be able to safely and successfully rendezvous with a target on 

orbit. 

During mission 41 C, unexpected plume impingement effects occurred when astronaut 

George Nelson approached the Solar Maximum satellite. There were approximately 18 cases 

of MMU thruster plumes contacting the satellite surface, causing the satellite to start 

tumbling. This experience resulted in the subsequent modelling of plume impingement 

effects of the MMU. 

The plume impingement effects were modelled by ignoring the minor variances in the 

exterior surface of the target and assuming it to be whatever basic geometric shape it most 

closely resembled. The plume effect for each thruster oriented towards the target was 

calculated and summed to produce a net effect. Because of the large number of calculations 

required to obtain the forces and moments impinging on the target at any given time, all data 

points for a variety of distances and rotational orientations were calculated off-line prior to 

the simulation and stored in a data table. During the simulation, the computer calculated the 

relative position and orientation of the target to the MMU and extracted the three forces and 

three moments from the table that most closely matched the present conditions. 

This method provided a first order approximation of the actual conditions that would 

exist on orbit, because it was not possible to determine the actual translational orientations, 

rotational orientations, and rates of the pilot and target that would exist on orbit during the 

rendezvous. It was also not possible to store a large enough table of data points that would 

allow for minute changes in position and orientation. In addition, the actual commands that 

would be used on orbit would be the result of a wide variety of factors that are 

unpredictable. This rough approximation was acceptable because it was only important for 

the pilot to be aware of the problems that would be caused if large amounts of gas were used 

near the target, not for the pilot to train for impingement of a specific target. This 

modelling was used in training astronauts Joe Allen and Dale Gardner to rendezvous and 

capture the Hughes Westar and Palapa-6 satellites during Mission 51 A. Because of their 

training, both astronauts reported only minor plume impingement effects on orbit. 

CONTACT DYNAMICS - Contact dynamics between two bodies in space is an important 

issue. If a force is applied to an object in the earth environment, the object may or may not 
. 

move, depending on other forces acting upon it. If a force is applied to an object in space, the 

object moves in a manner directly related to the magnitude and direction of the force applied. 

Therefore, it is necessary to simulate this effect so that the pilot can become accustomed to 

the effects of contact dynamics. The two important areas of the contact dynamics issue are 

contact between the craft and target during capture, and contact while working on a 

spacecraft, such as repairing a satellite. 

When the MMU is used to capture a target, it is possible to provide a relatively accurate 

model of the contact dynamics that exist. This is because the simulation system takes into 

account the relative shapes, positions, orientations, and rates of the two objects involved. 

Contact between the pilot's body and another object is difficult to simulate, because the 

human is an unpredictable and autonomous system. Therefore, it is necessary to obtain 

real-time data that describes the direction and magnitude of the forces being applied to the 

object. Presently, the only feasible method of determining this data is to place load cell 

arrays on all the surfaces of the target that will be involved. The load cell arrays provide a 

direct input of the magnitude and direction of the forces involved. This data can then be used 

to simulate the induced rates caused by the interaction and, in turn, affect the resultant 

motions of both the MMU and target. In a real-time simulation system, it is possible to 

model the relative motions between the pilot and target accurately with this method. This is 

an additional capability that is planned for implementation to the simulation system at a 

later date. 

FRAME RATE - Frame rate refers to how often the digital computer executes the 

necessary software models. This time period is critical when the simulation is operating in 

real-time, because it is necessary to execute the software as often as possible to simulate 

an anolog system. If the frame rate is too large, the hardware devices move in noticable 

steps. 

The frame rate of the SOS lab simulator is 40 milliseconds (1/25 second). Although 

this frame rate has been sufficient, there have been a couple of instances where a higher 

resolution would have been desirable. An example, was when astronaut Bruce McCandless 

indicated that thruster firing activity during STS mission 41 B was much faster than he had 

ever experienced in the simulator. This high level thruster activity was caused by AAH 

responding to rotational rates induced by translational commands. Through analyses, it was 

determined that the discrepency was due to the fact that the simulation frame rate was 

slower than the analog flight hardware. Since the simulator operates in discrete 

increments, it updates these rotational rates only once each frame. Therefore, it is likely 

that as the rotational rates build up, they will approach the AAH switching line (the point at 

which AAH will begin to correct for rotational rates or angles) in one frame and pass beyond 

it by the next frame. The simulation model will then command correcting rates, which will 

build up and take the rotational rates back across the switching line during one frame. This 

lagging response time can result in larger correctional moments and a slower AAH cycle 

time. 

On the analog MMU, correcting rates are commanded as soon as rotational rates pass the 

AAH switching line. As soon as the rates pass back across the switching line, the correcting 

rates are terminated. Because of this quick response time, the appropriate thrusters will 

cycle on and off at a frequency of about 5 Hr until the rotational rates are corrected. 

AAH RATE - The MMU AAH thruster logic utilizes thruster pulsing and continuous 

thruster firing, as necessary, to correct for unwanted rotational rates. The pulsing aspect 

of the logic operates in terms of 8 millisecond pulses, three times a second. Because the SOS 

lab simulation operates at 40 milliseconds, it was necessary to devise a method where the 

net forces produced by a specific command would be equal. Because impulse expended is the 

parameter that determines delta velocity, or in the above case, rotational rate, the net effect 

will be the same as long as the impulse is the same. The solution is found by using the 

relation between impulse, force, and time; I = F t. If t = 0.008 sec. and F = 1.7 Ib. (7.56 

N) (which is the nominal MMU force for one thruster), I = 0.0136 Ib.-sec. (0.0605 Nsec.). By setting t = 0.040 sec. (the simulation frame rate) and keeping I constant, it can 
be calculated that the equivalent 40 millisecond force level is F = 0.34 Ib. (1.51 N). By 

executing the AAH pulsing logic three times each frame and using this force value, the 

resultant effect in MMU motion will be the same as on orbit, even though the simulator is 

operating at a frame rate much slower than that of AAH. 

VISUAL CUES - Close proximity operations between the MMU and a target require full 

three-dimensional visual cues; therefore, it is necessary to provide the pilot with fullscale mockups of the targets qd the ability to move about them. The associated problem is 

that the MBC operates in a relatively confined area. The information gathered through both 

direct and peripheral viewing of the room provides the pilot with information that would not 

exist on orbit. 

In an effort to reduce the effect of any visual room cues during simulations, the axes of 

the target can be rotated so as to not align with any room edges. This procedure was used 

during training for the Skylab mission and for Cargo Bay mockup operations. In both of 

these examples, the astronauts trained within full-scale mockups; thus, they received 

visual cues from the mockups and not from the room. 

Another visual cue issue arose during STS mission 51 A training. This training involved 

learning how to capture a satellite in which the axis of spin is close to, but not exactly, 

aligned along the axis of capture. This spin effect, known as coning, results in the pilot 

trying to dock with a point that is actually moving in a circle, in reference to himself. 

When the addition of the coning effect to the SOS simulation system was first 

recommended, it was realized that the TAG would not be able to withstand the high inertias 

that would be induced by the satellite mockup. Since only the relative motions of the pilot 

and target were necessary for training, the visual coning effect of the satellite was imparted 

on the MBC. Concerns arose that these MBC motions would result in pilot disorientation or 

sickness. The results of the training simulations using this method demonstrated that the 

MBC motions did not cause any discomfort or disorientation. Subjective pilot comments 

indicated that the visual cues were more predominant than the motions of the MBC. Another 

concern was that the pilots would visually notice, from room cues, that the MBC and not the 

satellite mockup was coning. The pilots reported that they were unaware of this because of 

the high workload involved in performing the task. 

SULlMARy 

A simulation system that provides both developmental analysis data and operational 

training requires a high degree of simulation fidelity. Through comments of astronauts who 

have flown the MMU on orbit, it has been determined that many of the MMU simulation 

issues have been modelled to an appropriate degree of fidelity. These include center-ofmass offset, plume impingement, contact dynamics, AAH rate, and visual cues. On the other 

hand, the frame rate and flexible body dynamics issues have not yet been modelled to the 

desired degree of fidelity. 

The use of the SOS laboratory's simulation system has indicated that a high fidelity, 

real-time, man-in-the-loop simulation is feasible and effective. As demonstrated with the 

MMU, the simulation provided a reliable means of training personnel to effectively and 

safely operate on orbit. 

rKMEraAm 

- Automatic Attitude Hold 

PCD - Apogee Kick Motor Capture Device 

C€A - Control Electronics Assembly 

Ecs - Electrical Control and Switching 

FBD - Flexible Body Dynamics 

MBC - MovingBaseCm'age 

MMU - Manned Maneuvering Unit 
SaG - Single Axis Gimbal 

SX - Space Operations Simulation 

STS - Space Transportation System 

TPG - - ThreeAxisGimbal 

for their technical assistance. 

The authors would like to thank Robert A. Schein, Paul S. Cramer, and Leslie J. Rogers