Search NASA⌕ Search

SEARCH · Search NASA

Results for “software algorithms”

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

A real-time implementation of an advanced sensor failure detection, isolation, and accommodation algorithm

A sensor failure detection, isolation, and accommodation algorithm was developed which incorporates analytic sensor redundancy through software. This algorithm was implemented in a high level language on a microprocessor based controls computer. Parallel processing and state-of-the-art 16-bit microprocessors are used along with efficient programming practices to achieve real-time operation. Previously announced in STAR as N84-13140

Delaat, J. C.↗

A Parallel Rendering Algorithm for MIMD Architectures

Applications such as animation and scientific visualization demand high performance rendering of complex three dimensional scenes. To deliver the necessary rendering rates, highly parallel hardware architectures are required. The challenge is then to design algorithms and software which effectively use the hardware parallelism. A rendering algorithm targeted to distributed memory MIMD architectures is described. For maximum performance, the algorithm exploits both object-level and pixel-level parallelism. The behavior of the algorithm is examined both analytically and experimentally. Its performance for large numbers of processors is found to be limited primarily by communication overheads. An experimental implementation for the Intel iPSC/860 shows increasing performance from 1 to 128 processors across a wide range of scene complexities. It is shown that minimal modifications to the algorithm will adapt it for use on shared memory architectures as well.

Crockett, Thomas W.↗

Advanced communications technology satellite high burst rate link evaluation terminal communication protocol software user's guide, version 1.0

The Communication Protocol Software was developed at the NASA Lewis Research Center to support the Advanced Communications Technology Satellite High Burst Rate Link Evaluation Terminal (ACTS HBR-LET). The HBR-LET is an experimenters terminal to communicate with the ACTS for various experiments by government, university, and industry agencies. The Communication Protocol Software is one segment of the Control and Performance Monitor (C&PM) Software system of the HBR-LET. The Communication Protocol Software allows users to control and configure the Intermediate Frequency Switch Matrix (IFSM) on board the ACTS to yield a desired path through the spacecraft payload. Besides IFSM control, the C&PM Software System is also responsible for instrument control during HBR-LET experiments, uplink power control of the HBR-LET to demonstrate power augmentation during signal fade events, and data display. The Communication Protocol Software User's Guide, Version 1.0 (NASA CR-189162) outlines the commands and procedures to install and operate the Communication Protocol Software. Configuration files used to control the IFSM, operator commands, and error recovery procedures are discussed. The Communication Protocol Software Maintenance Manual, Version 1.0 (NASA CR-189163, to be published) is a programmer's guide to the Communication Protocol Software. This manual details the current implementation of the software from a technical perspective. Included is an overview of the Communication Protocol Software, computer algorithms, format representations, and computer hardware configuration. The Communication Protocol Software Test Plan (NASA CR-189164, to be published) provides a step-by-step procedure to verify the operation of the software. Included in the Test Plan is command transmission, telemetry reception, error detection, and error recovery procedures.

Reinhart, Richard C.↗

Rapid Development of the Seeker Free-Flying Inspector Guidance, Navigation, and Control System

Seeker is an automated extravehicular free-flying inspector CubeSat designed and built in-house at the Johnson Space Center (JSC). As a Class 1E project funded by the International Space Station (ISS) Program, Seeker had a streamlined process to flight certification, but the vehicle had to be designed, developed, tested, and delivered within approximately one year after authority to pro-ceed (ATP) and within a $1.8 million budget. These constraints necessitated an expedited Guidance, Navigation, and Control (GNC) development schedule, development began with a navigation sensor trade study using Linear Covariance (LinCov) analysis and a rapid sensor downselection process, resulting in the use of commercial off-the-shelf (COTS) sensors which could be procured quickly and subjected to in-house environmental testing to qualify them for flight. A neural network was used to enable a COTS camera to provide bearing measurements for visual navigation. The GNC flight software (FSW) algorithms utilized lean development practices and leveraged the Core Flight Software (CFS) architecture to rapidly develop the GNC system, tune the system parameters, and verify performance in simulation. This pace was anchored by several Hardware-Software Integration (HSI) milestones, which forced the Seeker GNC team to develop the interfaces both between hardware and software and between the GNC domains early in the project and to enable a timely delivery.

Sullivan, Jacob↗

Rapid Development of the Seeker Free-Flying Inspector Guidance, Navigation, and Control System

