Search NASA⌕ Search

SEARCH · Search NASA

Results for “command process”

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 541 records · Page 30
All sourcesNASA NTRSDOE OSTI
NASA NTRS1991

Autonomous reconfigurable GPS/INS navigation and pointing system for rendezvous and docking

The briefing describes work using the Global Positioning System to determine position of spacecraft and the development of computer tools to utilize these position determinations to enable autonomous rendezvous. Using GPS data in conjunction with Inertial Navigation Systems (INS) provides the capability for absolute spacecraft navigation, navigation of one spacecraft relative to another, and attitude determination. Some results presented are based on limited observations, though simulation results are documented. A GPS/INS navigation flight experiment could provide a platform for evaluating approaches for autonomous operation and reconfigurability of the navigation and attitude determination subsystem for future space vehicles. Current emphasis is on the development and demonstration of an Onboard Mission Manager (OMM) and a Multi-Mode Navigation Kalman filter. Sensor data will be handed over to the OMM, which will determine the appropriate response and generate commands for the Kalman filter to use to reconfigure itself. Global Positioning System measurements and INS data will be processed in the integrated navigation filter and used to compute errors in position, velocity, and attitude. Inertial Navigation Systems instrument errors (biases, scale factors, etc.) also can be estimated. The OMM then will use a knowledge base to determine appropriate system response. The GPS is good for missions that have attitude pointing accuracy requirements within the 100 to 200 arcsecond range.

Upadhyay, Triveni M.↗
NASA NTRS1998

End-to-End Data System Architecture for the Space Station Biological Research Project

