Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “earth system interface processes”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

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

At least 343 records · Page 19
All sourcesNASA NTRSDOE OSTI
NASA NTRS2022

Docking the Mars 2020 Perseverance Robotic Arm

The Mars 2020 Perseverance Rover includes an innovative Sample Caching Subsystem (SCS). Two key features of SCS are the ability to collect and process rock and regolith samples for possible future return to Earth and the ability to switch between different types of drill bits for coring rocks, abrading rocks, and collecting regolith. These capabilities are enabled by a Corer mounted on the end of a Robotic Arm and a Bit Carousel mounted on the front of the rover body. Beneath the Bit Carousel, a smaller Sample Handling Arm can insert and remove sample tubes from sampling bits in the carousel. For the Corer to interface with the Bit Carousel so that it can exchange drill bits and hand off rock samples, the Robotic Arm must maneuver the Corer to dock with the Bit Carousel. Docking serves two primary purposes: it precisely aligns the Corer with the hardware inside the Bit Carousel, and it applies enough preload between the Corer and the Bit Carousel to make them stay aligned through the process of bit exchange.The docking assembly consists of four concave alignment cones mounted on a large rotating ring, through the center of which the drill can exchange bits and samples with the Bit Carousel. The coring drill includes four alignment posts which mate with the four cones on the dock. Docking uses an algorithm we call “Force-Corrected Docking”, which means it iteratively reads the force/moments reported by the FTS, performs a small motion to reduce sideload and moments while increasing preload, and repeats until reaching a deadband around the target preload. Because docking is a critical function for SCS, the dock hardware and algorithm have been tested thousands of times over 7 years in various stages of development. The culmination of this work is a reliable docking system which has been demonstrated and used in flight.

Warner, Antonia↗
NASA NTRS2006

The Glory Program: Global Science from a Unique Spacecraft Integration

The Glory program is an Earth and Solar science mission designed to broaden science community knowledge of the environment. The causes and effects of global warming have become a concern in recent years and Glory aims to contribute to the knowledge base of the science community. Glory is designed for two functions: one is solar viewing to monitor the total solar irradiance and the other is observing the Earth s atmosphere for aerosol composition. The former is done with an active cavity radiometer, while the latter is accomplished with an aerosol polarimeter sensor to discern atmospheric particles. The Glory program is managed by NASA Goddard Space Flight Center (GSFC) with Orbital Sciences in Dulles, VA as the prime contractor for the spacecraft bus, mission operations, and ground system. This paper will describe some of the more unique features of the Glory program including the integration and testing of the satellite and instruments as well as the science data processing. The spacecraft integration and test approach requires extensive analysis and additional planning to ensure existing components are successfully functioning with the new Glory components. The science mission data analysis requires development of mission unique processing systems and algorithms. Science data analysis and distribution will utilize our national assets at the Goddard Institute for Space Studies (GISS) and the University of Colorado's Laboratory for Atmospheric and Space Physics (LASP). The Satellite was originally designed and built for the Vegetation Canopy Lidar (VCL) mission, which was terminated in the middle of integration and testing due to payload development issues. The bus was then placed in secure storage in 2001 and removed from an environmentally controlled container in late 2003 to be refurbished to meet the Glory program requirements. Functional testing of all the components was done as a system at the start of the program, very different from a traditional program. The plan for Glory is to minimize any changes to the spacecraft in order to meet the Glory requirements. This means that the instrument designs must adhere to the existing interfaces and capabilities as much as possible. Given Glory's unique history and the potential science return, the program is one of significant value to both the science community and the world. The findings Glory promises will improve our understanding of the drivers for global climate change for a minimal investment. The program hopes to show that reuse of existing government assets can result in a lower cost, and fully successful mission.

Bajpayee Jaya↗
NASA NTRS2008

Proven and Robust Ground Support Systems - GSFC Success and Lessons Learned

Over the past fifteen years, Goddard Space Flight Center has developed several successful science missions in-house: the Wilkinson Microwave Anisotropy Probe (WMAP), the Imager for Magnetopause-to-Aurora Global Exploration (IMAGE), the Earth Observing 1 (EO-1) [1], and the Space Technology 5 (ST-5)[2] missions, several Small Explorers, and several balloon missions. Currently in development are the Solar Dynamics Observatory (SDO) [3] and the Lunar Reconnaissance Orbiter (LRO)[4]. What is not well known is that these missions have been supported during spacecraft and/or instrument integration and test, flight software development, and mission operations by two in house satellite Telemetry and Command (T & C) Systems, the Integrated Test and Operations System (ITOS) and the Advanced Spacecraft Integration and System Test (ASIST). The advantages of an in-house satellite Telemetry and Command system are primarily in the flexibility of management and maintenance - the developers are considered a part of the mission team, get involved early in the development process of the spacecraft and mission operations-control center, and provide on-site, on-call support that goes beyond Help Desk and simple software fixes. On the other hand, care must be taken to ensure that the system remains generic enough for cost effective re-use from one mission to the next. The software is designed such that many features are user-configurable. Where user-configurable options were impractical, features were designed so as to be easy for the development team to modify. Adding support for a new ground message header, for example, is a one-day effort because of the software framework on which that code rests. This paper will discuss the many features of the Goddard satellite Telemetry and Command systems that have contributed to the success of the missions listed above. These features include flexible user interfaces, distributed parallel commanding and telemetry decommutation, a procedure language, the interfaces and tools needed for a high degree of automation, and instantly accessible archives of spacecraft telemetry. It will discuss some of the problems overcome during development, including secure commanding over networks or the Internet, constellation support for the three satellites that comprise the ST-5 mission, and geographically distributed telemetry end users.

