Search NASA⌕ Search

SEARCH · Search NASA

Results for “software tasks”

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 325 records · Page 18

Development of a preprototype times wastewater recovery subsystem, addendum

Six tasks are described reflecting subsystem hardware and software modifications and test evaluation of a TIMES wastewater recovery subsystem. The overall results are illustrated in a figure which shows the water production rate, the specific energy corrected to 26.5 VDC, and the product water conductivity at various points in the testing. Four tasks are described reflecting studies performed to develop a preliminary design concept for a next generation TIMES. The overall results of the study are the completion of major design analyses and preliminary configuration layout drawings.

Dehner, G. F.↗

Modifying a Commercial Centrifuge to Reduce Electromagnetic Interference and Evaluating Functionality of Ultrasound Equipment

The Project Management and Engineering Branch (SF4) supports the Human Health and Performance Directorate (HH&P) and is responsible for developing and supporting human systems hardware for the International Space Station (ISS). When a principal investigator's (PI) medical research project on the ISS is accepted, SF4 develops the necessary hardware and software to transport to the ISS. The two projects I primarily worked on were the centrifuge and ultrasound projects. Centrifuge: One concern with spacecraft such as the ISS is electromagnetic interference (EMI) from onboard equipment, typically from radio waves (frequencies of ~3 kHz to ~300 GHz), which can negatively affect nearby circuitry. Standard commercial centrifuges produce EMI above safety limits, so my task was to help reduce EMI production from this equipment. Two centrifuges were tested: one unmodified as a control and one modified. To reduce EMI below safety limits, one centrifuge was modified to become a Faraday shield, in which significant electrical contact was made between all regions of the centrifuge housing. This included removing non-conductive paint, applying conductive fabric to the lid and foam sealer, adding a 10,000 μF decoupling capacitor across the power supply, and adding copper adhesive-mount gaskets to the housing interior. EMI testing of both centrifuges was performed in the EMI/EMC Control Test and Measurement Facility. EMI for both centrifuges was below safety limits for frequencies between 10 MHz and 15 GHz (pass); however, between 14 kHz and 10 MHz, EMI for the unmodified centrifuge exceeded safety limits (fail) as expected. Alternatively, for the modified centrifuge with the Faraday shield, EMI was below the safely limit of 55 dBμV/m for electromagnetic frequencies between 14 kHz and 10 MHz. This result indicates our modifications were successful. The successful EMI test allowed us to communicate with the vendor what modifications they needed to make to their commercial unit to meet our specifications and to understand what needs to be done in lab to the new centrifuge. Our modifications will provide a standard for readying centrifuges for future missions. Once the new modified centrifuge arrives by the vendor, it will need to undergo EMI testing again for validation. The centrifuge is also in the process of compatibility testing with a custom stowage drawer, which is an ongoing project in SF4. Both of these items will be payloads on future missions to the ISS for various research purposes. Ultrasound: ISS currently has an onboard ultrasound (Ultrasound 2 system) for research and medical purposes. Every piece of medical flight hardware has an equivalent ground-unit so instrumentation can be routinely evaluated and transported to the ISS if necessary. The ground-unit ultrasound equipment must be evaluated every six months using a task performance sheet (TPS). A TPS is a document, written by the appropriate scientists and engineers, which describes how to run equipment and is written in such a way that astronauts with unspecialized training can follow the tasks. I was responsible for performing six TPSs on a combination of three ultrasounds and two video power converters (VPCs). Performing a TPS involves checking out and computationally documenting each piece of equipment removed from storage locations, setting up hardware and software, performing tasks to verify functionality, returning equipment, and logging items back into the computerized system. My work revealed all ground-unit ultrasounds were functioning properly. Because of proper function, a discrepancy report (DR) did not have to be opened. The TPS was then passed along to the Quality Engineering (QE) for review and ultimately given to Quality Assurance (QA). Other projects: In addition to my main projects, I participated in other tasks including troubleshooting an EEG headband, volunteering for an ultrasound training research study, and conformal coating printed circuit boards. My internship at SF4 has helped me understand how space systems hardware development for the ISS fits into NASA's mission and vision.

Greening, Gage J.↗

