Search NASA⌕ Search

SEARCH · Search NASA

Results for “Voice 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 19 records

Enabling a Voice Management System for Space Applications

The sustainable missions beyond Low Earth Orbit (LEO) envisioned for NASA’s Artemis program will require autonomous capabilities. Moreover, Artemis mission crews will need a means to efficiently interact with a spacecraft’s autonomous systems. This interaction can be facilitated by voice and speech communications because voice-based controls enable users to interact hands- and eyes-free, allowing the user to better focus on critical tasks. The goal of our project was to explore the knowledge and technology needed to successfully design effective Voice User Interfaces (VUIs) for autonomous systems utilizing Human Centered Design (HCD) principles. The focus of the human factors’ aspect of engineering, pays close attention to psychological and physiological principles in the development of autonomous crew operation systems. A main objective was to understand how a crew member, through voice interaction, could efficiently and intuitively communicate with a notional autonomous vehicle system manager. This project was a part of the NASA Moon to Mars eXploration Systems and Habitation (M2M X-Hab) 2020 Academic Innovation Challenge. The work from the BLiSS Team, at the University of Michigan, resulted in the design of a system persona, Diego, to which an astronaut may quickly build trust with autonomous systems, to alleviate known stressors on mental health expected during long duration space missions. Optimal software to facilitate integration of the system persona into a reference Lunar orbiting Gateway station was defined. Additionally, a Speech to Text (STT) system and a Graphical User Interface (GUI) that could be implemented in future missions was developed on an Internet of Things (IOT) platform. The Voice User Interface (VUI) design for the M2M X-Hab 2020 project leveraged previous technology developed by the BLiSS team to incorporate a voice-based interface into NASA’s Platform for Autonomous Systems (NPAS) software. This required technologies to convert voice to text, conduct semantic interpretations, and convert responses from the autonomous system to text and to speech; additionally, the spacecraft background noise environment was assessed, a noise mitigation technique was developed, and a relatable personality for the autonomous system was developed in order to facilitate human-like conversations. The success of our effort was largely due to the diversity of the team that included expertise in Space Systems Engineering, Human Computer Interaction, Aerospace Engineering, Computer Science, Biomedical Engineering, and Applied Physics. The diverse perspectives fostered elaborate discussions, resulting in the conception of three main subsystems: (1) User-System, (2) NPAS-System, and (3) Environment-System. The VUI was unique and had to be efficient and intuitive. For this project, 5 subteams were formed, each with a separate objective, Voice Design team, Background Noise Mitigation team, Software Integration team and Graphical User Interface team. The BLiSS team crafted a personality for the VUI to enable human-like conversation and drive user adoption and trust. User surveys were completed and used to help determine the required VUI system personality traits by capturing perspectives and expectations of prospective “Artemis Generation Astronauts”. To further simulate human-like conversations, the system had to be able to quickly interpret user speech and be able to integrate with NASA’s NPAS platform for quick and reliable information transfer. The outcomes of our research were: (1) a working prototype user interface, that is compatible with NASA’s NPAS platform; (2) software that demonstrates the ability of the VUI system to interpret user requests and respond appropriately; (3) the capability to implement fully expanded conversations between user and system using intuitive communication in four request categories; and (4) software and hardware recommendations that optimize the system’s ability to operate in a noisy environment. Our research has laid the foundation for the development of VUI’s for autonomy, and provides a baseline for future VUI developments.

Voice user interface↗

Enabling a Voice Management System for Space Applications, Design and Software Development

