Search NASA⌕ Search

SEARCH · Search NASA

Results for “Microsoft”

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

Transition Marshall Space Flight Center Wind Profiler Splicing Algorithm to Launch Services Program Upper Winds Tool

NASAs LSP customers and the future SLS program rely on observations of upper-level winds for steering, loads, and trajectory calculations for the launch vehicles flight. On the day of launch, the 45th Weather Squadron (45 WS) Launch Weather Officers (LWOs) monitor the upper-level winds and provide forecasts to the launch team via the AMU-developed LSP Upper Winds tool for launches at Kennedy Space Center (KSC) and Cape Canaveral Air Force Station. This tool displays wind speed and direction profiles from rawinsondes released during launch operations, the 45th Space Wing 915-MHz Doppler Radar Wind Profilers (DRWPs) and KSC 50-MHz DRWP, and output from numerical weather prediction models.The goal of this task was to splice the wind speed and direction profiles from the 45th Space Wing (45 SW) 915-MHz Doppler radar Wind Profilers (DRWPs) and KSC 50-MHz DRWP at altitudes where the wind profiles overlap to create a smooth profile. In the first version of the LSP Upper Winds tool, the top of the 915-MHz DRWP wind profile and the bottom of the 50-MHz DRWP were not spliced, sometimes creating a discontinuity in the profile. The Marshall Space Flight Center (MSFC) Natural Environments Branch (NE) created algorithms to splice the wind profiles from the two sensors to generate an archive of vertically complete wind profiles for the SLS program. The AMU worked with MSFC NE personnel to implement these algorithms in the LSP Upper Winds tool to provide a continuous spliced wind profile.The AMU transitioned the MSFC NE algorithms to interpolate and fill data gaps in the data, implement a Gaussian weighting function to produce 50-m altitude intervals in each sensor, and splice the data together from both DRWPs. They did so by porting the MSFC NE code written with MATLAB software into Microsoft Excel Visual Basic for Applications (VBA). After testing the new algorithms in stand-alone VBA modules, the AMU replaced the existing VBA code in the LSP Upper Winds tool with the new algorithms. They then tested the code in the LSP Upper Winds tool with archived data. The tool will be delivered to the 45 WS after the 50-MHz DRWP upgrade is complete and the tool is tested with real-time data. The 50-MHz DRWP upgrade is expected to be finished in October 2014.

Space launch↗

A Tool for the Automated Collection of Space Utilization Data: Three Dimensional Space Utilization Monitor

Space Human Factors and Habitability (SHFH) Element within the Human Research Program (HRP), in collaboration with the Behavioral Health and Performance (BHP) Element, is conducting research regarding Net Habitable Volume (NHV), the internal volume within a spacecraft or habitat that is available to crew for required activities, as well as layout and accommodations within that volume. NASA is looking for innovative methods to unobtrusively collect NHV data without impacting crew time. Data required includes metrics such as location and orientation of crew, volume used to complete tasks, internal translation paths, flow of work, and task completion times. In less constrained environments methods for collecting such data exist yet many are obtrusive and require significant post‐processing. Example technologies used in terrestrial settings include infrared (IR) retro‐reflective marker based motion capture, GPS sensor tracking, inertial tracking, and multiple camera filmography. However due to constraints of space operations many such methods are infeasible, such as inertial tracking systems which typically rely upon a gravity vector to normalize sensor readings, and traditional IR systems which are large and require extensive calibration. However multiple technologies have not yet been applied to space operations for these explicit purposes. Two of these include 3‐Dimensional Radio Frequency Identification Real‐Time Localization Systems (3D RFID‐RTLS) and depth imaging systems which allow for 3D motion capture and volumetric scanning (such as those using IR‐depth cameras like the Microsoft Kinect or Light Detection and Ranging / Light‐Radar systems, referred to as LIDAR).

Vos, Gordon A.↗

System Enhancements for Mechanical Inspection Processes

