Search NASA⌕ Search

SEARCH · Search NASA

Results for “human autonomy teaming”

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.

At least 163 records · Page 9

UAV Research at NASA Langley: Towards Safe, Reliable, and Autonomous Operations

Unmanned Aerial Vehicles (UAV) are fundamental components in several aspects of research at NASA Langley, such as flight dynamics, mission-driven airframe design, airspace integration demonstrations, atmospheric science projects, and more. In particular, NASA Langley Research Center (Langley) is using UAVs to develop and demonstrate innovative capabilities that meet the autonomy and robotics challenges that are anticipated in science, space exploration, and aeronautics. These capabilities will enable new NASA missions such as asteroid rendezvous and retrieval (ARRM), Mars exploration, in-situ resource utilization (ISRU), pollution measurements in historically inaccessible areas, and the integration of UAVs into our everyday lives all missions of increasing complexity, distance, pace, and/or accessibility. Building on decades of NASA experience and success in the design, fabrication, and integration of robust and reliable automated systems for space and aeronautics, Langley Autonomy Incubator seeks to bridge the gap between automation and autonomy by enabling safe autonomous operations via onboard sensing and perception systems in both data-rich and data-deprived environments. The Autonomy Incubator is focused on the challenge of mobility and manipulation in dynamic and unstructured environments by integrating technologies such as computer vision, visual odometry, real-time mapping, path planning, object detection and avoidance, object classification, adaptive control, sensor fusion, machine learning, and natural human-machine teaming. These technologies are implemented in an architectural framework developed in-house for easy integration and interoperability of cutting-edge hardware and software.

Davila, Carlos G.↗

Crew Health and Performance Integrated Data Architecture (CHP-IDA) Project

BACKGROUND: Future Human Exploration missions introduce a new paradigm as crews move further from the resupply and near real-time ground support typical of Low Earth Orbit missions today. Without immediate support from ground-based personnel, exploration crews will be more reliant on inflight data and technology to respond to emergencies and anomalies. A data architecture to support a new generation of technologies, employing advanced analytical and predictive modeling techniques, is needed to enable crew autonomy. OVERVIEW: The Crew Health and Performance Integrated Data Architecture (CHP-IDA) project funded by NASA’s Exploration Medical Integrated Product Team (XMIPT) is laying a foundation for future in-flight informatics by providing a back-end architecture for collecting, storing, and integrating multiple sources of data generated by and around the crew. CHP-IDA provides a platform for common data models and Application Programming Interfaces to access, integrate, process, and display CHP data (e.g., environmental, exercise, medical, sleep, performance, etc.). This will facilitate the increased situation awareness and decision support required by the crew and remote support of exploration missions. This presentation will describe the currently ongoing effort to develop and evaluate a path-to-flight concept of the CHP-IDA software and its core capabilities. Current integrations will be discussed, including analytics for Extravehicular Activity metabolic rate and data ingestion from a multi-functional integrated medical device. The presentation will also provide examples of scenarios used to demonstrate the CHP-IDA through human-in-the-loop test bed activities as well as examples of appropriate system performance metrics. DISCUSSION: Today, in-flight data is often siloed, unsynchronized, and largely inaccessible in real time. Many data sets require manual entry and/or data transfer between vehicles and the ground. These issues contribute to risks in supporting exploration medical capabilities. The CHP-IDA is a back-end data system providing core capabilities needed for timely and meaningful data insights across CHP domains to crew and remote personnel to enable increased crew autonomy. Future work includes collaboration with additional CHP domains, new technology integrations, and further demonstrations of the IDA within different vehicle and communication latency contexts. LEARNING OBJECTIVES 1. The audience will understand that the CHP-IDA is a back-end system, providing a platform to facilitate access, promote decision tools, and provide meaningful insights to crew and to remote stakeholders during exploration missions. 2. The audience will gain insight into human-centered research and activities used to discover CHP domain data needs and pain points and how this information is used to guide development of the IDA.

Exploration↗

Collaborating with Autonomous Agents

