SEARCH · Search NASA

Results for “virtual control 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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 127 records · Page 7

All sources NASA NTRS DOE OSTI

NASA NTRS2000

Information Power Grid: Distributed High-Performance Computing and Large-Scale Data Management for Science and Engineering

We use the term "Grid" to refer to distributed, high performance computing and data handling infrastructure that incorporates geographically and organizationally dispersed, heterogeneous resources that are persistent and supported. This infrastructure includes: (1) Tools for constructing collaborative, application oriented Problem Solving Environments / Frameworks (the primary user interfaces for Grids); (2) Programming environments, tools, and services providing various approaches for building applications that use aggregated computing and storage resources, and federated data sources; (3) Comprehensive and consistent set of location independent tools and services for accessing and managing dynamic collections of widely distributed resources: heterogeneous computing systems, storage systems, real-time data sources and instruments, human collaborators, and communications systems; (4) Operational infrastructure including management tools for distributed systems and distributed resources, user services, accounting and auditing, strong and location independent user authentication and authorization, and overall system security services The vision for NASA's Information Power Grid - a computing and data Grid - is that it will provide significant new capabilities to scientists and engineers by facilitating routine construction of information based problem solving environments / frameworks. Such Grids will knit together widely distributed computing, data, instrument, and human resources into just-in-time systems that can address complex and large-scale computing and data analysis problems. Examples of these problems include: (1) Coupled, multidisciplinary simulations too large for single systems (e.g., multi-component NPSS turbomachine simulation); (2) Use of widely distributed, federated data archives (e.g., simultaneous access to metrological, topological, aircraft performance, and flight path scheduling databases supporting a National Air Space Simulation systems}; (3) Coupling large-scale computing and data systems to scientific and engineering instruments (e.g., realtime interaction with experiments through real-time data analysis and interpretation presented to the experimentalist in ways that allow direct interaction with the experiment (instead of just with instrument control); (5) Highly interactive, augmented reality and virtual reality remote collaborations (e.g., Ames / Boeing Remote Help Desk providing field maintenance use of coupled video and NDI to a remote, on-line airframe structures expert who uses this data to index into detailed design databases, and returns 3D internal aircraft geometry to the field); (5) Single computational problems too large for any single system (e.g. the rotocraft reference calculation). Grids also have the potential to provide pools of resources that could be called on in extraordinary / rapid response situations (such as disaster response) because they can provide common interfaces and access mechanisms, standardized management, and uniform user authentication and authorization, for large collections of distributed resources (whether or not they normally function in concert). IPG development and deployment is addressing requirements obtained by analyzing a number of different application areas, in particular from the NASA Aero-Space Technology Enterprise. This analysis has focussed primarily on two types of users: the scientist / design engineer whose primary interest is problem solving (e.g. determining wing aerodynamic characteristics in many different operating environments), and whose primary interface to IPG will be through various sorts of problem solving frameworks. The second type of user is the tool designer: the computational scientists who convert physics and mathematics into code that can simulate the physical world. These are the two primary users of IPG, and they have rather different requirements. The results of the analysis of the needs of these two types of users provides a broad set of requirements that gives rise to a general set of required capabilities. The IPG project is intended to address all of these requirements. In some cases the required computing technology exists, and in some cases it must be researched and developed. The project is using available technology to provide a prototype set of capabilities in a persistent distributed computing testbed. Beyond this, there are required capabilities that are not immediately available, and whose development spans the range from near-term engineering development (one to two years) to much longer term R&D (three to six years). Additional information is contained in the original.

Johnston, William E.↗

NASA NTRS2020

Wind Tunnel Investigation of the Supersonic Stage Separation Aerodynamics of a Generic 0.0175-Scale Bimese Two-Stage-to-Orbit Reusable Launch Vehicle Configuration

