Search NASASearch

SEARCH · Search NASA

Results for “porting flight software”

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.

54 records · Page 3

The New Cloud Absorption Radiometer (CAR) Software: One Model for NASA Remote Sensing Virtual Instruments

The Cloud Absorption Radiometer (CAR) instrument has been the most frequently used airborne instrument built in-house at NASA Goddard Space Flight Center, having flown scientific research missions on-board various aircraft to many locations in the United States, Azores, Brazil, and Kuwait since 1983. The CAR instrument is capable of measuring scattered light by clouds in fourteen spectral bands in UV, visible and near-infrared region. This document describes the control, data acquisition, display, and file storage software for the new version of CAR. This software completely replaces the prior CAR Data System and Control Panel with a compact and robust virtual instrument computer interface. Additionally, the instrument is now usable for the first time for taking data in an off-aircraft mode. The new instrument is controlled via a LabVIEW v5. 1.1-developed software interface that utilizes, (1) serial port writes to write commands to the controller module of the instrument, and (2) serial port reads to acquire data from the controller module of the instrument. Step-by-step operational procedures are provided in this document. A suite of other software programs has been developed to complement the actual CAR virtual instrument. These programs include: (1) a simulator mode that allows pretesting of new features that might be added in the future, as well as demonstrations to CAR customers, and development at times when the instrument/hardware is off-location, and (2) a post-experiment data viewer that can be used to view all segments of individual data cycles and to locate positions where 'start' and stop' byte sequences were incorrectly formulated by the instrument controller. The CAR software described here is expected to be the basis for CAR operation for many missions and many years to come.

Roth, Don J.

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

Development of the ISS EMU SPEEDR

The Self Powered EVA EMU Data Recorder (SPEEDR) is an FPGA (Field-programmable gate array) based device designed to collect high-rate EMU (Extravehicular Mobility Unit) PLSS (Primary Life Support Subsystem) data for download at a later time. The existing EMU PLSS data down-link capability during EVA is one data packet every 2 minutes and is subject to bad packets or loss of signal. High-rate PLSS data is generated by the ECWS (Enhanced Caution and Warning System) but is not normally captured or distributed. Access to high-rate data will increase the capability of EMU anomaly resolution team to pinpoint issues remotely, saving crew time by reducing required call-down Q&A and on-orbit diagnostic activities. With no Shuttle flights post FY11, and potentially limited down-mass capability, the ISS crew and ground support personnel will have to be capable of on-orbit operations to maintain, diagnose, repair, and return to service EMU hardware, possibly through 2028. Collecting high-rate EMU PLSS data during both IVA (Intravehicular Activity) and EVA (Extravehicular Activity) operations will provide trending analysis for life extension and/or predictive performance. The SPEEDR concept has generated interest as a tool/technology that could be used for other ISS subsystems or future exploration-class space suits where hardware reliability/availability is critical and low/variable bandwidth may require "store then forward" methodology. Preliminary work in FY11 produced a functional prototype consisting of an FPGA evaluation board, custom memory/interface circuit board, and custom software. The SPEEDR concept includes a stand-alone battery that is recharged by a computer USB (Universal Serial Bus) port while data is being downloaded.

Bernard. Craig

Clearance Analysis of Node 3 Aft CBM to the Stowed FGB Solar Array

