SEARCH · Search NASA

Results for “Operational Autonomy”

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.

SourceResearch connectionFrom yearThrough year

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

At least 667 records · Page 37

All sources NASA NTRS DOE OSTI

NASA NTRS1988

Expert system for on-board satellite scheduling and control

An Expert System is described which Rockwell Satellite and Space Electronics Division (S&SED) is developing to dynamically schedule the allocation of on-board satellite resources and activities. This expert system is the Satellite Controller. The resources to be scheduled include power, propellant and recording tape. The activities controlled include scheduling satellite functions such as sensor checkout and operation. The scheduling of these resources and activities is presently a labor intensive and time consuming ground operations task. Developing a schedule requires extensive knowledge of the system and subsystems operations, operational constraints, and satellite design and configuration. This scheduling process requires highly trained experts anywhere from several hours to several weeks to accomplish. The process is done through brute force, that is examining cryptic mnemonic data off line to interpret the health and status of the satellite. Then schedules are formulated either as the result of practical operator experience or heuristics - that is rules of thumb. Orbital operations must become more productive in the future to reduce life cycle costs and decrease dependence on ground control. This reduction is required to increase autonomy and survivability of future systems. The design of future satellites require that the scheduling function be transferred from ground to on board systems.

Barry, John M.↗

NASA NTRSDate not supplied

Thinking outside the box: The human role in increasingly automated aviation systems

Rapid advances in artificial intelligence are enabling automated systems to operate in an increasingly autonomous manner in domains that previously required the involvement of human operators. Examples are rail transport systems, self-driving cars, and warehouse delivery systems. From time to time, such automation encounters operational conditions that fall outside a “competency box” within which the system has been designed to operate. Human operators add resilience because they can see and act outside the competency box of scenarios and environments for which the system was designed. The system’s competencies can be expanded over time with modifications to software, sensors, etc.; however, it is unclear at what point the competency box becomes large enough to safely eliminate the role of the human operator. One area where advanced automation may be applied is Urban Air Mobility (UAM). Current UAM concepts envision fleets of highly automated air vehicles providing on-demand transport for people and goods. A phased development of UAM has been proposed, beginning with on-board pilots and transitioning to a future state where automated vehicles operate with minimal human involvement. Proponents of UAM note that this final state reduces cost as well as eliminating pilot error, identified as a contributing factor in many aircraft accidents. However, eliminating human involvement also risks eliminating their positive contributions to system resilience. Here we examine Concepts of Operation proposed for future UAM systems and explore how humans can best be incorporated to maintain resilience while minimizing cost and risk. A human-autonomy teaming approach is suggested.

Advanced Air Mobility↗

NASA NTRSDate not supplied

Strategic and Tactical Functions in an Autonomous Air Traffic Management System

This paper evaluates, by means of fast-time simulation, performance of a candidate system for autonomous air traffic management. Advancing towards autonomy in air traffic management may be necessary in order for new air vehicle types such as electric Vertical Take Off and Landing (eVTOL) to operate safely and efficiently in airspace shared with conventional traffic. To account for uncertain prediction, autonomous air traffic management was divided into two integrated and coordinated subsystems: strategic scheduling, performed at predeparture, and tactical conflict detection and resolution, performed throughout the flight. The conflict detection and resolution subsystem contained a second tactical scheduling function that applied to flights operating in the airspace near the destination airport. This paper compares and contrasts the two subsystems and uses fast-time simulation to demonstrate the comparisons. A scenario of 54 flights inbound to Newark Liberty International Airport was simulated multiple times with different parameters. The scenario was created using flight plans recorded from the National Airspace System on a low weather, average traffic day in April 2018. Whereas the routes were not changed, the departure times of the flights were modified to increase arrival rates at the Newark runway and arrival meter fixes. Results of the simulations showed that the autonomous air traffic management system was able to safely manage the traffic, even with prediction uncertainty. In addition, they showed the importance of including flight holding maneuvers, in addition to path stretching, in conflict detection and resolution and of coordinating strategic and tactical scheduling. Finally, a tradeoff between absorbing the delay calculated by strategic scheduling on the ground versus in the air showed that taking most of the delay on the ground is cost effective for a simple idealized cost function. However, taking a little of the delay in the air prevented throughput on the runway from dropping for short periods due to trajectory prediction uncertainty.

air traffic control↗

NASA NTRS2021

Strategic and Tactical Functions in an Autonomous Air Traffic Management System

air traffic control↗

NASA NTRSDate not supplied

Flight Testing of In-Time Safety Assurance Technologies for UAS Operations

None.

safety management↗

NASA NTRS1991

Operational design factors for NASP derived vehicles