With the anticipated increase of small unmanned aircraft systems (sUAS) entering into the National Airspace System, it is highly likely that vehicle operators will be teaming with fleets of small autonomous vehicles. The small vehicles may consist of sUAS, which are 55 pounds or less that typically will y at altitudes 400 feet and below, and small ground vehicles typically operating in buildings or defined small campuses. Typically, the vehicle operators are not concerned with manual control of the vehicle; instead they are concerned with the overall mission. In order for this vision of high-level mission operators working with fleets of vehicles to come to fruition, many human factors related challenges must be investigated and solved. First, the interface between the human operator and the autonomous agent must be at a level that the operator needs and the agents can understand. This paper details the natural language human factors e orts that NASA Langley's Autonomy Incubator is focusing on. In particular these e orts focus on allowing the operator to interact with the system using speech and gestures rather than a mouse and keyboard. With this ability of the system to understand both speech and gestures, operators not familiar with the vehicle dynamics will be able to easily plan, initiate, and change missions using a language familiar to them rather than having to learn and converse in the vehicle's language. This will foster better teaming between the operator and the autonomous agent which will help lower workload, increase situation awareness, and improve performance of the system as a whole.

Trujillo, Anna C.↗

Human Mars Surface Science Operations

Human missions to the surface of Mars will have challenging science operations. This paper will explore some of those challenges, based on science operations considerations as part of more general operational concepts being developed by NASA's Human Spaceflight Architecture (HAT) Mars Destination Operations Team (DOT). The HAT Mars DOT has been developing comprehensive surface operations concepts with an initial emphasis on a multi-phased mission that includes a 500-day surface stay. This paper will address crew science activities, operational details and potential architectural and system implications in the areas of (a) traverse planning and execution, (b) sample acquisition and sample handling, (c) in-situ science analysis, and (d) planetary protection. Three cross-cutting themes will also be explored in this paper: (a) contamination control, (b) low-latency telerobotic science, and (c) crew autonomy. The present traverses under consideration are based on the report, Planning for the Scientific Exploration of Mars by Humans1, by the Mars Exploration Planning and Analysis Group (MEPAG) Human Exploration of Mars-Science Analysis Group (HEM-SAG). The traverses are ambitious and the role of science in those traverses is a key component that will be discussed in this paper. The process of obtaining, handling, and analyzing samples will be an important part of ensuring acceptable science return. Meeting planetary protection protocols will be a key challenge and this paper will explore operational strategies and system designs to meet the challenges of planetary protection, particularly with respect to the exploration of "special regions." A significant challenge for Mars surface science operations with crew is preserving science sample integrity in what will likely be an uncertain environment. Crewed mission surface assets -- such as habitats, spacesuits, and pressurized rovers -- could be a significant source of contamination due to venting, out-gassing and cleanliness levels associated with crew presence. Low-latency telerobotic science operations has the potential to address a number of contamination control and planetary protection issues and will be explored in this paper. Crew autonomy is another key cross-cutting challenge regarding Mars surface science operations, because the communications delay between earth and Mars could as high as 20 minutes one way, likely requiring the crew to perform many science tasks without direct timely intervention from ground support on earth. Striking the operational balance between crew autonomy and earth support will be a key challenge that this paper will address.

Bobskill, Marianne R.↗

Driving Curiosity: Mars Rover Mobility Trends During the First Seven Years

NASA’s Mars Science Laboratory (MSL) mission landed the Curiosity rover on Mars on August 6, 2012. As of August 6, 2019 (sol 2488), Curiosity has driven 21,318.5 meters over a variety of terrain types and slopes, employing multiple drive modes with varying amounts of onboard autonomy. Curiosity’s drive distances each sol have ranged from its shortest drive of 2.6 centimeters to its longest drive of 142.5 meters, with an average drive distance of 28.9 meters. Real-time human intervention during Curiosity drives on Mars is not possible due to the latency in uplinking commands and downlinking telemetry, so the operations team relies on the rover’s flight software to prevent an unsafe state during driving. Over the first seven years of the mission, Curiosity has attempted 738 drives. While 622 drives have completed successfully, 116 drives were prevented or stopped early by the rover’s fault protection software. The primary risks to mobility success have been wheel wear, wheel entrapment, progressive wheel sinkage (which can lead to rover embedding), and terrain interactions or hardware or cabling failures that result in an inability to command one or more steer or drive actuators. In this paper, we describe mobility trends over the first 21.3km of the mission, operational aspects of the mobility fault protection, and risk mitigation strategies that will support continued mobility success for the remainder of the mission.

Rankin, Arturo↗

Gateway Implementation of Cybersecurity Requirements