Pfarr, Barbara↗
NASA NTRS2016

SLS Flight Software Testing: Using a Modified Agile Software Testing Approach

NASA's Space Launch System (SLS) is an advanced launch vehicle for a new era of exploration beyond earth's orbit (BEO). The world's most powerful rocket, SLS, will launch crews of up to four astronauts in the agency's Orion spacecraft on missions to explore multiple deep-space destinations. Boeing is developing the SLS core stage, including the avionics that will control vehicle during flight. The core stage will be built at NASA's Michoud Assembly Facility (MAF) in New Orleans, LA using state-of-the-art manufacturing equipment. At the same time, the rocket's avionics computer software is being developed here at Marshall Space Flight Center in Huntsville, AL. At Marshall, the Flight and Ground Software division provides comprehensive engineering expertise for development of flight and ground software. Within that division, the Software Systems Engineering Branch's test and verification (T&V) team uses an agile test approach in testing and verification of software. The agile software test method opens the door for regular short sprint release cycles. The idea or basic premise behind the concept of agile software development and testing is that it is iterative and developed incrementally. Agile testing has an iterative development methodology where requirements and solutions evolve through collaboration between cross-functional teams. With testing and development done incrementally, this allows for increased features and enhanced value for releases. This value can be seen throughout the T&V team processes that are documented in various work instructions within the branch. The T&V team produces procedural test results at a higher rate, resolves issues found in software with designers at an earlier stage versus at a later release, and team members gain increased knowledge of the system architecture by interfacing with designers. SLS Flight Software teams want to continue uncovering better ways of developing software in an efficient and project beneficial manner. Through agile testing, there has been increased value through individuals and interactions over processes and tools, improved customer collaboration, and improved responsiveness to changes through controlled planning. The presentation will describe agile testing methodology as taken with the SLS FSW Test and Verification team at Marshall Space Flight Center.

Bolton, Albanie T.↗
NASA NTRSDate not supplied

CLINICAL DECISION SUPPORT: PATH TO FUNCTIONAL REQUIREMENTS

Long-duration, deep-space exploration missions present significant challenges to crew health and performance. These challenges include the individual and combined effects of microgravity, radiation exposure, isolation, limited resources (mass, volume, power, data and crew time), limited options for evacuation and those associated with delayed or constrained communications, all of which demand greater crew autonomy. Specifically, as the communication delays intensify the further we explore space, the unqualified need for Earth-independent medical operations focused on autonomous diagnosis, treatment and prevention will be key to mission continuation and success. To augment the requisite knowledge, skills and abilities (KSAs) of a time-constrained crew operating under stressful conditions, combatting fatigue, and facing a potential medical crisis, a robust clinical decision support system (CDSS) is a probable solution that would facilitate, guide and inform Earth-independent medical operations, while assisting crewmembers through various clinical presentations. The Exploration Medical Capability (ExMC) Element of the Human Research Program (HRP) is expanding the boundaries of space medical systems to advance the care of astronauts on future exploration missions beyond low Earth orbit. ExMC is actively identifying and testing next-generation medical care and crew health maintenance technologies. The Clinical Decision Support (CDS) project addresses gap Medical-701 within the Inflight Medical Conditions risk: “Enhance medical capabilities within an exploration medical system.” Though mass, volume, and power will face increasing constraints, the projected computational capabilities of spacecraft systems will increase exponentially as information technology continues to advance this decade and beyond. Hence, data, software and computational resources will play an essential and synergistic role in maintaining crew health, wellness and performance in deep space missions. The focus of the CDS project is to develop recommended requirements for an in-vehicle CDSS that acts as a ‘virtual assistant’ for delivering optimal health, performance and medical care during exploration missions. The CDSS is envisioned as an integrated, software-based tool deployed on a laptop computer or handheld device. The CDSS will assist the crew and ground support when interacting with knowledge/databases (e.g. records, pharmacy, schedule), instrumentation (e.g. imaging, physiological monitoring devices), and habitat (e.g. wellness system, task performance system) and vehicle systems (e.g. environmental system, communication system). In addition, the human interface will employ a context-based approach that accounts for the crew’s situation. Thus, extraneous and clinically/operationally non-relevant information are reduced to avoid an increase in cognitive load. The framework of an ideal spaceflight CDSS is to include core and advanced analytical features that incorporate work from collaborators yet maintain a flexible platform for integrating new technology in the future. In fiscal year 2021 (FY21), the CDS project identified requirements through two primary mechanisms: (i) the development of software implementation prototypes and (ii) the application of systems engineering processes. The CDS project developed and tested a series of increasingly complex system prototypes that were based on use cases derived from the CDSS concept of operations (ConOps). These software implementations yielded insights on CDSS functionality as well as lessons learned that provided the initial requirements for CDSS capability. By applying a systems engineering (SE) approach, medical scenarios provided in the ConOps and the use cases for software implementation underwent functional decomposition to identify CDSS functionality. Also, systems-based modeling language (SysML) tools such as activity diagrams were developed from the same ConOps and use cases to identify CDSS functionality. The lessons learned from software implementation defined both specific requirements and broad areas of requirements. Within these defined broad requirement areas, further analysis of the SE products identified specific capability that resulted in the final functional requirements. In summary, the software prototypes, functional decomposition of the ConOps and use cases, and SysML diagrams provided the basis for the CDSS requirements developed in FY21. In the upcoming year, these requirements will be refined for their final ExMC baseline review in latter FY22.