Quality inspection of parts is a major component to any project that requires hardware implementation. Keeping track of all of the inspection jobs is essential to having a smooth running process. By using HTML, the programming language ColdFusion, and the MySQL database, I created a web-based job management system for the 170 Mechanical Inspection Group that will replace the Microsoft Access based management system. This will improve the ways inspectors and the people awaiting inspection view and keep track of hardware as it is in the inspection process. In the end, the management system should be able to insert jobs into a queue, place jobs in and out of a bonded state, pre-release bonded jobs, and close out inspection jobs.

inspection processes↗

Data Interconnection Exploration

This project involves innovating the way the Quality Assurance organization at the Jet Propulsion Laboratory (JPL) tracks the receiving inspection of JPL Critical Items (JCI) procured from suppliers. The Quality Assurance organization uses a Microsoft Access based front-end to enter items into an inspection queue. The current design has grown to be much more than was expected when the inspection queue system was created in 2007. The goal is to migrate to a web based solution that will allow the handling of more data, multiple input interfaces, and customizable display options. This has been achieved by implementing a divided tables scheme, the use of ColdFusion programming language, and the usage of Web 2.0 technologies such as AJAX and jQuery. These updates will allow for future expansion as well as the standardization of inspection queues for the Quality Assurance organization. When engineers and scientists order flight hardware, they cannot use it straight away. After a spacecraft or a satellite has been launched, it will be impossible to repair; therefore, the parts used must be inspected to make sure they are operating correctly and within the required specifications. The task of inspecting these JPL Critical Items (JCI) falls on the Quality Assurance organization. One of the tools the receiving inspection group uses is a database to maintain a queue of inspections that need to be done and of inspections that have been completed. The current Access interface has worked well but increased amounts of data, multiple input interfaces, and changes to how data is handled have made it necessary to seek a new way of organizing items for inspection. In addition, the different inspection groups have recently been merged and each has different ways of keeping track of inspection information. The ultimate goal is for the new group to have one shared inspection queue and website. To achieve this goal, I have been working with Ian Luczon of Procurement Quality Assurance and 3 Myers Hawkins, another intern, to not only create the new queue for receiving inspection but also a central web portal for the newly combined inspection group.

flight hardware↗

Smarter Earth Science Data System

The explosive growth in Earth observational data in the recent decade demands a better method of interoperability across heterogeneous systems. The Earth science data system community has mastered the art in storing large volume of observational data, but it is still unclear how this traditional method scale over time as we are entering the age of Big Data. Indexed search solutions such as Apache Solr (Smiley and Pugh, 2011) provides fast, scalable search via keyword or phases without any reasoning or inference. The modern search solutions such as Googles Knowledge Graph (Singhal, 2012) and Microsoft Bing, all utilize semantic reasoning to improve its accuracy in searches. The Earth science user community is demanding for an intelligent solution to help them finding the right data for their researches. The Ontological System for Context Artifacts and Resources (OSCAR) (Huang et al., 2012), was created in response to the DARPA Adaptive Vehicle Make (AVM) programs need for an intelligent context models management system to empower its terrain simulation subsystem. The core component of OSCAR is the Environmental Context Ontology (ECO) is built using the Semantic Web for Earth and Environmental Terminology (SWEET) (Raskin and Pan, 2005). This paper presents the current data archival methodology within a NASA Earth science data centers and discuss using semantic web to improve the way we capture and serve data to our users.

data center↗

Domain-Specific Languages and Diagram Customization for a Concurrent Engineering Environment

