Search NASA⌕ Search

SEARCH · Search NASA

Results for “standard user interface”

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 379 records · Page 21

Implementation of a low-cost, commercial orbit determination system

This paper describes the implementation and potential applications of a workstation-based orbit determination system developed by Storm Integration, Inc. called the Precision Orbit Determination System (PODS). PODS is offered as a layered product to the commercially-available Satellite Tool Kit (STK) produced by Analytical Graphics, Inc. PODS also incorporates the Workstation/Precision Orbit Determination (WS/POD) product offered by Van Martin System, Inc. The STK graphical user interface is used to access and invoke the PODS capabilities and to display the results. WS/POD is used to compute a best-fit solution to user-supplied tracking data. PODS provides the capability to simultaneously estimate the orbits of up to 99 satellites based on a wide variety of observation types including angles, range, range rate, and Global Positioning System (GPS) data. PODS can also estimate ground facility locations, Earth geopotential model coefficients, solar pressure and atmospheric drag parameters, and observation data biases. All determined data is automatically incorporated into the STK data base, which allows storage, manipulation and export of the data to other applications. PODS is offered in three levels: Standard, Basic GPS and Extended GPS. Standard allows processing of non-GPS observation types for any number of vehicles and facilities. Basic GPS adds processing of GPS pseudo-ranging data to the Standard capabilities. Extended GPS adds the ability to process GPS carrier phase data.

Corrigan, Jim↗

Statistical Analysis of Model Data for Operational Space Launch Weather Support at Kennedy Space Center and Cape Canaveral Air Force Station

The 12-km resolution North American Mesoscale (NAM) model (MesoNAM) is used by the 45th Weather Squadron (45 WS) Launch Weather Officers at Kennedy Space Center (KSC) and Cape Canaveral Air Force Station (CCAFS) to support space launch weather operations. The 45 WS tasked the Applied Meteorology Unit to conduct an objective statistics-based analysis of MesoNAM output compared to wind tower mesonet observations and then develop a an operational tool to display the results. The National Centers for Environmental Prediction began running the current version of the MesoNAM in mid-August 2006. The period of record for the dataset was 1 September 2006 - 31 January 2010. The AMU evaluated MesoNAM hourly forecasts from 0 to 84 hours based on model initialization times of 00, 06, 12 and 18 UTC. The MesoNAM forecast winds, temperature and dew point were compared to the observed values of these parameters from the sensors in the KSC/CCAFS wind tower network. The data sets were stratified by model initialization time, month and onshore/offshore flow for each wind tower. Statistics computed included bias (mean difference), standard deviation of the bias, root mean square error (RMSE) and a hypothesis test for bias = O. Twelve wind towers located in close proximity to key launch complexes were used for the statistical analysis with the sensors on the towers positioned at varying heights to include 6 ft, 30 ft, 54 ft, 60 ft, 90 ft, 162 ft, 204 ft and 230 ft depending on the launch vehicle and associated weather launch commit criteria being evaluated. These twelve wind towers support activities for the Space Shuttle (launch and landing), Delta IV, Atlas V and Falcon 9 launch vehicles. For all twelve towers, the results indicate a diurnal signal in the bias of temperature (T) and weaker but discernable diurnal signal in the bias of dewpoint temperature (T(sub d)) in the MesoNAM forecasts. Also, the standard deviation of the bias and RMSE of T, T(sub d), wind speed and wind direction indicated the model error increased with the forecast period all four parameters. The hypothesis testing uses statistics to determine the probability that a given hypothesis is true. The goal of using the hypothesis test was to determine if the model bias of any of the parameters assessed throughout the model forecast period was statistically zero. For th is dataset, if this test produced a value >= -1 .96 or <= 1.96 for a data point, then the bias at that point was effectively zero and the model forecast for that point was considered to have no error. A graphical user interface (GUI) was developed so the 45 WS would have an operational tool at their disposal that would be easy to navigate among the multiple stratifications of information to include tower locations, month, model initialization times, sensor heights and onshore/offshore flow. The AMU developed the GUI using HyperText Markup Language (HTML) so the tool could be used in most popular web browsers with computers running different operating systems such as Microsoft Windows and Linux.

