Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “mission 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.

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

At least 505 records · Page 28
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

Stochastic Verification by Analysis for Autonomous Systems Management Architecture (ASMA)

The Gateway Vehicle Systems Manager (VSM) is the top-level of a distributed, hierarchical software control system. VSM is data-driven and will make decisions related to mission, fault, resource management and vehicle control. These attributes combined with a high degree of autonomy make it susceptible to emergent behavior. In order to achieve the high level of confidence needed in this critical system, the VSM team has developed a multifaceted verification strategy employing traditional verification techniques, simulation, model checking, and runtime verification. Individual algorithms are verified using conventional testing and model checking using assume-guarantee contracts. A discrete event-based simulation approach is being developed to verify timelines. This presentation describes an enhancement to the verification approach using analysis to enhance system robustness by detecting and resolving the potential for emergent behavior. The verification by analysis employs a Software in the Loop (SITL) environment with real flight software executing on emulated processors, simulations of vehicle subsystems, flight dynamics, and human inputs. Since the possible input space and configuration data set are too large for exhaustive testing, a Monte Carlo approach is used to cover feasible scenarios, augmented with corner cases and known higher-risk scenarios. A key problem in using Monte Carlo-based system verification is evaluating test results to ensure that system behavior is correct. The presentation describes the approach the VSM team uses to monitor behavior for compliance with predetermined boundaries and to identify anomalous behavior for further analysis. This presentation describes the multi-level systems approach to verification, and the simulation-based layer that covers the feasible state space: 1. Overview of the Gateway VSM 2. Special challenges due to heterogeneous, hierarchical architecture 3. Modeling and simulation environment using flight software and system simulations 4. Developing input sets to ensure state-space coverage 5. Developing model and data configuration sets to ensure model coverage 6. Interpreting results without predetermined outcomes 7. Lessons learned and future work

Verification and Validation↗
NASA NTRSDate not supplied

Human-Autonomy Teaming Assistant to Support Small Uncrewed Aircraft Systems for Wildland Firefighting Operations

An exploratory human-in-the-loop simulation was conducted to investigate and characterize a Human-Autonomy Teaming (HAT) Assistant to support a remote operator of multiple small Uncrewed Aircraft Systems (sUAS) using a ground control station (GCS) in the context of a wildland fire surveillance mission. Operator performance using the GCS with the HAT Assistant (Assisted Mode) was compared to operator performance using the GCS without the HAT Assistant (Unassisted Mode) during two types of contingency-event scenarios (Low and High Complexity). In the Assisted Mode, the HAT Assistant provided updates to the level of risk to the mission along with recommendations for risk mitigation, which were not provided in the Unassisted Mode. No significant differences in objective performance and subjective ratings of workload, situation awareness, and trust in automation between the Assisted and Unassisted Modes were detected, however there were indications that participants preferred the Assisted GCS over the Unassisted GCS and directions for further development were explored. Additional work is necessary to further refine the HAT Assistant and better characterize its effects on remote operator performance while managing multiple sUAS assets. Future work is recommended to optimize the implementation of an assistant to support operator performance during different missions and across vehicle classes

Human-Autonomy Teaming↗
NASA NTRS1981

Voyager at Saturn

The spacecraft design and operations and mission results of the Voyager Project are reviewed with particular emphasis on the results of the Saturn encounters. The mission was undertaken by two spacecraft: Voyager 2, launched first on August 20, 1977 on a lower energy trajectory to Jupiter, Saturn, Uranus and Neptune; and Voyager 1, launched on September 5, 1977 on a higher energy trajectory to closer flybys of Jupiter and Saturn. The Voyager spacecraft make use of earlier Mariner and Viking Orbiter design concepts, with additional capabilities for solar independent power, long-range communications and autonomy as well as equipment for the 11 science investigations. The Voyager operations system consists of a ground data system, missions operations system, and support by the Mission Control and Computer Center and Deep Space Network. Among the results of the Jupiter encounter are data concerning the magnetospheric structure and atmospheric dynamics of the planet and the surface features of the Galilean satellites. The encounters with Saturn produced scientific data concerning wind speeds, auroral emissions, and radio emissions from the planet, the fine structure of the previously known and newly discovered rings, the surface features of the satellites and the atmospheric composition and conditions of Titan. Voyager 1 is presently making field and particle measurements on its flight into interstellar space, while Voyager 2 is headed for an encounter with Uranus in January 1986 and Neptune in August 1989.

