Search NASA⌕ Search

SEARCH · Search NASA

Results for “Voice interface for space systems”

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.

45 records · Page 3
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

Preliminary Design of an 'Autonomous Medical Response Agent' Interface Prototype for Long Duration Spaceflight

Major challenges for astronauts in future long-duration exploration missions (LDEMs) will be that crewmembers are not expected to be medical professionals, may be under high workload and stress, are facing physiological challenges caused by spaceflight, and will have limited, delayed voice communications with medical support from Earth. An autonomous medical response agent (AMRA) is envisioned to help astronauts address medical complaints, develop a differential diagnosis, and guide self-treatment until a healthy state is restored. AMRA develops a process of personalized diagnosis and treatment through a Bayesian predictive control system that recommends therapeutic control actions including diagnostic tests and treatments to crewmembers (Menon, 2020). The Human Computer Interaction (HCI) lab from NASA Ames Research Center’s Human Systems Integration Division (Code TH) has collaborated with Nahlia Inc in human-centered design augmentation research for AMRA. The project, titled Design of ‘Autonomous Medical Response Agent Interface Prototype for Long Duration Spaceflight, has been funded by the Translational Research Institute for Space Health (TRISH) and introduces an interactive user-interface prototype that guides astronauts through self-diagnosis, treatment, and rehabilitation while communicating with remote specialists in ground support (most notably a patient’s flight surgeon). Our project develops the interaction design for the crewmember using AMRA through user research, iterative design, and usability testing to evaluate the user interface and workflow designed. The interface design deliverable for this project, titled AMRA Aggregate Information Display (AMRA AID) is an integrated information display system for comprehensive autonomous medical guidance, diagnosis, and treatment of in-flight medical conditions experienced by crewmembers. AMRA AID demonstrates how we might ensure crew autonomy, increase the crew’s medical capabilities, and decrease cognitive burden within a front-end user interface. AMRA AID refrains from relying on input from ground or mission control for self-treatment of medical issues—though ground awareness and communication with ground is maintained as a means of ensuring trust between mission control and crew. AMRA AID demonstrates how the crew’s on-board medical system might integrate with information from vehicle monitoring and crew schedule, without assuming causal relationships. AMRA AID’s comprehensive view enables efficient information access for both crew and ground support, reducing cognitive burden in the event of an unplanned or emergency medical incident and enabling informed analytical decisions to be made based on both crew and vehicle health. Human-centered design augmentation advanced within the prototype included: enhanced workflow and treatment guidance for two medical scenarios for a non-specialist user base with various levels of medical training, interaction design which considered speech (conversational user interface) elements and on-screen interactions to be developed in future iterations of the project, communication design and functional requirements relevant to self-care versus caring for another astronaut, as well as user testing of the prototype with an international space medical community. This project arrives at critical findings regarding usability needs, communication requirements, and integrated information requirements for a future technology interface functioning to increase confidence between ground support and LDEM crewmembers.

TRISH↗
NASA NTRS2010

Suggestions for Layout and Functional Behavior of Software-Based Voice Switch Keysets

Marshall Space Flight Center (MSFC) provides communication services for a number of real time environments, including Space Shuttle Propulsion support and International Space Station (ISS) payload operations. In such settings, control team members speak with each other via multiple voice circuits or loops. Each loop has a particular purpose and constituency, and users are assigned listen and/or talk capabilities for a given loop based on their role in fulfilling the purpose. A voice switch is a given facility's hardware and software that supports such communication, and may be interconnected with other facilities switches to create a large network that, from an end user perspective, acts like a single system. Since users typically monitor and/or respond to several voice loops concurrently for hours on end and real time operations can be very dynamic and intense, it s vital that a control panel or keyset for interfacing with the voice switch be a servant that reduces stress, not a master that adds it. Implementing the visual interface on a computer screen provides tremendous flexibility and configurability, but there s a very real risk of overcomplication. (Remember how office automation made life easier, which led to a deluge of documents that made life harder?) This paper a) discusses some basic human factors considerations related to keysets implemented as application software windows, b) suggests what to standardize at the facility level and what to leave to the user's preference, and c) provides screen shot mockups for a robust but reasonably simple user experience. Concepts apply to keyset needs in almost any type of operations control or support center.

Scott, David W.↗
NASA NTRS2014

NASA Wearable Technology CLUSTER 2013-2014 Report

