Search NASA⌕ Search

SEARCH · Search NASA

Results for “Guidance Navigation and Controls Hardware”

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.

140 records · Page 8

Seeker 1.0: Prototype Robotic Free Flying Inspector Mission Overview

Seeker 1.0 is a prototype free flying robot that will one day be capable of inspecting human-rated spacecraft. Building off previous free flyer experience, this technology will eventually improve safety of human spacecraft by offering a variety of inspection capabilities for both routine and emergency scenarios providing increased capability and safety over current inspection methods. Seeker 1.0 is capable of 6 degree of freedom flight via a cold gas propulsion system and can operate up to 1 hour via a semi-autonomous guidance, navigation, and control system. The prototype spacecraft is capable of capturing still images at a variety of resolutions up to 13 MP. The initial test flight utilizes a command and data relay box called Kenobi. Kenobi is a derivative of the Seeker design and will communicate between Cygnus and Seeker and store data for post-mission downlink. Seeker and Kenobi have launched inside a NanoRacks External CubeSat Deployer (NRCSD-E) attached to the NG-11 Cygnus ISS resupply vehicle and will operate after Cygnus departs ISS and moves to a safe altitude. Operations will last approximately 30 minutes and will consist of basic vehicle maneuvers while capturing high-resolution still images. With any remaining time and propellant, Seeker will demonstrate additional safety capabilities and maneuvers required for operations around a crewed spacecraft. The Seeker project utilized the Class IE process that allows for streamlined flight hardware development and increased mission risk tolerance.

Spacecraft Inspection↗

Automated Rendezvous and Capture System Development and Simulation for NASA

The United States does not have an Automated Rendezvous and Capture Docking (AR&C) capability and is reliant on manned control for rendezvous and docking of orbiting spacecraft. T h i s reliance on the labor intensive manned interface for control of rendezvous and docking vehicles has a significant impact on the cost of the operation of the International Space Station (ISS) and precludes the use of any U.S. expendable launch capabilities for Space Station resupply. The Marshall Space Flight Center (MSFC) has conducted pioneering research in the development of an automated rendezvous and capture (or docking) (AR&C) system for U.S. space vehicles. This A M C system was tested extensively using hardware-in-the-loop simulations in the Flight Robotics Laboratory, and a rendezvous sensor, the Video Guidance Sensor was developed and successfully flown on the Space Shuttle on flights STS-87 and STS-95, proving the concept of a video- based sensor. Further developments in sensor technology and vehicle and target configuration have lead to continued improvements and changes in AR&C system development and simulation. A new Advanced Video Guidance Sensor (AVGS) with target will be utilized as the primary navigation sensor on the Demonstration of Autonomous Rendezvous Technologies (DART) flight experiment in 2004. Realtime closed-loop simulations will be performed to validate the improved AR&C systems prior to flight.

Roe, Fred D.↗

An Overview of the Guided Parafoil System Derived from X-38 Experience

The NASA Johnson Space Center built a 4200 sq ft parafoil for the U.S. Army Natick Soldier Center to demonstrate autonomous flight using a guided parafoil system to deliver 10,000 lbs of useable payload. The parafoil's design was based upon that developed during the X-38 program. The drop test payload consisted of a standard 20-foot Type V airdrop platform, a standard 12-foot weight tub, a 60 ft drogue parachute, a 4200 ft2 parafoil, an instrumentation system, and a Guidance, Navigation, and Control (GN&C) system. Instrumentation installed on the load was used to gather data to validate simulation models and preflight loads predictions and to perform post flight trajectory and performance reconstructions. The GN&C system, developed during NASA's X-38 program, consisted of a flight computer, modems for uplink commands and downlink data, a compass, laser altimeter, and two winches. The winches were used to steer the parafoil and to perform the dynamic flare maneuver for a soft landing. The laser was used to initiate the flare. The GN&C software was originally provided to NASA by the European Space Agency. NASA incorporated further software refinements based upon the X-38 flight test results. Three full-scale drop tests were conducted, with the third being performed during the Precision Airdrop Technology Conference and Demonstration (PATCAD) Conference at the U.S. Army Yuma Proving Ground (YPG) in November of 2003. For the PATCAD demonstration, the parafoil and GN&C software and hardware performed well, concluding with a good flare and the smallest miss distance ever experienced in NASA's parafoil drop test program. This paper describes the 4200 sq ft parafoil system, simulation results, and the results of the drop tests.

