Search NASA⌕ Search

SEARCH · Search NASA

Results for “script”

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 1,603 records · Page 89

Integrated Test and Evaluation (ITE) Flight Test Series 4

The integrated Flight Test 4 (FT4) will gather data for the UAS researchers Sense and Avoid systems (referred to as Detect and Avoid in the RTCA SC 228 ToR) algorithms and pilot displays for candidate UAS systems in a relevant environment. The technical goals of FT4 are to: 1) perform end-to-end traffic encounter test of pilot guidance generated by DAA algorithms; 2) collect data to inform the initial Minimum Operational Performance Standards (MOPS) for Detect and Avoid systems. FT4 objectives and test infrastructure builds from previous UAS project simulations and flight tests. NASA Ames (ARC), NASA Armstrong (AFRC), and NASA Langley (LaRC) Research Centers will share responsibility for conducting the tests, each providing a test lab and critical functionality. UAS-NAS project support and participation on the 2014 flight test of ACAS Xu and DAA Self Separation (SS) significantly contributed to building up infrastructure and procedures for FT3 as well. The DAA Scripted flight test (FT4) will be conducted out of NASA Armstrong over an eight-week period beginning in April 2016.

ITE↗

Finite Element Modeling and Analysis of Mars Entry Aeroshell Baseline Concept

The structure that is developed and analyzed in this project must be able to survive all the various load conditions that it will encounter along its course to Mars with the minimal amount of weight and material. At this stage, the goal is to study the capability of the structure using a finite element model (FEM). This FEM is created using a python script, and is numerically solved in Nastran. The purpose of the model is to achieve an optimization of mass given specific constraints on launch and entry. The generation and analysis of the baseline Rigid Mid-Range Lift to Drag Ratio Aeroshell model is a continuation and an improvement on previous work done for the FEM. The model is generated using Python programming with the axisymmetric placement of nodes for beam and shell elements. The shells are assigned a honeycomb sandwich material with an aluminum honeycomb core and composite face sheets, and the beams are assigned the same material as the shell face sheets. There are two load cases assigned to the model: Earth launch and Mars entry. The Earth launch case consists of pressure, gravity, and vibration loads, and the Mars entry case consists of just pressure and gravity loads. The Earth launch case was determined to be the driving case, though the analyses are performed for both cases to ensure the constraints are satisfied. The types of analysis performed with the model are design optimization, statics, buckling, normal modes, and frequency response, the last of which is only for the Earth launch load case. The final results indicated that all of the requirements are satisfied except the thermal limits, which could not yet be tested, and the normal modes for the Mars entry. However, the frequency limits during Mars entry are expected to be much higher than the lower frequency limits set for the analysis. In addition, there are still improvements that can be made in order to reduce the weight while still meeting all requirements.

Ahmed, Samee W.↗

A Method for Rapid Measurement of Contrast Sensitivity on Mobile Touch-Screens

Touch-screen displays in cell phones and tablet computers are now pervasive, making them an attractive option for vision testing outside of the laboratory or clinic. Here we de- scribe a novel method in which subjects use a finger swipe to indicate the transition from visible to invisible on a grating which is swept in both contrast and frequency. Because a single image can be swiped in about a second, it is practical to use a series of images to zoom in on particular ranges of contrast or frequency, both to increase the accuracy of the measurements and to obtain an estimate of the reliability of the subject. Sensitivities to chromatic and spatio-temporal modulations are easily measured using the same method. A proto- type has been developed for Apple Computer's iPad/iPod/iPhone family of devices, implemented using an open-source scripting environment known as QuIP (QUick Image Processing, http://hsi.arc.nasa.gov/groups/scanpath/research.php). Preliminary data show good agreement with estimates obtained from traditional psychophysical methods as well as newer rapid estimation techniques. Issues relating to device calibration are also discussed.

contrast sensitivity↗

OpenSatKit Enables Quick Startup for CubeSat Missions

