SEARCH · Engineering Papers

Results for “Learning with errors”

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.

486 records · Page 27

All sources NASA NTRS DOE OSTI

NASA NTRS2005

Airdata Measurement and Calibration

This Section provides a brief introduction to airdata measurement and calibration. Readers will learn about typical test objectives, quantities to measure, and flight maneuvers and operations for calibration. The Section informs readers about tower-flyby, trailing cone, pacer, radar-tracking, and dynamic airdata calibration maneuvers. Readers will also begin to understand how some data analysis considerations and special airdata cases, including high-angle-of-attack flight, high-speed flight, and nonobtrusive sensors are handled. This section is not intended to be all inclusive; readers should review AGARDograph 300, Volume 1, "Calibration of Airdata Systems and Flow Direction Sensors" for more detailed information. [11-1] References 11-2, 11-3, and 11-4 also supply pertinent information to better understand airdata measurement and calibration and related terminology. Airdata are vital to successfully complete an aircraft's mission and are derived from the air surrounding the aircraft. These airdata encompass indicated and true airspeed, pressure altitude, ambient air temperature, angles of attack and sideslip, Mach number, and rate of climb. Typically, pitot and static pressures are sensed and converted (by mechanical means in the instruments themselves) into indications on the altimeter, vertical speed indicator, airspeed indicator, and Machmeter. Similarly, measured local flow angles establish angles of attack and sideslip, and the outside air temperature is measured and indicated in the cockpit. (Instruments that can perform the conversion, such as airspeed indicators, altimeters, and Machmeters, do not correct for errors in the input values.) These measured parameters are commonly input to the airdata computer which, using appropriate algorithms and correction factors (or calibrations, as discussed later), can provide other parameters, such as true airspeed, required by the aircraft's avionics or flight control system. The presence of the aircraft in the airstream causes input errors to the measuring instruments - the aircraft disturbs the air that it flies through, thereby also disturbing the airdata measurements. Figure 11-1 shows the airflow around an airplane wing. The air above the wing has lower pressure than the ambient air, while the pressure below the wing is higher than the ambient air. Compressibility and shock waves also disturb the air and affect the measurements. Compressibility effects become important above approximately Mach number 0.3. As a result the static pressure around an airplane varies considerably with location. Local flow angles also differ from the free-stream flow direction. In straight-and-level flight the airflow rises to the wing leading edge and falls below the trailing edge, causing errors in flow direction measurements. To some extent these errors can be studied in wind tunnels, but wind-tunnel measurements cannot replace in-flight measurements.

Haering, Edward A., Jr.↗

NASA NTRS2023

A Blind Convolutional Deep Autoencoder for Spectral Unmixing of Hyperspectral Images Over Waterbodies

Harmful algal blooms have dangerous repercussions for biodiversity, the ecosystem, and public health. Automatic identification based on remote sensing hyperspectral image analysis provides a valuable mechanism for extracting the spectral signatures of harmful algal blooms and their respective percentage in a region of interest. This paper proposes a new model called a non-symmetrical autoencoder for spectral unmixing to perform endmember extraction and fractional abundance estimation. The model is assessed in benchmark datasets, such as Jasper Ridge and Samson. Additionally, a case study of the HSI2 image acquired by NASA over Lake Erie in 2017 is conducted for extracting optical water types. The results using the proposed model for the benchmark datasets improve unmixing performance, as indicated by the spectral angle distance compared to five baseline algorithms. Improved results were obtained for various metrics. In the Samson dataset, the proposed model outperformed other methods for water (0.060) and soil (0.025) endmember extraction. Moreover, the proposed method exhibited superior performance in terms of mean spectral angle distance compared to the other five baseline algorithms. The non-symmetrical autoencoder for the spectral unmixing approach achieved better results for abundance map estimation, with a root mean square error of 0.091 for water and 0.187 for soil, compared to the ground truth. For the Jasper Ridge dataset, the non-symmetrical autoencoder for the spectral unmixing model excelled in the tree (0.039) and road (0.068) endmember extraction and also demonstrated improved results for water abundance maps (0.1121). The proposed model can identify the presence of chlorophyll-a in waterbodies. Chlorophyll-a is an essential indicator of the presence of the different concentrations of macrophytes and cyanobacteria. The non-symmetrical autoencoder for spectral unmixing achieves a value of 0.307 for the spectral angle distance metric compared to a reference ground truth spectral signature of chlorophyll-a. The source code for the proposed model, as implemented in this manuscript, can be found at https://github.com/EstefaniaAlfaro/autoencoder_owt_spectral.git.

hyperspectral imaging↗

NASA NTRSDate not supplied

US-EUSST SSA Data Exchange for Improved Orbital Safety

Data sharing and exchange among different Space Situational Awareness (SSA) data collectors/providers is frequently discussed as a mechanism to improve the accuracy and precision of orbital safety products. Indeed, at the conceptual level this claim is quite sensible: objects with more tracking, and thus presumably better distribution of that tracking about their orbit, should produce updates with smaller epoch errors and more realistic covariances at epoch, which should then translate into better performance in prediction and thus improved close approach calculations. However, this thesis has not been verified with any large study involving two different data providers, through which the amount of realized improvement can be quantified and, perhaps more importantly, the logistics of effecting observation data sharing in a regularized way can be established and circulated to assist others. To create rubrics for helpful data sharing for conjunction assessment applications, and to collect empirical data on the improvements achieved through sharing of measurement data, the US Office of Space Commerce and the European Union Space Surveillance and Tracking (EUSST) Support Framework have embarked on a joint experiment to collect and exchange satellite metric observations on selected satellites of interest over an experimental period. Each entity will perform orbit determination with their own observations, the other entity’s observations, and with both observation data sets combined. The product results will be compared with each other, showing differences attributable both to the three different data groups and to the two entities’ different approaches to orbit determination. The exemplar satellites include both objects that have external precision reference ephemerides and those that do not, allowing the experiment to exercise both precision-comparison and assimilative-comparison techniques. The present reporting will give preliminary results and a set of lessons learned for data sharing; a second presentation later in 2023 will provide a full accounting of the experiment’s results. The hope is that, through this work, a pathway can be established for the expeditious and fruitful sharing among collection entities, both commercial and governmental.

