SEARCH · Search NASA

Results for “autonomous planners”

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.

150 records · Page 9

All sources NASA NTRS DOE OSTI

NASA NTRS1990

Autonomous planetary rover at Carnegie Mellon

This report describes progress in research on an autonomous robot for planetary exploration. In 1989, the year covered by this report, a six-legged walking robot, the Ambler, was configured, designed, and constructed. This configuration was used to overcome shortcomings exhibited by existing wheeled and walking robot mechanisms. The fundamental advantage of the Ambler is that the actuators for body support are independent of those for propulsion; a subset of the planar joints propel the body, and the vertical actuators support and level the body over terrain. Models of the Ambler's dynamics were developed and the leveling control was studied. An integrated system capable of walking with a single leg over rugged terrain was implemented and tested. A prototype of an Ambler leg is suspended below a carriage that slides along rails. To walk, the system uses a laser scanner to find a clear, flat foothold, positions the leg above the foothold, contacts the terrain with the foot, and applies force enough to advance the carriage along the rails. Walking both forward and backward, the system has traversed hundreds of meters of rugged terrain including obstacles too tall to step over, trenches too deep to step in, closely spaced rocks, and sand hills. In addition, preliminary experiments were conducted with concurrent planning and execution, and a leg recovery planner that generates time and power efficient 3D trajectories using 2D search was developed. A Hero robot was used to demonstrate mobile manipulation. Indoor tasks include collecting cups from the lab floor, retrieving printer output, and recharging when its battery gets low. The robot monitors its environment, and handles exceptional conditions in a robust fashion, using vision to track the appearance and disappearance of cups, onboard sonars to detect imminent collisions, and monitors to detect the battery level.

Whittaker, William↗

NASA NTRSDate not supplied

Markov Decision Process based Trajectory Planning for UAVs under Uncertain Wind Conditions

In this paper we propose a Markov Decision Process (MDP) algorithm for path-planning of Unmanned Aviation Vehicles (UAVs) under varying wind conditions. Solutions to path-planning for UAVs are becoming increasingly necessary as autonomous UAVs continue to enter commercial and government spaces. Path-planning is inherently challenging, as UAVs needs to account for dynamically changing flying conditions such as weather, obstacle or no-fly zones, degraded vehicle health and off-nominal battery power consumption. Machine learning methods such as Markov Decision Process (MDPs) have the potential to revolutionize how vehicles navigate in such uncertain environments. Previous papers have demonstrated the use of MDPs to optimize UAV path-planning for energy consumption under time-varying wind distribution. In this study, UAV trajectories from a pre-determined waypoint to target cell, will be computed on a 7X7 grid environment by optimizing parameters for mission assurance and safety limits in addition to the energy consumption, and operation time. The UAV navigates the grid by taking actions to move in either of the eight cardinal and intercardinal directions, under constant thrust profile. The next state of the UAV is calculated by considering its action, transition probability, obstacle cells and the wind speed magnitude and direction. Both constant and stochastic wind will be considered in this paper, the parameters being extracted from real wind measurements in proximity to an experimental UAV flight. One of the studies to be demonstrated in this paper is that as the unmanned airspace gets more complex with multiple vehicles and environmental uncertainties, trade-offs between energy consumption, operation time, risk tolerance, and mission assurance needs to be made. Further, MDPs are capable of fast computation of UAV trajectories under varying wind, hence making them suitable for in-flight path planners.

decision-making↗

DOE OSTI2021

Universal Utility Data Exchange (UUDEX) – Security and Administration: Cybersecurity of Energy Delivery Systems (CEDS) Research and Development