The software required to develop, integrate, and operate a spacecraft is substantial regardless of whether its a large or small satellite. Even getting started can be a monumental task. To solve this problem, NASAs Core Flight System (cFS), NASA's 42 spacecraft dynamics simulator, and Ball Aerospaces COSMOS ground system have been integrated together into a kit called OpenSatKit that provides a complete and open source software solution for starting a new satellite mission. Users can have a working system with flight software, dynamics simulation, and a ground command and control system up and running within hours.Every satellite mission requires three primary categories of software to function. The first is Flight Software (FSW) which provides the onboard control of the satellites and its payload(s). NASA's cFS provides a great platform for developing this software. Second, while developing a satellite on earth, it is necessary to simulate the satellites orbit, attitude, and actuators, to ensure that the systems that control these aspects will work correctly in the real environment. NASAs 42 simulator provides these functionalities. Finally, the ground has to be able to communicate with the satellite, monitor its performance and health, and display its data. Additionally, test scripts have to be written to verify the system on the ground. Ball Aerospace's COSMOS command and control system provides this functionality. Once the OpenSatKit is up and running, the next step is to customize the platform and get it running on the end target. Starting from a fully working system makes porting the cFS from Linux to a users platform much easier. An example Raspberry Pi target is included in the kit so users can gain experience working with a low cost hardware target. All users can benefit from OpenSatKit but the greatest impact and benefits will be to SmallSat missions with constrained budgets and small software teams. This paper describes OpenSatKits system design, the steps necessary to run the system to target the Raspberry Pi, and future plans. OpenSatKit is a free fully functional spacecraft software system that we hope will greatly benefit the SmallSat community.

Software↗

Kepler Fine Guidance Sensor Data

The Kepler and K2 missions collected Fine Guidance Sensor (FGS) data in addition to the science data, as discussed in the Kepler Instrument Handbook (KIH, Van Cleve and Caldwell 2016). The FGS CCDs are frame transfer devices (KIH Table 7) located in the corners of the Kepler focal plane (KIH Figure 24), which are read out 10 times every second. The FGS data are being made available to the user community for scientific analysis as flux and centroid time series, along with a limited number of FGS full frame images which may be useful for constructing a World Coordinate System (WCS) or otherwise putting the time series data in context. This document will describe the data content and file format, and give example MATLAB scripts to read the time series. There are three file types delivered as the FGS data.1. Flux and Centroid (FLC) data: time series of star signal and centroid data. 2. Ancillary FGS Reference (AFR) data: catalog of information about the observed stars in the FLC data. 3. FGS Full-Frame Image (FGI) data: full-frame image snapshots of the FGS CCDs.

Kepler↗

Interactive Exploration Robots: Human-Robotic Collaboration and Interactions

For decades, NASA has employed different operational approaches for human and robotic missions. Human spaceflight missions to the Moon and in low Earth orbit have relied upon near-continuous communication with minimal time delays. During these missions, astronauts and mission control communicate interactively to perform tasks and resolve problems in real-time. In contrast, deep-space robotic missions are designed for operations in the presence of significant communication delay - from tens of minutes to hours. Consequently, robotic missions typically employ meticulously scripted and validated command sequences that are intermittently uplinked to the robot for independent execution over long periods. Over the next few years, however, we will see increasing use of robots that blend these two operational approaches. These interactive exploration robots will be remotely operated by humans on Earth or from a spacecraft. These robots will be used to support astronauts on the International Space Station (ISS), to conduct new missions to the Moon, and potentially to enable remote exploration of planetary surfaces in real-time. In this talk, I will discuss the technical challenges associated with building and operating robots in this manner, along with lessons learned from research conducted with the ISS and in the field.

Fong, Terry↗

Assessment of Air Traffic Controller Acceptability of Aircrew Route Change Requests