Bauman, William H., III↗

How far away is plug 'n' play? Assessing the near-term potential of sonification and auditory display

The commercial music industry offers a broad range of plug 'n' play hardware and software scaled to music professionals and scaled to a broad consumer market. The principles of sound synthesis utilized in these products are relevant to application in virtual environments (VE). However, the closed architectures used in commercial music synthesizers are prohibitive to low-level control during real-time rendering, and the algorithms and sounds themselves are not standardized from product to product. To bring sound into VE requires a new generation of open architectures designed for human-controlled performance from interfaces embedded in immersive environments. This presentation addresses the state of the sonic arts in scientific computing and VE, analyzes research challenges facing sound computation, and offers suggestions regarding tools we might expect to become available during the next few years. A list of classes of audio functionality in VE includes sonification -- the use of sound to represent data from numerical models; 3D auditory display (spatialization and localization, also called externalization); navigation cues for positional orientation and for finding items or regions inside large spaces; voice recognition for controlling the computer; external communications between users in different spaces; and feedback to the user concerning his own actions or the state of the application interface. To effectively convey this considerable variety of signals, we apply principles of acoustic design to ensure the messages are neither confusing nor competing. We approach the design of auditory experience through a comprehensive structure for messages, and message interplay we refer to as an Automated Sound Environment. Our research addresses real-time sound synthesis, real-time signal processing and localization, interactive control of high-dimensional systems, and synchronization of sound and graphics.

Bargar, Robin↗

LAURA Users Manual: 5.5-64987

This users manual provides in-depth information concerning installation and execution of LAURA, version 5. LAURA is a structured, multi-block, computational aerothermodynamic simulation code. Version 5 represents a major refactoring of the original Fortran 77 LAURA code toward a modular structure afforded by Fortran 95. The refactoring improved usability and maintain ability by eliminating the requirement for problem dependent recompilations, providing more intuitive distribution of functionality, and simplifying interfaces required for multi-physics coupling. As a result, LAURA now shares gas-physics modules, MPI modules, and other low-level modules with the Fun3D unstructured-grid code. In addition to internal refactoring, several new features and capabilities have been added, e.g., a GNU standard installation process, parallel load balancing, automatic trajectory point sequencing, free-energy minimization, and coupled ablation and flowfield radiation.

Mazaheri, Alireza↗

Laura Users Manual: 5.1-41601

This users manual provides in-depth information concerning installation and execution of LAURA, version 5. LAURA is a structured, multi-block, computational aerothermodynamic simulation code. Version 5 represents a major refactoring of the original Fortran 77 LAURA code toward a modular structure afforded by Fortran 95. The refactoring improved usability and maintainability by eliminating the requirement for problem-dependent re-compilations, providing more intuitive distribution of functionality, and simplifying interfaces required for multiphysics coupling. As a result, LAURA now shares gas-physics modules, MPI modules, and other low-level modules with the FUN3D unstructured-grid code. In addition to internal refactoring, several new features and capabilities have been added, e.g., a GNU-standard installation process, parallel load balancing, automatic trajectory point sequencing, free-energy minimization, and coupled ablation and flowfield radiation.

Mazaheri, Alireza↗

LAURA Users Manual: 5.2-43231

This users manual provides in-depth information concerning installation and execution of LAURA, version 5. LAURA is a structured, multi-block, computational aerothermodynamic simulation code. Version 5 represents a major refactoring of the original Fortran 77 LAURA code toward a modular structure afforded by Fortran 95. The refactoring improved usability and maintainability by eliminating the requirement for problem-dependent re-compilations, providing more intuitive distribution of functionality, and simplifying interfaces required for multiphysics coupling. As a result, LAURA now shares gas-physics modules, MPI modules, and other low-level modules with the FUN3D unstructured-grid code. In addition to internal refactoring, several new features and capabilities have been added, e.g., a GNU-standard installation process, parallel load balancing, automatic trajectory point sequencing, free-energy minimization, and coupled ablation and flowfield radiation.