The Space Station Biological Research Project (SSBRP) Is developing hardware referred to as the "facility" for providing life sciences research capability on the International Space Station. This hardware includes several biological specimen habitats, habitat holding racks, a centrifuge and a glovebox. An SSBRP end to end data system architecture has been developed to allow command and control of the facility from the ground, either with crew assistance or autonomously. The data system will be capable of handling commands, sensor data, and video from multiple cameras. The data will traverse through several onboard and ground networks and processing entities including the SSBRP and Space Station onboard and ground data systems. A large number of onboard and ground (,entities of the data system are being developed by the Space Station Program, other NASA centers and the International Partners. The SSBRP part of the system which includes the habitats, holding racks, and the ground operations center, User Operations Facility (UOF) will be developed by a multitude of geographically distributed development organizations. The SSBRP has the responsibility to define the end to end data and communications systems to make the interfaces manageable and verifiable with multiple contractors with widely varying development constraints and schedules. This paper provides an overview of the SSBRP end-to-end data system. Specifically, it describes the hardware, software and functional interactions of individual systems, and interface requirements among various entities of the end-to-end system.

Mian, Arshad↗
NASA NTRS2006

Modification of a Limbed Robot to Favor Climbing

The figure shows the LEMUR IIb, which is a modified version of the LEMUR II the second generation of the Limbed Excursion Mechanical Utility Robot (LEMUR). Except as described below, the LEMUR IIb hardware is mostly the same as that of the LEMUR II. The IIb and II versions differ in their kinematic configurations and characteristics associated with their kinematic configurations. The differences are such that relative to the LEMUR II, the LEMUR IIb is simpler and is better suited to climbing on inclined surfaces. The first-generation LEMUR, now denoted the LEMUR I, was described in Six-Legged Experimental Robot (NPO-20897), NASA Tech Briefs, Vol. 25, No. 12 (December 2001), page 58. The LEMUR II was described in Second-Generation Six-Limbed Experimental Robot (NPO-35140) NASA Tech Briefs, Vol. 28, No. 11 (November 2004), page 55. To recapitulate: the LEMUR I and LEMUR II were six-legged or sixlimbed robots for demonstrating robotic capabilities for assembly, maintenance, and inspection. They were designed to be capable of walking autonomously along a truss structure toward a mechanical assembly at a prescribed location. They were equipped with stereoscopic video cameras and image-data-processing circuitry for navigation and mechanical operations. They were also equipped with wireless modems, through which they could be commanded remotely. Upon arrival at a mechanical assembly, the LEMUR I would perform simple mechanical operations by use of one or both of its front legs (or in the case of the LEMUR II, any of its limbs could be used to perform mechanical operations). Either LEMUR could also transmit images to a host computer. The differences between the LEMUR IIb and the LEMUR II are the following: Whereas the LEMUR II had six limbs, the LEMUR IIb has four limbs. This change has reduced both the complexity and mass of the legs and of the overall robot. Whereas each limb of the LEMUR II had four degrees of freedom (DOFs), each limb of the LEMUR IIb has three DOFs. This change has also reduced both complexity and mass. Notwithstanding the decrease in the number of DOFs, the three remaining DOFs are configured to provide greater dexterity for motion along a surface. To extend reach, the limbs of the LEMUR IIb are 25 percent longer than those of the LEMUR II. Additional benefits stemming from the modifications are that the robot body supported by the limbs is now less massive and its center of gravity is now closer to the surface along which the robot is to move. These benefits have been obtained without sacrificing load-carrying capacity. Hence, overall, the LEMUR IIb is a more adept climber.

Okon, Avi↗
NASA NTRS2010

Speech Acquisition and Automatic Speech Recognition for Integrated Spacesuit Audio Systems

A voice-command human-machine interface system has been developed for spacesuit extravehicular activity (EVA) missions. A multichannel acoustic signal processing method has been created for distant speech acquisition in noisy and reverberant environments. This technology reduces noise by exploiting differences in the statistical nature of signal (i.e., speech) and noise that exists in the spatial and temporal domains. As a result, the automatic speech recognition (ASR) accuracy can be improved to the level at which crewmembers would find the speech interface useful. The developed speech human/machine interface will enable both crewmember usability and operational efficiency. It can enjoy a fast rate of data/text entry, small overall size, and can be lightweight. In addition, this design will free the hands and eyes of a suited crewmember. The system components and steps include beam forming/multi-channel noise reduction, single-channel noise reduction, speech feature extraction, feature transformation and normalization, feature compression, model adaption, ASR HMM (Hidden Markov Model) training, and ASR decoding. A state-of-the-art phoneme recognizer can obtain an accuracy rate of 65 percent when the training and testing data are free of noise. When it is used in spacesuits, the rate drops to about 33 percent. With the developed microphone array speech-processing technologies, the performance is improved and the phoneme recognition accuracy rate rises to 44 percent. The recognizer can be further improved by combining the microphone array and HMM model adaptation techniques and using speech samples collected from inside spacesuits. In addition, arithmetic complexity models for the major HMMbased ASR components were developed. They can help real-time ASR system designers select proper tasks when in the face of constraints in computational resources.

Huang, Yiteng↗
NASA NTRS2008

Automated and Adaptive Mission Planning for Orbital Express

The Orbital Express space mission was a Defense Advanced Research Projects Agency (DARPA) lead demonstration of on-orbit satellite servicing scenarios, autonomous rendezvous, fluid transfers of hydrazine propellant, and robotic arm transfers of Orbital Replacement Unit (ORU) components. Boeing's Autonomous Space Transport Robotic Operations (ASTRO) vehicle provided the servicing to the Ball Aerospace's Next Generation Serviceable Satellite (NextSat) client. For communication opportunities, operations used the high-bandwidth ground-based Air Force Satellite Control Network (AFSCN) along with the relatively low-bandwidth GEO-Synchronous space-borne Tracking and Data Relay Satellite System (TDRSS) network. Mission operations were conducted out of the RDT&E Support Complex (RSC) at the Kirtland Air Force Base in New Mexico. All mission objectives were met successfully: The first of several autonomous rendezvous was demonstrated on May 5, 2007; autonomous free-flyer capture was demonstrated on June 22, 2007; the fluid and ORU transfers throughout the mission were successful. Planning operations for the mission were conducted by a team of personnel including Flight Directors, who were responsible for verifying the steps and contacts within the procedures, the Rendezvous Planners who would compute the locations and visibilities of the spacecraft, the Scenario Resource Planners (SRPs), who were concerned with assignment of communications windows, monitoring of resources, and sending commands to the ASTRO spacecraft, and the Mission planners who would interface with the real-time operations environment, process planning products and coordinate activities with the SRP. The SRP position was staffed by JPL personnel who used the Automated Scheduling and Planning ENvironment (ASPEN) to model and enforce mission and satellite constraints. The lifecycle of a plan began three weeks outside its execution on-board. During the planning timeframe, many aspects could change the plan, causing the need for re-planning. These variable factors, ranging from shifting contact times to ground-station closures and required maintenance times, are discussed along with the flexibility of the ASPEN tool to accommodate changes to procedures and the daily or long-range plan, which contributed to the success of the mission. This paper will present an introduction to ASPEN, a more in-depth discussion on its use on the Orbital Express mission, and other relative work. A description of ground operations after the SRP deliveries were made is included, and we briefly discuss lessons learned from the planning perspective and future work.

scheduling↗
NASA NTRS2019

Active Flutter Suppression Using Reduced-Order Modeling for Transonic Aeroservoelastic Control Law Development

In this paper, several aerodynamic reduced-order models (ROMs) are generated and coupled with structural models to form aeroelastic ROMs. The aerodynamic ROMs generated here include the effects of control surface motion and are appropriate for use in aeroservoelastic applications. Simple observer-based full-state feedback controllers were designed from these aeroelastic ROMs. Additionally, observer gain matrices were designed from and coupled to the aeroelastic ROMs. Each (linear) observer was then used to estimate the dynamics of a (nonlinear) stand-alone computational fluid-structure dynamics simulation. Then, using the estimated states and the full-state feedback controller, control surface commands were fed back into the computational fluid-structure dynamics simulation to successfully achieve active flutter suppression. The process, as well as some results, are presented in this paper.

Waite, Josiah M.↗
NASA NTRSDate not supplied

GL4U: GeneLab for Colleges and Universities

GeneLab for Colleges and Universities (GL4U) will provide space biology-relevant training in bioinformatics to the next generation of scientists through direct and indirect approaches. The GeneLab (GL) team will host two annual data processing bootcamps, one for college-level students (direct) and one for college educators (indirect – Training of Trainers), in which participants learn to analyze space-relevant omics data hosted on GL. The first bootcamp took place in early June 2021 with about 30 SJSU undergraduate students and covered space biology-specific lectures and hands-on instruction using Jupyter Notebooks (JNs) for RNA sequence (RNAseq) data analysis. All training materials including the enclosed files listed below will be made publicly available on GitHub. RNAseq Bootcamp Lectures (attached in combined file): Introduction to NASA, Space Biology, GeneLab, and the Command Line: NASA_GL_CL_Intro_FINAL.pdf - DRAFT from initial submission NASA_SB_GL_CL_Intro_FULL.pdf - FINAL version presented during the bootcamp - only minor edits from the draft version RNAseq and Data Processing Overview: RNAseq_Overview_FINAL.pdf - DRAFT from initial submission RNAseq_Overview_FULL.pdf - FINAL version presented during the bootcamp - only minor edits from the draft version Overview of the Statistics Used for RNAseq Data Analysis: SJSU_Statistics_Intro_Lecture_FINAL.pdf - DRAFT from initial submission Statistics_Overview_FULL.pdf - FINAL version presented during the bootcamp - only minor edits from the draft version Completed JNs in HTML format (attached in combined file): Unix_Intro_JN_06-2021_completed.html R_Intro_JN_06-2021_completed.html RNAseq_fastq_to_counts_JN_06-2021_completed.html RNAseq_DGE_JN_06-2021_completed.html RNAseq Bootcamp Recordings (attached): GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day1_Part_1_of_5.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day1_Part_2_of_5.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day1_Part_3_of_5.mp4 *There were issues with the part 4 recording so that is not available GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day1_Part_5_of_5.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day2_Part_1_of_3.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day2_Part_2_of_3.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day2_Part_3_of_3.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day3_Part_1_of_4.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day3_Part_2_of_4.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day3_Part_3_of_4.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day3_Part_4_of_4.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day4_Part_1_of_4.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day4_Part_2_of_4.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day4_Part_3_of_4.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day4_Part_4_of_4.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day5_Part_1_of_4.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day5_Part_2_of_4.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day5_Part_3_of_4.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day5_Part_4_of_4.mp4

GeneLab↗
NASA NTRS2010

Adaptive Planning: Understanding Organizational Workload to Capability/ Capacity through Modeling and Simulation

In August 2003, the Secretary of Defense (SECDEF) established the Adaptive Planning (AP) initiative [1] with an objective of reducing the time necessary to develop and revise Combatant Commander (COCOM) contingency plans and increase SECDEF plan visibility. In addition to reducing the traditional plan development timeline from twenty-four months to less than twelve months (with a goal of six months)[2], AP increased plan visibility to Department of Defense (DoD) leadership through In-Progress Reviews (IPRs). The IPR process, as well as the increased number of campaign and contingency plans COCOMs had to develop, increased the workload while the number of planners remained fixed. Several efforts from collaborative planning tools to streamlined processes were initiated to compensate for the increased workload enabling COCOMS to better meet shorter planning timelines. This paper examines the Joint Strategic Capabilities Plan (JSCP) directed contingency planning and staffing requirements assigned to a combatant commander staff through the lens of modeling and simulation. The dynamics of developing a COCOM plan are captured with an ExtendSim [3] simulation. The resulting analysis provides a quantifiable means by which to measure a combatant commander staffs workload associated with development and staffing JSCP [4] directed contingency plans with COCOM capability/capacity. Modeling and simulation bring significant opportunities in measuring the sensitivity of key variables in the assessment of workload to capability/capacity analysis. Gaining an understanding of the relationship between plan complexity, number of plans, planning processes, and number of planners with time required for plan development provides valuable information to DoD leadership. Through modeling and simulation AP leadership can gain greater insight in making key decisions on knowing where to best allocate scarce resources in an effort to meet DoD planning objectives.

Hase, Chris↗
NASA NTRS2001

The Integration of COTS/GOTS within NASA's HST Command and Control System

NASA's mission critical Hubble Space Telescope (HST) command and control system has been re-engineered with COTS/GOTS and minimal custom code. This paper focuses on the design of this new HST Control Center System (CCS) and the lessons learned throughout its development. CCS currently utilizes 31 COTS/GOTS products with an additional 12 million lines of custom glueware code; the new CCS exceeds the capabilities of the original system while significantly reducing the lines of custom code by more than 50%. The lifecycle of COTS/GOTS products will be examined including the pack-age selection process, evaluation process, and integration process. The advantages, disadvantages, issues, concerns, and lessons teamed for integrating COTS/GOTS into the NASA's mission critical HST CCS will be examined in detail. Command and control systems designed with traditional custom code development efforts will be compared with command and control systems designed with new development techniques relying heavily on COTS/COTS integration. This paper will reveal the many hidden costs of COTS/GOTS solutions when compared to traditional custom code development efforts; this paper will show the high cost of COTS/GOTS solutions including training expenses, consulting fees, and long-term maintenance expenses.

Pfarr, Thomas↗
NASA NTRS2006

TRIGA: Telecommunications Protocol Processing Subsystem Using Reconfigurable Interoperable Gate Arrays

We present the Telecommunications protocol processing subsystem using Reconfigurable Interoperable Gate Arrays (TRIGA), a novel approach that unifies fault tolerance, error correction coding and interplanetary communication protocol off-loading to implement CCSDS File Delivery Protocol and Datalink layers. The new reconfigurable architecture offers more than one order of magnitude throughput increase while reducing footprint requirements in memory, command and data handling processor utilization, communication system interconnects and power consumption.

protocol processing hardware engine↗
NASA NTRS1984

Understanding a technical language: A schema-based approach

Workers in many job categories tend to develop technical languages, which are restricted subjects of natural language. A better knowledge of these retrictions provides guidelines for the design of the restricted languages of interactive systems. Accordingly, a technical language used by air-traffic controllers in their communications with pilots was studied. A method of analysis is presented that allows the schemata underlying each category of messages to be identified. This schematic knowledge was implemented in programs, which assume that the goal-oriented aspect of technical languages (and particularly the restricted domain of discourse) limits the processes and the data necessary in order to understand the messages (monosemy, limited vocabulary, evocation of the schemata by some command words, absence of syntax). The programs can interpret, and translate into sequences of action, the messages emitted by the controllers.

Falzon, P.↗
NASA NTRS1986

Evaluation of automated decision making methodologies and development of an integrated robotic system simulation: Study results

The implementation of a generic computer simulation for manipulator systems (ROBSIM) is described. The program is written in FORTRAN, and allows the user to: (1) Interactively define a manipulator system consisting of multiple arms, load objects, targets, and an environment; (2) Request graphic display or replay of manipulator motion; (3) Investigate and simulate various control methods including manual force/torque and active compliance control; and (4) Perform kinematic analysis, requirements analysis, and response simulation of manipulamotion. Previous reports have described the algorithms and procedures for using ROBSIM. These reports are superseded and additional features which were added are described. They are: (1) The ability to define motion profiles and compute loads on a common base to which manipulator arms are attached; (2) Capability to accept data describing manipulator geometry from a Computer Aided Design data base using the Initial Graphics exchange Specification format; (3) A manipulator control algorithm derived from processing the TV image of known reference points on a target; and (4) A vocabulary of simple high level task commands which can be used to define task scenarios.

Haley, D. C.↗
NASA NTRS2000

Adaptive Management of Computing and Network Resources for Spacecraft Systems

It is likely that NASA's future spacecraft systems will consist of distributed processes which will handle dynamically varying workloads in response to perceived scientific events, the spacecraft environment, spacecraft anomalies and user commands. Since all situations and possible uses of sensors cannot be anticipated during pre-deployment phases, an approach for dynamically adapting the allocation of distributed computational and communication resources is needed. To address this, we are evolving the DeSiDeRaTa adaptive resource management approach to enable reconfigurable ground and space information systems. The DeSiDeRaTa approach embodies a set of middleware mechanisms for adapting resource allocations, and a framework for reasoning about the real-time performance of distributed application systems. The framework and middleware will be extended to accommodate (1) the dynamic aspects of intra-constellation network topologies, and (2) the complete real-time path from the instrument to the user. We are developing a ground-based testbed that will enable NASA to perform early evaluation of adaptive resource management techniques without the expense of first deploying them in space. The benefits of the proposed effort are numerous, including the ability to use sensors in new ways not anticipated at design time; the production of information technology that ties the sensor web together; the accommodation of greater numbers of missions with fewer resources; and the opportunity to leverage the DeSiDeRaTa project's expertise, infrastructure and models for adaptive resource management for distributed real-time systems.

Pfarr, Barbara↗
NASA NTRS2009

Telemetry-Enhancing Scripts

Scripts Providing a Cool Kit of Telemetry Enhancing Tools (SPACKLE) is a set of software tools that fill gaps in capabilities of other software used in processing downlinked data in the Mars Exploration Rovers (MER) flight and test-bed operations. SPACKLE tools have helped to accelerate the automatic processing and interpretation of MER mission data, enabling non-experts to understand and/or use MER query and data product command simulation software tools more effectively. SPACKLE has greatly accelerated some operations and provides new capabilities. The tools of SPACKLE are written, variously, in Perl or the C or C++ language. They perform a variety of search and shortcut functions that include the following: Generating text-only, Event Report-annotated, and Web-enhanced views of command sequences; Labeling integer enumerations with their symbolic meanings in text messages and engineering channels; Systematic detecting of corruption within data products; Generating text-only displays of data-product catalogs including downlink status; Validating and labeling of commands related to data products; Performing of convenient searches of detailed engineering data spanning multiple Martian solar days; Generating tables of initial conditions pertaining to engineering, health, and accountability data; Simplified construction and simulation of command sequences; and Fast time format conversions and sorting.

Maimone, Mark W.↗
NASA NTRS2004

Second-Generation Six-Limbed Experimental Robot

The figure shows the LEMUR II - the second generation of the Limbed Excursion Mechanical Utility Robot (LEMUR), which was described in "Six-Legged Experimental Robot" (NPO-20897), NASA Tech Briefs, Vol. 25, No. 12 (December 2001), page 58. The LEMUR II incorporates a number of improvements, including new features, that extend its capabilities beyond those of its predecessor, which is now denoted the LEMUR I. To recapitulate: the LEMUR I was a six-limbed robot for demonstrating robotic capabilities for assembly, maintenance, and inspection. The LEMUR I was designed to be capable of walking autonomously along a truss structure toward a mechanical assembly at a prescribed location and to perform other operations. The LEMUR I was equipped with stereoscopic video cameras and image-data-processing circuitry for navigation and mechanical operations. It was also equipped with a wireless modem, through which it could be commanded remotely. Upon arrival at a mechanical assembly, the LEMUR I would perform simple mechanical operations with one or both of its front limbs. It could also transmit images to a host computer. Each of the six limbs of the LEMUR I was operated independently. Each of the four rear limbs had three degrees of freedom (DOFs), while each of the front two limbs had four DOFs. The front two limbs were designed to hold, operate, and/or be integrated with tools. The LEMUR I included an onboard computer equipped with an assortment of digital control circuits, digital input/output circuits, analog-to-digital converters for input, and digital-to-analog (D/A) converters for output. Feedback from optical encoders in the limb actuators was utilized for closed-loop microcomputer control of the positions and velocities of the actuators. The LEMUR II incorporates the following improvements over the LEMUR I: a) The drive trains for the joints of the LEMUR II are more sophisticated, providing greater torque and accuracy. b) The six limbs are arranged symmetrically about a hexagonal body platform instead of in straight lines along the sides. This symmetrical arrangement is more conducive to omnidirectional movement in a plane. c) The number of degrees of freedom of each of the rear four limbs has been increased by one. Now, every limb has four degrees of freedom: three at the hip (or shoulder, depending on one s perspective) and one at the knee (or elbow, depending on one s perspective). d) Now every limb (instead of only the two front limbs) can perform operations. For this purpose, each limb is tipped with an improved quick-release mechanism for swapping of end-effector tools. e) New end-effector tools have been developed. These include an instrumented rotary driver that accepts all tool bits that have 0.125-in. (3.175-mm)-diameter shanks, a charge-coupled-device video camera, a super bright light-emitting diode for illuminating the work area of the robot, and a generic collet tool that can be quickly and inexpensively modified to accept any cylindrical object up to 0.5 in. (12.7 mm) in diameter. f) The stereoscopic cameras are mounted on a carriage that moves along a circular track, thereby providing for omnidirectional machine vision. g) The control software has been augmented with software that implements innovations reported in two prior NASA Tech Briefs articles: the HIPS algorithm ["Hybrid Image-Plane/Stereo Manipulation" (NPO-30492), Vol. 28, No. 7 (July 2004), page 55] and the CAMPOUT architecture ["An Architecture for Controlling Multiple Robots" (NPO-30345), Vol. 28, No. 10 (October 2004), page 65].