NASA developed the traffic aware strategic aircrew requests concept for a cockpit automation that identifies route improvements and advises the aircrew to request the change from the air traffic controller. In order to increase the chance of air traffic control approval, the automation ensures that the route is clear of known traffic, weather, and airspace restrictions. Hence the technology is anticipated to provide benefits in areas such as flight efficiency, flight schedule compliance, passenger comfort, and pilot and controller workload. In support of a field trial of a prototype of the technology, observations were conducted at the Atlanta and Jacksonville air traffic control centers to identify the main factors that affect the acceptability of aircrew requests by air traffic controllers. Observers shadowed air traffic controllers as the test flight pilot made pre-scripted requests to invoke acceptability issues and then they interviewed voluntarily fifty controllers with experience ranging from one to thirty-five years. The most common reason for rejecting requests is conflicting with traffic followed by violating air traffic procedures, increasing sector workload, and conflicting with major arrival and departure flows and flow restrictions. Quantitative parameters such as the distance that a route should maintain from sector boundaries and special use airspace were identified and recommended for inclusion in the automation.

Flight Optimization; Field Trial↗

Assessment of Air Traffic Controller Acceptability of Aircrew Route Change Requests

NASA developed the traffic aware strategic aircrew requests concept for a cockpit automation that identifies route improvements and advises the aircrew to request the change from the air traffic controller. In order to increase the chance of air traffic control approval, the automation ensures that the route is clear of known traffic, weather, and airspace restrictions. Hence the technology is anticipated to provide benefits in areas such as flight efficiency, flight schedule compliance, passenger comfort, and pilot and controller workload. In support of a field trial of a prototype of the technology, observations were conducted at the Atlanta and Jacksonville air traffic control centers to identify the main factors that affect the acceptability of aircrew requests by air traffic controllers. Observers shadowed air traffic controllers as the test flight pilot made pre-scripted requests to invoke acceptability issues and then they interviewed voluntarily fifty controllers with experience ranging from one to thirty-five years. The most common reason for rejecting requests is conflicting with traffic followed by violating air traffic procedures, increasing sector workload, and conflicting with major arrival and departure flows and flow restrictions. Quantitative parameters such as the distance that a route should maintain from sector boundaries and special use airspace were identified and recommended for inclusion in the automation.

Flight Optimization; Field Trial↗

Launch Control System Software Development System Automation Testing

The Spaceport Command and Control System (SCCS) is the National Aeronautics and Space Administration's (NASA) launch control system for the Orion capsule and Space Launch System, the next generation manned rocket currently in development. This system requires high quality testing that will measure and test the capabilities of the system. For the past two years, the Exploration and Operations Division at Kennedy Space Center (KSC) has assigned a group including interns and full-time engineers to develop automated tests to save the project time and money. The team worked on automating the testing process for the SCCS GUI that would use streamed simulated data from the testing servers to produce data, plots, statuses, etc. to the GUI. The software used to develop automated tests included an automated testing framework and an automation library. The automated testing framework has a tabular-style syntax, which means the functionality of a line of code must have the appropriate number of tabs for the line to function as intended. The header section contains either paths to custom resources or the names of libraries being used. The automation library contains functionality to automate anything that appears on a desired screen with the use of image recognition software to detect and control GUI components. The data section contains any data values strictly created for the current testing file. The body section holds the tests that are being run. The function section can include any number of functions that may be used by the current testing file or any other file that resources it. The resources and body section are required for all test files; the data and function sections can be left empty if the data values and functions being used are from a resourced library or another file. To help equip the automation team with better tools, the Project Lead of the Automated Testing Team, Jason Kapusta, assigned the task to install and train an optical character recognition (OCR) tool to Brandon Echols, a fellow intern, and I. The purpose of the OCR tool is to analyze an image and find the coordinates of any group of text. Some issues that arose while installing the OCR tool included the absence of certain libraries needed to train the tool and an outdated software version. We eventually resolved the issues and successfully installed the OCR tool. Training the tool required many images and different fonts and sizes, but in the end the tool learned to accurately decipher the text in the images and their coordinates. The OCR tool produced a file that contained significant metadata for each section of text, but only the text and coordinates of the text was required for our purpose. The team made a script to parse the information we wanted from the OCR file to a different file that would be used by automation functions within the automated framework. Since a majority of development and testing for the automated test cases for the GUI in question has been done using live simulated data on the workstations at the Launch Control Center (LCC), a large amount of progress has been made. As of this writing, about 60% of all of automated testing has been implemented. Additionally, the OCR tool will help make our automated tests more robust due to the tool's text recognition being highly scalable to different text fonts and text sizes. Soon we will have the whole test system automated, allowing for more full-time engineers working on development projects.