Cybersecurity threats are a constant present-day reality for any type of business -- Space exploration is not excluded from these threats either. The Gateway Program is one of NASA’s latest initiatives that extend space exploration beyond low earth orbit. Gateway allows for NASA to prove technologies and mature systems necessary to live and work on another celestial body before embarking on multi-year missions to Mars. The Gateway is a small, human-tended space station in orbit around the Moon. With the increased autonomy, distance and criticality of systems, cybersecurity is a critical discipline that touches and integrates with most if not all subsystems of the Gateway. Building a gateway to the lunar orbit is no simple task. In this presentation, we outline an approach that the Gateway team adopted in creating a cyber safe and robust vehicle to support operations and assure protection of the critical functions. Gateway Program is required to implement National Institute of Standards and Technology (NIST) guidelines to adhere to the Federal Information Security Modernization Act (FISMA). NIST provides a framework for managing and controlling cybersecurity risks by defining cybersecurity controls and methodologies for implementation. The NIST framework is based upon the system, data within the system, integrations with external systems, and risk assessments to determine impacts for each of those systems. The goals and objectives are to identify appropriate security controls that fulfil and map to the NIST 800-53 framework. The implementation process involves developing an organizational understanding to manage cybersecurity risk to systems, people, assets, data, and capabilities. NIST Security controls are interpreted and defined within the Gateway vehicle requirements subsystems specifications. This paper details the approach, implementation, and challenges faced during the development and design phases to address cyber threats during the Gateway vehicle operations.

Cybersecurity↗

Experimental Evaluation of Verification and Validation Tools on Martian Rover Software

To achieve its science objectives in deep space exploration, NASA has a need for science platform vehicles to autonomously make control decisions in a time frame that excludes intervention from Earth-based controllers. Round-trip light-time is one significant factor motivating autonomy capability, another factor is the need to reduce ground support operations cost. An unsolved problem potentially impeding the adoption of autonomy capability is the verification and validation of such software systems, which exhibit far more behaviors (and hence distinct execution paths in the software) than is typical in current deepspace platforms. Hence the need for a study to benchmark advanced Verification and Validation (V&V) tools on representative autonomy software. The objective of the study was to access the maturity of different technologies, to provide data indicative of potential synergies between them, and to identify gaps in the technologies with respect to the challenge of autonomy V&V. The study consisted of two parts: first, a set of relatively independent case studies of different tools on the same autonomy code, second a carefully controlled experiment with human participants on a subset of these technologies. This paper describes the second part of the study. Overall, nearly four hundred hours of data on human use of three different advanced V&V tools were accumulated, with a control group that used conventional testing methods. The experiment simulated four independent V&V teams debugging three successive versions of an executive controller for a Martian Rover. Defects were carefully seeded into the three versions based on a profile of defects from CVS logs that occurred in the actual development of the executive controller. The rest of the document is structured a s follows. In section 2 and 3, we respectively describe the tools used in the study and the rover software that was analyzed. In section 4 the methodology for the experiment is described; this includes the code preparation, seeding of defects, participant training and experimental setup. Next we give a qualitative overview of how the experiment went from the point of view of each technology; model checking (section 5), static analysis (section 6), runtime analysis (section 7) and testing (section 8). The find section gives some preliminary quantitative results on how the tools compared.

Brat, Guillaume↗

Streamlining GNC Architecture Development and FSW Integration forthe Mars Ascent Vehicle

The Mars Ascent Vehicle (MAV) will be the first vehicle to perform an ascent from the surface ofanother atmospheric planetary body outside of the Earth-Moon system. Significant light-time delayrequires complete autonomy of flight throughout ascent, and naturally a high level of reliability isdesired in both MAV’s hardware and software subsystems. The MAV Guidance, Navigation and Controls(GNC) team and the MAV Flight Software (FSW) team have partnered together to improve the efficiencyof algorithm integration onto the MAV flight processor, and to increase confidence that said integrationis successful and without human error. An interface architecture is proposed for the GNC suite thatallows both the guidance and navigation subsystems to provide code algorithms directly in C++, and thecontrols subsystem to provide MATLAB Simulink auto-coded algorithms. Several continuous integration/deployment (CI/CD) methodologies have been considered for ease of transition of algorithm code fromthe GNC team to the FSW team. The GNC/FSW teams also worked together to develop a cFS-friendlywrapper which abstracts the integration of the GNC algorithm code into an interface-level API that iscompatible with cFS. Several iterations of vehicle GNC code have been produced between the GNC/FSWteam’s partnership, and this strong interface between these two teams have allowed the GNC/FSWteams to greatly increase confidence of efficient and error-free implementation of the GNC code ontoMAV for a successful flight.

GNC↗

Gateway Implementation of Cybersecurity Requirements