space situational awareness↗

NASA NTRS2001

Twenty Years of Radiation Measurements in Low-Earth Orbit - What Have We Learned Space Radiation Environment?

The advent of the Space Shuttle program has made possible space radiation environment measurements spanning a wide range of altitudes and orbital inclinations over multiple solar cycles. These measurements range from routine integral dose measurements with thermoluminescent dosimeters to particle energy spectra measurements made with a charged particle telescope. This paper will review the new understanding about the space radiation environment gained from this diverse data set. Major findings from these measurements include: estimations of the westward drift rate of the South Atlantic Anomaly (SAA) of 0.28-0.49/y; evidence for a northward component to the SAA drift of 0.08-0.12/y; observation of the formation and decay of the pseudo-stable additional radiation belt following the Mar 1991 SPE and geomagnetic storm with an estimated decay e-folding time of 9-10 months; observation of a local geomagnetic east-west trapped proton exposure anisotropy with an estimated magnitude of 1.6-3.3; demonstration that the trapped proton exposure in low-Earth orbit (LEO) can be reasonably modeled as a power law function of atmospheric density in the SAA region, with best correlations obtained when the exospheric temperature saturates at 938-975 K; the actual solar cycle modulation of trapped proton exposure in LEO is less than predicted by the AP8 model; and the testing and validation of GCR flux models, radiation transport codes, and dynamic geomagnetic cutoff models. Long-term, time-resolved proportional counter measurements made aboard the Mir during the same period provides further demonstration of the solar cycle modulation of the trapped protons at low altitudes - the observed modulation is also well described as power law function of atmospheric density. These data and findings have helped to improve the overall accuracy of pre-mission crew exposure projections using various semi-empirical space environment models, radiation transport codes, and spacecraft radiation shielding models. During the rise phase of solar cycle 22 (1987-1991), the RMS error between preflight exposure projections and measured crew exposure was 73%. For the rise phase of cycle 23 (1997-2001), the preflight exposure projection RMS error has decreased to 23%. The launch and assembly of the Space Station has begun a new era of long-term LEO space environment monitoring. The radiation environment at the Space Station will be monitored with three external charged particle telescopes oriented in the velocity vector, anti-velocity vector, and zenith directions. Data from the telescopes will provide charge, mass, energy, and arrival direction for incident particles with energy to mass ratios of 13- 450 MeV/amu and Z of 1-24. The external environment data will be complimented by measurements from a portable charged particle telescope and proportional counter located inside the vehicle.

Golightly, Michael J.↗

NASA NTRS2001

Enabling Advanced Automation in Spacecraft Operations with the Spacecraft Emergency Response System

True autonomy is the Holy Grail of spacecraft mission operations. The goal of launching a satellite and letting it manage itself throughout its useful life is a worthy one. With true autonomy, the cost of mission operations would be reduced to a negligible amount. Under full autonomy, any problems (no matter the severity or type) that may arise with the spacecraft would be handled without any human intervention via some combination of smart sensors, on-board intelligence, and/or smart automated ground system. Until the day that complete autonomy is practical and affordable to deploy, incremental steps of deploying ever-increasing levels of automation (computerization of once manual tasks) on the ground and on the spacecraft are gradually decreasing the cost of mission operations. For example, NASA's Goddard Space Flight Center (NASA-GSFC) has been flying spacecraft with low cost operations for several years. NASA-GSFC's SMEX (Small Explorer) and MIDEX (Middle Explorer) missions have effectively deployed significant amounts of automation to enable the missions to fly predominately in 'light-out' mode. Under light-out operations the ground system is run without human intervention. Various tools perform many of the tasks previously performed by the human operators. One of the major issues in reducing human staff in favor of automation is the perceived increased in risk of losing data, or even losing a spacecraft, because of anomalous conditions that may occur when there is no one in the control center. When things go wrong, missions deploying advanced automation need to be sure that anomalous conditions are detected and that key personal are notified in a timely manner so that on-call team members can react to those conditions. To ensure the health and safety of its lights-out missions, NASA-GSFC's Advanced Automation and Autonomy branch (Code 588) developed the Spacecraft Emergency Response System (SERS). The SERS is a Web-based collaborative environment that enables secure distributed fault and resource management. The SERS incorporates the use of intelligent agents, threaded discussions, workflow, database connectivity, and links to a variety of communications devices (e.g., two-way paging, PDA's, and Internet phones) via commercial gateways. When the SERS detects a problem, it notifies on-call team members, who then can remotely take any necessary actions to resolve the anomalies.The SERS goes well beyond a simple '911' system that sends out an error code to everyone with a pager. Instead, SERS' software agents send detailed data (i.e., notifications) to the most appropriate team members based on the type and severity of the anomaly and the skills of the on-call team members. The SERS also allows the team members to respond to the notifications from their wireless devices. This unique capability ensures rapid response since the team members no longer have to go to a PC or the control center for every anomalous event. Most importantly, the SERS enables safe experimentation with various techniques for increasing levels of automation, leading to robust autonomy. For the MIDEX missions at NASA GSFC, the SERS is used to provide 'human-in-the-loop' automation. During lights-out operations, as greater control is given to the MIDEX automated systems, the SERS can be configured to page remote personnel and keep them informed regarding actions taking place in the control center. Remote off-duty operators can even be given the option of enabling or inhibiting a specific automated response in near real time via their two-way pagers. The SERS facilitates insertion of new technology to increase automation, while maintaining the safety and security of mission resources. This paper will focus on SERS' overall functionality and how SERS has been designed to handle the monitoring and emergency response for missions with varying levels of automation. The paper will also convey some of the key lessons learned from SERS' deployment across of variety of missions, highlighting this incremental approach to achieving 'robust autonomy'.

