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.
This paper is concerned with our present state of knowledge on the procedures and effectiveness of aborts from manned orbital and lunar missions. By abort is meant a deliberate or unintentional termination of the primary mission followed by an expedient return to earth of the payload (spacecraft and crew). A deliberate abort may be initiated if a critical component failed and thus impaired the probability of mission success or the crew's safety. Examples of this kind of abort are failure of the launch guidance system or the oxygen and cabin pressure system. Also, an unintentional abort may occur during the launch phase due to the complete or partial failure of one of the launch-vehicle stages to operate. For each mission every conceivable set of circumstances must be considered and evaluated to see if an abort of the mission is called for and to determine what sequence of events should occur to bring the spacecraft and crew safely back to earth with the highest probability of success. Factors which must be considered are: how to specify and sense an abort condition, how much fuel should be put onboard the vehicle for abort purposes, what size and kind of rocket engines are best suited for each mission, and what compromise is incurred due to other mission requirements? If an abort occurs, the optimum time of application as well as the magnitude and direction of the velocity changes must be determined beforehand and the crew must be clearly informed of what action is required or what the situation is so that they can decide the proper action.
The Kepler Mission uses a wide field-of-view telescope to photometrically monitor 100,000 main-sequence stars for evidence of planetary transits. Because of the large number of stars monitored and because the mission is designed with a precision (0.002%) sufficient to readily recognize Earth-size planets transiting solar-like stars, several hundred Earth-size planets should be found. Based on the the Dopper velocity observations that find 2% of the main-sequence stars have Jupiter-size planets in short-period orbits, the Kepler mission is also expected to detect about 2000 giant planets. Several questions about the association of planet types and stellar characteristics can be investigated. For example; Are small planets found when Jupiter-mass planets are also present in inner orbits? What is the frequency of small planets compared to Jupiter-mass planets? What is the frequency and distribution of planets intermediate in size and mass to that of Earth and Jupiter? What correlations exist between planet size, distribution, and frequency with the characteristics of the stars they orbit? A comparison between model predictions and observation should be a useful step in evolving better models of planetary system formation and help put the formation of our Solar System in perspective.
As part of the Artemis program to return humans to the lunar surface, the National Aeronautics and Space Administration is planning to use the Orion Multi- Purpose Crew Vehicle to transport crew to a small orbital platform called Gate- way in cislunar space. To facilitate this activity, Orion is required to perform Rendezvous, Proximity Operations, and Docking (RPOD) with both the Gate- way and the launch vehicle upper stage. The Orion spacecraft uses sequencing in the form of Phases, Segments, Activities, and Modes (PSAM) to configure Guidance, Navigation, & Control (GN&C) software during each portion of the mission. Significant updates to Orion PSAM definitions are required for RPOD. This paper describes the process of defining these new sequencing elements, implementing them in prototype flight software, and testing them in an integrated simulation environment. First, requirements are specified to determine the nominal and off-nominal sequencing behavior necessary to complete the mission. These requirements also specify which software functions should be fully autonomous and which functions require manual interactions from crew or ground operators. Next, the RPOD concept of operations is defined with detailed events listed in a mission timeline. Third, a state machine diagram is developed to show all PSAM states, including all possible transitions between them. After this, the PSAM states and transitions are entered into a sequencing software emulator and parameter values and modes are defined for GN&C software elements. Finally, the PSAM architecture is tested within an integrated simulation environment by connecting it with prototypes of relevant GN&C flight software elements and with detailed vehicle models. After the sequencing design has been finalized and tested, it is implemented in flight software.
For decades, NASA has employed different operational approaches for human and robotic missions. Human spaceflight missions to the Moon and in low Earth orbit have relied upon near-continuous communication with minimal time delays. During these missions, astronauts and mission control communicate interactively to perform tasks and resolve problems in real-time. In contrast, deep-space robotic missions are designed for operations in the presence of significant communication delay - from tens of minutes to hours. Consequently, robotic missions typically employ meticulously scripted and validated command sequences that are intermittently uplinked to the robot for independent execution over long periods. Over the next few years, however, we will see increasing use of robots that blend these two operational approaches. These interactive exploration robots will be remotely operated by humans on Earth or from a spacecraft. These robots will be used to support astronauts on the International Space Station (ISS), to conduct new missions to the Moon, and potentially to enable remote exploration of planetary surfaces in real-time. In this talk, I will discuss the technical challenges associated with building and operating robots in this manner, along with lessons learned from research conducted with the ISS and in the field.
The Mars Observer team was, until the untimely loss of the spacecraft on August 21, 1993, performing flight operations with greater efficiency and speed than any previous JPL mission of its size. This level of through-put was made possible by a Mission Operations System which was composed of skilled personnel using sophisticated sequencing and commanding tools. During cruise flight operations, however, it was realized by the project that this commanding level was not going to be sufficient to support the activities planned for the mapping operations. The project had committed to providing the science instrument principle investigators with a much higher level of commanding during mapping. Thus, the project began taking steps to enhance the capabilities of the flight team. One mechanism used by project management was a tool available from Total Quality Management (TQM). This tool is known as a Process Action Team (PAT). The Mars Observer PAT was tasked to increase the capacity of the flight team's non-stored commanding process by fifty percent with no increase in staffing and a minimal increase in risk. The outcome of this effort was to, in fact, increase the capacity by a factor of 2.5 rather than the desired fifty percent and actually reduce risk. The majority of these improvements came from the automation of the existing command process. The results required very few changes to the existing mission operations system. Rather, the PAT was able to take advantage of automation capabilities inherent in the existing system and make changes to the existing flight team procedures. This paper will describe in detail the enhancements recommended by the PAT for the non-stored command generation process on Mars Observer. This will be contrasted with the process used by the flight team prior to implementation of these improvements. Finally, there will be a discussion of the applicability of the techniques devised by the PAT for enhancement of the non-stored command process to present and future projects.
Human missions to Mars will fundamentally transform how the planet is explored, enabling new scientific discoveries through more sophisticated sample acquisition and processing than can currently be implemented in robotic exploration. The presence of humans also poses new challenges, including ensuring astronaut safety and health and monitoring contamination. Because the capability to transfer materials to Earth will be extremely limited, there is a strong need for in situ diagnostic capabilities. Nucleotide sequencing is a particularly powerful tool because it can be used to: (1) mitigate microbial risks to crew by allowing identification of microbes in water, in air, and on surfaces; (2) identify optimal treatment strategies for infections that arise in crew members; and (3) track how crew members, microbes, and mission-relevant organisms (e.g., farmed plants) respond to conditions on Mars through transcriptomic and genomic changes. Sequencing would also offer benefits for science investigations occurring on the surface of Mars by permitting identification of Earth-derived contamination in samples. If Mars contains indigenous life, and that life is based on nucleic acids or other closely related molecules, sequencing would serve as a critical tool for the characterization of those molecules. Therefore, spaceflight-compatible nucleic acid sequencing would be an important capability for both crew health and astrobiology exploration. Advances in sequencing technology on Earth have been driven largely by needs for higher throughput and read accuracy. Although some reduction in size has been achieved, nearly all commercially available sequencers are not compatible with spaceflight due to size, power, and operational requirements. Exceptions are nanopore-based sequencers that measure changes in current caused by DNA passing through pores; these devices are inherently much smaller and require significantly less power than sequencers using other detection methods. Consequently, nanopore-based sequencers could be made flight-ready with only minimal modifications.
Until the past few years, missions typically involved fairly large expensive spacecraft. Such missions have primarily favored using older proven technologies over more recently developed ones, and humans controlled spacecraft by manually generating detailed command sequences with low-level tools and then transmitting the sequences for subsequent execution on a spacecraft controller. This approach toward controlling a spacecraft has worked spectacularly on previous missions, but it has limitations deriving from communications restrictions - scheduling time to communicate with a particular spacecraft involves competing with other projects due to the limited number of deep space network antennae. This implies that a spacecraft can spend a long time just waiting whenever a command sequence fails. This is one reason why the New Millennium program has an objective to migrate parts of mission control tasks onboard a spacecraft to reduce wait time by making spacecraft more robust. The migrated software is called a "remote agent" and has 4 components: a mission manager to generate the high level goals, a planner/scheduler to turn goals into activities while reasoning about future expected situations, an executive/diagnostics engine to initiate and maintain activities while interpreting sensed events by reasoning about past and present situations, and a conventional real-time subsystem to interface with the spacecraft to implement an activity's primitive actions. In addition to needing remote planning and execution for isolated spacecraft, a trend toward multiple-spacecraft missions points to the need for remote distributed planning and execution. The past few years have seen missions with growing numbers of probes. Pathfinder has its rover (Sojourner), Cassini has its lander (Huygens), and the New Millenium Deep Space 3 (DS3) proposal involves a constellation of 3 spacecraft for interferometric mapping. This trend is expected to continue to progressively larger fleets. For example, one mission proposed to succeed DS3 would have 18 spacecraft flying in formation in order to detect earth-sized planets orbiting other stars. A proposed magnetospheric constellation would involve 5 to 500 spacecraft in Earth orbit to measure global phenomena within the magnetosphere. This work describes and compares three autonomy architectures for a system that continuously plans to control a fleet of spacecraft using collective mission goals instead of goals or command sequences for each spacecraft. A fleet of self-commanding spacecraft would autonomously coordinate itself to satisfy high level science and engineering goals in a changing partially-understood environment making feasible the operation of tens or even a hundred spacecraft (such as for interferometry or plasma physics missions). The easiest way to adapt autonomous spacecraft research to controlling constellations involves treating the constellation as a single spacecraft. Here one spacecraft directly controls the others as if they were connected. The controlling "master" spacecraft performs all autonomy reasoning, and the slaves only have real-time subsystems to execute the master's commands and transmit local telemetry/observations. The executive/diagnostics module starts actions and the master's real-time subsystem controls the action either locally or remotely through a slave. While the master/slave approach benefits from conceptual simplicity, it relies on an assumption that the master spacecraft's executive can continuously monitor the slaves' real-time subsystems, and this relies on high-bandwidth highly-reliable communications. Since unintended results occur fairly rarely, one way to relax the bandwidth requirements involves only monitoring unexpected events in spacecraft. Unfortunately, this disables the ability to monitor for unexpected events between spacecraft and leads to a host of coordination problems among the slaves. Also, failures in the communications system can result in losing slaves. The other two architectures improve robustness while reducing communications by progressively distributing more of the other three remote agent components across the constellation. In a teamwork architecture, all spacecraft have executives and real-time subsystems - only the leader has the planner/scheduler and mission manager. Finally, distributing all remote agent components leads to a peer-to-peer approach toward constellation control.
The Galileo Jupiter orbital mission using the Low Gain Antenna (LGA) requires a higher degree of spacecraft state knowledge than was originally anticipated. Key elements of the revised design include onboard buffering of science and engineering data and extensive processing of data prior to downlink. In order to prevent loss of data resulting from overflow of the buffers and to allow efficient use of the spacecraft resources, ground based models of the spacecraft processes will be implemented. These models will be integral tools in the development of satellite encounter sequences and the cruise/playback sequences where recorded data is retrieved.
Version 5.0 of the AutoGen software has been released. Previous versions, variously denoted Autogen and autogen, were reported in two articles: Automated Sequence Generation Process and Software (NPO-30746), Software Tech Briefs (Special Supplement to NASA Tech Briefs), September 2007, page 30, and Autogen Version 2.0 (NPO- 41501), NASA Tech Briefs, Vol. 31, No. 10 (October 2007), page 58. To recapitulate: AutoGen (now signifying automatic sequence generation ) automates the generation of sequences of commands in a standard format for uplink to spacecraft. AutoGen requires fewer workers than are needed for older manual sequence-generation processes, and greatly reduces sequence-generation times. The sequences are embodied in spacecraft activity sequence files (SASFs). AutoGen automates generation of SASFs by use of another previously reported program called APGEN. AutoGen encodes knowledge of different mission phases and of how the resultant commands must differ among the phases. AutoGen also provides means for customizing sequences through use of configuration files. The approach followed in developing AutoGen has involved encoding the behaviors of a system into a model and encoding algorithms for context-sensitive customizations of the modeled behaviors. This version of AutoGen addressed the MRO (Mars Reconnaissance Orbiter) primary science phase (PSP) mission phase. On previous Mars missions this phase has more commonly been referred to as mapping phase. This version addressed the unique aspects of sequencing orbital operations and specifically the mission specific adaptation of orbital operations for MRO. This version also includes capabilities for MRO s role in Mars relay support for UHF relay communications with the MER rovers and the Phoenix lander.
Solar electric propulsion (SEP) trajectories to Saturn using multiple gravity assists are explored for the joint NASA and ESA Titan Saturn System Mission study. Results show that these new trajectories enable greater performance compared to chemical propulsion with similar gravity assists or SEP without gravity assists. This paper describes the method used in finding these interplanetary trajectories and examines variations in the performance for different SEP systems, flight times, and flyby sequences. The benefits of the SEP trajectories for a mission to Saturn are also discussed.
The Mars Pathfinder Mission was a great engineering achievement for the National Aeronautics and Space Administration (NASA) and the Jet Propulsion Laboratory (JPL) which built the Pathfinder Spacecraft and the Sojourner TM Rover. The mechanical design of the mission hardware was critical to the success of the complex entry sequence and landed operations. A wide variety of mechanisms were employed with varying technologies and heritage. These mechanisms have played a key role in the mission which has greatly exceeded expectations.
Science objectives are outlined for long surface traverse missions on Mars and the moon, with remotely-controlled roving vehicles. Series of candidate rover science payloads are proposed, varying in purpose, development needed, cost, and weight (35 to almost 300 kg). A high degree of internal control will be needed on the Mars rover, including the ability to carry out complex science sequences. Decision-making by humans in the Mars mission includes supervisory control of rover operations and selection of features and samples of geological and biological interest. For the lunar mission, less control on the rover and more on earth is appropriate. Operational problem areas for Mars include control, communications, data storage, night operations, and the mission operations system. For the moon, science data storage on the rover would be unnecessary and control much simpler.
The science goals for the Mars exploration program, together with the HEDS precursor environmental and technology needs, have been carefully laid out over the last several years and serve as a solid starting point for re-planning the program in an orderly way. Most recently, the science and HEDS communities have recognized the significance of subsurface sampling as a key component in "following the water": 1) to achieve science goals related to the search for evidence of life and 2) to gain access to the most valuable resource -- water. Accessing samples from hundreds and even thousands of meters beneath the surface is a challenge that will call for technology development and for one or more demonstration missions. Recent mission failures and concerns about the complexity of the previously planned MSR missions indicate that, before we are ready to undertake sample return and deep sampling, the Mars exploration program needs to include 1) technology development missions and 2) basic landing site assessment missions. These precursor missions should demonstrate the capability for reliable & accurate soft landing and in situ propellant production. The precursor missions will need to carry out close-up site observations, ground-penetrating radar mapping from orbit and conduct seismic surveys. The needs of the science and HEDS program requirements have much in common and clearly the programs should be planned as a single, continuous exploration effort. (We note that, although we are not yet ready to carry out sample return missions, we already have the capability to make impressive gains in in situ exploration by deploying full-scale rovers with mobility upward of ten kilometers.) A prudent minimum list of missions can be derived from the numerous goals and requirements; they can be sequenced in an orderly way to ensure that time is available to feed forward the results of the precursor missions.
Detecting extrasolar terrestrial planets orbiting main-sequence stars is of great interest and importance. Current ground-based methods are only capable of detecting objects about the size or mass of Jupiter or larger. The difficulties encountered with direct imaging of Earth-size planets from space are expected to be resolved in the next twenty years. Spacebased photometry of planetary transits is currently the only viable method for detection of terrestrial planets (30-600 times less massive than Jupiter). This method searches the extended solar neighborhood, providing a statistically large sample and the detailed characteristics of each individual case. A robust concept has been developed and proposed as a Discovery-class mission. Its capabilities and strengths are presented.
The 'Deviser III' automated spacecraft mission planner prototype can plan complete Voyager spacecraft operational sequences consisting of over 100 data capture goals, working 10-50 times faster than a human analyst. The planner generates a loop-free network of actions and events resembling a program evaluation and review technique chart. Actions, events, and inferences are the building blocks from which plans are assembled. It is noted that, for a very large spacecraft mission plan, the backtracking through remembered decision trees entailed by this artificial intelligence system can consume megabite quantities of computer memory.
Science objectives and properties to be measured are outlined for long surface traverse missions on Mars and the Moon, with remotely-controlled roving vehicles. A series of candidate rover payloads is proposed for each planet, varying in weight, cost, purpose, and development needed. The smallest weighs 35 kg; the largest almost 300 kg. A high degree of internal control will be needed on the Mars rover, including the ability to carry out complex science sequences. Decision-making by humans in the Mars mission includes supervisory control of rover operations and selection of features and samples of geological and biological interest. For the lunar mission, less control on the rover and more on earth is appropriate. Science portions of the rover mission profile are outlined, with timelines and mileage breakdowns. Operational problem areas for Mars include control, communications, data storage, night operations, and the mission operations system. For the moon, science data storage on the rover would be unnecessary and control much simpler.
Emerging methods in component-based software development offer significant advantages but may seem incompatible with existing mission operations applications. In this paper we relate our positive experiences integrating existing mission applications into component-based tools we are delivering to three missions. In most operations environments, a number of software applications have been integrated together to form the mission operations software. In contrast, with component-based software development chunks of related functionality and data structures, referred to as components, can be individually delivered, integrated and re-used. With the advent of powerful tools for managing component-based development, complex software systems can potentially see significant benefits in ease of integration, testability and reusability from these techniques. These benefits motivate us to ask how component-based development techniques can be relevant in a mission operations environment, where there is significant investment in software tools that are not component-based and may not be written in languages for which component-based tools even exist. Trusted and complex software tools for sequencing, validation, navigation, and other vital functions cannot simply be re-written or abandoned in order to gain the advantages offered by emerging component-based software techniques. Thus some middle ground must be found. We have faced exactly this issue, and have found several solutions. Ensemble is an open platform for development, integration, and deployment of mission operations software that we are developing. Ensemble itself is an extension of an open source, component-based software development platform called Eclipse. Due to the advantages of component-based development, we have been able to vary rapidly develop mission operations tools for three surface missions by mixing and matching from a common set of mission operation components. We have also had to determine how to integrate existing mission applications for sequence development, sequence validation, and high level activity planning, and other functions into a component-based environment. For each of these, we used a somewhat different technique based upon the structure and usage of the existing application.