Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Graphics”

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 1,639 records · Page 91
All sourcesNASA NTRSDOE OSTI
NASA NTRS2014

Are We Alone? Kepler on a Quest

Two presentations, a technical and a non-technical with information about the Kepler Mission. Includes graphics on the telescope, how it works, the planets it has found. The technical includes couple of slides on the software pipeline architecture that helps detect the planets using Kepler Data. None of the Kepler graphics are newly created. Except the About Me slide everything else has been borrowed from not one but several different presentations, ones that I deemed helpful to me while doing my talks.

Kepler↗
NASA NTRS2019

Piloted Full-Motion Simulation in Simulink®

A recent experiment at NASA Ames Research Center’s Vertical Motion Simulator (VMS) successfully combined a real-time, human in-the-loop architecture with the flexibility of operating in the Simulink® graphical model-based engineering environment. The VMS is a large amplitude flight simulator designed to be adaptable to provide rapid integration and development of a wide variety of vehicles and support diverse aeronautical investigations. Math models are often programmed in Simulink. Typically, to run Simulink models in real time, they are converted to C code. However, the conversion and integration process can be time consuming and cumbersome. Thus, the VMS facility capabilities were expanded to allow a Simulink vehicle math model to run in the MathWorks’ MATLAB environment during a piloted full-motion simulation experiment. The MATLAB Simulink based approach to driving the VMS was found to decrease development time by allowing quick integration of math model changes and providing the ability to run the same version of the model on researcher’s desktop computers. This accomplishment demonstrated that the development ease of the graphical Simulink environment could be retained, while working within the real-time environment of the VMS architecture and maintaining the unique flexibility of the VMS.

Lewis, Emily K.↗
NASA NTRS2017

Flight Deck Surface Trajectory-Based Operations (STBO): A Four-Dimensional Trajectory (4DT) Simulation

In four-dimensional trajectory (4DT) Surface Trajectory-Based Operations (STBO), aircraft are assigned a conflict-free 4DT which defines an expected location (x,y coordinates) at all times, t, along the taxi route (with altitude, being fixed). These 4DTs afford the highest temporal certainty at all points along the taxi route, and at the departure runway. In the present study, a 4DT flight deck display was presented on the Airport Moving Map (AMM) to support pilot conformance to a 4DT clearance while taxiing under manual control. This pilot-in-the-loop simulation compared the effect of 4DT flight deck display formats on distance from the expected 4DT location, conformance to the displayed tolerance band, eyes-out time, and pilot ratings of safety and workload. In the defined-tolerance display format, a graphical representation of the expected 4DT location, with a distance-based allowable-tolerance band, was depicted on the AMM. Two defined-tolerance band sizes were tested: plus or minus 164 feet and plus or minus 405 feet. In the undefined-tolerance display format, the expected 4DT location was displayed graphically on the AMM, with no indicated allowable-tolerance bounds. Each taxi trial included 4DT speed changes (two or five, per trial) and a range of 4DT taxi speeds. Results showed that the larger (plus or minus 405 feet) defined-tolerance band yielded higher conformance levels than the smaller (plus or minus 164 feet) band, with pilots staying within the specified and displayed conformance bounds more in the larger (99.71%) than the smaller defined-tolerance band (93.37 percent). However, in terms of being able to predict the location of the aircraft compared to the expected 4DT location, the smaller defined-tolerance band resulted in pilots keeping their aircraft closer to the 4DT location, for both average distance and for a given confidence interval (e.g., 95 percent), than either the larger defined-tolerance band or the undefined-tolerance display format. The larger tolerance band yielded more “eyes-out-the-window” time than the smaller tolerance band. Pilots also rated taxing with the larger tolerance band as safer than the smaller tolerance band.

STBO↗
NASA NTRS2019

Updating the Space Communications and Navigation (SCaN) Link Tool Executable Software to Version 5