Development of Monte Carlo Capability for Orion Parachute Simulations

Parachute test programs employ Monte Carlo simulation techniques to plan testing and make critical decisions related to parachute loads, rate-of-descent, or other parameters. This paper describes the development and use of a MATLAB-based Monte Carlo tool for three parachute drop test simulations currently used by NASA. The Decelerator System Simulation (DSS) is a legacy 6 Degree-of-Freedom (DOF) simulation used to predict parachute loads and descent trajectories. The Decelerator System Simulation Application (DSSA) is a 6-DOF simulation that is well suited for modeling aircraft extraction and descent of pallet-like test vehicles. The Drop Test Vehicle Simulation (DTVSim) is a 2-DOF trajectory simulation that is convenient for quick turn-around analysis tasks. These three tools have significantly different software architectures and do not share common input files or output data structures. Separate Monte Carlo tools were initially developed for each simulation. A recently-developed simulation output structure enables the use of the more sophisticated DSSA Monte Carlo tool with any of the core-simulations. The task of configuring the inputs for the nominal simulation is left to the existing tools. Once the nominal simulation is configured, the Monte Carlo tool perturbs the input set according to dispersion rules created by the analyst. These rules define the statistical distribution and parameters to be applied to each simulation input. Individual dispersed parameters are combined to create a dispersed set of simulation inputs. The Monte Carlo tool repeatedly executes the core-simulation with the dispersed inputs and stores the results for analysis. The analyst may define conditions on one or more output parameters at which to collect data slices. The tool provides a versatile interface for reviewing output of large Monte Carlo data sets while preserving the capability for detailed examination of individual dispersed trajectories. The Monte Carlo tool described in this paper has proven useful in planning several Crew Exploration Vehicle parachute tests.

Moore, James W.↗

X-HAB 2020: AR Field Treks Summary and Conclusions

As part of the FY20 X-Hab Challenge, BLiSS sought to create an Augmented Reality (AR) toolkit to help with analog field trek operations under the supervision of the Solar System Exploration Research Virtual Institute (SSERVI). These treks are operational and technical demonstrations at space-like destinations on Earth to test current extra-vehicular activity (EVA) techniques. While BLiSS as an organization has experience studying operational tasks such as this, it has never developed AR software at this scale. For that reason, another team at the University was brought on to work in parallel. The Collaborative Lab for Advancing Work in Space (CLAWS) is a veteran group of the NASA Spacesuit User Interface Technologies for Students (SUITS) challenge in which Hololens displays for astronauts are created within a year. The operational and technological pairing was ideally suited for tackling this problem. The team divided its responsibilities so that BLiSS would handle the research required to shape the project. As this deliverable had an end user, it was decided that interviewing these field geologists and operations specialists would provide the best insight. These interviews paired with literature review would reveal niche applications for AR that remained within feasible bounds. These science-driven EVAs in unknown terrain require more flexible tools than the current generation of EVA assistants. Rather than focus on sequential instructions, there instead needs to be a broad toolkit that's only called upon in specific instances. This AR Toolkit for Lunar Astronauts and Scientists (ATLAS) became the development goal of the project: create a non-intrusive assembly of tools that could be accessed in AR on the field. The current ATLAS design makes use of a geospatially and temporally annotated eld note system called GeoNotes. This allows for data to be collected and coordinated in a way that's synchronized across time, space, and different users. A Mission Control Center (MCC) and Mobile Support Equipment (MSE) were all needed to transport the AR headset into the field with the user. A network infrastructure was designed and set up within the University to enable this functionality. The software is based on a Protocol-Module structure that allows for modular development of each capability. A Protocol Manager coordinates different protocols that make use of modules. Each module tackles a different individual task while the protocol puts each one to use. The protocol manager coordinates when these are called to be used. This software is hosted on a head-mounted display (HMD) with the MCC acting as support from afar. While the software would be unit-tested at each level and each hardware component verified, a final demonstration would serve to prove the system's capabilities: an analog field trek. The team would prepare to support a user in a remote location from the MCC back at the University. A local area near campus would be tested before going out to do sample field geology further away. This unfortunately became impossible with the arrival of COVID-19. Access to all of the facilities to complete the project as planned were shut down. Our team was scattered across the globe and forced to complete the rest virtually. Adjustments were made to produce a small virtual concept in Adobe XD in the meantime. Even digital surveys were created based on the NASA task-load index (TLX) originally intended for testing actual users. The goal shifted towards completing software and getting feedback on the user interfaces (UI) and user experiences (UX). This team has reformed in response to COVID and its focus has shifted to what can be done remotely. There is still an intention to finish the original deliverable described in this report. The work has been expanded beyond the original X-Hab challenge and has instead become its own research e ort to be continued afterwards. This report collects the processes and knowledge gained from a year of studying and working at this problem with two teams. It should preserve it for the time until the world returns to normal and work can resume. CLAWS will be taking over full responsibility from that point forward, eventually surpassing the original needs of the project. While this document captures the work done towards an eventual end, the CLAWS team has written their own proposal alongside it. It outlines a new future for ATLAS beyond X-Hab, BLiSS, and hopefully beyond COVID-19. This project began as a vague goal hoping to place a new technology into the unique setting of exploration science. The project has since comfortably taken root and will hopefully bloom over the next year.

