Search NASA⌕ Search

SEARCH · Search NASA

Results for “COMMAND MODULE”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 415 records · Page 23
All sourcesNASA NTRSDOE OSTI
NASA NTRS1987

Nuclear electric power for multimegawatt orbit transfer vehicles

Multimegawatt nuclear propulsion is an attractive option for orbit transfer vehicles. The masses of these platforms are expected to exceed the capability of a single launch from Earth necessitating assembly in space in a parking orbit. The OTV would transfer the platform from the parking orbit to the operational orbit and then return for the next mission. Electric propulsion is advantageous because of the high specific impulse achieved by the technology, 1000 to 5000 s and beyond, to reduce the propellant required. Nuclear power is attractive as the power system because of the weight savings over solar systems in the multimegawatt regime, and multimegawatts of power are required. A conceptual diagram is shown of an OTV with a command control module using electric thrusters powered from an SP-100 class nuclear reactor power system.

Casagrande, R. D.↗
NASA NTRS1993

NEP power subsystem modeling

The Nuclear Electric Propulsion (NEP) system optimization code consists of a master module and various submodules. Each of the submodules represents a subsystem within the total NEP power system. The master module sends commands and input data to each of the submodules and receives output data back. Rocketdyne was responsible for preparing submodules for the power conversion (both K-Rankine and Brayton), heat rejection, and power management and distribution.

Harty, Richard B.↗
NASA NTRS1993

Thermogeologic mapping of the Moon from lunar orbit

The Infrared Scanning Radiometer (ISR) onboard the Apollo 17 Command-Service Module (CSM) mapped thermal emission of the lunar surface from orbit. Measured temperature values span the diurnal range of lunar temperatures (85 K to 400 K) and have an accuracy of approximately plus or minus 2 K. Surface spatial resolution at nadir is 2.2 km. This Apollo data is being revisited using data presentation software for the Macintosh computer, which was not available 20 years ago, even on mainframes. The new thermal images exhibit subtleties in the delineation of geophysical surface units that were unappreciated in the original survey of the data. Looking first at nighttime thermal emission from the ground tracks over Oceanus Procellarum to Mare Orientale, we have confirmed and expanded on earlier observations of regolith differences between mare and highlands and of a scheme for relative age-dating of larger impact craters of the Copernican age. We see an impact crater near Lenz, just north of Orientale, which exhibits an extraordinarily fresh ejecta blanket. Photography of this area is extremely poor, but we can see the feature in the Galileo data. We plan to derive geophysical surface properties of the overflown region using thermal models of regolith structures.

Mendell, W. W.↗
NASA NTRS1996

The Global File System

The global file system (GFS) is a prototype design for a distributed file system in which cluster nodes physically share storage devices connected via a network-like fiber channel. Networks and network-attached storage devices have advanced to a level of performance and extensibility so that the previous disadvantages of shared disk architectures are no longer valid. This shared storage architecture attempts to exploit the sophistication of storage device technologies whereas a server architecture diminishes a device's role to that of a simple component. GFS distributes the file system responsibilities across processing nodes, storage across the devices, and file system resources across the entire storage pool. GFS caches data on the storage devices instead of the main memories of the machines. Consistency is established by using a locking mechanism maintained by the storage devices to facilitate atomic read-modify-write operations. The locking mechanism is being prototyped in the Silicon Graphics IRIX operating system and is accessed using standard Unix commands and modules.

Soltis, Steven R.↗
NASA NTRS2003

Shuttle Payload Ground Command and Control: An Experiment Implementation Combustion Module-2 Software Development, STS-107

This presentation covers the design of a command and control architecture developed by the author for the Combustion Module-2 microgravity experiment, which flew aboard the STS-107 Shuttle mission, The design was implemented to satisfy a hybrid network that utilized TCP/IP for both the onboard segment and ground segment, with an intermediary unreliable transport for the space to ground segment. With the infusion of Internet networking technologies into Space Shuttle, Space Station, and spacecraft avionics systems, comes the need for robust methodologies for ground command and control. Considerations of high bit error links, and unreliable transport over intermittent links must be considered in such systems. Internet protocols applied to these systems, coupled with the appropriate application layer protections, can provide adequate communication architectures for command and control. However, there are inherent limitations and additional complexities added by the use of Internet protocols that must be considered during the design. This presentation will discuss the rationale for the: framework and protocol algorithms developed by the author. A summary of design considerations, implantation issues, and learned lessons will be will be presented. A summary of mission results using this communications architecture will be presented. Additionally, areas of further needed investigation will be identified.