clinical decision support↗
NASA NTRSDate not supplied

Clinical Decision Support: Path to Functional Requirements

Long-duration, deep-space exploration missions present significant challenges to crew health and performance. These challenges include the individual and combined effects of microgravity, radiation exposure, isolation, limited resources (mass, volume, power, data and crew time), limited options for evacuation and those associated with delayed or constrained communications, all of which demand greater crew autonomy. Specifically, as the communication delays intensify the further we explore space, the unqualified need for Earth-independent medical operations focused on autonomous diagnosis, treatment and prevention will be key to mission continuation and success. To augment the requisite knowledge, skills and abilities (KSAs) of a time-constrained crew operating under stressful conditions, combatting fatigue, and facing a potential medical crisis, a robust clinical decision support system (CDSS) is a probable solution that would facilitate, guide and inform Earth-independent medical operations, while assisting crewmembers through various clinical presentations. The Exploration Medical Capability (ExMC) Element of the Human Research Program (HRP) is expanding the boundaries of space medical systems to advance the care of astronauts on future exploration missions beyond low Earth orbit. ExMC is actively identifying and testing next-generation medical care and crew health maintenance technologies. The Clinical Decision Support (CDS) project addresses gap Medical-701 within the Inflight Medical Conditions risk: “Enhance medical capabilities within an exploration medical system.” Though mass, volume, and power will face increasing constraints, the projected computational capabilities of spacecraft systems will increase exponentially as information technology continues to advance this decade and beyond. Hence, data, software and computational resources will play an essential and synergistic role in maintaining crew health, wellness and performance in deep space missions. The focus of the CDS project is to develop recommended requirements for an in-vehicle CDSS that acts as a ‘virtual assistant’ for delivering optimal health, performance and medical care during exploration missions. The CDSS is envisioned as an integrated, software-based tool deployed on a laptop computer or handheld device. The CDSS will assist the crew and ground support when interacting with knowledge/databases (e.g. records, pharmacy, schedule), instrumentation (e.g. imaging, physiological monitoring devices), and habitat (e.g. wellness system, task performance system) and vehicle systems (e.g. environmental system, communication system). In addition, the human interface will employ a context-based approach that accounts for the crew’s situation. Thus, extraneous and clinically/operationally non-relevant information are reduced to avoid an increase in cognitive load. The framework of an ideal spaceflight CDSS is to include core and advanced analytical features that incorporate work from collaborators yet maintain a flexible platform for integrating new technology in the future. In fiscal year 2021 (FY21), the CDS project identified requirements through two primary mechanisms: (i) the development of software implementation prototypes and (ii) the application of systems engineering processes. The CDS project developed and tested a series of increasingly complex system prototypes that were based on use cases derived from the CDSS concept of operations (ConOps). These software implementations yielded insights on CDSS functionality as well as lessons learned that provided the initial requirements for CDSS capability. By applying a systems engineering (SE) approach, medical scenarios provided in the ConOps and the use cases for software implementation underwent functional decomposition to identify CDSS functionality. Also, systems-based modeling language (SysML) tools such as activity diagrams were developed from the same ConOps and use cases to identify CDSS functionality. The lessons learned from software implementation defined both specific requirements and broad areas of requirements. Within these defined broad requirement areas, further analysis of the SE products identified specific capability that resulted in the final functional requirements. In summary, the software prototypes, functional decomposition of the ConOps and use cases, and SysML diagrams provided the basis for the CDSS requirements developed in FY21. In the upcoming year, these requirements will be refined for their final ExMC baseline review in latter FY22.

Clinical decision support↗
NASA NTRS2015

Integrated Space Asset Management Database and Modeling

Effective Space Asset Management is one key to addressing the ever-growing issue of space congestion. It is imperative that agencies around the world have access to data regarding the numerous active assets and pieces of space junk currently tracked in orbit around the Earth. At the center of this issues is the effective management of data of many types related to orbiting objects. As the population of tracked objects grows, so too should the data management structure used to catalog technical specifications, orbital information, and metadata related to those populations. Marshall Space Flight Center's Space Asset Management Database (SAM-D) was implemented in order to effectively catalog a broad set of data related to known objects in space by ingesting information from a variety of database and processing that data into useful technical information. Using the universal NORAD number as a unique identifier, the SAM-D processes two-line element data into orbital characteristics and cross-references this technical data with metadata related to functional status, country of ownership, and application category. The SAM-D began as an Excel spreadsheet and was later upgraded to an Access database. While SAM-D performs its task very well, it is limited by its current platform and is not available outside of the local user base. Further, while modeling and simulation can be powerful tools to exploit the information contained in SAM-D, the current system does not allow proper integration options for combining the data with both legacy and new M&S tools. This paper provides a summary of SAM-D development efforts to date and outlines a proposed data management infrastructure that extends SAM-D to support the larger data sets to be generated. A service-oriented architecture model using an information sharing platform named SIMON will allow it to easily expand to incorporate new capabilities, including advanced analytics, M&S tools, fusion techniques and user interface for visualizations. In addition, tight control of information sharing policy will increase confidence in the system, which would encourage industry partners to provide commercial data. Combined with the integration of new and legacy M&S tools, a SIMON-based architecture will provide a robust environment that can be extended and expanded indefinitely.

