Search NASA⌕ Search

SEARCH · Search NASA

Results for “autonomy JPL”

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.

61 records · Page 4
All sourcesNASA NTRSDOE OSTI
NASA NTRS1999

Autonomous Formation Flying from Ground to Flight

The cost of on-orbit operations remains a significant and increasingly visible concern in the support of satellite missions. Headway has been made in automating some ground operations; however, increased mission complexity and more precise orbital constraints have compelled continuing human involvement in mission design and maneuver planning operations. AI Solutions, Inc. in cooperation with the National Aeronautics and Space Administration's (NASA) Goddard Space Flight Center (GSFC) has tackled these more complex problems through the development of AutoCon as a tool for an automated solution. NASA is using AutoCon to automate the maneuver planning for the Earth Orbiter-1 (EO-1) mission. AutoCon was developed originally as a ground system tool. The EO-1 mission will be using a scaled version of AutoCon on-board the EO-1 satellite to command orbit adjustment maneuvers. The flight version of AutoCon plans maneuvers based on formation flying algorithms developed by GSFC, JPL, and other industry partners. In its fully autonomous mode, an AutoCon planned maneuver will be executed on-board the satellite without intervention from the ground. This paper describes how AutoCon automates maneuver planning for the formation flying constraints of the EO-1 mission. AutoCon was modified in a number of ways to automate the maneuver planning on-board the satellite. This paper describes how the interface and functionality of AutoCon were modified to support the on-board system. A significant component of this modification was the implementation of a data smoother, based on a Kalman filter, that ensures that the spacecraft states estimated by an on-board GPS receiver are as accurate as possible for maneuver planning. This paper also presents the methodology use to scale the AutoCon functionality to fit and execute on the flight hardware. This paper also presents the modes built that allow the incremental phasing in of autonomy. New technologies for autonomous operations are usually received with significant, and probably appropriate trepidation. A number of safeguards have been designed in both AutoCon and the interfacing systems to alleviate the potential of mission-impacting anomalies from the on-board autonomous system. This paper describes the error checking, input data integrity validation and limits set on maneuvers in AutoCon and the on-board system.

Chapman, Keith B.↗
NASA NTRS1999

Autonomous Formation Flying from the Ground to Flight

The cost of on-orbit operations remains a significant and increasingly visible concern in the support of satellite missions. Headway has been made in automating some ground operations; however, increased mission complexity and more precise orbital constraints have compelled continuing human involvement in mission design and maneuver planning operations. AI Solutions, Inc. in cooperation with the National Aeronautics and Space Administration's (NASA) Goddard Space Flight Center (GSFC) has tackled these more complex problems through the development of AutoCon(TM) as a tool for an automated solution. NASA is using AutoCon(TM) to automate the maneuver planning for the Earth Orbiter-1 (EO-1) mission. AutoCon(TM) was developed originally as a ground system tool. The EO-1 mission will be using a scaled version of AutoCon(TM) on-board the EO-1 satellite to command orbit adjustment maneuvers. The flight version of AutoCon(TM) plans maneuvers based on formation flying algorithms developed by GSFC, JPL, and other industry partners. In its fully autonomous mode, an AutoCon(TM) planned maneuver will be executed on-board the satellite without intervention from the ground. This paper describes how AutoCon(TM) automates maneuver planning for the formation flying constraints of the EO-1 mission. AutoCon(TM) was modified in a number of ways to automate the maneuver planning on-board the satellite. This paper describes how the interface and functionality of AutoCon(TM) were modified to support the on-board system. A significant component of this modification was the implementation of a data smoother, based on a Kalman filter, that ensures that the spacecraft states estimated by an on-board GPS receiver are as accurate as possible for maneuver planning. This paper also presents the methodology used to scale the AutoCon(TM) functionality to fit and execute on the flight hardware. This paper also presents the modes built into the system that allow the incremental phasing in of autonomy. New technologies for autonomous operations are usually received with significant, and probably appropriate, trepidation. A number of safeguards have been designed in both AutoCon(TM) and the interfacing systems to alleviate the potential of mission-impacting anomalies from the on-board autonomous system. This paper describes the error checking, input data integrity validation, and limits set on maneuvers in AutoCon(TM) and the on-board system.

Chapman, Keith B.↗
NASA NTRS2009

Aerobot Autonomy Architecture