Stein, Jenny M.↗

Precision Pointing for the Wide-Field Infrared Survey Telescope(WFIRST)

The Wide-Field Infrared Survey Telescope (WFIRST) mission, scheduled for a mid-2020's launch, is currently in its definition phase. The mission is designed to investigate essential questions in the areas of dark energy, exoplanets, and infrared astrophysics. WFIRST will use a 2.4-meter primary telescope (same size as the Hubble Space Telescope's primary mirror) and two instruments: the Wide Field Instrument (WFI) and the Coronagraph Instrument (CGI). In order to address the critical science requirements, the WFIRST mission will conduct large-scale surveys of the infrared sky, requiring both agility and precision pointing (11.6 milli-arcsec stability, 14 milli-arcsec jitter). This paper describes some of the challenges this mission profile presents to the Guidance, Navigation, and Control (GNC) subsystem, and some of the design elements chosen to accommodate those challenges. The high-galactic-latitude survey is characterized by 3-minute observations separated by slews ranging from 0.025 deg to 0.8 deg. The need for observation efficiency drives the slew and settle process to be as rapid as possible. A description of the shaped slew profile chosen to minimize excitation of structural oscillation, and the handoff from star tracker-gyro control to fine guidance sensor control is detailed. Also presented is the fine guidance sensor (FGS), which is integral with the primary instrument (WFI). The FGS is capable of tracking up to 18 guide stars, enabling robust FGS acquisition and precision pointing. To avoid excitation of observatory structural jitter, reaction wheel speeds are operationally maintained within set limits. In addition, the wheel balance law is designed to maintain 1-Hz separation between the wheel speeds to avoid reinforcing jitter excitation at any particular frequency. The wheel balance law and operational implications are described. Finally, the candidate GNC hardware suite needed to meet the requirements of the mission is presented.

Stoneking, Eric T.↗

Sensor Data Quality and Angular Rate Down-Selection Algorithms on SLS EM-1

The NASA Space Launch System Block 1 launch vehicle is equipped with an Inertial Navigation System (INS) and multiple Rate Gyro Assemblies (RGA) that are used in the Guidance, Navigation, and Control (GN&C) algorithms. The INS provides the inertial position, velocity, and attitude of the vehicle along with both angular rate and specific force measurements. Additionally, multiple sets of co-located rate gyros supply angular rate data. The collection of angular rate data, taken along the launch vehicle, is used to separate out vehicle motion from flexible body dynamics. Since the system architecture uses redundant sensors, the capability was developed to evaluate the health (or validity) of the independent measurements. A suite of Sensor Data Quality (SDQ) algorithms is responsible for assessing the angular rate data from the redundant sensors. When failures are detected, SDQ will take the appropriate action and disqualify or remove faulted sensors from forward processing. Additionally, the SDQ algorithms contain logic for down-selecting the angular rate data used by the GNC software from the set of healthy measurements. This paper explores the trades and analyses that were performed in selecting a set of robust fault-detection algorithms included in the GN&C flight software. These trades included both an assessment of hardware-provided health and status data as well as an evaluation of different algorithms based on time-to-detection, type of failures detected, and probability of detecting false positives. We then provide an overview of the algorithms used for both fault-detection and measurement down selection. We next discuss the role of trajectory design, flexible-body models, and vehicle response to off-nominal conditions in setting the detection thresholds. Lastly, we present lessons learned from software integration and hardware-in-the-loop testing.

Park, Thomas↗

Simulation of Mission Phases

