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.
The onboard data processor for OAO 3 flight applications executes instructions at the rate of 2 1/2 billion per day. The computer commands, processes data, and controls telemetry subsystem programs onboard the spacecraft.
The Apollo guidance computer was designed to provide the computation necessary for guidance, navigation and control of the command module and the lunar landing module of the Apollo spacecraft. The computer was designed using the technology of the early 1960's and the production was completed by 1969. During the development, production, and operational phase of the program, the computer has accumulated a very interesting history which is valuable for evaluating the technology, production methods, system integration, and the reliability of the hardware. The operational experience in the Apollo guidance systems includes 17 computers which flew missions and another 26 flight type computers which are still in various phases of prelaunch activity including storage, system checkout, prelaunch spacecraft checkout, etc. These computers were manufactured and maintained under very strict quality control procedures with requirements for reporting and analyzing all indications of failure. Probably no other computer or electronic equipment with equivalent complexity has been as well documented and monitored. Since it has demonstrated a unique reliability history, it is important to evaluate the techniques and methods which have contributed to the high reliability of this computer.
Instrument data systems consist of a microprocessor, 3K bytes of Read Only Memory and 3K bytes of Random Access Memory. It interfaces with the spacecraft data bus through an isolated user interface with a direct memory access bus adaptor, and/or parallel data from instrument devices such as registers, buffers, analog to digital converters, multiplexers, and solid state sensors. These data systems support the spacecraft hardware and software communication protocol, decode and process instrument commands, generate continuous instrument operating modes, control the instrument mechanisms, acquire, process, format, and output instrument science data.
The Operations and Science Instrument Support (OASIS) project is a long-term effort to help produce operations capabilities that can support space science missions of the next century. Portions of the OASIS concept in software have been implemented under the general name OASIS-R/T. OASIS-CC is the OASIS Command and Control, for monitoring and controlling science instruments and spacecraft during test, integration, launch and on-orbit operations. Viewgraphs are presented on the OASIS-CC functionality description, OASIS-CC support, and OASIS-CC as a tool.
On this second day of the STS-98 mission, Atlantis continues to pursue the International Space Station (ISS). The unmanned Progress resupply spacecraft, loaded with trash, is sent into an orbit that will eventually drop the spacecraft into Earth's atmosphere, which will burn it up. Commander Cockrell and Mission Specialist Tom Jones are seen answering questions about the Destiny Laboratory Module and the mission.
Chandra is the world's largest and most sensitive X-ray telescope. The Chandra X-ray Observatory is the third in NASA's family of "Great Observatories." The Chandra X-ray Observatory, launched by Space Shuttle Columbia on July 23, 1999, is NASA's newest Great Observatory. The Chandra space flight software is the operational software, which controls and directs the Chandra X-ray Observatory. The Chandra flight software has executed faultlessly for over 13,000 hours on-orbit. The Chandra flight software directly controls the Pointing, Aspect Determination, Electrical Power Subsystem, Propulsion system, and the Command, Communications, and Data Management subsystems. The software controls the spacecraft operations during all phases of the mission. The software also performs thermal control of the telescope to maintain pointing accuracy and monitors radiation levels throughout the orbit so that the Science Instruments can be safed if radiation thresholds are exceeded. The efficient operation of Chandra flight software has enabled the gathering of crucial science data. The Chandra flight software fault protection is the key to early detection and prevention of science instrument or spacecraft damage in an operating platform/environment, which is completely unforgiving. Permanently open Sun Shade Door and ACIS focal plane radiator sensitivity exposes science instruments and mirrors to damage for pointing anomalies causing an attitude excursion. The Chandra flight software must prevent these attitude excursions from occurring for ANY failure. Another example is that the power system has an unregulated bus, which imposes severe operating requirements on Chandra flight software to control array pointing and battery connection/disconnect using a unique algorithmic and logic approach. The Chandra flight software has enabled a truly autonomous vehicle with greater than 99% of all mission data collected as planned. Less than 15% of spacecraft operations are conducted in view (1 hour out of 8) leading to very extended periods without ground contact. The Chandra flight software implements the flexible mission plan during this out of view period, manages the solid state recorder capacity, controls all pointing and maneuvers, provides fault detection for all satellite subsystems, and initiates communications with the ground at the appropriate time. This paper will describe the software architecture features, key design elements and software testing techniques that have facilitated Chandra's success.
This video shows the water landing of the Apollo 13 spacecraft. A computer animation shows the atmospheric reentry of the Command Module.
Space exploration applications can benefit greatly from autonomous systems. Great distances, limited communications and high costs make direct operations impossible while mandating operations reliability and efficiency beyond what traditional commanding can provide. Autonomous systems can improve reliability and enhance spacecraft capability significantly. However, there is reluctance to utilizing autonomous systems. In part this is due to general hesitation about new technologies, but a more tangible concern is that of reliability of predictability of autonomous software. In this paper, we describe ongoing work aimed at increasing robustness and predictability of autonomous software, with the ultimate goal of building trust in such systems. The work combines state-of-the-art technologies and capabilities in autonomous systems with advanced validation and synthesis techniques. The focus of this paper is on the autonomous system architecture that has been defined, and on how it enables the application of validation techniques for resulting autonomous systems.
The Cassini-Huygens mission is a joint NASA and European Space Agency (ESA) mission to collect scientific data of the Saturnian system and is managed by the Jet Propulsion Laboratory (JPL). After having arrived in Saturn orbit and releasing the ESA's Huygens probe for a highly successful descent and landing mission on Saturn's moon Titan, the Cassini orbiter continues on its tour of Saturn, its satellites, and the Saturnian environment. JPL's Cassini Integrated Test laboratory (ITL) is a dedicated high fidelity test bed that verifies and validates command sequences and flight software before upload to the Cassini spacecraft. The ITL provides artificial stimuli that allow a highly accurate hardware-in-the-loop test bed model that tests the operation of the Cassini spacecraft on the ground. This enables accurate prediction and recreation of mission events and flight software and hardware behavior. As we discovered more about the Saturnian environment, a combination of creative test methods and simulation changes were necessary to simulate the harmful effect that the optical and physical environment has on the pointing performance of Cassini. This paper presents the challenges experienced and overcome in that endeavor to simulate and test the post Saturn Orbit Insertion (SOI) and Probe Relay tour phase of the Cassini mission.
As computational power and speech recognition algorithms improve, the consumer market will see better-performing speech recognition applications. The cell phone and Internet-related service industry have further enhanced speech recognition applications using artificial intelligence and statistical data-mining techniques. These improvements to speech recognition technology (SRT) may one day help astronauts on future deep space human missions that require control of complex spacecraft systems or spacesuit applications by voice. Though SRT and more advanced speech recognition techniques show promise, use of this technology for a space application such as vehicle/habitat/spacesuit requires careful considerations. This paper provides considerations and guidance for the use of SRT in voice-controlled spacecraft systems (VCSS) applications for space missions, specifically in command-and-control (C2) applications where the commanding is user-initiated. First, current SRT limitations as known at the time of this report are given. Then, highlights of SRT used in the space program provide the reader with a history of some of the human spaceflight applications and research. Next, an overview of the speech production process and the intrinsic variations of speech are provided. Finally, general guidance and considerations are given for the development of a VCSS using a human-centered design approach for space applications that includes vocabulary selection and performance testing, as well as VCSS considerations for C2 dialogue management design, feedback, error handling, and evaluation/usability testing.
This paper addresses the technical aspects of the sample return system for the upcoming Origins, Spectral Interpretation, Resource Identification, and Security-Regolith Explorer (OSIRIS-REx) asteroid sample return mission. The overall mission design and current implementation are presented as an overview to establish a context for the technical description of the reentry and landing segment of the mission.The prime objective of the OSIRIS-REx mission is to sample a primitive, carbonaceous asteroid and to return that sample to Earth in pristine condition for detailed laboratory analysis. Targeting the near-Earth asteroid Bennu, the mission launches in September 2016 with an Earth reentry date of September 24, 2023.OSIRIS-REx will thoroughly characterize asteroid Bennu providing knowledge of the nature of near-Earth asteroids that is fundamental to understanding planet formation and the origin of life. The return to Earth of pristine samples with known geologic context will enable precise analyses that cannot be duplicated by spacecraft-based instruments, revolutionizing our understanding of the early Solar System. Bennu is both the most accessible carbonaceous asteroid and one of the most potentially Earth-hazardous asteroids known. Study of Bennu addresses multiple NASA objectives to understand the origin of the Solar System and the origin of life and will provide a greater understanding of both the hazards and resources in near-Earth space, serving as a precursor to future human missions to asteroids.This paper focuses on the technical aspects of the Sample Return Capsule (SRC) design and concept of operations, including trajectory design and reentry retrieval. Highlights of the mission are included below.The OSIRIS-REx spacecraft provides the essential functions for an asteroid characterization and sample return mission: attitude control propulsion power thermal control telecommunications command and data handling structural support to ensure successful rendezvous with Bennu characterization of Bennus properties delivery of the sampler to the surface, and return of the spacecraft to the vicinity of the Earth sample collection, performed by the Touch-and-Go Sample Acquisition Mechanism (TAGSAM), to acquire a regolith sample from the surface Earth re-entry and SRC recovery. Following sample collection, OSIRIS-REx drifts away from Bennu until the Asteroid Departure Maneuver is commanded on March 4, 2021, sending OSIRIS-REx on a ballistic return cruise to Earth. No additional large deterministic maneuvers are required to return the SRC to Earth. During the cruise, tracking and trajectory correction maneuvers (TCMs) are performed as necessary to precisely target the entry corridor. As OSIRIS-REx approaches Earth, the reentry plans are reviewed starting about a year before arrival, and preparations begin. The spacecraft is targeted away from the Earth until 7 days before entry. The final two trajectory correction maneuvers bring the spacecraft on target toward the Utah Test and Training Range (UTTR), with sufficient time for contingency resolution. The SRC releases 4 hours prior to atmospheric entry interface and, using the Stardust capsule heritage design, employs a traditional drogue and main parachute descent system for a soft touchdown.
The Space Technology 5 (ST5) mission is a NASA New Millennium Program project that will validate new technologies for future space science missions and demonstrate the feasibility of building launching and operating multiple, miniature spacecraft that can collect research-quality in-situ science measurements. The three satellites in the ST5 constellation will be launched into a sun-synchronous Earth orbit in early 2006. ST5 fits into the 25-kilogram and 24-watt class of very small but fully capable spacecraft. The new technologies and design concepts for a compact power and command and data handling (C&DH) avionics system are presented. The 2-card ST5 avionics design incorporates new technology components while being tightly constrained in mass, power and volume. In order to hold down the mass and volume, and quali& new technologies for fUture use in space, high efficiency triple-junction solar cells and a lithium-ion battery were baselined into the power system design. The flight computer is co-located with the power system electronics in an integral spacecraft structural enclosure called the card cage assembly. The flight computer has a full set of uplink, downlink and solid-state recording capabilities, and it implements a new CMOS Ultra-Low Power Radiation Tolerant logic technology. There were a number of challenges imposed by the ST5 mission. Specifically, designing a micro-sat class spacecraft demanded that minimizing mass, volume and power dissipation would drive the overall design. The result is a very streamlined approach, while striving to maintain a high level of capability, The mission's radiation requirements, along with the low voltage DC power distribution, limited the selection of analog parts that can operate within these constraints. The challenge of qualifying new technology components for the space environment within a short development schedule was another hurdle. The mission requirements also demanded magnetic cleanliness in order to reduce the effect of stray (spacecraft-generated) magnetic fields on the science-grade magnetometer.
Time-Tag Generation Script (TTaGS) is an application program, written in the AWK scripting language, for generating commands for aiming one Ku-band antenna and two S-band antennas for communicating with spacecraft. TTaGS saves between 2 and 4 person-hours per every 24 hours by automating the repetitious process of building between 150 and 180 antenna-control commands. TTaGS reads a text database of communication satellite schedules and a text database of satellite rise and set times and cross-references items in the two databases. It then compares the scheduled start and stop with the geometric rise and set to compute the times to execute antenna control commands. While so doing, TTaGS determines whether to generate commands for guidance, navigation, and control computers to tell them which satellites to track. To help prevent Ku-band irradiation of the Earth, TTaGS accepts input from the user about horizon tolerance and accordingly restricts activation and effects deactivation of the transmitter. TTaGS can be modified easily to enable tracking of additional satellites and for such other tasks as reading Sun-rise/set tables to generate commands to point the solar photovoltaic arrays of the International Space Station at the Sun.
Traditional satellite and launch control systems have consisted of custom solutions requiring significant development and maintenance costs. These systems have typically been designed to support specific program requirements and are expensive to modify and augment after delivery. The expanding role of space in today's marketplace combined with the increased sophistication and capabilities of modern satellites has created a need for more efficient, lower cost solutions to complete command and control systems. Recent technical advances have resulted in commercial-off-the-shelf products which greatly reduce the complete life-cycle costs associated with satellite launch and control system procurements. System integrators and spacecraft operators have, however, been slow to integrate these commercial based solutions into a comprehensive command and control system. This is due, in part, to a resistance to change and the fact that many available products are unable to effectively communicate with other commercial products. The United States Air Force, responsible for the health and safety of over 84 satellites via its Air Force Satellite Control Network (AFSCN), has embarked on an initiative to prove that commercial products can be used effectively to form a comprehensive command and control system. The initial version of this system is being installed at the Air Force's Center for Research Support (CERES) located at the National Test Facility in Colorado Springs, Colorado. The first stage of this initiative involved the identification of commercial products capable of satisfying each functional element of a command and control system. A significant requirement in this product selection criteria was flexibility and ability to integrate with other available commercial products. This paper discusses the functions and capabilities of the product selected to provide orbit determination functions for this comprehensive command and control system.
The Apollo 16 spacecraft is scheduled for launch on Apr. 16, 1972 from Complex 39A at the Kennedy Space Center, Florida by the Saturn V launch vehicle. Crewmen are mission commander John W. Young, command module pilot Thomas K. Mattingly II and lunar module pilot Charles M. Duke Jr. Objectives of the mission, to last up to 12 days, as outlined by NASA: to perform selenological inspection, survey and sampling of materials in a preselected region of Descartes using a lunar roving' vehicle; deploy and activate Apollo surface experiments; develop man's capability to work in the lunar environment; obtain photographs of candidate exploration sites; and toconduct inflight experiments and photographic tasks in lunar orbit. Following launch, the spacecraft will reach Earth Parking Orbit and remain in orbit for about two and one-half revolutions prior to Translunar Injection. Next, the Command and Service Module docks with the Lunar Module and the spacecraft "coasts" to the moon. In orbit around the moon, the Command and Service Module/Lunar Module combination will descend to within 50,000 feet of the lunar surface before undocking. The Lunar Module will continue to descend while the Command and Service Module returns to an orbit approximately 60 miles high. Stay time on the lunar surface is scheduled for approximately 73 hours. The ascent stage of the Lunar Module then lifts the astronauts back into lunar orbit where they will dock with the Command/Service Module. The Lunar Module is jettisoned and Transearth Injection follows. Just prior to reentry into the earth's atmosphere, the Service Module is jettisoned, and the astronauts in the Command Module splashdown in the Pacific Ocean. The target point for end-of-mission splashdown is at 05 degrees 0 minutes north latitude and 158 degrees 40 minutes west longitude or approximately 985 nautical miles south of Honolulu, Hawaii. Splashdown is scheduled for Apr. 28, 1972 at 10:30 a.m. Hawaiian Standard Time (2:30 p.m. CST). Recovery forces for Apollo 16, stationed in both the Atlantic and Pacific Oceans, will consist of three ships, nine aircraft and nearly 1,700 personnel. CTF-130 (Manned Spacecraft Recovery Force, Pacific) forces will be stationed south of Hawaii. Three ships, eight helicopters and three Air Force HC-130H aircraft, and nearly 1,100 personnel, will take part. Task Force 140 (Manned Spacecraft Recovery Force, Atlantic), comprising one ship, six HC-130H aircraft, three helicopters and approximately 300 personnel, will be positioned for possible launch abort operations. Two ships in the Atlantic will also be used for acoustical testing. Other forces, primarily aircraft and personnel of the Air Force Aerospace Rescue and Recovery Service will be on alert around the world for contingency recovery support.
The X-band Acquisition Aid (AAP) software is a low-cost acquisition aid for the Deep Space Network (DSN) antennas, and is used while acquiring a spacecraft shortly after it has launched. When enabled, the acquisition aid provides corrections to the antenna-predicted trajectory of the spacecraft to compensate for the variations that occur during the actual launch. The AAP software also provides the corrections to the antenna-predicted trajectory to the navigation team that uses the corrections to refine their model of the spacecraft in order to produce improved antenna-predicted trajectories for each spacecraft that passes over each complex. The software provides an automated Acquisition Aid receiver calibration, and provides graphical displays to the operator and remote viewers via an Ethernet connection. It has a Web server, and the remote workstations use the Firefox browser to view the displays. At any given time, only one operator can control any particular display in order to avoid conflicting commands from more than one control point. The configuration and control is accomplished solely via the graphical displays. The operator does not have to remember any commands. Only a few configuration parameters need to be changed, and can be saved to the appropriate spacecraft-dependent configuration file on the AAP s hard disk. AAP automates the calibration sequence by first commanding the antenna to the correct position, starting the receiver calibration sequence, and then providing the operator with the option of accepting or rejecting the new calibration parameters. If accepted, the new parameters are stored in the appropriate spacecraft-dependent configuration file. The calibration can be performed on the Sun, greatly expanding the window of opportunity for calibration. The spacecraft traditionally used for calibration is in view typically twice per day, and only for about ten minutes each pass.
The Orion Spacecraft will be required to perform entry and landing functions for both Low Earth Orbit (LEO) and Lunar return missions, utilizing only the Command Module (CM) with its unique systems and GN&C design. This paper presents the current CM Flight Control System (FCS) design to support entry and landing, with a focus on analyses that have supported its development to date. The CM FCS will have to provide for spacecraft stability and control while following guidance or manual commands during exo-atmospheric flight, after Service Module separation, translational powered flight required of the CM, atmospheric flight supporting both direct entry and skip trajectories down to drogue chute deploy, and during roll attitude reorientation just prior to touchdown. Various studies and analyses have been performed or are on-going supporting an overall FCS design with reasonably sized Reaction Control System (RCS) jets, that minimizes fuel usage, that provides appropriate command following but with reasonable stability and control margin. Results from these efforts to date are included, with particular attention on design issues that have emerged, such as the struggle to accommodate sub-sonic pitch and yaw control without using excessively large jets that could have a detrimental impact on vehicle weight. Apollo, with a similar shape, struggled with this issue as well. Outstanding CM FCS related design and analysis issues, planned for future effort, are also briefly be discussed.
The Radio Frequency Health Node (RFHN) wireless sensor system differs from other wireless sensor systems in ways originally intended to enhance utility as an instrumentation system for a spacecraft. The RFHN can also be adapted to use in terrestrial applications in which there are requirements for operational flexibility and integrability into higher-level instrumentation and data acquisition systems. As shown in the figure, the heart of the system is the RFHN, which is a unit that passes commands and data between (1) one or more commercially available wireless sensor units (optionally, also including wired sensor units) and (2) command and data interfaces with a local control computer that may be part of the spacecraft or other engineering system in which the wireless sensor system is installed. In turn, the local control computer can be in radio or wire communication with a remote control computer that may be part of a higher-level system. The remote control computer, acting via the local control computer and the RFHN, cannot only monitor readout data from the sensor units but can also remotely configure (program or reprogram) the RFHN and the sensor units during operation. In a spacecraft application, the RFHN and the sensor units can also be configured more nearly directly, prior to launch, via a serial interface that includes an umbilical cable between the spacecraft and ground support equipment. In either case, the RFHN wireless sensor system has the flexibility to be configured, as required, with different numbers and types of sensors for different applications. The RFHN can be used to effect realtime transfer of data from, and commands to, the wireless sensor units. It can also store data for later retrieval by an external computer. The RFHN communicates with the wireless sensor units via a radio transceiver module. The modular design of the RFHN makes it possible to add radio transceiver modules as needed to accommodate additional sets of wireless sensor units. The RFHN includes a core module that performs generic computer functions, including management of power and input, output, processing, and storage of data. In a typical application, the processing capabilities in the RFHN are utilized to perform preprocessing, trending, and fusion of sensor data. The core module also serves as the unit through which the remote control computer configures the sensor units and the rest of the RFHN.