SEARCH · Engineering Papers

Results for “gui”

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 199 records · Page 11

All sources NASA NTRS DOE OSTI

NASA NTRS2003

LabVIEW Serial Driver Software for an Electronic Load

A LabVIEW-language computer program enables monitoring and control of a Transistor Devices, Inc., Dynaload WCL232 (or equivalent) electronic load via an RS-232 serial communication link between the electronic load and a remote personal computer. (The electronic load can operate at constant voltage, current, power consumption, or resistance.) The program generates a graphical user interface (GUI) at the computer that looks and acts like the front panel of the electronic load. Once the electronic load has been placed in remote-control mode, this program first queries the electronic load for the present values of all its operational and limit settings, and then drops into a cycle in which it reports the instantaneous voltage, current, and power values in displays that resemble those on the electronic load while monitoring the GUI images of pushbuttons for control actions by the user. By means of the pushbutton images and associated prompts, the user can perform such operations as changing limit values, the operating mode, or the set point. The benefit of this software is that it relieves the user of the need to learn one method for operating the electronic load locally and another method for operating it remotely via a personal computer.

Scullin, Vincent↗

NASA NTRS2003

NASA Tech Briefs, September 2003

Topics include: Oxygen-Partial-Pressure Sensor for Aircraft Oxygen Mask; Three-Dimensional Venturi Sensor for Measuring Extreme Winds; Swarms of Micron-Sized Sensors; Monitoring Volcanoes by Use of Air-Dropped Sensor Packages; Capacitive Sensors for Measuring Masses of Cryogenic Fluids; UHF Microstrip Antenna Array for Synthetic- Aperture Radar; Multimode Broad-Band Patch Antennas; 164-GHz MMIC HEMT Frequency Doubler; GPS Position and Heading Circuitry for Ships; Software for Managing Parametric Studies; Software Aids Visualization of Computed Unsteady Flow; Software for Testing Electroactive Structural Components; Advanced Software for Analysis of High-Speed Rolling-Element Bearings; Web Program for Development of GUIs for Cluster Computers; XML-Based Generator of C++ Code for Integration With GUIs; Oxide Protective Coats for Ir/Re Rocket Combustion Chambers; Simplified Waterproofing of Aerogels; Improved Thermal-Insulation Systems for Low Temperatures; Device for Automated Cutting and Transfer of Plant Shoots; Extension of Liouville Formalism to Postinstability Dynamics; Advances in Thrust-Based Emergency Control of an Airplane; Ultrasonic/Sonic Mechanisms for Drilling and Coring; Exercise Device Would Exert Selectable Constant Resistance; Improved Apparatus for Measuring Distance Between Axles; Six Classes of Diffraction-Based Optoelectronic Instruments; Modernizing Fortran 77 Legacy Codes; Active State Model for Autonomous Systems; Shields for Enhanced Protection Against High-Speed Debris; Scaling of Two-Phase Flows to Partial-Earth Gravity; Neutral-Axis Springs for Thin-Wall Integral Boom Hinges.

Source record↗

NASA NTRS2003

High-Speed Recording of Test Data on Hard Disks

Disk Recording System (DRS) is a systems-integration computer program for a direct-to-disk (DTD) high-speed data acquisition system (HDAS) that records rocket-engine test data. The HDAS consists partly of equipment originally designed for recording the data on tapes. The tape recorders were replaced with hard-disk drives, necessitating the development of DRS to provide an operating environment that ties two computers, a set of five DTD recorders, and signal-processing circuits from the original tape-recording version of the HDAS into one working system. DRS includes three subsystems: (1) one that generates a graphical user interface (GUI), on one of the computers, that serves as a main control panel; (2) one that generates a GUI, on the other computer, that serves as a remote control panel; and (3) a data-processing subsystem that performs tasks on the DTD recorders according to instructions sent from the main control panel. The software affords capabilities for dynamic configuration to record single or multiple channels from a remote source, remote starting and stopping of the recorders, indexing to prevent overwriting of data, and production of filtered frequency data from an original time-series data file.