The factors that significantly affect the operability of aerospace planes are identified and considered in terms of the development of the National Aerospace Plane (NASP). The aircraftlike vehicle can be affected by variables related to the structure, propulsion, and mechanical elements of the design. The requirements to control the factors are listed including robustness, fuels and propellants, maintainability, autonomy, and development testing. The details of the requirements indicate critical factors such as the strength-to-weight ratios of the materials, propellant-system components that can withstand 5000 consecutive cycles, and low vehicle-failure probabilities. The NASP program is concluded to require: (1) models for quantitative operational assessments; (2) a modular design for the NASP structure; (3) computer-technology integration; and (4) technologies to support and normalize cryogenic operations.

Hickman, R. A.↗

NASA NTRS2017

Beyond Point Design: General Pattern to Specific Implementations

We have previously laid out a general framework for Human-Autonomy Teaming (HAT) and described how we applied this framework to a specific aeronautic task. In this presentation we demonstrate the applicability of these same principles to two familiar areas, photography and driving directions, focusing on bi-directional communication. We argue that good HAT requires communication of situation variables including operator goals and preferences and threats to meeting them, options including rationale, projected outcomes and confidence, and delegation.

human factors↗

NASA NTRS1995

Realization of Autonomous Image-Based Spacecraft Pointing Systems: Planetary Flyby Example

The paper summarizes efforts at JPL to develop an intelligent autonomous tracking and pointing system for space applications. A powerful 3D graphic software testbed has also been developed to simulate a likely scenario of autonomous tracking and pointing operations during a planetary flyby.

autonomous↗

NASA NTRS2007

Automated Rendezvous and Docking Sensor Testing at the Flight Robotics Laboratory

The Exploration Systems Architecture defines missions that require rendezvous, proximity operations, and docking (RPOD) of two spacecraft both in Low Earth Orbit (LEO) and in Low Lunar Orbit (LLO). Uncrewed spacecraft must perform automated and/or autonomous rendezvous, proximity operations and docking operations (commonly known as Automated Rendezvous and Docking, AR&D). The crewed versions may also perform AR&D, possibly with a different level of automation and/or autonomy, and must also provide the crew with relative navigation information for manual piloting. The capabilities of the RPOD sensors are critical to the success of the Exploration Program. NASA has the responsibility to determine whether the Crew Exploration Vehicle (CEV) contractor-proposed relative navigation sensor suite will meet the CEV requirements. The relatively low technology readiness of relative navigation sensors for AR&D has been carried as one of the CEV Projects top risks. The AR&D Sensor Technology Project seeks to reduce this risk by increasing technology maturation of selected relative navigation sensor technologies through testing and simulation, and to allow the CEV Project to assess the relative navigation sensors.

Mitchell, J.↗

NASA NTRS2008

Integrated Docking Simulation and Testing with the Johnson Space Center Six-Degree of Freedom Dynamic Test System

The Exploration Systems Architecture defines missions that require rendezvous, proximity operations, and docking (RPOD) of two spacecraft both in Low Earth Orbit (LEO) and in Low Lunar Orbit (LLO). Uncrewed spacecraft must perform automated and/or autonomous rendezvous, proximity operations and docking operations (commonly known as Automated Rendezvous and Docking, AR&D). The crewed versions may also perform AR&D, possibly with a different level of automation and/or autonomy, and must also provide the crew with relative navigation information for manual piloting. The capabilities of the RPOD sensors are critical to the success of the Constellation Program; this is carried as one of the CEV Project top risks. The Exploration Technology Development Program (ETDP) AR&D Sensor Technology Project seeks to reduce this risk by increasing technology maturation of selected relative navigation sensor technologies through testing and simulation. One of the project activities is a series of "pathfinder" testing and simulation activities to integrate relative navigation sensors with the Johnson Space Center Six-Degree-of-Freedom Test System (SDTS). The SDTS will be the primary testing location for the Orion spacecraft s Low Impact Docking System (LIDS). Project team members have integrated the Orion simulation with the SDTS computer system so that real-time closed loop testing can be performed with relative navigation sensors and the docking system in the loop during docking and undocking scenarios. Two relative navigation sensors are being used as part of a "pathfinder" activity in order to pave the way for future testing with the actual Orion sensors. This paper describes the test configuration and test results.

Mitchell, Jennifer D.↗

NASA NTRSDate not supplied

HAT m:N Activity Overview