A wind tunnel investigation was conducted of the supersonic stage separation aerodynamics of a generic two-stage-to-orbit bimese wingbody configuration in the NASA Langley Research Center Unitary Plan Wind Tunnel. Proximity and isolated model testing was conducted at Mach numbers of 2.3, 3.0, and 4.5 and a unit Reynolds number of 2.0 million per foot using 0.0175-scale models of the Langley Glide-Back Booster concept designated as the orbiter and booster in belly-to-belly and back-to-belly configurations. Longitudinal forces and moments were obtained on both models and surface static pressure measurements were obtained on the orbiter model at 328 relative proximity locations and at relative angles of attack of 0 degrees and 5 degrees. The test results supported a larger effort to develop and validate experimental and computational tools applicable to the design and simulation of stage separation and abort procedures for reusable launch vehicles composed of multiple bodies, including winged bodies. An initial proof-of-concept experiment featuring low-cost uninstrumented models was conducted to verify an emerging automated model control system and new support system hardware, and to identify potential model and support system blockage and unsteady aerodynamics/model dynamics prior to committing to higher-fidelity instrumented models. This investigation led to upgrades in the facility stage separation hardware, calibration and testing techniques and capabilities, and data analysis and documentation methodologies that have been extended to the more recent NASA Constellation and Space Launch System crew and cargo launch vehicle programs. A virtual diagnostics interface methodology was used to facilitate the design of the stage separation support hardware, to position the models in the test section, and to define the experimental test space. Advances in the facility automated model positioning system established a foundation for the development of a continuous-sweep data acquisition technique that is responsible for significant productivity improvements to the current NASA Space Launch System test program. The automated model positioning capability was leveraged to conduct a companion statistically-designed stage separation experiment requiring randomization of the relative proximity positions of the orbiter and booster models. The respective zones of influence and interference effects of the orbiter and booster were identified from three-dimensional scatter plots, contour and influence maps, and two-dimensional plotting methods. The highly-nonlinear, shock-dominated aerodynamic characteristics of the orbiter and booster in the Unitary Plan Wind Tunnel exhibited good agreement with independent test data obtained in a NASA Marshall Space Flight Center wind tunnel and with computational fluid dynamics predictions using a compressible, three-dimensional flow solver and an inviscid, unstructured Cartesian method.

Erickson, Gary E.↗

NASA NTRS1988

Spacecraft flight simulation: A human factors investigation into the man-machine interface between an astronaut and a spacecraft performing docking maneuvers and other proximity operations

The anticipated increase in rendezvous and docking activities in the various space programs in the Space Station era necessitates a renewed interest in manual docking procedures. Ten test subjects participated in computer simulated docking missions in which the influence of initial velocity was examined. All missions started from a resting position of 304.8 meters (1000 feet) along the space station's +V-bar axis. Test subjects controlled their vehicle with a translational hand controller and digital auto pilot which are both virtually identical to their space shuttle counterparts. While the 0.1 percent rule (range rate is equal to 0.1 percent of the range) used by space shuttle pilots is comfortably safe, it is revealed to be extremely inefficient in terms of time and not justifiable in terms of marginal safety. Time is worth money, not only because of training and launch costs, but because the sooner a pilot and spacecraft return from a mission, the sooner they can begin the next one. Inexperienced test subjects reduced the costs of simulated docking by close to a factor of 2 and achieved safe dockings in less than 4 percent of the time the baseline approach would entail. This reduction in time can be used to save lives in the event of an accident on orbit, and can tremendously reduce docking costs if fuel is produced from waste water on orbit.

Brody, Adam R.↗

NASA NTRS1994

Lessons learned supporting onboard solid-state recorders