Breed, Julie↗

NASA NTRS2000

North Atlantic Aerosol Single Scattering Albedos: TARFOX and ACE-2 Results and Their Relation to Radiative Effects Derived from Satellite Optical Depths

Bergstrom and Russell estimated direct solar radiative flux changes caused by atmospheric aerosols over the mid-latitude North Atlantic Ocean under cloud-free and cloudy conditions. They excluded African dust aerosols, primarily by restricting calculations to latitudes 25-60 N. As inputs they used midvisible aerosol optical depth (AOD) maps derived from AVHRR satellite measurements and aerosol intensive properties determined primarily in the 1996 IGAC Troposheric Aerosol Radiative Forcing Observational Experiment (TARFOX). Those aerosol intensive properties, which included optical depth wavelength dependence and spectra of single scattering albedo (SSA) and scattering asymmetry parameter, were also checked against initial properties from the 1997 North Atlantic Aerosol Characterization Experiment (ACE 2). Bergstrom and Russell investigated the sensitivity of their derived flux changes to assumed input parameters, including midvisible AOD, SSA, and scattering asymmetry parameter. Although the sensitivity of net flux change at the tropopause to SSA was moderate over the ocean (e.g., a SSA uncertainty of 0.07 produced a flux-change uncertainty of 21%), the sensitivity over common land surfaces can be much larger. Also, flux changes within and below the aerosol layer, which affect atmospheric stability, heating rates, and cloud formation and persistence, are quite sensitive to aerosol SSA. Therefore, this paper focuses on the question: "What have we learned from TARFOX and ACE 2 regarding aerosol single scattering albedo?" Three techniques were used in TARFOX to determine midvisible SSA. One of these derived SSA as a best-fit parameter in comparing radiative flux changes measured by airborne pyranometer to those computed from aerosol properties. Another technique combined airborne measurements of aerosol scattering and absorption by nephelometer and absorption photometer. A third technique obtained SSA from best-fit complex refractive indices derived by comparing vertical profiles of lidar backscatter, sunphotometer extinction, and relative size distribution. In ACE 2 midvisible SSA was determined both as a best-fit parameter in comparing measured and calculated flux changes at the surface and by combining nephelometer and absorption photometer measurements. The nephelometer/absorption-photometer results were obtained on the ACE 2 ship (10 m asl), at the Sagres, Portugal site at 50 m asl, and also on the Pelican aircraft. This paper presents and compares the TARFOX and ACE 2 SSA results from the above techniques for different situations (e.g., marine vs continental flows, "clean" vs polluted conditions). It also discusses the strengths and limitations of the techniques, including whether they describe the aerosol in its ambient state or as perturbed by sampling processes; whether they describe the aerosol at the surface, as a function of altitude, or integrated over a column; the ease of acquiring representative data sets; results obtained in tests of consistency with radiative flux changes, and the likelihood of various artifacts and errors.

Russell, P. B.↗

NASA NTRSDate not supplied

Earth Independent Medical Operations (EIMO) Datascope: Challenges and Potential Solutions

Data flows and storage/retrieval capacity are severely constrained during missions in space and challenges will become even greater during exploration class missions. There is a need for an artificial intelligence (AI)-based clinical decision support system (CDSS) to monitor and analyze data to provide real-time consultative support for crew medical officer (CMO) decision-making. EIMO is defined as the gradual transition of medical care and decision making from terrestrial to space-based assets, enabling support of astronaut health and performance and reducing overall mission risk. While a hallmark of this paradigm shift from low-earth orbit is that on-board care will increasingly become the responsibility of the astronauts for primary management and decision making, terrestrial assets will continue to be paramount in pre-mission screening and planning, as well as prevention, health maintenance and long-term care contingencies. New capabilities and systems that enable progressively more robust and resilient systems and crews will be necessary to reduce risk and increase probability of deep space exploration mission success. An aspiration for EIMO is to develop AI-enhanced solutions for analysis of crew health & performance data and to facilitate clinical decision support for autonomous medical operations. A “system of systems” approach is envisioned whereby EIMO will deploy AI-supported natural language processing and machine learning (ML) techniques to utilize embedded reference databases and real-time data streams [input vectors] from multiple data sources. Constituent input vectors may include environmental controls, countermeasures data, behavioral data, physiologic wearables, point-of-care laboratory tests, personalized medical records, inventory trade space risk assessments, COTS medical databases, and ground support inputs. An ideal AI capability would possess trained fusion algorithms to cross reference input vectors with medical ‘knowledge’ [cultivated database] to stratify relevant data streams for predictive and actionable capabilities. In addition, EIMO will feature mobility, in that it can be accessed and can push/pull data within and between multiple vehicles/habitats. Large amounts and variable sources of data can be leveraged to diagnose, inform treatment strategies, and potentially predict medical events and performance decrements. Inclusion of advanced training tools using extended reality will enable increasingly autonomous medical care to aid a CMO when ground support is unavailable or time-delayed beyond required action window, e.g., emergent medical situations. EIMO CDSS would require very large datasets to train pre-flight and significant amounts of data are needed to support ML via in-flight CDSS operations. An additional challenge will be to find sufficient data to train a model relevant to astronaut demographics. The rapid, accelerating evolution of this field creates a propitious solution space to leverage multi-modal AI through public-private partnership(s). The status of multi-modal AI systems today would preclude their use for long duration missions as they remain unreliable and are subject to “digital hallucinations” and other errors that could pose operational risk. A federated labs structure is being considered to test and optimize data flow from the multiple input vectors leading to field testing in suitable ground/flight analogs. Critical to the success of an EIMO CDSS will be integration and interoperability and success will be defined by a system that can serve as an in-flight medical consult for the CMO providing critical support during medical contingencies. Benefits to terrestrial medicine may be significant as an outflow of the EIMO medical system, particularly for remote areas and communities lacking significant infrastructure, personnel and resources.