Lagarde, Paul M., Jr.↗

NASA NTRS2012

User's Guide for the Commercial Modular Aero-Propulsion System Simulation (C-MAPSS): Version 2

This report is a Users Guide for version 2 of the NASA-developed Commercial Modular Aero-Propulsion System Simulation (C-MAPSS) software, which is a transient simulation of a large commercial turbofan engine (up to 90,000-lb thrust) with a realistic engine control system. The software supports easy access to health, control, and engine parameters through a graphical user interface (GUI). C-MAPSS v.2 has some enhancements over the original, including three actuators rather than one, the addition of actuator and sensor dynamics, and an improved controller, while retaining or improving on the convenience and user-friendliness of the original. C-MAPSS v.2 provides the user with a graphical turbofan engine simulation environment in which advanced algorithms can be implemented and tested. C-MAPSS can run user-specified transient simulations, and it can generate state-space linear models of the nonlinear engine model at an operating point. The code has a number of GUI screens that allow point-and-click operation, and have editable fields for user-specified input. The software includes an atmospheric model which allows simulation of engine operation at altitudes from sea level to 40,000 ft, Mach numbers from 0 to 0.90, and ambient temperatures from -60 to 103 F. The package also includes a power-management system that allows the engine to be operated over a wide range of thrust levels throughout the full range of flight conditions.

Liu, Yuan↗

NASA NTRS2012

System-of-Systems Technology-Portfolio-Analysis Tool

Advanced Technology Life-cycle Analysis System (ATLAS) is a system-of-systems technology-portfolio-analysis software tool. ATLAS affords capabilities to (1) compare estimates of the mass and cost of an engineering system based on competing technological concepts; (2) estimate life-cycle costs of an outer-space-exploration architecture for a specified technology portfolio; (3) collect data on state-of-the-art and forecasted technology performance, and on operations and programs; and (4) calculate an index of the relative programmatic value of a technology portfolio. ATLAS facilitates analysis by providing a library of analytical spreadsheet models for a variety of systems. A single analyst can assemble a representation of a system of systems from the models and build a technology portfolio. Each system model estimates mass, and life-cycle costs are estimated by a common set of cost models. Other components of ATLAS include graphical-user-interface (GUI) software, algorithms for calculating the aforementioned index, a technology database, a report generator, and a form generator for creating the GUI for the system models. At the time of this reporting, ATLAS is a prototype, embodied in Microsoft Excel and several thousand lines of Visual Basic for Applications that run on both Windows and Macintosh computers.

O'Neil, Daniel↗

NASA NTRS2012

Vandenberg Air Force Base Upper Level Wind Launch Weather Constraints

The 30th Operational Support Squadron Weather Flight (30 OSSWF) provides comprehensive weather services to the space program at Vandenberg Air Force Base (VAFB) in California. One of their responsibilities is to monitor upper-level winds to ensure safe launch operations of the Minuteman III ballistic missile. The 30 OSSWF tasked the Applied Meteorology Unit (AMU) to analyze VAFB sounding data with the goal of determining the probability of violating (PoV) their upper-level thresholds for wind speed and shear constraints specific to this launch vehicle, and to develop a tool that will calculate the PoV of each constraint on the day of launch. In order to calculate the probability of exceeding each constraint, the AMU collected and analyzed historical data from VAFB. The historical sounding data were retrieved from the National Oceanic and Atmospheric Administration Earth System Research Laboratory archive for the years 1994-2011 and then stratified into four sub-seasons: January-March, April-June, July-September, and October-December. The maximum wind speed and 1000-ft shear values for each sounding in each subseason were determined. To accurately calculate the PoV, the AMU determined the theoretical distributions that best fit the maximum wind speed and maximum shear datasets. Ultimately it was discovered that the maximum wind speeds follow a Gaussian distribution while the maximum shear values follow a lognormal distribution. These results were applied when calculating the averages and standard deviations needed for the historical and real-time PoV calculations. In addition to the requirements outlined in the original task plan, the AMU also included forecast sounding data from the Rapid Refresh model. This information provides further insight for the launch weather officers (LWOs) when determining if a wind constraint violation will occur over the next few hours on day of launch. The interactive graphical user interface (GUI) for this project was developed in Microsoft Excel using Visual Basic for Applications. The GUI displays the critical sounding data easily and quickly for the LWOs on day of launch. This tool will replace the existing one used by the 30 OSSWF, assist the LWOs in determining the probability of exceeding specific wind threshold values, and help to improve the overall upper winds forecast for the launch customer.