Kennedy, Brett↗
NASA NTRS2013

Orion Scripted Interface Generator (OrionSIG)

The Orion spacecraft undergoing development at NASA and Lockheed Martin aims to launch the first humans to set foot on asteroids and Mars.' Sensors onboard Orion must transmit back to Earth astronomical amounts of data recording almost everything in 50,231 lb. (22,784 kg)2 of spacecraft, down to the temperatures, voltages, or torsions of even the most minor components. This report introduces the new Orion Scripted Interface Generator (OrionSIG) software created by summer 2013 NASA interns Robert Dooling and Samuel Harris. OrionSIG receives a list of Orion variables and produces a script to graph these measurements regardless of their size or type. The program also accepts many other input options to manipulate displays, such as limits on the graph's range or commands to graph different values in a reverse sawtooth wave. OrionSIG paves the way for monitoring stations on Earth to process, display, and test Orion data much more efficiently, a helpful asset in preparation for Orion's first test mission in 2014. Figure I.

Dooling, Robert J.↗
NASA NTRS2013

Integrated Collision Avoidance System for Air Vehicle

Collision with ground/water/terrain and midair obstacles is one of the common causes of severe aircraft accidents. The various data from the coremicro AHRS/INS/GPS Integration Unit, terrain data base, and object detection sensors are processed to produce collision warning audio/visual messages and collision detection and avoidance of terrain and obstacles through generation of guidance commands in a closed-loop system. The vision sensors provide more information for the Integrated System, such as, terrain recognition and ranging of terrain and obstacles, which plays an important role to the improvement of the Integrated Collision Avoidance System.