This position with the Simulation and Graphics Branch (ER7) at Johnson Space Center (JSC) provided an introduction to vehicle hardware, mission planning, and simulation design. ER7 supports engineering analysis and flight crew training by providing high-fidelity, real-time graphical simulations in the Systems Engineering Simulator (SES) lab. The primary project assigned by NASA mentor and SES lab manager, Meghan Daley, was to develop a graphical simulation of the rendezvous, proximity operations, and docking (RPOD) phases of flight. The simulation is to include a generic crew/cargo transportation vehicle and a target object in low-Earth orbit (LEO). Various capsule, winged, and lifting body vehicles as well as historical RPOD methods were evaluated during the project analysis phase. JSC core mission to support the International Space Station (ISS), Commercial Crew Program (CCP), and Human Space Flight (HSF) influenced the project specifications. The simulation is characterized as a 30 meter +V Bar and/or -R Bar approach to the target object's docking station. The ISS was selected as the target object and the international Low Impact Docking System (iLIDS) was selected as the docking mechanism. The location of the target object's docking station corresponds with the RPOD methods identified. The simulation design focuses on Guidance, Navigation, and Control (GNC) system architecture models with station keeping and telemetry data processing capabilities. The optical and inertial sensors, reaction control system thrusters, and the docking mechanism selected were based on CCP vehicle manufacturer's current and proposed technologies. A significant amount of independent study and tutorial completion was required for this project. Multiple primary source materials were accessed using the NASA Technical Report Server (NTRS) and reference textbooks were borrowed from the JSC Main Library and International Space Station Library. The Trick Simulation Environment and User Training Materials version 2013.0 release was used to complete the Trick tutorial. Multiple network privilege and repository permission requests were required in order to access previous simulation models. The project was also an introduction to computer programming and the Linux operating system. Basic C++ and Python syntax was used during the completion of the Trick tutorial. Trick's engineering analysis and Monte Carlo simulation capabilities were observed and basic space mission planning procedures were applied in the conceptual design phase. Multiple professional development opportunities were completed in addition to project duties during this internship through the System for Administration, Training, and Education Resources for NASA (SATERN). Topics include: JSC Risk Management Workshop, CCP Risk Management, Basic Radiation Safety Training, X-Ray Radiation Safety, Basic Laser Safety, JSC Export Control, ISS RISE Ambassador, Basic SharePoint 2013, Space Nutrition and Biochemistry, and JSC Personal Protective Equipment. Additionally, this internship afforded the opportunity for formal project presentation and public speaking practice. This was my first experience at a NASA center. After completing this internship I have a much clearer understanding of certain aspects of the agency's processes and procedures, as well as a deeper appreciation from spaceflight simulation design and testing. I will continue to improve my technical skills so that I may have another opportunity to return to NASA and Johnson Space Center.

Carlstrom, Nicholas Mercury↗

SCL: An off-the-shelf system for spacecraft control

In this age of shrinking military, civil, and commercial space budgets, an off-the-shelf solution is needed to provide a multimission approach to spacecraft control. A standard operational interface which can be applied to multiple spacecraft allows a common approach to ground and space operations. A trend for many space programs has been to reduce operational staff by applying autonomy to the spacecraft and to the ground stations. The Spacecraft Command Language (SCL) system developed by Interface and Control Systems, Inc. (ICS) provides an off-the-shelf solution for spacecraft operations. The SCL system is designed to provide a hyper-scripting interface which remains standard from program to program. The spacecraft and ground station hardware specifics are isolated to provide the maximum amount of portability from system to system. Uplink and downlink interfaces are also isolated to allow the system to perform independent of the communications protocols chosen. The SCL system can be used for both the ground stations and the spacecraft, or as a value added package for existing ground station environments. The SCL system provides an expanded stored commanding capability as well as a rule-based expert system on-board. The expert system allows reactive control on-board the spacecraft for functions such as electrical power systems (EPS), thermal control, etc. which have traditionally been performed on the ground. The SCL rule and scripting capability share a common syntax allowing control of scripts from rules and rules from scripts. Rather than telemeter over sampled data to the ground, the SCL system maintains a database on-board which is available for interrogation by the scripts and rules. The SCL knowledge base is constructed on the ground and uploaded to the spacecraft. The SCL system follows an open-systems approach allowing other tasks to communicate with SCL on the ground and in space. The SCL system was used on the Clementine program (launched January 25, 1994) and is required to have bidirectional communications with the guidance, navigation, and control (GNC) algorithms which were written as another task. Sequencing of the spacecraft maneuvers are handled by SCL, but the low-level thruster pulse commands are handled by the GNC software. Attitude information is reported back as telemetry, allowing the SCL expert system to inference on the changing data. The Clementine SCL flight software was largely reused from another Naval Center for Space Technology (NCST) satellite program. This paper details the SCL architecture and how an off-the-shelf solution makes sense for multimission spacecraft programs. The Clementine mission will be used as a case study in the application of the SCL to a 'fast track' program. The benefits of such a system in a 'better, cheaper, faster' climate will be discussed.