Cyber threats are a constant present-day reality for any type of business -- Space exploration is not excluded from these threats either. The Gateway Program is one of NASA’s latest initiatives that extend space exploration beyond low earth orbit. Gateway allows for NASA to prove technologies and mature systems necessary to live and work on another celestial body before embarking on multi-year missions to Mars. The Gateway is a small, human-tended space station in orbit around the Moon. With the increased autonomy, distance and criticality of systems, cybersecurity is one of the critical subsystems that touches and integrates with most if not all subsystems of the Gateway. Building a gateway to the lunar orbit is no simple task. In this presentation, we outline an approach that the Gateway team adopted in creating a cyber safe and robust vehicle to support operations and assure protection of the critical functions. Gateway Program is required to implement National Institute of Standards and Technology (NIST) guidelines to adhere to the Federal Information Security Modernization Act (FISMA). NIST provides a framework for managing and controlling cybersecurity risks by defining cybersecurity controls and methodologies for implementation. The NIST framework is based upon the system, data within the system, integrations with external systems, and risk assessments to determine impacts for each of those systems. The goals and objectives are to identify appropriate security controls that fulfill and map to the NIST 800-53 framework. The implementation process involves developing an organizational understanding to manage cybersecurity risk to systems, people, assets, data, and capabilities. NIST Security controls are interpreted and defined within the Gateway vehicle requirements subsystems specifications. This paper details the approach, implementation, and challenges faced during the development and design phases to address cyber threats during the Gateway vehicle operations.

Svetlana Hanson↗

Software Engineering for Human Spaceflight

The Spacecraft Software Engineering Branch of NASA Johnson Space Center (JSC) provides world‐class products, leadership, and technical expertise in software engineering, processes, technology, and systems management for human spaceflight. The branch contributes to major NASA programs (e.g. ISS, MPCV/Orion) with in‐house software development and prime contractor oversight, and maintains the JSC Engineering Directorate CMMI rating for flight software development. Software engineering teams work with hardware developers, mission planners, and system operators to integrate flight vehicles, habitats, robotics, and other spacecraft elements. They seek to infuse automation and autonomy into missions, and apply new technologies to flight processor and computational architectures. This presentation will provide an overview of key software‐related projects, software methodologies and tools, and technology pursuits of interest to the JSC Spacecraft Software Engineering Branch.

Fredrickson, Steven E.↗

Streamlining GNC Architecture Development and FSW Integration for the Mars Ascent Vehicle

The Mars Ascent Vehicle (MAV) will be the first vehicle to perform an ascent from the surface of another atmospheric planetary body outside of the Earth-Moon system. Significant light-time delay requires complete autonomy of flight throughout ascent, and naturally a high level of reliability is desired in both MAV’s hardware and software subsystems. The MAV Guidance, Navigation and Controls (GNC) team and the MAV Flight Software (FSW) team have partnered together to improve the efficiency of algorithm integration onto the MAV flight processor, and to increase confidence that said integration is successful and without human error. An interface architecture is proposed for the GNC suite that allows both the guidance and navigation subsystems to provide code algorithms directly in C++, and the controls subsystem to provide MATLAB Simulink auto-coded algorithms. Several continuous integration/deployment (CI/CD) methodologies have been considered for ease of transition of algorithm code from the GNC team to the FSW team. The GNC/FSW teams also worked together to develop a cFS-friendly wrapper which abstracts the integration of the GNC algorithm code into an interface-level API that is compatible with cFS. Several iterations of vehicle GNC code have been produced between the GNC/FSW team’s partnership, and this strong interface between these two teams have allowed the GNC/FSW teams to greatly increase confidence of efficient and error-free implementation of the GNC code onto MAV for a successful flight.

Engineering↗

Mars Ascent Vehicle GNC Targeting Routines with Considerations for Flight Software Development

The Mars Ascent Vehicle (MAV) will be the first vehicle to perform an ascent from the surface of another atmospheric planetary body outside of the Earth-Moon system. Significant light-time delay requires complete autonomy of flight throughout ascent, and naturally a high level of reliability is desired in both MAV’s hardware and software subsystems. The MAV Guidance, Navigation and Controls (GNC) team and the MAV Flight Software (FSW) team have partnered together to improve the efficiency of algorithm integration onto the MAV flight processor, and to increase confidence that said integration is successful and without human error. An interface architecture is proposed for the GNC suite that allows both the guidance and navigation subsystems to provide code algorithms directly in C++, and the controls subsystem to provide MATLAB Simulink auto-coded algorithms. Several continuous integration/deployment (CI/CD) methodologies have been considered for ease of transition of algorithm code from the GNC team to the FSW team. The GNC/FSW teams also worked together to develop a cFS-friendly wrapper which abstracts the integration of the GNC algorithm code into an interface-level API that is compatible with cFS. Several iterations of vehicle GNC code have been produced between the GNC/FSW team’s partnership, and this strong interface between these two teams have allowed the GNC/FSW teams to greatly increase confidence of efficient and error-free implementation of the GNC code onto MAV for a successful flight.