Automation↗

A Reliability Comparison of Classical and Stochastic Thickness Margin Approaches to Address Material Property Uncertainties for the Orion Heat Shield

The Orion Thermal Protection System (TPS) margin process uses a root-sum-square approach with branches addressing trajectory, aerothermodynamics, and material response uncertainties in ablator thickness design. The material response branch applies a bondline temperature reduction between the Avcoat ablator and EA9394 adhesive by 60 C (108 F) from its peak allowed value of 260 C (500 F). This process is known as the Bond Line Temperature Material Margin (BTMM) and is intended to cover material property and performance uncertainties. The value of 60 C (108 F) is a constant, applied at any spacecraft body location and for any trajectory. By varying only material properties in a random (monte carlo) manner, the perl-based script mcCHAR is used to investigate the confidence interval provided by the BTMM. In particular, this study will look at various locations on the Orion heat shield forebody for a guided and an abort (ballistic) trajectory.

margins↗

A Reliability Comparison of Classical and Stochastic Thickness Margin Approaches to Address Material Property Uncertainties for the Orion Heat Shield

The Orion Thermal Protection System (TPS) margin process uses a root-sum-square approach with branches addressing trajectory, aerothermodynamics, and material response uncertainties in ablator thickness design. The material response branch applies a bond line temperature reduction between the Avcoat ablator and EA9394 adhesive by 60 C (108 F) from its peak allowed value of 260 C (500 F). This process is known as the Bond Line Temperature Material Margin (BTMM) and is intended to cover material property and performance uncertainties. The value of 60 C (108 F) is a constant, applied at any spacecraft body location and for any trajectory. By varying only material properties in a random (monte carlo) manner, the perl-based script mcCHAR is used to investigate the confidence interval provided by the BTMM. In particular, this study will look at various locations on the Orion heat shield forebody for a guided and an abort (ballistic) trajectory.

FIAT↗

Comparative Analysis of ACAS-Xu and DAIDALUS Detect-and-Avoid Systems

The Detect and Avoid (DAA) capability of a recent version (Run 3) of the Airborne Collision Avoidance System-Xu (ACAS-Xu) is measured against that of the Detect and AvoID Alerting Logic for Unmanned Systems (DAIDALUS), a reference algorithm for the Phase 1 Minimum Operational Performance Standards (MOPS) for DAA. This comparative analysis of the two systems' alerting and horizontal guidance outcomes is conducted through the lens of the Detect and Avoid mission using flight data of scripted encounters from a recent flight test. Results indicate comparable timelines and outcomes between ACAS-Xu's Remain Well Clear alert and guidance and DAIDALUS's corrective alert and guidance, although ACAS-Xu's guidance appears to be more conservative. ACAS-Xu's Collision Avoidance alert and guidance occurs later than DAIDALUS's warning alert and guidance, and overlaps with DAIDALUS's timeline of maneuver to remain Well Clear. Interesting discrepancies between ACAS-Xu's directive guidance and DAIDALUS's "Regain Well Clear" guidance occur in some scenarios.

Davies, Jason T.↗

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↗

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↗

The GMAO Hybrid Ensemble-Variational Atmospheric Data Assimilation System: Version 2.0