Sustainable missions, beyond low Earth orbit, will require autonomous capabilities in order to achieve NASA’s Artemis program objectives. Correspondingly, the crew must have a means to efficiently interact with these autonomous systems; this can be facilitated via voice and speech communications. Voice-based controls enable the user to access autonomous systems hands-free/eyes-free, allowing the user to better focus on critical tasks. The goal of this project was to explore the knowledge and technology needed to successfully design effective voice interfaces for autonomous systems. The main objective was to understand how a crew member, through voice interaction, could most efficiently and intuitively communicate with a notional autonomous vehicle system manager. This project leveraged prior research conducted by the University of Michigan’s Bioastronautics and Life Support System (BLiSS) team as part of a NASA Moon to Mars eXploration Systems and Habitation (M2M X-Hab) 2020 Academic Innovation Challenge. The X-Hab 2020 work from the BliSS Team resulted in an intuitive graphical user interface/user experience that was built on an Internet of Things (IOT) platform. The Voice User Interface (VUI) design for the M2M X-Hab 2021 project leveraged this technology and incorporated a voice-based assistant and NASA’s Platform for Autonomous Systems (NPAS) software. This required technologies to convert voice to text, conduct semantic interpretations, and convert responses from the autonomous system to text and to speech; additionally, the background noise environment of spacecraft was assessed, and a relatable personality for the autonomous system to facilitate human-like conversations was created. This work’s success was largely due to the diverse team that included expertise in Space Systems Engineering, Human Computer Interaction, Aerospace Engineering, Computer Science, Biomedical Engineering, and Applied Physics. The differing perspectives fostered elaborate discussions, resulting in the conception of three main interactions: (1) User-System, (2) NPAS-System, and (3) Environment-System. The system developed, i.e. the VUI, had to be unique, efficient, and intuitive; thus, the team crafted a personality for the system to enable human-like conversation. User surveys sent to students and young professionals were used to help determine these personality traits by capturing perspectives and expectations of the “Artemis Generation Astronauts”. To further simulate human-like conversations, the system had to be able to quickly interpret user speech and be able to integrate with NASA’s NPAS system for quick and reliable information transfer. Results of this research include (1) a working prototype user interface, that is compatible with NASA’s NPAS system; (2) software that demonstrates the ability to interpret user requests and respond appropriately; (3) the capability to implement fully expanded conversations between user and system using intuitive communication in four request categories; and (4) software and hardware recommendations that optimize the system’s ability to operate, i.e. be heard, in a noisy environment. The technologies chosen for this project’s demonstrations included the following: Raspberry Pi, RASA, Mozilla Deep Speech, Coqui, RTX Voice and Adobe XD. This work has laid the foundation for the development of VUI’s used for autonomy, and is intended to provide guidance for future VUI development.

Tara Vega↗

Interface Anywhere: Development of a Voice and Gesture System for Spaceflight Operations

The Interface Anywhere Project was funded through Innovation Charge Account (ICA) at NASA JSC in the Fall of 2012. The project was collaboration between human factors and engineering to explore the possibility of designing an interface to control basic habitat operations through gesture and voice control; (a) Current interfaces require the users to be physically near an input device in order to interact with the system; and (b) By using voice and gesture commands, the user is able to interact with the system anywhere they want within the work environment.

Thompson, Shelby↗

A Notional Artemis Lunar Surface Exploration Package (ArLSEP) based on the Gandalf Staff Platform