MacLeod, Todd↗
DOE OSTI2024

Thermally generated magnonic spin currents in a polycrystalline gadolinium iron garnet thin film with perpendicular magnetic anisotropy

Rare-earth iron garnets (REIGs) are the benchmark systems for magnonics, including the longitudinal spin Seebeck effect (LSSE). While most research has focused on single-crystalline REIGs on complimentary garnet substrates, moving to more, cost-effective complementary metal-oxide semiconductor (CMOS)-compatible substrates is important to integrate REIG thin films with existing technology. In this regard, we grow a 130 nm-thick polycrystalline gadolinium iron garnet (GdIG) film on the Si/SiO2 substrate and investigate the temperature-dependent LSSE. Interestingly, the polycrystalline GdIG film exhibits perpendicular magnetic anisotropy (PMA) at room temperature which is induced by tensile in-plane (IP)-strain originating from the thermal-expansion mismatch between the GdIG film and the substrate during rapid thermal annealing. Further, a spin-reorientation transition from the out-of-plane IP direction below TS = 180 K is observed. Additionally, the film reveals a magnetic compensation temperature, TComp, of ≈240 K. The LSSE voltage not only demonstrates a sign-inversion around TComp, but also shows noticeable changes around TS. As compared to a single-crystalline GdIG film, the lower LSSE voltage for the polycrystalline GdIG is attributed to the higher effective magnetic anisotropy and enhanced magnon scattering at the grain boundaries. Our study not only paves the way for the cost-effective growth of CMOS-compatible REIG-based systems with PMA for magnonic memory and information processing applications, but also highlights the fact that the spincaloritronic and spin-insulatronic properties of the polycrystalline REIGs follow those of their single-crystalline counterparts with reduced spin-to-charge conversion efficiency through LSSE which can be tuned further by controlling the average gran size and interface engineering.

Physics↗
NASA NTRS2021

Microscale Processes Determining Macroscale Evolution of Magnetic Flux Tubes along Earth’s Magnetopause

An important process affecting solar wind-Earth’s magnetosphere coupling is non-steady dayside magnetic reconnection, observationally evidenced by a flux-transfer-event (FTE) that shows a bipolar variation of the magnetic field component normal to the magnetopause. FTEs often consist of two interlinked flux tubes, but, local kinetic processes between the flux tubes are not understood in the context of the FTE structuring, evolution, and impact. An FTE observed by MMS on 18 December 2017 consisted of two flux tubes of different topology. One includes field lines with ends connected to the northern and southern hemispheres while the other includes field lines with both ends connected to the magnetosheath. Reconnection occurring at the flux-tube interface indicates how interacting flux tubes evolve into a flux rope with helical magnetic topology that is either closed or open. This study demonstrates a new aspect of how micro-to meso-scale dynamics occurring within FTEs determines their macroscale characteristics and evolution.

Solar-terrestrial interactions↗
NASA NTRSDate not supplied

SAGE III/ISS Rapid Data Analysis Through Dashboarding with Jupyter Notebooks

Spaceborne remote sensing observations of Earth’s atmosphere produce significant quantities of data over the life of each mission. In the case of the Stratospheric Aerosol and Gas Experiment III on the International Space Station (SAGE III/ISS) nearly four years of vertical profiles of atmospheric ozone, water vapor, and nitrogen dioxide concentrations as well as aerosol extinction coefficients have been released. The dichotomy of the desire for both long-term trends in the atmospheric state alongside the assessment of short-term impacts of major disruptive events such as volcanic eruptions and pyrocumulus injections requires agile tools to handle these cases in near real-time as new data are produced. The analysis landscape is further complicated by the desire to compare results between the numerous contemporary observations available for a given dataset. The SAGE III/ISS team has developed a suite of tools leveraging modern web-based frameworks allowing members to interact with a dashboard-style interface to load the data record, assess new profiles as they are generated and in ensemble, compare between species, and additionally add in measurements observed by other platforms as necessary. Leveraging a commonly packaged data format of NetCDF alongside the Python Jupyter Notebook framework, the data can be served to interested parties from an analysis server while still runnable on personal systems if required. This presentation illustrates the ecosystem developed by the SAGE III/ISS team, the applicability to measurements made by any limb-observing platform, and the benefit to transforming routine analyses into readily accessible dynamic plots. Frameworks currently exist at larger scales with projects such as GIOVANNI, and this illustration seeks to show that similar frameworks are accessible and possible within the local research environment while simultaneously unloading human processing cycles for more specialized analysis tasks.