Alex Sena↗

Eye/Brain/Task Testbed And Software

Eye/brain/task (EBT) testbed records electroencephalograms, movements of eyes, and structures of tasks to provide comprehensive data on neurophysiological experiments. Intended to serve continuing effort to develop means for interactions between human brain waves and computers. Software library associated with testbed provides capabilities to recall collected data, to process data on movements of eyes, to correlate eye-movement data with electroencephalographic data, and to present data graphically. Cognitive processes investigated in ways not previously possible.

Janiszewski, Thomas↗

Comparison of Human Modeling Tools for Efficiency of Prediction of EVA Tasks

Design of ExtraVehicular Activity (EVA) interfaces for International Space Station is important to successful assembly. This is highlighted by the recent rise in the estimate of time required for EVA during the assembly to 900 hours. The traditional method of evaluating EVA design is examination of mockups in neutral buoyancy testing. While effective, this is costly. Any tools for streamlining this process have positive cost and schedule implications for Station design. The human modelling software package Jack has been shown to be a useful tool in computer-aided design of space hardware requiring actuation in EVA. The package has been used to aid in the design of flight hardware for a Station Assembly Mission; evaluation was based on comparison of the computer simulations with neutral buoyancy simulations. When used to predict the feasibility of tasks, the software was found to be effective for reach and visibility evaluation. Some limitations have been encountered in prediction of work clearances. Another human simulator is currently being evaluated using the same hardware and comparisons to the same Neutral Buoyancy simulations. Preliminary results for ERGO, which is derived from robotics software, indicate similar strengths and weaknesses.

Dischinger, H. Charles, Jr.↗

Robot welding process control development task

The completion of, and improvements made to, the software developed during 1990 for program maintenance on the PC and HEURIKON and transfer to the CYRO, and integration of the Rocketdyne vision software with the CYRO is documented. The new programs were used successfully by NASA, Rocketdyne, and UAH technicians and engineers to create, modify, upload, download, and control CYRO NC programs.

Romine, Peter L.↗

Improving and Expanding NASA Software Cost Estimation Methods

Estimators and analysts are increasingly being tasked to develop better models and reliable cost estimates in support of program planning and execution. While there has been extensive work on improving parametric methods for cost estimation, there is very little focus on the use of cost models based on analogy and clustering algorithms. In this paper we summarize the results of our research in developing an analogy method for estimating NASA spacecraft flight software using spectral clustering on system characteristics (symbolic nonnumerical data) and evaluate its performance by comparing it to a number of the most commonly used estimation methods. The strengths and weaknesses of each method based on their performance are also discussed. The paper concludes with an overview of the analogy estimation tool (ASCoT) developed for use within NASA that implements the recommended analogy algorithm.

Hihn, Jairus↗

An investigative study of multispectral data compression for remotely-sensed images using vector quantization and difference-mapped shift-coding

