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 505 records · Page 28

Status of the JWST Science Instrument Payload

The James Webb Space Telescope (JWST) Integrated Science Instrument Module (ISIM) system consists of five sensors (4 science): Mid-Infrared Instrument (MIRI), Near Infrared Imager and Slitless Spectrograph (NIRISS), Fine Guidance Sensor (FGS), Near InfraRed Camera (NIRCam), Near InfraRed Spectrograph (NIRSpec); and nine instrument support systems: Optical metering structure system, Electrical Harness System; Harness Radiator System, ISIM Electronics Compartment, ISIM Remote Services Unit, Cryogenic Thermal Control System, Command and Data Handling System, Flight Software System, Operations Scripts System.

JWST Payload↗

TASAR Flight Trial 2: Assessment of Air Traffic Controller Acceptability of TASAR Requests

In support of the Flight Trial (FT-2) of NASA's prototype of the Traffic Aware Strategic Aircrew Requests (TASAR) concept, observations were conducted at the air traffic facilities to identify and assess the main factors that affect the acceptability of pilot requests by air traffic controllers. Two observers shadowed air traffic controllers at the Atlanta (ZTL) and Jacksonville (ZJX) air traffic control centers as the test flight pilot made pre-scripted requests to invoke acceptability issues and then they interviewed the observed and other controllers voluntarily. Fifty controllers were interviewed with experience ranging from one to thirty-five years. All interviewed controllers were enthusiastic about the technology and accounting for sector boundaries in pilot requests, particularly if pilots can be made aware of high workload situations. All interviewed controllers accept more than fifty percent of pilot requests; forty percent of them reject less than ten percent of requests. The most common reason for rejecting requests is conflicting with traffic followed by violating letters of agreement (LOAs) and negatively impacting neighboring sector workload, major arrival and departure flows and flow restrictions. Thirty-six requests were made during the test, eight of which were rejected due to: the aircraft already handed off to another sector, violating LOA, opposing traffic, intruding into an active special use airspace (SUA), intruding into another center, weather, and unfamiliarity with the requested waypoint. Nine requests were accepted with delay mostly because the controller needed to locate unfamiliar waypoints or to coordinate with other controllers.

Idris, Husni↗

ROS Hexapod

As an intern project for NASA Johnson Space Center (JSC), my job was to familiarize myself and operate a Robotics Operating System (ROS). The project outcome will convert existing software assets into ROS using nodes, enabling a robotic Hexapod to communicate and to be functional and controlled by an existing PlayStation 3 (PS3) controller. Existing control algorithms and current libraries have no ROS capabilities within the Hexapod C++ source code. Conversion of C++ codes to ROS will enable existing code to be compatible with ROS, and will be controlled using existing PS3 controller. Furthermore, my job description is to design ROS messages and script programs which will enable assets to participate in the ROS ecosystem. In addition, an open source software (IDE) Arduino board will be integrated in the ecosystem with designing circuitry on a breadboard to add additional behavior with push buttons, potentiometers and other simple elements in the electrical circuitry. Other projects with the Arduino will be a GPS module digital clock that will run off 22 satellites to show accurate real time using a GPS signal and internal patch antenna to communicate with satellites.

Davis, Kirsch↗

Simulation Development and Analysis of Crew Vehicle Ascent Abort

