Search NASA⌕ Search

SEARCH · Search NASA

Results for “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 523 records · Page 29

A Graphical Operator Interface for a Telerobotic Inspection System

Operator interface has recently emerged as an important element for efficient and safe operatorinteractions with the telerobotic system. Recent advances in graphical user interface (GUI) andgraphics/video merging technologies enable development of more efficient, flexible operatorinterfaces. This paper describes an advanced graphical operator interface newly developed for aremote surface inspection system at Jet Propulsion Laboratory. The interface has been designed sothat remote surface inspection can be performed by a single operator with an integrated robot controland image inspection capability. It supports three inspection strategies of teleoperated human visual inspection, human visual inspection with automated scanning, and machine-vision-based automated inspection.

Kim, W. S.↗

Overview of Umbilical Extravehicular Activity (EVA) Interfaces in Life Support Systems on Spacecraft Vehicles and Applications for the Crew Exploration Vehicle (CEV)

Extravehicular Activities (EVAs) for manned spacecraft vehicles have been performed for contingencies and nominal operations numerous times throughout history. This paper will investigate how previous U.S. manned spacecraft vehicles provided life support to crewmembers performing the EVA. Specifically defined are umbilical interfaces with respect to crewmember cooling, drinking water, air (or oxygen), humidity control, and carbon dioxide removal. As historical data is available, the need for planned versus contingency EVAs in previous vehicles as well as details for a nominal EVA day versus a contingency EVA day will be discussed. The hardware used to provide the cooling, drinking water, air (or oxygen), humidity control, and carbon dioxide removal, and the general functions of that hardware, will also be detailed, as information is available. The Crew Exploration Vehicle (CEV or Orion) EVA interfaces will be generically discussed to provide a glimpse of how similar they are to the EVA interfaces in previous vehicles. Conclusions on strategies that should be used for CEV based on previous spacecraft EVA interfaces will be made in the form of questions and recommendations.

Peterson, Laurie J.↗

Operator Performance Evaluation of Fault Management Interfaces for Next-Generation Spacecraft

In the cockpit of the NASA's next generation of spacecraft, most of vehicle commanding will be carried out via electronic interfaces instead of hard cockpit switches. Checklists will be also displayed and completed on electronic procedure viewers rather than from paper. Transitioning to electronic cockpit interfaces opens up opportunities for more automated assistance, including automated root-cause diagnosis capability. The paper reports an empirical study evaluating two potential concepts for fault management interfaces incorporating two different levels of automation. The operator performance benefits produced by automation were assessed. Also, some design recommendations for spacecraft fault management interfaces are discussed.

Hayashi, Miwa↗

Interface Supports Lightweight Subsystem Routing for Flight Applications

A wireless avionics interface exploits the constrained nature of data networks in flight systems to use a lightweight routing method. This simplified routing means that a processor is not required, and the logic can be implemented as an intellectual property (IP) core in a field-programmable gate array (FPGA). The FPGA can be shared with the flight subsystem application. In addition, the router is aware of redundant subsystems, and can be configured to provide hot standby support as part of the interface. This simplifies implementation of flight applications requiring hot stand - by support. When a valid inbound packet is received from the network, the destination node address is inspected to determine whether the packet is to be processed by this node. Each node has routing tables for the next neighbor node to guide the packet to the destination node. If it is to be processed, the final packet destination is inspected to determine whether the packet is to be forwarded to another node, or routed locally. If the packet is local, it is sent to an Applications Data Interface (ADI), which is attached to a local flight application. Under this scheme, an interface can support many applications in a subsystem supporting a high level of subsystem integration. If the packet is to be forwarded to another node, it is sent to the outbound packet router. The outbound packet router receives packets from an ADI or a packet to be forwarded. It then uses a lookup table to determine the next destination for the packet. Upon detecting a remote subsystem failure, the routing table can be updated to autonomously bypass the failed subsystem.

Lux, James P.↗

Modeling Geometry and Progressive Failure of Material Interfaces in Plain Weave Composites