A study is conducted to investigate the effects and advantages of data compression techniques on multispectral imagery data acquired by NASA's airborne scanners at the Stennis Space Center. The first technique used was vector quantization. The vector is defined in the multispectral imagery context as an array of pixels from the same location from each channel. The error obtained in substituting the reconstructed images for the original set is compared for different compression ratios. Also, the eigenvalues of the covariance matrix obtained from the reconstructed data set are compared with the eigenvalues of the original set. The effects of varying the size of the vector codebook on the quality of the compression and on subsequent classification are also presented. The output data from the Vector Quantization algorithm was further compressed by a lossless technique called Difference-mapped Shift-extended Huffman coding. The overall compression for 7 channels of data acquired by the Calibrated Airborne Multispectral Scanner (CAMS), with an RMS error of 15.8 pixels was 195:1 (0.41 bpp) and with an RMS error of 3.6 pixels was 18:1 (.447 bpp). The algorithms were implemented in software and interfaced with the help of dedicated image processing boards to an 80386 PC compatible computer. Modules were developed for the task of image compression and image analysis. Also, supporting software to perform image processing for visual display and interpretation of the compressed/classified images was developed.

Jaggi, S.↗

Application of Lightweight Formal Methods to Software Security

Formal specification and verification of security has proven a challenging task. There is no single method that has proven feasible. Instead, an integrated approach which combines several formal techniques can increase the confidence in the verification of software security properties. Such an approach which species security properties in a library that can be reused by 2 instruments and their methodologies developed for the National Aeronautics and Space Administration (NASA) at the Jet Propulsion Laboratory (JPL) are described herein The Flexible Modeling Framework (FMF) is a model based verijkation instrument that uses Promela and the SPIN model checker. The Property Based Tester (PBT) uses TASPEC and a Text Execution Monitor (TEM). They are used to reduce vulnerabilities and unwanted exposures in software during the development and maintenance life cycles.

security↗

Multidisciplinary Optimization Branch Experience Using iSIGHT Software

The Multidisciplinary Optimization (MDO) Branch at NASA Langley Research Center is investigating frameworks for supporting multidisciplinary analysis and optimization research. An optimization framework call improve the design process while reducing time and costs. A framework provides software and system services to integrate computational tasks and allows the researcher to concentrate more on the application and less on the programming details. A framework also provides a common working environment and a full range of optimization tools, and so increases the productivity of multidisciplinary research teams. Finally, a framework enables staff members to develop applications for use by disciplinary experts in other organizations. Since the release of version 4.0, the MDO Branch has gained experience with the iSIGHT framework developed by Engineous Software, Inc. This paper describes experiences with four aerospace applications: (1) reusable launch vehicle sizing, (2) aerospike nozzle design, (3) low-noise rotorcraft trajectories, and (4) acoustic liner design. All applications have been successfully tested using the iSIGHT framework, except for the aerospike nozzle problem, which is in progress. Brief overviews of each problem are provided. The problem descriptions include the number and type of disciplinary codes, as well as all estimate of the multidisciplinary analysis execution time. In addition, the optimization methods, objective functions, design variables, and design constraints are described for each problem. Discussions on the experience gained and lessons learned are provided for each problem. These discussions include the advantages and disadvantages of using the iSIGHT framework for each case as well as the ease of use of various advanced features. Potential areas of improvement are identified.

Padula, S. L.↗

ISS Operations Cost Reductions Through Automation of Real-Time Planning Tasks

