Search NASA⌕ Search

SEARCH · Search NASA

Results for “virtual control interface”

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

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

194 records · Page 11

Creating Camera Controls for First-Person Camera in VulkanSceneGraph

The way users interact with a virtual, three-dimensional (3D) scene is heavily influenced by the way the camera used to view the scene is controlled. A first-person camera is a common form of camera control for computer programs. Its role is to create an immersive viewer experience, which allows users to traverse a scene as they might in the real world. Allowing for the implementation of the first-person camera makes for a more holistic, well-rounded way to interact with the visualization program. Accomplishing this involves mathematical calculations that define how the camera should be moved for the computer system. These movements equate to the rotation, translation, and scale of the changes. It should be noted that a computer does not inherently process what movement directions (left, right, up, or down) mean. The mathematical equations used define these principles in a way the computer can process. Further aspects to consider are detecting when the camera has moved and how far. This is most frequently accomplished through user |input through external devices. These devices, for the purpose of this report, include mouse input and keyboard input. Additionally, the in-development program this report is referencing works with the VulkanSceneGraph (VSG) library to create the scene and build the base of the camera controls. Although VSG is a powerful library with many capabilities, additional Application Programming Interfaces (APIs) might be needed during development to produce the desired results, as is the case in this program. Through combining proper mathematical calculations, utilizing additional APIs, and implementing the existing VSG library capabilities, implementing first-person camera controls is possible in a 3D scene.

Kristie O'Brien↗

Increasing Flight Software Reuse with OpenSatKit

In January 2015 the NASA Goddard Space Flight Center (GSFC) released the Core Flight System (cFS) as open source under the NASA Open Source Agreement (NOSA) license. The cFS is based on flight software (FSW) developed for 12 spacecraft spanning nearly two decades of effort and it can provide about a third of the FSW functionality for a low-earth orbiting scientific spacecraft. The cFS is a FSW framework that is portable, configurable, and extendable using a product line deployment model. However, the components are maintained separately so the user must configure, integrate, and deploy them as a cohesive functional system. This can be very challenging especially for organizations such as universities building cubesats that have minimal experience developing FSW. Supporting universities was one of the primary motivators for releasing the cFS under NOSA. This paper describes the OpenSatKit that was developed to address the cFS deployment challenges and to serve as a cFS training platform for new users. It provides a fully functional out-of-the box software system that includes NASA's cFS, Ball Aerospace's command and control system COSMOS, and a NASA dynamic simulator called 42. The kit is freely available since all of the components have been released as open source. The kit runs on a Linux platform, includes 8 cFS applications, several kit-specific applications, and built in demos illustrating how to use key application features. It also includes the software necessary to port the cFS to a Raspberry Pi and instructions for configuring COSMOS to communicate with the target. All of the demos and test scripts can be rerun unchanged with the cFS running on the Raspberry Pi. The cFS uses a 3-tiered layered architecture including a platform abstraction layer, a Core Flight Executive (cFE) middle layer, and an application layer. Similar to smart phones, the cFS application layer is the key architectural feature for users to extend the FSW functionality to meet their mission-specific requirements. The platform abstraction layer and the cFE layers go a step further than smart phones by providing a platform-agnostic Application Programmer Interface (API) that allows applications to run unchanged on different platforms. OpenSatKit can serve two significant architectural roles that will further help the adoption of the cFS and help create a community of users that can share assets. First, the kit is being enhanced to automate the integration of applications with the goal of creating a virtual cFS "App Store".. Second, a platform certification test suite can be developed that would allow users to verify the port of the cFS to a new platform. This paper will describe the current state of these efforts and future plans.

Computer Programming and Software↗

Managing the Digital Thread for Structural Applications With Fit for Purpose Materials

With the increased emphasis on reducing the cost and time to market of new materials, the need for analytical tools that enable the virtual design and optimization of materials throughout their processing - internal structure - property - performance envelope, along with the capturing and storing of the associated material and model information across its lifecycle, has become critical. This need is also fueled by the demands for higher efficiency in material testing; consistency, quality and traceability of data; product design; engineering analysis; as well as control of access to proprietary or sensitive information. Consequently, at NASA Glenn Research Center a robust information management system that manages the digital thread across the full material life (i.e., capture, analysis, maintenance, and dissemination of data) cycle directed at the design of ‘fit-for-purpose materials’ is under development. To this end the Application Table has been incorporated within NASA Glenn Research Center’s ICME Information Management framework within the ANSYS Granta MI tool. The Application Table provides a place where material and structural application information/requirements can be linked to marry the “design-the-material” (structural engineering) and the “design-with-material” (material science) paradigms and thereby enable application-driven design and optimization of materials and structures. In additional several associated toolsets, specifically: AIMAOS (Automated Information Management Across Organizations and Scales), Py MILab, and JARIMIS (Just A Rather Intelligent Material Interrogation System) are also under development to assist in the judicious automation of this process. AIMOAS offers users an interactive graphical user interface for connecting material information management systems with both commercial and in-house simulation tools at various length scales to enable such automation in the handoff across scales and maintenance of material digital twins and the digital thread. Py MILab, is an automatic framework for the capture, analysis, maintenance, and storage of material test data. Py MILab uses a modular approach for capturing raw data, analyzing the data, and storing the data in a database, interfaced by neutral file structures, to promote plug-and-play capabilities for various analysis types. Finally, JARIMIS is an expert system that integrates various materials informatics tools (e.g., MicroNet, Surrogate ML models, ANSYS Granta MI, etc.) to enable inverse design of materials and facilitate the application of machine learning (ML) and data science with human in the loop decision making to rapidly discover and optimize new materials.

Digital Transformation↗

Increasing Flight Software Reuse with OpenSatKit