Introduction: The Artemis program is planning to deliver crew and cargo to the lunar surface, but there is no current package for supporting lunar in-struments and experiments similar to the Apollo Lunar Surface Exploration Package (ALSEP). This abstract provides a possible concept for such a package using the Gandalf Staff Platform as a common core. Gandalf Staff: The Gandalf Staff is an early prototype system developed over FY’21/FY’22 using NASA Science Technology Mission Directorate (STMD) Center Information Fund (CIF) grants to de-sign, build and test “proof-of-concept” components. These components include a 24v battery powered monopole that powers a suite of subsystems, including a Graphical User Interface (GUI) for crew, surface voice and data communications, Lunar Search and Rescue (LunaSAR) navigation and communications, LiDAR, field site external lighting, 360-degree camera, and a geothermal instrument for measuring sub-surface temperature gradient. The staff can be carried independently by an Extra-Vehicular Activity (EVA) astronaut, or can be mounted into a tripod for “hands free” support at a surface site being investigated. The staff can be attached to an external solar array and power storage system for long-duration operations. [1,2] ALSEP: An ASLEP flew on each mission Apollo 12 to Apollo 17. For Apollo 11, a simplified packaged called the Early Apollo Scientific Experiments Pack-age (EASEP) was flown. Each package included a “Central Station” that provided the power and communications connected to a variety of instruments and sensors. The power was provided by a Radioisotope Thermoelectric Generator (RTG) fueled by Plutoni-um-238 generating 70 watts of power (initially, decayed over time) [3]. The communications system provide for direct to Earth data transfer from the lunar surface. Each pack-age was stowed externally in the Lunar Module (LM) Scientific Equipment (SEQ) bay with a mass up to 163 kg (Apollo 17). The crew unloaded the ALSEP from the LM and deployed the instruments on the lunar surface. Although designed to operate for only 1 year, many sites operated for up to 8 years successfully [4]. The Active Seismic Experiment (ASE) included 3 geophones for detecting seismic waves created by mortars and thumpers deployed by the crew. Other active experiments measured the lunar atmosphere, the heat flow in the subsurface, the lunar gravity and potential gravity waves, the lunar magnetic field, the solar wind and plasma interactions in cislunar space. Passive experiments included collectors for dust and cosmic rays, and retroreflectors for precise measurements of distance using a laser from Earth. The ALSEP program continues to generate insights into lunar formation and evolution. ArLSEP Concepts: The lunar surface science package for the Artemis program will hopefully exceed the capability of the ALSEP. There are multiple issues for discussion leading to the design of a new ArLSEP, needing requirements definition from the science community, NASA mission architecture, and NASA budget planners. 1. Delivery Mechanism Two possible projects currently provide capability to deliver scientific cargo to the lunar surface: 1) the Commercial Lunar Payload Services (CLPS) [5] and the Human Landing System (HLS) [6, 7]. Each project is controlled by a different organization within NASA and budgeted with different criteria although both support lunar exploration. The HLS system delivers crew (and potentially cargo) to human landing sites. If an ArLSEP is “predeployed” to such a site, the design must include power (either from the vehicle or independently) to keep the electronics functioning until deployed by the crew. If an ArLSEP is delivered on a vehicle after the crew is present on the lunar surface, safety protocols require adequate distance from the humans for impact from descent propelled sur-face regolith ejecta. This distance can not exceed the capability of the crew to walk (if no rover) to the vehicle for ArLSEP deployment. 2. Overall Guidelines The general design of ArLSEP will likely follow the ALSEP with a common system for communications and power; however, significant architecture differences between Apollo and Artemis exist. Power: The RTG will not be available for early Artemis missions nor likely follow-on Lunar Exploration Transportation Services (LETS) missions [8]. Thus, ArLSEP power must be supplied by solar arrays with sufficient battery capability to “keep alive” necessary electronics during any lunar surface eclipse period. Communication: The Artemis program is developing a series of communications satellites for lunar orbit to provide surface transmission of data and voice to Earth. Called “LunaNET”, this network is component useful for ArLSEP since south polar locations may not always have direct “line-of-sight” to Earth [9]. 3. Concept of Operations (ConOps) The general ConOps for ArLSEP is to deliver the package to lunar surface before the crew arrives, and then have the crew deploy the package after some period of time. This requires coordinated design (for power systems) and launch window (for schedule) on both the cargo and crew missions. Once the ArLSEP is deployed, it will operate autonomously for a number of years. It should be designed to be EVA compatible for crew maintenance and upgrade. 4. Notional Design (for discussion purpose only) The landing site near the South Pole is expected to have no eclipse cycle exceeding 5 days, so the “keep alive” power is 144 hours (6 days to include margin). A 12v ArLSEP will use rechargeable LiFePO4 cells, which are common in the Electric Vehicle (EV) industry. With a current of 5 amps and a 125 watt system, the mass is about 90kg. The comm. system and structure adds another 10kg, thus the “Central Station” is approximately 100kg. The solar power is collected on four arrays (each 2m above the surface), and the entire ArLSEP is designed to stow in a 2m x 1m x 1m volume. The experiment and instrument design will vary for each installation and add mass to the total (although they are expected to fit within the 2m3 volume). Seismic wave generation will likely not be provided with mortars, thus an electric “thumper” will be required. Active instruments such as imaging systems and sensing instruments will benefit from the additional power and communication capability provided by ArLSEP. Passive systems such as retroreflectors, witness plates, and cosmic dust collectors can be added to either the landing vehicle and/or the ArLSEP. With repeated HLS missions to the same human site, the ArLSEP can be expanded and easily maintained for long duration science collection on the lunar surface.