In 2008 the Johnson Space Center s Mission Operations Directorate (MOD) management team challenged their organization to find ways to reduce the costs of International Space station (ISS) console operations in the Mission Control Center (MCC). Each MOD organization was asked to identify projects that would help them attain a goal of a 30% reduction in operating costs by 2012. The MOD Operations and Planning organization responded to this challenge by launching several software automation projects that would allow them to greatly improve ISS console operations and reduce staffing and operating costs. These projects to date have allowed the MOD Operations organization to remove one full time (7 x 24 x 365) ISS console position in 2010; with the plan of eliminating two full time ISS console support positions by 2012. This will account for an overall 10 EP reduction in staffing for the Operations and Planning organization. These automation projects focused on utilizing software to automate many administrative and often repetitive tasks involved with processing ISS planning and daily operations information. This information was exchanged between the ground flight control teams in Houston and around the globe, as well as with the ISS astronaut crew. These tasks ranged from managing mission plan changes from around the globe, to uploading and downloading information to and from the ISS crew, to even more complex tasks that required multiple decision points to process the data, track approvals and deliver it to the correct recipient across network and security boundaries. The software solutions leveraged several different technologies including customized web applications and implementation of industry standard web services architecture between several planning tools; as well as a engaging a previously research level technology (TRL 2-3) developed by Ames Research Center (ARC) that utilized an intelligent agent based system to manage and automate file traffic flow, archiving f data, and generating console logs. This technology called OCAMS (OCA (Orbital Communication System) Management System), is now considered TRL level 9 and is in daily use in the Mission Control Center in support of ISS operations. These solutions have not only allowed for improved efficiency on console; but since many of the previously manual data transfers are now automated, many of the human error prone steps have been removed, and the quality of the planning products has improved tremendously. This has also allowed our Planning Flight Controllers more time to focus on the abstract areas of the job, (like the complexities of planning a mission for 6 international crew members with a global planning team), instead of being burdened with the administrative tasks that took significant time each console shift to process. The resulting automation solutions have allowed the Operations and Planning organization to realize significant cost savings for the ISS program through 2020 and many of these solutions could be a viable

Hall, Timothy A.↗

Developing CORBA-Based Distributed Scientific Applications from Legacy Fortran Programs

Recent progress in distributed object technology has enabled software applications to be developed and deployed easily such that objects or components can work together across the boundaries of the network, different operating systems, and different languages. A distributed object is not necessarily a complete application but rather a reusable, self-contained piece of software that co-operates with other objects in a plug-and-play fashion via a well-defined interface. The Common Object Request Broker Architecture (CORBA), a middleware standard defined by the Object Management Group (OMG), uses the Interface Definition Language (IDL) to specify such an interface for transparent communication between distributed objects. Since IDL can be mapped to any programming language, such as C++, Java, Smalltalk, etc., existing applications can be integrated into a new application and hence the tasks of code re-writing and software maintenance can be reduced. Many scientific applications in aerodynamics and solid mechanics are written in Fortran. Refitting these legacy Fortran codes with CORBA objects can increase the codes reusability. For example, scientists could link their scientific applications to vintage Fortran programs such as Partial Differential Equation(PDE) solvers in a plug-and-play fashion. Unfortunately, CORBA IDL to Fortran mapping has not been proposed and there seems to be no direct method of generating CORBA objects from Fortran without having to resort to manually writing C/C++ wrappers. In this paper, we present an efficient methodology to integrate Fortran legacy programs into a distributed object framework. Issues and strategies regarding the conversion and decomposition of Fortran codes into CORBA objects are discussed. The following diagram shows the conversion and decomposition mechanism we proposed. Our goal is to keep the Fortran codes unmodified. The conversion- aided tool takes the Fortran application program as input and helps programmers generate C/C++ header file and IDL file for wrapping the Fortran code. Programmers need to determine by themselves how to decompose the legacy application into several reusable components based on the cohesion and coupling factors among the functions and subroutines. However, programming effort still can be greatly reduced because function headings and types have been converted to C++ and IDL styles. Most Fortran applications use the COMMON block to facilitate the transfer of large amount of variables among several functions. The COMMON block plays the similar role of global variables used in C. In the CORBA-compliant programming environment, global variables can not be used to pass values between objects. One approach to dealing with this problem is to put the COMMON variables into the parameter list. We do not adopt this approach because it requires modification of the Fortran source code which violates our design consideration. Our approach is to extract the COMMON blocks and convert them into a structure-typed attribute in C++. Through attributes, each component can initialize the variables and return the computation result back to the client. We have tested successfully the proposed conversion methodology based on the f2c converter. Since f2c only translates Fortran to C, we still needed to edit the converted code to meet the C++ and IDL syntax. For example, C++/IDL requires a tag in the structure type, while C does not. In this paper, we identify the necessary changes to the f2c converter in order to directly generate the C++ header and the IDL file. Our future work is to add GUI interface to ease the decomposition task by simply dragging and dropping icons.

Sang, Janche↗

Software forecasting as it is really done: A study of JPL software engineers