Carek, David Andrew↗
NASA NTRS1989

Risk-Based Fire Safety Experiment Definition for Manned Spacecraft

Risk methodology is used to define experiments to be conducted in space which will help to construct and test the models required for accident sequence identification. The development of accident scenarios is based on the realization that whether damage occurs depends on the time competition of two processes: the ignition and creation of an adverse environment, and the detection and suppression activities. If the fire grows and causes damage faster than it is detected and suppressed, then an accident occurred. The proposed integrated experiments will provide information on individual models that apply to each of the above processes, as well as previously unidentified interactions and processes, if any. Initially, models that are used in terrestrial fire risk assessments are considered. These include heat and smoke release models, detection and suppression models, as well as damage models. In cases where the absence of gravity substantially invalidates a model, alternate models will be developed. Models that depend on buoyancy effects, such as the multizone compartment fire models, are included in these cases. The experiments will be performed in a variety of geometries simulating habitable areas, racks, and other spaces. These simulations will necessitate theoretical studies of scaling effects. Sensitivity studies will also be carried out including the effects of varying oxygen concentrations, pressures, fuel orientation and geometry, and air flow rates. The experimental apparatus described herein includes three major modules: the combustion, the fluids, and the command and power modules.

Apostolakis, G. E.↗
NASA NTRS1981

IGDS/TRAP Interface Program (ITIP). Detailed Design Specification (DDS)

The software modules which comprise the IGDS/TRAP Interface Program are described. A hierarchical input processing output (HIPO) chart for each user command is given. The description consists of: (1) function of the user command; (2) calling sequence; (3) moduls which call this use command; (4) modules called by this user command; (5) IGDS commands used by this user command; and (6) local usage of global registers. Each HIPO contains the principal functions performed within the module. Also included with each function are a list of the inputs which may be required to perform the function and a list of the outputs which may be created as a result of performing the function.

Jefferys, S.↗
NASA NTRS1972

The Skylab orbital laboratory.

The Skylab orbital laboratory is described in terms of spacecraft design features, the experiment programs, and the schedule of planned missions. Attention is given to flight and crew operations, rescue measures, the Multiple Docking Adapter, the Airlock Module, the Workshop, the Apollo Telescope Mount, Saturn V booster, Command and Service Modules, the life support system, thermal and environmental control, electrical power, attitude and pointing control, instrumentation and communications, crew equipment, provisions, and stowage.

Schneider, W. C.↗
NASA NTRS1992

ROMPS critical design review. Volume 2: Robot module design documentation

The robot module design documentation for the Remote Operated Materials Processing in Space (ROMPS) experiment is compiled. This volume presents the following information: robot module modifications; Easylab commands definitions and flowcharts; Easylab program definitions and flowcharts; robot module fault conditions and structure charts; and C-DOC flow structure and cross references.

Dobbs, M. E.↗
NASA NTRS1972

Digital autopilot for the SKYLAB orbital assembly.

In Project SKYLAB, the Command and Service Module which ferries astronaut crews to and from the Orbital Workshop is required to have the capability of providing attitude control for the entire Orbital Assembly during docked phases of the mission. A digital autopilot has been designed which meets this requirement. It is a direct descendant of the digital autopilot designed for and used extensively in project Apollo. There is a major difference however. For Apollo, it was reasonable to design an autopilot that treated the roll, pitch, and yaw axes independently. Because of the geometry of the Orbital Assembly, however, it is of considerable advantage to design the jet selection logic for SKYLAB such that the roll and pitch axes are treated as coupled, and also that the roll and yaw axes are treated as coupled. This paper discusses how inter-axis dependence has been incorporated in the Command and Service Module's digital autopilot while working within the limitations of the onboard computer.

Turnbull, J. F.↗
NASA NTRS1973

Apollo experience report: Ascent propulsion system