Seeker is an automated extravehicular free-flying inspector CubeSat designed and built in-house at the Johnson Space Center (JSC). As a Class 1E project funded by the International Space Station (ISS) Program, Seeker had a stream-lined process to flight certification, but the vehicle had to be designed, developed, tested, and delivered within approximately one year after authority to proceed (ATP) and within a $1.8 million budget. These constraints necessitated an expedited Guidance, Navigation, and Control (GNC) development schedule. Development began with a navigation sensor trade study using Linear Covariance (LinCov) analysis and a rapid sensor down-selection process, resulting in the use of commercial off-the-shelf (COTS) sensors which could be procured quickly and subjected to in-house environmental testing to qualify them for flight. A neural network was used to enable a COTS camera to provide bearing measure-ments for visual navigation. The GNC flight software (FSW) algorithms utilized lean development practices and leveraged the Core Flight Software (CFS) architecture to rapidly develop the GNC system, tune the system parameters, and verify performance in simulation. This pace was anchored by several Hardware-Software Integration (HSI) milestones, which forced the Seeker GNC team to develop the interfaces both between hardware and software and between the GNC domains early in the project and to enable a timely delivery.

Sullivan, Jake↗

Parallel-Processing Test Bed For Simulation Software

Second-generation Hypercluster computing system is multiprocessor test bed for research on parallel algorithms for simulation in fluid dynamics, electromagnetics, chemistry, and other fields with large computational requirements but relatively low input/output requirements. Built from standard, off-shelf hardware readily upgraded as improved technology becomes available. System used for experiments with such parallel-processing concepts as message-passing algorithms, debugging software tools, and computational steering. First-generation Hypercluster system described in "Hypercluster Parallel Processor" (LEW-15283).

Blech, Richard↗

Contour Error Map Algorithm

The contour error map (CEM) algorithm and the software that implements the algorithm are means of quantifying correlations between sets of time-varying data that are binarized and registered on spatial grids. The present version of the software is intended for use in evaluating numerical weather forecasts against observational sea-breeze data. In cases in which observational data come from off-grid stations, it is necessary to preprocess the observational data to transform them into gridded data. First, the wind direction is gridded and binarized so that D(i,j;n) is the input to CEM based on forecast data and d(i,j;n) is the input to CEM based on gridded observational data. Here, i and j are spatial indices representing 1.25-km intervals along the west-to-east and south-to-north directions, respectively; and n is a time index representing 5-minute intervals. A binary value of D or d = 0 corresponds to an offshore wind, whereas a value of D or d = 1 corresponds to an onshore wind. CEM includes two notable subalgorithms: One identifies and verifies sea-breeze boundaries; the other, which can be invoked optionally, performs an image-erosion function for the purpose of attempting to eliminate river-breeze contributions in the wind fields.

Merceret, Francis↗

NASA's Moon to Mars Autonomous Habitat Status

NASA is developing a strategy for sending humans to the Mars vicinity, known broadly as the Moon to Mars (M2M) Campaign. A critical part of this campaign is the development of in-space and surface habitation systems capable of substantially extending human presence beyond Low Earth Orbit (LEO). Mars missions feature an in-space transit habitat capable of supporting crews of four on ~850-1200-day missions, including transit to and from Mars and time in Mars orbit. Surface and transit habitats are complex elements which must keep crewmembers healthy and productive in deep-space environments with limited resources, long rescue times in contingency situations, and communication delays; all within constrained mass, volume, and power budgets. These habitats provide crew both living and workspace as well as most of the resources needed to support crew life. For deep space habitats, automation needs to be employed due to latency and for significant amounts of time when the habitats are uncrewed. Automation of systems is possible in space applications, but there are limitations. Outside of the Earth’s (or any) magnetosphere, radiation environments are harsh to both the physical hardware and the software components. Radiation (charged particles and ionizing electromagnetic waves) degrades and damages the hardware and causes single event upsets (SEUs) in software. If the hardware is damaged, data can be lost, or control actions not made. For software, SEUs cause algorithms to result in different solutions, or incorrect commands to be sent out. This means that algorithms and hardware used for deep space systems are different than what is used on Earth. Radiation-tolerant hardware is generations behind the current state-of-the-art hardware. Recent NASA missions, such as James Webb Space Telescope, continue to rely on older technologies such as the RAD750 processor, and the most advanced processors are still single core and less than 1.5 GHz. There have been attempts to use higher performance processors, but these often take multiple mitigation steps to handle the radiation environments, which limits the processing power and/or throughput. Current techniques for radiation mitigation have been redundancies, voting, physical separation of hardware, encasing materials, under-clocking hardware, and more. Some radiation mitigation techniques do provide benefits such as having a redundant system to improve the probability that a system will be available when needed. Autonomous software systems will have fewer interactions with humans on deep space missions and therefore need to be able to handle more off-nominal conditions. Microgravity also complicates the autonomous aspects of the mission because autonomous systems are usually built from known deterministic states, but microgravity causes physical objects to shift and move changing the location an autonomous system placed the object. Not only does the software need to be reliable and deterministic, losing resources due to a software error is not only costly but detrimental to reputation. The combination of having lower performance hardware and having to be able to verify and deterministically run software and an ever-changing environment makes deep space autonomous systems more complicated. Multiple gaps have been identified including verification of autonomous software algorithms (including artificial intelligence and machine learning), higher performance processors (graphics and general purpose), high speed networks (onboard and transmissions), memory, power distribution, data security, and variations from these. These gaps need to be closed for more advanced systems to be deployed and reduce the size, weight, and power impacts on the habitats.