A critical component of the Universal Utility Data Exchange (UUDEX) approach is the integrated security contained within its processing. This document describes how that security is designed and expected to be implemented by UUDEX Implementations (U-Implementations), including the UUDEX Server (U-Server) and UUDEX Clients (U-Clients). The UUDEX security hierarchy consists of three levels: 1. The UUDEX Instance (U-Instance) itself, which sits at the top of the hierarchy and contains the U-Server, the UUDEX Identity Authority (U-Identity Authority), and the UUDEX Administrator (U-Administrator) functions; 2. A group of one or more UUDEX Participants (U-Participants) that present “organizations” that participate in the U-Instance and contains the UUDEX Administrator Participant (U-U-Administrator Participant) function; 3. A group of one or more UUDEX Endpoints (U-Endpoints) that represent the individual UUDEX Publish Clients (U-Publish Client) responsible for supplying data to the U-Instance that is consumed by UUDEX Subscriber Clients (U-Subscriber Clients). U-Endpoints can be either autonomous devices that publish and subscribe data such as data exchange servers found in supervisory control and data acquisition and energy management systems, or they can be tied to users of applications that, for example, submit DOE OE-417 disturbance reports. U-Participants and U-Endpoints can be organized into UUDEX Groups (U-Groups). Any number of U-Participants or U-Endpoints can be members of a U-Group. A given U-Participant or U-Endpoint can be a member of multiple U-Groups, but a U-Group cannot contain other U-Groups. For example, a U-Group could be created to contain all U-Participant Transmission Operators within the purview of a Reliability Coordinator, and another U-Group could be created to contain all U-Participant Generator Operators within the purview of a Reliability Coordinator. U-Participants that are both Transmission Operators and Generator Operators would be members of both U-Groups. U-Participants, U-Endpoints, and U-Groups are used in the access control structures to provide access to individual UUDEX Subjects (U-Subjects). U-Groups are created by the U-Administrator and are managed by the U-Administrator or the designated U-Group Managers. U-Endpoints can be assigned UUDEX Roles (U-Roles) that can be used to further restrict access. U-Roles are assigned to individual U-Endpoints. For example, a U-Role of “Security Analyst” could be used to restrict which U-Endpoints can publish or subscribe security incident reports and vulnerability notifications, while a U-Role of “Transmission Planner” can be used to restrict which U-Endpoints can publish power system model updates. U-Role definitions are created by the U-Administrator, but the U-Roles are assigned to U-Endpoints by their respective UUDEX Participant Administrators (U-Participant Administrator). Because all information required to make security decisions is either included within the U-Endpoint’s X.509 digital certificate or stored in a datastore on the U-Server, all security decisions are performed and enforced within the U-Server. This reduces the complexity of the U-Client code and minimizes the chance for compromise of the integrity of the UUDEX security features.

97 MATHEMATICS AND COMPUTING↗

NASA NTRS2022

The Mars 2020 Ground Data System Architecture

The Mars 2020 Mission’s primary objective is to collect 20 geographically unique samples during its prime mission of one and a quarter Martian years, or just over 2 Earth years. Mission planners determined the project needed to develop a system that would enable the operations team to analyze engineering and science data, make science decisions, select viable rover targets at a millimeter resolution and validate an uplink bundle for a car sized rover with more complex science instruments than any previous Mars surface mission. All this had to be done within a five hour time frame. Doing this with a small team would be a challenge, but this had to be accomplished by a large team of engineers and scientists located across North America and Europe. Achieving this level of operational efficiency was unheard of in the prime mission. In addition, the mission had another set of requirements that had nothing to do with surface operations; the Mars 2020 Ground Data System (GDS) was also expected to comply with a new set of security requirements to keep up with the ever changing cybersecurity landscape. The Mars 2020 Ground Data System (GDS) is a re-architected version of the Mars Science Laboratory GDS. The primary goal was to integrate the lessons learned from previous Mars surface missions, accommodate a set of new requirements and capabilities required to ensure mission success, and comply with a new set of cybersecurity controls. The new architecture includes several unique qualities including a data lake, language-agnostic system-wide event-based operations, containerization, automated deployment, network segmentation, infrastructure-as-code, API-driven interfaces, and the first Mars surface GDS to operate primarily in the cloud. The new architecture enabled greater access to the system’s data, tighter integration with the operations team, and a higher level of traceability. The availability of the data also enabled a new set of capabilities previously not possible on surface missions. These new capabilities include an autonomous data to information, pipeline for downlink analysis, horizontal scaling of science data processing capabilities, autonomous round trip data tracking of science and engineering data, integration of flight system state into the tactical planning cycle, high fidelity targeting utilizing kinematic data, and hierarchical image and 3d meshes data representations. This paper will introduce the requirements for the Mars 2020 Mission, the heritage architecture, and the rationale for the changes to achieve the new architecture. The paper will continue to describe the fundamental changes made to the GDS architecture, how these changes enabled a more tightly integrated GDS, and the new capabilities that were enabled by the new architecture. The paper will conclude with the lessons learned from the process of rearchitecting a heritage GDS system and from the first 200 days of operations supporting over 800 users from around the world.

Lopez-Roig, Reynaldo↗

NASA NTRSDate not supplied

A Notional Artemis Lunar Surface Exploration Package (ArLSEP) based on the Gandalf Staff Platform