Mazaheri, Alireza↗

Next Generation Flight Displays Using HTML5

The Human Integrated Vehicles and Environments (HIVE) lab at Johnson Space Center (JSC) is focused on bringing together inter-disciplinary talent to design and integrate innovative human interface technologies for next generation manned spacecraft. As part of this objective, my summer internship project centered on an ongoing investigation in to building flight displays using the HTML5 standard. Specifically, the goals of my project were to build and demo "flight-like" crew and wearable displays as well as create a webserver for live systems being developed by the Advanced Exploration Systems (AES) program. In parallel to my project, a LabVIEW application, called a display server, was created by the HIVE that uses an XTCE (XML (Extensible Markup Language) Telemetry and Command Exchange) parser and CCSDS (Consultative Committee for Space Data System) space packet decoder to translate telemetry items sent by the CFS (Core Flight Software) over User Datagram Protocol (UDP). It was the webserver's job to receive these UDP messages and send them to the displays. To accomplish this functionality, I utilized Node.js and the accompanying Express framework. On the display side, I was responsible for creating the power system (AMPS) displays. I did this by using HTML5, CSS and JavaScript to create web pages that could update and change dynamically based on the data they received from the webserver. At this point, I have not started on the commanding, being able to send back to the CFS, portion of the displays but hope to have this functionality working by the completion of my internship. I also created a way to test the webserver's functionality without the display server by making a JavaScript application that read in a comma-separate values (CSV) file and converted it to XML which was then sent over UDP. One of the major requirements of my project was to build everything using as little preexisting code as possible, which I accomplished by only using a handful of JavaScript libraries. As a side project, I created a model of the HIVE lab and Building 29 using SketchUp. I obtained the floorplans of the building from the JSC Geographic Information Systems (GIS), which were computer-aided design (CAD) files, and imported them into SketchUp. I then took those floorplans and created a 3D model of the building from them. Working in conjunction with the Hybrid Reality lab in Building 32, the SketchUp model was imported into Unreal Engine for use with the HTC Vive. Using the Vive, I was able to interact with the model I created in virtual reality (VR). The purpose of this side project was to be able to visualize potential lab layouts and mockup designs as they are in development in order to finalize design decisions. Pending approval, the model that I created will be used in the Build-As-You-Test: Can Hybrid Reality Improve the SE/HSI Design Process project in the fall. Getting the opportunity to work at NASA has been one of the most memorable experiences of my life. Over the course of my internship, I improved my programming and web development abilities substantially. I will take all the skills and experiences I have had while at NASA back to school with me in the fall and hope to pursue a career in the aerospace industry after graduating in the spring.

Greenwood, Brian↗

LAURA Users Manual: 5.4-54166

This users manual provides in-depth information concerning installation and execution of Laura, version 5. Laura is a structured, multi-block, computational aerothermodynamic simulation code. Version 5 represents a major refactoring of the original Fortran 77 Laura code toward a modular structure afforded by Fortran 95. The refactoring improved usability and maintainability by eliminating the requirement for problem dependent re-compilations, providing more intuitive distribution of functionality, and simplifying interfaces required for multi-physics coupling. As a result, Laura now shares gas-physics modules, MPI modules, and other low-level modules with the Fun3D unstructured-grid code. In addition to internal refactoring, several new features and capabilities have been added, e.g., a GNU-standard installation process, parallel load balancing, automatic trajectory point sequencing, free-energy minimization, and coupled ablation and flowfield radiation.

Mazaheri, Alireza↗

Sally Ride EarthKAM - Automated Image Geo-Referencing Using Google Earth Web Plug-In