Lin, Ching-Fang↗
NASA NTRS2016

Euclid Near Infrared Spectro Photometer instrument concept and first test results obtained for different breadboards models at the end of phase C

The Euclid mission objective is to understand why the expansion of the Universe is accelerating through by mapping the geometry of the dark Universe by investigating the distance-redshift relationship and tracing the evolution of cosmic structures. The Euclid project is part of ESA's Cosmic Vision program with its launch planned for 2020 (ref [1]). The NISP (Near Infrared Spectrometer and Photometer) is one of the two Euclid instruments and is operating in the near-IR spectral region (900- 2000nm) as a photometer and spectrometer. The instrument is composed of: - a cold (135K) optomechanical subsystem consisting of a Silicon carbide structure, an optical assembly (corrector and camera lens), a filter wheel mechanism, a grism wheel mechanism, a calibration unit and a thermal control system - a detection subsystem based on a mosaic of 16 HAWAII2RG cooled to 95K with their front-end readout electronic cooled to 140K, integrated on a mechanical focal plane structure made with molybdenum and aluminum. The detection subsystem is mounted on the optomechanical subsystem structure - a warm electronic subsystem (280K) composed of a data processing / detector control unit and of an instrument control unit that interfaces with the spacecraft via a 1553 bus for command and control and via Spacewire links for science data This presentation describes the architecture of the instrument at the end of the phase C (Detailed Design Review), the expected performance, the technological key challenges and preliminary test results obtained for different NISP subsystem breadboards and for the NISP Structural and Thermal model (STM).

Maciaszek, Thierry↗