Buckley, Brian↗

Modeling in the State Flow Environment to Support Launch Vehicle Verification Testing for Mission and Fault Management Algorithms in the NASA Space Launch System

Analysis methods and testing processes are essential activities in the engineering development and verification of the National Aeronautics and Space Administration's (NASA) new Space Launch System (SLS). Central to mission success is reliable verification of the Mission and Fault Management (M&FM) algorithms for the SLS launch vehicle (LV) flight software. This is particularly difficult because M&FM algorithms integrate and operate LV subsystems, which consist of diverse forms of hardware and software themselves, with equally diverse integration from the engineering disciplines of LV subsystems. M&FM operation of SLS requires a changing mix of LV automation. During pre-launch the LV is primarily operated by the Kennedy Space Center (KSC) Ground Systems Development and Operations (GSDO) organization with some LV automation of time-critical functions, and much more autonomous LV operations during ascent that have crucial interactions with the Orion crew capsule, its astronauts, and with mission controllers at the Johnson Space Center. M&FM algorithms must perform all nominal mission commanding via the flight computer to control LV states from pre-launch through disposal and also address failure conditions by initiating autonomous or commanded aborts (crew capsule escape from the failing LV), redundancy management of failing subsystems and components, and safing actions to reduce or prevent threats to ground systems and crew. To address the criticality of the verification testing of these algorithms, the NASA M&FM team has utilized the State Flow environment6 (SFE) with its existing Vehicle Management End-to-End Testbed (VMET) platform which also hosts vendor-supplied physics-based LV subsystem models. The human-derived M&FM algorithms are designed and vetted in Integrated Development Teams composed of design and development disciplines such as Systems Engineering, Flight Software (FSW), Safety and Mission Assurance (S&MA) and major subsystems and vehicle elements such as Main Propulsion Systems (MPS), boosters, avionics, Guidance, Navigation, and Control (GN&C), Thrust Vector Control (TVC), liquid engines, and the astronaut crew office. Since the algorithms are realized using model-based engineering (MBE) methods from a hybrid of the Unified Modeling Language (UML) and Systems Modeling Language (SysML), SFE methods are a natural fit to provide an in depth analysis of the interactive behavior of these algorithms with the SLS LV subsystem models. For this, the M&FM algorithms and the SLS LV subsystem models are modeled using constructs provided by Matlab which also enables modeling of the accompanying interfaces providing greater flexibility for integrated testing and analysis, which helps forecast expected behavior in forward VMET integrated testing activities. In VMET, the M&FM algorithms are prototyped and implemented using the same C++ programming language and similar state machine architectural concepts used by the FSW group. Due to the interactive complexity of the algorithms, VMET testing thus far has verified all the individual M&FM subsystem algorithms with select subsystem vendor models but is steadily progressing to assessing the interactive behavior of these algorithms with LV subsystems, as represented by subsystem models. The novel SFE applications has proven to be useful for quick look analysis into early integrated system behavior and assessment of the M&FM algorithms with the modeled LV subsystems. This early MBE analysis generates vital insight into the integrated system behaviors, algorithm sensitivities, design issues, and has aided in the debugging of the M&FM algorithms well before full testing can begin in more expensive, higher fidelity but more arduous environments such as VMET, FSW testing, and the Systems Integration Lab7 (SIL). SFE has exhibited both expected and unexpected behaviors in nominal and off nominal test cases prior to full VMET testing. In many findings, these behavioral characteristics were used to correct the M&FM algorithms, enable better test coverage, and develop more effective test cases for each of the LV subsystems. This has improved the fidelity of testing and planning for the next generation of M&FM algorithms as the SLS program evolves from non-crewed to crewed flight, impacting subsystem configurations and the M&FM algorithms that control them. SFE analysis has improved robustness and reliability of the M&FM algorithms by revealing implementation errors and documentation inconsistencies. It is also improving planning efficiency for future VMET testing of the M&FM algorithms hosted in the LV flight computers, further reducing risk for the SLS launch infrastructure, the SLS LV, and most importantly the crew.

Trevino, Luis↗

Control Activity in Support of NASA Turbine Based Combined Cycle (TBCC) Research