Sally Ride EarthKAM is an educational program funded by NASA that aims to provide the public the ability to picture Earth from the perspective of the International Space Station (ISS). A computer-controlled camera is mounted on the ISS in a nadir-pointing window; however, timing limitations in the system cause inaccurate positional metadata. Manually correcting images within an orbit allows the positional metadata to be improved using mathematical regressions. The manual correction process is time-consuming and thus, unfeasible for a large number of images. The standard Google Earth program allows for the importing of KML (keyhole markup language) files that previously were created. These KML file-based overlays could then be manually manipulated as image overlays, saved, and then uploaded to the project server where they are parsed and the metadata in the database is updated. The new interface eliminates the need to save, download, open, re-save, and upload the KML files. Everything is processed on the Web, and all manipulations go directly into the database. Administrators also have the control to discard any single correction that was made and validate a correction. This program streamlines a process that previously required several critical steps and was probably too complex for the average user to complete successfully. The new process is theoretically simple enough for members of the public to make use of and contribute to the success of the Sally Ride EarthKAM project. Using the Google Earth Web plug-in, EarthKAM images, and associated metadata, this software allows users to interactively manipulate an EarthKAM image overlay, and update and improve the associated metadata. The Web interface uses the Google Earth JavaScript API along with PHP-PostgreSQL to present the user the same interface capabilities without leaving the Web. The simpler graphical user interface will allow the public to participate directly and meaningfully with EarthKAM. The use of similar techniques is being investigated to place ground-based observations in a Google Mars environment, allowing the MSL (Mars Science Laboratory) Science Team a means to visualize the rover and its environment.

Andres, Paul M.↗

LAURA Users Manual: 5.3-48528

This users manual provides in-depth information concerning installation and execution of LAURA, version 5. LAURA is a structured, multi-block, computational aerothermodynamic simulation code. Version 5 represents a major refactoring of the original Fortran 77 LAURA code toward a modular structure afforded by Fortran 95. The refactoring improved usability and maintainability by eliminating the requirement for problem-dependent re-compilations, providing more intuitive distribution of functionality, and simplifying interfaces required for multi-physics coupling. As a result, LAURA now shares gas-physics modules, MPI modules, and other low-level modules with the FUN3D unstructured-grid code. In addition to internal refactoring, several new features and capabilities have been added, e.g., a GNU-standard installation process, parallel load balancing, automatic trajectory point sequencing, free-energy minimization, and coupled ablation and flowfield radiation.

Mazaheri, Alireza↗

Design and Development of Functionally Effective Human-Machine Interfaces for Firing Room Displays

This project involves creating software for support equipment used on the Space Launch System (SLS). The goal is to create applications and displays that will be used to remotely operate equipment from the firing room and will continue to support the SLS launch vehicle to the extent of its program. These displays include design practices that help to convey information effectively, such as minimizing distractions at normal operating state and displaying intentional distractions during a warning or alarm state. The general practice for creating an operator display is to reduce the detail of unimportant aspects of the display and promote focus on data and dynamic information. These practices include using minimalist design, using muted tones for background colors, using a standard font at a readable text size, displaying alarms visible for immediate attention, grouping data logically, and displaying data appropriately varying on the type of data. Users of these displays are more likely to stay focused on operating for longer periods by using design practices that reduce eye strain and fatigue. Effective operator displays will improve safety by reducing human errors during operation, which will help prevent catastrophic accidents. This report entails the details of my work on developing remote displays for the Hypergolic fuel servicing system. Before developing a prototype display, the design and requirements of the system are outlined and compiled into a document. Then each subsystem has schematic representations drawn that meet the specifications detailed in the document. The schematics are then used as the outline to create display representations of each subsystem. Each display is first tested individually. Then the displays are integrated with a prototype of the master system, and they are tested in a simulated environment then retested in the real environment. Extensive testing is important to ensure the displays function reliably as intended.

displays↗

Design and Development of Functionally Effective Human-Machine Interfaces for Firing Room Displays