This paper presents a summary of the results to date of a Jet Propulsion Laboratory internally funded research task to study the costing process and parameters used by internally recognized software cost estimating experts. Protocol Analysis and Markov process modeling were used to capture software engineer's forecasting mental models. While there is significant variation between the mental models that were studied, it was nevertheless possible to identify a core set of cost forecasting activities, and it was also found that the mental models cluster around three forecasting techniques. Further partitioning of the mental models revealed clustering of activities, that is very suggestive of a forecasting lifecycle. The different forecasting methods identified were based on the use of multiple-decomposition steps or multiple forecasting steps. The multiple forecasting steps involved either forecasting software size or an additional effort forecast. Virtually no subject used risk reduction steps in combination. The results of the analysis include: the identification of a core set of well defined costing activities, a proposed software forecasting life cycle, and the identification of several basic software forecasting mental models. The paper concludes with a discussion of the implications of the results for current individual and institutional practices.

Griesel, Martha Ann↗

High-Performance Data Analysis Tools for Sun-Earth Connection Missions

The data analysis tool of choice for many Sun-Earth Connection missions is the Interactive Data Language (IDL) by ITT VIS. The increasing amount of data produced by these missions and the increasing complexity of image processing algorithms requires access to higher computing power. Parallel computing is a cost-effective way to increase the speed of computation, but algorithms oftentimes have to be modified to take advantage of parallel systems. Enhancing IDL to work on clusters gives scientists access to increased performance in a familiar programming environment. The goal of this project was to enable IDL applications to benefit from both computing clusters as well as graphics processing units (GPUs) for accelerating data analysis tasks. The tool suite developed in this project enables scientists now to solve demanding data analysis problems in IDL that previously required specialized software, and it allows them to be solved orders of magnitude faster than on conventional PCs. The tool suite consists of three components: (1) TaskDL, a software tool that simplifies the creation and management of task farms, collections of tasks that can be processed independently and require only small amounts of data communication; (2) mpiDL, a tool that allows IDL developers to use the Message Passing Interface (MPI) inside IDL for problems that require large amounts of data to be exchanged among multiple processors; and (3) GPULib, a tool that simplifies the use of GPUs as mathematical coprocessors from within IDL. mpiDL is unique in its support for the full MPI standard and its support of a broad range of MPI implementations. GPULib is unique in enabling users to take advantage of an inexpensive piece of hardware, possibly already installed in their computer, and achieve orders of magnitude faster execution time for numerically complex algorithms. TaskDL enables the simple setup and management of task farms on compute clusters. The products developed in this project have the potential to interact, so one can build a cluster of PCs, each equipped with a GPU, and use mpiDL to communicate between the nodes and GPULib to accelerate the computations on each node.

Messmer, Peter↗

A Change Impact Analysis to Characterize Evolving Program Behaviors

Change impact analysis techniques estimate the potential effects of changes made to software. Directed Incremental Symbolic Execution (DiSE) is an intraprocedural technique for characterizing the impact of software changes on program behaviors. DiSE first estimates the impact of the changes on the source code using program slicing techniques, and then uses the impact sets to guide symbolic execution to generate path conditions that characterize impacted program behaviors. DiSE, however, cannot reason about the flow of impact between methods and will fail to generate path conditions for certain impacted program behaviors. In this work, we present iDiSE, an extension to DiSE that performs an interprocedural analysis. iDiSE combines static and dynamic calling context information to efficiently generate impacted program behaviors across calling contexts. Information about impacted program behaviors is useful for testing, verification, and debugging of evolving programs. We present a case-study of our implementation of the iDiSE algorithm to demonstrate its efficiency at computing impacted program behaviors. Traditional notions of coverage are insufficient for characterizing the testing efforts used to validate evolving program behaviors because they do not take into account the impact of changes to the code. In this work we present novel definitions of impacted coverage metrics that are useful for evaluating the testing effort required to test evolving programs. We then describe how the notions of impacted coverage can be used to configure techniques such as DiSE and iDiSE in order to support regression testing related tasks. We also discuss how DiSE and iDiSE can be configured for debugging finding the root cause of errors introduced by changes made to the code. In our empirical evaluation we demonstrate that the configurations of DiSE and iDiSE can be used to support various software maintenance tasks