Dashboarding↗
DOE OSTI2025

Continuous snow depth and temperature measurements from dense network of above-ground distributed temperature profiling systems from 2021-09-23 to 2024-08-23, Seward Peninsula, Alaska

The dataset contains temperature measurements from distributed temperature profiling (DTP) systems (Dafflon et al., 2022; Wielandt et al., 2022; Wang et al., 2024a; Fiolleau et al., 2024) deployed vertically above the ground surface at a large number of locations from 2021 to 2024. The research is designed to improve understanding of the local heterogeneity in snow depth and snow thermal insulation dynamics, as well as their interactions in a discontinuous permafrost region (Wang et al., 2025). The DTP systems were deployed at 96 locations in a watershed along the Nome-Teller road at mile marker 27 (T27) and at 54 locations on a hillslope along the Kougarok road at mile marker 64 (K64) in the Seward Peninsula, Alaska. The probe location information is stored in Probe_locations_T27.csv and Probe_locations_K64.csv. Temperature measurements were recorded at 15-minute intervals using high-precision digital sensors (accuracy: ±0.1°C, resolution: 0.0078°C). The temperature probes, either 1.4 m or 1.6 m long, contain sensors spaced every 5 cm or 10 cm along their length. The temperature data are stored in compressed files following the format: DTP_snow_air_temperature_(site)_(start)_(end).zip, where site is either T27 or K64, and start and end represent the time series period. Within each ZIP file, individual CSV files are named by probe ID and contain temperature records at different heights above the ground surface.This dataset also includes derived snow depth time series over three snow seasons, estimated from temperature measurements. Snow depth was estimated by identifying the consecutive sensor pair that exhibited the largest drop in high-frequency temperature fluctuations (detailed in the methods). These data are stored in: Snow_depths_flags_(site)_(start)_(end).csv, which includes snow depth time series and corresponding quality flags (defined in the methods) from different probes. Additionally, the dataset includes derived metrics and supporting measurements at selected locations over two snow seasons, contributing to the manuscript of Wang et al., 2025. These locations were chosen based on the availability of high-quality snow depth time series during both seasons. The additional data include: (1) Air temperature proxies measured from the top sensors on the pole when they were not buried by snow, stored in Air_temperature_proxies_(site)_(start)_(end).csv (2) Ground interface temperature, recorded at 3 cm above the ground, stored in Ground_interface_temperature_(site)_(start)_(end).csv (3) Site characteristics, including vegetation height, elevation, and the topographic position index (TPI) within a 50 m radius, stored in Selected_probe_locations_gps_vegheight_tpi_elevation_(site).csv. These metrics were derived from 1 m resolution summer LiDAR-based digital elevation models and digital surface models from Singhania et al., 2023, DOI:10.5440/1832016. Metadata files include data descriptions (_dd.csv) for tabular data. All included files are listed and described in xxxx_flmd.csv.This dataset is an updated version of a previous archive (Wang et al., 2024b, DOI: 10.15485/2475020), incorporating multiple seasons and improved snow depth estimation. Please note that due to large amount of information present in this dataset, many specificities associated with the acquisition of snow temperature, air temperature proxy and estimation of snow depth, and the future archiving of additional datasets on the soil temperature, thaw depth and soil characteristics at these locations, the author would welcome being contacted by people planning to use this dataset.The Next-Generation Ecosystem Experiments: Arctic (NGEE Arctic), was a research effort to reduce uncertainty in Earth System Models by developing a predictive understanding of carbon-rich Arctic ecosystems and feedbacks to climate. NGEE Arctic was supported by the Department of Energy's Office of Biological and Environmental Research.The NGEE Arctic project had two field research sites: 1) located within the Arctic polygonal tundra coastal region on the Barrow Environmental Observatory (BEO) and the North Slope near Utqiagvik (Barrow), Alaska and 2) multiple areas on the discontinuous permafrost region of the Seward Peninsula north of Nome, Alaska.Through observations, experiments, and synthesis with existing datasets, NGEE Arctic provided an enhanced knowledge base for multi-scale modeling and contributed to improved process representation at global pan-Arctic scales within the Department of Energy's Earth system Model (the Energy Exascale Earth System Model, or E3SM), and specifically within the E3SM Land Model component (ELM).

54 ENVIRONMENTAL SCIENCES↗
NASA NTRS1997

STRIPE: Remote Driving Using Limited Image Data

