255,796 research outputs found

    Metamorphoses of ONAV console operations: From prototype to real time application

    Get PDF
    The ONAV (Onboard Navigation) Expert System is being developed as a real time console assistant to the ONAV flight controller for use in the Mission Control Center at the Johnson Space Center. Currently the entry and rendezvous systems are in verification, and the ascent is being prototyped. To arrive at this stage, from a prototype to real world application, the ONAV project has had to deal with not only AI issues but operating environment issues. The AI issues included the maturity of AI languages and the debugging tools, what is verification, and availability, stability, and the size of the expert pool. The environmental issues included real time data acquisition, hardware stability, and how to achieve acceptance by users and management

    A real-time navigation monitoring expert system for the Space Shuttle Mission Control Center

    Get PDF
    The ONAV (Onboard Navigation) Expert System has been developed as a real time console assistant for use by ONAV flight controllers in the Mission Control Center at the Johnson Space Center. This expert knowledge based system is used to monitor the Space Shuttle onboard navigation system, detect faults, and advise flight operations personnel. This application is the first knowledge-based system to use both telemetry and trajectory data from the Mission Operations Computer (MOC). To arrive at this stage, from a prototype to real world application, the ONAV project has had to deal with not only AI issues but operating environment issues. The AI issues included the maturity of AI languages and the debugging tools, verification, and availability, stability and size of the expert pool. The environmental issues included real time data acquisition, hardware suitability, and how to achieve acceptance by users and management

    NASA Johnson Space Center Life Sciences Data System

    Get PDF
    The Life Sciences Project Division (LSPD) at JSC, which manages human life sciences flight experiments for the NASA Life Sciences Division, augmented its Life Sciences Data System (LSDS) in support of the Spacelab Life Sciences-2 (SLS-2) mission, October 1993. The LSDS is a portable ground system supporting Shuttle, Spacelab, and Mir based life sciences experiments. The LSDS supports acquisition, processing, display, and storage of real-time experiment telemetry in a workstation environment. The system may acquire digital or analog data, storing the data in experiment packet format. Data packets from any acquisition source are archived and meta-parameters are derived through the application of mathematical and logical operators. Parameters may be displayed in text and/or graphical form, or output to analog devices. Experiment data packets may be retransmitted through the network interface and database applications may be developed to support virtually any data packet format. The user interface provides menu- and icon-driven program control and the LSDS system can be integrated with other workstations to perform a variety of functions. The generic capabilities, adaptability, and ease of use make the LSDS a cost-effective solution to many experiment data processing requirements. The same system is used for experiment systems functional and integration tests, flight crew training sessions and mission simulations. In addition, the system has provided the infrastructure for the development of the JSC Life Sciences Data Archive System scheduled for completion in December 1994

    Magnetospheric Multiscale Mission (MMS) Phase 2B Navigation Performance

    Get PDF
    The Magnetospheric Multiscale (MMS) formation flying mission, which consists of four spacecraft flying in a tetrahedral formation, has challenging navigation requirements associated with determining and maintaining the relative separations required to meet the science requirements. The baseline navigation concept for MMS is for each spacecraft to independently estimate its position, velocity and clock states using GPS pseudorange data provided by the Goddard Space Flight Center-developed Navigator receiver and maneuver acceleration measurements provided by the spacecraft's attitude control subsystem. State estimation is performed onboard in real-time using the Goddard Enhanced Onboard Navigation System flight software, which is embedded in the Navigator receiver. The current concept of operations for formation maintenance consists of a sequence of two maintenance maneuvers that is performed every 2 weeks. Phase 2b of the MMS mission, in which the spacecraft are in 1.2 x 25 Earth radii orbits with nominal separations at apogee ranging from 30 km to 400 km, has the most challenging navigation requirements because, during this phase, GPS signal acquisition is restricted to less than one day of the 2.8-day orbit. This paper summarizes the results from high-fidelity simulations to determine if the MMS navigation requirements can be met between and immediately following the maintenance maneuver sequence in Phase 2b

    The Fully Automated and Self-Contained Operations Paradigm of the CSIM Mission

    Get PDF
    The Compact Spectral Irradiance Monitor (CSIM) CubeSat Mission has been collecting solar spectral irradiance (SSI) data for over two years, contributing to 40+ years of multi-mission SSI data collection. CSIM utilizes a fully automated and self-contained operations paradigm developed at the Laboratory for Atmospheric and Space Physics (LASP). LASP efficiently performs the entire operations workflow for CSIM, from planning through data processing, which nominally requires only 15 minutes of staffed operations support per week. Mission operations students at LASP are responsible for the entire planning process. They query for ground station contacts and solar observation times which are input into a suite of software tools to create the onboard stored command table and the weekly uplink plan. An automated ground station script then configures for the upcoming CSIM contacts by querying Space-Track for overflights. Within 2 minutes from the start of a pass, the script commands the UHF or S-Band antenna to point at the spacecraft, brings up the command-and-control software, and performs an initial health-and-safety check upon AOS (acquisition of signal). Automated command scripts then configure the spacecraft and upload the plan using command success logic checks. This ensures that all commands are sent and accepted by the spacecraft in-order, and without overwriting any non-expired scheduling slots. The week\u27s worth of commands is loaded within a few passes, and science collection typically starts soon after. Ground automation will detect major anomalies and notify the flight control team in real-time, allowing the operators to recover the spacecraft on the next contact and prepare a new activity plan for autonomous upload. Additionally, ground automation queries CSIM health and safety data and sends telemetry trends to the operations team for daily, weekly, and monthly health and safety checks. CSIM science data is downlinked during 1 or 2 passes per day via the S-band antenna. This data is processed twice per day via an automated data processing pipeline which requires no regular human intervention. The self-contained and automated nature of the data processing pipeline ensures that LASP scientists can access CSIM data within a few hours of being received on the ground. We discuss how this efficient single-mission, self-contained operations paradigm will be expanded to support multiple missions and external customers in the future

    A modular software architecture for UAVs

    Get PDF
    There have been several attempts to create scalable and hardware independent software architectures for Unmanned Aerial Vehicles (UAV). In this work, we propose an onboard architecture for UAVs where hardware abstraction, data storage and communication between modules are efficiently maintained. All processing and software development is done on the UAV while state and mission status of the UAV is monitored from a ground station. The architecture also allows rapid development of mission-specific third party applications on the vehicle with the help of the core module

    America in Space - the First Decade. Linking Man and Spacecraft

    Get PDF
    NASA methods, systems, equipment, and facilities for information transfer between spacecraft and eart

    Galileo early cruise, including Venus, first Earth, and Gaspra encounters

    Get PDF
    This article documents Deep Space Network (DSN) support for the Galileo cruise to Jupiter. The unique trajectory affords multiple encounters during this cruise phase. Each encounter had or will have unique requirements for data acquisition and DSN support configurations. An overview of the cruise and encounters through the asteroid Gaspra encounter is provided

    The ARIEL Instrument Control Unit design for the M4 Mission Selection Review of the ESA's Cosmic Vision Program

    Get PDF
    The Atmospheric Remote-sensing Infrared Exoplanet Large-survey mission (ARIEL) is one of the three present candidates for the ESA M4 (the fourth medium mission) launch opportunity. The proposed Payload will perform a large unbiased spectroscopic survey from space concerning the nature of exoplanets atmospheres and their interiors to determine the key factors affecting the formation and evolution of planetary systems. ARIEL will observe a large number (>500) of warm and hot transiting gas giants, Neptunes and super-Earths around a wide range of host star types, targeting planets hotter than 600 K to take advantage of their well-mixed atmospheres. It will exploit primary and secondary transits spectroscopy in the 1.2-8 um spectral range and broad-band photometry in the optical and Near IR (NIR). The main instrument of the ARIEL Payload is the IR Spectrometer (AIRS) providing low-resolution spectroscopy in two IR channels: Channel 0 (CH0) for the 1.95-3.90 um band and Channel 1 (CH1) for the 3.90-7.80 um range. It is located at the intermediate focal plane of the telescope and common optical system and it hosts two IR sensors and two cold front-end electronics (CFEE) for detectors readout, a well defined process calibrated for the selected target brightness and driven by the Payload's Instrument Control Unit (ICU).Comment: Experimental Astronomy, Special Issue on ARIEL, (2017
    corecore