With the advance of semiconductor technology, Solid-State Recorders (SSR) have matured and been accepted as primary onboard data storage devices. Their high reliability, simpler interface and control, and high flexibility have made the SSR's a superb choice in today's spacecraft design. While there are many benefits, the use of SSR's may also add significant complexity to ground data systems. For instance, real-time and playback data may be interleaved into the same data stream, making data sequencing and time ordering difficult. Stored data may be played back out of time order, increasing processing load significantly. Data may also be played back after being sorted by Virtual Channels in the SSR, potentially creating bursts in packet rates that exceed the real-time processing capabilities of the ground systems. This paper presents a summary of lessons learned through the efforts in supporting a number of NASA's missions that employ SSR's. It describes various problems encountered through the design process, and their potential impact on ground system performance, resources, and cost. Recommended approaches to minimizing the impact are demonstrated by examples. The discussion leads to the conclusion that the use of SSR's demands an even higher level of cooperation between spacecraft and ground system designers in order to build the most cost effective end-to-end system.

Shi, Jeff↗

NASA NTRS2006

In-Space Crew-Collaborative Task Scheduling

As humans venture farther from Earth for longer durations, it will become essential for those on the journey to have significant control over the scheduling of their own activities as well as the activities of their companion systems and robots. However, the crew will not do all the scheduling; timelines will be the result of collaboration with ground personnel. Emerging technologies such as in-space message buses, delay-tolerant networks, and in-space internet will be the carriers on which the collaboration rides. Advances in scheduling technology, in the areas of task modeling, scheduling engines, and user interfaces will allow the crew to become virtual scheduling experts. New concepts of operations for producing the timeline will allow the crew and the ground support to collaborate while providing safeguards to ensure that the mission will be effectively accomplished without endangering the systems or personnel.

Jaap, John↗

NASA NTRS2006

Remote Collaboration on Task Scheduling for Humans at Mars

Jaap, John↗

NASA NTRS1994

The NASA Ames Closed Environmental Research Chamber: Present Status

The Closed Environmental Research Chamber (CERC) at the NASA Ames Research Center was created to investigate both components and complete systems for life support of advanced space exploration missions. This facility includes a Main Chamber, an Airlock, a Sample Transfer Lock, a Vacuum System, an Air Recompression System, a dedicated control room and a pit area for housing supporting and environmental control systems. The Main Chamber provides 310 sq ft of internal working/living space on two levels. It is planned that the CERC will be a human-rated facility for habitation simulation under mass balance closure conditions. The internal pressure will be variable over the range of 14.7 psia to 5 psia with accompanying capability for variation in atmosphere composition to maintain the oxygen partial pressure at 160 mm Hg. The CERC will be provided with a core set of primary life support subsystems for temperature and humidity control, C02 removal and trace contaminant control. Interfacing with external life support technology test b~ds with be provided, along with connection to centralized, microprocessor-based data acquisition and control systems. This paper will discuss the current status of the CERC facility and show how it is being used to address the advanced technology requirements necessary to implement an integrated working and living environment for a planetary habitat. In particular, it will be shown how the CERC, along with a human-powered centrifuge, a planetary terrain simulator and advanced displays and a virtual reality capability will work together to develop and demonstration applicable technologies for future planetary habitats. Artificial intelligence and expert system programming techniques will be used extensively to provide an automated environment for a 4-person crew. There will be several robotic mechanisms performing exploration tasks external to the habitat that will be controlled through the virtual environment to provide representative workloads for the crew. Finally, there will be a discussion of how effective are innovative new multidisciplinary test facilities to the investigation of the wide range of human and machine problems inherent in exploration missions.

Gross, Anthony R.↗

NASA NTRS2006

In-Space Crew-Collaborative Task Scheduling

As humans venture farther from earth for longer durations, it will become essential for those on the journey to have significant control over the scheduling of their own activities as well as the activities of their companion systems and robots. However, there are many reasons why the crew will not do all the scheduling; timelines will be the result of collaboration with ground personnel. Emerging technologies such as in-space message buses, delay-tolerant networks, and in-space internet will be the carriers on which the collaboration rides. Advances in scheduling technology, in the areas of task modeling, scheduling engines, and user interfaces will allow the crew to become virtual scheduling experts. New concepts of operations for producing the timeline will allow the crew and the ground support to collaborate while providing safeguards to ensure that the mission will be effectively accomplished without endangering the systems or personnel.