Control research for a Turbine Based Combined Cycle (TBCC) propulsion system is the current focus of the Hypersonic Guidance, Navigation, and Control (GN&C) discipline team. The ongoing work at the NASA Glenn Research Center (GRC) supports the Hypersonic GN&C effort in developing tools to aid the design of control algorithms to manage a TBCC airbreathing propulsion system during a critical operating period. The critical operating period being addressed in this paper is the span when the propulsion system transitions from one cycle to another, referred to as mode transition. One such tool, that is a basic need for control system design activities, is computational models (hereto forth referred to as models) of the propulsion system. The models of interest for designing and testing controllers are Control Development Models (CDMs) and Control Validation Models (CVMs). CDMs and CVMs are needed for each of the following propulsion system elements: inlet, turbine engine, ram/scram dual-mode combustor, and nozzle. This paper presents an overall architecture for a TBCC propulsion system model that includes all of the propulsion system elements. Efforts are under way, focusing on one of the propulsion system elements, to develop CDMs and CVMs for a TBCC propulsion system inlet. The TBCC inlet aerodynamic design being modeled is that of the Combined-Cycle Engine (CCE) Testbed. The CCE Testbed is a large-scale model of an aerodynamic design that was verified in a small-scale screening experiment. The modeling approach includes employing existing state-of-the-art simulation codes, developing new dynamic simulations, and performing system identification experiments on the hardware in the NASA GRC 10 by10-Foot Supersonic Wind Tunnel. The developed CDMs and CVMs will be available for control studies prior to hardware buildup. The system identification experiments on the CCE Testbed will characterize the necessary dynamics to be represented in CDMs for control design. These system identification models will also be the reference models to validate the CDM and CVM models. Validated models will give value to the tools used to develop the models.

Stueber, Thomas J.↗

A Closed-Loop Hardware Simulation of Decentralized Satellite Formation Control

In recent years, there has been significant interest in the use of formation flying spacecraft for a variety of earth and space science missions. Formation flying may provide smaller and cheaper satellites that, working together, have more capability than larger and more expensive satellites. Several decentralized architectures have been proposed for autonomous establishment and maintenance of satellite formations. In such architectures, each satellite cooperatively maintains the shape of the formation without a central supervisor, and processing only local measurement information. The Global Positioning System (GPS) sensors are ideally suited to provide such local position and velocity measurements to the individual satellites. An investigation of the feasibility of a decentralized approach to satellite formation flying was originally presented by Carpenter. He extended a decentralized linear-quadratic-Gaussian (LQG) framework proposed by Speyer in a fashion similar to an extended Kalman filter (EKE) which processed GPS position fix solutions. The new decentralized LQG architecture was demonstrated in a numerical simulation for a realistic scenario that is similar to missions that have been proposed by NASA and the U.S. Air Force. Another decentralized architecture was proposed by Park et al. using carrier differential-phase GPS (CDGPS). Recently, Busse et al demonstrated the decentralized CDGPS architecture in a hardware-in-the-loop simulation on the Formation Flying TestBed (FFTB) at Goddard Space Flight Center (GSFC), which features two Spirent Cox 16 channel GPS signal generator. Although representing a step forward by utilizing GPS signal simulators for a spacecraft formation flying simulation, only an open-loop performance, in which no maneuvers were executed based on the real-time state estimates, was considered. In this research, hardware experimentation has been extended to include closed-loop integrated guidance and navigation of multiple spacecraft formations using GPS receivers and real-time vehicle telemetry. A hardware closed-loop simulation has been performed using the decentralized LQG architecture proposed by Carpenter in the GPS test facility at the Center for Space Research (CSR). This is the first presentation using this type of hardware for demonstration of closed-loop spacecraft formation flying.

Ebimuma, Takuji↗

Orion Optical Navigation Progress Toward Exploration: Mission 1