NASA’s Space Communications and Navigation (SCaN) program is responsible for providing space communication channels in low Earth orbit, geosynchronous orbit, and deep space for a variety of space missions. The SCaN Link Tool is a standalone, executable, and personal computer (PC)-based software operated via a user interface, which provides NASA civil servants and contractors, as well as the public by way of the tool’s inclusion in the NASA Software Catalog, with in-depth satellite communications link analysis capability. Version 4 of the tool was built using PythonTM (Python Software Foundation) with the help of libraries such as NumPy and SciPy for numerical calculations, Matplotlib for graphical visualizations, and PyQt5 for the graphical user interface. It utilizes radiofrequency (RF) and optical communications link analysis calculations to give users the ability to input known link parameters and calculate select link performance outputs. With the development of the next-generation architecture for space satellite communications in the coming decade, NASA will benefit by having more in-depth communications link analysis tools at its disposal. The tool’s update from version 4 to version 5 aims to provide higher output value accuracy, the ability to solve for a more diverse set of output variables, as well as analog and digital repeater capabilities. Options included in the tool’s functionality, such as the ability to save configuration parameter values, graphs, and results, as well as the provision of default parameter values, increase the tool’s versatility. Users will have access to in-depth, accurate communications link analysis as more advanced satellite constellations are designed and deployed by NASA and the growing commercial aerospace community.

Green, Jack L.↗
NASA NTRS2019

NASA Orbital Debris Engineering Model ORDEM 3.1 - Software User Guide

This National Aeronautics and Space Administration (NASA) Orbital Debris Engineering Model (ORDEM) 3.1 Software User Guide accompanies delivery of the latest upgraded version of the model, ORDEM 3.1. The user guide also provides a top-level program description and a list of capabilities. It includes descriptions of runtime error and information codes, input/output file formats, runtimes for different orbit configurations, and how to use uncertainty files. ORDEM 3.1 supersedes the previous NASA Orbital Debris Program Office (ODPO) models – ORDEM 3.0 (Stansbery, et al. 2014) and ORDEM2000 (Liou, et al. 2002). The availability of new sensor and in situ data, re-analysis of older data, and development of new analytical techniques has enabled the construction of this more comprehensive and sophisticated model. An upgraded graphical user interface (GUI) is integrated with the software. This upgraded GUI uses project-oriented organization and provides the user with graphical representations of numerous output data products. For example, these range from the conventional flux vs. average debris size (or altitude bin) for chosen analysis orbits (or views) to the more complex color-contoured, two-dimensional (2-D) directional flux diagrams in local spacecraft elevation and azimuth. The current model, ORDEM 3.1, supports spacecraft as well as telescope/radar project assessments. ORDEM 3.1 contains updated debris populations covering low Earth orbit (LEO, up to 2000 km altitude) to geosynchronous orbit (GEO, up to 40,000 km altitude) and can assess debris calculations up to year 2050, extending coverage past the previous limit of 2035 in ORDEM 3.0. Although populations differ from its predecessor, ORDEM 3.1 is functionally the same as ORDEM 3.0 and can support ORDEM 3.0 projects through backward compatibility.

Vavrin, Andrew B.↗
NASA NTRS2019

Macro-Scale Findings of the DebriSat Debris Field Obtained from X-Rays of the Catch Panels

The DebriSat project analyzes the debris from a hypervelocity impact test conducted on a 56 kg-simulated satellite target in 2014. Its purpose is to generate a comprehensive database of the size, mass, material, shape, and the radar and optical properties of fragments generated from orbital collisions of modern-built spacecraft. Three hundred ninety-one foam catch panels from the DebriSat test have been X-rayed to locate the particles within them for subsequent extraction and assessment. The data from the tens of thousands of extracted particles has heretofore been the focus of the debris assessment. The work presented here connects the X-ray sample location images to reconstruct the 3D distribution of the entire fragment cloud. Although some errors are inherent to the process, this 3D database is valuable for qualitative studies of size and energy distributions. Further, the 3D database can indicate the extent of bending or breaking of the fragments as they decelerated to full capture. By virtue of its full sphere perspective, the 3D database allows graphical insight to the physics of the collision and breakup. This 3D representation has been developed as a “point and click” graphical interface to retrieve the full data set on individual recovered and assessed fragments within the growing database. Overall, this macro-level screening technique has added enormous insight to the experiment in unexpected ways.

Allen, Anthony↗
NASA NTRS2020

How Loud is X-59's Shaped Sonic Boom?