This document describes the implementation and usage of the Goddard Earth Observing System (GEOS) Hybrid Ensemble-Variational Atmospheric Data Assimilation System (Hybrid EVADAS). Its aim is to provide comprehensive guidance to users of GEOS ADAS interested in experimenting with its hybrid functionalities. The document is also aimed at providing a short summary of the state-of-science in this release of the hybrid system. As explained here, the ensemble data assimilation system (EnADAS) mechanism added to GEOS ADAS to enable hybrid data assimilation applications has been introduced to the pre-existing machinery of GEOS in the most non-intrusive possible way. Only very minor changes have been made to the original scripts controlling GEOS ADAS with the objective of facilitating its usage by both researchers and the GMAO's near-real-time Forward Processing applications. In a hybrid scenario two data assimilation systems run concurrently in a two-way feedback mode such that: the ensemble provides background ensemble perturbations required by the ADAS deterministic (typically high resolution) hybrid analysis; and the deterministic ADAS provides analysis information for recentering of the EnADAS analyses and information necessary to ensure that observation bias correction procedures are consistent between both the deterministic ADAS and the EnADAS. The nonintrusive approach to introducing hybrid capability to GEOS ADAS means, in particular, that previously existing features continue to be available. Thus, not only is this upgraded version of GEOS ADAS capable of supporting new applications such as Hybrid 3D-Var, 3D-EnVar, 4D-EnVar and Hybrid 4D-EnVar, it remains possible to use GEOS ADAS in its traditional 3D-Var mode which has been used in both MERRA and MERRA-2. Furthermore, as described in this document, GEOS ADAS also supports a configuration for exercising a purely ensemble-based assimilation strategy which can be fully decoupled from its variational component. We should point out that Release 1.0 of this document was made available to GMAO in mid-2013, when we introduced Hybrid 3D-Var capability to GEOS ADAS. This initial version of the documentation included a considerably different state-of-science introductory section but many of the same detailed description of the mechanisms of GEOS EnADAS. We are glad to report that a few of the desirable Future Works listed in Release 1.0 have now been added to the present version of GEOS EnADAS. These include the ability to exercise an Ensemble Prediction System that uses the ensemble analyses of GEOS EnADAS and (a very early, but functional version of) a tool to support Ensemble Forecast Sensitivity and Observation Impact applications.

Todling, Ricardo↗

Knowledge Base for Distributed Spacecraft Mission Design Using the Trade-Space Analysis Tool for Constellations (TAT-C)

Opportunities for multi-point measurements, greater revisit frequency, failure robustness, and improved cost effectiveness motivate consideration of Distributed Spacecraft Missions (DSMs) for future Earth science missions. However, careful analysis is required to assess the distributed sensing capabilities of a constellation compared to more mature monolithic spacecraft while also considering other important dimensions such as cost and risk. The large combinatorial DSM design space limits existing mission analysis tools and exploration methods which emphasize monolithic design variables. The Trade-space Analysis Tool for Constellations (TAT-C) under development at Goddard seeks to enumerate and evaluate alternative mission architectures to minimize cost and maximize scientific return for pre-defined goals during pre-phase A analysis.Similar to other model-centric engineering efforts, efficient data management is a significant challenge for DSM mission analysis. In TAT-C, a Knowledge Base (KB) is envisioned as a cumulative central repository of information and meta-information about DSMs. Initial KB concepts store related data for reuse within or across mission analyses; however, over time, the KB is envisioned to be an important layer to coordinate actions of both human analysts and automated design agents to search a large design space for desirable mission alternatives. Preliminary KB research builds on a modern web technology stack to provide the following functionality: 1) storage of trade-space search requests which set requirements and constraints for DSM concepts, 2) storage of analysis results which quantify performance metrics for evaluated DSM concepts, 3) a RESTful application programming interface (API) for scripted access to data from TAT-C modules, 4) web-based graphical user interface (GUI) for manual access to underlying data, and 5) access control and management restrictions relevant to data protection and security. These efforts have culminated in a prototype KB used by the research team during TAT-C development to assess opportunities for future work.