Wearable technology has the potential to revolutionize the way humans interact with one another, with information, and with the electronic systems that surround them. This change can already be seen in the dramatic increase in the availability and use of wearable health and activity monitors. These devices continuously monitor the wearer using on-­‐body sensors and wireless communication. They provide feedback that can be used to improve physical health and performance. Smart watches and head mounted displays are also receiving a great deal of commercial attention, providing immediate access to information via graphical displays, as well as additional sensing features. For the purposes of the Wearable Technology CLUSTER, wearable technology is broadly defined as any electronic sensing, human interfaces, computing, or communication that is mounted on the body. Current commercially available wearable devices primarily house electronics in rigid packaging to provide protection from flexing, moisture, and other contaminants. NASA mentors are interested in this approach, but are also interested in direct integration of electronics into clothing to enable more comfortable systems. For human spaceflight, wearable technology holds a great deal of promise for significantly improving safety, efficiency, autonomy, and research capacity for the crew in space and support personnel on the ground. Specific capabilities of interest include: Continuous biomedical monitoring for research and detection of health problems. Environmental monitoring for individual exposure assessments and alarms. Activity monitoring for responsive robotics and environments. Multi-modal caution and warning using tactile, auditory, and visual alarms. Wireless, hands-free, on-demand voice communication. Mobile, on-demand access to space vehicle and robotic displays and controls. Many technical challenges must be overcome to realize these wearable technology applications. For example, to make a wearable device that is both functional and comfortable for long duration wear, developers must strive to reduce electronic mass and volume while also addressing constraints imposed by the body attachment method. Depending on the application, the device must be placed in a location that the user can see and reach, and that provides the appropriate access to air and the wearer's skin. Limited power is available from body-­‐worn batteries and heat must be managed to prevent discomfort. If the clothing is to be washed, there are additional durability and washability hurdles that traditional electronics are not designed to address. Finally, each specific capability has unique technical challenges that will likely require unique solutions. In addition to the technical challenges, development of wearable devices is made more difficult by the diversity of skills required and the historic lack of collaboration across domains. Wearable technology development requires expertise in textiles engineering, apparel design, software and computer engineering, electronic design and manufacturing, human factors engineering, and application-­‐specific fields such as acoustics, medical devices, and sensing. Knowledge from each of these domains must be integrated to create functional and comfortable devices. For this reason, the diversity of knowledge and experience represented in the Wearable Technology is critical to overcoming the fundamental challenges in the field.

Simon, Cory↗
NASA NTRS1998

NASA Lewis' Telescience Support Center Supports Orbiting Microgravity Experiments

The Telescience Support Center (TSC) at the NASA Lewis Research Center was developed to enable Lewis-based science teams and principal investigators to monitor and control experimental and operational payloads onboard the International Space Station. The TSC is a remote operations hub that can interface with other remote facilities, such as universities and industrial laboratories. As a pathfinder for International Space Station telescience operations, the TSC has incrementally developed an operational capability by supporting space shuttle missions. The TSC has evolved into an environment where experimenters and scientists can control and monitor the health and status of their experiments in near real time. Remote operations (or telescience) allow local scientists and their experiment teams to minimize their travel and maintain a local complement of expertise for hardware and software troubleshooting and data analysis. The TSC was designed, developed, and is operated by Lewis' Engineering and Technical Services Directorate and its support contractors, Analex Corporation and White's Information System, Inc. It is managed by Lewis' Microgravity Science Division. The TSC provides operational support in conjunction with the NASA Marshall Space Flight Center and NASA Johnson Space Center. It enables its customers to command, receive, and view telemetry; monitor the science video from their on-orbit experiments; and communicate over mission-support voice loops. Data can be received and routed to experimenter-supplied ground support equipment and/or to the TSC data system for display. Video teleconferencing capability and other video sources, such as NASA TV, are also available. The TSC has a full complement of standard services to aid experimenters in telemetry operations.

Hawersaat, Bob W.↗
NASA NTRS2004

Space-based Science Operations Grid Prototype