NASA’s X-59 Quiet SuperSonic Technology low boom flight demonstrator aircraft is designed to produce a shaped sonic boom or “sonic thump” of 75 dB Perceived Level (PL) at the ground. One communication challenge that NASA’s Low Boom Flight Demonstration Mission faces is how to describe the sonic thump to the public, most of whom have never heard a sonic thump or a sonic boom. Furthermore, the public is unfamiliar with the acoustic metrics such as PL used to describe impulsive sounds. One technique to describe unfamiliar sounds using words and graphics only is to put them in the context of more familiar sounds, both in terms of acoustical level and in terms of sound type (continuous vs. impulsive). In this work, a database of recordings of familiar impulsive noise sources at known distances and their associated PL values was assembled and is available online. The comparison of these sounds can be framed as a “thermometer” of acoustic levels. An example acoustic thermometer graphic is presented. Additionally, the impulsive sounds’ one-third octave band sound pressure levels and sone spectra are compared to that of a simulated X-59 ground waveform. These show the origin of differences in the PL of each sound.

sonic boom↗
NASA NTRS2017

A CubeSat-Payload Radiation-Reliability Assurance Case using Goal Structuring Notation

CubeSats have become an attractive platform for universities, industry, and government space missions because they are cheaper and quicker to develop than full-scale satellites. One way CubeSats keep costs low is by using commercial off-the-shelf parts (COTS) instead of space-qualified parts. Space-qualified parts are often costlier, larger, and consume more power than their commercial counterparts precluding their use within the CubeSat form-factor. Given typical power budgets, monetary budgets, and timelines for CubeSat missions, conventional radiation hardness assurance, like the use of space-qualified parts and radiation testing campaigns of COTS parts, is not practical. Instead, a system-level approach to radiation effects mitigation is needed. In this paper an assurance case for a system-level approach to mitigate radiation effects of a CubeSat science experiment is expressed using Goal Structuring Notation (GSN), a graphical argument standard. The case specifically looks at three main mitigation strategies for the radiation environment: total ionizing dose (TID) screening of parts, detection and recovery from single-event latch-ups (SEL) and single-event functional interrupts (SEFI). The graphical assurance case presented makes a qualitative argument for the radiation reliability of the CubeSat experiment using part and system-level mitigation strategies.

COTS↗
NASA NTRS2021

Generation-based Evolutionary Tool for the Optimization of Constellations (GenETOC)

With the rapid growth in the capabilities of smaller satellites, satellite architectures that replace a single, extremely capable spacecraft with multiple, cheaper ones are gaining in popularity. Unfortunately, the orbit design process for constellations can be significantly more involved, especiallywhen the relative placement of the individual spacecraft within the constellation is not constrained by mission and/or science objectives. Optimizing a satellite constellation in the presence of multiple, competing objectives is a highly complex problem to which many traditional mathematical optimization methods cannot be applied and few tools exist to help mission designers search for promising candidate mission designs. The Generation-based Evolutionary Tool for the Optimization of Constellations (GenETOC) has been created to search for near-optimal constellation design options. GenETOC combines a modified version of the Non-dominated Sorting Genetic Algorithm II (NSGA II) with STK Components libraries (a 3rdparty .NET package created by Analytical Graphics Inc.) to create a framework that enables a mission designer to generate a simulation that models the design problem and obtain a family of potential, near-optimal solutions that can be investigated more in detail. GenETOC was developed in C# using the .NET framework with Windows Presentation Foundation (WPF) serving as the framework from which to create the graphical user interface (GUI). GenETOC user inputs can be categorized into three major data components: definition of the problem (areas of interest, satellite decision parameters, and sensor configurations), definition of performance objectives, and specification of the genetic algorithm (GA) parameters. In the problem definition component, the user is prompted to define the areas of interest against which the performance metrics will be computed, define the sensor parameters and attach them to specific spacecraft, select which satellite orbital parameters will be added to the decision space of the GA, and specify the range of desired values for each optimization parameter. For performance objectives, the user is presented with a list of available coverage and revisit performance based calculation options from which two metrics are chosen to serve as the objective functions that the GA will use to evaluate solutions during the optimization process. Finally, the definition of the GA parameters provides user control over the number of generations (number of optimization iterations), the population size (number of candidate constellations created in each generation), and the adaptive mutation and crossover threshold values (control parameters for how frequently each process occurs during the optimization). GenETOC has been extensively tested to verify the individual components of the optimization process. The GA has been tested against a suite of GA test problems to confirm convergence to the known two and three-dimensional Pareto fronts. The coverage and revisit performance metrics obtained in GenETOC are compared with STK desktop scenarios, confirming the constellations are being appropriately modeled within GenETOC simulations. A walkthrough of a simple, example problem is provided to illustrate the workings of GenETOC and to demonstrate the output available to the mission designer.