A procedure combining a geometrically nonlinear, explicit-dynamics contact analysis, computer aided design techniques, and elasticity-based mesh adjustment is proposed to efficiently generate realistic finite element models for meso-mechanical analysis of progressive failure in textile composites. In the procedure, the geometry of fiber tows is obtained by imposing a fictitious expansion on the tows. Meshes resulting from the procedure are conformal with the computed tow-tow and tow-matrix interfaces but are incongruent at the interfaces. The mesh interfaces are treated as cohesive contact surfaces not only to resolve the incongruence but also to simulate progressive failure. The method is employed to simulate debonding at the material interfaces in a ceramic-matrix plain weave composite with matrix porosity and in a polymeric matrix plain weave composite without matrix porosity, both subject to uniaxial cyclic loading. The numerical results indicate progression of the interfacial damage during every loading and reverse loading event in a constant strain amplitude cyclic process. However, the composites show different patterns of damage advancement.

Hsu, Su-Yuen↗

Ultrasonic Characterization of Interfaces in Composite Bonds

The inverse determination of imperfect interfaces from reflection spectra of normal and oblique incident ultrasonic waves in adhesive bonds of multidirectional composites is investigated. The oblique measurements are complicated by the highly dispersed nature of oblique wave spectra at frequencies above 3MHz. Different strategies for bond property reconstruction, including a modulation method, are discussed. The relation of measured interfacial spring density to the physico-chemical model of a composite interface described by polymer molecular bonds to emulate loss of molecular strength on an adhesive composite interface is discussed. This potentially relates the interfacial (adhesion) strength (number of bonds at the adhesive substrate interface) to the spring constant (stiffness) area density (flux), which is an ultrasonically measurable parameter.

Wang, N.↗

A Study of Fluid Interface Configurations in Exploration Vehicle Propellant Tanks

The equilibrium shape and location of fluid interfaces in spacecraft propellant tanks while in low-gravity is of interest to system designers, but can be challenging to predict. The propellant position can affect many aspects of the spacecraft such as the spacecraft center of mass, response to thruster firing due to sloshing, liquid acquisition, propellant mass gauging, and thermal control systems. We use Surface Evolver, a fluid interface energy minimizing algorithm, to investigate theoretical equilibrium liquid-vapor interfaces for spacecraft propellant tanks similar to those that have been considered for NASA's new class of Exploration vehicles. The choice of tank design parameters we consider are derived from the NASA Exploration Systems Architecture Study report. The local acceleration vector employed in the computations is determined by estimating low-Earth orbit (LEO) atmospheric drag effects and centrifugal forces due to a fixed spacecraft orientation with respect to the Earth or Moon, and rotisserie-type spacecraft rotation. Propellant/vapor interface positions are computed for the Earth Departure Stage and Altair lunar lander descent and ascent stage tanks for propellant loads applicable to LEO and low-lunar orbit. In some of the cases investigated the vapor ullage bubble is located at the drain end of the tank, where propellant management device hardware is often located.

Zimmerli, Gregory A.↗

Sitting in the Pilot's Seat; Optimizing Human-Systems Interfaces for Unmanned Aerial Vehicles

One of the pilot-machine interfaces (the forward viewing camera display) for an Unmanned Aerial Vehicle called the DROID (Dryden Remotely Operated Integrated Drone) will be analyzed for optimization. The goal is to create a visual display for the pilot that as closely resembles an out-the-window view as possible. There are currently no standard guidelines for designing pilot-machine interfaces for UAVs. Typically, UAV camera views have a narrow field, which limits the situational awareness (SA) of the pilot. Also, at this time, pilot-UAV interfaces often use displays that have a diagonal length of around 20". Using a small display may result in a distorted and disproportional view for UAV pilots. Making use of a larger display and a camera lens with a wider field of view may minimize the occurrences of pilot error associated with the inability to see "out the window" as in a manned airplane. It is predicted that the pilot will have a less distorted view of the DROID s surroundings, quicker response times and more stable vehicle control. If the experimental results validate this concept, other UAV pilot-machine interfaces will be improved with this design methodology.

Queen, Steven M.↗

SNE Industrial Fieldbus Interface