Rungta, Neha Shyam↗

Thomas Leps Internship Abstract

An optical navigation system is being flown as the backup system to the primary Deep Space Network telemetry for navigation and guidance purposes on Orion. This is required to ensure Orion can recover from a loss of communication, which would simultaneously cause a loss of DSN telemetry. Images taken of the Moon and Earth are used to give range and position information to the navigation computer for trajectory calculations and maneuver execution. To get telemetry data from these images, the size and location of the moon need to be calculated with high accuracy and precision. The reentry envelope for the Orion EM-1 mission requires the centroid and radius of the moon images to be determined within 1/3 of a pixel 3 sigma. In order to ensure this accuracy and precision can be attained, I was tasked with building precise dot grid images for camera calibration as well as building a hardware in the loop test stand for flight software and hardware proofing. To calibrate the Op-Nav camera a dot grid is imaged with the camera, the error between the image dot location and the actual dot location can be used to build a distortion map of the camera and lens system so that images can be fixed to display truth locations. To build the dot grid images I used the Electro Optics Lab optical bench Bright Object Simulator System, and gimbal. The gimbal was slewed to a series of elevations and azimuths. An image of the collimated single point light source was then taken at each position. After a series of 99 images were taken at different locations the single light spots were extracted from each image and added to a composite image containing all 99 points. During the development of these grids it was noticed that an intermittent error in the artificial "star" locations occurred. Prior to the summer this error was attributed to the gimbal having glitches in it's pointing direction and was going to be replaced, however after further examining the issue I determined it to be a software issue. I have since narrowed the likely source of the error down to a Software Development Kit released by the camera supplier PixeLink. I have since developed a workaround in order to build star grids for calibration until the software bug can be isolated and fixed. I was also tasked with building a Hardware in the Loop test stand in order to test the full Op-Nav system. A 4k screen displays simulated Lunar and Terrestrial images from a possible Orion trajectory. These images are then projected through a collimator and then captured with an Op-Nav camera controlled by an Intel NUC computer running flight software. The flight software then analyzes the images to determine attitude and position, this data is then reconstructed into a trajectory and matched to the simulated trajectory in order to determine the accuracy of the attitude and position estimates. In order for the system to work it needs to be precisely and accurately aligned. I developed an alignment procedure that allows the screen, collimator and camera to be squared, centered and collinear with each other within a micron spatially and 5 arcseconds in rotation. I also designed a rigid mount for the screen that was machined on site in Building 10 by another intern. While I was working in the EOL we received a $500k Orion startracker for alignment procedure testing. Due to my prior experience in electronics development, as an ancillary duty, I was tasked with building the cables required to operate and power the startracker. If any errors are made building these cables the startracker would be destroyed, I was honored that the director of the lab entrusted such a critical component with me. This internship has cemented my view on public space exploration. I always preferred public sector to privatization because, as a scientist, the most interesting aspects of space for me are not necessarily the most profitable. I was concerned that the public sector was faltering however, and that in order to improve human space exploration I would be forced into private sector. I now know that, at least at JSC, human spaceflight is still progressing, and exciting work is still being done. I am now actively seeking employment at JSC after I complete my Ph.D and have met with my branch chiefs and mentor to discuss transitioning to a grad Co-op position.

Leps, Thomas↗

A Software Architecture for Semiautonomous Robot Control

A software architecture has been developed to increase the safety and effectiveness with which tasks are performed by robots that are capable of functioning autonomously but sometimes are operated under control by humans. The control system of such a robot designed according to a prior software architecture has no way of taking account of how the environment has changed or what parts of a task were performed during an interval of control by a human, so that errors can occur (and, hence, safety and effectiveness jeopardized) when the human relinquishes control. The present architecture incorporates the control, task-planning, and sensor-based-monitoring features of typical prior autonomous-robot software architectures, plus features for updating information on the environment and planning of tasks during control by a human operator in order to enable the robot to track the actions taken by the operator and to be ready to resume autonomous operation with minimal error. The present architecture also provides a user interface that presents, to the operator, a variety of information on the internal state of the robot and the status of the task.

Kortenkamp, David↗