Scott B. Tashakkor↗

Complete Decoding and Reporting of Aviation Routine Weather Reports (METARs)

Aviation Routine Weather Report (METAR) provides surface weather information at and around observation stations, including airport terminals. These weather observations are used by pilots for flight planning and by air traffic service providers for managing departure and arrival flights. The METARs are also an important source of weather data for Air Traffic Management (ATM) analysts and researchers at NASA and elsewhere. These researchers use METAR to correlate severe weather events with local or national air traffic actions that restrict air traffic, as one example. A METAR is made up of multiple groups of coded text, each with a specific standard coding format. These groups of coded text are located in two sections of a report: Body and Remarks. The coded text groups in a U.S. METAR are intended to follow the coding standards set by National Oceanic and Atmospheric Administration (NOAA). However, manual data entry and edits made by a human report observer may result in coded text elements that do not follow the standards, especially in the Remarks section. And contrary to the standards, some significant weather observations are noted only in the Remarks section and not in the Body section of the reports. While human readers can infer the intended meaning of non-standard coding of weather conditions, doing so with a computer program is far more challenging. However such programmatic pre-processing is necessary to enable efficient and faster database query when researchers need to perform any significant historical weather analysis. Therefore, to support such analysis, a computer algorithm was developed to identify groups of coded text anywhere in a report and to perform subsequent decoding in software. The algorithm considers common deviations from the standards and data entry mistakes made by observers. The implemented software code was tested to decode 12 million reports and the decoding process was able to completely interpret 99.93 of the reports. This document presents the deviations from the standards and the decoding algorithm. Storing all decoded data in a database allows users to quickly query a large amount of data and to perform data mining on the data. Users can specify complex query criteria not only on date or airport but also on weather condition. This document also describes the design of a database schema for storing the decoded data, and a Data Warehouse web application that allows users to perform reporting and analysis on the decoded data. Finally, this document presents a case study correlating dust storms reported in METARs from the Phoenix International airport with Ground Stops issued by Air Route Traffic Control Centers (ATCSCC). Blowing widespread dust is one of the weather conditions when dust storm occurs. By querying the database, 294 METARs were found to report blowing widespread dust at the Phoenix airport and 41 of them reported such condition only in the Remarks section of the reports. When METAR is a data source for an ATM research, it is important to include weather conditions not only from the Body section but also from the Remarks section of METARs.

METAR Decoder/Parser↗

Studies in Software Cost Model Behavior: Do We Really Understand Cost Model Performance?

While there exists extensive literature on software cost estimation techniques, industry practice continues to rely upon standard regression-based algorithms. These software effort models are typically calibrated or tuned to local conditions using local data. This paper cautions that current approaches to model calibration often produce sub-optimal models because of the large variance problem inherent in cost data and by including far more effort multipliers than the data supports. Building optimal models requires that a wider range of models be considered while correctly calibrating these models requires rejection rules that prune variables and records and use multiple criteria for evaluating model performance. The main contribution of this paper is to document a standard method that integrates formal model identification, estimation, and validation. It also documents what we call the large variance problem that is a leading cause of cost model brittleness or instability.

data mining↗

Space station dynamics, attitude control and momentum management

The Space Station Attitude Control System software test-bed provides a rigorous environment for the design, development and functional verification of GN and C algorithms and software. The approach taken for the simulation of the vehicle dynamics and environmental models using a computationally efficient algorithm is discussed. The simulation includes capabilities for docking/berthing dynamics, prescribed motion dynamics associated with the Mobile Remote Manipulator System (MRMS) and microgravity disturbances. The vehicle dynamics module interfaces with the test-bed through the central Communicator facility which is in turn driven by the Station Control Simulator (SCS) Executive. The Communicator addresses issues such as the interface between the discrete flight software and the continuous vehicle dynamics, and multi-programming aspects such as the complex flow of control in real-time programs. Combined with the flight software and redundancy management modules, the facility provides a flexible, user-oriented simulation platform.

Sunkel, John W.↗