Programmable logic controllers (PLCs) have very limited diagnostic and no prognostic capabilities, while current smart sensor designs do not have the capability to communicate over Fieldbus networks. The aim is to interface smart sensors with PLCs so that health and status information, such as failure mode identification and measurement tolerance, can be communicated via an industrial Fieldbus such as ControlNet. The SNE Industrial Fieldbus Interface (SIFI) is an embedded device that acts as a communication module in a networked smart sensor. The purpose is to enable a smart sensor to communicate health and status information to other devices, such as PLCs, via an industrial Fieldbus networking protocol. The SNE (Smart Network Element) is attached to a commercial off-the-shelf Any bus-S interface module through the SIFI. Numerous Anybus-S modules are available, each one designed to interface with a specific Fieldbus. Development of the SIFI focused on communications using the ControlNet protocol, but any of the Anybus-S modules can be used. The SIFI communicates with the Any-bus module via a data buffer and mailbox system on the Anybus module, and supplies power to the module. The Anybus module transmits and receives data on the Fieldbus using the proper protocol. The SIFI is intended to be connected to other existing SNE modules in order to monitor the health and status of a transducer. The SIFI can also monitor aspects of its own health using an onboard watchdog timer and voltage monitors. The SIFI also has the hardware to drive a touchscreen LCD (liquid crystal display) unit for manual configuration and status monitoring.

Lucena, Angel↗

Magnetic Interface for Segmented Mirror Assembly

Newly developed magnetic devices are used to create an interface between adjacent mirror segments so that once assembled, aligned, and phased, the multiple segments will behave functionally equivalent to a monolithic aperture mirror. One embodiment might be a kinematic interface that is reversible so that any number of segments can be pre-assembled, aligned, and phased to facilitate fabrication operations, and then disassembled and reassembled, aligned, and phased in space for operation. The interface mechanism has sufficient stiffness, force, and stability to maintain phasing. The key to producing an interface is the correlated magnetic surface. While conventional magnets are only constrained in one direction -- the direction defined by their point of contact (they are in contact and cannot get any closer) -- correlated magnets can be designed to have constraints in multiple degrees of freedom. Additionally, correlated magnetic surfaces can be designed to have a limited range of action.

Stahl, H.↗

General MACOS Interface for Modeling and Analysis for Controlled Optical Systems

The General MACOS Interface (GMI) for Modeling and Analysis for Controlled Optical Systems (MACOS) enables the use of MATLAB as a front-end for JPL s critical optical modeling package, MACOS. MACOS is JPL s in-house optical modeling software, which has proven to be a superb tool for advanced systems engineering of optical systems. GMI, coupled with MACOS, allows for seamless interfacing with modeling tools from other disciplines to make possible integration of dynamics, structures, and thermal models with the addition of control systems for deformable optics and other actuated optics. This software package is designed as a tool for analysts to quickly and easily use MACOS without needing to be an expert at programming MACOS. The strength of MACOS is its ability to interface with various modeling/development platforms, allowing evaluation of system performance with thermal, mechanical, and optical modeling parameter variations. GMI provides an improved means for accessing selected key MACOS functionalities. The main objective of GMI is to marry the vast mathematical and graphical capabilities of MATLAB with the powerful optical analysis engine of MACOS, thereby providing a useful tool to anyone who can program in MATLAB. GMI also improves modeling efficiency by eliminating the need to write an interface function for each task/project, reducing error sources, speeding up user/modeling tasks, and making MACOS well suited for fast prototyping.

Sigrist, Norbert↗

Airborne Precision Spacing for Dependent Parallel Operations Interface Study

This paper describes a usability study of proposed cockpit interfaces to support Airborne Precision Spacing (APS) operations for aircraft performing dependent parallel approaches (DPA). NASA has proposed an airborne system called Pair Dependent Speed (PDS) which uses their Airborne Spacing for Terminal Arrival Routes (ASTAR) algorithm to manage spacing intervals. Interface elements were designed to facilitate the input of APS-DPA spacing parameters to ASTAR, and to convey PDS system information to the crew deemed necessary and/or helpful to conduct the operation, including: target speed, guidance mode, target aircraft depiction, and spacing trend indication. In the study, subject pilots observed recorded simulations using the proposed interface elements in which the ownship managed assigned spacing intervals from two other arriving aircraft. Simulations were recorded using the Aircraft Simulation for Traffic Operations Research (ASTOR) platform, a medium-fidelity simulator based on a modern Boeing commercial glass cockpit. Various combinations of the interface elements were presented to subject pilots, and feedback was collected via structured questionnaires. The results of subject pilot evaluations show that the proposed design elements were acceptable, and that preferable combinations exist within this set of elements. The results also point to potential improvements to be considered for implementation in future experiments.