Grid technology is the up and coming technology that is enabling widely disparate services to be offered to users that is very economical, easy to use and not available on a wide basis. Under the Grid concept disparate organizations generally defined as "virtual organizations" can share services i.e. sharing discipline specific computer applications, required to accomplish the specific scientific and engineering organizational goals and objectives. Grids are emerging as the new technology of the future. Grid technology has been enabled by the evolution of increasingly high speed networking. Without the evolution of high speed networking Grid technology would not have emerged. NASA/Marshall Space Flight Center's (MSFC) Flight Projects Directorate, Ground Systems Department is developing a Space-based Science Operations Grid prototype to provide to scientists and engineers the tools necessary to operate space-based science payloads/experiments and for scientists to conduct public and educational outreach. In addition Grid technology can provide new services not currently available to users. These services include mission voice and video, application sharing, telemetry management and display, payload and experiment commanding, data mining, high order data processing, discipline specific application sharing and data storage, all from a single grid portal. The Prototype will provide most of these services in a first step demonstration of integrated Grid and space-based science operations technologies. It will initially be based on the International Space Station science operational services located at the Payload Operations Integration Center at MSFC, but can be applied to many NASA projects including free flying satellites and future projects. The Prototype will use the Internet2 Abilene Research and Education Network that is currently a 10 Gb backbone network to reach the University of Alabama at Huntsville and several other, as yet unidentified, Space Station based science experimenters. There is an international aspect to the Grid involving the America's Pathway (AMPath) network, the Chilean REUNA Research and Education Network and the University of Chile in Santiago that will further demonstrate how extensive these services can be used. From the user's perspective, the Prototype will provide a single interface and logon to these varied services without the complexity of knowing the where's and how's of each service. There is a separate and deliberate emphasis on security. Security will be addressed by specifically outlining the different approaches and tools used. Grid technology, unlike the Internet, is being designed with security in mind. In addition we will show the locations, configurations and network paths associated with each service and virtual organization. We will discuss the separate virtual organizations that we define for the varied user communities. These will include certain, as yet undetermined, space-based science functions and/or processes and will include specific virtual organizations required for public and educational outreach and science and engineering collaboration. We will also discuss the Grid Prototype performance and the potential for further Grid applications both space-based and ground based projects and processes. In this paper and presentation we will detail each service and how they are integrated using Grid

Bradford, Robert N.↗
NASA NTRS2016

Using Natural Language to Enhance Mission Effectiveness

The availability of highly capable, yet relatively cheap, unmanned aerial vehicles (UAVs) is opening up new areas of use for hobbyists and for professional-related activities. The driving function of this research is allowing a non-UAV pilot, an operator, to define and manage a mission. This paper describes the preliminary usability measures of an interface that allows an operator to define the mission using speech to make inputs. An experiment was conducted to begin to enumerate the efficacy and user acceptance of using voice commands to define a multi-UAV mission and to provide high-level vehicle control commands such as "takeoff." The primary independent variable was input type - voice or mouse. The primary dependent variables consisted of the correctness of the mission parameter inputs and the time needed to make all inputs. Other dependent variables included NASA-TLX workload ratings and subjective ratings on a final questionnaire. The experiment required each subject to fill in an online form that contained comparable required information that would be needed for a package dispatcher to deliver packages. For each run, subjects typed in a simple numeric code for the package code. They then defined the initial starting position, the delivery location, and the return location using either pull-down menus or voice input. Voice input was accomplished using CMU Sphinx4-5prealpha for speech recognition. They then inputted the length of the package. These were the option fields. The subject had the system "Calculate Trajectory" and then "Takeoff" once the trajectory was calculated. Later, the subject used "Land" to finish the run. After the voice and mouse input blocked runs, subjects completed a NASA-TLX. At the conclusion of all runs, subjects completed a questionnaire asking them about their experience in inputting the mission parameters, and starting and stopping the mission using mouse and voice input. In general, the usability of voice commands is acceptable. With a relatively well-defined and simple vocabulary, the operator can input the vast majority of the mission parameters using simple, intuitive voice commands. However, voice input may be more applicable to initial mission specification rather than for critical commands such as the need to land immediately due to time and feedback constraints. It would also be convenient to retrieve relevant mission information using voice input. Therefore, further on-going research is looking at using intent from operator utterances to provide the relevant mission information to the operator. The information displayed will be inferred from the operator's utterances just before key phrases are spoken. Linguistic analysis of the context of verbal communication provides insight into the intended meaning of commonly heard phrases such as "What's it doing now?" Analyzing the semantic sphere surrounding these common phrases enables us to predict the operator's intent and supply the operator's desired information to the interface. This paper also describes preliminary investigations into the generation of the semantic space of UAV operation and the success at providing information to the interface based on the operator's utterances.

Trujillo, Anna C.↗
NASA NTRS2013

Communications Dashboard (Control Rooms Take a Cue from Facebook), Chapter 1