Optical navigation of human spacecraft was proposed on Gemini and implemented successfully on Apollo as a means of autonomously operating the vehicle in the event of lost communication with controllers on Earth. It shares a history with the "method of lunar distances" that was used in the 18th century and gained some notoriety after its use by Captain James Cook during his 1768 Pacific voyage of the HMS Endeavor. The Orion emergency return system utilizing optical navigation has matured in design over the last several years, and is currently undergoing the final implementation and test phase in preparation for Exploration Mission 1 (EM-1) in 2019. The software development is being worked as a Government Furnished Equipment (GFE) project delivered as an application within the Core Flight Software of the Orion camera controller module. The mathematical formulation behind the initial ellipse fit in the image processing is detailed in Christian. The non-linear least squares refinement then follows the technique of Mortari as an estimation process of the planetary limb using the sigmoid function. The Orion optical navigation system uses a body fixed camera, a decision that was driven by mass and mechanism constraints. The general concept of operations involves a 2-hour pass once every 24 hours, with passes specifically placed before all maneuvers to supply accurate navigation information to guidance and targeting. The pass lengths are limited by thermal constraints on the vehicle since the OpNav attitude generally deviates from the thermally stable tail-to-sun attitude maintained during the rest of the orbit coast phase. Calibration is scheduled prior to every pass due to the unknown nature of thermal effects on the lens distortion and the mounting platform deformations between the camera and star trackers. The calibration technique is described in detail by Christian, et al. and simultaneously estimates the Brown-Conrady coefficients and the Star Tracker/Camera interlock angles. Accurate attitude information is provided by the star trackers during each pass. Figure 1 shows the various phases of lunar return navigation when the vehicle is in autonomous operation with lost ground communication. The midcourse maneuvers are placed to control the entry interface conditions to the desired corridor for safe landing. The general form of optical navigation on Orion is where still images of the Moon or Earth are processed to find the apparent angular diameter and centroid in the camera focal plane. This raw data is transformed into range and bearing angle measurements using planetary data and precise star tracker inertial attitude. The measurements are then sent to the main flight computer's Kalman filter to update the onboard state vector. The images are, of course, collected over an arc to converge the state and estimate velocity. The same basic technique was used by Apollo to satisfy loss-of-comm, but Apollo used manual crew sightings with a vehicle-integral sextant instead of autonomously processing optical imagery. The software development is past its Critical Design Review, and is progressing through test and certification for human rating. In support of this, a hardware-in-the-loop test rig was developed in the Johnson Space Center Electro-Optics Lab to exercise the OpNav system prior to integrated testing on the Orion vehicle. Figure 2 shows the rig, which the test team has dubbed OCILOT (Orion Camera In the Loop Optical Testbed). Analysis performed to date shows a delivery that satisfies an allowable entry corridor as shown in Figure 3.

Holt, Greg N.↗

Navigation Strategy for the Mars 2001 Lander Mission

The Mars Surveyor Program (MSP) is an ongoing series of missions designed to robotically study, map and search for signs of life on the planet Mars. The MSP 2001 project will advance the effort by sending an orbiter, a lander and a rover to the red planet in the 2001 opportunity. Each vehicle will carry a science payload that will Investigate the Martian environment on both a global and on a local scale. Although this mission will not directly search for signs of life, or cache samples to be returned to Earth, it will demonstrate certain enabling technologies that will be utilized by the future Mars Sample Return missions. One technology that is needed for the Sample Return mission is the capability to place a vehicle on the surface within several kilometers of the targeted landing site. The MSP'01 Lander will take the first major step towards this type of precision landing at Mars. Significant reduction of the landed footprint will be achieved through two technology advances. The first, and most dramatic, is hypersonic aeromaneuvering; the second is improved approach navigation. As a result, the guided entry will produce in a footprint that is only tens of kilometers, which is an order of magnitude improvement over the Pathfinder and Mars Polar Lander ballistic entries. This reduction will significantly enhance scientific return by enabling the potential selection of otherwise unreachable landing sites with unique geologic interest and public appeal. A landed footprint reduction from hundreds to tens of kilometers is also a milestone on the path towards human exploration of Mars, where the desire is to place multiple vehicles within several hundred meters of the planned landing site. Hypersonic aeromaneuvering is an extension of the atmospheric flight goals of the previous landed missions, Pathfinder and Mars Polar Lander (MPL), that utilizes aerodynamic lift and an autonomous guidance algorithm while in the upper atmosphere. The onboard guidance algorithm will control the direction of the lift vector, via bank angle modulation, to keep the vehicle on the desired trajectory. While numerous autonomous guidance algorithms have been developed for use during hypersonic flight at Earth, this will be the first flight of an autonomously directed lifting entry vehicle at Mars. However, without sufficient control and knowledge of the atmospheric entry conditions, the guidance algorithm will not perform effectively. The goal of the interplanetary navigation strategy is to deliver the spacecraft to the desired entry condition with sufficient accuracy and knowledge to enable satisfactory guidance algorithm performance. Specifically, the entry flight path angle must not exceed 0.27 deg. to a 3 sigma confidence level. Entry errors will contribute directly to the size of the landed footprint and the most significant component is entry flight path angle. The size of the entry corridor is limited on the shallow side by integrated heating constraints, and on the steep side by deceleration (g-load) and terminal descent propellant. In order to meet this tight constraint it is necessary to place a targeting maneuver seven hours prior to the time of entry. At this time the trajectory knowledge will be quite accurate, and the effects of maneuver execution errors will be small. The drawback is that entry accuracy is dependent on the success of this final late maneuver. Because propulsive maneuvers are critical events, it is desirable to minimize their occurrence and provide the flight team with as much response time as possible in the event of a spacecraft fault. A mission critical maneuver at Entry - 7 hours does not provide much fault tolerance, and it is desirable to provide a strategy that minimizes reliance on this maneuver. This paper will focus on the Improvements in interplanetary navigation that will decrease entry errors and will reduce the landed footprint, even in the absence of aeromaneuvering. The easiest to take advantage of are Improvements In the knowledge of the Mars ephemeris and gravity field due to the MGS and MSP'98 missions. Improvements In data collection and reduction techniques such as "precislon ranging' and near-simultaneous tracking will also be utilized. In addition to precise trajectory control, a robust strategy for communications and flight operations must also be demonstrated. The result Is a navigation and communications strategy on approach that utilizes optimal maneuver placement to take advantage of trajectory knowledge, minimizes risk for the flight operations team, is responsive to spacecraft hardware limitations, and achieves the entry corridor. The MSP2001 mission Is managed at JPL under the auspices of the Mars Exploration Directorate. The spacecraft flight elements are built and managed by Lockheed-Martin Astronautics in Denver, Colorado.