J Lemery↗

NASA NTRS2024

Earth Independent Medical Operations (EIMO) Datascope: Challenges and Potential Solutions

Medical Operations↗

NASA NTRS2016

Hexapod Robot

The project I am working on at NASA-Johnson Space Center in Houston, TX is a hexapod robot. This project was started by various engineers at the Trick Lab. The goal of this project is to have the hexapod track a yellow ball or possibly another object from left to right and up/down. The purpose is to have it track an object like a real creature. The project will consist of using software and hardware. This project started with a hexapod robot which uses a senor bar to track a yellow ball but with a limited field of vision. The sensor bar acts as the robots "head." Two servos will be added to the hexapod to create flexion and extension of the head. The neck and head servos will have to be programmed to be added to the original memory map of the existing servos. I will be using preexisting code. The main programming language that will be used to add to the preexisting code is C++. The trick modeling and simulation software will also be used in the process to improve its tracking and movement. This project will use a trial and error approach, basically seeing what works and what does not. The first step is to initially understand how the hexapod works. To get a general understanding of how the hexapod maneuvers and plan on how to had a neck and head servo which works with the rest of the body. The second step would be configuring the head and neck servos with the leg servos. During this step, limits will be programmed specifically for the each servo. By doing this, the servo is limited to how far it can rotate both clockwise and counterclockwise and this is to prevent hardware damage. The hexapod will have two modes in which it works in. The first mode will be if the sensor bar does not detect an object. If the object it is programmed to look for is not in its view it will automatically scan from left to right 3 times then up and down once. The second mode will be if the sensor bar does detect the object. In this mode the hexapod will track the object from left to right or up and down. The hexapod will eventually be able to track the object moving its head and body in sync with on another and being able to rotate its body at 360 degrees. This is the plans and possible end results for the hexapod robot I will be working on during my summer internship at NASA Johnson Space Center. Since working on the hexapod project I have gained an increase interest in robotics. I enjoy the process of critical thinking. Also will working on this project I was challenged in a way that made more passionate to strive even more to become an engineer. I've learned that asking questions is an important part of the learning process. Also I learn that much more is accomplished when teamwork is applied.

Begody, Ericka↗

NASA NTRS2016

Modeling a Miniaturized Scanning Electron Microscope Focusing Column - Lessons Learned in Electron Optics Simulation

This presentation discusses work done to assess the design of a focusing column in a miniaturized Scanning Electron Microscope (SEM) developed at the NASA Marshall Space Flight Center (MSFC) for use in-situ on the Moon-in particular for mineralogical analysis. The MSFC beam column design uses purely electrostatic fields for focusing, because of the severe constraints on mass and electrical power consumption imposed by the goals of lunar exploration and of spaceflight in general. The resolution of an SEM ultimately depends on the size of the focused spot of the scanning beam probe, for which the stated goal here is a diameter of 10 nanometers. Optical aberrations are the main challenge to this performance goal, because they blur the ideal geometrical optical image of the electron source, effectively widening the ideal spot size of the beam probe. In the present work the optical aberrations of the mini SEM focusing column were assessed using direct tracing of non-paraxial rays, as opposed to mathematical estimates of aberrations based on paraxial ray-traces. The geometrical ray-tracing employed here is completely analogous to ray-tracing as conventionally understood in the realm of photon optics, with the major difference being that in electron optics the lens is simply a smoothly varying electric field in vacuum, formed by precisely machined electrodes. Ray-tracing in this context, therefore, relies upon a model of the electrostatic field inside the focusing column to provide the mathematical description of the "lens" being traced. This work relied fundamentally on the boundary element method (BEM) for this electric field model. In carrying out this research the authors discovered that higher accuracy in the field model was essential if aberrations were to be reliably assessed using direct ray-tracing. This led to some work in testing alternative techniques for modeling the electrostatic field. Ultimately, the necessary accuracy was attained using a BEM/Fourier series hybrid approach. The presentation will give background remarks about the MSFC mini Lunar SEM concept and electron optics modeling, followed by a description of the alternate field modeling techniques that were tried, along with their incorporation into a ray-trace simulation. Next, the validation of this simulation against commercially available software will be discussed using an example lens as a test case. Then, the efficacy of aberration assessment using direct ray-tracing will be demonstrated, using this same validation case. The discussion will include practical error checks of the field solution. Finally, the ray-trace assessment of the MSFC mini Lunar SEM concept will be shown and discussed. The authors believe this presentation will be of general interest to practitioners of modeling and simulation, as well as those with a general optics background. Because electron optics and photon optics share many basic concepts (e.g., lenses, images, aberrations, etc.), the appeal of this presentation need not be restricted to just those interested in charged particle optics.

Modeling Miniaturizing Scanning↗

NASA NTRS2010