Since 2020, researchers from the Human Autonomy Teaming (HAT) Laboratory at NASA Ames Research Center have conducted human-in-the-loop (HITL) simulation research to study a new control paradigm for operations involving multiple remotely piloted aircraft systems (RPAS). Colloquially referred to as "m:N," this paradigm is characterized by multiple operators collaboratively controlling multiple vehicles between them. The m:N name expresses a ratio whereby m is the number of operators and N is the number of vehicles shared between them. In this presentation, HAT Lab researchers provide a high-level overview of the m:N studies that have been performed to-date. These include a study of the m:N concept of operations (CONOPS) and the attending roles and responsibilities ("ConOps/R&R Sim"), a study focused on contingency management involving dynamic, inter-operator transfers of vehicles ("Handoff Sim"), and a study examining the effects of pilot-ATC communication systems on workload ("UAM Comms Sim"). A selection of key results are provided. The presentation concludes with a brief discussion of planned research into m:N operations.

m:N↗

NASA NTRS1989

Multi-level manual and autonomous control superposition for intelligent telerobot

Space telerobots are recognized to require cooperation with human operators in various ways. Multi-level manual and autonomous control superposition in telerobot task execution is described. The object model, the structured master-slave manipulation system, and the motion understanding system are proposed to realize the concept. The object model offers interfaces for task level and object level human intervention. The structured master-slave manipulation system offers interfaces for motion level human intervention. The motion understanding system maintains the consistency of the knowledge through all the levels which supports the robot autonomy while accepting the human intervention. The superposing execution of the teleoperational task at multi-levels realizes intuitive and robust task execution for wide variety of objects and in changeful environment. The performance of several examples of operating chemical apparatuses is shown.

Hirai, Shigeoki↗

NASA NTRS2002

Systems Architecture for Fully Autonomous Space Missions

The NASA Goddard Space Flight Center is working to develop a revolutionary new system architecture concept in support of fully autonomous missions. As part of GSFC's contribution to the New Millenium Program (NMP) Space Technology 7 Autonomy and on-Board Processing (ST7-A) Concept Definition Study, the system incorporates the latest commercial Internet and software development ideas and extends them into NASA ground and space segment architectures. The unique challenges facing the exploration of remote and inaccessible locales and the need to incorporate corresponding autonomy technologies within reasonable cost necessitate the re-thinking of traditional mission architectures. A measure of the resiliency of this architecture in its application to a broad range of future autonomy missions will depend on its effectiveness in leveraging from commercial tools developed for the personal computer and Internet markets. Specialized test stations and supporting software come to past as spacecraft take advantage of the extensive tools and research investments of billion-dollar commercial ventures. The projected improvements of the Internet and supporting infrastructure go hand-in-hand with market pressures that provide continuity in research. By taking advantage of consumer-oriented methods and processes, space-flight missions will continue to leverage on investments tailored to provide better services at reduced cost. The application of ground and space segment architectures each based on Local Area Networks (LAN), the use of personal computer-based operating systems, and the execution of activities and operations through a Wide Area Network (Internet) enable a revolution in spacecraft mission formulation, implementation, and flight operations. Hardware and software design, development, integration, test, and flight operations are all tied-in closely to a common thread that enables the smooth transitioning between program phases. The application of commercial software development techniques lays the foundation for delivery of product-oriented flight software modules and models. Software can then be readily applied to support the on-board autonomy required for mission self-management. An on-board intelligent system, based on advanced scripting languages, facilitates the mission autonomy required to offload ground system resources, and enables the spacecraft to manage itself safely through an efficient and effective process of reactive planning, science data acquisition, synthesis, and transmission to the ground. Autonomous ground systems in turn coordinate and support schedule contact times with the spacecraft. Specific autonomy software modules on-board include mission and science planners, instrument and subsystem control, and fault tolerance response software, all residing within a distributed computing environment supported through the flight LAN. Autonomy also requires the minimization of human intervention between users on the ground and the spacecraft, and hence calls for the elimination of the traditional operations control center as a funnel for data manipulation. Basic goal-oriented commands are sent directly from the user to the spacecraft through a distributed internet-based payload operations "center". The ensuing architecture calls for the use of spacecraft as point extensions on the Internet. This paper will detail the system architecture implementation chosen to enable cost-effective autonomous missions with applicability to a broad range of conditions. It will define the structure needed for implementation of such missions, including software and hardware infrastructures. The overall architecture is then laid out as a common thread in the mission life cycle from formulation through implementation and flight operations.

Esper, Jamie↗

NASA NTRS1998

Rovers for Mars Polar Exploration

