SEARCH · Search NASA
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.
This paper compares and contrasts several coordination schemes for a system that continuously plans to control collections of rovers or spacecraft using collective mission goals instead of goals or command sequences for each spacecraft.
Adhesives in Apollo command, service and lunar modules primary load carrying structures, electrical potting and sealing medium
Cassini is a NASA/JPL spacecraft that is planned to be launched in 1997 for a 10.7 year mission to
Spacecraft control algorithms must know the expected vehicle response to any command to the available control effectors, such as reaction thrusters or torque devices. Spacecraft control system design approaches have traditionally relied on the estimated vehicle mass properties to determine the desired force and moment, as well as knowledge of the effector performance to efficiently control the spacecraft. A pattern recognition approach was used to investigate the relationship between the control effector commands and spacecraft responses. Instead of supplying the approximated vehicle properties and the thruster performance characteristics, a database of information relating the thruster ring commands and the desired vehicle response was used for closed-loop control. A Monte Carlo simulation data set of the spacecraft dynamic response to effector commands was analyzed to establish the influence a command has on the behavior of the spacecraft. A tool developed at NASA Johnson Space Center to analyze flight dynamics Monte Carlo data sets through pattern recognition methods was used to perform this analysis. Once a comprehensive data set relating spacecraft responses with commands was established, it was used in place of traditional control methods and gains set. This pattern recognition approach was compared with traditional control algorithms to determine the potential benefits and uses.
The Deep Space Science Vessel (DSSV) is a conceptual design of a very large spacecraft intended as a mobile microgravity science platform. It represents an effort to conceptualize the systems and internal architectures needed to support a forty-eight-person crew for multi-year missions throughout the inner solar system and potentially beyond. The general arrangement of the DSSV is a modular spacecraft. Considering only the pressurized, habitable elements, the DSSV includes two large pressurized modules (Hab and Lab) docked together along with eight smaller node modules completing the habitable configuration. The Hab and Lab modules are docked side by side, with the longitudinal axes parallel to each other and a single docking port connecting them. A node module is docked to each dome on the Hab and Lab modules, such that the two small node modules on each end of the large Hab and Lab domes are docked both to each other and to the Hab and Lab. This creates a “racetrack” translation path on the interior. The other four node modules are docked at the center of the Hab and Lab modules, two on each side, creating another “racetrack” translation path perpendicular to the first one. The DSSV has a generally vertical orientation. Within the Hab and Lab modules the decks are perpendicular to the longitudinal axis. The node modules are oriented with their longitudinal axes perpendicular to those of the Hab and Lab modules, so the nodes have a horizontal internal orientation. Decks are numbered one through nine, with decks two and eight representing the “top” and “bottom” domes of the Hab and Lab modules. The Hab Module decks encompass the ship’s galley, crew quarters, waste, hygiene, portions of crew exercise, and group recreation. The Lab Module contains food production facilities, the life science lab, the ship’s infirmary, the physical science lab, and the maintenance and fabrication workshop. The Node Modules serve a number of different functions. The two Exercise Nodes are docked to deck five of both the Hab and Lab modules and contain most of the aerobic and resistive exercise devices. Also docked to deck five but on the opposite side of the Hab and Lab modules are the Observation Deck and Space Café. These two node modules provide social gathering space for small numbers of crew. The Mission Operations Node is on deck nine directly above the Galley and contains spacecraft monitoring and commanding capabilities. Docked to it is the EVA Operations Node, which contains suit maintenance and storage. (The airlock is a separate, external element docked to the EVA Operations Node.) The Subsystems Node is on deck one beneath the maintenance and fabrication workshop. Docked to it is the Stowage Node. This node does not house DSSV primary stowage, but is a staging point where stowage brought in from logistics modules can be sorted, unpacked, or repacked as needed prior to distribution to the appropriate sections of the spacecraft.
The interface between a spacecraft and its ground operations segment includes the flow of commands, configuration, and sequencing elements to the spacecraft, and the flow of telemetry and data products from the spacecraft. Creating and implementing a complete definition of this interface simplifies and standardizes mission operations, allowing easy sharing of operations personnel across missions. Early spacecraft featured a simple flight / ground interface (FGI) using hardware command decoding in the radio, driven by technological limitations of the time. Modern spacecraft use command and data handling (CDH) avionics on which flight software executes, which in turn controls and configures the mission, executes subsystem and instrument instructions, and implements critical fault protection actions. Deep space missions feature advanced operations software for running sequenced activities over a period of weeks, which allows them to function with only infrequent ground contact. This approach comes at the cost of increased complexity in the FGI, requiring expensive modifications to heritage flight software and ground systems. By hosting the interface in the radio instead of the CDH avionics, modern missions can approximate the FGI design simplicity of early spacecraft, with significant advantages for vendor competition, lowered costs, standardization of operations, and reduction of implementation risk.
The film shows artists rendition of the spacecrafts, boosters, and flight of the Apollo lunar missions. The Apollo spacecraft will consist of three modules: the manned Command Module; the Service Module, which contains propulsion systems; and the Lunar Excursion Module (LEM) to carry astronauts to the moon and back to the Command and Service Modules. The spacecraft will be launched via a three-stage Saturn booster. The first stage will provide 7.5 million pounds of thrust from five F-1 engines for liftoff and initial powered flight. The second stage will develop 1 million pounds of thrust from five J-2 engines to boost the spacecraft almost into Earth orbit. Immediately after ignition of the second stage, the Launch Escape System will be jettisoned. A single J-2 engine in the S4B stage will provide 200,000 pounds of thrust to place the spacecraft in an earth parking orbit. It also will be used to propel the spacecraft into a translunar trajectory, then it will separate from the Apollo Modules. Onboard propulsion systems will be used to insert the spacecraft into lunar orbit. Two astronauts will enter the LEM, which will separate from the command and service modules. The LEM will go into elliptical orbit and prepare for landing. The LEM will lift off of the Moon's surface to return to the Command and Service Modules, and most likely be left in lunar orbit. After leaving the Moon's orbit, and shortly before entering Earth's orbit, the Service Module will be ejected. The Command Module will be oriented for reentry into the Earth's atmosphere. A drogue parachute will deploy at approximately 50,000 feet, followed by the main parachute system for touchdown.
Digital Command Network for error-free radio command control of manned and unmanned spacecraft
The Common Habitat is a long-duration habitat concept based on the Skylab II architecture that leverages a single, multi-destination design applicable to microgravity Mars transit, 1/6 g lunar surface, 3/8 g Mars surface, and 1 g Earth. A trade study for the Common Habitat will address vertical versus horizontal internal orientation and a crew size of four or eight crew. This has resulted in the creation of four variants of the Common Habitat: Four Crew Horizontal Configuration, Four Crew Vertical Configuration, Eight Crew Horizontal Configuration, and Eight Crew Vertical Configuration. Design guidelines that shaped the four configurations are discussed, including: mission duration, destinations/missions, pressure vessel, hatches and docking, subsystems and utilities, lander integration and offloading, and eight-crew extensibility. Functional capabilities for crew-related systems are also discussed, including: private habitation, meal preparation, meal consumption, medical operations, exercise, group socialization and recreation, human waste collection, hygiene, logistics, spacecraft monitoring and commanding, mission planning, robotics and teleoperation, scientific research, maintenance and fabrication, and EVA. Each of the four Common Habitat designs will be presented, with a deck-by-deck description of each workstation, crew station, or subsystem along with an assessment of its degree of compliance with the guidelines and functional capabilities. Finally, forward work will be identified that will down-select a single Common Habitat. This includes multiple analyses that will be performed on the four variants, a down-selection process, and design refinement goals for the selected variant.
Command File Error (CFE), as defined by the Jet Propulsion Laboratory's (JPL) Mission Operations Assurance (MOA) is, regardless of the consequence on the spacecraft, either: an error in a command file sent to the spacecraft, an error in the process for developing and delivering a command file to the spacecraft, or the omission of a command file that should have been sent to the spacecraft. The risk consequence of a CFE can be mission ending and thus a concern to space exploration projects during their mission operations. A CFE during space mission operations is often the symptom of some kind of imbalance or inadequacy within the system that comprises the hardware & software used for command generation and the human experts involved in this endeavour. As we move into an era of enhanced collaboration with other NASA centers and commercial partners, these systems become more and more complex and hence it is all the more important to formally model and analyze CFEs in order to manage the risk of CFEs. Here we will provide a summary of the ongoing efforts at JPL in this area and also explain some more recent developments in the area of developing quantitative models for the purpose of managing CFE's.
Packaging, machine organization, error detection, and fabrication and test in determining solution to long-term and time-critical reliability of Apollo command module guidance-control computer
Deep Space Information Facility equipment for processing spacecraft telemetry and command data
Chronological order of events concerning satellite, scientific sounding rocket, and spacecraft missions - tracking, command, and data acquisition facilities
The efficiency of a biodetection grinder, used to recover buried contamination, was tested using spacecraft components and laminated polystyrene strips containing Bacillus subtilis var. niger spores. The surfaces were decontaminated before tests. Results are given in tabular form. Tables are also given for heat resistance of bacteria spores, prevalence of bacteria in spacecraft before launch, and the types of bacteria found in Apollo 15 spacecraft components and command modules.
The development of optical, radar, and candidate subsystems for Project Apollo is discussed. The design and development of the optical subsystems for both the Apollo command and lunar spacecraft are described. Design approaches, problems, and solutions are presented. The evolution of radar interfaces with the GN&C system is discussed; these interfaces involved both hardware and software in a relatively complex interrelationship. The design and development of three candidate subsystems are also described. The systems were considered for use in Apollo, but were not incorporated into the final GN&C system. The three subsystems discussed are the star tracker-horizon photometer, the map and data viewer and the lunar module optical rendezvous system.
The International Ultraviolet Explorer (IUE) is a large astronomical observatory scheduled to be placed in a three-axis stabilized synchronous orbit in the fourth quarter of 1977. The thermal control system consists of multilayer insulation, ammonia-filled grooved heat pipes, bimetallic actuated louvers, and assorted commandable heaters. The spacecraft must operate over a 135-deg solar aspect range and must be able to survive an 85-min.-zero power eclipse. It has a design lifetime of three years. To verify the thermal design, an Engineering Test Unit (ETU) was subjected to a thermal balance test in the Solar Environment Simulator (SES) at the Goddard Space Flight Center (GSFC). Heater skins were utilized to simulate four solar aspect angles, and various internal power settings were used to simulate different operational cases. Temperatures obtained corresponded within 5C of predicted values, thus verifying the thermal analytical model. In addition, two 85-min.-eclipse periods were successfully completed verifying that the thermal design of the IUE was adequate for this mission requirement.
The work to identify, evaluate, and make recommendations concerning the functions and interfaces of those orbiter avionic subsystems which are dedicated to, or play some part in, handling communication signals (telemetry and command) to/from payloads (spacecraft) that will be carried into orbit by the shuttle is reported. Some principal directions of the research are: (1) analysis of the ability of the various avionic equipment to interface with and appropriately process payload signals; (2) development of criteria which will foster equipment compatibility with diverse types of payloads and signals; (3) study of operational procedures, especially those affecting signal acquisition; (4) trade-off analysis for end-to-end data link performance optimization; (5) identification of possible hardware design weakness which might degrade signal processing performance.
Beginning with the challenges presented by Sputnik 1 in 1957, and the formation of NASA, the apollo lunar exploration program is reviewed through Apollo Flight 11. The focal points are the spacecraft including the command and service modules, and the lunar module.