Heacock, R. L.↗
NASA NTRS2011

Intelligent Autonomy for Unmanned Surface and Underwater Vehicles

As the Autonomous Underwater Vehicle (AUV) and Autonomous Surface Vehicle (ASV) platforms mature in endurance and reliability, a natural evolution will occur towards longer, more remote autonomous missions. This evolution will require the development of key capabilities that allow these robotic systems to perform a high level of on-board decisionmaking, which would otherwise be performed by humanoperators. With more decision making capabilities, less a priori knowledge of the area of operations would be required, as these systems would be able to sense and adapt to changing environmental conditions, such as unknown topography, currents, obstructions, bays, harbors, islands, and river channels. Existing vehicle sensors would be dual-use; that is they would be utilized for the primary mission, which may be mapping or hydrographic reconnaissance; as well as for autonomous hazard avoidance, route planning, and bathymetric-based navigation. This paper describes a tightly integrated instantiation of an autonomous agent called CARACaS (Control Architecture for Robotic Agent Command and Sensing) developed at JPL (Jet Propulsion Laboratory) that was designed to address many of the issues for survivable ASV/AUV control and to provide adaptive mission capabilities. The results of some on-water tests with US Navy technology test platforms are also presented.

environmental sensing↗
NASA NTRS2021

Demonstrations of System-Level Autonomy for Spacecraft

System-level autonomy refers to autonomously meeting the crosscutting needs of a system through awareness and coordinated control spanning the system's breadth of capabilities. In contrast to function-level autonomy, which focuses on capabilities required to achieve a specific function such as surface navigation or image recognition, system-level autonomy addresses the needs to coordinate and manage activities and resources, and estimate the state, across subsystems. This paper describes demonstrations that were conducted on a spacecraft workstation testbed. The autonomy was provided by system-level planning and execution integrated with system-level estimators of orbit knowledge and spacecraft hardware health. These components are embedded in a system-level framework defining how goals are formed and executed, which elements exist, and how control authority is distributed among components. The planning and execution system at the heart of the framework has the capability to schedule, execute and monitor completion of tasks, as well as plan around unexpected events including new science opportunities and anomalies. The planning and scheduling system is the Multi-mission EXECutive (MEXEC), supported by the system-level health state estimator Model-Based Off-Nominal State Identification and Detection (MONSID), and Autonomous Navigation (AutoNav) algorithms, which determine the orbital system state based on optical observation of other targets. These components are applicable to many kinds of missions on different platforms. These demonstrations were elaborations of earlier experiments conducted on the ASTERIA (Arcsecond Space Telescope Enabling Research In Astrophysics) CubeSat, described in a companion submission [1]. The spacecraft’s extended mission served as an in-flight test platform, during which some individual autonomous capabilities were flown successfully. The autonomy experiments described here were performed on the ASTERIA workstation testbed.

Prather, Maurice↗
NASA NTRS1988

Space telerobots and planetary rovers

Space telerobots and planetary rovers are advanced forms of space automation that are being studied for missions beginning in the 1990s. This paper describes telerobots and planetary rovers, points out that pure autonomy is far beyond the state of the art, and goes on to discuss how useful, realizable telerobots and rovers can be developed in the context of human-machine systems. Telerobot and rover computational and architectural requirements are also briefly examined, and examples of current work, including the development of dedicated analog processing chips based upon neural networks are described. The paper closes with some speculations on the terrestrial implications of space robotics and some general conclusions.

Ruoff, Carl F.↗
NASA NTRS1989

Hazard avoidance for a Mars rover

The challenging geology of the surface of Mars, when coupled with the impossibility of continuous remote driving from earth, dictate the need for autonomous hazard detection, recognition and possibly hazard avoidance capabilities onboard any robotic Mars roving vehicle. The main technical issues represented by terrain hazards are accidental damage and vehicle entrapment. Several approaches to vehicle design geared to prevent such immobilization threats are identified. The gamut of alternatives for rover autonomy are also presented, and the applicability of the various options for the Mars Rover/Sample Return mission are assessed in the context of the technology state of the art for hazard sensors and processing algorithms.