Shafer, Jaclyn A.↗

NASA NTRS2013

Integrating Wind Profiling Radars and Radiosonde Observations with Model Point Data to Develop a Decision Support Tool to Assess Upper-Level Winds for Space Launch

On the day-of-launch, the 45th Weather Squadron (45 WS) Launch Weather Officers (LWOs) monitor the upper-level winds for their launch customers to include NASA's Launch Services Program and NASA's Ground Systems Development and Operations Program. They currently do not have the capability to display and overlay profiles of upper-level observations and numerical weather prediction model forecasts. The LWOs requested the Applied Meteorology Unit (AMU) develop a tool in the form of a graphical user interface (GUI) that will allow them to plot upper-level wind speed and direction observations from the Kennedy Space Center (KSC) 50 MHz tropospheric wind profiling radar, KSC Shuttle Landing Facility 915 MHz boundary layer wind profiling radar and Cape Canaveral Air Force Station (CCAFS) Automated Meteorological Processing System (AMPS) radiosondes, and then overlay forecast wind profiles from the model point data including the North American Mesoscale (NAM) model, Rapid Refresh (RAP) model and Global Forecast System (GFS) model to assess the performance of these models. The AMU developed an Excel-based tool that provides an objective method for the LWOs to compare the model-forecast upper-level winds to the KSC wind profiling radars and CCAFS AMPS observations to assess the model potential to accurately forecast changes in the upperlevel profile through the launch count. The AMU wrote Excel Visual Basic for Applications (VBA) scripts to automatically retrieve model point data for CCAFS (XMR) from the Iowa State University Archive Data Server (http://mtarchive.qeol.iastate.edu) and the 50 MHz, 915 MHz and AMPS observations from the NASA/KSC Spaceport Weather Data Archive web site (http://trmm.ksc.nasa.gov). The AMU then developed code in Excel VBA to automatically ingest and format the observations and model point data in Excel to ready the data for generating Excel charts for the LWO's. The resulting charts allow the LWOs to independently initialize the three models 0-hour forecasts against the observations to determine which is the best performing model and then overlay the model forecasts on time-matched observations during the launch countdown to further assess the model performance and forecasts. This paper will demonstrate integration of observed and predicted atmospheric conditions into a decision support tool and demonstrate how the GUI is implemented in operations.

Bauman, William H., III↗

NASA NTRS2012

Assessing Upper-Level Winds on Day-of-Launch

On the day-or-launch. the 45th Weather Squadron Launch Weather Officers (LWOS) monitor the upper-level winds for their launch customers to include NASA's Launch Services Program (LSP). During launch operations, the payload launch team sometimes asks the LWO if they expect the upper level winds to change during the countdown but the LWOs did not have the capability to quickly retrieve or display the upper-level observations and compare them to the numerical weather prediction model point forecasts. The LWOs requested the Applied Meteorology Unit (AMU) develop a capability in the form of a graphical user interface (GUI) that would allow them to plot upper-level wind speed and direction observations from the Kennedy Space Center Doppler Radar Wind Profilers and Cape Canaveral Air Force Station rawinsondes and then overlay model point forecast profiles on the observation profiles to assess the performance of these models and graphically display them to the launch team. The AMU developed an Excel-based capability for the LWOs to assess the model forecast upper-level winds and compare them to observations. They did so by creating a GUI in Excel that allows the LWOs to first initialize the models by comparing the O-hour model forecasts to the observations and then to display model forecasts in 3-hour intervals from the current time through 12 hours.

Bauman, William H., III↗

NASA NTRS2013

The General-Use Nodal Network Solver (GUNNS) Modeling Package for Space Vehicle Flow System Simulation

The General-Use Nodal Network Solver (GUNNS) is a modeling software package that combines nodal analysis and the hydraulic-electric analogy to simulate fluid, electrical, and thermal flow systems. GUNNS is developed by L-3 Communications under the TS21 (Training Systems for the 21st Century) project for NASA Johnson Space Center (JSC), primarily for use in space vehicle training simulators at JSC. It has sufficient compactness and fidelity to model the fluid, electrical, and thermal aspects of space vehicles in real-time simulations running on commodity workstations, for vehicle crew and flight controller training. It has a reusable and flexible component and system design, and a Graphical User Interface (GUI), providing capability for rapid GUI-based simulator development, ease of maintenance, and associated cost savings. GUNNS is optimized for NASA's Trick simulation environment, but can be run independently of Trick.

Harvey, Jason↗

NASA NTRS2008

Statistical Short-Range Guidance for Peak Wind Speed Forecasts at Edwards Air Force Base, CA

The peak winds near the surface are an important forecast element for Space Shuttle landings. As defined in the Shuttle Flight Rules (FRs), there are peak wind thresholds that cannot be exceeded in order to ensure the safety of the shuttle during landing operations. The National Weather Service Spaceflight Meteorology Group (SMG) is responsible for weather forecasts for all shuttle landings. They indicate peak winds are a challenging parameter to forecast. To alleviate the difficulty in making such wind forecasts, the Applied Meteorology Unit (AMTJ) developed a personal computer based graphical user interface (GUI) for displaying peak wind climatology and probabilities of exceeding peak-wind thresholds for the Shuttle Landing Facility (SLF) at Kennedy Space Center. However, the shuttle must land at Edwards Air Force Base (EAFB) in southern California when weather conditions at Kennedy Space Center in Florida are not acceptable, so SMG forecasters requested that a similar tool be developed for EAFB. Marshall Space Flight Center (MSFC) personnel archived and performed quality control of 2-minute average and 10-minute peak wind speeds at each tower adjacent to the main runway at EAFB from 1997- 2004. They calculated wind climatologies and probabilities of average peak wind occurrence based on the average speed. The climatologies were calculated for each tower and month, and were stratified by hour, direction, and direction/hour. For the probabilities of peak wind occurrence, MSFC calculated empirical and modeled probabilities of meeting or exceeding specific 10-minute peak wind speeds using probability density functions. The AMU obtained and reformatted the data into Microsoft Excel PivotTables, which allows users to display different values with point-click-drag techniques. The GUT was then created from the PivotTables using Visual Basic for Applications code. The GUI is run through a macro within Microsoft Excel and allows forecasters to quickly display and interpret peak wind climatology and likelihoods in a fast-paced operational environment. A summary of how the peak wind climatologies and probabilities were created and an overview of the GUT will be presented.

Dreher, Joseph↗

NASA NTRS2013

Remote Data Exploration with the Interactive Data Language (IDL)

A difficulty for many NASA researchers is that often the data to analyze is located remotely from the scientist and the data is too large to transfer for local analysis. Researchers have developed the Data Access Protocol (DAP) for accessing remote data. Presently one can use DAP from within IDL, but the IDL-DAP interface is both limited and cumbersome. A more powerful and user-friendly interface to DAP for IDL has been developed. Users are able to browse remote data sets graphically, select partial data to retrieve, import that data and make customized plots, and have an interactive IDL command line session simultaneous with the remote visualization. All of these IDL-DAP tools are usable easily and seamlessly for any IDL user. IDL and DAP are both widely used in science, but were not easily used together. The IDL DAP bindings were incomplete and had numerous bugs that prevented their serious use. For example, the existing bindings did not read DAP Grid data, which is the organization of nearly all NASA datasets currently served via DAP. This project uniquely provides a fully featured, user-friendly interface to DAP from IDL, both from the command line and a GUI application. The DAP Explorer GUI application makes browsing a dataset more user-friendly, while also providing the capability to run user-defined functions on specified data. Methods for running remote functions on the DAP server were investigated, and a technique for accomplishing this task was decided upon.

Galloy, Michael↗

NASA NTRS2013

Adams-Based Rover Terramechanics and Mobility Simulator - ARTEMIS

The Mars Exploration Rovers (MERs), Spirit and Opportunity, far exceeded their original drive distance expectations and have traveled, at the time of this reporting, a combined 29 kilometers across the surface of Mars. The Rover Sequencing and Visualization Program (RSVP), the current program used to plan drives for MERs, is only a kinematic simulator of rover movement. Therefore, rover response to various terrains and soil types cannot be modeled. Although sandbox experiments attempt to model rover-terrain interaction, these experiments are time-intensive and costly, and they cannot be used within the tactical timeline of rover driving. Imaging techniques and hazard avoidance features on MER help to prevent the rover from traveling over dangerous terrains, but mobility issues have shown that these methods are not always sufficient. ARTEMIS, a dynamic modeling tool for MER, allows planned drives to be simulated before commands are sent to the rover. The deformable soils component of this model allows rover-terrain interactions to be simulated to determine if a particular drive path would take the rover over terrain that would induce hazardous levels of slip or sink. When used in the rover drive planning process, dynamic modeling reduces the likelihood of future mobility issues because high-risk areas could be identified before drive commands are sent to the rover, and drives planned over these areas could be rerouted. The ARTEMIS software consists of several components. These include a preprocessor, Digital Elevation Models (DEMs), Adams rover model, wheel and soil parameter files, MSC Adams GUI (commercial), MSC Adams dynamics solver (commercial), terramechanics subroutines (FORTRAN), a contact detection engine, a soil modification engine, and output DEMs of deformed soil. The preprocessor is used to define the terrain (from a DEM) and define the soil parameters for the terrain file. The Adams rover model is placed in this terrain. Wheel and soil parameter files can be altered in the respective text files. The rover model and terrain are viewed in Adams View, the GUI for ARTEMIS. The Adams dynamics solver calls terramechanics subroutines in FORTRAN containing the Bekker-Wong equations.

Trease, Brian P.↗

NASA NTRS2013

Translating MAPGEN to ASPEN for MER

This software translates MAPGEN (Europa and APGEN) domains to ASPEN, and the resulting domain can be used to perform planning for the Mars Exploration Rover (MER). In other words, this is a conversion of two distinct planning languages (both declarative and procedural) to a third (declarative) planning language in order to solve the problem of faithful translation from mixed-domain representations into the ASPEN Modeling Language. The MAPGEN planning system is an example of a hybrid procedural/declarative system where the advantages of each are leveraged to produce an effective planner/scheduler for MER tactical planning. The adaptation of the planning system (ASPEN) was investigated, and, with some translation, much of the procedural knowledge encoding is amenable to declarative knowledge encoding. The approach was to compose translators from the core languages used for adapting MAGPEN, which consists of Europa and APGEN. Europa is a constraint- based planner/scheduler where domains are encoded using a declarative model. APGEN is also constraint-based, in that it tracks constraints on resources and states and other variables. Domains are encoded in both constraints and code snippets that execute according to a forward sweep through the plan. Europa and APGEN communicate to each other using proxy activities in APGEN that represent constraints and/or tokens in Europa. The composition of a translator from Europa to ASPEN was fairly straightforward, as ASPEN is also a declarative planning system, and the specific uses of Europa for the MER domain matched ASPEN s native encoding fairly closely. On the other hand, translating from APGEN to ASPEN was considerably more involved. On the surface, the types of activities and resources one encodes in APGEN appear to match oneto- one to the activities, state variables, and resources in ASPEN. But, when looking into the definitions of how resources are profiled and activities are expanded, one sees code snippets that access various information available during planning for the moment in time being planned to decide at the time what the appropriate profile or expansion is. APGEN is actually a forward (in time) sweeping discrete event simulator, where the model is composed of code snippets that are artfully interleaved by the engine to produce a plan/schedule. To solve this problem, representative code is simulated as a declarative series of task expansions. Predominantly, three types of procedural models were translated: loops, if statements, and code blocks. Loops and if statements were handled using controlled task expansion, and code blocks were handled using constraint networks that maintained the generation of results based on what the order of execution would be for a procedural representation. One advantage with respect to performance for MAPGEN is the use of APGEN s GUI. This GUI is written in C++ and Motif, and performs very well for large plans.

Rabideau, Gregg R.↗

NASA NTRS2013

Orbital Debris Engineering Model (ORDEM) v.3

A model of the manmade orbital debris environment is required by spacecraft designers, mission planners, and others in order to understand and mitigate the effects of the environment on their spacecraft or systems. A manmade environment is dynamic, and can be altered significantly by intent (e.g., the Chinese anti-satellite weapon test of January 2007) or accident (e.g., the collision of Iridium 33 and Cosmos 2251 spacecraft in February 2009). Engineering models are used to portray the manmade debris environment in Earth orbit. The availability of new sensor and in situ data, the re-analysis of older data, and the development of new analytical and statistical techniques has enabled the construction of this more comprehensive and sophisticated model. The primary output of this model is the flux [#debris/area/time] as a function of debris size and year. ORDEM may be operated in spacecraft mode or telescope mode. In the former case, an analyst defines an orbit for a spacecraft and "flies" the spacecraft through the orbital debris environment. In the latter case, an analyst defines a ground-based sensor (telescope or radar) in terms of latitude, azimuth, and elevation, and the model provides the number of orbital debris traversing the sensor's field of view. An upgraded graphical user interface (GUI) is integrated with the software. This upgraded GUI uses project-oriented organization and provides the user with graphical representations of numerous output data products. These range from the conventional flux as a function of debris size for chosen analysis orbits (or views), for example, to the more complex color-contoured two-dimensional (2D) directional flux diagrams in local spacecraft elevation and azimuth.

Matney, Mark↗

NASA NTRS2013

Datacasting V3.0

Datacasting V3.0 provides an RSSbased feed mechanism for publishing the availability of Earth science data records in real time. It also provides a utility for subscribing to these feeds and sifting through all the items in an automatic manner to identify and download the data records that are required for a specific application. Datacasting is a method by which multiple data providers can publish the availability of new Earth science data and users download those files that meet a predefined need; for example, to only download data files related to a specific earthquake or region on the globe. Datacasting is a server-client architecture. The server-side software is used by data providers to create and publish the metadata about recently available data according to the Datacasting RSS (Really Simple Syndication) specification. The client software subscribes to the Datacasting RSS and other RSS-based feeds. By configuring filters associated with feeds, data consumers can use the client to identify and automatically download files that meet a specific need. On the client side, a Datacasting feed reader monitors the server for new feeds. The feed reader will be tuned by the user, via a graphical user interface (GUI), to examine the content of the feeds and initiate a data pull after some criteria are satisfied. The criteria might be, for example, to download sea surface temperature data for a particular region that has cloud cover less than 50% and during daylight hours. After the granule is downloaded to the client, the user will have the ability to visualize the data in the GUI. Based on the popular concept of podcasting, which gives listeners the capability to download only those MP3 files that match their preference, Earth science Datacasting will give users a method to download only the Earth science data files that are required for a particular application.

Bingham, Andrew W.↗

NASA NTRS2013

Flat Surface Damage Detection System (FSDDS)

The Flat Surface Damage Detection system (FSDDS} is a sensory system that is capable of detecting impact damages to surfaces utilizing a novel sensor system. This system will provide the ability to monitor the integrity of an inflatable habitat during in situ system health monitoring. The system consists of three main custom designed subsystems: the multi-layer sensing panel, the embedded monitoring system, and the graphical user interface (GUI). The GUI LABVIEW software uses a custom developed damage detection algorithm to determine the damage location based on the sequence of broken sensing lines. It estimates the damage size, the maximum depth, and plots the damage location on a graph. Successfully demonstrated as a stand alone technology during 2011 D-RATS. Software modification also allowed for communication with HDU avionics crew display which was demonstrated remotely (KSC to JSC} during 2012 integration testing. Integrated FSDDS system and stand alone multi-panel systems were demonstrated remotely and at JSC, Mission Operations Test using Space Network Research Federation (SNRF} network in 2012. FY13, FSDDS multi-panel integration with JSC and SNRF network Technology can allow for integration with other complementary damage detection systems.

Williams, Martha↗

NASA NTRS2014

Robot Task Commander with Extensible Programming Environment

A system for developing distributed robot application-level software includes a robot having an associated control module which controls motion of the robot in response to a commanded task, and a robot task commander (RTC) in networked communication with the control module over a network transport layer (NTL). The RTC includes a script engine(s) and a GUI, with a processor and a centralized library of library blocks constructed from an interpretive computer programming code and having input and output connections. The GUI provides access to a Visual Programming Language (VPL) environment and a text editor. In executing a method, the VPL is opened, a task for the robot is built from the code library blocks, and data is assigned to input and output connections identifying input and output data for each block. A task sequence(s) is sent to the control module(s) over the NTL to command execution of the task.

Hart, Stephen W↗

NASA NTRS2015

Analysis of Human-Spacesuit Interaction

Astronauts sustain injuries of various natures such as finger delamination, joint pain, and redness due to their interaction with the space suit. The role of the Anthropometry and Biomechanics Facility is to understand the biomechanics, environmental variables, and ergonomics of the suit. This knowledge is then used to make suggestions for improvement in future iterations of the space suit assembly to prevent injuries while allowing astronauts maneuverability, comfort, and tactility. The projects I was involved in were the Extravehicular Mobility Unit (EMU) space suit stiffness study and the glove feasibility study. The EMU project looked at the forces exerted on the shoulder, arm, and wrist when subjects performed kinematic tasks with and without a pressurized suit. The glove study consisted of testing three conditions - the Series 4000 glove, the Phase VI glove, and the no glove condition. With more than forty channels of sensor data total, it was critical to develop programs that could analyze data with basic descriptive statistics and generate relevant graphs to help understand what happens within the space suit and glove. In my project I created a Graphical User Interface (GUI) in MATLAB that would help me visualize what each sensor was doing within a task. The GUI is capable of displaying overlain plots and can be synchronized with video. This was helpful during the stiffness testing to visualize how the forces on the arm acted while the subject performed tasks such as shoulder adduction/abduction and bicep curls. The main project of focus, however, was the glove comparison study. I wrote MATLAB programs which generated movies of the strain vectors during specific tasks. I also generated graphs that summarized the differences between each glove for the strain, shear and FSR sensors. Preliminary results indicate that the Phase VI glove places less strain and shear on the hand. Future work includes continued data analysis of surveys and sensor data. In the end, the ideal glove is one that provides more tactility for the astronauts but lessens injuries. Often times, a more tactile glove transmits forces better to the hand; thus, achieving a balance of both a tactile and safe glove is the main challenge present.

Thomas, Neha↗