mission design↗
NASA NTRS1996

Off-the-Shelf Real-Time Monitoring of Satellite Constellations in a Visual 3-D Environment

The MSAS Data Monitor is a generic software product that represents the next-generation in real-time data monitoring and analysis tools. It goes beyond conventional text-based displays by representing data in a unique graphical form, conveying system status through the shape, color, motion, and position of graphical objects floating in a three-dimensional cyberspace environment...This paper describes some of the details and benefits of the MSAS monitoring and analysis suite, with primary focus on the Data Monitor.

MSAS↗
NASA NTRS1995

Virtual Reality Calibration and Preview/Predictive Displays for Telerobotics

A virtual reality (VR) calibration technique of matching a virtual environment of simulated 3-D graphic models with actual camera views of the remote site task environment has been developed. This VR calibration enables high-fidelity preview/predictive displays with calibrated graphics overlay on live video. Reliable and accurate calibration is achieved by operator-interactive camera calibration and object localization procedures based on new linear/nonlinear least-squares algorithms that can handle multiple-camera views.

Virtual↗
NASA NTRS1993

Demonstration of A High-Fidelity Predictive/Preview Display Technique for Telerobotic Servicing in Space

A highly effective predictive/preview display technique for telerobotic servicing in space under several seconds communication time delay has been demonstrated on a large laboratory scale in May, 1993, involving the Jet Propulsion Laboratory as the simulated ground control station and, 2500 miles away, the Goddard Space Flight Center as the simulated satellite servicing set-up. The technique isbased on a high-fidelity calibration procedure that enables a high-fidelity overlay of 3-D graphics robot arm and object models over given 2-D TV camera images of robot arm and objects. Togenerate robot arm motions, the operator can confidently interact in real time with the graphics models of the robot arm and objects overlaid on an actual camera view of the remote work site. The technique also enables the operator to generate high-fidelity synthetic TV camera views showing motion events that are hidden in a given TV camera view or for which no TV camera views are available...

Bejczy, A. K.↗
NASA NTRS2018

The InSAR Scientific Computing Environment 3.0: A Flexible Framework for NISAR Operational and User-Led Science Processing

The InSAR Scientific Computing Environment (ISCE) was first developed under the NASA Advanced Information Systems Technology as a flexible, extensible object-oriented framework for Interferometric Synthetic Aperture Radar (InSAR) processing. The ISCE framework uses Python 3 at the workflow level, controlling modules of compiled code for functional processing, and managing inputs, outputs, and other flow control services. The currently released version, called ISCE 2.1, is distributed to the research community through the Western North America InSAR Consortium under a research license. The ISCE team is working on the next generation of the code in order to prepare for the NASAISRO SAR (NISAR) mission operational processing. Innovations in this code include augmentation or conversion of the custom Python framework elements in ISCE with the Pyre framework, new workflows for interferometric and polarimetric stack processing, a more intuitive and graphically based user interface, and flow control for hybrid computing environments including CPU/GPU clusters, logging and error tracking facilities, and new more efficient computational modules that exploit graphical processor units (GPUs) when available. The ISCE 3.0 framework is designed to work in an operational environment as well as on a single user’s laptop or compute cluster, with services to discover capabilities and scale computations accordingly.

Buckley, Sean M.↗
NASA NTRSDate not supplied

Utilizing Gaps and Key Performance Parameters to Inform NASA Environmental Control and Life Support and Human Health and Performance Capability Technology Decisions