In January 2015 the NASA Goddard Space Flight Center (GSFC) released the Core Flight System (cFS) as open source under the NASA Open Source Agreement (NOSA) license. The cFS is based on flight software (FSW) developed for 12 spacecraft spanning nearly two decades of effort and it can provide about a third of the FSW functionality for a low-earth orbiting scientific spacecraft. The cFS is a FSW framework that is portable, configurable, and extendable using a product line deployment model. However, the components are maintained separately so the user must configure, integrate, and deploy them as a cohesive functional system. This can be very challenging especially for organizations such as universities building cubesats that have minimal experience developing FSW. Supporting universities was one of the primary motivators for releasing the cFS under NOSA. This paper describes the OpenSatKit that was developed to address the cFS deployment challenges and to serve as a cFS training platform for new users. It provides a fully functional out-of-the box software system that includes NASA's cFS, Ball Aerospaceâ€"TM"s command and control system COSMOS, and a NASA dynamic simulator called 42. The kit is freely available since all of the components have been released as open source. The kit runs on a Linux platform, includes 8 cFS applications, several kit-specific applications, and built in demos illustrating how to use key application features. It also includes the software necessary to port the cFS to a Raspberry Pi and instructions for configuring COSMOS to communicate with the target. All of the demos and test scripts can be rerun unchanged with the cFS running on the Raspberry Pi. The cFS uses a 3-tiered layered architecture including a platform abstraction layer, a Core Flight Executive (cFE) middle layer, and an application layer. Similar to smart phones, the cFS application layer is the key architectural feature for userâ€"TM"s to extend the FSW functionality to meet their mission-specific requirements. The platform abstraction layer and the cFE layers go a step further than smart phones by providing a platform-agnostic Application Programmer Interface (API) that allows applications to run unchanged on different platforms. OpenSatKit can serve two significant architectural roles that will further help the adoption of the cFS and help create a community of users that can share assets. First, the kit is being enhanced to automate the integration of applications with the goal of creating a virtual cFS 'App Store'. Second, a platform certification test suite can be developed that would allow users to verify the port of the cFS to a new platform. This paper will describe the current state of these efforts and future plans.

McComas, David↗

Bird's Eye View - A 3-D Situational Awareness Tool for the Space Station

Even as space-qualified computer hardware lags well behind the latest home computers, the possibility of using high-fidelity interactive 3-D graphics for displaying important on board information has finally arrived, and is being used on board the International Space Station (ISS). With the quantity and complexity of space-flight telemetry, 3-D displays can greatly enhance the ability of users, both onboard and on the ground, to interpret data quickly and accurately. This is particularly true for data related to vehicle attitude, position, configuration, and relation to other objects on the ground or in-orbit Bird's Eye View (BEV) is a 3-D real-time application that provides a high degree of Situational Awareness for the crew. Its purpose is to instantly convey important motion-related parameters to the crew and mission controllers by presenting 3-D simulated camera views of the International Space Station (ISS) in its actual environment Driven by actual telemetry, and running on board, as well as on the ground, the user can visualize the Space Station relative to the Earth, Sun, stars, various reference frames, and selected targets, such as ground-sites or communication satellites. Since the actual ISS configuration (geometry) is also modeled accurately, everything from the alignment of the solar panels to the expected view from a selected window can be visualized accurately. A virtual representation of the Space Station in real time has many useful applications. By selecting different cameras, the crew or mission control can monitor the station's orientation in space, position over the Earth, transition from day to night, direction to the Sun, the view from a particular window, or the motion of the robotic arm. By viewing the vehicle attitude and solar panel orientations relative to the Sun, the power status of the ISS can be easily visualized and understood. Similarly, the thermal impacts of vehicle attitude can be analyzed and visually confirmed. Communication opportunities can be displayed, and line-of-sight blockage due to interference by the vehicle structure (or the Earth) can be seen easily. Additional features in BEV display targets on the ground and in-orbit, including cities, communication sites, landmarks, satellites, and special sites of scientific interest for Earth observation and photography. Any target can be selected and tracked. This gives the user a continual line-of-sight to the target of current interest, and real-time knowledge about its visibility. Similarly, the vehicle ground-track, and an option to show "visibility circles" around displayed ground sites, provide continuous insight regarding current and future visibility to any target BEV was designed with inputs from many disciplines in the flight control and operations community both at NASA and from the International Partners. As such, BEV is setting the standards for interactive 3-D graphics for spacecraft applications. One important contribution of BEV is a generic graphical interface for camera control that can be used for any 3-D applications. This interface has become part of the International Display and Graphics Standards for the 16-nation ISS partnership. Many other standards related to camera properties, and the display of 3-D data, also have been defined by BEV. Future enhancements to BEV will include capabilities related to simulating ahead of the current time. This will give the user tools for analyzing off-nominal and future scenarios, as well as for planning future operations.

Dershowitz, Adam↗

Additive Manufacturing, Design, Testing, and Fabrication: A Full Engineering Experience at JSC