Pattern Recognition↗

Automated Spacecraft Communications Service Demonstration Using NASA's SCaN Testbed

The traditional paradigm for space mission operations relies on inefficient, highly scripted pre-planned activities between space communications & navigation service providers and user ground mission operations centers. Typically there is limited or non-existent automation capabilities on the user spacecraft for requesting space communications services, and on the provider network for request dispositioning and service provisioning. In the past, using these processes for space networks was sufficient with the relatively small number of user spacecraft requesting services. However, with an ever increasing number of satellites being launched to orbit, more complex event-driven science objectives, exploration missions involving collaborative platforms, and more distant missions, approaches that improve automation, flexibility and efficiency are needed. This paper describes NASA's recently completed on-orbit demonstration results of a new space communications service concept called User Initiated Service, and a discussion for infusing this innovation into operations.

waveforms↗

Electrodynamic Dust Shield (EDS) Preparation for MISSE-11 Launch

The dusty surfaces of the Moon, Mars, and various asteroids present a significant challenge to NASA’s manned and unmanned space exploration efforts. The fine, electrostatically charged dust is difficult to remove and has resulted in vision obscuration, false instrument readings, contamination, elevated temperatures, performance reduction, and equipment failure. To alleviate these problems, NASA KSC’s Electrostatics and Surface Physics Laboratory (ESPL) is developing active dust mitigation systems for solar system exploration and in situ resource utilization (ISRU). Part of KSC’s Swamp Works system, the lab emphasizes fast-paced, hands-on, cost-effective, and collaborative innovation. The Electrodynamic Dust Shield (EDS) is an ESPL technology being developed to prevent dust accumulation on space components. It consists of a dielectric substrate embedded with parallel electrodes which, when applied with high voltage out-of-phase waveforms, produce a traveling electric field wave that scatters dust particles from its surface via dielectrophoretic and electrostatic forces. The EDS is currently fully functional and has been tested for scalability and endurance in reduced gravity/pressure flight. Next, it will be part of the May 2019 Materials International Space Station Experiment-11 (MISSE-11) payload, which will test small shield samples for performance durability with exposure to the harsh space environment. The summer objective was to test EDS functionality before active and passive dust shield samples launch on MISSE-11, in order to screen for good flight/control samples as well as to compare pre-flight and post-flight clearing efficiencies. I imaged glass and Kapton shields of 2-phase and 3-phase electrode configurations with the Keyence VHX-5000 digital microscope to check for damage before and after all testing for a qualitative pre-flight baseline; helped with vacuum testing of high-voltage shield breakdown; assembled shields and wires using Electrobond 004 silver epoxy; and helped with vacuum and cryogenic dust clearance testing of assembled EDS systems. I learned CAD (computer-aided design) and 3D printing skills to create parts for a shaker table/motor assembly, which will allow for repeatable experiments by evening out EDS dust distribution in a consistent manner prior to dust scattering testing. I will also be improving the interfacing with Alpha Space’s prototype Data Communications Unit (DCU), a payload component to control power to the EDS and store data, by mapping the DCU structure upon power-up and writing shell scripts to improve various processes. Finally, I also CADed and 3D-printed plastic supports for three different geometries of the Electrostatic Precipitator (ESP), a project that aims to use high voltage electrodes to charge and filter out dust from the Martian atmosphere drawn for ISRU devices. This work on dust mitigation technologies will help to support future robotic and human space exploration missions, including NASA’s Journey to Mars; the EDS has especially significant applications to spacecraft solar panels, thermal radiators, viewports, and astronaut visors. This opportunity has also allowed me to become more familiar with various lab equipment and hardware testing, develop key modeling skills in SolidWorks, explore past and present components critical to America’s space program, work with inspiring peers and mentors, and ascertain my dream of working permanently for NASA.

space↗