Jaap, John↗

NASA NTRS2005

VERSE - Virtual Equivalent Real-time Simulation

Distributed real-time simulations provide important timing validation and hardware in the- loop results for the spacecraft flight software development cycle. Occasionally, the need for higher fidelity modeling and more comprehensive debugging capabilities - combined with a limited amount of computational resources - calls for a non real-time simulation environment that mimics the real-time environment. By creating a non real-time environment that accommodates simulations and flight software designed for a multi-CPU real-time system, we can save development time, cut mission costs, and reduce the likelihood of errors. This paper presents such a solution: Virtual Equivalent Real-time Simulation Environment (VERSE). VERSE turns the real-time operating system RTAI (Real-time Application Interface) into an event driven simulator that runs in virtual real time. Designed to keep the original RTAI architecture as intact as possible, and therefore inheriting RTAI's many capabilities, VERSE was implemented with remarkably little change to the RTAI source code. This small footprint together with use of the same API allows users to easily run the same application in both real-time and virtual time environments. VERSE has been used to build a workstation testbed for NASA's Space Interferometry Mission (SIM PlanetQuest) instrument flight software. With its flexible simulation controls and inexpensive setup and replication costs, VERSE will become an invaluable tool in future mission development.

virtual real time↗

NASA NTRS1994

Technology transfer of operator-in-the-loop simulation

The technology developed for operator-in-the-loop simulation in space teleoperation has been applied to Caterpillar's backhoe, wheel loader, and off-highway truck. On an SGI workstation, the simulation integrates computer modeling of kinematics and dynamics, real-time computational and visualization, and an interface with the operator through the operator's console. The console is interfaced with the workstation through an IBM-PC in which the operator's commands were digitized and sent through an RS-232 serial port. The simulation gave visual feedback adequate for the operator in the loop, with the camera's field of vision projected on a large screen in multiple view windows. The view control can emulate either stationary or moving cameras. This simulator created an innovative engineering design environment by integrating computer software and hardware with the human operator's interactions. The backhoe simulation has been adopted by Caterpillar in building a virtual reality tool for backhoe design.

Yae, K. H.↗

NASA NTRS2007

Deep Space Network Antenna Logic Controller

The Antenna Logic Controller (ALC) software controls and monitors the motion control equipment of the 4,000-metric-ton structure of the Deep Space Network 70-meter antenna. This program coordinates the control of 42 hydraulic pumps, while monitoring several interlocks for personnel and equipment safety. Remote operation of the ALC runs via the Antenna Monitor & Control (AMC) computer, which orchestrates the tracking functions of the entire antenna. This software provides a graphical user interface for local control, monitoring, and identification of faults as well as, at a high level, providing for the digital control of the axis brakes so that the servo of the AMC may control the motion of the antenna. Specific functions of the ALC also include routines for startup in cold weather, controlled shutdown for both normal and fault situations, and pump switching on failure. The increased monitoring, the ability to trend key performance characteristics, the improved fault detection and recovery, the centralization of all control at a single panel, and the simplification of the user interface have all reduced the required workforce to run 70-meter antennas. The ALC also increases the antenna availability by reducing the time required to start up the antenna, to diagnose faults, and by providing additional insight into the performance of key parameters that aid in preventive maintenance to avoid key element failure. The ALC User Display (AUD) is a graphical user interface with hierarchical display structure, which provides high-level status information to the operation of the ALC, as well as detailed information for virtually all aspects of the ALC via drill-down displays. The operational status of an item, be it a function or assembly, is shown in the higher-level display. By pressing the item on the display screen, a new screen opens to show more detail of the function/assembly. Navigation tools and the map button allow immediate access to all screens.