Lessons Learned on Implementing Fault Detection, Isolation, and Recovery (FDIR) in a Ground Launch Environment

This paper's main purpose is to detail issues and lessons learned regarding designing, integrating, and implementing Fault Detection Isolation and Recovery (FDIR) for Constellation Exploration Program (CxP) Ground Operations at Kennedy Space Center (KSC). Part of the0 overall implementation of National Aeronautics and Space Administration's (NASA's) CxP, FDIR is being implemented in three main components of the program (Ares, Orion, and Ground Operations/Processing). While not initially part of the design baseline for the CxP Ground Operations, NASA felt that FDIR is important enough to develop, that NASA's Exploration Systems Mission Directorate's (ESMD's) Exploration Technology Development Program (ETDP) initiated a task for it under their Integrated System Health Management (ISHM) research area. This task, referred to as the FDIIR project, is a multi-year multi-center effort. The primary purpose of the FDIR project is to develop a prototype and pathway upon which Fault Detection and Isolation (FDI) may be transitioned into the Ground Operations baseline. Currently, Qualtech Systems Inc (QSI) Commercial Off The Shelf (COTS) software products Testability Engineering and Maintenance System (TEAMS) Designer and TEAMS RDS/RT are being utilized in the implementation of FDI within the FDIR project. The TEAMS Designer COTS software product is being utilized to model the system with Functional Fault Models (FFMs). A limited set of systems in Ground Operations are being modeled by the FDIR project, and the entire Ares Launch Vehicle is being modeled under the Functional Fault Analysis (FFA) project at Marshall Space Flight Center (MSFC). Integration of the Ares FFMs and the Ground Processing FFMs is being done under the FDIR project also utilizing the TEAMS Designer COTS software product. One of the most significant challenges related to integration is to ensure that FFMs developed by different organizations can be integrated easily and without errors. Software Interface Control Documents (ICDs) for the FFMs and their usage will be addressed as the solution to this issue. In particular, the advantages and disadvantages of these ICDs across physically separate development groups will be delineated.

Ferrell, Bob A.↗

NASA NTRS2016

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↗

NASA NTRSDate not supplied

Vacuum Sealable Container (VSC) and Astronaut Lunar Drill (ALD) for Artemis

Introduction: NASA’s Artemis Program is under development to send first woman and next man to the Moon. Artemis will utilize a suite of new technology for Lunar exploration, including new space vehicles, new space suits, and new Astronaut Tools. Honeybee Robotics has been working with NASA JSC to develop a new Vacuum Sealable Container (VSC) and new Astronaut Lunar Drill (ALD) for the upcoming Artemis missions. Vacuum Sealable Container: Sample return continues to be the “Holy Grail” of space exploration, allowing for the analysis of materials using Earth-based laboratories instead of needing to miniaturize and ruggedize instrumentation for space. The Apollo missions to the Moon had several kinds of Sealable Containers which brought back Lunar samples for analysis [1]. These samples are still being analyzed, fifty years later. The VSC requirements are different from that for Apollo containers and as such, new development was required. One major difference between Artemis samples and those from Apollo is the desire to bring back volatiles which may be part of lunar regolith. The VSC is designed to withstand a high-pressure differential caused by sublimating volatiles. Because of the new, stricter sealing requirements, additional features have been added to the VSC. For example, the seal on the container is required to be more robust, thus required more force to actuate, and the seal must be locked in place with a secondary mechanism. Astronaut Lunar Drill: The ALD is designed to be a multi-functional platform for Lunar sample acquisition. The drill builds on lessons learned from the Apollo Lunar Surface Drill (ALSD), as well as Honeybee’s long history of mechanized sample acquisition devices for space [2]. The main functionality of the ALD is Deep Core Regolith Drilling. Additional functionality includes Surface Rock Coring (SRC), and GeoTech Tools (GTT). The ALD is a rotary-percussive drill designed with deep drilling in mind. The ALD is currently designed to have decoupled rotary and percussion subsystems to allow for maximum battery life and reduced fatigue on the crewmember. Honeybee drill technology will automatically engage the percussion when needed to drill at maximum efficiency. The mechanized drill stand helps improve drilling efficiency; the system utilizes advanced drilling algorithms which only require the crewmember to hold a single switch. Additionally, the stand aids in extraction of deep cores, something which was a problem on Apollo. The SRC functionality of the ALD utilizes Honeybee’s Eccentric Tube Core Breakoff technology to collect and retain rock core samples. This technology has also been infused into the Perseverance rover mission. The ALD is removable from the stand to allow crewmembers to collect samples from large boulders. Bringing back rock cores samples instead of full rocks allows for a wider variety of samples to be returned to Earth for study and puts them in a uniform form-factor for effective sealing and analysis. SRC bits will utilize the power of the drill’s percussion system to drill hard Lunar rocks and expedite sample acquisition. The mechanized stand on the ALD allows for additional attachments for taking geotechnical measurements with a Static Cone Penetrometer (SCP) and a Shear Vane (SV). With the stand, the ALD can take SCP measurements with the touch of a button, storing data for return to Earth. SV measurements utilize the ALD’s Rotary motor to spin the vanes in a controlled manner, getting clean data untampered by human error. References: [1] Bar Cohen and Zacny (2009), Drilling in Extreme Environments - Penetration and Sampling on Earth and Other Planets, Wiley. [2] Bar-Cohen and Zacny, Advances in Terrestrial and Extraterrestrial Drilling, CRC Press. [3] Myrick (2003), Core Break-off Mechanism. US Patent No. 6,550,549 Acknowledgements: This work has been supported by NASA via SBIR Phase 3.

Artemis↗

NASA NTRS2022

Automating Surface Attitude Positioning and Pointing Operations for Mars 2020