Driving a vehicle, either directly or remotely, is an inherently visual task. When heavy fog limits visibility, we reduce our car's speed to a slow crawl, even along very familiar roads. In teleoperation systems, an operator's view is limited to images provided by one or more cameras mounted on the remote vehicle. Traditional methods of vehicle teleoperation require that a real time stream of images is transmitted from the vehicle camera to the operator control station, and the operator steers the vehicle accordingly. For this type of teleoperation, the transmission link between the vehicle and operator workstation must be very high bandwidth (because of the high volume of images required) and very low latency (because delayed images can cause operators to steer incorrectly). In many situations, such a high-bandwidth, low-latency communication link is unavailable or even technically impossible to provide. Supervised TeleRobotics using Incremental Polyhedral Earth geometry, or STRIPE, is a teleoperation system for a robot vehicle that allows a human operator to accurately control the remote vehicle across very low bandwidth communication links, and communication links with large delays. In STRIPE, a single image from a camera mounted on the vehicle is transmitted to the operator workstation. The operator uses a mouse to pick a series of 'waypoints' in the image that define a path that the vehicle should follow. These 2D waypoints are then transmitted back to the vehicle, where they are used to compute the appropriate steering commands while the next image is being transmitted. STRIPE requires no advance knowledge of the terrain to be traversed, and can be used by novice operators with only minimal training. STRIPE is a unique combination of computer and human control. The computer must determine the 3D world path designated by the 2D waypoints and then accurately control the vehicle over rugged terrain. The human issues involve accurate path selection, and the prevention of disorientation, a common problem across all types of teleoperation systems. STRIPE is the only semi-autonomous teleoperation system that can accurately follow paths designated in monocular images on varying terrain. The thesis describes the STRIPE algorithm for tracking points using the incremental geometry model, insight into the design and redesign of the interface, an analysis of the effects of potential errors, details of the user studies, and hints on how to improve both the algorithm and interface for future designs.

REMOTE CONTROL↗
NASA NTRS2021

Concept of Operations for OSIRIS-REx Optical Navigation Image Planning

Optical navigation (OpNav) is a critical subsystem of the OSIRIS-REx asteroid sample return mission, which operated in the vicinity of near-Earth asteroid (101955) Bennu from August 2018 through April 2021. A substantial amount of mission resources across multiple subsystems and institutions is required to ensure that the OpNav data are successfully acquired. The KinetX OpNav team, part of the Flight Dynamics System (FDS), is responsible for performing required analysis to develop the OpNav operations plans; requesting, reviewing and verifying the plans; and ultimately using the image data for critical navigation operations. The FDS team, responsible for the mission navigation, is operated by KinetX Aerospace with management and operations support from NASA’s Goddard Space Flight Center. The Science Processing and Operations Center (SPOC), located at the University of Arizona’s Lunar and Planetary Laboratory, is responsible for generating the planning products for all science and most OpNav data. These plans are integrated into the spacecraft sequences, tested, and commanded by the Mission Support Area (MSA) at Lockheed Martin Space. To ensure mission-critical navigation image data are successfully acquired, the plan is developed through a waterfall of planning cycles over the course of 3 months prior to onboard plan execution. During the initial strategic planning for a mission phase, detailed analysis is performed by the OpNav team to conceptualize the concept of operations (ConOps) for image data collection. This phase OpNav Narrative is included along with other strategic planning documents for the key ground segment stakeholders to review and provide feedback. The detailed OpNav plans get defined in the tactical planning cycle, which spans 8 to 3 weeks before the week-long integrated sequence is executed on-board the spacecraft. During the tactical cycle, the initial OpNav Request is submitted along with the science requests, kicking off development of the science and OpNav plans. Once the initial plan is drafted, interfaces are exercised so that the plan can be reviewed and iterated, if necessary. A rigorous schedule is followed by the planning teams during the implementation cycle, spanning the last 18 days before uplink, to ensure all the necessary integration, testing, and reviewing can occur on time. The development of the OpNav planning ConOps, including responsibilities, interfaces, timelines, and procedures, took extensive collaboration across mission elements and institutions. The process was robust throughout the 137 weeks of continuous Optical Navigation Operations at Bennu, which concluded on April 9th, 2021.

Coralie D. Adam↗
NASA NTRS2008

NASA's Ares I and Ares V Launch Vehicles -- Effective Space Operations Through Efficient Ground Operations

The United States (U.S.) plans to return to the Moon by 2020, with the development of a new human-rated space transportation system to replace the Space Shuttle, which is due for retirement in 2010 after it completes its missions of building the International Space Station and servicing the Hubble Space Telescope. Powering the future of space-based scientific exploration will be the Ares I Crew Launch Vehicle, which will transport the Orion Crew Exploration Vehicle to orbit where it will rendezvous with the Lunar Lander. which will be delivered by the Ares V Cargo Launch Vehicle. This new transportation infrastructure, developed by the National Aeronautics and Space Administration (NASA), will allow astronauts to leave low-Earth orbit for extended lunar exploration and preparation for the first footprint on Mars. All space-based operations begin and are controlled from Earth. NASA's philosophy is to deliver safe, reliable, and cost-effective solutions to sustain a multi-billion-dollar program across several decades. Leveraging 50 years of lessons learned, NASA is partnering with private industry, while building on proven hardware experience. This paper will discuss how the Engineering Directorate at NASA's Marshall Space Flight Center is working with the Ares Projects Office to streamline ground operations concepts and reduce costs. Currently, NASA's budget is around $17 billion, which is less than 1 percent of the U.S. Federal budget. Of this amount, NASA invests approximately $4.5 billion each year in Space Shuttle operations, regardless of whether the spacecraft is flying or not. The affordability requirement is for the Ares I to reduce this expense by 50 percent, in order to allow NASA to invest more in space-based scientific operations. Focusing on this metric, the Engineering Directorate provides several solutions-oriented approaches, including Lean/Six Sigma practices and streamlined hardware testing and integration, such as assembling major hardware elements before shipping to the Kennedy Space Center for launch operations. This paper provides top-level details for several cost saving initiatives, including both process and product improvements that will result in space transportation systems that are designed with operations efficiencies in mind. The Engineering Directorate provides both the intellectual capital embodied in an experienced workforce and unique facilities in which to validate the information technology tools that allow a nationwide team to collaboratively connect across miles that separate them and the engineering disciplines that integrate various piece parts into a whole system. As NASA transforms ground-based operations, it also is transitioning its workforce from an era of intense hands-on labor to a new one of mechanized conveniences and robust hardware with simpler interfaces. Ensuring that space exploration is on sound footing requires that operations efficiencies be designed into the transportation system and implemented in the development stage. Applying experience gained through decades of ground and space op'erations, while using value-added processes and modern business and engineering tools, is the philosophy upon which a new era of exploration will be built to solve some of the most pressing exploration challenges today -- namely, safety, reliability, and affordability.