NASA's Commercial Crew Program is an integral step in its journey to Mars as it would expedite development of space technologies and open up partnership with U.S. commercial companies. NASA reviews and independent assessment of Commercial Crew Program is fundamental to its success, and being able to model a commercial crew vehicle in a simulation rather than conduct a live test would be a safer, faster, and less expensive way to assess and certify the capabilities of the vehicle. To this end, my project was to determine the feasibility of using a simulation tool named SOMBAT version 2.0 to model a multiple parachute system for Commercial Crew Program simulation. The main tasks assigned to me were to debug and test the main parachute system model, (capable of simulating one to four main parachute bodies), and to utilize a graphical program to animate the simulation results. To begin tackling the first task, I learned how to use SOMBAT by familiarizing myself with its mechanics and by understanding the methods used to tweak its various parameters and outputs. I then used this new knowledge to set up, run, and analyze many different situations within SOMBAT in order to explore the limitations of the parachute model. Some examples of parameters that I varied include the initial velocity and orientation of the falling capsule, the number of main parachutes, and the location where the parachutes were attached to the capsule. Each parameter changed would give a different output, and in some cases, would expose a bug or limitation in the model. A major bug that I discovered was the inability of the model to handle any number of parachutes other than three. I spent quite some time trying to debug the code logically, but was unable to figure it out until my mentor taught me that digital simulation limitations can occur when some approximations are mistakenly assumed for certain in a physical system. This led me to the realization that unlike in all of the programming classes I have taken thus far that focus on pure logic, simulation code focuses on mimicking the physical world with some approximation and can have inaccuracies or numerical instabilities. Learning from my mistake, I adopted new methods to analyze these different simulations. One method the student used was to numerically plot various physical parameters using MATLAB to confirm the mechanical behavior of the system in addition to comparing the data to the output from a separate simulation tool called FAST. By having full control over what was being outputted from the simulation, I could choose which parameters to change and to plot as well as how to plot them, allowing for an in depth analysis of the data. Another method of analysis was to convert the output data into a graphical animation. Unlike the numerical plots, where all of the physical components were displayed separately, this graphical display allows for a combined look at the simulation output that makes it much easier for one to see the physical behavior of the model. The process for converting SOMBAT output for EDGE graphical display had to be developed. With some guidance from other EDGE users, I developed a process and created a script that would easily allow one to display simulations graphically. Another limitation with the SOMBAT model was the inability for the capsule to have the main parachutes instantly deployed with a large angle between the air speed vector and the chutes drag vector. To explore this problem, I had to learn about different coordinate frames used in Guidance, Navigation & Control (J2000, ECEF, ENU, etc.) to describe the motion of a vehicle and about Euler angles (e.g. Roll, Pitch, Yaw) to describe the orientation of the vehicle. With a thorough explanation from my mentor about the description of each coordinate frame, as well as how to use a directional cosine matrix to transform one frame to another, I investigated the problem by simulating different capsule orientations. In the end, I was able to show that this limitation could be avoided if the capsule is initially oriented antiparallel to its velocity vector.

Wong, Chi S.↗

Investigating the Simulink Auto-Coding Process

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

Gualdoni, Matthew J.↗

Optical Testing and Verification Methods for the James Webb Space Telescope Integrated Science Instrument Module Element

NASA's James Webb Space Telescope (JWST) is a 6.6m diameter, segmented, deployable telescope for cryogenic IR space astronomy (~40K). The JWST Observatory includes the Optical Telescope Element (OTE) and the Integrated Science Instrument Module (ISIM) that contains four science instruments (SI) and the fine guider. The SIs are mounted to a composite metering structure. The SI and guider units were integrated to the ISIM structure and optically tested at the NASA Goddard Space Flight Center as a suite using the Optical Telescope Element SIMulator (OSIM). OSIM is a full field, cryogenic JWST telescope simulator. SI performance, including alignment and wave front error, were evaluated using OSIM. We describe test and analysis methods for optical performance verification of the ISIM Element, with an emphasis on the processes used to plan and execute the test. The complexity of ISIM and OSIM drove us to develop a software tool for test planning that allows for configuration control of observations, associated scripts, and management of hardware and software limits and constraints, as well as tools for rapid data evaluation, and flexible re-planning in response to the unexpected. As examples of our test and analysis approach, we discuss how factors such as the ground test thermal environment are compensated in alignment. We describe how these innovative methods for test planning and execution and post-test analysis were instrumental in the verification program for the ISIM element, with enough information to allow the reader to consider these innovations and lessons learned in this successful effort in their future testing for other programs.

spaceborne telescopes↗

ROS Hexapod