The Surface Attitude Positioning and Pointing (SAPP) subsystem of the Mars Perseverance rover keeps track of the rover’s position and attitude on the surface of Mars. The SAPP Downlink Engineering Operations team members receive data from the rover on a daily basis. They must interpret the data to make sure the rover is staying safe and to support uplink planning. The SAPP team keeps track of the error growth in the rover’s attitude estimate due to noise in the Rover Inertial Measurement Unit’s (RIMU) gyroscopes used to propagate that attitude estimate whenever the rover is moving. Whenever this error grows to a particular threshold, SAPP is responsible for updating the onboard attitude knowledge using the RIMU’s accelerometers to estimate rover roll and pitch and sun imaging to estimate rover yaw, thereby reducing this attitude estimation error. Accurate attitude estimation is required so that the rover can successfully point its High Gain Antenna (HGA) to receive information from Earth and as a backup to the Mars orbiters used for sending data from the rover to Earth, point instruments on its Remote Sensing Mast (RSM), and support safe movement and placement of instruments by the rover’s ARM relative to the Martian surface. The Mars 2020 Engineering Operations team has been working to increase the operational efficiency of the mission and eventually move to a five-hour timeline for daily operations. In pursuit of this goal, the SAPP Engineering Operations team has automated their downlink process by developing a centralized Jupyter notebook to analyze the data received daily from the rover. The SAPP downlink Jupyter notebook automatically collects the data relevant to the SAPP subsystem and visualizes this information in plots and tables that can be easily read by downlink operators to aid them in assessing the status of the subsystem. Various Application Programming Interfaces (APIs) have been incorporated into the downlink daily notebook to automate the collection and posting of data, such as gathering and posting data products to the cloud. The SAPP team has also developed a SAPP downlink software library that includes functions to aid the notebook in processing data. In addition to assessing the SAPP subsystem on a daily basis, operators need to assess the long-term trending behavior of the subsystem over time. An automated trending process has been developed to collect information from the daily notebooks in order to plot and analyze that data in a centralized place. These daily and trending processes have expedited the SAPP downlink assessment and laid the groundwork to completely automate the SAPP downlink process so that SAPP operators are unnecessary unless something unexpected occurs. This paper will provide an overview of the functions that the SAPP subsystem carries out on a daily basis, and will then dive into the automations that have been developed for daily and trending downlink assessment. An assessment of the downlink efficiency will be provided, along with a summary of lessons learned and work to go. Finally, the authors will discuss how these types of automated spacecraft health assessments could be more broadly used within mission operations.

Zarifian, Anais↗

NASA NTRSDate not supplied

Supervisory Control with Dual Tasking in Post G-Transition Vehicle Landings

BACKGROUND Landing during exploration spaceflight may consist of both planned automated supervisory control and unplanned crew override. Supervisory control, particularly when performed under cognitive load with additional monitoring tasks, is essential for ensuring overall mission success during landing contingencies. Evaluating performance in a relevant Human Landing System (HLS) supervisory landing task after long-duration microgravity exposure can help identify potential risks from human error and sensorimotor alterations. Adaptive changes in the sensorimotor system can manifest during g-transitions as spatial disorientation. Although training and landing aids facilitate successful landings despite disorientation, these adaptive changes may heighten cognitive demand, which must be considered in the landing strategy. It is important to characterize these effects as soon as possible following the G-transition while the sensorimotor system remains in a state of adaptive flux to inform appropriate countermeasures. METHODS A Multi-attribute Lunar Table Battery (MALTB) task was developed for an iOS tablet device to provide flexible crew testing and training capabilities in-flight and on the ground. Elements of the tablet task were derived from the Multi-Attribute Task Battery (MATB, Cegarra et al. 2020). The task requires crew members to study a map of a planned landing site and memorizing the terrain and surface landmarks to inform potential divert maneuvers during landing. The user will oversee a series of approaches through touchdown simulations on the tablet with an external camera view of the Lunar surface. The primary responsibility of the crew member will be to execute a divert if the guidance recommended site is erroneous (e.g., the guidance projected landing target is not within 10m of the planned landing site center), or the projected landing site is no longer suitable due to surface obstacles. Considering vehicle maneuverability and fuel reserves, the divert capabilities will diminish as the task progresses. In cases where a divert is initiated, a new landing target will need to be designated by the user and will be evaluated for the proximity to the original pre-planned site. A secondary operational monitoring task will challenge the user's cognitive reserve by requiring the user to maintain several gauges within acceptable limits and respond to a visual indicator while completing the landing approach. Outcome measures include distance from the planned landing site to the user-initiate divert landing location, ground slope at the new landing site, time to divert, the ability to accomplish the secondary monitoring tasks, and perceived workload. The tablet task is being evaluated in a ground-based study to determine the learning effect of first-time users. The tablet task will be utilized in a flight study to test performance multiple times postflight. Future potential testing in-flight have been identified for capsules with iOS tablet devices. Multi-attribute Lunar Table Battery Task MALTB comprises video footage of thirty distinct landing conditions. The landing scenarios feature various landing sites (n = 3), hazardous object sizes (n = 6), sun azimuth degrees (n = 4), camera modes (i.e., fixed or gimbaled), and navigation bias (i.e., true or false). Each seventy second trial uses a sixty-degree constant glideslope trajectory. The application architecture and layout include user identification setup and data storing, a guided walkthrough of the task and interface components, practice mode for task familiarization, and a modified Bedford workload scale administered following task completion. The time-based dependent measures are saved locally to the iOS Files application and post-processing scripts have been developed to evaluate the remaining measures of performance. RELEVANCE This project will deliver an operational demonstration of crew monitoring capability following spaceflight and identify potential deficits that may require remediation. Comparison of individual vestibular and cognitive changes with crew performance will help better characterize the landing risks associated with sensorimotor alterations. ACKNOWLEDGEMENTS: This project is funded by NASA’s Human Research Program Human Health Countermeasures Element. REFERENCES Cegarra J, Valery B, Avril E, Calmettes C, Navarro J (2020) OpenMATB: A Multi-Attribute Task Battery promoting task customization, software extensibility and experiment replicability. Behav Res Methods 52:1980-1990 doi: 10.3758/s13428-020-01364-w