In early 2011, the ISS Vehicle Configuration Office began considering the relocation of the Permanent Multipurpose Module (PMM) to the aft facing Common Berthing Mechanism (CBM) on Node 3 to open a berthing location for visiting vehicles on the Node 1 nadir CBM. In this position, computer-aided design (CAD) models indicated that the aft end of the PMM would be only a few inches from the stowed Functional Cargo Block (FGB) port solar array. To validate the CAD model clearance analysis, in the late summer of 2011 the Image Science and Analysis Group (ISAG) was asked to determine the true geometric relationship between the on-orbit aft facing Node 3 CBM and the FGB port solar array. The desired measurements could be computed easily by photogrammetric analysis if current imagery of the ISS hardware were obtained. Beginning in the fall of 2011, ISAG used the Dynamic Onboard Ubiquitous Graphics (DOUG) program to design a way to acquire imagery of the aft face of Node 3, the aft end-cone of Node 1, the port side of pressurized mating adapter 1 (PMA1), and the port side of the FGB out to the tip of the port solar array using cameras on the Space Station Remote Manipulator System (SSRMS). This was complicated by the need to thread the SSRMS under the truss, past Node 3 and the Cupola, and into the space between the aft side of Node 3 and the FGB solar array to acquire more than 100 images from multiple positions. To minimize the number of SSRMS movements, the Special Purpose Dexterous Manipulator (SPDM) would be attached to the SSRMS. This would make it possible to park the SPDM in one position and acquire multiple images by changing the viewing orientation of the SPDM body cameras using the pan/tilt units on which the cameras are mounted. Using this implementation concept, ISAG identified four SSRMS/SPDM positions from which all of the needed imagery could be acquired. Based on a photogrammetric simulation, it was estimated that the location of the FGB solar array could be measured within an accuracy of about 1 in. in each axis relative to the ISS Analysis Coordinate System (ISSACS). In October 2011, a proposed image-acquisition plan was drafted by ISAG and released for review. The ISS Robotics flight control team (ROBO) proposed minor changes to SPDM positions 1 and 4 to meet ISS proximity requirements. The updated image acquisition plan and draft chit were presented to and approved by the Systems Working Group (SWG) November 18 and were sent to the Vehicle Configuration Board (VCB) in early December 2011. Working with ROBO on 3 successive days (February 21, 22, and 23), ISAG collected 161 images of the ISS. Approximately 40 images were collected from each of the four different SSRMS/SPDM positions, with each set mapping the region from the Node 3 end cone, across Node 1, along the forward port side portion of the FGB, and out the port side FGB solar arrays. From this imagery, the best 80 images were selected for use in the analysis. The images were radiometrically enhanced to improve color and contrast and loaded into the FotoG analysis software along with the camera parameters and control data, which consisted of the coordinates for 54 handrail attachment bolts on the aft face of Node 3, in the ISSACS coordinate system. The results of this analysis produced the measured coordinates of 116 points distributed across the face of the FGB solar array panels (see figure 3) along with propagated uncertainty estimates in each coordinate axis. These results were sent to the ISS Vehicle Configuration Office, which sent them to the Configuration Analysis Modeling and Mass Properties (CAMMP) team for comparison with the Russian-provided CAD model for the retracted FGB solar arrays. The CAMMP analysis unexpectedly showed that the measured location of the port FGB solar array was up to 41-in. further outboard than the design and was slightly twisted about its rotational axis. The unexpected comparison results produced some initial concern regarding the accuracy of the photogrammetric measurements. To verify the measured results, ISAG personnel conducted a second analysis using just the imagery of the solar arrays in an arbitrary coordinate system defined by the three corner points of the inboard-most panel, with the design distance between points A1 and A10 as the only scale. The new measurements agreed with the original results to within less than 1 in. RMS in each axis, confirming the original solar array measurements. ISAG produced a final report for the ISS Vehicle Configuration Office documenting an apparent anomaly in the retracted configuration of the port FGB solar arrays. A copy of the measurement report was translated and sent to the Russian Space Agency. During a Vehicle Integrated Performance and Resources (VIPeR) teleconference September 24, 2012, the Russians acknowledged receipt of a translated copy of the ISAG report. The Russian representative stated that the head of the solar array design team claimed that the measured configuration was impossible unless the structure was physically broken. The Russians acknowledged that they had no expertise in photogrammetry, so the analysis technique employed was a "black box" to them, and they did not know how to use the ISAG results. They asked for a single image in which the overextension of the port solar array could be obviously seen. On November 10, 2012, during a face-to-face meeting with their Russian counterparts at JSC, ISAG presented nadir-view imagery of the FGB acquired during Space Shuttle rendezvous. Using the known width of the pressurized portion of the FGB as a scale, this analysis clearly showed that the port FGB solar array was extended outboard further than the Russian design for the retracted solar array.

Liddle, Donn

Development of the Self-Powered Extravehicular Mobility Unit Extravehicular Activity Data Recorder