Introduction: The Artemis program is planning to deliver crew and cargo to the lunar surface, but there is no current package for supporting lunar in-struments and experiments similar to the Apollo Lunar Surface Exploration Package (ALSEP). This abstract provides a possible concept for such a package using the Gandalf Staff Platform as a common core. Gandalf Staff: The Gandalf Staff is an early prototype system developed over FY’21/FY’22 using NASA Science Technology Mission Directorate (STMD) Center Information Fund (CIF) grants to de-sign, build and test “proof-of-concept” components. These components include a 24v battery powered monopole that powers a suite of subsystems, including a Graphical User Interface (GUI) for crew, surface voice and data communications, Lunar Search and Rescue (LunaSAR) navigation and communications, LiDAR, field site external lighting, 360-degree camera, and a geothermal instrument for measuring sub-surface temperature gradient. The staff can be carried independently by an Extra-Vehicular Activity (EVA) astronaut, or can be mounted into a tripod for “hands free” support at a surface site being investigated. The staff can be attached to an external solar array and power storage system for long-duration operations. [1,2] ALSEP: An ASLEP flew on each mission Apollo 12 to Apollo 17. For Apollo 11, a simplified packaged called the Early Apollo Scientific Experiments Pack-age (EASEP) was flown. Each package included a “Central Station” that provided the power and communications connected to a variety of instruments and sensors. The power was provided by a Radioisotope Thermoelectric Generator (RTG) fueled by Plutoni-um-238 generating 70 watts of power (initially, decayed over time) [3]. The communications system provide for direct to Earth data transfer from the lunar surface. Each pack-age was stowed externally in the Lunar Module (LM) Scientific Equipment (SEQ) bay with a mass up to 163 kg (Apollo 17). The crew unloaded the ALSEP from the LM and deployed the instruments on the lunar surface. Although designed to operate for only 1 year, many sites operated for up to 8 years successfully [4]. The Active Seismic Experiment (ASE) included 3 geophones for detecting seismic waves created by mortars and thumpers deployed by the crew. Other active experiments measured the lunar atmosphere, the heat flow in the subsurface, the lunar gravity and potential gravity waves, the lunar magnetic field, the solar wind and plasma interactions in cislunar space. Passive experiments included collectors for dust and cosmic rays, and retroreflectors for precise measurements of distance using a laser from Earth. The ALSEP program continues to generate insights into lunar formation and evolution. ArLSEP Concepts: The lunar surface science package for the Artemis program will hopefully exceed the capability of the ALSEP. There are multiple issues for discussion leading to the design of a new ArLSEP, needing requirements definition from the science community, NASA mission architecture, and NASA budget planners. 1. Delivery Mechanism Two possible projects currently provide capability to deliver scientific cargo to the lunar surface: 1) the Commercial Lunar Payload Services (CLPS) [5] and the Human Landing System (HLS) [6, 7]. Each project is controlled by a different organization within NASA and budgeted with different criteria although both support lunar exploration. The HLS system delivers crew (and potentially cargo) to human landing sites. If an ArLSEP is “predeployed” to such a site, the design must include power (either from the vehicle or independently) to keep the electronics functioning until deployed by the crew. If an ArLSEP is delivered on a vehicle after the crew is present on the lunar surface, safety protocols require adequate distance from the humans for impact from descent propelled sur-face regolith ejecta. This distance can not exceed the capability of the crew to walk (if no rover) to the vehicle for ArLSEP deployment. 2. Overall Guidelines The general design of ArLSEP will likely follow the ALSEP with a common system for communications and power; however, significant architecture differences between Apollo and Artemis exist. Power: The RTG will not be available for early Artemis missions nor likely follow-on Lunar Exploration Transportation Services (LETS) missions [8]. Thus, ArLSEP power must be supplied by solar arrays with sufficient battery capability to “keep alive” necessary electronics during any lunar surface eclipse period. Communication: The Artemis program is developing a series of communications satellites for lunar orbit to provide surface transmission of data and voice to Earth. Called “LunaNET”, this network is component useful for ArLSEP since south polar locations may not always have direct “line-of-sight” to Earth [9]. 3. Concept of Operations (ConOps) The general ConOps for ArLSEP is to deliver the package to lunar surface before the crew arrives, and then have the crew deploy the package after some period of time. This requires coordinated design (for power systems) and launch window (for schedule) on both the cargo and crew missions. Once the ArLSEP is deployed, it will operate autonomously for a number of years. It should be designed to be EVA compatible for crew maintenance and upgrade. 4. Notional Design (for discussion purpose only) The landing site near the South Pole is expected to have no eclipse cycle exceeding 5 days, so the “keep alive” power is 144 hours (6 days to include margin). A 12v ArLSEP will use rechargeable LiFePO4 cells, which are common in the Electric Vehicle (EV) industry. With a current of 5 amps and a 125 watt system, the mass is about 90kg. The comm. system and structure adds another 10kg, thus the “Central Station” is approximately 100kg. The solar power is collected on four arrays (each 2m above the surface), and the entire ArLSEP is designed to stow in a 2m x 1m x 1m volume. The experiment and instrument design will vary for each installation and add mass to the total (although they are expected to fit within the 2m3 volume). Seismic wave generation will likely not be provided with mortars, thus an electric “thumper” will be required. Active instruments such as imaging systems and sensing instruments will benefit from the additional power and communication capability provided by ArLSEP. Passive systems such as retroreflectors, witness plates, and cosmic dust collectors can be added to either the landing vehicle and/or the ArLSEP. With repeated HLS missions to the same human site, the ArLSEP can be expanded and easily maintained for long duration science collection on the lunar surface.