Mobility is a generic capability needed for Mars exploration. Requirements for mobility range from those to get observations of individual rocks all the way to getting high resolution observations of regional areas. Table 1 shows the required-range of mobility to achieve various tasks. The Pathfinder mission and field experiments simulating rover missions [1, 2, 3, 4, 5] provide guidance as to rover capabilities that can reasonably be expected in the next decade. Rover mobility can be accomplished in a variety of ways, the most common being wheels or tracks and legged-walkers. Wheeled vehicles can traverse over rocks smaller than 1/2 wheel diameter, and with path planning to avoid larger rocks, can traverse terrains comparable to those seen on Mars in the Viking and Pathfinder landing sites. Slopes of 45 deg can be easily negotiated by wheeled rovers. Walking vehicles can negotiate even more complex terrain but requires computation capability to select each leg placement. Extremely complex terrain was traversed by the Nomad II walker which descended into (and most of the way out of) an active volcanic caldera (Mount Spur, AK) in 1995, although a slope failure eventually resulted in broken legs. The traverse range of a rover is limited by its science objectives, performance capabilities, and operational lifetime. The speed of rover traverse is a relative minor factor. With a different communication system, and no stops for science experiments, Sojourner could probably have traveled a kilometer. But, achieving land speed records is not a major objective of a science mission. Achieving science objectives requires targeting particular objects and studying them in detail, and the associated operational requirements will likely limit rover traverse range significantly. Traversing from target to target requires relatively few command cycles provided the traverse is over a short enough distance that it can be adequately planned. An operational goal of 100 m traverse per command cycle, arriving at a predetermined target, seems achievable. Investigating science targets requiring manipulator or instrument placement and sample collection will likely take several command cycles per target. Mission simulations [6] have demonstrated that traverse dI stances of 100-300 m, with detailed investigation of 5-10 targets take 50-100 command cycles, not unlike the Pathfinder experience in spite of the use of larger, faster, more capable rovers. Significant advances in rover autonomy will be needed to improve this Situation and it is not clear how much improvement will be brought to flight programs in the next decade. Dust accumulation on solar panels degrades power over time and, without dust removal, rover operational lifetimes may be limited to 90 sols.

Stoker, Carol↗

NASA NTRS2000

Autonomy Architectures for a Constellation of Spacecraft

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.

Barrett, Anthony↗

NASA NTRS2016

Intelligent (Autonomous) Power Controller Development for Human Deep Space Exploration

As NASAs Evolvable Mars Campaign and other exploration initiatives continue to mature they have identified the need for more autonomous operations of the power system. For current human space operations such as the International Space Station, the paradigm is to perform the planning, operation and fault diagnosis from the ground. However, the dual problems of communication lag as well as limited communication bandwidth beyond GEO synchronous orbit, underscore the need to change the operation methodology for human operation in deep space. To address this need, for the past several years the Glenn Research Center has had an effort to develop an autonomous power controller for human deep space vehicles. This presentation discusses the present roadmap for deep space exploration along with a description of conceptual power system architecture for exploration modules. It then contrasts the present ground centric control and management architecture with limited autonomy on-board the spacecraft with an advanced autonomous power control system that features ground based monitoring with a spacecraft mission manager with autonomous control of all core systems, including power. It then presents a functional breakdown of the autonomous power control system and examines its operation in both normal and fault modes. Finally, it discusses progress made in the development of a real-time power system model and how it is being used to evaluate the performance of the controller and well as using it for verification of the overall operation.

Power Systems↗

NASA NTRSDate not supplied

The Role of Trust and Usability in Enabling Spaceflight Crew Autonomy

Future long duration exploration missions will require an increased use of onboard automated systems as spaceflight crews venture further than before and have longer communications delays with ground support. The design of these systems must support appropriate crew trust and have sufficient usability to enable spaceflight crew autonomy or risk being misused while crews wait to communicate with ground support. We evaluated trust & usability in our self-scheduling tool, Playbook, for crew mission timelines. Data was collected in a controlled lab experiment with 31 participants. Participants in the study conducted two tasks: scheduling, where participants were responsible for scheduling a majority of a day's operational tasks, and rescheduling, where participants were provided a schedule and asked to reschedule higher priority activities. We found a significant correlation between system trust and usability, irrespective of self-scheduling tasks. We conclude that system usability may play a bigger role in how trust is learned while conducting novel crew autonomy tasks such as self-scheduling. Future research should investigate the role of usability to encourage appropriate trust in onboard automated crew systems and enable crew autonomy.

crew autonomy↗

NASA NTRS2006

Flying the ST-5 Constellation with "Plug and Play" Autonomy Components and the GMSEC Bus

The Space Technology 5 (ST5) Project, part of NASA's New Millennium Program, will consist of a constellation of three micro-satellites. This viewgraph document presents the components that will allow it to operate in an autonomous mode. The ST-5 constellation will use the GSFC Mission Services Evolution Center (GMSEC) architecture to enable cost effective model based operations. The ST-5 mission will demonstrate several principles of self managing software components.

Shendock, Bob↗