ALSEP↗

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↗

Autonomy Voice Assistant for NPAS (NASA Platform for Autonomous Systems)

A prototype voice interaction system, Autonomy Voice Assistant (AVA), is described in this paper. AVA is designed to seamlessly integrate into the NASA Platform for Autonomous Systems (NPAS), an autonomy software platform, and to enable an operator to interact with NPAS autonomy applications through voice conversations. By integrating VA with NPAS, a major enhancement to NPAS applications is facilitated, enabling interaction through natural language expressions. An AVA prototype has been designed incorporating two principles:(1) self-containment (no external data or computations required), and (2) a readily modifiable, reconfigurable, and flexible architecture. By using voice messages in an NPAS application, an additional layer of user interface capability is enabled, thereby enhancing a user’s overall experience. Advancements, over the past several decades in speech recognition and natural language processing technologies has made it possible for AVA to implement robust messaging capabilities while still being lightweight. The main objective of incorporating a voice assistant like AVA is to augment the number and effectiveness of interactions a user has with a system that typically uses mouse-based interaction, while simultaneously enriching the user experience and providing heightened system awareness.

Lucian Murdock↗

Applications of artificial intelligence to space station: General purpose intelligent sensor interface

This final report describes the accomplishments of the General Purpose Intelligent Sensor Interface task of the Applications of Artificial Intelligence to Space Station grant for the period from October 1, 1987 through September 30, 1988. Portions of the First Biannual Report not revised will not be included but only referenced. The goal is to develop an intelligent sensor system that will simplify the design and development of expert systems using sensors of the physical phenomena as a source of data. This research will concentrate on the integration of image processing sensors and voice processing sensors with a computer designed for expert system development. The result of this research will be the design and documentation of a system in which the user will not need to be an expert in such areas as image processing algorithms, local area networks, image processor hardware selection or interfacing, television camera selection, voice recognition hardware selection, or analog signal processing. The user will be able to access data from video or voice sensors through standard LISP statements without any need to know about the sensor hardware or software.

Mckee, James W.↗

Broadening the interface bandwidth in simulation based training

Currently most computer based simulations rely exclusively on computer generated graphics to create the simulation. When training is involved, the method almost exclusively used to display information to the learner is text displayed on the cathode ray tube. MICROEXPERT Systems is concentrating on broadening the communications bandwidth between the computer and user by employing a novel approach to video image storage combined with sound and voice output. An expert system is used to combine and control the presentation of analog video, sound, and voice output with computer based graphics and text. Researchers are currently involved in the development of several graphics based user interfaces for NASA, the U.S. Army, and the U.S. Navy. Here, the focus is on the human factors considerations, software modules, and hardware components being used to develop these interfaces.

Somers, Larry E.↗

The use of hypermedia to increase the productivity of software development teams

