Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “automatic adaptivity”

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.

514 records · Page 29

Two-Piece Screens for Decontaminating Granular Material

Two-piece screens have been designed specifically for use in filtering a granular material to remove contaminant particles that are significantly wider or longer than are the desired granules. In the original application for which the twopiece screens were conceived, the granular material is ammonium perchlorate and the contaminant particles tend to be wires and other relatively long, rigid strands. The basic design of the twopiece screens can be adapted to other granular materials and contaminants by modifying critical dimensions to accommodate different grain and contaminant- particle sizes. A two-piece screen of this type consists mainly of (1) a top flat plate perforated with circular holes arranged in a hexagonal pattern and (2) a bottom plate that is also perforated with circular holes (but not in a pure hexagonal pattern) and is folded into an accordion structure. Fabrication of the bottom plate begins with drilling circular holes into a flat plate in a hexagonal pattern that is interrupted, at regular intervals, by parallel gaps. The plate is then folded into the accordion structure along the gaps. Because the folds are along the gaps, there are no holes at the peaks and valleys of the accordion screen. The top flat plate and the bottom accordion plate are secured within a metal frame. The resulting two-piece screen is placed at the bottom opening of a feed hopper containing the granular material to be filtered. Tests have shown that such long, rigid contaminant strands as wires readily can pass through a filter consisting of the flat screen alone and that the addition of the accordion screen below the flat screen greatly increases the effectiveness of removal of wires and other contaminant strands. Part of the reason for increased effectiveness is in the presentation of the contaminant to the filter surface. Testing has shown that wire type contamination will readily align itself parallel to the material direction flow. Since this direction of flow is nearly always perpendicular to the filter surface holes, the contamination is automatically aligned to pass through. The two-filter configuration reduces the likelihood that a given contaminant strand will be aligned with the flow of material by eliminating the perpendicular presentation angle. Thus, for wires of a certain diameter, a two-piece screen is 20 percent more effective than is the corresponding flat perforated plate alone, even if the holes in the flat plate are narrower. An accordion screen alone is similarly effective in catching contaminants, but lumps of agglomerated granules of the desired material often collect in the valleys and clog the screen. The addition of a flat screen above the accordion screen prevents clogging of the accordion screen. Flat wire screens have often been used to remove contaminants from granular materials, and are about as effective as are the corresponding perforated flat plates used alone.

Backes, Douglas↗

2007 Research and Engineering Annual Report

Selected research and technology activities at NASA Dryden Flight Research Center are summarized. These following activities exemplify the Center's varied and productive research efforts: Developing a Requirements Development Guide for an Automatic Ground Collision Avoidance System; Digital Terrain Data Compression and Rendering for Automatic Ground Collision Avoidance Systems; Nonlinear Flutter/Limit Cycle Oscillations Prediction Tool; Nonlinear System Identification Using Orthonormal Bases: Application to Aeroelastic/Aeroservoelastic Systems; Critical Aerodynamic Flow Feature Indicators: Towards Application with the Aerostructures Test Wing; Multidisciplinary Design, Analysis, and Optimization Tool Development Using a Genetic Algorithm; Structural Model Tuning Capability in an Object-Oriented Multidisciplinary Design, Analysis, and Optimization Tool; Extension of Ko Straight-Beam Displacement Theory to the Deformed Shape Predictions of Curved Structures; F-15B with Phoenix Missile and Pylon Assembly--Drag Force Estimation; Mass Property Testing of Phoenix Missile Hypersonic Testbed Hardware; ARMD Hypersonics Project Materials and Structures: Testing of Scramjet Thermal Protection System Concepts; High-Temperature Modal Survey of the Ruddervator Subcomponent Test Article; ARMD Hypersonics Project Materials and Structures: C/SiC Ruddervator Subcomponent Test and Analysis Task; Ground Vibration Testing and Model Correlation of the Phoenix Missile Hypersonic Testbed; Phoenix Missile Hypersonic Testbed: Performance Design and Analysis; Crew Exploration Vehicle Launch Abort System-Pad Abort-1 (PA-1) Flight Test; Testing the Orion (Crew Exploration Vehicle) Launch Abort System-Ascent Abort-1 (AA-1) Flight Test; SOFIA Flight-Test Flutter Prediction Methodology; SOFIA Closed-Door Aerodynamic Analyses; SOFIA Handling Qualities Evaluation for Closed-Door Operations; C-17 Support of IRAC Engine Model Development; Current Capabilities and Future Upgrade Plans of the C-17 Data Rack; Intelligent Data Mining Capabilities as Applied to Integrated Vehicle Health Management; STARS Flight Demonstration No. 2 IP Data Formatter; Space-Based Telemetry and Range Safety (STARS) Flight Demonstration No. 2 Range User Flight Test Results; Aerodynamic Effects of the Quiet Spike(tm) on an F-15B Aircraft; F-15 Intelligent Flight Controls-Increased Destabilization Failure; F-15 Integrated Resilient Aircraft Control (IRAC) Improved Adaptive Controller; Aeroelastic Analysis of the Ikhana/Fire Pod System; Ikhana: Western States Fire Missions Utilizing the Ames Research Center Fire Sensor; Ikhana: Fiber-Optic Wing Shape Sensors; Ikhana: ARTS III; SOFIA Closed-Door Flutter Envelope Flight Testing; F-15B Quiet Spike(TM) Aeroservoelastic Flight Test Data Analysis; and UAVSAR Platform Precision Autopilot Flight Results.