I worked on several projects this term. While most projects involved additive manufacturing, I was also involved with two design projects, two testing projects, and a fabrication project. The primary mentor for these was Richard Hagen. Secondary mentors were Hai Nguyen, Khadijah Shariff, and fabrication training from James Brown. Overall, my experience at JSC has been successful and what I have learned will continue to help me in my engineering education and profession long after I leave. My 3D printing projects ranged from less than a 1 cubic centimeter to about 1 cubic foot and involved several printers using different printing technologies. It was exciting to become familiar with printing technologies such as industrial grade FDM (Fused Deposition Modeling), the relatively new SLA (Stereolithography), and PolyJet. My primary duty with the FDM printers was to model parts that came in from various sources to print effectively and efficiently. Using methods my mentor taught me and the Stratasys Insight software, I was able to minimize imperfections, hasten build time, improve strength for specific forces (tensile, shear, etc...), and reduce likelihood of a print-failure. Also using FDM, I learned how to repair a part after it was printed. This is done by using a special kind of glue that chemically melts the two faces of plastic parts together to form a fused interface. My first goal with SLA technology was to bring the printer back to operational readiness. In becoming familiar with the Pegasus SLA printer, I researched the leveling, laser settings, and different vats to hold liquid material. With this research, I was successfully able to bring the Pegasus back online and have successfully printed multiple sample parts as well as functional parts. My experience with PolyJet technology has been focused on an understanding of the abilities/limits, costs, and the maintenance for daily use. Still upcoming will be experience with using a composite printer that uses FDM technology to print plastic while laying an internal filament of Kevlar or carbon-fiber inside the printed material. It has been incredible being exposed to this range of technologies and I feel very fortunate to be ready for virtually any kind of printing technology I come across in the future. Design work played a part in my internship this term as well. Working with Hai Nguyen, I was able to design a set of testing tips and a test frame for use with an Arcjet. The testing tips will be made of several different materials that will possibly be used in the heat shield of the Orion space craft. These designs included technical drawings that were presented to the fabrication shop. The frame design was created from 80/20 (a popular brand of frame construction equipment) and included an order form with pricing for fabrication. An independent design was also done for the virtual reality lab. This design was to create a hand-controller based on a previous design. This final design was sent directly to a 3D printer without technical drawings. Overall, my design work has given me experience with using 80/20, helped improve my CAD (Computer Aided Design) proficiency, and increased my knowledge of how to set up technical drawings for fabrication. The final role I have played in this internship has been to assist with testing of the inflatable technology materials working Khadijah Shariff. I began the internship assisting with permeability testing with the initial plan to continue the testing independently after training. Unfortunately, the testing apparatus suffered a technical failure and had funding pulled which cancelled that portion of the project. Further testing with inflatable technology continued with tensile testing of various stitching methods. This testing took place over a two-days and concluded successfully. Final testing was to be more tensile testing but of straps used to connect various inflatable sections. Unfortunately, the needed grips for the tensile tests could not be located and put the testing on hold. It is possible this round of testing will still take place by the end of the internship if the grips can be found. Overall, this portion of the internship has helped me become familiar with one kind of permeability test as well as a popular tensile/compression testing machine. Finally, I also had the chance to be trained using a metal lathe for making very small tips for a soldering iron. These tips will be used to melt threaded brass inserts into 3D printed plastic. Working with James Brown, I was able to successfully machine a brass rod down to as little as 0.064 inches plus or minus 0.001 inches. It was very rewarding to learn how to best use the machine and become familiar with a skill that will undoubtedly be used again in the future. I have been told by several professional engineers that learning to use a lathe and mill will be invaluable skills in the field. This knocks 50 percent of that goal off and I look forward to learning the mill at some point in the future. As is apparent with this list of projects, my internship was not focused on a single over-arching goal. Instead, I was able to gain experience in a myriad of very different areas. I feel like my time here was spent bouncing from one project to the next. Though sometimes difficult to switch gears, it was very rewarding to be a part of so much in so little time. My career and education will be positively impacted by what I have learned at JSC. My experience with 3D printing has improved my ability to handle many issues that may come up in the future with multiple different technologies. The design work I took part in, especially creating technical drawings, will help me better present designs to any engineer or shop I will encounter. My testing experience has helped me become familiar with a popular kind of tensile test machine that will likely be similar to the kinds I will encounter in the future. Finally, my experience with fabrication has given me a rare opportunity, as an engineer, to take part in the fabrication of a part. This experience will help me better tailor my future designs for the manufacturing process and has given me an appreciation for detailed/delicate machining work. My experience at JSC has been successful and will continue to assist me for a long time within the engineering field.

Zusack, Steven↗

"Virtual Cockpit Window" for a Windowless Aerospacecraft

A software system processes navigational and sensory information in real time to generate a three-dimensional-appearing image of the external environment for viewing by crewmembers of a windowless aerospacecraft. The design of the particular aerospacecraft (the X-38) is such that the addition of a real transparent cockpit window to the airframe would have resulted in unacceptably large increases in weight and cost. When exerting manual control, an aircrew needs to see terrain, obstructions, and other features around the aircraft in order to land safely. The X-38 is capable of automated landing, but even when this capability is utilized, the crew still needs to view the external environment: From the very beginning of the United States space program, crews have expressed profound dislike for windowless vehicles. The wellbeing of an aircrew is considerably promoted by a three-dimensional view of terrain and obstructions. The present software system was developed to satisfy the need for such a view. In conjunction with a computer and display equipment that weigh less than would a real transparent window, this software system thus provides a virtual cockpit window. The key problem in the development of this software system was to create a realistic three-dimensional perspective view that is updated in real time. The problem was solved by building upon a pre-existing commercial program LandForm C3 that combines the speed of flight-simulator software with the power of geographic-information-system software to generate real-time, three-dimensional-appearing displays of terrain and other features of flight environments. In the development of the present software, the pre-existing program was modified to enable it to utilize real-time information on the position and attitude of the aerospacecraft to generate a view of the external world as it would appear to a person looking out through a window in the aerospacecraft. The development included innovations in realistic horizon-limit modeling, three-dimensional stereographic display, and interfaces for utilization of data from inertial-navigation devices, Global Positioning System receivers, and laser rangefinders.

Abernathy, Michael F.↗

Network-Capable Application Process and Wireless Intelligent Sensors for ISHM