Ascent, Transition, Entry, and Abort Guidance Algorithm Design for the X-33 Vehicle

One of the primary requirements for X-33 is that it be capable of flying autonomously. That is, onboard computers must be capable of commanding the entire flight from launch to landing, including cases where a single engine failure abort occurs. Guidance algorithms meeting these requirements have been tested in simulation and have been coded into prototype flight software. These algorithms must be sufficiently robust to account for vehicle and environmental dispersions, and must issue commands that result in the vehicle operating, within all constraints. Continual tests of these algorithms (and modifications as necessary) will occur over the next year as the X-33 nears its first flight. This paper describes the algorithms in use for X-33 ascent, transition, and entry flight, as well as for the powered phase of PowerPack-out (PPO) aborts (equivalent in thrust impact to losing an engine). All following discussion refers to these phases of flight when discussing guidance. The paper includes some trajectory results and results of dispersion analysis.

Hanson, John M.↗

ULTRA: Underwater Localization for Transit and Reconnaissance Autonomy

This software addresses the issue of underwater localization of unmanned vehicles and the inherent drift in their onboard sensors. The software gives a 2 to 3 factor of improvement over the state-of-the-art underwater localization algorithms. The software determines the localization (position, heading) of an AUV (autonomous underwater vehicle) in environments where there is no GPS signal. It accomplishes this using only the commanded position, onboard gyros/accelerometers, and the bathymetry of the bottom provided by an onboard sonar system. The software does not rely on an onboard bathymetry dataset, but instead incrementally determines the position of the AUV while mapping the bottom. In order to enable long-distance underwater navigation by AUVs, a localization method called ULTRA uses registration of the bathymetry data products produced by the onboard forward-looking sonar system for hazard avoidance during a transit to derive the motion and pose of the AUV in order to correct the DR (dead reckoning) estimates. The registration algorithm uses iterative point matching (IPM) combined with surface interpolation of the Iterative Closest Point (ICP) algorithm. This method was used previously at JPL for onboard unmanned ground vehicle localization, and has been optimized for efficient computational and memory use.

Huntsberger, Terrance L.↗

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↗

Description of the GMAO OSSE for Weather Analysis Software Package: Version 3

The Global Modeling and Assimilation Office (GMAO) at the NASA Goddard Space Flight Center has developed software and products for conducting observing system simulation experiments (OSSEs) for weather analysis applications. Such applications include estimations of potential effects of new observing instruments or data assimilation techniques on improving weather analysis and forecasts. The GMAO software creates simulated observations from nature run (NR) data sets and adds simulated errors to those observations. The algorithms employed are much more sophisticated, adding a much greater degree of realism, compared with OSSE systems currently available elsewhere. The algorithms employed, software designs, and validation procedures are described in this document. Instructions for using the software are also provided.

OSSE↗

Numerical arc segmentation algorithm for a radio conference - A software tool for communication satellite systems planning

A detailed description of a Numerical Arc Segmentation Algorithm for a Radio Conference (NASARC) software package for communication satellite systems planning is presented. This software provides a method of generating predetermined arc segments for use in the development of an allotment planning procedure to be carried out at the 1988 World Administrative Radio Conference (WARC - 88) on the use of the GEO and the planning of space services utilizing GEO. The features of the NASARC software package are described, and detailed information is given about the function of each of the four NASARC program modules. The results of a sample world scenario are presented and discussed.

Whyte, W. A.↗

Caesy: A software tool for computer-aided engineering

A new software tool, Caesy, is described. This tool provides a strongly typed programming environment for research in the development of algorithms and software for computer-aided control system design. A description of the user language and its implementation as they currently stand are presented along with a description of work in progress and areas of future work.

Wette, Matt↗

PredGuid+A: Orion Entry Guidance Modified for Aerocapture

PredGuid+A software was developed to enable a unique numerical predictor-corrector aerocapture guidance capability that builds on heritage Orion entry guidance algorithms. The software can be used for both planetary entry and aerocapture applications. Furthermore, PredGuid+A implements a new Delta-V minimization guidance option that can take the place of traditional targeting guidance and can result in substantial propellant savings. PredGuid+A allows the user to set a mode flag and input a target orbit's apoapsis and periapsis. Using bank angle control, the guidance will then guide the vehicle to the appropriate post-aerocapture orbit using one of two algorithms: Apoapsis Targeting or Delta-V Minimization (as chosen by the user). Recently, the PredGuid guidance algorithm was adapted for use in skip-entry scenarios for NASA's Orion multi-purpose crew vehicle (MPCV). To leverage flight heritage, most of Orion's entry guidance routines are adapted from the Apollo program.

Lafleur, Jarret↗