Papers published via IEEE and AIAA conferences have presented an overview of how social media could benefit NASA working environments in general and proposed three specific social applications to benefit space flight control operations. One of them, Communications Dashboard, would help a real time flight controller keep up with both the "big picture" and significant details of operations via a cohesive interface similar to those of social networking services (SNS). Instead of recreational social features, "CommDash" would support functions like console logging, categorized and threaded text chat streams with enhanced accountability and graphics display features, high-level status displays driven by telemetry or other events, and an on-screen hailing function for requesting voice or text stream conversation. Moving certain voice conversations to text streams would reduce confusion and stress in two ways. Within text conversations, there would be far less repetition of content since text conversations have visual persistence and are reviewable instantly, e.g., there s no need to brief new participants to a discussion -- they just read what s already there. Remaining voice traffic would stand out more clearly, and quieter voice loops means fewer "say again" calls and less distraction from visual and mental tasks, thus less stress. (Most flight controllers monitor 4 or 5 voice loops at once.) Links could be created from console log entries to chat selections so that underlying details are readily available yet unobtrusive. This would reduce the confusion that rises from having multiple and sometimes divergent copies of the same information due to cut/copy and paste operations, attachments, and asynchronous editing. This concept could apply to a plethora of real time control environments and to other settings with lots of information juggling. This paper explores the dashboard concept in further detail and chronicles the first phase of a NASA IT Labs (Information Technology) project that could lead to a working system

Scott, David w.↗
NASA NTRSDate not supplied

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↗
NASA NTRS2023

Safety Case for Small Uncrewed Aircraft Systems (sUAS) Beyond Visual Line of Sight (BVLOS) Operations at NASA Langley Research Center

This Technical Memorandum (TM) is written to provide for dissemination of the methods and safety considerations for operations of small Uncrewed Aerial Systems (sUAS) Beyond Visual Line-of-Sight (BVLOS)at NASA Langley Research Center. It includes the Safety Case used to acquire a BVLOS Certificate of Authorization (COA) from the FAA and is being published to enable others to benefit from this work. The intended operations, subject to approval from the Federal Aviation Administration (FAA) and the National Aeronautics and Space Administration (NASA), will include a combination of Within Visual Line of Sight (WVLOS) and Beyond Visual Line of Sight (BVLOS) flights, comprising of at most five sUAS operating concurrently, with no more than three operating BVLOS. Flights will occur in a subset of the Langley Air Force Base (LAFB) Class D airspace (KLFI) at a maximum altitude of 400 ft AGL. Most operations within this subset will take place in the City Environment Range Testing for Autonomous Integrated Navigation (CERTAIN) Range. The CERTAIN Range includes airspace inside the borders of NASA Langley Research Center (LaRC). Additional airspace over the northern section of CERTAIN will be requested as part of the Certificate of Authorization (COA). NASA LaRC BVLOS operations on the CERTAIN Range can be broken down into five critical components needed to meet the 14 CFR § 91.113 see and avoid requirement: 1) procedural deconfliction with LAFB for UAS operations at or below 400 ft and manned aircraft at or above 900’ AGL; 2) ground equipment for detection of intruder aircraft and to support communications between crewmembers ; 3) sUAS vehicles with advanced onboard automation capable of autonomously maintaining safe separation; 4) BVLOS standardized operating procedures (SOPs); 5) and personnel to execute the flight operations in accordance with the SOPs and respond to airborne contingencies. The introduction of new ground equipment includes the use of the Remote Operations for Autonomous Missions (ROAM) UAS Operations Center, development and use of an Integrated Airspace Display (IAD), use of the L-STAR and GA-9120 radars, and the incorporation of standardized Vertiports. The ROAM Operations Center will be the central point for all BVLOS sUAS operations. All command and control (C2), voice communications and airspace awareness displays will reside inside ROAM. The IAD will provide raw data from ADS-B, FLARM, radar tracks and telemetered GPS vehicle positions for interpretation by an Airspace Monitor. The radars will search the class D airspace around the CERTAIN Range and serve as a backup to procedural deconfliction procedures coordinated with LAFB. In the event of a procedural deconfliction breakdown, radar detections of non-participating aircraft will be available so that the 91.113 see and avoid requirement can still be safely met. Finally, the incorporation of Vertiports will have video and network connectivity that enables large numbers of sUAS launches and recoveries from a single location. This is a continuation of the remote command and control of unpiloted aircraft component focused on evaluating unpiloted aircraft flight crew roles and responsibilities, control interfaces and the associated data links needed to operate a fleet of aircraft within a UAM Ecosystem. This work supports the development of future aviation operational concepts based on an Urban Air Mobility Maturity Level (UML) 4 environment (Patterson, 2020). It is assumed that future airspace will include hundreds of simultaneous aircraft operations within the airspace, therefore scalable operations are essential for enabling this future airspace to become a reality. Follow on work includes envisioned flights that expand operations beyond the CERTAIN range and lead to an effective Maritime Surveillance capability.

Matthew W Coldsnow↗