The Self-Powered Extravehicular Mobility Unit (EMU) Extravehicular Activity (EVA) Data Recorder (SPEEDR) is a field-programmable gate array (FPGA)-based device designed to collect high-rate EMU Primary Life Support Subsystem (PLSS) data for download at a later time. During EVA, the existing EMU PLSS data downlink capability is one data packet every 2 minutes and is subject to bad packets or loss of signal. Higher-rate PLSS data is generated by the Enhanced Caution and Warning System but is not normally captured or distributed. Access to higher-rate data will increase the capability of EMU anomaly resolution team to pinpoint issues remotely, saving crew time by reducing required call-down Q&A and on-orbit diagnostic activities. With no Space Shuttle flights post Fiscal Year 2011 (FY11), and potentially limited down-mass capability, the ISS crew and ground support personnel will have to be capable of on-orbit operations to maintain, diagnose, repair, and return to service EMU hardware, possibly through 2028. Collecting high-rate EMU PLSS data during both intravehicular activity (IVA) and EVA operations will provide trending analysis for life extension and/or predictive performance. The SPEEDR concept has generated interest as a tool/technology that could be used for other International Space Station subsystems or future exploration-class space suits where hardware reliability/availability is critical and low/variable bandwidth may require store then forward methodology. Preliminary work in FY11 produced a functional prototype consisting of an FPGA evaluation board, custom memory/interface circuit board, and custom software. The SPEEDR concept includes a stand-alone battery that is recharged by a computer Universal Serial Bus (USB) port while data are being downloaded.

Bernard, Craig

Space Operations Learning Center

The Space Operations Learning Center (SOLC) is a tool that provides an online learning environment where students can learn science, technology, engineering, and mathematics (STEM) through a series of training modules. SOLC is also an effective media for NASA to showcase its contributions to the general public. SOLC is a Web-based environment with a learning platform for students to understand STEM through interactive modules in various engineering topics. SOLC is unique in its approach to develop learning materials to teach schoolaged students the basic concepts of space operations. SOLC utilizes the latest Web and software technologies to present this educational content in a fun and engaging way for all grade levels. SOLC uses animations, streaming video, cartoon characters, audio narration, interactive games and more to deliver educational concepts. The Web portal organizes all of these training modules in an easily accessible way for visitors worldwide. SOLC provides multiple training modules on various topics. At the time of this reporting, seven modules have been developed: Space Communication, Flight Dynamics, Information Processing, Mission Operations, Kids Zone 1, Kids Zone 2, and Save The Forest. For the first four modules, each contains three components: Flight Training, Flight License, and Fly It! Kids Zone 1 and 2 include a number of educational videos and games designed specifically for grades K-6. Save The Forest is a space operations mission with four simulations and activities to complete, optimized for new touch screen technology. The Kids Zone 1 module has recently been ported to Facebook to attract wider audience.

Lui, Ben

Port-O-Sim Object Simulation Application

Port-O-Sim is a software application that supports engineering modeling and simulation of launch-range systems and subsystems, as well as the vehicles that operate on them. It is flexible, distributed, object-oriented, and realtime. A scripting language is used to configure an array of simulation objects and link them together. The script is contained in a text file, but executed and controlled using a graphical user interface. A set of modules is defined, each with input variables, output variables, and settings. These engineering models can be either linked to each other or run as standalone. The settings can be modified during execution. Since 2001, this application has been used for pre-mission failure mode training for many Range Safety Scenarios. It contains range asset link analysis, develops look-angle data, supports sky-screen site selection, drives GPS (Global Positioning System) and IMU (Inertial Measurement Unit) simulators, and can support conceptual design efforts for multiple flight programs with its capacity for rapid six-degrees-of-freedom model development. Due to the assembly of various object types into one application, the application is applicable across a wide variety of launch range problem domains.

Lanzi, Raymond J.

Multi-level Simulation of a Real Time Vibration Monitoring System Component