A major open question for advocates of Model-Based Systems Engineering (MBSE) is the question of how system and subsystem engineers will work together. The Systems Modeling Language (SysML), like any language intended for a large audience, is in tension between the desires for simplicity and for expressiveness. In order to be more expressive, many specialized language elements may be introduced, which will unfortunately make a complete understanding of the language a more daunting task. While this may be acceptable for systems modelers, it will increase the challenge of including subsystem engineers in the modeling effort. One possible answer to this situation is the use of Domain-Specific Languages (DSL), which are fully supported by the Unified Modeling Language (UML). SysML is in fact a DSL for systems engineering. The expressive power of a DSL can be enhanced through the use of diagram customization. Various domains have already developed their own schematic vocabularies. Within the space engineering community, two excellent examples are the propulsion and telecommunication subsystems. A return to simple box-and-line diagrams (e.g., the SysML Internal Block Diagram) are in many ways a step backward. In order allow subsystem engineers to contribute directly to the model, it is necessary to make a system modeling tool at least approximate in accessibility to drawing tools like Microsoft PowerPoint and Visio. The challenge is made more extreme in a concurrent engineering environment, where designs must often be drafted in an hour or two. In the case of the Jet Propulsion Laboratory's Team X concurrent design team, a subsystem is specified using a combination of PowerPoint for drawing and Excel for calculation. A pilot has been undertaken in order to meld the drawing portion and the production of master equipment lists (MELs) via a SysML authoring tool, MagicDraw. Team X currently interacts with its customers in a process of sharing presentations. There are several inefficiencies that arise from this situation. The first is that a customer team must wait two weeks to a month (which is 2-4 times the duration of most Team X studies themselves) for a finalized, detailed design description. Another is that this information must be re-entered by hand into the set of engineering artifacts and design tools that the mission concept team uses after a study is complete. Further, there is no persistent connection to Team X or institutionally shared formulation design tools and data after a given study, again reducing the direct reuse of designs created in a Team X study. This paper presents the underpinnings of subsystem DSLs as they were developed for this pilot. This includes specialized semantics for different domains as well as the process by which major categories of objects were derived in support of defining the DSLs. The feedback given to us by the domain experts on usability, along with a pilot study with the partial inclusion of these tools is also discussed.

Cole, Bjorn↗

Alssat Development Status and Its Applications in Trade Studies

The development of the Advanced Life Support (ALS) Sizing Analysis Tool (ALSSAT) using Microsoft® Excel was initiated by the Crew and Thermal Systems Division (CTSD) of Johnson Space Center (JSC) in 1997 to support the ALS and Exploration Offices in Environmental Control and Life Support System (ECLSS) design and studies. It aids the user in performing detailed sizing of the ECLSS based on suggested default values or user inputs for different combinations of the ALS regenerative system technologies (Ref. 1, 2). This analysis tool will assist the user in performing ECLSS preliminary design and trade studies as well as system optimization efficiently and economically. Since ALSSAT's latest publication in ICES 2001 (Ref. 1) describing the development of ALSSAT with its Air Revitalization Subsystem (ARS), Water Management Subsystem (WMS), and Biomass Subsystem (Biomass) mass balance sheets, ALSSAT has been expanded to include mass balance and sizing models for the remaining three ALS subsystems, namely, the Solid Waste Management Subsystem (SWMS), the Food Management Subsystem (FMS), and the Thermal Control Subsystem (TCS). The external interfaces, including the Extravehicular Activities (EVA) and Human Accommodations (HA), were implemented into ALSSAT in 2002. The overall mass balance sheet, which integrates the six ALS subsystems and the external interfaces applicable to the ECLSS, was also developed. In 2003, ALSSAT was upgraded to include the consideration of redundancy and contingency options in the ECLSS, as well as more ALS regenerative technology selections. ALSSAT has been used for the Metric Calculation for FY02 and FY03 (Ref. 3). Several trade studies were conducted in 2003. The analytical results will be presented in this paper.

Yeh, H. Y. (Jannivine)↗

Visual Stability of Objects and Environments Viewed through Head-Mounted Displays