This project involves creating software for support equipment used on the Space l aunch System (SLS). The goal is to create applications and displays that will be used to remotely operate equipment from the firing room and will continue to support the SLS launch vehicle to the extent of its program. These displays include design practices that help to convey information effectively, such as minimizing distractions at normal operating state and displaying intentional distractions during a warning or alarm state. The general practice for creating an operator display is to reduce the detail of unimportant aspects of the display and promote focus on data and dynamic information. These practices include using minimalist design, using muted tones for background colors, using a standard font at a readable text size, displaying alarms visible for Immediate attention, grouping data logically, and displaying data appropriately varying on the type of data. Users of these displays are more likely to stay focused on operating for longer periods by using design practices that reduce eye strain and fatigue. Effective operator displays will improve safety by reducing human errors during operation, which will help prevent catastrophic accidents. This report entails the details of my work on developing remote displays for the Hypergolics ground system. Before developing a prototype display, the design and requirements of the system are outlined and compiled into a document. Then each subsystem has schematic representations drawn tha.t meet the specifications detailed in the document. The schematics are then used as the outline to create display representations of each subsystem. Each display is first tested individually. Then the displays are integrated with a prototype of the master system, and they are tested in a simulated environment then retested in the real environment. Extensive testing is important to ensure the displays function reliably as intended.

Cho, Henry↗

What is the Role of Usability and Trust in Autonomy?

Usability encompasses learnability, efficiency, memorability, effectiveness, and satisfaction. NASA’s standards for usability acceptance criteria focus on interfaces that help operators achieve their tasks efficiently, effectively, and with satisfaction. However, discussions on usability, especially regarding future highly automated and autonomous systems, rarely include trust. As NASA plans for long-duration exploration missions, it envisions astronauts operating more independently from Mission Control on Earth. This independence will drive the development of these highly automated and autonomous systems that astronauts will use daily. To prepare for this future, our team has developed a scheduling and execution software tool that facilitates self-scheduling, allowing astronauts to independently manage their own schedule without Mission Control’s involvement. Over many years, we have developed, matured, and evaluated our software tool in extreme environments, prioritizing user-centered design and high usability. These evaluations have included multiple campaigns in NASA analogs, including NEEMO, BASALT, and HERA, as well as technology demonstrations onboard the International Space Station. Our recent research on software interfaces for future astronaut autonomy revealed a strong correlation between usability and trust measures. In a controlled lab experiment, we asked novice users to perform a complex scheduling task, during which the software immediately validated the schedule’s constraints and checked for violations. We collected usability (User Experience Questionnaire, UEQ) and trust (Trust in Automated Systems scale, TAS) measures; significant, strong, and moderate correlations emerged between several of the UEQ metrics and TAS. These results support the argument for investing in usability early to enable and sustain trust in highly automated and autonomous systems.

usability↗

BioSensor Users' Guide

The BioSensor is a fully autonomous 3-color LED-based spectrophotometer paired with a fluidics system that supports microbes in liquid culture. Originally developed for the BioSentinel CubeSat mission to study the response of a wild type and mutant strain of yeast to the deep space environment, the BioSensor consists of a series of 16-well, independently plumbed fluidics cards. The cards utilize filters to allow the fluidic system to administer reagents while constraining the microbes in their wells. Heaters on each card incubate to the appropriate growth temperature once the experiment begins. During the active experiment, the LED/detector system measures the transmission of light through each well at three specific wavelengths, similar to a standard benchtop spectrophotometer. The transmission/absorbance kinetics curves for each well are telemetered back to Earth, along with temperature data, for analysis on the ground. The BioSensor is being upgraded from its original CubeSat free-flyer interface to be a secondary payload on lunar landers, Gateway, and other BLEO applications, while maintaining the same functionality and science utility for future experiments.

Matthew Lera↗

BioSensor Users' Guide