This paper describes the development of a custom built Digital Signal Processing (DSP) printed circuit board designed to implement the Advanced Real Time Vibration Monitoring Subsystem proposed by Marshall Space Flight Center (MSFC) Transportation Directorate in 2000 for the Space Shuttle Main Engine Advanced Health Management System (AHMS). This Real Time Vibration Monitoring System (RTVMS) is being developed for ground use as part of the AHMS Health Management Computer-Integrated Rack Assembly (HMC-IRA). The HMC-IRA RTVMS design contains five DSPs which are highly interconnected through individual communication ports, shared memory, and a unique communication router that allows all the DSPs to receive digitized data fiom two multi-channel analog boards simultaneously. This paper will briefly cover the overall board design but will focus primarily on the state-of-the-art simulation environment within which this board was developed. This 16-layer board with over 1800 components and an additional mezzanine card has been an extremely challenging design. Utilization of a Mentor Graphics simulation environment provided the unique board and system level simulation capability to ascertain any timing or functional concerns before production. By combining VHDL, Synopsys Software and Hardware Models, and the Mentor Design Capture Environment, multiple simulations were developed to verify the RTVMS design. This multi-level simulation allowed the designers to achieve complete operability without error the first time the RTVMS printed circuit board was powered. The HMC-IRA design has completed all engineering and deliverable unit testing. P

Robertson, Bryan A.

The International Space Station Assembly on Schedule

As engineers continue to prepare the International Space Station (ISS) for in-orbit assembly in the year 2002, ANSYS software has proven instrumental in resolving a structural problem in the project's two primary station modules -- Nodes 1 and 2. Proof pressure tests performed in May revealed "low temperature, post-yield creep" in some of the Nodes' gussets, which were designed to reinforce ports for loads from station keeping and reboost motion of the entire space station. An extensive effort was undertaken to characterize the creep behavior of the 2219-T851 aluminum forging material from which the gussets were made. Engineers at Sverdrup Technology, Inc. (Huntsville, AL) were responsible for conducting a combined elastic-plastic-creep analysis of the gussets to determine the amount of residual compressive stress which existed in the gussets following the proof pressure tests, and to determine the stress-strain history in the gussets while on-orbit. Boeing, NASA's Space Station prime contractor, supplied the Finite Element Analysis (FEA) model geometry and developed the creep equations from the experimental data taken by NASA's Marshall Space Flight Center and Langley Research Center. The goal of this effort was to implement the uniaxial creep equations into a three dimensional finite element program, and to determine analytically whether or not the creep was something that the space station program could live with. The objective was to show analytically that either the creep rate was at an acceptable level, or that the node module had to be modified to lower the stress levels to where creep did not occur. The elastic-plastic-creep analysis was performed using the ANSYS finite element program of ANSYS, Inc. (Houston, PA). The analysis revealed that the gussets encountered a compressive stress of approximately 30,000 pounds per square inch (psi) when unloaded. This compressive residual stress significantly lowered the maximum tension stress in the gussets which decreased the creep strain rate. The analysis also showed that the gussets would not experience a great deal of creep from future pressure tests if braces or struts proposed by Boeing were installed to redistribute stress away from them. Subsequent analysis of on-orbit station keeping and reboost loads convinced Boeing that the gussets should be removed altogether.

Source record

Evaluation of the Trajectory Operations Applications Software Task (TOAST)

The Trajectory Operations Applications Software Task (TOAST) is a software development project under the auspices of the Mission Operations Directorate. Its purpose is to provide trajectory operation pre-mission and real-time support for the Space Shuttle program. As an Application Manager, TOAST provides an isolation layer between the underlying Unix operating system and the series of user programs. It provides two main services: a common interface to operating system functions with semantics appropriate for C or FORTRAN, and a structured input and output package that can be utilized by user application programs. In order to evaluate TOAST as an Application Manager, the task was to assess current and planned capabilities, compare capabilities to functions available in commercially-available off the shelf (COTS) and Flight Analysis Design System (FADS) users for TOAST implementation. As a result of the investigation, it was found that the current version of TOAST is well implemented and meets the needs of the real-time users. The plans for migrating TOAST to the X Window System are essentially sound; the Executive will port with minor changes, while Menu Handler will require a total rewrite. A series of recommendations for future TOAST directions are included.

Perkins, Sharon

The Goddard Space Flight Center (GSFC) robotics technology testbed