Spiessbach, Andrew J.↗
NASA NTRS2000

Autonomy Architectures for a Constellation of Spacecraft

This paper describes three autonomy architectures for a system that continuously plans to control a fleet of spacecraft using collective mission goals instead of goals of 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 of even a hundred spacecraft (such as for interferometer or magnetospheric constellation missions).

Barrett, Anthony↗
NASA NTRS2007

Multi-Sensor Testing for 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 AR&D). The crewed missions may also perform rendezvous and docking operations and may require different levels of automation and/or autonomy, and must 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 requirements. The relatively low technology readiness level of AR&D relative navigation sensors has been carried as one of the CEV Project's top risks. The AR&D Sensor Technology Project seeks to reduce the risk by the testing and analysis of selected relative navigation sensor technologies through hardware-in-the-loop testing and simulation. These activities will provide the CEV Project information to assess the relative navigation sensors maturity as well as demonstrate test methods and capabilities. The first year of this project focused on a series of"pathfinder" testing tasks to develop the test plans, test facility requirements, trajectories, math model architecture, simulation platform, and processes that will be used to evaluate the Contractor-proposed sensors. Four candidate sensors were used in the first phase of the testing. The second phase of testing used four sensors simultaneously: two Marshall Space Flight Center (MSFC) Advanced Video Guidance Sensors (AVGS), a laser-based video sensor that uses retroreflectors attached to the target vehicle, and two commercial laser range finders. The multi-sensor testing was conducted at MSFC's Flight Robotics Laboratory (FRL) using the FRL's 6-DOF gantry system, called the Dynamic Overhead Target System (DOTS). The target vehicle for "docking" in the laboratory was a mockup that was representative of the proposed CEV docking system, with added retroreflectors for the AVGS. The multi-sensor test configuration used 35 open-loop test trajectories covering three major objectives: (1) sensor characterization trajectories designed to test a wide range of performance parameters; (2) CEV-specific trajectories designed to test performance during CEV-like approach and departure profiles; and (3) sensor characterization tests designed for evaluating sensor performance under more extreme conditions as might be induced during a spacecraft failure or during contingency situations. This paper describes the test development, test facility, test preparations, test execution, and test results of the multi-sensor series of trajectories.

Brewster, L.↗
NASA NTRS2008

Multi-Sensor Testing for Automated Rendezvous and Docking Sensor Testing at the Flight Robotics Lab

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 AR&D). The crewed missions may also perform rendezvous and docking operations and may require different levels of automation and/or autonomy, and must provide the crew with relative navigation information for manual piloting. The capabilities of the RPOD sensors are critical to the success ofthe Exploration Program. NASA has the responsibility to determine whether the Crew Exploration Vehicle (CEV) contractor-proposed relative navigation sensor suite will meet the requirements. The relatively low technology readiness level of AR&D relative navigation sensors has been carried as one of the CEV Project's top risks. The AR&D Sensor Technology Project seeks to reduce the risk by the testing and analysis of selected relative navigation sensor technologies through hardware-in-the-Ioop testing and simulation. These activities will provide the CEV Project information to assess the relative navigation sensors maturity as well as demonstrate test methods and capabilities. The first year of this project focused on a series of "pathfinder" testing tasks to develop the test plans, test facility requirements, trajectories, math model architecture, simulation platform, and processes that will be used to evaluate the Contractor-proposed sensors. Four candidate sensors were used in the first phase of the testing. The second phase of testing used four sensors simultaneously: two Marshall Space Flight Center (MSFC) Advanced Video Guidance Sensors (AVGS), a laser-based video sensor that uses retroreflectors attached to the target vehicle, and two commercial laser range finders. The multi-sensor testing was conducted at MSFC's Flight Robotics Laboratory (FRL) using the FRL's 6-DOF gantry system, called the Dynamic Overhead Target System (DOTS). The target vehicle for "docking" in the laboratory was a mockup that was representative of the proposed CEV docking system, with added retroreflectors for the AVGS.' The multi-sensor test configuration used 35 open-loop test trajectories covering three major objectives: (l) sensor characterization trajectories designed to test a wide range of performance parameters; (2) CEV-specific trajectories designed to test performance during CEV-like approach and departure profiles; and (3) sensor characterization tests designed for evaluating sensor performance under more extreme conditions as might be induced during a spacecraft failure or during contingency situations. This paper describes the test development, test facility, test preparations, test execution, and test results of the multisensor series oftrajectories