Rapid progress in low-cost commercial PC-class multimedia workstation technology will potentially have a dramatic impact on the productivity of distributed work groups of 50-100 software developers. Hypermedia/multimedia involves the seamless integration in a graphical user interface (GUI) of a wide variety of data structures, including high-resolution graphics, maps, images, voice, and full-motion video. Hypermedia will normally require the manipulation of large dynamic files for which relational data base technology and SQL servers are essential. Basic machine architecture, special-purpose video boards, video equipment, optical memory, software needed for animation, network technology, and the anticipated increase in productivity that will result for the introduction of hypermedia technology are covered. It is suggested that the cost of the hardware and software to support an individual multimedia workstation will be on the order of $10,000.

Coles, L. Stephen↗

An evaluation of the documented requirements of the SSP UIL and a review of commercial software packages for the development and testing of UIL prototypes

A review was conducted of software packages currently on the market which might be integrated with the interface language and aid in reaching the objectives of customization, standardization, transparency, reliability, maintainability, language substitutions, expandability, portability, and flexibility. Recommendations are given for best choices in hardware and software acquisition for inhouse testing of these possible integrations. Software acquisition in the line of tools to aid expert-system development and/or novice program development, artificial intelligent voice technology and touch screen or joystick or mouse utilization as well as networking were recommended. Other recommendations concerned using the language Ada for the user interface language shell because of its high level of standardization, structure, and ability to accept and execute programs written in other programming languages, its DOD ownership and control, and keeping the user interface language simple so that multiples of users will find the commercialization of space within their realm of possibility which is, after all, the purpose of the Space Station.

Gill, Esther Naomi↗

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↗

Subject Matter Expert Evaluation of Multi-Flight Common Route Advisories

Traffic flow management seeks to balance the demand for National Airspace System (NAS) flight resources, such as airspace and airports, with the available supply. When forecasted weather blocks nominal air traffic routes, traffic managers must re-route affected flights for weather avoidance. Depending on the nature and scope of the weather, traffic managers may use pre-coordinated re-routes such as Playbook Routes or Coded Departure Routes, or may design ad hoc local re-routes. The routes of affected flights are modified accordingly. These weather avoidance routes will, of course, be less efficient than the nominal routes due to increased flight time and fuel burn. In current traffic management operations, the transition into a weather avoidance re-routing initiative is typically implemented more aggressively than the transition out of that initiative after the weather has dissipated or moved away. For example, strategic large-scale Playbook re-routes are sometimes left in place (as initially implemented) for many hours before being lifted entirely when the weather dissipates. There is an opportunity to periodically modify the re-routing plan as weather evolves, thereby attenuating its adverse impact on flight time and fuel consumption; this is called delay recovery. Multi-Flight Common Routes (MFCR) is a NASA-developed operational concept and associated decision support tool for delay recovery, designed to assist traffic managers to efficiently update weather avoidance traffic routes after the original re-routes have become stale due to subsequent evolution of the convective weather system. MFCR groups multiple flights to reduce the number of advisories that the traffic manager needs to evaluate, and also merges these flights on a common route segment to provide an orderly flow of re-routed traffic. The advisory is presented to the appropriate traffic manager who evaluates it and has the option to modify it using MFCRs graphical user interface. If the traffic manager finds the advisory to be operationally appropriate, he or she would coordinate with the Area Supervisor(s) of the sectors that currently control the flights in the advisory. When the traffic manager accepts the MFCR advisory via the user interface, the corresponding flight plan amendments would be sent to the displays of the appropriate sector controllers, using the Airborne Re-Routing (ABRR) capability which is scheduled for nationwide operation in 2017. The sector controllers would then offer this time-saving route modification to the pilots of the affected flights via datalink (or voice), and implement the corresponding flight plan amendment if the pilots accept it. MFCR is implemented as an application in the software environment of the Future Air traffic management Concepts Evaluation Tool (FACET). This paper focuses on an initial subject matter expert (SME) evaluation of MFCR. The evaluation covers MFCRs operational concept, algorithm, and user interface.

Human-in-the-loop Evaluation↗