Virtual Environments (aka Virtual Reality) is again catching the public imagination and a number of startups (e.g. Oculus) and even not-so-startup companies (e.g. Microsoft) are trying to develop display systems to capitalize on this renewed interest. All acknowledge that this time they will get it right by providing the required dynamic fidelity, visual quality, and interesting content for the concept of VR to take off and change the world in ways it failed to do so in past incarnations. Some of the surprisingly long historical background of the technology that the form of direct simulation that underlies virtual environment and augmented reality displays will be briefly reviewed. An example of a mid 1990's augmented reality display system with good dynamic performance from our lab will be used to illustrate some of the underlying phenomena and technology concerning visual stability of virtual environments and objects during movement. In conclusion some idealized performance characteristics for a reference system will be proposed. Interestingly, many systems more or less on the market now may actually meet many of these proposed technical requirements. This observation leads to the conclusion that the current success of the IT firms trying to commercialize the technology will depend on the hidden costs of using the systems as well as the development of interesting and compelling content.

virtual environment↗

NASA's X-Plane Database and Parametric Cost Model v 2.0

The NASA Armstrong Cost Engineering Team with technical assistance from NASA HQ (SID)has gone through the full process in developing new CERs from Version #1 to Version #2 CERs. We took a step backward and reexamined all of the data collected, such as dependent and independent variables, cost, dry weight, length, wingspan, manned versus unmanned, altitude, Mach number, thrust, and skin. We used a well- known statistical analysis tool called CO$TAT instead of using "R" multiple linear or the "Regression" tool found in Microsoft Excel(TradeMark). We setup an "array of data" by adding 21" dummy variables;" we analyzed the standard error (SE) and then determined the "best fit." We have parametrically priced-out several future X-planes and compared our results to those of other resources. More work needs to be done in getting "accurate and traceable cost data" from historical X-plane records!

life cycle cost↗

Medical Optimization Network for Space Telemedicine Resources

INTRODUCTION: Long-duration missions beyond low Earth orbit introduce new constraints to the space medical system. Beyond the traditional limitations in mass, power, and volume, consideration must be given to other factors such as the inability to evacuate to Earth, communication delays, and limitations in clinical skillsets. As NASA develops the medical system for an exploration mission, it must have an ability to evaluate the trade space of what resources will be most important. The Medical Optimization Network for Space Telemedicine Resources (MONSTR) was developed over the past year for this reason, and is now a system for managing data pertaining to medical resources and their relative importance when addressing medical conditions. METHODS: The MONSTR web application with a Microsoft SQL database backend was developed and made accessible to Tableau v9.3 for analysis and visualization. The database was initially populated with a list of medical conditions of concern for an exploration mission taken from the Integrated Medical Model (IMM), a probabilistic model designed to quantify in-flight medical risk. A team of physicians working within the Exploration Medical Capability Element of NASA's Human Research Program compiled a list diagnostic and treatment medical resources required to address best- and worst-case scenarios of each medical condition using a terrestrial standard of care and entered this data into the system. This list included both tangible resources (e.g. medical equipment, medications) and intangible resources (e.g. clinical skills required to perform a procedure). The physician team then assigned criticality values to each instance of a resource, representing the importance of that resource to diagnosing or treating its associated condition(s). Medical condition probabilities of occurrence during a Mars mission were pulled from the IMM and imported into the MONSTR database for use within a resource criticality-weighting algorithm. DISCUSSION: The MONSTR tool is a novel approach to assess the relative value of individual resources needed for the diagnosis and treatment of medical conditions. Future work will add resources for prevention and long term care of these conditions. Once data collection is complete, MONSTR will provide the operational and research communities at NASA with information to support informed decisions regarding areas of research investment, future crew training, and medical supplies manifested as part of any exploration medical system.

Rubin, D.↗

Automated ISS Flight Utilities