Brewster, Linda L.↗
NASA NTRSDate not supplied

Autonomous Navigation, Guidance, and Control Software in a Low SWaP Box

Onboard autonomy is a necessity for responsive space operations. Autonomous navigation, guidance, and control (NGC) enables space missions to reduce their dependence on high demand ground assets and costly ground personnel. It also allows for in-situ decision making and higher return on mission data. A flight software and hardware system providing this capability, called “autoNGC,” is currently being developed at NASA Goddard Space Flight Center for infusion into multiple future missions. The autoNGC flight software is built on the plug-and-play architecture of the core Flight System (cFS) consisting of the standard cFS apps and newly developed autoNGC interface apps and libraries. The various apps cooperate through communication over the message-based software bus. With the plug-and-play architecture of autoNGC, cFS apps can easily be added and replaced to meet the needs of different missions, even after launch. The first flight software release of autoNGC is targeted for Summer 2024 to provide autonomous navigation at the Moon and beyond. It can perform sensor fusion of multiple measurement types including pseudo-range from a Global Navigation Satellite System (GNSS) receiver (including weak signal), 1-way and 2-way range and Doppler from ground stations (i.e., direct to Earth (DTE)), bearing and range from optical camera images, and accelerometer data. Accurate onboard navigation and timing is obtained through the Goddard Enhanced Onboard Navigation System (GEONS) software library which fuses different measurement types through an extended Kalman filter (EKF) framework. Optical measurements that are ingested in GEONS are first extracted from optical images by the cFS Goddard Image Analysis and Navigation Tool (cGIANT) app. If the imaged body is far enough away that it appears as a pixel or cluster of pixels, then bearing angles to the body centroid can be provided. If the body is close enough and the shape is known coarsely, then bearing angles and range to the body centroid can be derived from the limb. Bearing angles to individual surface features can also be extracted (i.e., terrain relative navigation (TRN)). Onboard guidance and control capabilities are being developed for a future release to perform autonomous station-keeping and trajectory correction maneuvers in multiple orbital regimes. Capabilities to enable distributed systems missions and constellations, such as crosslink measurements, and onboard time management are being developed as well. The first hardware implementation of autoNGC is a minimal size, weight, and power (SWaP) design allowing for inclusion into CubeSats and SmallSat-size buses. Advancements in miniaturized space processors, such as the SpaceCube 3.0 Mini and the SpaceCube Mini-Z are utilized for low SWaP while maintaining a high level of performance. The current enclosure design is 12 cm x 17 cm x 13.5 cm. The box mass is expected to be less than 2 kg, and the nominal power is 21 W. In order to accommodate a wide range of missions, the hardware interfaces are designed for flexibility with a variety of sensor inputs. Through comprehensive testing in the software-in-the-loop, processor-in-the-loop, and hardware-in-the-loop test beds that are concurrently being developed, autoNGC is expected to achieve TRL 6 by late 2024.

Sun Hur-Diaz↗
NASA NTRSDate not supplied

Low SWaP Onboard Satellite Navigation, Guidance, and Control Technology