Jason Everett↗

Exploration Technologies for Operations

Although the International Space Station (ISS) assembly has been completed, the Operations support teams continue to seek more efficient and effective ways to prepare for and conduct the ISS operations and future exploration missions beyond low earth orbit. This search for improvement has led to a significant collaboration between the NASA research and advanced software development community at NASA Ames Research Center and the Mission Operations community at NASA Johnson Space Center. Since 2001, NASA Ames Research Center has been developing and applying its advanced intelligent systems and human systems integration research to mission operations tools for several of the unmanned Mars missions operations. Since 2006, NASA Ames Research Center has also been developing and applying its advanced intelligent systems and human systems integration research to mission operations tools for manned operations support with the Mission Operations Directorate at NASA Johnson Space Center. This paper discusses the completion of the development and deployment of a variety of intelligent and human systems technologies adopted for manned mission operations. The technologies associated with the projects include advanced software systems for operations and human-centered computing. Human-centered computing looks to the processes and procedures that people do to perform any given job, then attempts to identify opportunities to improve these processes and procedures. In particular, for mission operations, improvements are quantified by specifically identifying how a tool can increase a persons efficiency, enhance a persons functional capability, andor improve the assurance of a persons decisions. The Ames development team has collaborated with the Mission Operations team to identify areas of efficiencies through technology infusion applications in support of the Plan, Train, and Fly activities of human-spaceflight mission operations. The specific applications discussed in this paper are in the areas of mission planning systems, mission operations design modeling and workflow automation, advanced systems monitoring, mission control technologies, search tools, training management tools, spacecraft solar array management, spacecraft power management, and spacecraft attitude planning. We discuss these specific projects between the Ames Research Center and the Johnson Space Centers Mission Operations Directorate, and how these technologies and projects are enhancing the mission operations support for the International Space Station. We also discuss the challenges, problems, and successes associated with long-distance and multi-year development projects between the research team at Ames and the Mission Operations customers at Johnson Space center. Finally, we discuss how these technology infusion applications and underlying technologies might be used in the future to support on-board operations of the crew and spacecraft systems as human exploration expands beyond low earth orbit to destinations in the solar system where communications delays will require more on-board autonomy and planning by the crew. Longer communications delays will require that the ground mission operations support will be primarily strategic in nature, while the tactical level of planning, systems monitoring and control, and failure analysisisolationrecovery will be the responsibility of both the spacecraft autonomous systems and the crew. Our expectation is that the technologies

mission operations↗

Autonomous Mission Operations Roadmap

As light time delays increase, the number of such situations in which crew autonomy is the best way to conduct the mission is expected to increase. However, there are significant open questions regarding which functions to allocate to ground and crew as the time delays increase. In situations where the ideal solution is to allocate responsibility to the crew and the vehicle, a second question arises: should the activity be the responsibility of the crew or an automated vehicle function? More specifically, we must answer the following questions: What aspects of mission operation responsibilities (Plan, Train, Fly) should be allocated to ground based or vehicle based planning, monitoring, and control in the presence of significant light-time delay between the vehicle and the Earth?How should the allocated ground based planning, monitoring, and control be distributed across the flight control team and ground system automation? How should the allocated vehicle based planning, monitoring, and control be distributed between the flight crew and onboard system automation?When during the mission should responsibility shift from flight control team to crew or from crew to vehicle, and what should the process of shifting responsibility be as the mission progresses? NASA is developing a roadmap of capabilities for Autonomous Mission Operations for human spaceflight. This presentation will describe the current state of development of this roadmap, with specific attention to in-space inspection tasks that crews might perform with minimum assistance from the ground.

Mission Operations↗

Creating an Interface to view Multi-Spacecraft Swarm Telemetry