Stoliker, Patrick↗

Network-Capable Application Process and Wireless Intelligent Sensors for ISHM

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

Figueroa, Fernando↗

Adaptive Morphological Feature-Based Object Classifier for a Color Imaging System

Utilizing a Compact Color Microscope Imaging System (CCMIS), a unique algorithm has been developed that combines human intelligence along with machine vision techniques to produce an autonomous microscope tool for biomedical, industrial, and space applications. This technique is based on an adaptive, morphological, feature-based mapping function comprising 24 mutually inclusive feature metrics that are used to determine the metrics for complex cell/objects derived from color image analysis. Some of the features include: Area (total numbers of non-background pixels inside and including the perimeter), Bounding Box (smallest rectangle that bounds and object), centerX (x-coordinate of intensity-weighted, center-of-mass of an entire object or multi-object blob), centerY (y-coordinate of intensity-weighted, center-of-mass, of an entire object or multi-object blob), Circumference (a measure of circumference that takes into account whether neighboring pixels are diagonal, which is a longer distance than horizontally or vertically joined pixels), . Elongation (measure of particle elongation given as a number between 0 and 1. If equal to 1, the particle bounding box is square. As the elongation decreases from 1, the particle becomes more elongated), . Ext_vector (extremal vector), . Major Axis (the length of a major axis of a smallest ellipse encompassing an object), . Minor Axis (the length of a minor axis of a smallest ellipse encompassing an object), . Partial (indicates if the particle extends beyond the field of view), . Perimeter Points (points that make up a particle perimeter), . Roundness [(4(pi) x area)/perimeter(squared)) the result is a measure of object roundness, or compactness, given as a value between 0 and 1. The greater the ratio, the rounder the object.], . Thin in center (determines if an object becomes thin in the center, (figure-eight-shaped), . Theta (orientation of the major axis), . Smoothness and color metrics for each component (red, green, blue) the minimum, maximum, average, and standard deviation within the particle are tracked. These metrics can be used for autonomous analysis of color images from a microscope, video camera, or digital, still image. It can also automatically identify tumor morphology of stained images and has been used to detect stained cell phenomena (see figure).

McDowell, Mark↗

Licklider Transmission Protocol Implementation

This software is an implementation of the Licklider Transmission Protocol (LTP), a communications protocol intended to support the Bundle Protocol in Delay-Tolerant Network (DTN) operations. LTP is designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times and/or frequent interruptions in connectivity. Communication in interplanetary space is the most prominent example of this sort of environment, and LTP is principally aimed at supporting long-haul reliable transmission over deep-space RF links. Like any reliable transport service employing ARQ (Automatic Repeat re-Quests), LTP is stateful. In order to assure the reception of a block of data it has sent, LTP must retain for possible retransmission all portions of that block which might not have been received yet. In order to do so, it must keep track of which portions of the block are known to have been received so far, and which are not, together with any additional information needed for purposes of retransmitting part, or all, of the block. Long round-trip times mean substantial delay between the transmission of a block of data and the reception of an acknowledgement from the block s destination, signaling arrival of the block. If LTP postponed transmission of additional blocks of data until it received acknowledgement of the arrival of all prior blocks, valuable opportunities to use what little deep space transmission bandwidth is available would be forever lost. For this reason, LTP is based in part on a notion of massive state retention. Any number of requested transmission conversations (sessions) may be concurrently in flight at various displacements along the link between two LTP engines, and the LTP engines must necessarily retain transmission status and retransmission resources for all of them. Moreover, if any of the data of a given block are lost en route, it will be necessary to retain the state of that transmission during an additional round trip while the lost data are retransmitted; even multiple retransmission cycles may be necessary. LTP's possible multiplicity of sessions per association makes it necessary for each segment of application data to include an additional demultiplexing token: a session ID that uniquely identifies the session in which the segment was issued and, implicitly, the block of data being conveyed by this session. This software comprises a prototype implementation developed by Johns Hopkins University APL in cooperation with JPL, together with adaptations that improve the robustness, correctness, and operability of that implementation.

Burleigh, Scott C.↗

Firmware Architecture of the ARMADAS Bolting Robot

The Automated Reconfigurable Mission Adaptive Digital Assembly Systems (ARMADAS) project, under development at NASA Ames Research Center, has demonstrated on-ground autonomous robotic assembly of extensive digital structures, and it is now moving forward towards in-space demonstration. The ARMADAS system comprises of the operation software, the operation user interface (opsUI), and a swarm of robots. The robotic system consists of a multitude of collaborative agents specifically designed to transport, place and bolt the building blocks, called voxels (volumetric pixels). This paper focuses on the bolting robot, referred to as Mobile Metamaterial Internal Co-Integrator (MMIC-I). MMIC-I is a battery-powered crawling robot. It navigates the structure through extension, contraction and gripping. Two distinct controller boards operate the robot's two symmetric modules, referred to as module A and B. Board A is the master board: it coordinates motion planning and motion primitives execution, hosts the WiFi client, performs periodic self-assessment and system idle check and triggers faults if anomalies are detected. Board B periodically sends a heartbeat to board A, through a wired communication channel that uses the Serial protocol. Additionally, board A's WiFi client receives heartbeat packet requests or motion/bolting commands from a dedicated server board, and acknowledges reception sending back a response heartbeat packet containing information about the overall robot status, e. g. electrical current and voltage values, target and actual angles, operating mode, fault status. Whenever a motion command is sent, the motion planning section of the firmware determines the current robot configuration, using Inertial Measurement Unit readings and the motors Pulse Width Modulation values. Afterwards, it calculates the list of primitives needed to reach the target state, and controls their execution in the proper order. MMIC-I can receive and execute motion and bolting commands only when it is in operational mode. MMIC-I has three operating modes: standby, operational and safed. Standby mode is automatically entered upon startup. While in standby mode, all motors are powered off, and the only accepted commands are the ones relative to a change of mode and heartbeat packet request. Fault detection causes the robot to automatically enter safed or standby mode. Whenever the detected fault occurs within a motion and requires immediate intervention, e. g. an over-current situation, the robot enters safed mode. Safed mode powers off all motors except for the locomotion module, thus preventing the robot from collapsing. Conversely, when the detected fault doesn't require immediate intervention (low battery warning, for instance), the robot enters standby mode after completing the ongoing motion. This paper provides a detailed discussion of MMIC-I's firmware architecture. It accurately describes the implementation approach for each module: sensor data reading, motor control and actuation, WiFi server-client communication, intra-boards Serial communication, operating modes and autonomous fault detection, motion planning, coordination and execution, etc. Moreover, in support of the software description, this paper includes a thorough characterization of MMIC-I's hardware and avionics.

In-space assembly↗

Neural Net Safety Monitor Design

The National Aeronautics and Space Administration (NASA) at the Dryden Flight Research Center (DFRC) has been conducting flight-test research using an F-15 aircraft (figure 1). This aircraft has been specially modified to interface a neural net (NN) controller as part of a single-string Airborne Research Test System (ARTS) computer with the existing quad-redundant flight control system (FCC) shown in figure 2. The NN commands are passed to FCC channels 2 and 4 and are cross channel data linked (CCDL) to the other computers as shown. Numerous types of fault-detection monitors exist in the FCC when the NN mode is engaged; these monitors would cause an automatic disengagement of the NN in the event of a triggering fault. Unfortunately, these monitors still may not prevent a possible NN hard-over command from coming through to the control laws. Therefore, an additional and unique safety monitor was designed for a single-string source that allows authority at maximum actuator rates but protects the pilot and structural loads against excessive g-limits in the case of a NN hard-over command input. This additional monitor resides in the FCCs and is executed before the control laws are computed. This presentation describes a floating limiter (FL) concept1 that was developed and successfully test-flown for this program (figure 3). The FL computes the rate of change of the NN commands that are input to the FCC from the ARTS. A window is created with upper and lower boundaries, which is constantly floating and trying to stay centered as the NN command rates are changing. The limiter works by only allowing the window to move at a much slower rate than those of the NN commands. Anywhere within the window, however, full rates are allowed. If a rate persists in one direction, it will eventually hit the boundary and be rate-limited to the floating limiter rate. When this happens, a persistent counter begins and after a limit is reached, a NN disengage command is generated. The tunable metrics for the FL are (1) window size, (2) drift rate, and (3) persistence counter. Ultimate range limits are also included in case the NN command should drift slowly to a limit value that would cause the FL to be defeated. The FL has proven to work as intended. Both high-g transients and excessive structural loads are controlled with NN hard-over commands. This presentation discusses the FL design features and presents test cases. Simulation runs are included to illustrate the dramatic improvement made to the control of NN hard-over effects. A mission control room display from a flight playback is presented to illustrate the neural net fault display representation. The FL is very adaptable to various requirements and is independent of flight condition. It should be considered as a cost-effective safety monitor to control single-string inputs in general.

Larson, Richard R.↗

Template Matching Approach to Signal Prediction

A new approach to signal prediction and prognostic assessment of spacecraft health resolves an inherent difficulty in fusing sensor data with simulated data. This technique builds upon previous work that demonstrated the importance of physics-based transient models to accurate prediction of signal dynamics and system performance. While models can greatly improve predictive accuracy, they are difficult to apply in general because of variations in model type, accuracy, or intended purpose. However, virtually any flight project will have at least some modeling capability at its disposal, whether a full-blown simulation, partial physics models, dynamic look-up tables, a brassboard analogue system, or simple hand-driven calculation by a team of experts. Many models can be used to develop a predict, or an estimate of the next day s or next cycle s behavior, which is typically used for planning purposes. The fidelity of a predict varies from one project to another, depending on the complexity of the simulation (i.e. linearized or full differential equations) and the level of detail in anticipated system operation, but typically any predict cannot be adapted to changing conditions or adjusted spacecraft command execution. Applying a predict blindly, without adapting the predict to current conditions, produces mixed results at best, primarily due to mismatches between assumed execution of spacecraft activities and actual times of execution. This results in the predict becoming useless during periods of complicated behavior, exactly when the predict would be most valuable. Each spacecraft operation tends to show up as a transient in the data, and if the transients are misaligned, using the predict can actually harm forecasting performance. To address this problem, the approach here expresses the predict in terms of a baseline function superposed with one or more transient functions. These transients serve as signal templates, which can be relocated in time and space against the signal background. One then has the ability to reconstruct a signal regardless of the precise timing of the transients. During operation, one applies the actual start times of spacecraft activities as they occur, and produces a reconstructed, accurate predict in real-time. This general approach is valid under two important conditions. First, the transients themselves must be time-invariant. Second, the transients must be reasonably consistent with respect to different operating points. Both of these assumptions are generally valid, but in the case of a complicated system with numerous types of overlapping transients, this approach may not be effective. Fortunately, there tend to be few transients in spacecraft telemetry of sensor quantities or low-level health and status information because these signals rarely reflect multiple different types of operation. Furthermore, if the predict is at least reasonably close to actual operation, the shift either in time, or in the operating point when the transient occurs - is likely to be small. The proposed approach considers three ways to recognize a transient. The first and most reliable is to use a different signal that identifies operating mode - often the transient will be correlated to a change in operating mode, and this change can usually be detected positively from discrete signals in spacecraft telemetry. If there is no useful mode signal, the second option is to identify the transient template by hand, and detect the onset of the transient using a curve-fitting approach. Finally, if one elects not to choose by hand, there is an option for automatic selection. This technique has been applied to sensor data from several JPL missions and industrial applications, demonstrating an improvement in accurate prediction of future behavior and early detection of system problems. This technique is applicable to practically any time-varying, quantitative sensor measurement.

Mackey, Ryan↗

Automatic Command Sequence Generation

Automatic Sequence Generator (Autogen) Version 3.0 software automatically generates command sequences for the Mars Reconnaissance Orbiter (MRO) and several other JPL spacecraft operated by the multi-mission support team. Autogen uses standard JPL sequencing tools like APGEN, ASP, SEQGEN, and the DOM database to automate the generation of uplink command products, Spacecraft Command Message Format (SCMF) files, and the corresponding ground command products, DSN Keywords Files (DKF). Autogen supports all the major multi-mission mission phases including the cruise, aerobraking, mapping/science, and relay mission phases. Autogen is a Perl script, which functions within the mission operations UNIX environment. It consists of two parts: a set of model files and the autogen Perl script. Autogen encodes the behaviors of the system into a model and encodes algorithms for context sensitive customizations of the modeled behaviors. The model includes knowledge of different mission phases and how the resultant command products must differ for these phases. The executable software portion of Autogen, automates the setup and use of APGEN for constructing a spacecraft activity sequence file (SASF). The setup includes file retrieval through the DOM (Distributed Object Manager), an object database used to store project files. This step retrieves all the needed input files for generating the command products. Depending on the mission phase, Autogen also uses the ASP (Automated Sequence Processor) and SEQGEN to generate the command product sent to the spacecraft. Autogen also provides the means for customizing sequences through the use of configuration files. By automating the majority of the sequencing generation process, Autogen eliminates many sequence generation errors commonly introduced by manually constructing spacecraft command sequences. Through the layering of commands into the sequence by a series of scheduling algorithms, users are able to rapidly and reliably construct the desired uplink command products. With the aid of Autogen, sequences may be produced in a matter of hours instead of weeks, with a significant reduction in the number of people on the sequence team. As a result, the uplink product generation process is significantly streamlined and mission risk is significantly reduced. Autogen is used for operations of MRO, Mars Global Surveyor (MGS), Mars Exploration Rover (MER), Mars Odyssey, and will be used for operations of Phoenix. Autogen Version 3.0 is the operational version of Autogen including the MRO adaptation for the cruise mission phase, and was also used for development of the aerobraking and mapping mission phases for MRO.

Fisher, Forest↗

Evaluation of Crew-Centric Onboard Mission Operations Planning and Execution Tool: Year 2

Currently, mission planning for the International Space Station (ISS) is largely affected by ground operators in mission control. The task of creating a week-long mission plan for ISS crew takes dozens of people multiple days to complete, and is often created far in advance of its execution. As such, re-planning or adapting to changing real-time constraints or emergent issues is similarly taxing. As we design for future mission operations concepts to other planets or areas with limited connectivity to Earth, more of these ground-based tasks will need to be handled autonomously by the crew onboard.There is a need for a highly usable (including low training time) tool that enables efficient self-scheduling and execution within a single package. The ISS Program has identified Playbook as a potential option. It already has high crew acceptance as a plan viewer from previous analogs and can now support a crew self-scheduling assessment on ISS or on another mission. The goals of this work, a collaboration between the Human Research Program and the ISS Program, are to inform the design of systems for more autonomous crew operations and provide a platform for research on crew autonomy for future deep space missions. Our second year of the research effort have included new insights on the crew self-scheduling sessions performed by the crew through use on the HERA (Human Exploration Research Analog) and NEEMO (NASA Extreme Environment Mission Operations) analogs. Use on the NEEMO analog involved two self-scheduling strategies where the crew planned and executed two days of EVAs (Extra-Vehicular Activities). On HERA year two represented the first HERA campaign where we were able to perform research tasks. This involved selected flexible activities that the crew could schedule, mock timelines where the crew completed more complex planning exercises, usability evaluation of the crew self-scheduling features, and more insights into the limit of plan complexity that the crew could effectively self-schedule. In parallel we have added in new features and functionality in the Playbook tool based off of our insights from crew self-scheduling in the NASA analogs. In particular this year we have added in the ability for the crew to add, edit, and remove their own activities in the Playbook tool, expanding the type of planning and re-planning possible in the tool and opening up the ability for more free form plan creation. The ability to group and manipulate groups of activities from the plan task list was also added, allowing crew members to add predefined sets of activities onto their mission timeline. In addition we also added a way for crew members to roll back changes in their plan, in order to allow an undo like capability. These features expand and complement the initial self-scheduling features added in year one with the goal of making crew autonomous planning more efficient. As part of this work we have also finished developing the first version of our Playbook Data Analysis Tool, a research tool built to interpret and analyze the unobtrusively collected data obtained during the NASA analog missions through Playbook. This data which includes user click interaction as well as plan change information, through the Playbook Data Analysis Tool, allows us to playback this information as if a video camera was mounted over the crewmember's tablet. While the primary purpose of this tool is to allow usability analysis of crew self-scheduling sessions used on the NASA analog, since the data collected is structured, the tool can automatically derive metrics that would be traditionally tedious to achieve without manual analysis of video playback. We will demonstrate and discuss the ability for future derived metrics to be added to the tool. In addition to the current data and results gathered in year two we will also discuss the preparation and goals of our International Space Station (ISS) onboard technology demonstration with Playbook. This technology demonstration will be preformed as part of the CAST payload starting in late 2016.

onboard planning↗