Onboard autonomy is a necessity for responsive space operations. Autonomous navigation, guidance, and control (NGC) enables space missions to reduce their dependence on high demand ground assets and costly ground personnel. It also allows for in-situ decision making and higher return on mission data. A flight software and hardware system providing this capability, called “autoNGC,” is currently being developed at NASA Goddard Space Flight Center for infusion into multiple future missions. The first build of autoNGC, providing autonomous navigation for lunar orbiting spacecraft, is targeted for completion by Fall 2024. It provides sensor fusion of multiple measurement types including pseudo-range from a weak signal Global Navigation Satellite Service (GNSS) receiver, 1-way and 2-way direct to Earth (DTE) range and Doppler, bearing and range from optical camera sensed images, and an accelerometer. AutoNGC is also being targeted for future missions that involve small body proximity operations, Sun Earth Libration point orbits, and distributed systems missions (DSMs) including those at outer planets. AutoNGC flight software is being built upon the plug-and-play architecture of the core Flight System (cFS) [Ref. 1]. Figure (Slide 7) shows the message-based software bus layout of various software applications (“apps”) consisting of the standard cFS apps and autoNGC interface apps and libraries. Accurate onboard navigation and timing is obtained through the Goddard Enhanced Onboard Navigation System (GEONS) software library [Ref. 2], which fuses different measurement types through an extended Kalman filter (EKF) framework. Optical measurements that are ingested in GEONS are provided by the cFS Goddard Image Analysis and Navigation Tool (cGIANT) app [Ref. 3]. This app processes optical images to extract the bearing angles of the centroid of the imaged body (near or far), the range to the imaged body, and/or of the features on the surface of a body to perform terrain relative navigation (TRN). Measurement of range to the body’s center of mass can also be derived from the detection of the limb. The first build of autoNGC for a lunar orbiting spacecraft is a minimal size, weight, and power (SWaP) hardware design allowing for inclusion into CubeSats and SmallSat-size class buses. Advancements in miniaturized space processors, such as the SpaceCube 3.0 Mini and the SpaceCube Mini-Z [Ref. 4] are utilized for low SWaP while maintaining a high level of performance. Figure (Slide 11) shows the composition of the first autoNGC build. The current enclosure design has dimensions 12 cm x 17 cm x 13.5 cm. The box mass is expected to be less than 2 kg, and the nominal power is 21 W. The hardware interfaces are designed for flexibility with a variety of sensor inputs. The achievable navigation performance depends on the sensors utilized, including the onboard clock for 1-way pseudo-range measurements. Analysis using a configuration that consists of weak signal GPS, TRN, and 1-way DTE has shown position and velocity accuracies of 10 meters and 2 cm/s (3-σ ) RSS, respectively, with onboard time knowledge estimated to better than 13 ns (3-σ ), for a spacecraft in a representative 12-hour eccentric lunar orbit. Other measurement types such as x-rays from known pulsars (called XNAV) and cross-links can also be processed in GEONS. With the plug-and-play architecture of autoNGC, cFS apps can easily be added and replaced, even after launch. Goddard is actively seeking partners to collaborate in the development of additional capabilities for autoNGC, including industry, academia, and others across the US Government. Plans are being formulated to make the autoNGC software platform available for use by any US government organization to leverage the non-recurring engineering associated with the development of onboard autonomous NGC 3 capabilities. As advancements in space qualified sensors, microprocessors, and algorithms are made, the autoNGC platform provides a ready starting point for inclusion of these technologies.

C. J. Gramling↗
NASA NTRS1986

Issues in the design of an executive controller shell for Space Station automation

A major goal of NASA's Systems Autonomy Demonstration Project is to focus research in artificial intelligence, human factors, and dynamic control systems in support of Space Station automation. Another goal is to demonstrate the use of these technologies in real space systems, for both round-based mission support and on-board operations. The design, construction, and evaluation of an intelligent autonomous system shell is recognized as an important part of the Systems Autonomy research program. His paper describes autonomous systems and executive controllers, outlines how these intelligent systems can be utilized within the Space Station, and discusses a number of key design issues that have been raised during some preliminary work to develop an autonomous executive controller shell at NASA Ames Research Center.

Erickson, William K.↗
NASA NTRS2019

Communication Bandwidth Considerations for Exploration Medical Care During Space Missions