Dumbacher, Daniel L.↗
NASA NTRS2015

Python-Based Scientific Analysis and Visualization of Precipitation Systems at NASA Marshall Space Flight Center

At NASA Marshall Space Flight Center (MSFC), Python is used several different ways to analyze and visualize precipitating weather systems. A number of different Python‐based software packages have been developed, which are available to the larger scientific community. The approach in all these packages is to utilize pre‐existing Python modules as well as to be object‐oriented and scalable. The first package that will be described and demonstrated is the Python Advanced Microwave Precipitation Radiometer (AMPR) Data Toolkit, or PyAMPR for short. PyAMPR reads geolocated brightness temperature data from any flight of the AMPR airborne instrument over its 25‐year history into a common data structure suitable for user‐defined analyses. It features rapid, simplified (i.e., one line of code) production of quick‐look imagery, including Google Earth overlays, swath plots of individual channels, and strip charts showing multiple channels at once. These plotting routines are also capable of significant customization for detailed, publication‐ready figures. Deconvolution of the polarization‐varying channels to static horizontally and vertically polarized scenes is also available. Examples will be given of PyAMPR's contribution toward real‐time AMPR data display during the Integrated Precipitation and Hydrology Experiment (IPHEx), which took place in the Carolinas during May‐June 2014. The second software package is the Marshall Multi‐Radar/Multi‐Sensor (MRMS) Mosaic Python Toolkit, or MMM‐Py for short. MMM‐Py was designed to read, analyze, and display three‐dimensional national mosaicked reflectivity data produced by the NOAA National Severe Storms Laboratory (NSSL). MMM‐Py can read MRMS mosaics from either their unique binary format or their converted NetCDF format. It can also read and properly interpret the current mosaic design (4 regional tiles) as well as mosaics produced prior to late July 2013 (8 tiles). MMM‐Py can easily stitch multiple tiles together to provide a larger regional or national picture of precipitating weather systems. Composites, horizontal and vertical crosssections, and combinations thereof are easily displayed using as little as one line of code. MMM‐Py can also write to the native MRMS binary format, and sub‐sectioning of tiles (or multiple stitched tiles) is anticipated to be in place by the time of this meeting. Thus, MMM‐Py also can be used to power the creation of custom mosaics for targeted regional studies. Overlays of other data (e.g., lightning observations) are easily accomplished. Demonstrations of MMM‐Py, including the creation of animations, will be shown. Finally, Marshall has done significant work to interface Python‐based analysis routines with the U.S. Department of Energy's Py‐ART software package for radar data ingest, processing, and analysis. One example of this is the Python Turbulence Detection Algorithm (PyTDA), an MSFC‐based implementation of the National Center for Atmospheric Research (NCAR) Turbulence Detection Algorithm (NTDA) for the purposes of convective‐scale analysis, situational awareness, and forensic meteorology. PyTDA exploits Py‐ART's radar data ingest routines and data model to rapidly produce aviation‐relevant turbulence estimates from Doppler radar data. Work toward processing speed optimization and better integration within the Py‐ART framework will be highlighted. Python‐based analysis within the Py‐ART framework is also being done for new research related to intercomparison of ground‐based radar data with satellite estimates of ocean winds, as well as research on the electrification of pyrocumulus clouds.

Lang, Timothy J.↗
NASA NTRSDate not supplied

The Wizard Staff: A Mobile Tool Supporting Human Exploration on The Lunar Surface