Intelligent sensor technology and systems are increasingly becoming attractive means to serve as frameworks for intelligent rocket test facilities with embedded intelligent sensor elements, distributed data acquisition elements, and onboard data acquisition elements. Networked intelligent processors enable users and systems integrators to automatically configure their measurement automation systems for analog sensors. NASA and leading sensor vendors are working together to apply the IEEE 1451 standard for adding plug-and-play capabilities for wireless analog transducers through the use of a Transducer Electronic Data Sheet (TEDS) in order to simplify sensor setup, use, and maintenance, to automatically obtain calibration data, and to eliminate manual data entry and error. A TEDS contains the critical information needed by an instrument or measurement system to identify, characterize, interface, and properly use the signal from an analog sensor. A TEDS is deployed for a sensor in one of two ways. First, the TEDS can reside in embedded, nonvolatile memory (typically flash memory) within the intelligent processor. Second, a virtual TEDS can exist as a separate file, downloadable from the Internet. This concept of virtual TEDS extends the benefits of the standardized TEDS to legacy sensors and applications where the embedded memory is not available. An HTML-based user interface provides a visual tool to interface with those distributed sensors that a TEDS is associated with, to automate the sensor management process. Implementing and deploying the IEEE 1451.1-based Network-Capable Application Process (NCAP) can achieve support for intelligent process in Integrated Systems Health Management (ISHM) for the purpose of monitoring, detection of anomalies, diagnosis of causes of anomalies, prediction of future anomalies, mitigation to maintain operability, and integrated awareness of system health by the operator. It can also support local data collection and storage. This invention enables wide-area sensing and employs numerous globally distributed sensing devices that observe the physical world through the existing sensor network. This innovation enables distributed storage, distributed processing, distributed intelligence, and the availability of DiaK (Data, Information, and Knowledge) to any element as needed. It also enables the simultaneous execution of multiple processes, and represents models that contribute to the determination of the condition and health of each element in the system. The NCAP (intelligent process) can configure data-collection and filtering processes in reaction to sensed data, allowing it to decide when and how to adapt collection and processing with regard to sophisticated analysis of data derived from multiple sensors. The user will be able to view the sensing device network as a single unit that supports a high-level query language. Each query would be able to operate over data collected from across the global sensor network just as a search query encompasses millions of Web pages. The sensor web can preserve ubiquitous information access between the querier and the queried data. Pervasive monitoring of the physical world raises significant data and privacy concerns. This innovation enables different authorities to control portions of the sensing infrastructure, and sensor service authors may wish to compose services across authority boundaries.

Figueroa, Fernando↗

A SIMULINK environment for flight dynamics and control analysis: Application to the DHC-2 Beaver. Part 1: Implementation of a model library in SIMULINK. Part 2: Nonlinear analysis of the Beaver autopilot