Destinations beyond low Earth orbit, especially Mars, have several important constraints, including limited resupply, limited to no possibility of medical evacuation, and delayed communication with ground support teams. Therefore, medical care is driven towards greater autonomy and necessitates a medical system that supports this paradigm, including the potential for high medical data transfer rates in order to share medical information and coordinate care with the ground in an intermittent fashion as communication allows. The medical data transfer needs for a Martian exploration mission were estimated by defining two medical scenarios that would require high data rate communications between the spacecraft and Earth. One medical scenario involves a case of hydronephrosis (outflow obstruction of the kidney) that evolves into pyelonephritis (kidney infection), then urosepsis (systemic infection originating from the kidney), due to obstruction by a kidney stone. A second medical scenario involved the death of a crewmember’s child back on Earth that requires behavioral health care. For each of these scenarios, a data communications timeline was created following the medical care described by the scenario. From these timelines, total medical data transfers and burst transmission rates were estimated. Total data transferred from the vehicle-to-ground were estimated to be 94 gigabytes (GB) and 835 GB for the hydronephrosis and behavioral health scenarios, respectively. Data burst rates were estimated to be 7.7 megabytes per second (MB/s) and 15 MB/s for the hydronephrosis and behavioral health scenarios, respectively. Even though any crewed Mars mission should be capable of functioning autonomously, as long as the possibility of communication between Earth and Mars exists, Earth-based subject matter experts will be relied upon to augment mission medical capability. Therefore, setting an upper boundary limit for medical communication rates can help factor medical system needs into total vehicle communication requirements.

Krihak, Michael↗
NASA NTRS2016

Designing and Building a Crew-Centric Mobile Scheduling and Planning Tool for Exploring Crew Autonomy Concepts Onboard the International Space Station

During 2015, as part of our ongoing research on crew autonomy, our team adapted and extended the plan viewing tool, Playbook, into a mobile tool for exploring crew autonomy onboard the International Space Station (ISS). This work enables crewmembers to intuitively re-plan and schedule on their own with limited input from mission control. Designed for ease of use, re-planning is composed of simple drag and drop interactions and learning the tool requires little to no training. Playbook was successfully uplinked onto ISS as a technology demonstration and completed its onboard ground and crew checkouts in August and September 2015, respectively. We will discuss and describe how Playbook was able to integrate with actual ISS operational plans and operational procedures without disrupting real mission operations. This work will also outline the design and technical constraints required to build a collaborative tool that allows multiple users to simultaneously self-schedule and synchronize during communication dropouts in the restricted networking and computing environment onboard ISS. Finally, we will explore the aspects of crew autonomy that this technology enables as well as discuss our next steps and possible extensions.

ISS↗
NASA NTRS2015

Low-Latency Teleoperations for Human Exploration and Evolvable Mars Campaign

NASA has been analyzing a number of mission concepts and activities that involve low-latency telerobotic (LLT) operations. One mission concept that will be covered in this presentation is Crew-Assisted Sample Return which involves the crew acquiring samples (1) that have already been delivered to space, and or acquiring samples via LLT from orbit to a planetary surface and then launching the samples to space to be captured in space and then returned to the earth with the crew. Both versions of have key roles for low-latency teleoperations. More broadly, the NASA Evolvable Mars Campaign is exploring a number of other activities that involve LLT, such as: (a) human asteroid missions, (b) PhobosDeimos missions, (c) Mars human landing site reconnaissance and site preparation, and (d) Mars sample handling and analysis. Many of these activities could be conducted from Mars orbit and also with the crew on the Mars surface remotely operating assets elsewhere on the surface, e.g. for exploring Mars special regions and or teleoperating a sample analysis laboratory both of which may help address planetary protection concerns. The operational and technology implications of low-latency teleoperations will be explored, including discussion of relevant items in the NASA Technology Roadmap and also how previously deployed robotic assets from any source could subsequently be used by astronauts via LLT.

crew autonomy↗
NASA NTRS2005

Aerial Vehicle Surveys of other Planetary Atmospheres and Surfaces: Imaging, Remote-sensing, and Autonomy Technology Requirements

The objective of this paper is to review the anticipated imaging and remote-sensing technology requirements for aerial vehicle survey missions to other planetary bodies in our Solar system that can support in-atmosphere flight. In the not too distant future such planetary aerial vehicle (a.k.a. aerial explorers) exploration missions will become feasible. Imaging and remote-sensing observations will be a key objective for these missions. Accordingly, it is imperative that optimal solutions in terms of imaging acquisition and real-time autonomous analysis of image data sets be developed for such vehicles.

Young, Larry A.↗