Mase, Robert A.↗

Thomas Leps Internship Abstract

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

Leps, Thomas↗

Solar Dynamics Observatory Guidance, Navigation, and Control System Overview

The Solar Dynamics Observatory (SDO) was designed and built at the Goddard Space Flight Center, launched from Cape Canaveral on February 11, 2010, and reached its final geosynchronous science orbit on March 16, 2010. The purpose of SDO is to observe the Sun and continuously relay data to a dedicated ground station. SDO remains Sun-pointing throughout most of its mission for the instruments to take measurements of the Sun. The SDO attitude control system (ACS) is a single-fault tolerant design. Its fully redundant attitude sensor complement includes sixteen coarse Sun sensors (CSSs), a digital Sun sensor (DSS), three two-axis inertial reference units (IRUs), and two star trackers (STs). The ACS also makes use of the four guide telescopes included as a part of one of the science instruments. Attitude actuation is performed using four reaction wheels assemblies (RWAs) and eight thrusters, with a single main engine used to provide velocity-change thrust for orbit raising. The attitude control software has five nominal control modes, three wheel-based modes and two thruster-based modes. A wheel-based Safehold running in the attitude control electronics box improves the robustness of the system as a whole. All six modes are designed on the same basic proportional-integral-derivative attitude error structure, with more robust modes setting their integral gains to zero. This paper details the final overall design of the SDO guidance, navigation, and control (GN&C) system and how it was used in practice during SDO launch, commissioning, and nominal operations. This overview will include the ACS control modes, attitude determination and sensor calibration, the high gain antenna (HGA) calibration, and jitter mitigation operation. The Solar Dynamics Observatory mission is part of the NASA Living With a Star program, which seeks to understand the changing Sun and its effects on the Solar System, life, and society. To this end, the SDO spacecraft carries three Sun-observing instruments: Helioseismic and Magnetic Imager (HMI), led by Stanford University; Atmospheric Imaging Assembly (AIA), led by Lockheed Martin Space and Astrophysics Laboratory; and Extreme Ultraviolet Variability Experiment (EVE), led by the University of Colorado. The basic mission is to observe the Sun for a very high percentage of the 5-year mission (10-year goal) with long stretches of uninterrupted observations and with constant, high-data-rate transmission to a dedicated ground station to be located in White Sands, New Mexico. These goals guided the design of the spacecraft bus that will carry and service the three-instrument payload. Overarching design goals for the bus are geosynchronous orbit, near-constant Sun observations with the ability to fly through eclipses, and constant HGA contact with the dedicated ground station. A three-axis stabilized ACS is needed both to point at the Sun accurately and to keep the roll about the Sun vector correctly positioned with respect to the solar north pole. This roll control is especially important for the magnetic field imaging of HM I. The mission requirements have several general impacts on the ACS design. Both the AIA and HMI instruments are very sensitive to the blurring caused by jitter. Each has an image stabilization system (ISS) with some ability to filter out high frequency motion, but below the bandwidth of the ISS the control system must compensate for disturbances within the ACS bandwidth or avoid exciting jitter at higher frequencies. Within the ACS bandwidth, the control requirement imposed by AIA is to place the center of the solar disk no more than 2 arc sec, 3 , from a body-defined target based on one of the GTs that accompany the instrument. This body-defined target, called the science reference boresight (SRB), was determined from the postlaunch orientation of the GTs by averaging the bounding telescope boresights for pitch to get a pitch SRB coordinate, and by averaging the bounding boresights for yaw toet the yaw SRB coordinate. The location of this SRB in the 0.5-deg field-of-view for each GT then becomes the central target for each telescope; one GT is selected for use as the ACS controlling guide telescope (CGT) at any given time. Fine Sun-pointing is effected based on this SRB for all three instruments when the Sun is within the linear range of the CGT. In addition to limiting jitter, HMI science requires averaging several observations, making the instrument sensitive to low frequency motion that induces differential motion between each observation. This requires the spacecraft attitude to be stable about the roll axis to approximately 10 arcsec over a ten-minute period. Instrument calibrations require that the spacecraft point the SRB up to 2.5 degrees in pitch and yaw away from the center of the Sun, placing the Sun outside the field-of-view of the guide telescopes. In such instances, when the GTs cannot provide the definitive target for the ACS, on-board attitude determination combined with ephemeris prediction of the Sun direction must provide the definitive target. EVE is capable of observing the Sun with less dependence on attitude control. However, the ground data processing needs for calibrations result in the most strict attitude knowledge requirements for the mission: [35,70,70] arcsec, 3 , of knowledge with respect to the center of the solar disk. In addition to driving the ACS sensor selection, the knowledge requirements, which have their effect primarily during Inertial mode calibrations, drive the accuracy requirements for the solar ephemeris. The need to achieve and maintain geosynchronous orbit (GEO) drove the need for high-efficiency propulsive systems and appropriate attitude control. The main engine provided high specific impulse for the maneuvers to attain GEO, while the smaller ACS thrusters managed the disturbance torques of the larger engine and provided the capability for much smaller adjustment burns on orbit. SDO s large solar profile means that solar radiation pressure is a large torque disturbance, and the momentum buildup from this disturbance and the GEO altitude drives the ACS to use thrusters to manage vehicle momentum. The demanding data capture budget for the mission, however, requires SDO to avoid frequent thruster maneuvers, while concerns about on-orbit jitter restrict the maximum desired wheel speeds desired from the RWAs. The plan for on-orbit wheel speed and momentum management will be discussed as well as what is now being done in operation after the jitter environment was characterized. The SDO ACS hardware complement is single-fault tolerant. Two main processors carry virtually identical copies of the command and data handling and ACS software, and two identical attitude control electronics (ACE) boxes carry Coldfire processors with contingency ACS software and other hardware interface cards; the ACE structure allows reaction wheels to be commanded by the Sun-pointing Safehold independent of the Mil Std 1553 data bus. The sixteen Adcole CSSs are grouped into primary and backup sets of eight sensors, each set providing the ability to calculate a sun vector. Each set of eight eyes provides full 4 -steradian coverage. The Adcole DSS comprises an optics head and a separate electronics box providing a 1553 data interface. The electronics box is mounted inside the Faraday cage created by the spacecraft bus module. The DSS head with its 32- deg square FOV is mounted on the instrument module with its boresight along the spacecraft X axis, nearly aligned with the Sun during observations. Adcole has designed the DSS calibration parameters so that the accuracy is 0.24 arcminutes within 10 deg of the boresight, and diminishes to 3 arcminutes as the Sun moves towards the edges of its FOV . This DSS calibration scheme provides higher accuracy attitude determination over the range of the instrument calibration maneuvers.

Morgenstern, Wendy M.↗