Ahlstrom, Harlow↗

NASA NTRS2017

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↗

NASA NTRS2008

Virtual Satellite

Virtual Satellite (VirtualSat) is a computer program that creates an environment that facilitates the development, verification, and validation of flight software for a single spacecraft or for multiple spacecraft flying in formation. In this environment, enhanced functionality and autonomy of navigation, guidance, and control systems of a spacecraft are provided by a virtual satellite that is, a computational model that simulates the dynamic behavior of the spacecraft. Within this environment, it is possible to execute any associated software, the development of which could benefit from knowledge of, and possible interaction (typically, exchange of data) with, the virtual satellite. Examples of associated software include programs for simulating spacecraft power and thermal- management systems. This environment is independent of the flight hardware that will eventually host the flight software, making it possible to develop the software simultaneously with, or even before, the hardware is delivered. Optionally, by use of interfaces included in VirtualSat, hardware can be used instead of simulated. The flight software, coded in the C or C++ programming language, is compilable and loadable into VirtualSat without any special modifications. Thus, VirtualSat can serve as a relatively inexpensive software test-bed for development test, integration, and post-launch maintenance of spacecraft flight software.

Hammrs, Stephan R.↗

NASA NTRS2020

X-HAB 2020: AR Field Treks Summary and Conclusions

As part of the FY20 X-Hab Challenge, BLiSS sought to create an Augmented Reality (AR) toolkit to help with analog field trek operations under the supervision of the Solar System Exploration Research Virtual Institute (SSERVI). These treks are operational and technical demonstrations at space-like destinations on Earth to test current extra-vehicular activity (EVA) techniques. While BLiSS as an organization has experience studying operational tasks such as this, it has never developed AR software at this scale. For that reason, another team at the University was brought on to work in parallel. The Collaborative Lab for Advancing Work in Space (CLAWS) is a veteran group of the NASA Spacesuit User Interface Technologies for Students (SUITS) challenge in which Hololens displays for astronauts are created within a year. The operational and technological pairing was ideally suited for tackling this problem. The team divided its responsibilities so that BLiSS would handle the research required to shape the project. As this deliverable had an end user, it was decided that interviewing these field geologists and operations specialists would provide the best insight. These interviews paired with literature review would reveal niche applications for AR that remained within feasible bounds. These science-driven EVAs in unknown terrain require more flexible tools than the current generation of EVA assistants. Rather than focus on sequential instructions, there instead needs to be a broad toolkit that's only called upon in specific instances. This AR Toolkit for Lunar Astronauts and Scientists (ATLAS) became the development goal of the project: create a non-intrusive assembly of tools that could be accessed in AR on the field. The current ATLAS design makes use of a geospatially and temporally annotated eld note system called GeoNotes. This allows for data to be collected and coordinated in a way that's synchronized across time, space, and different users. A Mission Control Center (MCC) and Mobile Support Equipment (MSE) were all needed to transport the AR headset into the field with the user. A network infrastructure was designed and set up within the University to enable this functionality. The software is based on a Protocol-Module structure that allows for modular development of each capability. A Protocol Manager coordinates different protocols that make use of modules. Each module tackles a different individual task while the protocol puts each one to use. The protocol manager coordinates when these are called to be used. This software is hosted on a head-mounted display (HMD) with the MCC acting as support from afar. While the software would be unit-tested at each level and each hardware component verified, a final demonstration would serve to prove the system's capabilities: an analog field trek. The team would prepare to support a user in a remote location from the MCC back at the University. A local area near campus would be tested before going out to do sample field geology further away. This unfortunately became impossible with the arrival of COVID-19. Access to all of the facilities to complete the project as planned were shut down. Our team was scattered across the globe and forced to complete the rest virtually. Adjustments were made to produce a small virtual concept in Adobe XD in the meantime. Even digital surveys were created based on the NASA task-load index (TLX) originally intended for testing actual users. The goal shifted towards completing software and getting feedback on the user interfaces (UI) and user experiences (UX). This team has reformed in response to COVID and its focus has shifted to what can be done remotely. There is still an intention to finish the original deliverable described in this report. The work has been expanded beyond the original X-Hab challenge and has instead become its own research e ort to be continued afterwards. This report collects the processes and knowledge gained from a year of studying and working at this problem with two teams. It should preserve it for the time until the world returns to normal and work can resume. CLAWS will be taking over full responsibility from that point forward, eventually surpassing the original needs of the project. While this document captures the work done towards an eventual end, the CLAWS team has written their own proposal alongside it. It outlines a new future for ATLAS beyond X-Hab, BLiSS, and hopefully beyond COVID-19. This project began as a vague goal hoping to place a new technology into the unique setting of exploration science. The project has since comfortably taken root and will hopefully bloom over the next year.