Matthew McDonnell↗

NASA NTRS1997

Walking to Olympus: An EVA Chronology

Spacewalkers enjoy a view of Earth once reserved for Apollo, Zeus, and other denizens of Mt. Olympus. During humanity's first extravehicular activity (EVA), Alexei Leonov floated above Gibraltar, the rock ancient seafarers saw as the gateway to the great unknown Atlantic. The symbolism was clear, Leonov stepped past a new Gibraltar when he stepped into space. More than 32 years and 154 EVAs later, Jerry Linenger conducted an EVA with Vladimir Tsibliyev as part of International Space Station Phase 1. They floated together above Gibraltar. Today the symbolism has new meaning: humanity is starting to think of stepping out of Earth orbit, space travel's new Gibraltar, and perhaps obtaining a new olympian view, a close-up look at Olympus Mons on Mars. Walking to Olympus: An EVA Chronology chronicles the 154 EVAs conducted from March 1965 to April 1997. It is intended to make clear the crucial role played by EVA in the history of spaceflight, as well as to chronicle the large body of EVA "lessons learned." Russia and the U.S. define EVA differently. Russian cosmonauts are said to perform EVA any time they are in vacuum in a space suit. A U.S. astronaut must have at least his head outside his spacecraft before he is said to perform an EVA. The difference is based in differing spacecraft design philoso- phies. Russian and Soviet spacecraft have always had a specialized airlock through which the EVA cosmonaut egressed, leaving the main habitable volume of the spacecraft pressurized. The U.S. Gemini and Apollo vehicles, on the other hand, depressurized their entire habitable volume for egress. In this document, we apply the Russian definition to Russian EVAS, and the U.S. definition to U.S. EVAS. Thus, for example, Gemini 4 Command Pilot James McDivitt does not share the honor of being first American spacewalker with Ed White, even though he was suited and in vacuum when White stepped out into space. Non-EVA spaceflights are listed in the chronology to provide context and to display the large num- ber of flights in which EVA played a role. This approach also makes apparent significant EVA gaps, for example, the U.S. gap between 1985 and 1991 following the Challenger accident. This NASA History Monograph is an edited extract from an extensive EVA Chronology and Reference Book being produced by the EVA Project Office, NASA Johnson Space Center, Houston, Texas. The larger work will be published as part of the NASA Formal Series in 1998. The authors gratefully acknowledge the assistance rendered by Max Ary, Ashot Bakunts, Gert-Jan Bartelds, Frank Cepollina, Andrew Chaikin, Phillip Clark, Richard Fullerton, Steven Glenn, Linda Godwin, Jennifer Green, Greg Harris, Clifford Hess, Jeffrey Hoffman, David Homan, Steven Hopkins, Nicholas Johnson, Eric Jones, Neville Kidger, Joseph Kosmo, Alexei Lebedev, Mark Lee, James LeBlanc, Dmitri Leshchenskii, Jerry Linenger, Igor Lissov, James McBarron, Clay McCullough, Joseph McMann, Story Musgrave, Dennis Newkirk, James Oberg, Joel Powell, Lee Saegesser, Andy Salmon, Glen Swanson, Joseph Tatarewicz, Kathy Thornton, Chris Vandenberg, Charles Vick, Bert Vis, David Woods, Mike Wright, John Young, and Keith Zimmerman. Special thanks to Laurie Buchanan, John Charles, Janet Kovacevich, Joseph Loftus, Sue McDonald, Martha Munies, Colleen Rapp, and Jerry Ross. Any errors remain the responsibility of the authors.

Portree, David S. F.↗

NASA NTRS2012

Development of Human System Integration at NASA

Human Systems Integration seeks to design systems around the capabilities and limitations of the humans which use and interact with the system, ensuring greater efficiency of use, reduced error rates, and less rework in the design, manufacturing and operational deployment of hardware and software. One of the primary goals of HSI is to get the human factors practitioner involved early in the design process. In doing so, the aim is to reduce future budget costs and resources in redesign and training. By the preliminary design phase of a project nearly 80% of the total cost of the project is locked in. Potential design changes recommended by evaluations past this point will have little effect due to lack of funding or a huge cost in terms of resources to make changes. Three key concepts define an effective HSI program. First, systems are comprised of hardware, software, and the human, all of which operate within an environment. Too often, engineers and developers fail to consider the human capacity or requirements as part of the system. This leads to poor task allocation within the system. To promote ideal task allocation, it is critical that the human element be considered early in system development. Poor design, or designs that do not adequately consider the human component, could negatively affect physical or mental performance, as well as, social behavior. Second, successful HSI depends upon integration and collaboration of all the domains that represent acquisition efforts. Too often, these domains exist as independent disciplines due to the location of expertise within the service structure. Proper implementation of HSI through participation would help to integrate these domains and disciplines to leverage and apply their interdependencies to attain an optimal design. Via this process domain interests can be integrated to perform effective HSI through trade-offs and collaboration. This provides a common basis upon which to make knowledgeable decisions. Finally, HSI must be considered early in the requirements development phase of system design and acquisition. This will provide the best opportunity to maximize return on investment (ROI) and system performance. HSI requirements must be developed in conjunction with capability ]based requirements generation through functional. HSI requirements will drive HSI metrics and embed HSI issues within the system design. After a system is designed, implementation of HSI oversights can be very expensive. An HSI program should be included as an integral part of a total system approach to vehicle and habitat development. This would include, but not limited to, workstation design, D&C development, volumetric analysis, training, operations, and human -robotic interaction. HSI is a necessary process for Human Space Flight programs to meet the Agency Human ]System standards and thus mitigate human risks to acceptable levels. NASA has been involved in HSI planning, procedures development, process, and implementation for many years, and has been building several internal and publicly accessible products to facilitate HSI fs inclusion in the NASA Systems Engineering Lifecycle. Some of these products include: NASA STD 3001 Volumes 1 and 2, Human Integration Design Handbook, NASA HSI Implementation Plan, NASA HSI Implementation Plan Templates, NASA HSI Implementation Handbook, and a 2 ]hour short course on HSI delivered as part of the NASA Space and Life Sciences Directorate Academy. These products have been created leveraging industry best practices and lessons learned from other Federal Government agencies.