Human spaceflight is a complex endeavor requiring a multitude of capabilities for transportation, crew health, scientific goals, and safe return to Earth. The difference between spaceflight proven capabilities and those needed for a particular mission is defined as a capability gap. Capability gaps are not technology specific. Each capability gap is approachable with a wide array of technologies that have unique benefits and challenges. Determining what a capability’s relevant and distinguishing key performance parameters (KPPs) are for a mission is critical. Mass, power, and volume are always constrained and important, but defining these in a way normalized by performance is challenging. Additionally, KPP definition for reliability, dormancy, and integration needs are very important and still evolving. This paper provides the approach of the Environmental Control and Life Support – Crew Health and Performance (ECLSS-CHP) System Capability Leadership Team (SCLT) to defining gaps and KPPs in support of the NASA’s Capabilities Integration Team data call objectives. The nine ECLSS-CHP capability areas are decomposed to capabilities, gaps, and KPPs. Rather than defining very detailed gaps, ECLSS-CHP defines high-level gaps to be technology agnostic. Within a gap, detailed KPPs are defined to both compare technologies and measure progress within a technology over time. Ideally, KPPs are clearly defined, widely communicated both internally and externally, and provide a common nomenclature to describe the state of the art and the degree of improvement required for exploration missions. KPPs help define when the gap is closed and the core mission objectives can be accomplished. Further technology improvements to enhance the capability, as measured by improved KPPs, must then be weighed against investments in open capability gaps that prevent NASA from achieving its exploration missions. It is uncommon that a technology maturation to improve all the relevant KPPs simultaneously but using KPPs is a critical technology investment decision making component. In addition to traditional technology selections, KPPs are informing how investments in ground testing prior to and in parallel with ISS technology demonstrations are required to improve reliability KPPs. The collection of all major technology activities within a capability area are captured on technology roadmaps to communicate how diverse program activities are coordinated to close gaps and infuse into exploration mission needs. A selection of ECLSS-CHP gaps and KPPs and their formulation, current state, and how they inform capability roadmap planning are discussed. The paper will contain a summary of the approximately 60 gaps. Gaps are classified as to their type (architecture, knowledge, technology, developmental, or engineering) depending on the magnitude of the gap. The paper will provide brief overviews of a few major technology challenges and the technologies being considered, but will reference detailed papers for a more thorough treatment of the challenges and state of the art. Data analysis of the gaps is in work and results are not currently available for this abstract. It is anticipated the paper will include examples of select KPPs with descriptions as to why these are the relevant measures. Additionally some KPPs will be graphically presented over time to show progress to date and when performance targets need to be achieved to support exploration missions. Graphical summaries of how gaps closures with near term mission elements support follow-on mission elements will be provided.

Life Support↗
NASA NTRSDate not supplied

Digital Lunar Exploration Sites (DLES)

It has been almost 50 years since humans last set foot on the Moon. With NASA’s Artemis program, the United States and its international and commercial partners are embarking on a new endeavor to explore the lunar surface. Before we return, we will have simulated every aspect of these future missions. Many of these models and simulations (M&S) will rely on well-known and commonly-used technologies, some of which trace their origins back to the Apollo program. However, M&S has advanced significantly, as have the underlying computational capabilities. As a result, we are able to model many more aspects of the Artemis vehicles and support systems with significantly improved detail and confidence. Accurately and efficiently modeling the lunar environment will be critical to simulating the Artemis elements and mission activities. This includes characterizing and modeling lunar topography, smaller craters, exposed surface rocks, lunar regolith, surface lighting, and ambient thermal environment. These are all necessary for understanding fundamental behaviors and performance of vehicles and support systems in the lunar environment and are often determining factors in the selection of exploration sites and defining mission profiles. The Astromaterials Research and Exploration Sciences (ARES) team in the Exploration Integration and Science Directorate at NASA’s Johnson Space Center (JSC) and the NASA Exploration Systems Simulations (NExSyS) team in the Simulation and Graphics Branch at JSC are developing and maintaining the Digital Lunar Exploration Sites (DLES) data, documentation, and software packages. This data is being fed directly into a diverse collection of graphics and simulation environments, where it is used to construct the closest known truth for numerous potential Lunar South Pole landing sites. DLES is available to projects across NASA and particularly the Artemis program to support coordinated digital representations of the lunar environment. This paper describes the fundamental need for DLES, the science data sets that are going into DLES, some of the processes used to integrate this data into DLES products, the basic products that constitute DLES, and some examples of DLES in use.

Lunar↗
NASA NTRSDate not supplied