ALSEP↗

NASA NTRSDate not supplied

A Science-Focused Artificial Intelligence (AI) Responding in Real-Time to New Information: Capability Demonstration for Ocean World Missions

Introduction: Artificial intelligence (AI) has long been considered a potential mechanism to explore increasingly challenging environments, including those with extreme temperatures and pressures, limited communication capabilities, or those with demanding terrain. We posit that missions in extreme environments could deploy an onboard AI focused on science observations and goals in order to augment a traditional concept(s) of operations (ConOps). An onboard AI capability could perform functions such as data analysis in order to make high-level decisions, including prioritized data transmission for analysis by ground-based teams or autonomously-guided follow-on analyses that maximize science return. Such a capability would empower missions to respond to scientific data of interest in real-time; a mission could make observations and perform a preliminary analysis to alert ground-based scientists to an observation of interest, enabling an informed, rapid response from Earth-based teams. Enceladus Case Study for Onboard AI: We are developing an onboard AI capability for real-time telemetry response that formulates and carries-out informed decisions in service to established mission goals, enabling increased science return of a mission. We focus our AI development for use on a constellation of SmallSats orbiting Enceladus. Our Enceladus case study tests autonomous decision-making capabilities in scenarios with complex orbital dynamics, plume ejecta, extreme cold environments, power restrictions, and a requirement to maximize science return for a potential positive detection of life, while critically evaluating the potential for false positives. Telemetry includes simulated scientific data, spacecraft onboard operational data (e.g., position, velocity, and rotation), and engineering hardware performance data. Enceladus SmallSat Constellation. Our constellation includes eight SmallSat spacecraft in an 8:35 resonant orbit-based formation, leveraging Saturn’s gravitational forces to maintain stable orbits with global coverage around Enceladus. To our knowledge, we simulate the first stable configuration of multiple spacecraft in closed orbits around Enceladus, using a full ephemeris force model (Russell and Lara, 2009). Each spacecraft’s orbit will precess, causing an eastward ground track shift (from an orbiter’s perspective) of each spacecraft for each orbit. However, all spacecraft return to their original positions relative to Enceladus after eight Enceladus revolutions around Saturn. We model communication pathways between SmallSats to understand how information would need to be transmitted across the constellation to enable AI-driven decision-making and resource allocation across the fleet. Capability Demonstration. Our simulated capability demonstration inputs position, velocity, and rotation telemetry from our Enceladus-focused constellation simulations, and mass spectrometry data collected from abiotic and biotic laboratory-analog ocean world experiments (Theiling et al., 2018; Theiling, 2021; Da Poian et al., 2023). Data from these experiments are used to simulate MS measurements and different scenarios of science observations for onboard analysis performed on each of the eight spacecraft. For these demonstrations, we integrate 24 machine learning (ML) algorithms into an onboard intelligence as a ‘knowledge base’, including algorithms evaluating data quality and those predicting (with % confidence) gas composition, ocean aqueous chemistry, and whether the sample was influenced by microbial life. The onboard AI capability is designed to use the knowledge base to come to a consensus-based decision in the interpretation of the observed data in order to request additional action outside of a pre-defined ConOps. Requested actions could include e.g., prioritized downlink to Earth (for analysis by ground-based teams) or follow-on analyses performed across the constellation. The spacecraft’s intelligent onboard planner must then determine whether sufficient resources (e.g., time, power, etc.) are available and weigh the request with mission priorities. In our simulation, the constellation is able to identify potential biosignatures using onboard ML algorithms, evaluate the confidence of that prediction, and perform follow-on analyses across the fleet to confirm the detection, in order to best prepare a transmission of these data to Earth-based teams.

astrobiology↗