Volk, Paul M.↗

How NASA KSC Controls Interfaces with the use of Motion Skeletons and Product Structure

This presentation will show how NASA KSC controls interfaces for Modular Product Architecture (MPA) using Locator Skeletons, Interface Skeletons, and Product Structure, to be combined together within a Motion Skeleton. The user will learn how to utilize skeleton models to communicate interface data, as successfully done at NASA KSC in their use of Motion Skeletons to control interfaces for multi-launch systems. There will be discussion of the methodology used to control design requirements through WTParts, and how to utilize product structure for non-CAD documents.

Jones, Corey↗

Interfacing and Verifying ALHAT Safe Precision Landing Systems with the Morpheus Vehicle

The NASA Autonomous precision Landing and Hazard Avoidance Technology (ALHAT) project developed a suite of prototype sensors to enable autonomous and safe precision landing of robotic or crewed vehicles under any terrain lighting conditions. Development of the ALHAT sensor suite was a cross-NASA effort, culminating in integration and testing on-board a variety of terrestrial vehicles toward infusion into future spaceflight applications. Terrestrial tests were conducted on specialized test gantries, moving trucks, helicopter flights, and a flight test onboard the NASA Morpheus free-flying, rocket-propulsive flight-test vehicle. To accomplish these tests, a tedious integration process was developed and followed, which included both command and telemetry interfacing, as well as sensor alignment and calibration verification to ensure valid test data to analyze ALHAT and Guidance, Navigation and Control (GNC) performance. This was especially true for the flight test campaign of ALHAT onboard Morpheus. For interfacing of ALHAT sensors to the Morpheus flight system, an adaptable command and telemetry architecture was developed to allow for the evolution of per-sensor Interface Control Design/Documents (ICDs). Additionally, individual-sensor and on-vehicle verification testing was developed to ensure functional operation of the ALHAT sensors onboard the vehicle, as well as precision-measurement validity for each ALHAT sensor when integrated within the Morpheus GNC system. This paper provides some insight into the interface development and the integrated-systems verification that were a part of the build-up toward success of the ALHAT and Morpheus flight test campaigns in 2014. These campaigns provided valuable performance data that is refining the path toward spaceflight infusion of the ALHAT sensor suite.

Carson, John M., III↗

MaROS Strategic Relay Planning and Coordination Interfaces

The Mars Relay Operations Service (MaROS) is designed to provide planning and analysis tools in support of ongoing Mars Network relay operations. Strategic relay planning requires coordination between lander and orbiter mission ground data system (GDS) teams to schedule and execute relay communications passes. MaROS centralizes this process, correlating all data relevant to relay coordination to provide a cohesive picture of the relay state. Service users interact with the system through thin-layer command line and web user interface client applications. Users provide and utilize data such as lander view periods of orbiters, Deep Space Network (DSN) antenna tracks, and reports of relay pass performance. Users upload and download relevant relay data via formally defined and documented file structures including some described in Extensible Markup Language (XML). Clients interface with the system via an http-based Representational State Transfer (ReST) pattern using Javascript Object Notation (JSON) formats. This paper will provide a general overview of the service architecture and detail the software interfaces and considerations for interface design.

Allard, Daniel A.↗

Assessment of the Orion-SLS Interface Management Process in Achieving the EIA 731.1 Systems Engineering Capability Model Generic Practices Level 3 Criteria