Much of the technology planned for use in NASA's Flight Telerobotic Servicer (FTS) and the Demonstration Test Flight (DTF) is relatively new and untested. To provide the answers needed to design safe, reliable, and fully functional robotics for flight, NASA/GSFC is developing a robotics technology testbed for research of issues such as zero-g robot control, dual arm teleoperation, simulations, and hierarchical control using a high level programming language. The testbed will be used to investigate these high risk technologies required for the FTS and DTF projects. The robotics technology testbed is centered around the dual arm teleoperation of a pair of 7 degree-of-freedom (DOF) manipulators, each with their own 6-DOF mini-master hand controllers. Several levels of safety are implemented using the control processor, a separate watchdog computer, and other low level features. High speed input/output ports allow the control processor to interface to a simulation workstation: all or part of the testbed hardware can be used in real time dynamic simulation of the testbed operations, allowing a quick and safe means for testing new control strategies. The NASA/National Bureau of Standards Standard Reference Model for Telerobot Control System Architecture (NASREM) hierarchical control scheme, is being used as the reference standard for system design. All software developed for the testbed, excluding some of simulation workstation software, is being developed in Ada. The testbed is being developed in phases. The first phase, which is nearing completion, and highlights future developments is described.

Schnurr, Rick

NASA Tech Briefs, November 2011

The topics include: 1) Flight Test Results from the Rake Airflow Gage Experiment on the F-15B; 2) Telemetry and Science Data Software System; 3) CropEx Web-Based Agricultural Monitoring and Decision Support; 4) High-Performance Data Analysis Tools for Sun-Earth Connection Missions; 5) Experiment in Onboard Synthetic Aperture Radar Data Processing; 6) Microfabrication of a High-Throughput Nanochannel Delivery/Filtration System; 7) Improved Design and Fabrication of Hydrated-Salt Pills; 8) Monolithic Flexure Pre-Stressed Ultrasonic Horns; 9) Cryogenic Quenching Process for Electronic Part Screening; 10) Broadband Via-Less Microwave Crossover Using Microstrip-CPW Transitions; 11) Wheel-Based Ice Sensors for Road Vehicles; 12) G-DYN Multibody Dynamics Engine; 13) Multibody Simulation Software Testbed for Small-Body Exploration and Sampling; 14) Propulsive Reaction Control System Model; 15) Licklider Transmission Protocol Implementation; 16) Core Recursive Hierarchical Image Segmentation; 17) Two-Stage Centrifugal Fan; 18) Combined Structural and Trajectory Control of Variable-Geometry Planetary Entry Systems; 19) Pressure Regulator With Internal Ejector Circulation Pump, Flow and Pressure Measurement Porting, and Fuel Cell System Integration Options; 20) Temperature-Sensitive Coating Sensor Based on Hematite; 21) Standardization of a Volumetric Displacement Measurement for Two-Body Abrasion Scratch Test Data Analysis; 22) Detection of Carbon Monoxide Using Polymer-Carbon Composite Films; 23) Substituted Quaternary Ammonium Salts Improve Low-Temperature Performance of Double-Layer Capacitors; 24) Sustainably Sourced, Thermally Resistant, Radiation Hard Biopolymer; 25) Integrated Lens Antennas for Multi-Pixel Receivers; 26) 180-GHz Interferometric Imager; 27) Maturation of Structural Health Management Systems for Solid Rocket Motors; 28) Validating Phasing and Geometry of Large Focal Plane Arrays; 29) Transverse Pupil Shifts for Adaptive Optics Non-Common Path Calibration; 30) Qualification of Fiber Optic Cables for Martian Extreme Temperature Environments; 31) Solid-State Spectral Light Source System; 32) Multiple-Event, Single-Photon Counting Imaging Sensor; 33) Surface Modeling to Support Small-Body Spacecraft Exploration and Proximity Operations; and 34) Achieving Exact and Constant Turnaround Ratio in a DDS-Based Coherent Transponder.

Source record

Plug-in Plan Tool v3.0.3.1