The development of the Apollo lunar module ascent propulsion subsystem is documented. The ascent propulsion subsystem was designed, built, and tested to provide propulsive power for launching the ascent stage of the lunar module from the surface of the moon into lunar orbit for rendezvous with the orbiting command and service module. Because total redundancy was prohibitive in this subsystem, special emphasis had to be placed on reliability in design with adequate demonstration short of an extensive flight-demonstration program. The significant technical problems encountered during all phases of the program are identified and the corrective actions are discussed. Based on this experience, several recommendations are made for any future program with similar subsystem requirements.

Humphries, C. E.↗
NASA NTRS2015

Space Launch System Co-Manifested Payload Options for Habitation

The Space Launch System (SLS) has a co-manifested payload capability that will grow over time as the launch vehicle matures and planned upgrades are implemented. The final configuration is planned to be capable of inserting a payload greater than 10 metric tons (mt) into a trans-lunar injection trajectory along with the crew in the Orion capsule and its service module. The co-manifested payload is located below the Orion and its service module in a 10 m high fairing similar to the way the Saturn launch vehicle carried the lunar lander below the Apollo command and service modules. Various approaches that utilize this comanifested payload capability to build up infrastructure in deep space have been explored in support of future asteroid, lunar, and Mars mission scenarios. This paper reports on the findings of the Advanced Concepts Office study team at NASA Marshall Space Flight Center (MSFC) working with the Advanced Exploration Systems Program on the Exploration Augmentation Module Project. It includes some of the possible options for habitation in the co-manifested payload volume of the SLS. Findings include a set of module designs that can be developed in 10 mt increments to support these co-manifested payload missions along with a comparison of this approach to a large-module payload flight configuration for the SLS.

Smitherman, David↗
NASA NTRS2015

Space Launch System Co-Manifested Payload Options for Habitation

The Space Launch System (SLS) has a co-manifested payload capability that will grow over time as the rocket matures and planned upgrades are implemented. The final configuration is planned to be capable of inserting a payload greater than 10 metric tons (mt) into a trans-lunar injection trajectory along with the crew in the Orion capsule and the service module. The co-manifested payload is located below the Orion and its service module in a 10-meter high fairing similar to the way the Saturn launch vehicle carried the lunar lander below the Apollo command and service modules. A variety of approaches have been explored that utilizes this co-manifested payload capability to build up infrastructure in deep space in support of future asteroid, lunar, and Mars mission scenarios. This paper is a report on the findings from the Advanced Concepts Office study team at the NASA Marshall Space Flight Center, working with the Advanced Exploration Systems Program on the Exploration Augmentation Module Project. It includes some of the possible options for habitation in the co-manifested payload volume on SLS. Findings include module designs that can be developed in 10mt increments to support these missions, including overall conceptual layouts, mass properties, and approaches for integration into various scenarios for near-term support of deep space habitat research and technology development, support to asteroid exploration, and long range support for Mars transfer flights.

Smitherman, David↗
NASA NTRS2008

Improved CLARAty Functional-Layer/Decision-Layer Interface

Improved interface software for communication between the CLARAty Decision and Functional layers has been developed. [The Coupled Layer Architecture for Robotics Autonomy (CLARAty) was described in Coupled-Layer Robotics Architecture for Autonomy (NPO-21218), NASA Tech Briefs, Vol. 26, No. 12 (December 2002), page 48. To recapitulate: the CLARAty architecture was developed to improve the modularity of robotic software while tightening coupling between planning/execution and basic control subsystems. Whereas prior robotic software architectures typically contained three layers, the CLARAty contains two layers: a decision layer (DL) and a functional layer (FL).] Types of communication supported by the present software include sending commands from DL modules to FL modules and sending data updates from FL modules to DL modules. The present software supplants prior interface software that had little error-checking capability, supported data parameters in string form only, supported commanding at only one level of the FL, and supported only limited updates of the state of the robot. The present software offers strong error checking, and supports complex data structures and commanding at multiple levels of the FL, and relative to the prior software, offers a much wider spectrum of state-update capabilities.

Estlin, Tara↗
NASA NTRS1973

Single-channel digital command-detection system

System, fabricated of highly-reliable digital logic elements, operates on binary pulse-code-modulated signals and derives internal synchronization from data signal. All-digital implementation of detector develops synchronization from data signal by computer cross-correlation of command modulation signal with its expected forms in sequence and adjusts detector phases in accordance with correlation peaks.

Carl, C. C.↗