As an intern project for NASA Johnson Space Center (JSC), my job was to familiarize myself and operate a Robotics Operating System (ROS). The project outcome converted existing software assets into ROS using nodes, enabling a robotic Hexapod to communicate to be functional and controlled by an existing PlayStation 3 (PS3) controller. Existing control algorithms and current libraries have no ROS capabilities within the Hexapod C++ source code when the internship started, but that has changed throughout my internship. Conversion of C++ codes to ROS enabled existing code to be compatible with ROS, and is now controlled using an existing PS3 controller. Furthermore, my job description was to design ROS messages and script programs that enabled assets to participate in the ROS ecosystem by subscribing and publishing messages. Software programming source code is written in directories using C++. Testing of software assets included compiling code within the Linux environment using a terminal. The terminal ran the code from a directory. Several problems occurred while compiling code and the code would not compile. So modifying code to where C++ can read the source code were made. Once the code was compiled and ran, the code was uploaded to Hexapod and then controlled by a PS3 controller. The project outcome has the Hexapod fully functional and compatible with ROS and operates using the PlayStation 3 controller. In addition, an open source software (IDE) Arduino board will be integrated into the ecosystem with designing circuitry on a breadboard to add additional behavior with push buttons, potentiometers and other simple elements in the electrical circuitry. Other projects with the Arduino will be a GPS module, digital clock that will run off 22 satellites to show accurate real time using a GPS signal and an internal patch antenna to communicate with satellites. In addition, this internship experience has led me to pursue myself to learn coding more efficiently and effectively to write, subscribe and publish my own source code in different programming languages. With some familiarity with software programming, it will enhance my skills in the electrical engineering field. In contrast, my experience here at JSC with the Simulation and Graphics Branch (ER7) has led me to take my coding skill to be more proficient to increase my knowledge in software programming, and also enhancing my skills in ROS. This knowledge will be taken back to my university to implement coding in a school project that will use source coding and ROS to work on the PR2 robot which is controlled by ROS software. My skills learned here will be used to integrate messages to subscribe and publish ROS messages to a PR2 robot. The PR2 robot will be controlled by an existing PS3 controller by changing C++ coding to subscribe and publish messages to ROS. Overall the skills that were obtained here will not be lost, but increased.

Davis, Kirsch↗

US Navy Submarine Sea Trial of the NASA Air Quality Monitor

For the past four years, the Air Quality Monitor (AQM) has been the operational instrument for measuring trace volatile organic compounds on the International Space Station (ISS). The key components of the AQM are the inlet preconcentrator, the gas chromatograph (GC), and the differential mobility spectrometer. Most importantly, the AQM operates at atmospheric pressure and uses air as the GC carrier gas, which translates into a small reliable instrument. Onboard ISS there are two AQMs, with different GC columns that detect and quantify 22 compounds. The AQM data contributes valuable information to the assessment of air quality aboard ISS for each crew increment. The U.S. Navy is looking to update its submarine air monitoring suite of instruments, and the success of the AQM on ISS has led to a jointly planned submarine sea trial of a NASA AQM. In addition to the AQM, the Navy is also interested in the Multi-Gas Monitor (MGM), which was successfully flown on ISS as a technology demonstration to measure major constituent gases (oxygen, carbon dioxide, water vapor, and ammonia). A separate paper will present the MGM sea trial results. A prototype AQM, which is virtually identical to the operational AQM, has been readied for the sea trial. Only one AQM will be deployed during the sea trial, but it is sufficient to detect the compounds of interest to the Navy for the purposes of this trial. A significant benefit of the AQM is that runs can be scripted for pre-determined intervals and no crew intervention is required. The data from the sea trial will be compared to archival samples collected prior to and during the trial period. This paper will give a brief overview of the AQM technology and protocols for the submarine trial. After a quick review of the AQM preparation, the main focus of the paper will be on the results of the submarine trial. Of particular interest will be the comparison of the contaminants found in the ISS and submarine atmospheres, as both represent closed environments. In U.K. submarine trials in the early 2000s, the submarine and ISS atmospheres were found to be remarkably similar.