The role of PLUTO (Plug-in Port UTilization Officer) and the growth of the International Space Station (ISS) have exceeded the capabilities of the current tool PiP (Plug-in Plan). Its users (crew and flight controllers) have expressed an interest in a new, easy-to-use tool with a higher level of interactivity and functionality that is not bound by the limitations of Excel. The PiP Tool assists crewmembers and ground controllers in making real-time decisions concerning the safety and compatibility of hardware plugged into the UOPs (Utility Outlet Panels) onboard the ISS. The PiP Tool also provides a reference to the current configuration of the hardware plugged in to the UOPs, and enables the PLUTO and crew to test Plug-in locations for constraint violations (such as cable connector mismatches or amp limit violations), to see the amps and volts for an end item, to see whether or not the end item uses 1553 data, and the cable length between the outlet and the end item. As new equipment is flown or returned, the database can be updated appropriately as needed. The current tool is a macroheavy Excel spreadsheet with its own database and reporting functionality. The new tool captures the capabilities of the original tool, ports them to new software, defines a new dataset, and compensates for ever-growing unique constraints associated with the Plug-in Plan. New constraints were designed into the tool, and updates to existing constraints were added to provide more flexibility and customizability. In addition, there is an option to associate a "Flag" with each device that will let the user know there is a unique constraint associated with it when they use it. This helps improve the safety and efficiency of real-time calls by limiting the amount of "corporate knowledge" overhead that has to be trained and learned through use. The tool helps save time by automating previous manual processes, such as calculating connector types and deciding which cables are required and in what order.

Andrea-Liner, Kathleen E.

Space Network Devices Developed

The NASA Glenn Research Center through a contract with Spectrum Astro, Inc., has been developing space network hardware as an enabling technology using open systems interconnect (OSI) standards for space-based communications applications. The OSI standard is a well-recognized layered reference model that specifies how data should be sent node to node in a communications network. Because of this research and technology development, a space-qualifiable Ethernet-based network interface card (similar to the type found in a networked personal computer) and the associated four-port hub were designed and developed to flight specifications. During this research and development, there also have been many lessons learned for determining approaches for migrating existing spacecraft architectures to an OSI-network-based platform. Industry has recognized the benefits of targeting hardware developed around OSI standards such as Transmission Control Protocol/Internet Protocol (TCP/IP) or similar protocols for use in future generations of space communication systems. Some of these tangible benefits include overall reductions in mission schedule and cost and in system complexity. This development also brings us a step closer to the realization of a principal investigator on a terrestrial Internet site being able to interact with space platform assets in near real time. To develop this hardware, Spectrum Astro first conducted a technology analysis of alternatives study. For this analysis, they looked at the features of three protocol specifications: Ethernet (IEEE 802.3), Firewire (IEEE 1394), and Spacewire (IEEE 1355). A thorough analysis was performed on the basis of criteria such as current protocol performance and suitability for future space applications. Spectrum Astro also projected future influences such as cost, hardware and software availability, throughput performance, and integration procedures for current and transitive space architectures. After a thorough analysis, Ethernet was chosen because it was seen as the best longer term fit because of the prevalent commercial market; the current and projected availability of hardware, software, and development tools; and the ease of architecture integration.

Jones, Robert E.

Simulation of Non-Acoustic Combustion Instability in a Hybrid Rocket Motor

A transient model of a hybrid motor was formulated to study the cause and elimination of non-acoustic combustion instability. The transient model was used to simulate four key tests out of a series of seventeen hybrid motor tests conducted by Thiokol, Rocketdyne and Martin Marietta at NASA/Marshall Space Flight Center (NASA/MSFC). These tests were performed under the Hybrid Propulsion Technology for Launch Vehicle Boosters (HPTLVB) program. The first test resulted in stable combustion. The second test resulted in large-amplitude, 6.5 Hz chamber pressure oscillations that gradually damped away by the end of the test. The third test resulted in large-amplitude, 7.5 Hz chamber pressure oscillations that were sustained throughout the test. The seventh test resulted in the elimination of combustion instability with the installation of an orifice immediately upstream of the injector. The formulation and implementation of the model are the scope of this presentation. The current model is an independent continuation of modeling presented previously by joint Thiokol-Rocketdyne collaborators Boardman, Hawkins, Wassom, and Claflin. The previous model simulated an unstable IR&D hybrid motor test performed by Thiokol. There was very good agreement between the model and the test data. Like the previous model, the current model was developed using Matrix-x simulation software. However, the tests performed at NASA/MSFC under the HPTLVB program were actually simulated. In the current model, the hybrid motor consisting of the liquid oxygen (LOX) injector, the multi-port solid fuel grain and the nozzle was simulated. Also, simulated in the model was the LOX feed system consisting of the tank, venturi, valve and feed lines. All components of the hybrid motor and LOX feed system are treated by a lumped-parameter approach. Agreement between the results of the transient model and the actual test data was very good. This agreement between simulated and actual test data indicated that the combustion instability in the hybrid motor was due to two causes. The first cause was a LOX feed system of insufficient stiffness. The second cause was a LOX injector with an impedance or pressure drop that was too low to provide damping against the feed system oscillations. Also, it was discovered that testing with a new grain of solid fuel sustained the combustion instability. However, testing with a used grain of solid fuel caused the combustion instability to gradually decay.