SIRIUS: Simulation Infrastructure for Research on Interoperating Unmanned Systems

This paper presents the Simulation Infrastructure for Research on Interoperating Unmanned Systems (SIRIUS), a research framework for simulation and analysis of future conceptual Urban Air Mobility (UAM) operations. SIRIUS is being developed under the auspices of the NASA Air Traffic Management eXploration project, UAM subproject (ATM-X UAM). SIRIUS provides an intuitive, highly configurable graphical user interface to design complex traffic scenarios and airspace configurations representative of conceptual UAM operations. Aircraft simulated with SIRIUS can be equipped with flight-tested capabilities for detect and avoid (DAA), geofencing, distributed merging and spacing, path conformance, and path planning while executing time-constrained, 4D trajectories generated by a UAM ground operations system. Central to the design of the SIRIUS simulation framework is the capability to evaluate the integration and interoperability of ground-based separation services (e.g., strategic separation) with extended DAA functionality (e.g., path monitoring, separation provision, merging and spacing, etc.) The simulation environment also supports modelling of wind, navigation, and sensor uncertainties, as well as communication delays. SIRIUS enables distributed simulation of large-scale scenarios. An interactive graphical analysis capability helps isolate, visualize, and compare relevant vehicle state data and widely used measures of performance metrics across multiple scenarios.

Andrew Peters↗
NASA NTRSDate not supplied

NESC GN&C TDT Workshop on 2D Image Motion Optical Transfer Functions, Pointing Performance Analysis, and Requirements

What You Will Learn: The focus is on payload imaging performance due to pointing motion. Some historical background on pointing performance analysis is given. The Optical Transfer Function (OTF) and Modulation Transfer Function (MTF) are defined. The imaging performance due to pointing motion is measured by image motion optical transfer functions (IM OTF). IM OTFs are defined for displacement, smear, and jitter motions, which are all rigorously defined. Deterministic and Statistical IM OTFs are briefly derived and graphically illustrated and compared. The IM OTFs are parameterized by pointing error metrics(PEM), which are means and covariances of displacement, smear, and jitter. Emphasis is on procedures and algorithms to evaluate the image motion optical transfer functions and pointing error metrics. Three procedures are covered, which depend on whether the pointing error data is from time-domain simulation, frequency-domain analysis, or stochastic modeling. A method to evaluate the relative contribution of disturbance sources and to identify the most significant contributors is presented. The presentation includes pertinent discussion of flexible structures and control-structure interaction. No single book can adequately cover this subject, so a book is not required for the course. A list of selected articles, reports, documents, and books is provided for reference and further study. Mathis kept to the minimum necessary to convey principles; lengthy derivations are left to the reference material. Graphics are used to illustrate concepts. As with any such learning endeavor, the knowledge gained will be retained and strengthened through actual practice.c©2019–2021 Mark E. Pittelkau— 5

NASA Engineering and Safety Center (NESC)↗
NASA NTRSDate not supplied

Ray Tracing Techniques for the Characterization of Lunar Communication Architectures

This paper provides an overview of the computational techniques used to characterize the viability of different lunar architectures and their ability to provide communication services to the lunar surface. This analysis was done with modern ray tracing techniques that allow for the computations to be done on Graphics Processing Unit (GPU) clusters for a high level of parallelism and severe reduction in computation time. The ray tracing computations were done with the GPU platform Compute Unified Device Architecture (CUDA) provided by NVIDIA which utilizes general-purpose computing on graphics processing units (GPGPU). This new method provides the advantage of being able to characterize a much larger portion of the lunar surface due to its computational efficiency as well as providing a more accurate representation of elevation angle limits instead of the typical and often inaccurate elevation angle mask. The Lunar surface can now be characterized with metrics such as contact time, outage time, and received data rate. With these metrics, different proposed Lunar architectures can be rapidly evaluated. This reduction in computation time not only leads to more accurate results but allows these results to be obtained in a time frame that allows for the complete characterization of the trade space. It is expected that these different architecture comparisons will lead to a conclusive determination of the optimal Lunar architecture and will allow for future Lunar missions to operate as close to real time as possible. In addition, this computation method can be used to recreate visibility figures generated by previous methods but with an increased level of accuracy.

Thomas Montano↗