NASA is currently developing the next generation crewed spacecraft and launch vehicle for exploration beyond earth orbit including returning to the Moon and making the transit to Mars. Managing the design integration of major hardware elements of a space transportation system is critical for overcoming both the technical and programmatic challenges in taking a complex system from concept to space operations. An established method of accomplishing this is formal interface management. In this paper we set forth an argument that the interface management process implemented by NASA between the Orion Multi-Purpose Crew Vehicle (MPCV) and the Space Launch System (SLS) achieves the Level 3 tier of the EIA 731.1 System Engineering Capability Model (SECM) for Generic Practices. We describe the relevant NASA systems and associated organizations, and define the EIA SECM Level 3 Generic Practices. We then provide evidence for our compliance with those practices. This evidence includes discussions of: NASA Systems Engineering Interface (SE) Management standard process and best practices; the tailoring of that process for implementation on the Orion to SLS interface; changes made over time to improve the tailored process, and; the opportunities to take the resulting lessons learned and propose improvements to our institutional processes and best practices. We compare this evidence against the practices to form the rationale for the declared SECM maturity level.

Jellicorse, John J.↗

Incorporating Speech Recognition into a Natural User Interface

The Augmented/ Virtual Reality (AVR) Lab has been working to study the applicability of recent virtual and augmented reality hardware and software to KSC operations. This includes the Oculus Rift, HTC Vive, Microsoft HoloLens, and Unity game engine. My project in this lab is to integrate voice recognition and voice commands into an easy to modify system that can be added to an existing portion of a Natural User Interface (NUI). A NUI is an intuitive and simple to use interface incorporating visual, touch, and speech recognition. The inclusion of speech recognition capability will allow users to perform actions or make inquiries using only their voice. The simplicity of needing only to speak to control an on-screen object or enact some digital action means that any user can quickly become accustomed to using this system. Multiple programs were tested for use in a speech command and recognition system. Sphinx4 translates speech to text using a Hidden Markov Model (HMM) based Language Model, an Acoustic Model, and a word Dictionary running on Java. PocketSphinx had similar functionality to Sphinx4 but instead ran on C. However, neither of these programs were ideal as building a Java or C wrapper slowed performance. The most ideal speech recognition system tested was the Unity Engine Grammar Recognizer. A Context Free Grammar (CFG) structure is written in an XML file to specify the structure of phrases and words that will be recognized by Unity Grammar Recognizer. Using Speech Recognition Grammar Specification (SRGS) 1.0 makes modifying the recognized combinations of words and phrases very simple and quick to do. With SRGS 1.0, semantic information can also be added to the XML file, which allows for even more control over how spoken words and phrases are interpreted by Unity. Additionally, using a CFG with SRGS 1.0 produces a Finite State Machine (FSM) functionality limiting the potential for incorrectly heard words or phrases. The purpose of my project was to investigate options for a Speech Recognition System. To that end I attempted to integrate Sphinx4 into a user interface. Sphinx4 had great accuracy and is the only free program able to perform offline speech dictation. However it had a limited dictionary of words that could be recognized, single syllable words were almost impossible for it to hear, and since it ran on Java it could not be integrated into the Unity based NUI. PocketSphinx ran much faster than Sphinx4 which would've made it ideal as a plugin to the Unity NUI, unfortunately creating a C# wrapper for the C code made the program unusable with Unity due to the wrapper slowing code execution and class files becoming unreachable. Unity Grammar Recognizer is the ideal speech recognition interface, it is flexible in recognizing multiple variations of the same command. It is also the most accurate program in recognizing speech due to using an XML grammar to specify speech structure instead of relying solely on a Dictionary and Language model. The Unity Grammar Recognizer will be used with the NUI for these reasons as well as being written in C# which further simplifies the incorporation.

Chapa, Nicholas↗

UAS Measured Response: The Effect of GCS Control Mode Interfaces on Pilot Ability to Comply with ATC Clearances

The present study examines the effects of three different control mode interfaces on unmanned aerial system (UAS) pilots ability to comply with air traffic controller traffic clearances. Pilots controlled a simulated UAS with a waypoint-only interface, an auto-pilot interface and a manual, stick and throttle interface. Results indicate that pilots are best able to get in-the-loop when provided with auto-pilot and manual control inputs. Limitations to the present study and future analyses are discussed.

Measured Response↗