Rocker, Marvin

Simulation of Non-Acoustic Combustion Instability in a Hybrid Rocket Motor

A transient model of a hybrid motor was formulated to study the cause and elimination of non-acoustic combustion instability. The transient model was used to simulate four key tests out of a series of seventeen hybrid motor tests conducted by Thiokol, Rocketdyne and Martin Marietta at NASA/Marshall Space Flight Center (NASAIMSFC). These tests were performed under the Hybrid Propulsion Technology for Launch Vehicle Boosters (HPTLVB) program. The first test resulted in stable combustion. The second test resulted in large-amplitude, 6.5 Hz chamber pressure oscillations that gradually damped away by the end of the test. The third test resulted in large-amplitude, 7.5 Hz chamber pressure oscillations that were sustained throughout the test. The seventh test resulted in the elimination of combustion instability with the installation of an orifice immediately upstream of the injector. The formulation and implementation of the model are the scope of this presentation. The current model is an independent continuation of modeling presented previously by joint Thiokol-Rocketdyne collaborators Boardman, Hawkins, Wassom, and Claflin. The previous model simulated an unstable IR&D hybrid motor test performed by Thiokol. There was very good agreement between the model and the test data. Like the previous model, the current model was developed using Matrix-x simulation software. However, the tests performed at NASA/MSFC under the HPTLVB program were actually simulated. In the current model, the hybrid motor consisting of the liquid oxygen (LOX) injector, the multi-port solid fuel grain and the nozzle was simulated. Also, simulated in the model was the LOX feed system consisting of the tank, venturi, valve and feed lines. All components of the hybrid motor and LOX feed system are treated by a lumped-parameter approach. Agreement between the results of the transient model and the actual test data was very good. This agreement between simulated and actual test data indicated that the combustion instability in the hybrid motor was due to two causes. The first cause was a LOX feed system of insufficient stiffness. The second cause was a LOX injector with an impedance or pressure drop that was too low to provide damping against the feed system oscillations. Also, it was discovered that testing with a new grain of solid fuel sustained the combustion instability. However, testing with a used grain of solid fuel caused the combustion instability to gradually decay.

Rocker, Marvin

Virtual Reality Simulation of the International Space Welding Experiment

Virtual Reality (VR) is a set of breakthrough technologies that allow a human being to enter and fully experience a 3-dimensional, computer simulated environment. A true virtual reality experience meets three criteria: (1) It involves 3-dimensional computer graphics; (2) It includes real-time feedback and response to user actions; and (3) It must provide a sense of immersion. Good examples of a virtual reality simulator are the flight simulators used by all branches of the military to train pilots for combat in high performance jet fighters. The fidelity of such simulators is extremely high -- but so is the price tag, typically millions of dollars. Virtual reality teaching and training methods are manifestly effective, and we have therefore implemented a VR trainer for the International Space Welding Experiment. My role in the development of the ISWE trainer consisted of the following: (1) created texture-mapped models of the ISWE's rotating sample drum, technology block, tool stowage assembly, sliding foot restraint, and control panel; (2) developed C code for control panel button selection and rotation of the sample drum; (3) In collaboration with Tim Clark (Antares Virtual Reality Systems), developed a serial interface box for the PC and the SGI Indigo so that external control devices, similar to ones actually used on the ISWE, could be used to control virtual objects in the ISWE simulation; (4) In collaboration with Peter Wang (SFFP) and Mark Blasingame (Boeing), established the interference characteristics of the VIM 1000 head-mounted-display and tested software filters to correct the problem; (5) In collaboration with Peter Wang and Mark Blasingame, established software and procedures for interfacing the VPL DataGlove and the Polhemus 6DOF position sensors to the SGI Indigo serial ports. The majority of the ISWE modeling effort was conducted on a PC-based VR Workstation, described below.

Phillips, James A.

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

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

Flight Control System Design