Whitmore, Mihriban↗

NASA NTRS2016

Investigating the Simulink Auto-Coding Process

Model based program design is the most clear and direct way to develop algorithms and programs for interfacing with hardware. While coding "by hand" results in a more tailored product, the ever-growing size and complexity of modern-day applications can cause the project work load to quickly become unreasonable for one programmer. This has generally been addressed by splitting the product into separate modules to allow multiple developers to work in parallel on the same project, however this introduces new potentials for errors in the process. The fluidity, reliability and robustness of the code relies on the abilities of the programmers to communicate their methods to one another; furthermore, multiple programmers invites multiple potentially differing coding styles into the same product, which can cause a loss of readability or even module incompatibility. Fortunately, Mathworks has implemented an auto-coding feature that allows programmers to design their algorithms through the use of models and diagrams in the graphical programming environment Simulink, allowing the designer to visually determine what the hardware is to do. From here, the auto-coding feature handles converting the project into another programming language. This type of approach allows the designer to clearly see how the software will be directing the hardware without the need to try and interpret large amounts of code. In addition, it speeds up the programming process, minimizing the amount of man-hours spent on a single project, thus reducing the chance of human error as well as project turnover time. One such project that has benefited from the auto-coding procedure is Ramses, a portion of the GNC flight software on-board Orion that has been implemented primarily in Simulink. Currently, however, auto-coding Ramses into C++ requires 5 hours of code generation time. This causes issues if the tool ever needs to be debugged, as this code generation will need to occur with each edit to any part of the program; additionally, this is lost time that could be spent testing and analyzing the code. This is one of the more prominent issues with the auto-coding process, and while much information is available with regard to optimizing Simulink designs to produce efficient and reliable C++ code, not much research has been made public on how to reduce the code generation time. It is of interest to develop some insight as to what causes code generation times to be so significant, and determine if there are architecture guidelines or a desirable auto-coding configuration set to assist in streamlining this step of the design process for particular applications. To address the issue at hand, the Simulink coder was studied at a foundational level. For each different component type made available by the software, the features, auto-code generation time, and the format of the generated code were analyzed and documented. Tools were developed and documented to expedite these studies, particularly in the area of automating sequential builds to ensure accurate data was obtained. Next, the Ramses model was examined in an attempt to determine the composition and the types of technologies used in the model. This enabled the development of a model that uses similar technologies, but takes a fraction of the time to auto-code to reduce the turnaround time for experimentation. Lastly, the model was used to run a wide array of experiments and collect data to obtain knowledge about where to search for bottlenecks in the Ramses model. The resulting contributions of the overall effort consist of an experimental model for further investigation into the subject, as well as several automation tools to assist in analyzing the model, and a reference document offering insight to the auto-coding process, including documentation of the tools used in the model analysis, data illustrating some potential problem areas in the auto-coding process, and recommendations on areas or practices in the current Ramses model that should be further investigated. Several skills were required to be built up over the course of the internship project. First and foremost, my Simulink skills have improved drastically, as much of my experience had been modeling electronic circuits as opposed to software models. Furthermore, I am now comfortable working with the Simulink Auto-coder, a tool I had never used until this summer; this tool also tested my critical thinking and C++ knowledge as I had to interpret the C++ code it was generating and attempt to understand how the Simulink model affected the generated code. I had come into the internship with a solid understanding of Matlab code, but had done very little in using it to automate tasks, particularly Simulink tasks; along the same lines, I had rarely used shell script to automate and interface with programs, which I gained a fair amount of experience with this summer, including how to use regular expression. Lastly, soft-skills are an area everyone can continuously improve on; having never worked with NASA engineers, which to me seem to be a completely different breed than what I am used to (commercial electronic engineers), I learned to utilize the wealth of knowledge present at JSC. I wish I had come into the internship knowing exactly how helpful everyone in my branch would be, as I would have picked up on this sooner. I hope that having gained such a strong foundation in Simulink over this summer will open the opportunity to return to work on this project, or potentially other opportunities within the division. The idea of leaving a project I devoted ten weeks to is a hard one to cope with, so having the chance to pick up where I left off sounds appealing; alternatively, I am interested to see if there are any opening in the future that would allow me to work on a project that is more in-line with my research in estimation algorithms. Regardless, this summer has been a milestone in my professional career, and I hope this has started a long-term relationship between JSC and myself. I really enjoy the thought of building on my experience here over future summers while I work to complete my PhD at Missouri University of Science and Technology.

Gualdoni, Matthew J.↗