During my internship at NASA Johnson Space Center, I worked in the Space Radiation Analysis Group (SRAG), where I was tasked with a number of projects focused on the automation of tasks and activities related to the operation of the International Space Station (ISS). As I worked on a number of projects, I have written short sections below to give a description for each, followed by more general remarks on the internship experience. My first project is titled "General Exposure Representation EVADOSE", also known as "GEnEVADOSE". This project involved the design and development of a C++/ ROOT framework focused on radiation exposure for extravehicular activity (EVA) planning for the ISS. The utility helps mission managers plan EVAs by displaying information on the cumulative radiation doses that crew will receive during an EVA as a function of the egress time and duration of the activity. SRAG uses a utility called EVADOSE, employing a model of the space radiation environment in low Earth orbit to predict these doses, as while outside the ISS the astronauts will have less shielding from charged particles such as electrons and protons. However, EVADOSE output is cumbersome to work with, and prior to GEnEVADOSE, querying data and producing graphs of ISS trajectories and cumulative doses versus egress time required manual work in Microsoft Excel. GEnEVADOSE automates all this work, reading in EVADOSE output file(s) along with a plaintext file input by the user providing input parameters. GEnEVADOSE will output a text file containing all the necessary dosimetry for each proposed EVA egress time, for each specified EVADOSE file. It also plots cumulative dose versus egress time and the ISS trajectory, and displays all of this information in an auto-generated presentation made in LaTeX. New features have also been added, such as best-case scenarios (egress times corresponding to the least dose), interpolated curves for trajectories, and the ability to query any time in the EVADES output. As mentioned above, GEnEVADOSE makes extensive use of ROOT version 6, the data analysis framework developed at the European Organization for Nuclear Research (CERN), and the code is written to the C++11 standard (as are the other projects). My second project is the Automated Mission Reference Exposure Utility (AMREU).Unlike GEnEVADOSE, AMREU is a combination of three frameworks written in both Python and C++, also making use of ROOT (and PyROOT). Run as a combination of daily and weekly cron jobs, these macros query the SRAG database system to determine the active ISS missions, and query minute-by-minute radiation dose information from ISS-TEPC (Tissue Equivalent Proportional Counter), one of the radiation detectors onboard the ISS. Using this information, AMREU creates a corrected data set of daily radiation doses, addressing situations where TEPC may be offline or locked up by correcting doses for days with less than 95% live time (the total amount time the instrument acquires data) by averaging the past 7 days. As not all errors may be automatically detectable, AMREU also allows for manual corrections, checking an updated plaintext file each time it runs. With the corrected data, AMREU generates cumulative dose plots for each mission, and uses a Python script to generate a flight note file (.docx format) containing these plots, as well as information sections to be filled in and modified by the space weather environment officers with information specific to the week. AMREU is set up to run without requiring any user input, and it automatically archives old flight notes and information files for missions that are no longer active. My other projects involve cleaning up a large data set from the Charged Particle Directional Spectrometer (CPDS), joining together many different data sets in order to clean up information in SRAG SQL databases, and developing other automated utilities for displaying information on active solar regions, that may be used by the space weather environment officers to monitor solar activity. I consulted my mentor Dr. Ryan Rios and Dr. Kerry Lee for project requirements and added features, and ROOT developer Edmond Offermann for advice on using the ROOT library. I also received advice and feedback from Dr. Janet Barzilla of SRAG, who tested my code. Besides these inputs, I worked independently, writing all of the code by myself. The code for all these projects is documented throughout, and I have attempted to write it in a modular format. Assuming that ROOT is updated accordingly, these codes are also Y2038-compliant (and Y10K-compliant). This allows the code to be easily referenced, modified and possibly repurposed for non-ISS missions in the future, should the necessary inputs exist. These projects have taught me a lot about coding and software design - I have become a much more skilled C++ programmer and ROOT user, and I also learned to code in Python and PyROOT (and its advantages and disadvantages compared to C++/ ROOT). Furthermore, I have learned about space radiation and radiation modeling, topics that greatly interest me as I pursue a degree in physics. Working alongside experimental physicists like Dr. Rios, I have developed a greater understanding and appreciation for experimental science, something I have always leaned towards but to which I lacked significant exposure. My work in SRAG has also given me the invaluable opportunity to witness the work environment for physicists at NASA, and what a career in academia may look like at a government laboratory such as NASA Johnson Space Center. As I continue my studies and look forward to graduate school and a future career, this experience at NASA has given me a meaningful and enjoyable opportunity to put my skills to use and see what my future career path might hold.

Offermann, Jan Tuzlic↗

A Tool for the Automated Collection of Space Utilization Data: Three Dimensional Space Utilization Monitor