The design of advanced Automatic Aircraft Control Systems (AACS's) can be improved upon considerably if the designer can access all models and tools required for control system design and analysis through a graphical user-interface, from within one software environment. This MSc-thesis presents the first step in the development of such an environment, which is currently being done at the Section for Stability and Control of Delft University of Technology, Faculty of Aerospace Engineering. The environment is implemented within the commercially available software package MATLAB/SIMULINK. The report consists of two parts. Part I gives a detailed description of the AACS design environment. The heart of this environment is formed by the SIMULINK implementation of a nonlinear aircraft model in block-diagram format. The model has been worked out for the old laboratory aircraft of the Faculty, the De Havilland DHC-2 'Beaver', but due to its modular structure, it can easily be adapted for other aircraft. Part I also describes MATLAB programs which can be applied for finding steady-state trimmed-flight conditions and for linearization of the aircraft model, and it shows how the built-in simulation routines of SIMULINK have been used for open-loop analysis of the aircraft dynamics. Apart from the implementation of the models and tools, a thorough treatment of the theoretical backgrounds is presented. Part II of this report presents a part of an autopilot design process for the 'Beaver' aircraft, which clearly demonstrates the power and flexibility of the AACS design environment from part I. Evaluations of all longitudinal and lateral control laws by means of nonlinear simulations are treated in detail. The AACS design environment from part I proved to be a very useful tool for designing the control laws of the 'Beaver' autopilot within a very tight time-schedule. The autopilot design process itself will be used as a guideline for future AACS research at the Faculty of Aerospace Engineering. Flight tests of the 'Beaver' autopilot, done after evaluating the control laws in the SIMULINK package, proved to be quite successful. In the future, the AACS design package will evolve into a standardized, integrated design environment which can be applied to virtually any type of aircraft. The AACS design cycle will be shortened further by developing tools for automatically porting control laws from the MATLAB/SIMULINK environment to a piloted real-time flight simulator and the Flight Control Computers of the aircraft.

Flight Control System Design↗

NPSS on NASA's IPG: Using CORBA and Globus to Coordinate Multidisciplinary Aeroscience Applications

Within NASA's High Performance Computing and Communication (HPCC) program, the NASA Glenn Research Center is developing an environment for the analysis/design of aircraft engines called the Numerical Propulsion System Simulation (NPSS). The vision for NPSS is to create a "numerical test cell" enabling full engine simulations overnight on cost-effective computing platforms. To this end, NPSS integrates multiple disciplines such as aerodynamics, structures, and heat transfer and supports "numerical zooming" between O-dimensional to 1-, 2-, and 3-dimensional component engine codes. In order to facilitate the timely and cost-effective capture of complex physical processes, NPSS uses object-oriented technologies such as C++ objects to encapsulate individual engine components and CORBA ORBs for object communication and deployment across heterogeneous computing platforms. Recently, the HPCC program has initiated a concept called the Information Power Grid (IPG), a virtual computing environment that integrates computers and other resources at different sites. IPG implements a range of Grid services such as resource discovery, scheduling, security, instrumentation, and data access, many of which are provided by the Globus toolkit. IPG facilities have the potential to benefit NPSS considerably. For example, NPSS should in principle be able to use Grid services to discover dynamically and then co-schedule the resources required for a particular engine simulation, rather than relying on manual placement of ORBs as at present. Grid services can also be used to initiate simulation components on parallel computers (MPPs) and to address inter-site security issues that currently hinder the coupling of components across multiple sites. These considerations led NASA Glenn and Globus project personnel to formulate a collaborative project designed to evaluate whether and how benefits such as those just listed can be achieved in practice. This project involves firstly development of the basic techniques required to achieve co-existence of commodity object technologies and Grid technologies; and secondly the evaluation of these techniques in the context of NPSS-oriented challenge problems. The work on basic techniques seeks to understand how "commodity" technologies (CORBA, DCOM, Excel, etc.) can be used in concert with specialized "Grid" technologies (for security, MPP scheduling, etc.). In principle, this coordinated use should be straightforward because of the Globus and IPG philosophy of providing low-level Grid mechanisms that can be used to implement a wide variety of application-level programming models. (Globus technologies have previously been used to implement Grid-enabled message-passing libraries, collaborative environments, and parameter study tools, among others.) Results obtained to date are encouraging: we have successfully demonstrated a CORBA to Globus resource manager gateway that allows the use of CORBA RPCs to control submission and execution of programs on workstations and MPPs; a gateway from the CORBA Trader service to the Grid information service; and a preliminary integration of CORBA and Grid security mechanisms. The two challenge problems that we consider are the following: 1) Desktop-controlled parameter study. Here, an Excel spreadsheet is used to define and control a CFD parameter study, via a CORBA interface to a high throughput broker that runs individual cases on different IPG resources. 2) Aviation safety. Here, about 100 near real time jobs running NPSS need to be submitted, run and data returned in near real time. Evaluation will address such issues as time to port, execution time, potential scalability of simulation, and reliability of resources. The full paper will present the following information: 1. A detailed analysis of the requirements that NPSS applications place on IPG. 2. A description of the techniques used to meet these requirements via the coordinated use of CORBA and Globus. 3. A description of results obtained to date in the first two challenge problems.

Lopez, Isaac↗

EVA Swab Kit: Tools and Techniques for Collecting Aseptic Samples from Crewed Space Missions

Introduction: When we send humans to search for life on other planets, we'll need to know what we brought with us versus what may already be there. To ensure our crewed spacecraft meet planetary protection requirements—and to protect our science from human contamination—we'll need to assess and verify whether micro-organisms may be leaking/venting from our spacesuits. This requires collecting samples under Extravehicular Activity (EVA) conditions. Detailed, systematic research on forward contamination from robotic spacecraft has been steadily progressing since the Viking missions, but systematic studies of contamination from space suits has not been conducted in many years. The modern EMU (Extravehicular Mobility Unit) suit used by NASA is designed to leak at rates as high as 100 cc/min. Before humans land on Mars there is a critical need to understand the types and quantities of microbes that could be introduced via space suits. The Human Forward Contamination Assessment team at NASA’s Johnson Space Center (JSC) has developed a prototype EVA swab tool [1,2,3,4] designed for use in space to sample cleaned and uncleaned space suits to determine the present day microbial load and eventually the rate of leakage. The ability to assess microbial leakage early in advanced space suit and life support system design cycles will help avoid costly hardware redesign later. Test Objectives: The primary objective of EMU testing was to characterize the type of micro-organisms typically found on or near selected suit pressure joints under suit differential pressure conditions. Most human-borne microbes can fit through a 0.5 to 1.0 µm gap. Knowing which joints are more likely to leak will inform hardware design decisions. Knowing which types of micro-organisms may leak from EVA suits provides a basis for subsequent studies to characterize the viability of those organisms under destination conditions, as well as how far they might spread through natural or human-influenced processes. That data, in turn, will inform exploration mission operations and hardware design. The secondary objective of testing was to evaluate the interface between a fully suited test subject and the EVA swab tool at vacuum. Bulky EVA suits can restrict movement and limit visibility through the helmet visor. Fully suited testing is important for identifying tool design issues prior to flight. At exploration destinations, such as Mars, suited crew may be required to periodically sample their suits as part of an environmental monitoring protocol. Suit Microbial Sampling Results: This report details results of microbial swabs collected from current flight suit configurations worn by crew members assigned to upcoming ISS expedition missions as well as swabs collected from prototype suits intended for use on the Orion spacecraft. These tests were intended to characterize the types of contaminants found on flight suits under current, typical handling conditions. No attempt was made to change suit handling procedures, provide additional sterilization, or to limit typical potential contaminant sources. Using culture based techniques, we cultivated 235 CFU (colony forming units) comprised of 26 bacterial species and one fungal species on the outside of the suits. The fungal species and 14 of the bacterial species were unique to the suit surfaces and were not detected in any of the background samples collected within the chambers. We sequenced 755,434 ribosomal fragments on all of the suit surfaces from swab samples. 557,016 of these sequences represent DNA that survived at least 4 hours at vacuum. These sequences formed 2,464 OTU's (Operational Taxonomic Units, 97% similarity) showing low diversity in the samples. The most abundant sequences that survived vacuum belong to the genera Staphyloccocus, Ralstona, Bacillus and Rhodobacter all of which are common to the human microbiome. [5] See Danko et al., (2021) for more complete details of these first analyses. Further analysis of EVA suit materials with respect to the efficacy of various cleaning protocols and engineered containment solutions is planned to inform suit design for NASA’s Artemis Moon to Mars program crew testing. Swab Tool Function Results: The kit was demonstrated for fit and function in suited subject vacuum tests to determine how well the tool worked as an aseptic microbial sampling device as well as to identify any design elements that could be upgraded for EVA task specific improvement. It was found that sample acquisition efficacy could be enhanced by redesign of the sample canister to end-effector interface. Several modifications of the sample caddy assemblies to optimize EVA safety and functionality were also identified. Consequently, fabrication of the redesigned sample canister to end-effector assembly interfaces and and the sample caddy assemblies are required. Fabrication of sixteen flight sample canister assemblies (8 per each of two EVA Swab Kits) and two sample caddy assemblies are in process to be followed by hardware testing and certification to produce two flight-certified EVA Swab Kits for transport to ISS no earlier than summer of 2022. Sampling Strategy: The International Space Station is an ideal testbed for systematic studies of contamination from crewed vehicles since it has been continuously occupied for 20 years and exposed to non-terrestrial conditions. We will sample the exterior of the ISS during EVA using a purpose-built swab tool capable of maintaining sterility while undergoing temperature changes from -151 to +121°C under hard vacuum. Prior to each EVA, the project team will work with ISS mission managers to identify precise sampling locations, which will vary by EVA based on the translation paths and worksites scheduled for that particular EVA. Ideally, translation path handrails and areas near ECLSS (Environmental Control and Life Support System) external vent openings on a spacecraft would be assessed. There are currently more than a dozen ECLSS external vents on the ISS. Some are connected to systems that vent waste products, while others are intended to equalize cabin pressure. As EVA opportunity allows, microbial samples from any of these external vents would provide a valuable data point, though some will be more useful than others. Four criteria have been identified to help prioritize sampling sites near vents: • EVA Accessibility: To minimize cost, it is desired to piggy-back onto a planned EVA. Therefore, the sampling location must be readily accessible by an EVA crew • Type of Vented Products: Vent products that have been in direct contact with crew, such as cabin air, are more likely to contain microorganisms than vent products associated with isolated systems, such as experiment module combustion products. • Mass of Vented Products: Higher-flow vents are more likely to contain detectible levels of microbial contaminants than lower-flow vents. • Local Environment: Sample locations with relatively benign local conditions, such as warm surfaces shielded from direct ultraviolet (UV) radiation exposure, may be more likely to support microbial growth than locations with harsher local environmental conditions. Because EVA accessibility is the most important criteria, the proposal team worked with an astronaut and flight controllers using the Dynamic Onboard Ubiquitous Graphics (DOUG) tool. The DOUG virtual environment allows an operator to “fly” around the current ISS vehicle configuration to assess EVA translation paths, attach points, and keep-out zones. While analysis on station or rapid return to Earth would be preferable, samples collected from the exterior of the ISS have already been exposed to temperature variations between -157 and +121 °C as well as hard vacuum. Therefore, they should be fairly stable and robust. We hypothesize that samples collected from the ISS exterior could be stored for up to 6 months at -80°C without degradation. Sample canisters will be returned to Earth while frozen at -80°C for analysis, and sterilized canisters can be re-flown back to ISS to support additional sampling opportunities Relevance to NASA Exploration Objectives: These data will allow us to identify new or improved methods, technologies, and procedures for spacecraft sterilization and leakage mitigation to minimize the amount of contamination introduced to the environment by human explorers. This work is funded by NASA research grant: NNH18ZDA001N-PPR References: [1] Bell, M.S. et al. (2015) LPS XLVI, Abst. #1832 [2] Rucker et al. (2018) 42nd COSPAR (PPP.3) [3] Bell, M.S. et al. (2019) Mars Extant Life Conference, Abst. #5096.[4] Bell, M.S. et al., (2020) 43rd COSPAR (BO.2).[5] Danko D, et.al.,(2021)Front.Microbiol.12:608478.

Mary Suzanne Bell↗

Using XR for Improving Scientific Discovery With Numerical Weather Models

Earth science (ES) digital twins will help us understand the complex interactions and interrelationships that make up our Earth system and the impacts of earth science phenomena on it. Our work addresses two underdeveloped areas in current ES digital twin work: improving the understanding and interaction with ES model outputs by using Virtual and Mixed Reality (XR) tools and improving the non-intuitive mapping of continuous ES natural phenomena to gridded reference frames in current numerical models. Traditionally, scientists working on ES view and analyze the results of calculated or measured observables with static 1-dimensional (1D), 2D or 3D plots displayed on flat computer screens or paper. Using such limited mediums, it can be very difficult to identify, track and understand the evolution of key features due to poor viewing angles and the nature of flat computer screens. In addition, numerical models, such as the NASA Goddard Earth Observing System (GEOS) ES model, are almost exclusively formulated, visualized and analyzed in an Eulerian reference frame with fixed grid points in space and time. However, ES phenomena such as convective clouds, hurricanes and wildfire smoke plumes are visualized and analyzed in a Lagrangian reference frame: therefore it is often difficult and unnatural to understand these phenomena in relation to each other, visualized either in an Eulerian or Lagrangian context. In 3D visualizations, data generally takes one of three forms: gridded (e.g., voxelized) data, where space is divided into regions; point clouds, where data is represented as a set of points; and meshes, where objects are rendered as surfaces composed of small polygons (usually triangles). A gridded, Eulerian reference frame has been the default representation for the 2D visual analysis of atmospheric data in part because the numerical methods used to generate atmospheric model data in the first place use a gridded approach, with equations defining the relationships between the physical variables in each of a grid's cells across successive timesteps. In our work, we are particularly interested in data from GEOS. Another reason why gridded representations tend to be used for visualizing data from such models is because trajectories are difficult to interpret from representations on 2D surfaces, due to line-of-sight ambiguity. Instead of a fixed grid from GEOS, we embed a trajectory model to simulate particles' movement throughout a GEOS run. We then ingest these particle trajectories as animated point clouds with a NASA open source XR toolkit, the Mixed Reality Exploration Toolkit (MRET), and merge GEOS data with ES phenomena data onto one combined visualization that the user can intuitively interact with. Efficient rendering of arbitrarily large point clouds is an ongoing challenge being addressed by the computer science community, with the GPU-based optimizations and efficient GPU memory utilization a common theme of recent advances, especially for XR, where sustained high frame rate is mandatory to save the user from suffering due to simulation sickness. In this work, we describe and evaluate our progress in choosing and implementing appropriate methods for rendering arbitrarily large point clouds within MRET for XR. While tracking the XR headset enables the immersion of a user within a 3D scene of a data visualization, tracking of XR handheld controllers or user’s hands enables us to implement intuitive user interactions with the visualized datasets. Conventional tools require a user working with an ES visualization to conduct many interactions to commit their intended selections or manipulations with a visualized dataset; for example to specify a set of points in 3D space. Doing so in a 2D flat screen interface has traditionally required specifying a set of points in three distinct 2D coordinate systems (XY, XZ, and YZ), which is cumbersome. In other scientific domains, it has been shown that specifying or selecting a location or volume in XR using handheld controllers or tracked hands allows for greater speed and accuracy. We anticipate the same will hold true for atmospheric data, and we will share initial results of measuring the utility of such an interface. Notably, as the data being visualized is generated by GEOS as a prediction based on initial conditions, an intended application of our tool is to serve as part of an iterative feedback loop. Through XR, a scientist will review and manipulate a GEOS model run, modifying the conditions as needed to do subsequent runs of GEOS. Thereby, XR-based improvements to speed and accuracy of 3D tagging of points minimizes the effort required by both the scientist and the computer cluster conducting the necessary calculations.

Thomas Grubb↗

State-of-the-Art: Small Spacecraft Technology

When the first edition of NASA’s Small Spacecraft Technology State-of-the-art report was published in 2013, 247 CubeSats and 105 other non-CubeSat small spacecraft under 50 kilograms (kg) had been launched worldwide, representing less than 2% of launched mass into orbit over multiple years. In 2013 alone, around 60% of the total spacecraft launched had a mass under 600 kg, and of those under 600 kg, 83% were under 200 kg and 37% were nanosatellites (1). Of the total 1,849 spacecraft launched in 2021, 94% were small spacecraft with an overall mass under 600 kg, and of those under 600 kg, 40% were under 200 kg, and 11% were nanosatellites (1). Since 2013, the fight heritage for small spacecraft has increased by over 30% and has become the primary source to space access for commercial, government, private, and academic institutions. The total number of spacecraft launched in the past 10 years is 5,681 and 45% of those had a mass. As with all previous editions of this report, the 2022 edition captures and distills a wealth of new information available on small spacecraft systems from NASA and other publicly available sources. This report is limited to publicly available information and cannot reflect major advances in development that are not publicly disclosed. We encourage any opportunity to publish mission outcomes and technology development milestones (e.g., via conference papers, press releases, company website) so they can be reflected in this report. Overall, this report is a survey of small spacecraft technologies sourced from open literature; it does not endeavor to be an original source, and only considers literature in the public domain to identify and classify devices. Commonly used sources for data include manufacturer datasheets, press releases, conference papers, journal papers, public filings with government agencies, news articles, presentations, the compendium of databases accessed via NASA’s Small Spacecraft Systems Virtual Institute (S3VI) Information Search, and engagement with companies. Data not appropriate for public dissemination, such as proprietary, export controlled, or otherwise restricted data, are not considered. As a result, this report includes many dedicated hours of desk research performed by subject matter experts reviewing resources noted above. Content in this 2022 edition is based on data available by October 2022. This report should not be considered as a comprehensive overview of all the technologies but a great reference for the current state-of-the-art SmallSat technologies. The organizational approach for each chapter is relatively consistent with previous editions and includes an introduction of the technology, current development status of the technology’s procurable systems, and summary tables of technologies surveyed. The content in each chapter is uniquely organized to present a mini-stand-alone report on spacecraft subsystems. As in previous years, chapters include information from previous editions but are updated with new and maturating technologies and reference missions. Tables in each section provide a convenient summary of the technologies discussed, with explanations and references in the body text. The authors have attempted to isolate trends in the small spacecraft industry to point out which technologies have been adopted after successful demonstration missions. Lastly, the authors tried to use the terms “SmallSat,” “microsatellite,” “nanosatellite,” and “CubeSat” in a consistent manner, even as these terms are often used interchangeably in the space industry. Every subsystem chapter contains updated information to reflect the growth in the small spacecraft market. Significant changes are included in several chapters. The “Complete Spacecraft Platforms” chapter now includes information on the two main market options, hosted payload services and dedicated buses. The “Power” chapter provides information on the development of solid-state batteries with significantly higher energy than the current state-of-theart lithium-ion batteries. A large effort was made to update the “Communications” chapter to appropriately capture the recent technology maturation of optical communications for SmallSats. The “Ground Data Systems and Mission Operations” chapter was updated to reflect the recent establishment of the Near Space Network and influx of SmallSat Optical Ground Stations. The “Guidance, Navigation and Control” chapter was updated to include Lidar sensor technology. The “Deorbit Systems” chapter includes a discussion of recently proposed changes by the Federal Communications Commission (FCC) to limit a spacecraft’s lifetime to no longer than 5 years after end-of-mission. The “Identification and Tracking” Chapter includes updated information on the progress of SmallSat tracking. Finally, this report now encompasses technology funded by NASA’s Small Spacecraft Technology (SST) program’s SmallSat Technology Partnerships (STP) initiative which is described further in this Introduction. The reader can find the included SST technology in the “On the Horizon” section of the “Thermal Systems”, “Communications”, and “Guidance, Navigation, and Control” chapters. A central element of this report is to list state-of-the-art technologies by NASA standard Technology Readiness Level (TRL) as defined by the 2020 NASA Engineering Handbook, found in NASA NPR 7123.1C NASA Systems Engineering Processes and Requirements. The authors have endeavored to independently verify the TRL value of each technology by reviewing and citing published test results or publicly available data to the best of their ability. Where test results and data disagree with vendors’ own advertised TRL, the authors have attempted to engage the vendors to discuss the discrepancy. Readers are strongly encouraged to follow the references cited in the literature describing the full performance range and capabilities of each technology. Readers of this report should reach out to individual companies to further clarify information. It is important to note that this report takes a broad system-level view. To attain a high TRL, the subsystem must be in a flight-ready configuration with all supporting infrastructure—such as mounting points, power conversion, and control algorithms—in an integrated unit. An accurate TRL assessment requires a high degree of technical knowledge on a subject device, and an in-depth understanding of the mission (including interfaces and environment) on which the device was flown. There is variability in TRL values depending on design factors for a specific technology. For example, differences in TRL assessment based on the operating environment may result from the thermal environment, mechanical loads, mission duration, or radiation exposure. If a technology has flown on a mission without success, or without providing valid confirmation to the operator, such claimed “flight heritage” was discounted. The authors believe TRLs are most accurately determined when assessed within the context of a program’s unique requirements. While the overall capability of small spacecraft has matured since the 2021 edition of this report, technologies are still being developed to make deep space SmallSat missions more routine and more cost effective. Future editions of this report may include content dedicated to the rapidly growing fields of assembly, integration, and testing services, and mission modeling and simulation–all of which are now extensively represented at small spacecraft conferences. Many of these subsystems and services are still in their infancy, but as they evolve and reliable conventions and standards emerge, the next iteration of this report may also evolve to include additional chapters.

Bruce Yost↗

Autonomous Ocean World Exploration: Advancement of a Virtual Testbed

The search for life (extinct or extant) and potentially habitable bodies in our solar system and beyond is one of the 12 priority science questions outlined in the National Acadamies’ 2022 decadal survey [5]. Extraterrestrial destinations containing liquid water present an opportunity to search for life as we know it, and in recent years an increasing number of such locations have been discovered within our solar system. Several Jovian moons—Europa, Ganymede, and Callisto [10]—and the Saturnian moons Enceladus [8] and Titan [9] are known or suspected to harbor massive subsurface oceans. Of these "ocean worlds", Europa is the focus of at least one planned NASA orbiter mission, Europa Clipper [4], and an early lander mission concept, the Europa Lander [2, 3]. Whereas most robotic missions to the Moon and Mars (e.g. orbiters, rovers, landers) to date have had ground controllers on Earth tightly involved in mission operations, missions to more distant worlds will require a high degree of onboard autonomy due to long communication lags and blackouts, harsh environments (radiation, cold), and more limited battery and hardware life. The past decade has seen great advances in both AI technologies and computing scalability and performance that offer promising solutions for spacecraft autonomy and motivate the software system and research programs described in this paper. The Ocean Worlds Autonomy Testbed for Exploration, Research, and Simulation (OceanWATERS) [1], which has been in development at the NASA Ames Research Center since 2018, is a virtual environment for testing lander autonomy solutions. It is built on the Robot Operating System (ROS), runs on consumer-grade Linux workstations, and was released as open source in 2020. OceanWATERS provides a physical and visual simulation of a prototypical lander in a Europa-like environment (Figure 1). The lander was modeled after requirements and specifications made in JPL’s Europa Lander Study of 2016 [3]. Simulated lander systems include stereo cameras and spotlights mounted on an antenna mast that pans and tilts, a 6 degrees of freedom (DoF) robotic arm with a force-torque sensor and two interchangeable end effectors, and a battery pack power system. The environment consists of multiple terrain models including a highly detailed model sourced from the FROST dataset [11], simulation of surrounding planetary bodies based on an ephemeris model, and lighting from the sun with associated surface illumination, reflectance, and shadows. Operations supported by OceanWATERS include panoramic and directed imaging of the environment and lander workspace, Cartesian and joint-level arm commanding, grinding of the terrain surface (e.g. digging a trench), and scooping of ground material (Figure 2) which can be discarded or collected as science samples in a receptacle that can be emptied (science operations themselves are not simulated). These operations are realized as ROS Actions and are complimented by a wide selection of telemetry that is continually produced by each lander subsystem. The power system model is driven by the open-source Generic Software Architecture for Prognostics (GSAP) [11] that predicts the battery’s remaining useful life and other characteristics. As a testbed for high-level autonomy, OceanWATERS provides an execution framework based on PLEXIL [12], an open-source plan specification language and execution engine developed largely at Ames. NASA's initial development of OceanWATERS, as well the Ocean Worlds Lander Autonomy Testbed (OWLAT) [6], a complimentary physical testbed developed at JPL, was the first step in a plan for realizing candidate onboard autonomy solutions for such planetary landers. In 2020 NASA solicited applications for its Autonomous Robotics Research for Ocean Worlds (ARROW) program, and in 2021 the similar Concepts for Ocean worlds Life Detection Technology (COLDTech) program. Collectively six research teams, based in universities and companies across the United States, were awarded grants to develop and demonstrate autonomy solutions on OceanWATERS and OWLAT. These 1–2-year projects have now finished or are nearing completion, and a wide variety of autonomy challenges in ocean world surface missions were addressed. Prototyped and demonstrated solutions have included autonomous discovery, response and adaptation to system faults and unexpected environmental events, world model synthesis through perception, plan synthesis using learned models, methods to optimize sample target selection and prioritize science data transmission, extension of PLEXIL for stochastic decision-making, and an integration of a model of JPL’s mission-ready COLDArm [7]. Technologies used in these projects include many forms of machine learning, causal reasoning, automated planning, Markov decision processes, formal methods, and other advanced techniques. A more detailed summary of the ARROW and COLDTech projects is given herein. OceanWATERS has had significant enhancements since its open-source release in 2020. Many of its new features were driven or shaped by feedback from the ARROW and COLDTech teams and requirements of their projects. In support of enabling autonomous adaptation to spacecraft faults (a specific capability solicited by both programs), a fault injection and detection framework was developed that supports a wide and growing range of fault types such as locked joints, image loss, and battery failures. The power system model was completed and integrated into the simulator, starting as a single-cell battery model and later upgraded to a multi-cell model with associated faults such as cell disconnection. Arm/terrain interaction was improved by adding a force-torque sensor and associated faults, and an analytic dig force model based on the Balovnev bucket force equations. Environment fidelity was increased by modeling terrain deformation resulting from digging and scooping; visual improvements were made in textures, lighting, and shadows. To facilitate interoperation with OWLAT, a unified command and telemetry interface between the testbeds was developed at the ROS level, along with a PLEXIL interface. The number of lander operations was greatly expanded (e.g. with Cartesian-based arm and antenna movement), and a framework was designed for users to build their own lander actions. A GUI for PLEXIL plan selection was created (Figure 3), and an expansive set of plans were added, such as those that illustrate patterns for fault handling. This paper provides a self-contained high-level description of OceanWATERS, focusing on more detailed coverage of the aforementioned enhancements. It provides a high-level summary of the projects undertaken by participants in the ARROW and COLDTech programs and how these efforts have helped shape OceanWATERS. Finally, potential future work and directions for the testbed are listed, as likely informed by the recent planetary science decadal survey [5].

K Michael Dalal↗