An architecture for autonomous operation of an aerobot (i.e., a robotic blimp) to be used in scientific exploration of planets and moons in the Solar system with an atmosphere (such as Titan and Venus) is undergoing development. This architecture is also applicable to autonomous airships that could be flown in the terrestrial atmosphere for scientific exploration, military reconnaissance and surveillance, and as radio-communication relay stations in disaster areas. The architecture was conceived to satisfy requirements to perform the following functions: a) Vehicle safing, that is, ensuring the integrity of the aerobot during its entire mission, including during extended communication blackouts. b) Accurate and robust autonomous flight control during operation in diverse modes, including launch, deployment of scientific instruments, long traverses, hovering or station-keeping, and maneuvers for touch-and-go surface sampling. c) Mapping and self-localization in the absence of a global positioning system. d) Advanced recognition of hazards and targets in conjunction with tracking of, and visual servoing toward, targets, all to enable the aerobot to detect and avoid atmospheric and topographic hazards and to identify, home in on, and hover over predefined terrain features or other targets of scientific interest. The architecture is an integrated combination of systems for accurate and robust vehicle and flight trajectory control; estimation of the state of the aerobot; perception-based detection and avoidance of hazards; monitoring of the integrity and functionality ("health") of the aerobot; reflexive safing actions; multi-modal localization and mapping; autonomous planning and execution of scientific observations; and long-range planning and monitoring of the mission of the aerobot. The prototype JPL aerobot (see figure) has been tested extensively in various areas in the California Mojave desert.

Elfes, Alberto↗
NASA NTRS2006

AutoNav Mark3: Engineering the Next Generation of Autonomous Onboard Navigation and Guidance

The success of JPL's AutoNav system at comet Tempel-1 on July 4, 2005, demonstrated the power of autonomous navigation technology for the Deep Impact Mission. This software is being planned for use as the onboard navigation, tracking and rendezvous system for a Mars Sample Return Mission technology demonstration, and several mission proposals are evaluating its use for rendezvous with, and landing on asteroids. Before this however, extensive re-engineering of AutoNav will take place. This paper describes the AutoNav systems-engineering effort in several areas: extending the capabilities, improving operability, utilizing new hardware elements, and demonstrating the new possibilities of AutoNav in simulations.

navigation↗
NASA NTRS2012

VML 3.0 Reactive Sequencing Objects and Matrix Math Operations for Attitude Profiling

VML (Virtual Machine Language) has been used as the sequencing flight software on over a dozen JPL deep-space missions, most recently flying on GRAIL and JUNO. In conjunction with the NASA SBIR entitled "Reactive Rendezvous and Docking Sequencer", VML version 3.0 has been enhanced to include object-oriented element organization, built-in queuing operations, and sophisticated matrix / vector operations. These improvements allow VML scripts to easily perform much of the work that formerly would have required a great deal of expensive flight software development to realize. Autonomous turning and tracking makes considerable use of new VML features. Profiles generated by flight software are managed using object-oriented VML data constructs executed in discrete time by the VML flight software. VML vector and matrix operations provide the ability to calculate and supply quaternions to the attitude controller flight software which produces torque requests. Using VML-based attitude planning components eliminates flight software development effort, and reduces corresponding costs. In addition, the direct management of the quaternions allows turning and tracking to be tied in with sophisticated high-level VML state machines. These state machines provide autonomous management of spacecraft operations during critical tasks like a hypothetic Mars sample return rendezvous and docking. State machines created for autonomous science observations can also use this sort of attitude planning system, allowing heightened autonomy levels to reduce operations costs. VML state machines cannot be considered merely sequences - they are reactive logic constructs capable of autonomous decision making within a well-defined domain. The state machine approach enabled by VML 3.0 is progressing toward flight capability with a wide array of applicable mission activities.

VML (Virtual Machine Language)↗
NASA NTRS2005

Lessons Learned in the Livingstone 2 on Earth Observing One Flight Experiment