Space Human Factors and Habitability (SHFH) Element within the Human Research Program (HRP) and the Behavioral Health and Performance (BHP) Element are conducting research regarding Net Habitable Volume (NHV), the internal volume within a spacecraft or habitat that is available to crew for required activities, as well as layout and accommodations within the volume. NASA needs methods to unobtrusively collect NHV data without impacting crew time. Data required includes metrics such as location and orientation of crew, volume used to complete tasks, internal translation paths, flow of work, and task completion times. In less constrained environments methods exist yet many are obtrusive and require significant post-processing. Examplesused in terrestrial settings include infrared (IR) retro-reflective marker based motion capture, GPS sensor tracking, inertial tracking, and multi-camera methods Due to constraints of space operations many such methods are infeasible. Inertial tracking systems typically rely upon a gravity vector to normalize sensor readings,and traditional IR systems are large and require extensive calibration. However, multiple technologies have not been applied to space operations for these purposes. Two of these include: 3D Radio Frequency Identification Real-Time Localization Systems (3D RFID-RTLS) Depth imaging systems which allow for 3D motion capture and volumetric scanning (such as those using IR-depth cameras like the Microsoft Kinect or Light Detection and Ranging / Light-Radar systems, referred to as LIDAR)

Vos, Gordon A.↗

Modeling ARRM Xenon Tank Pressurization Using 1D Thermodynamic and Heat Transfer Equations

As a first step in understanding what ground support equipment (GSE) is required to provide external cooling during the loading of 5,000 kg of xenon into 4 aluminum lined composite overwrapped pressure vessels (COPVs), a modeling analysis was performed using Microsoft Excel. The goals of the analysis were to predict xenon temperature and pressure throughout loading at the launch facility, estimate the time required to load one tank, and to get an early estimate of what provisions for cooling xenon might be needed while the tanks are being filled. The model uses the governing thermodynamic and heat transfer equations to achieve these goals. Results indicate that a single tank can be loaded in about 15 hours with reasonable external coolant requirements. The model developed in this study was successfully validated against flight and test data. The first data set is from the Dawn mission which also utilizes solar electric propulsion with xenon propellant, and the second is test data from the rapid loading of a hydrogen cylindrical COPV. The main benefit of this type of model is that the governing physical equations using bulk fluid solid temperatures can provide a quick and accurate estimate of the state of the propellant throughout loading which is much cheaper in terms of computational time and licensing costs than a Computation Fluid Dynamics (CFD) analysis while capturing the majority of the thermodynamics and heat transfer.

Xenon storage↗

Modeling Xenon Tank Pressurization using One-Dimensional Thermodynamic and Heat Transfer Equations

As a first step in understanding what ground support equipment (GSE) is required to provide external cooling during the loading of 5,000 kg of xenon into 4 aluminum lined composite overwrapped pressure vessels (COPVs), a modeling analysis was performed using Microsoft Excel. The goals of the analysis were to predict xenon temperature and pressure throughout loading at the launch facility, estimate the time required to load one tank, and to get an early estimate of what provisions for cooling xenon might be needed while the tanks are being filled. The model uses the governing thermodynamic and heat transfer equations to achieve these goals. Results indicate that a single tank can be loaded in about 15 hours with reasonable external coolant requirements. The model developed in this study was successfully validated against flight and test data. The first data set is from the Dawn mission which also utilizes solar electric propulsion with xenon propellant, and the second is test data from the rapid loading of a hydrogen cylindrical COPV. The main benefit of this type of model is that the governing physical equations using bulk fluid solid temperatures can provide a quick and accurate estimate of the state of the propellant throughout loading which is much cheaper in terms of computational time and licensing costs than a Computation Fluid Dynamics (CFD) analysis while capturing the majority of the thermodynamics and heat transfer.

Thermodynamic tank modeling↗

Engine Icing Data - An Analytics Approach