The BioSensor is a fully autonomous 3-color LED-based spectrophotometer paired with a fluidics system that supports microbes in liquid culture. Originally developed for the BioSentinel CubeSat mission to study the response of a wild type and mutant strain of yeast to the deep space environment, the BioSensor consists of a series of 16-well, independently plumbed fluidics cards. The cards utilize filters to allow the fluidic system to administer reagents while constraining the microbes in their wells. Heaters on each card incubate to the appropriate growth temperature once the experiment begins. During the active experiment, the LED/detector system measures the transmission of light through each well at three specific wavelengths, similar to a standard benchtop spectrophotometer. The transmission/ absorbance kinetics curves for each well are telemetered back to Earth, along with temperature data, for analysis on the ground. The BioSensor is being upgraded from its original CubeSat free-flyer interface to be a secondary payload on lunar landers, Gateway, and other BLEO applications, while maintaining the same functionality and science utility for future experiments.

Matthew Lera↗

The Critical Point Facility (CPF)

The Critical Point Facility (CPF) is an ESA multiuser facility designed for microgravity research onboard Spacelab. It has been conceived and built to offer investigators opportunities to conduct research on critical point phenomena in microgravity. This facility provides the high precision and stability temperature standards required in this field of research. It has been primarily designed for the purpose of optical investigations of transparent fluids. During a Spacelab mission, the CPF automatically processes several thermostats sequentially, each thermostat corresponding to an experiment. The CPF is now integrated in Spacelab at Kennedy Space Center, in preparation for the International Microgravity Lab. mission. The CPF was designed to submit transparent fluids to an adequate, user defined thermal scenario, and to monitor their behavior by using thermal and optical means. Because they are strongly affected by gravity, a good understanding of critical phenomena in fluids can only be gained in low gravity conditions. Fluids at the critical point become compressed under their own weight. The role played by gravity in the formation of interfaces between distinct phases is not clearly understood.

Source record↗

ISTP CDF Skeleton Editor

Basic Common Data Format (CDF) tools (e.g., cdfedit) provide no specific support for creating International Solar-Terrestrial Physics/Space Physics Data Facility (ISTP/SPDF) standard files. While it is possible for someone who is familiar with the ISTP/SPDF metadata guidelines to create compliant files using just the basic tools, the process is error-prone and unreasonable for someone without ISTP/SPDF expertise. The key problem is the lack of a tool with specific support for creating files that comply with the ISTP/SPDF guidelines. There are basic CDF tools such as cdfedit and skeletoncdf for creating CDF files, but these have no specific support for creating ISTP/ SPDF compliant files. The SPDF ISTP CDF skeleton editor is a cross-platform, Java-based GUI editor program that allows someone with only a basic understanding of the ISTP/SPDF guidelines to easily create compliant files. The editor is a simple graphical user interface (GUI) application for creating and editing ISTP/SPDF guideline-compliant skeleton CDF files. The SPDF ISTP CDF skeleton editor consists of the following components: A swing-based Java GUI program, JavaHelp-based manual/ tutorial, Image/Icon files, and HTML Web page for distribution. The editor is available as a traditional Java desktop application as well as a Java Network Launching Protocol (JNLP) application. Once started, it functions like a typical Java GUI file editor application for creating/editing application-unique files.

Chimiak, Reine↗

Database for Safety-Oriented Tracking of Chemicals

SafetyChem is a computer program that maintains a relational database for tracking chemicals and associated hazards at Johnson Space Center (JSC) by use of a Web-based graphical user interface. The SafetyChem database is accessible to authorized users via a JSC intranet. All new chemicals pass through a safety office, where information on hazards, required personal protective equipment (PPE), fire-protection warnings, and target organ effects (TOEs) is extracted from material safety data sheets (MSDSs) and recorded in the database. The database facilitates real-time management of inventory with attention to such issues as stability, shelf life, reduction of waste through transfer of unused chemicals to laboratories that need them, quantification of chemical wastes, and identification of chemicals for which disposal is required. Upon searching the database for a chemical, the user receives information on physical properties of the chemical, hazard warnings, required PPE, a link to the MSDS, and references to the applicable International Standards Organization (ISO) 9000 standard work instructions and the applicable job hazard analysis. Also, to reduce the labor hours needed to comply with reporting requirements of the Occupational Safety and Health Administration, the data can be directly exported into the JSC hazardous- materials database.

Stump, Jacob↗