Alex Sena↗

NASA NTRS1996

Integration of the Shuttle RMS/CBM Positioning Virtual Environment Simulation

Constructing the International Space Station, or other structures, in space presents a number of problems. In particular, payload restrictions for the Space Shuttle and other launch mechanisms prohibit assembly of large space-based structures on Earth. Instead, a number of smaller modules must be boosted into orbit separately and then assembled to form the final structure. The assembly process is difficult, as docking interfaces such as Common Berthing Mechanisms (CBMS) must be precisely positioned relative to each other to be within the "capture envelope" (approximately +/- 1 inch and +/- 0.3 degrees from the nominal position) and attach properly. In the case of the Space Station, the docking mechanisms are to be positioned robotically by an astronaut using the 55-foot-long Remote Manipulator System (RMS) robot arm. Unfortunately, direct visual or video observation of the placement process is difficult or impossible in many scenarios. One method that has been tested for aligning the CBMs uses a boresighted camera mounted on one CBM to view a standard target on the opposing CBM. While this method might be sufficient to achieve proper positioning with considerable effort, it does not provide a high level of confidence that the mechanisms have been placed within capture range of each other. It also does nothing to address the risk of inadvertent contact between the CBMS, which could result in RMS control software errors. In general, constraining the operator to a single viewpoint with few, if any, depth cues makes the task much more difficult than it would be if the target could be viewed in three-dimensional space from various viewpoints. The actual work area could be viewed by an astronaut during EVA; however, it would be extremely impractical to have an astronaut control the RMS while spacewalking. On the other hand, a view of the RMS and CBMs to be positioned in a virtual environment aboard the Space Shuttle orbiter or Space Station could provide similar benefits more safely and conveniently with little additional cost. In order to render and view the RMS and CBMs in a virtual world, the position and orientation of the end effector in three-dimensional space must be known with a high degree of accuracy. A precision video alignment sensor has been developed which can determine the position and orientation of the controlled element relative to the target CBM within approximately one-sixteenth inch and 0.07 angular degrees. Such a sensor could replace or augment the boresighted camera mentioned above. The computer system used to render the virtual world and the position tracking systems which might be used to monitor the user's movements (in order to adjust the viewpoint in virtual space) are small enough to carry to orbit. Thus, such a system would be feasible for use in constructing structures in space.

Dumas, Joseph D.↗

NASA NTRS2013

Gesture-Based Robot Control with Variable Autonomy from the JPL Biosleeve

This paper presents a new gesture-based human interface for natural robot control. Detailed activity of the user's hand and arm is acquired via a novel device, called the BioSleeve, which packages dry-contact surface electromyography (EMG) and an inertial measurement unit (IMU) into a sleeve worn on the forearm. The BioSleeve's accompanying algorithms can reliably decode as many as sixteen discrete hand gestures and estimate the continuous orientation of the forearm. These gestures and positions are mapped to robot commands that, to varying degrees, integrate with the robot's perception of its environment and its ability to complete tasks autonomously. This flexible approach enables, for example, supervisory point-to-goal commands, virtual joystick for guarded teleoperation, and high degree of freedom mimicked manipulation, all from a single device. The BioSleeve is meant for portable field use; unlike other gesture recognition systems, use of the BioSleeve for robot control is invariant to lighting conditions, occlusions, and the human-robot spatial relationship and does not encumber the user's hands. The BioSleeve control approach has been implemented on three robot types, and we present proof-of-principle demonstrations with mobile ground robots, manipulation robots, and prosthetic hands.