The Livingstone 2 (L2) model-based diagnosis software is a reusable diagnostic tool for monitoring complex systems. In 2004, L2 was integrated with the JPL Autonomous Sciencecraft Experiment (ASE) and deployed on-board Goddard's Earth Observing One (EO-1) remote sensing satellite, to monitor and diagnose the EO-1 space science instruments and imaging sequence. This paper reports on lessons learned from this flight experiment. The goals for this experiment, including validation of minimum success criteria and of a series of diagnostic scenarios, have all been successfully net. Long-term operations in space are on-going, as a test of the maturity of the system, with L2 performance remaining flawless. L2 has demonstrated the ability to track the state of the system during nominal operations, detect simulated abnormalities in operations and isolate failures to their root cause fault. Specific advances demonstrated include diagnosis of ambiguity groups rather than a single fault candidate; hypothesis revision given new sensor evidence about the state of the system; and the capability to check for faults in a dynamic system without having to wait until the system is quiescent. The major benefits of this advanced health management technology are to increase mission duration and reliability through intelligent fault protection, and robust autonomous operations with reduced dependency on supervisory operations from Earth. The work-load for operators will be reduced by telemetry of processed state-of-health information rather than raw data. The long-term vision is that of making diagnosis available to the onboard planner or executive, allowing autonomy software to re-plan in order to work around known component failures. For a system that is expected to evolve substantially over its lifetime, as for the International Space Station, the model-based approach has definite advantages over rule-based expert systems and limit-checking fault protection systems, as these do not scale well. The model-based approach facilitates reuse of the L2 diagnostic software; only the model of the system to be diagnosed and telemetry monitoring software has to be rebuilt for a new system or expanded for a growing system. The hierarchical L2 model supports modularity and expendability, and as such is suitable solution for integrated system health management as envisioned for systems-of-systems.

Hayden, Sandra C.↗
NASA NTRS2012

Science Benefits of Onboard Spacecraft Navigation

Primitive bodies (asteroids and comets), which have remained relatively unaltered since their formation, are important targets for scientific missions that seek to understand the evolution of the solar system. Often the first step is to fly by these bodies with robotic spacecraft. The key to maximizing data returns from these flybys is to determine the spacecraft trajectory relative to the target body-in short, navigate the spacecraft- with sufficient accuracy so that the target is guaranteed to be in the instruments' field of view. The most powerful navigation data in these scenarios are images taken by the spacecraft of the target against a known star field (onboard astrometry). Traditionally, the relative trajectory of the spacecraft must be estimated hours to days in advance using images collected by the spacecraft. This is because of (1)!the long round-trip light times between the spacecraft and the Earth and (2)!the time needed to downlink and process navigation data on the ground, make decisions based on the result, and build and uplink instrument pointing sequences from the results. The light time and processing time compromise navigation accuracy considerably, because there is not enough time to use more accurate data collected closer to the target-such data are more accurate because the angular capability of the onboard astrometry is essentially constant as the distance to the target decreases, resulting in better "plane-of- sky" knowledge of the target. Excellent examples of these timing limitations are high-speed comet encounters. Comets are difficult to observe up close; their orbits often limit scientists to brief, rapid flybys, and their coma further restricts viewers from seeing the nucleus in any detail, unless they can view the nucleus at close range. Comet nuclei details are typically discernable for much shorter durations than the roundtrip light time to Earth, so robotic spacecraft must be able to perform onboard navigation. This onboard navigation can be accomplished through a self- contained system that by eliminating light time restrictions dramatically improves the relative trajectory knowledge and control and subsequently increases the amount of quality data collected. Flybys are one-time events, so the system's underlying algorithms and software must be extremely robust. The autonomous software must also be able to cope with the unknown size, shape, and orientation of the previously unseen comet nucleus. Furthermore, algorithms must be reliable in the presence of imperfections and/or damage to onboard cameras accrued after many years of deep-space operations. The AutoNav operational flight software packages, developed by scientists at the Jet Propulsion Laboratory (JPL) under contract with NASA, meet all these requirements. They have been directly responsible for the successful encounters on all of NASA's close-up comet-imaging missions (see Figure !1). AutoNav is the only system to date that has autonomously tracked comet nuclei during encounters and performed autonomous interplanetary navigation. AutoNav has enabled five cometary flyby missions (Table!1) residing on four NASA spacecraft provided by three different spacecraft builders. Using this software, missions were able to process a combined total of nearly 1000 images previously unseen by humans. By eliminating the need to navigate spacecraft from Earth, the accuracy gained by AutoNav during flybys compared to ground-based navigation is about 1!order of magnitude in targeting and 2!orders of magnitude in time of flight. These benefits ensure that pointing errors do not compromise data gathered during flybys. In addition, these benefits can be applied to flybys of other solar system objects, flybys at much slower relative velocities, mosaic imaging campaigns, and other proximity activities (e.g., orbiting, hovering, and descent/ascent).

Autonomy↗