Distributed Spacecraft Systems are a type of multi-spacecraft mission architecture that can not only provide improved resolution, coverage, and availability of existing missions, but also enable missions that would be previously infeasible using traditional approaches. Distributed Spacecraft Autonomy (DSA) is a project developed by the National Aeronautics and Space Administration that enables distributed spacecraft systems. In previous science swarm missions, the spacecraft involved have not been able to communicate with each other without utilizing a ground station. Now that the spacecraft can perform inter-satellite communication, the spacecraft can be treated as a collective. Swarm autonomy is critical for a growing number of satellites which means novel ways of displaying swarm data needs to be implemented. Such systems introduce unique challenges to traditional approaches for command and control of these spacecraft, due to the large number of spacecraft and the complexity of the interactions between them. The ground data system for DSA addresses these challenges through the creation of a custom user interface that allows a single operator to orchestrate a multi-spacecraft swarm in a scalable way. This plenary describes the details of the autonomy demonstration being performed, the requirements of those using the interface to analyze the spacecraft telemetry to assess demonstration success, and the approach taken by the ground systems team to create an interface that satisfies these requirements. This approach involves the creation of several distinct components that correspond to the level of detail presented to the user. These components are based on conventional user roles in human-robot interaction, including supervisor, operator, and mechanic, extended to accommodate the additional overhead of coordinating actions between agents. One main feature of the interface is the listenability matrix component which will represent inter-satellite communications in a heat mapped matrix. The above work described will enable users to command and interact with the spacecraft as a collective.

human-swarm interaction↗

Human Factors in Training

Future space missions will be significantly longer than current Shuttle missions and new systems will be more complex than current systems. Increasing communication delays between crews and Earth-based support means that astronauts need to be prepared to handle the unexpected on their own. As crews become more autonomous, their potential span of control and required expertise must grow to match their autonomy. It is not possible to train for every eventuality ahead of time on the ground, or to maintain trained skills across long intervals of disuse. To adequately prepare NASA personnel for these challenges, new training approaches, methodologies, and tools are required. This research project aims at developing these training capabilities. Training efforts in FY07 strongly focused on crew medical training, but also began exploring how Space Flight Resource Management training for Mission Operations Directorate (MOD) Flight Controllers could be integrated with systems training for optimal Mission Control Center operations. Beginning in January 2008, the training research effort will include team training prototypes and tools. The Training Task addresses Program risks that lie at the intersection of the following three risks identified by the Project: 1) Risk associated with poor task design; 2) Risk of error due to inadequate information; 3) Risk associated with reduced safety and efficiency due to poor human factors design.

Barshi, Immanuel↗

On the Moral Hazard of Autonomy

This paper describes the concept of moral hazard as applied to technologies that incorporate automation and autonomy. Moral hazard is said to exist when a party to a transaction feels more comfortable taking undue risks because another party will bear the costs if things go badly. As opposed to regular physical hazards, a moral hazard comes from within a person. In this paper, we reveal two categories of moral hazards related to autonomy. The first category of moral hazard occurs when the owner of the autonomy introduces an autonomous system without accepting the full responsibility for improper operation thereby shifting the risks from one party to another party. This category of moral hazard is similar to moral hazards experienced in other industries and can often be addressed through appropriate policy and establishing liability for irresponsible behavior. The issue becomes more complicated in cases where the operator of the autonomy may not have a full understanding of the system behavior. In the second category of moral hazard, risks are shifted from people to autonomy. In this category, the humans in proximity to the autonomous system begin to trust its behavior. Their behavior may change in that they may believe they are more insulated from harm and subsequently exhibit more risky behavior towards increasingly autonomous technologies. Mitigating this type of moral hazard may require the autonomy to possess certain design features to discourage this type of harmful human behavior so that humans do not suffer needlessly in their interactions with autonomous systems by placing inappropriate trust where that trust is neither warranted nor deserved.

Cybernetics↗

Mars Exploration Rover Mission

Two rovers with a sophisticated geological payload have been operating on the surface of Mars since January of 2004. Future missions and their related technology developments will benefit from the lessons learned during these surface operations. The planning cycle was dictated by the communications opportunities and the times of day that the rovers could operate, and the team and tools were tuned to optimize the mission return for that cycle time. The ability to traverse and to approach and perform in situ investigations on targets was limited in speed by the same cycle time, due to required human involvement in the related planning and risk decisions. In addition traverse was limited by the speed of the on-board terrain and hazard assessment, and in situ operations were limited by a lack of autonomy. Different planning cycles and levels of autonomy should be considered for future surface missions, which will result in different approaches to science decision making.

Adler, M.↗