The Wizard Staff is a rechargeable, battery powered mobile tool with multiple uses for lunar surface exploration. It supports human activity as a surface survey tool, provides external illumination to enhance safety, delivers networking, communications, and navigation features to remote sites, and assists crew rescue with an emergency beacon and rigid splint structure. As a survey tool, it assists crewed geologic field site exploration with external lights, cameras, and LiDAR to illuminate, map, and record the sample collection process. As a relay station, it provides a surface intranet communications and navigation node for extended exploration far from the lander or habitation module. A separately developed Search-and-Rescue (SAR) handheld device can broadcast a signal to the Gandalf Staff containing crew position and biometric data. The staff then formats the message and sends it orbiting satellite(s) for emergency response via the LunaNET on a dedicated frequency similar to terrestrial applications using an Emergency Position-Indicating Radiobeacon (EPIRB). The staff is designed with an upper and lower segment. Components in the upper segment are the LiDAR, external lighting arrays, cameras, communications equipment, intelligence devices, and user interface for crew operations. The lower segment is a set of FeLiPO4 battery cells packed into the 2” diameter carbon fiber tube. When the battery pack is discharged, a spring connector (designed for the dusty lunar environment) easily disconnects the two segments for replacement with another fully charged battery pack. The lower segment can be used for Incapacitated Crew Rescue (ICR) as a rigid splint. As a stand-alone science platform, the Wizard Staff provides infrastructure for instruments and sensors to record the lunar environment over long periods of time. After a crew installs the components on the lunar surface, the platform delivers data to the lunar lander or base station for analysis. The stand-alone mode requires an auxiliary power source (e.g. solar array) and energy storage system (e.g. battery), so it could also be used as an electrical recharging station. A working prototype of Wizard Staff has been developed with collaboration between NASA (JSC, MSFC, and GSFC), Texas Space Technology Applications and Research (T STAR), and Texas A&M University (TAMU) using $300k of innovation funding in FY’21 and FY’22. The functional staff weights 36# on Earth (6# on the Moon), stands 2.1m tall and delivers external lighting with an array of 40 LED bulbs generating 1460 Lux at 2m range (near field), or 2 Lux at 50m (far field).

Gandalf Staff↗
NASA NTRS2001

Using XML and Java Technologies for Astronomical Instrument Control

Traditionally, instrument command and control systems have been highly specialized, consisting mostly of custom code that is difficult to develop, maintain, and extend. Such solutions are initially very costly and are inflexible to subsequent engineering change requests, increasing software maintenance costs. Instrument description is too tightly coupled with details of implementation. NASA Goddard Space Flight Center, under the Instrument Remote Control (IRC) project, is developing a general and highly extensible framework that applies to any kind of instrument that can be controlled by a computer. The software architecture combines the platform independent processing capabilities of Java with the power of the Extensible Markup Language (XML), a human readable and machine understandable way to describe structured data. A key aspect of the object-oriented architecture is that the software is driven by an instrument description, written using the Instrument Markup Language (IML), a dialect of XML. IML is used to describe the command sets and command formats of the instrument, communication mechanisms, format of the data coming from the instrument, and characteristics of the graphical user interface to control and monitor the instrument. The IRC framework allows the users to define a data analysis pipeline which converts data coming out of the instrument. The data can be used in visualizations in order for the user to assess the data in real-time, if necessary. The data analysis pipeline algorithms can be supplied by the user in a variety of forms or programming languages. Although the current integration effort is targeted for the High-resolution Airborne Wideband Camera (HAWC) and the Submillimeter and Far Infrared Experiment (SAFIRE), first-light instruments of the Stratospheric Observatory for Infrared Astronomy (SOFIA), the framework is designed to be generic and extensible so that it can be applied to any instrument. Plans are underway to test the framework with other types of instruments, such as remote sensing earth science instruments.

Ames, Troy↗
NASA NTRS2022

The Mars 2020 Ground Data System Architecture

The Mars 2020 Mission’s primary objective is to collect 20 geographically unique samples during its prime mission of one and a quarter Martian years, or just over 2 Earth years. Mission planners determined the project needed to develop a system that would enable the operations team to analyze engineering and science data, make science decisions, select viable rover targets at a millimeter resolution and validate an uplink bundle for a car sized rover with more complex science instruments than any previous Mars surface mission. All this had to be done within a five hour time frame. Doing this with a small team would be a challenge, but this had to be accomplished by a large team of engineers and scientists located across North America and Europe. Achieving this level of operational efficiency was unheard of in the prime mission. In addition, the mission had another set of requirements that had nothing to do with surface operations; the Mars 2020 Ground Data System (GDS) was also expected to comply with a new set of security requirements to keep up with the ever changing cybersecurity landscape. The Mars 2020 Ground Data System (GDS) is a re-architected version of the Mars Science Laboratory GDS. The primary goal was to integrate the lessons learned from previous Mars surface missions, accommodate a set of new requirements and capabilities required to ensure mission success, and comply with a new set of cybersecurity controls. The new architecture includes several unique qualities including a data lake, language-agnostic system-wide event-based operations, containerization, automated deployment, network segmentation, infrastructure-as-code, API-driven interfaces, and the first Mars surface GDS to operate primarily in the cloud. The new architecture enabled greater access to the system’s data, tighter integration with the operations team, and a higher level of traceability. The availability of the data also enabled a new set of capabilities previously not possible on surface missions. These new capabilities include an autonomous data to information, pipeline for downlink analysis, horizontal scaling of science data processing capabilities, autonomous round trip data tracking of science and engineering data, integration of flight system state into the tactical planning cycle, high fidelity targeting utilizing kinematic data, and hierarchical image and 3d meshes data representations. This paper will introduce the requirements for the Mars 2020 Mission, the heritage architecture, and the rationale for the changes to achieve the new architecture. The paper will continue to describe the fundamental changes made to the GDS architecture, how these changes enabled a more tightly integrated GDS, and the new capabilities that were enabled by the new architecture. The paper will conclude with the lessons learned from the process of rearchitecting a heritage GDS system and from the first 200 days of operations supporting over 800 users from around the world.

Lopez-Roig, Reynaldo↗