SEARCH · Engineering Papers
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.
Telerobotics continues to provide a means for extending human presence in space as an integral part of the control architecture of unmanned spacecraft. Supervised autonomy for control of space manipulators provides a safe and effective means for time delayed remote control of unmanned spacecraft.
This paper describes the integration of the Remote Agent (RA), a spacecraft autonomy system which is scheduled to control the Deep Space 1 spacecraft during a flight experiment in 1999. The RA is a reusable, model-based autonomy system that is quite different from software typically used to control an aerospace system. We describe the integration challenges we faced, how we addressed them, and the lessons learned. We focus on those aspects of integrating the RA that were either easier or more difficult than integrating a more traditional large software application because the RA is a model-based autonomous system. A number of characteristics of the RA made integration process easier. One example is the model-based nature of RA. Since the RA is model-based, most of its behavior is not hard coded into procedural program code. Instead, engineers specify high level models of the spacecraft's components from which the Remote Agent automatically derives correct system-wide behavior on the fly. This high level, modular, and declarative software description allowed some interfaces between RA components and between RA and the flight software to be automatically generated and tested for completeness against the Remote Agent's models. In addition, the Remote Agent's model-based diagnosis system automatically diagnoses when the RA models are not consistent with the behavior of the spacecraft. In flight, this feature is used to diagnose failures in the spacecraft hardware. During integration, it proved valuable in finding problems in the spacecraft simulator or flight software. In addition, when modifications are made to the spacecraft hardware or flight software, the RA models are easily changed because they only capture a description of the spacecraft. one does not have to maintain procedural code that implements the correct behavior for every expected situation. On the other hand, several features of the RA made it more difficult to integrate than typical flight software. For example, the definition of correct behavior is more difficult to specify for a system that is expected to reason about and flexibly react to its environment than for a traditional flight software system. Consequently, whenever a change is made to the RA it is more time consuming to determine if the resulting behavior is correct. We conclude the paper with a discussion of future work on the Remote Agent as well as recommendations to ease integration of similar autonomy projects.
This paper proposes an initial architecture for a Space Traffic Management (STM) system, based on openApplication Programming Interfaces (APIs) and drawing on previous work by the NASA Ames Research Center (ARC) to develop an architecture for low-altitude Unmanned Aerial System Traffic Management (UTM). The authors explore how autonomy could be used to enhance an STM system, and how constraints inherent in STM complicate and challenge certain applications of autonomy. We conceptually explore how autonomy could be used within an STM architecture, with multiple non-authoritative catalogs of resident space objects, and to determine which oftwo conjuncting spacecraft moves. NASA ARC is developing a software research environment for STM, along with a physical laboratory and visualization space. We invite STM stakeholders to collaborate in our infrastructure, to help inform the design of the proposed STM architecture, and to participate in the refinement and validation of its concept of operations using the software research platform.
NASA prioritizes autonomous systems development with the expectation that it will continue to drive significant improvements in human and science exploration capability. Crew operations benefit from a spectrum of machine assistance to complete replacement of dangerous or highly repetitive tasks. Many science operations have a teleoperation component, and similarly benefit from a range of autonomy implementations that make long distance applications feasible. As we consider longer duration deep space missions, we also consider higher levels of autonomy in order meet emergent safety, maintenance, and logistics needs. One of the challenges within this scope is installation and maintenance of infrastructure, such as large scale instrumentation and communications equipment, crew habitats, and operational facilities. We describe how a programmable meta-material architecture may shift the paradigm of how we design, build, and operate future space infrastructure and assets. A primary objective of this strategy is to free the design space from launch vehicle constraints and fundamentally shift how a mission is designed and conducted. This integrates advances in materials (mechanical meta-materials), manufacturing (cooperative mobile robotics), and autonomy (multi-agent planning algorithms). Engineering systems that utilize a modular and reconfiguration building block approach, such as digital communication and computation systems, currently lead in terms of size and complexity scalability. NASA is extending the benefits and flexibility of digital systems to hardware systems, to optimize materials life-cycle management and expand our space exploration mission capabilities to meet long duration and deep space infrastructure needs, in accordance with long term NASA goals of "in-space reliance" and "mass-less exploration."
NASA's Space Operations Management Office (SOMO) is working toward a goal of providing an integrated infrastructure of mission and data services for space missions undertaken by NASA enterprises. A significant portion of this effort is focused on reducing the cost of these services. We are interested in the potential of autonomy to reduce operations costs. Some attempts have already been made to apply autonomy and automation in these areas in the past with varying degrees of success. We present brief case histories and the lessons inferred from them. Combining this past experience with anticipated future needs, we attempt to clarify the challenges that must be met in order to realize the benefits of autonomy.
NASA's Space Operations Management Office (SOMO) is working toward a goal of providing an integrated infrastructure of mission and data services for space missions undertaken by NASA enterprises. A significant portion of this effort is focused on reducing the cost of these services. We are interested in the potential of autonomy to reduce operations costs. SOMO services support space missions, but are not part of the mission objectives; therefore the level of acceptable risk is very low. In fact, SOMO could be effective ly prevented from applying autonomy if customers merely perceive it as adding risk to their mission(s). We are interested in this workshop from the standpoint of understanding what can be done to realize the potential cost savings due to autonomy while maintaining acceptable risk and serving the needs of our customers. We would like to present our lessons learned so far in adopting autonomy and automation, which we think will contribute to clarifying the challenges facing the use of such technology. SOMO provides services to a diverse and ambitious set of mission customers. Many of these missions are groundbreaking missions for which communications, data, and other operations requirements sometimes cannot be clearly articulated early in the program. This motivates a need for systems that are robust in the face of unanticipated situations so that customer missions are not unreasonably constrained or impacted by "shortcomings" in SOMO services. One of SOMO's primary goals is to realize a paradigm in which SOMO acts as a service provider to organizations that fly space missions for NASA, other government agencies, and even the commercial sector. These organizations purchase SOMO services "by the pound" as customers. We have to provide systems that are not experiments themselves, but rather stable bases from which to do bold experiments. To this end, SOMO also seeks to work closely with industry to see that robust autonomy technology gets infused into products and services for the space industry and beyond. The potential for application of these technologies spans space-based communications networks (e.g. TDRSS) and ground-based assets including communication and tracking antenna systems, data networks, and control centers. There are several problems that are candidates for the application of autonomy, if it can be made reliable enough, including: antenna control, antenna scheduling, communication link scheduling and operation, navigation, attitude determination, fault detection, isolation, and reconfiguration (for spacecraft or ground assets), and mission-level planning and scheduling. Some attempts have been made to apply autonomy and automation in these areas in the past with varying degrees of success. We will present relevant case histories and the lessons inferred from them. Combining this past experience with anticipated future needs, we can clarify the challenges that must be met in order to realize the benefits of autonomy.
This report presents an informal survey of experts in the field of spacecraft automation, with recommendations for which technologies should be given the greatest development attention for implementation on the initial 1990's NASA Space Station. The recommendations implemented an autonomy philosophy that was developed by the Concept Development Group's Autonomy Working Group during 1983. They were based on assessments of the technologies' likely maturity by 1987, and of their impact on recurring costs, non-recurring costs, and productivity. The three technology areas recommended for programmatic emphasis were: (1) artificial intelligence expert (knowledge based) systems and processors; (2) fault tolerant computing; and (3) high order (procedure oriented) computer languages. This report also describes other elements required for Station autonomy, including technologies for later implementation, system evolvability, and management attitudes and goals. The cost impact of various technologies is treated qualitatively, and some cases in which both the recurring and nonrecurring costs might be reduced while the crew productivity is increased, are also considered. Strong programmatic emphasis on life cycle cost and productivity is recommended.
Explore the source record for details and available documents.
Current state of the art in Space Traffic Management (STM) relies on a handful of providers for surveillance and collision prediction, and manual coordination between operators. Neither is scalable to support the expected 10x increase in spacecraft population in less than 10 years, nor does it support automated manuever planning. We present a software prototype of an STM architecture based on open Application Programming Interfaces (APIs), drawing on previous work by NASA to develop an architecture for low-altitude Unmanned Aerial System Traffic Management. The STM architecture is designed to provide structure to the interactions between spacecraft operators, various regulatory bodies, and service suppliers, while maintaining flexibility of these interactions and the ability for new market participants to enter easily. Autonomy is an indispensable part of the proposed architecture in enabling efficient data sharing, coordination between STM participants and safe flight operations. Examples of autonomy within STM include syncing multiple non-authoritative catalogs of resident space objects, or determining which spacecraft maneuvers when preventing impending conjunctions between multiple spacecraft. The STM prototype is based on modern micro-service architecture adhering to OpenAPI standards and deployed in industry standard Docker containers, facilitating easy communication between different participants or services. The system architecture is designed to facilitate adding and replacing services with minimal disruption. We have implemented some example participant services (e.g. a space situational awareness provider/SSA, a conjunction assessment supplier/CAS, an automated maneuver advisor/AMA) within the prototype. Different services, with creative algorithms folded into then, can fulfil similar functional roles within the STM architecture by flexibly connecting to it using pre-defined APIs and data models, thereby lowering the barrier to entry of new players in the STM marketplace. We demonstrate the STM prototype on a multiple conjunction scenario with multiple maneuverable spacecraft, where an example CAS and AMA can recommend optimal maneuvers to the spacecraft operators, based on a predefined reward function. Such tools can intelligently search the space of potential collision avoidance maneuvers with varying parameters like lead time and propellant usage, optimize a customized reward function, and be implemented as a scheduling service within the STM architecture. The case study shows an example of autonomous maneuver planning is possible using the API-based framework. As satellite populations and predicted conjunctions increase, an STM architecture can facilitate seamless information exchange related to collision prediction and mitigation among various service applications on different platforms and servers. The availability of such an STM network also opens up new research topics on satellite maneuver planning, scheduling and negotiation across disjoint entities.
Rapid advances in automation has disrupted and transformed several industries in the past 25 years. Automation has evolved from regulation and control of simple systems like controlling the temperature in a room to the autonomous control of complex systems involving network of systems. The reason for automation varies from industry to industry depending on the complexity and benefits resulting from increased levels of automation. Automation may be needed to either reduce costs or deal with hazardous environment or make real-time decisions without the availability of humans. Space autonomy, Internet, robotic vehicles, intelligent systems, wireless networks and power systems provide successful examples of various levels of automation. NASA is conducting research in autonomy and developing plans to increase the levels of automation in aviation operations. This paper provides a brief review of levels of automation, previous efforts to increase levels of automation in aviation operations and current level of automation in the various tasks involved in aviation operations. It develops a methodology to assess the research and development in modeling, sensing and actuation needed to advance the level of automation and the benefits associated with higher levels of automation. Section II describes provides an overview of automation and previous attempts at automation in aviation. Section III provides the role of automation and lessons learned in Space Autonomy. Section IV describes the success of automation in Intelligent Transportation Systems. Section V provides a comparison between the development of automation in other areas and the needs of aviation. Section VI provides an approach to achieve increased automation in aviation operations based on the progress in other areas. The final paper will provide a detailed analysis of the benefits of increased automation for the Traffic Flow Management (TFM) function in aviation operations.
As we move towards human deep space missions, astronauts will no longer be able to say, Houston, we have a problem. The restricted contact with mission control because of the incredible distance from Earth will require astronauts to make autonomous decisions. How will astronauts take on the roles of mission control? This is an area of active research that has far reaching implications for the future of distant spaceflight. Come to this talk to hear how we are using design and user research to come up with innovative solutions for astronauts to effectively explore the Moon, Mars, and beyond.
Explore the source record for details and available documents.
The feasibility of onboard crew activity planning was examined. The use of expert systems technology to aid crewmembers in locating stowed equipment was also investigated. The crew activity planning problem, along with a summary of past and current research efforts, was discussed in detail. The requirements and specifications used to develop the crew activity planning system was also defined. The guidelines used to create, develop, and operate the MFIVE Crew Scheduler and Logistics Clerk were discussed. Also discussed is the mathematical algorithm, used by the MFIVE Scheduler, which was developed to aid in optimal crew activity planning.
NASA has long supported research on intelligent control technologies that could allow space systems to operate autonomously or with reduced human supervision. Proposed uses range from automated control of entire space vehicles to mobile robots that assist or substitute for astronauts to vehicle systems such as life support that interact with other systems in complex ways and require constant vigilance. The potential for pervasive use of such technology to extend the kinds of missions that are possible in practice is well understood, as is its potential to radically improve the robustness, safety and productivity of diverse mission systems. Despite its acknowledged potential, intelligent control capabilities are rarely used in space flight systems. Perhaps the most famous example of intelligent control on a spacecraft is the Remote Agent system flown on the Deep Space One mission (1998 - 2001). However, even in this case, the role of the intelligent control element, originally intended to have full control of the spacecraft for the duration of the mission, was reduced to having partial control for a two-week non-critical period. Even this level of mission acceptance was exceptional. In most cases, mission managers consider intelligent control systems an unacceptable source of risk and elect not to fly them. Overall, the technology is not trusted. From the standpoint of those who need to decide whether to incorporate this technology, lack of trust is easy to understand. Intelligent high-level control means allowing software io make decisions that are too complex for conventional software. The decision-making behavior of these systems is often hard to understand and inspect, and thus hard to evaluate. Moreover, such software is typically designed and implemented either as a research product or custom-built for a particular mission. In the former case, software quality is unlikely to be adequate for flight qualification and the functionality provided by the system is likely driven largely by the need to publish innovative work. In the latter case, the mission represents the first use of the system, a risky proposition even for relatively simple software.
Explore the source record for details and available documents.
We overview some of our recent work on highly autonomous mobile robots for planetary exploration.