BioSleeve↗

NASA NTRS2007

Interface for Physics Simulation Engines

DSS-Prototyper is an open-source, realtime 3D virtual environment software that supports design simulation for the new Vision for Space Exploration (VSE). This is a simulation of NASA's proposed Robotic Lunar Exploration Program, second mission (RLEP2). It simulates the Lunar Surface Access Module (LSAM), which is designed to carry up to four astronauts to the lunar surface for durations of a week or longer. This simulation shows the virtual vehicle making approaches and landings on a variety of lunar terrains. The physics of the descent engine thrust vector, production of dust, and the dynamics of the suspension are all modeled in this set of simulations. The RLEP2 simulations are drivable (by keyboard or joystick) virtual rovers with controls for speed and motor torque, and can be articulated into higher or lower centers of gravity (depending on driving hazards) to enable drill placement. Gravity also can be set to lunar, terrestrial, or zero-g. This software has been used to support NASA's Marshall Space Flight Center in simulations of proposed vehicles for robotically exploring the lunar surface for water ice, and could be used to model all other aspects of the VSE from the Ares launch vehicles and Crew Exploration Vehicle (CEV) to the International Space Station (ISS). This simulator may be installed and operated on any Windows PC with an installed 3D graphics card.

Damer, Bruce↗

NASA NTRS2016

NASA Alternative Orion Small Cell Battery Design Support

The NASA Orion Crew Module Reference Design was produced to address large scale thermal runaway (TR) hazard with specific safety controls for the Orion Spacecraft. The design presented provides the description of a full scale battery design reference for implementation as a drop in replacement to meet all spacecraft energy requirements with compatible 120 Vdc electrical and mechanical interface using small cell technology (18650) packaging. The 32V SuperBrick incorporates unique support features and an electrical bus bar arrangement that allows cells negative can insertion into heat sink that is compressively coupled to the battery enclosure to promote good thermal management. The housing design also provides an internal flame suppression "filter tray" and positive venting path internal to the enclosure to allow hot effluent ejecta to escape in the event of single cell TR. Virtual cells (14P Banks) that are supported to provide cell spacing with interstitial materials to prevent side can failures that can produce cell to cell TR propagation. These features were successfully test in four separate TR run with the full scale DTA1 test article in February 2016. Successfully Completed Test Objectives - Four separate TR test runs with Full-Scale DTA1 housing with Two SuperBricks, Two SuperBrick Emulators All Tests resulted in "clean" gas with less than 6 C rise at Battery vent All Tests resulted in less than 2 C temperature rise on cold-plate outlet All Tests resulted in less than 6 psi pressure rise in the battery housing Test Run 1 -One neighbor cell TR, highest remaining neighbor 139 C. Ejecta shorted to bus caused prolonged additional heating, One shorted cell did experience TR after 12 minutes, remaining cells had adequate thermal margin Test Run 2 - No cell to cell propagation, highest neighbor cell 112 C; Test Run 3 - No cell to cell propagation, highest neighbor cell 96 C; Test Run 4 - No cell to cell propagation, highest neighbor cell 101 C; Primary TR testing and analysis were completed and reviewed for endorsement by NASA Engineering and Safety Center team members. All Key Test Objectives were met and the small cell design alternative was demonstrated and selected to be a feasible drop in replacement for the MPCV Orion CM Battery for EM2 mission.

Haynes, Chuck↗