Engine icing researchers at the NASA Glenn Research Center use the Escort data acquisition system in the Propulsion Systems Laboratory (PSL) to generate and collect a tremendous amount of data every day. Currently these researchers spend countless hours processing and formatting their data, selecting important variables, and plotting relationships between variables, all by hand, generally analyzing data in a spreadsheet-style program (such as Microsoft Excel). Though spreadsheet-style analysis is familiar and intuitive to many, processing data in spreadsheets is often unreproducible and small mistakes are easily overlooked. Spreadsheet-style analysis is also time inefficient. The same formatting, processing, and plotting procedure has to be repeated for every dataset, which leads to researchers performing the same tedious data munging process over and over instead of making discoveries within their data. This paper documents a data analysis tool written in Python hosted in a Jupyter notebook that vastly simplifies the analysis process. From the file path of any folder containing time series datasets, this tool batch loads every dataset in the folder, processes the datasets in parallel, and ingests them into a widget where users can search for and interactively plot subsets of columns in a number of ways with a click of a button, easily and intuitively comparing their data and discovering interesting dynamics. Furthermore, comparing variables across data sets and integrating video data (while extremely difficult with spreadsheet-style programs) is quite simplified in this tool. This tool has also gathered interest outside the engine icing branch, and will be used by researchers across NASA Glenn Research Center. This project exemplifies the enormous benefit of automating data processing, analysis, and visualization, and will help researchers move from raw data to insight in a much smaller time frame.

Engine Icing↗

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↗

Virtual Exercise Training Software System

The purpose of this study was to develop and evaluate a virtual exercise training software system (VETSS) capable of providing real-time instruction and exercise feedback during exploration missions. A resistive exercise instructional system was developed using a Microsoft Kinect depth-camera device, which provides markerless 3-D whole-body motion capture at a small form factor and minimal setup effort. It was hypothesized that subjects using the newly developed instructional software tool would perform the deadlift exercise with more optimal kinematics and consistent technique than those without the instructional software. Following a comprehensive evaluation in the laboratory, the system was deployed for testing and refinement in the NASA Extreme Environment Mission Operations (NEEMO) analog.

Vu, L.↗

Biomolecule Sequencer: Next-Generation DNA Sequencing Technology for In-Flight Environmental Monitoring, Research, and Beyond

On the International Space Station (ISS), technologies capable of rapid microbial identification and disease diagnostics are not currently available. NASA still relies upon sample return for comprehensive, molecular-based sample characterization. Next-generation DNA sequencing is a powerful approach for identifying microorganisms in air, water, and surfaces onboard spacecraft. The Biomolecule Sequencer payload, manifested to SpaceX-9 and scheduled on the Increment 4748 research plan (June 2016), will assess the functionality of a commercially-available next-generation DNA sequencer in the microgravity environment of ISS. The MinION device from Oxford Nanopore Technologies (Oxford, UK) measures picoamp changes in electrical current dependent on nucleotide sequences of the DNA strand migrating through nanopores in the system. The hardware is exceptionally small (9.5 x 3.2 x 1.6 cm), lightweight (120 grams), and powered only by a USB connection. For the ISS technology demonstration, the Biomolecule Sequencer will be powered by a Microsoft Surface Pro3. Ground-prepared samples containing lambda bacteriophage, Escherichia coli, and mouse genomic DNA, will be launched and stored frozen on the ISS until experiment initiation. Immediately prior to sequencing, a crew member will collect and thaw frozen DNA samples, connect the sequencer to the Surface Pro3, inject thawed samples into a MinION flow cell, and initiate sequencing. At the completion of the sequencing run, data will be downlinked for ground analysis. Identical, synchronous ground controls will be used for data comparisons to determine sequencer functionality, run-time sequence, current dynamics, and overall accuracy. We will present our latest results from the ISS flight experiment the first time DNA has ever been sequenced in space and discuss the many potential applications of the Biomolecule Sequencer for environmental monitoring, medical diagnostics, higher fidelity and more adaptable Space Biology Human Research Program investigations, and even life detection experiments for astrobiology missions.

Sequencer↗