Limero, Thomas↗

PISCES High Contrast Integral Field Spectrograph Simulations and Data Reduction Pipeline

The PISCES (Prototype Imaging Spectrograph for Coronagraphic Exoplanet Studies) is a lenslet array based integral field spectrograph (IFS) designed to advance the technology readiness of the WFIRST (Wide Field Infrared Survey Telescope)-AFTA (Astrophysics Focused Telescope Assets) high contrast Coronagraph Instrument. We present the end to end optical simulator and plans for the data reduction pipeline (DRP). The optical simulator was created with a combination of the IDL (Interactive Data Language)-based PROPER (optical propagation) library and Zemax (a MatLab script), while the data reduction pipeline is a modified version of the Gemini Planet Imager's (GPI) IDL pipeline. The simulations of the propagation of light through the instrument are based on Fourier transform algorithms. The DRP enables transformation of the PISCES IFS data to calibrated spectral data cubes.

The PISCES (Prototype Imaging Spectrograph for Cor↗

Automated ISS Flight Utilities

During my internship at NASA Johnson Space Center, I worked in the Space Radiation Analysis Group (SRAG), where I was tasked with a number of projects focused on the automation of tasks and activities related to the operation of the International Space Station (ISS). As I worked on a number of projects, I have written short sections below to give a description for each, followed by more general remarks on the internship experience. My first project is titled "General Exposure Representation EVADOSE", also known as "GEnEVADOSE". This project involved the design and development of a C++/ ROOT framework focused on radiation exposure for extravehicular activity (EVA) planning for the ISS. The utility helps mission managers plan EVAs by displaying information on the cumulative radiation doses that crew will receive during an EVA as a function of the egress time and duration of the activity. SRAG uses a utility called EVADOSE, employing a model of the space radiation environment in low Earth orbit to predict these doses, as while outside the ISS the astronauts will have less shielding from charged particles such as electrons and protons. However, EVADOSE output is cumbersome to work with, and prior to GEnEVADOSE, querying data and producing graphs of ISS trajectories and cumulative doses versus egress time required manual work in Microsoft Excel. GEnEVADOSE automates all this work, reading in EVADOSE output file(s) along with a plaintext file input by the user providing input parameters. GEnEVADOSE will output a text file containing all the necessary dosimetry for each proposed EVA egress time, for each specified EVADOSE file. It also plots cumulative dose versus egress time and the ISS trajectory, and displays all of this information in an auto-generated presentation made in LaTeX. New features have also been added, such as best-case scenarios (egress times corresponding to the least dose), interpolated curves for trajectories, and the ability to query any time in the EVADES output. As mentioned above, GEnEVADOSE makes extensive use of ROOT version 6, the data analysis framework developed at the European Organization for Nuclear Research (CERN), and the code is written to the C++11 standard (as are the other projects). My second project is the Automated Mission Reference Exposure Utility (AMREU).Unlike GEnEVADOSE, AMREU is a combination of three frameworks written in both Python and C++, also making use of ROOT (and PyROOT). Run as a combination of daily and weekly cron jobs, these macros query the SRAG database system to determine the active ISS missions, and query minute-by-minute radiation dose information from ISS-TEPC (Tissue Equivalent Proportional Counter), one of the radiation detectors onboard the ISS. Using this information, AMREU creates a corrected data set of daily radiation doses, addressing situations where TEPC may be offline or locked up by correcting doses for days with less than 95% live time (the total amount time the instrument acquires data) by averaging the past 7 days. As not all errors may be automatically detectable, AMREU also allows for manual corrections, checking an updated plaintext file each time it runs. With the corrected data, AMREU generates cumulative dose plots for each mission, and uses a Python script to generate a flight note file (.docx format) containing these plots, as well as information sections to be filled in and modified by the space weather environment officers with information specific to the week. AMREU is set up to run without requiring any user input, and it automatically archives old flight notes and information files for missions that are no longer active. My other projects involve cleaning up a large data set from the Charged Particle Directional Spectrometer (CPDS), joining together many different data sets in order to clean up information in SRAG SQL databases, and developing other automated utilities for displaying information on active solar regions, that may be used by the space weather environment officers to monitor solar activity. I consulted my mentor Dr. Ryan Rios and Dr. Kerry Lee for project requirements and added features, and ROOT developer Edmond Offermann for advice on using the ROOT library. I also received advice and feedback from Dr. Janet Barzilla of SRAG, who tested my code. Besides these inputs, I worked independently, writing all of the code by myself. The code for all these projects is documented throughout, and I have attempted to write it in a modular format. Assuming that ROOT is updated accordingly, these codes are also Y2038-compliant (and Y10K-compliant). This allows the code to be easily referenced, modified and possibly repurposed for non-ISS missions in the future, should the necessary inputs exist. These projects have taught me a lot about coding and software design - I have become a much more skilled C++ programmer and ROOT user, and I also learned to code in Python and PyROOT (and its advantages and disadvantages compared to C++/ ROOT). Furthermore, I have learned about space radiation and radiation modeling, topics that greatly interest me as I pursue a degree in physics. Working alongside experimental physicists like Dr. Rios, I have developed a greater understanding and appreciation for experimental science, something I have always leaned towards but to which I lacked significant exposure. My work in SRAG has also given me the invaluable opportunity to witness the work environment for physicists at NASA, and what a career in academia may look like at a government laboratory such as NASA Johnson Space Center. As I continue my studies and look forward to graduate school and a future career, this experience at NASA has given me a meaningful and enjoyable opportunity to put my skills to use and see what my future career path might hold.

Offermann, Jan Tuzlic↗

DAIDALUS Observations From UAS Integration in the NAS Project Flight Test 4

In order to validate the Unmanned Aerial System (UAS) Detect-and-Avoid (DAA) solution proposed by standards body RTCA Inc., the National Aeronautics and Space Administration (NASA) UAS Integration in the NAS project, alongside industry members General Atomics and Honeywell, conducted the fourth flight test in a series at Armstrong Flight Research Center in Edwards, California. Flight Test 4 (FT4) investigated problems of interoperability with the TCAS collision avoidance system with a DAA system as well as problems associated with sensor uncertainty. A series of scripted flight encounters between the NASA Ikhana UAS and various "intruder" aircraft were flown while alerting and guidance from the DAA algorithm were recorded to investigate the timeliness of the alerts and correctness of the guidance triggered by the DAA system. The results found that alerts were triggered in a timely manner in most instances. Cases where the alerting and guidance was incorrect were investigated further.

Vincent, Michael J.↗

Optimization Routine for Generating Medical Kits for Spaceflight Using the Integrated Medical Model

The Integrated Medical Model (IMM) is a MATLAB model that provides probabilistic assessment of the medical risk associated with human spaceflight missions.Different simulations or profiles can be run in which input conditions regarding both mission characteristics and crew characteristics may vary. For each simulation, the IMM records the total medical events that occur and “treats” each event with resources drawn from import scripts. IMM outputs include Total Medical Events (TME), Crew Health Index (CHI), probability of Evacuation (pEVAC), and probability of Loss of Crew Life (pLOCL).The Crew Health Index is determined by the amount of quality time lost (QTL). Previously, an optimization code was implemented in order to efficiently generate medical kits. The kits were optimized to have the greatest benefit possible, given amass and/or volume constraint. A 6-crew, 14-day lunar mission was chosen for the simulation and run through the IMM for 100,000 trials. A built-in MATLAB solver, mixed-integer linear programming, was used for the optimization routine. Kits were generated in 10% increments ranging from 10%-100% of the benefit constraints. Conditions wheremass alone was minimized, volume alone was minimized, and where mass and volume were minimizedjointly were tested.

Medical Kit↗

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↗