SEARCH · Search NASA
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.
The Advanced Video Guidance Sensor (AVGS) was designed to be the proximity operations sensor for the Demonstration of Autonomous Rendezvous Technologies (DART). The DART mission flew in April of2005 and was a partial success. The AVGS did not get the opportunity to operate in every mode in orbit, but those modes in which it did operate were completely successful. This paper will detail the development, testing, and on-orbit performance of the AVGS.
Testing Of the Advanced Video Guidance Sensor (AVGS) used for proximity operations navigation on the Orbital Express ASTRO spacecraft exposed several unanticipated imaging system artifacts and aberrations that required correction, to meet critical navigation performance requirements. Mitigation actions are described for a number of system error sources, including lens aberration, optical train misalignment, laser speckle, target image defects, and detector nonlinearity/noise characteristics. Sensor test requirements and protocols are described, along with a summary ,of test results from sensor confidence tests and system performance testing.
Identification, resolution, and avoidance of technical and programmatic issues are important for ensuring safe and successful space missions. Although the importance of applying lessons learned to reduce risk is frequently stressed, there is little material available to help technical and management personnel research and document lessons learned. Collecting, researching, identifying, and documenting lessons learned that will be useful to current and future management and engineering personnel is not always a straightforward task. This white paper presents lessons learned and best practices concerning the research and documentation of technical and organizational lessons learned. It is intended to enable organizations to initiate or improve lessons learned research and documentation efforts. The content of this white paper is based on four technical lessons learned projects conducted by the United Space Alliance (USA) Flight Design and Dynamics Department, in support of the NASA/Johnson Space Center (JSC) Flight Design and Dynamics Division. Each project published a report, titled as follows: (1) GPS Lessons Learned From the ISS, Space Shuttle and X-38; (2) Lessons Learned From Seven Space Shuttle Missions; (3) Space Shuttle Rendezvous and Proximity Operations Experience Report; and (4) Navigation Technical History with Lessons Learned. The four projects were different in availability of subject matter experts and primary source material, subject scope, and the level of effort required to produce the final report. However, generic lessons can be drawn from all of them. The best practices will be discussed by the phases of report research and development: (1) Defining Report Requirements, Project Organization, and Schedule; (2) Collection and Analysis of Source Material; (3) Writing and Integrating the Report; and (4) Review and Revision of the Report.
The Orbital Express (OE) mission performed the first autonomous rendezvous and docking in the history of the United States on May 5-6, 2007 with the Advanced Video Guidance Sensor (AVGS) acting as one of the primary docking sensors. Since that event, the OE spacecraft performed four more rendezvous and docking maneuvers, each time using the AVGS as one of the docking sensors. The Marshall Space Flight Center's (MSFC's) AVGS is a nearfield proximity operations sensor that was integrated into the Autonomous Rendezvous and Capture Sensor System (ARCSS) on OE. The ARCSS provided the relative state knowledge to allow the OE spacecraft to rendezvous and dock. The AVGS is a mature sensor technology designed to support Automated Rendezvous and Docking (AR&D) operations. It is a video-based laser-illuminated sensor that can determine the relative position and attitude between itself and its target. Due to parts obsolescence, the AVGS that was flown on OE can no longer be manufactured. MSFC has been working on the next generation of AVGS for application to future Constellation missions. This paper provides an overview of the performance of the AVGS on Orbital Express and discusses the work on the Next Generation AVGS (NGAVGS).
A program of research, development, test, and evaluation is planned for the development of Spacecraft Handling Qualities guidelines. In this first experiment, the effects of Reaction Control System design characteristics and rotational control laws were evaluated during simulated proximity operations and docking. Also, the influence of piloting demands resulting from varying closure rates was assessed. The pilot-in-the-loop simulation results showed that significantly different spacecraft handling qualities result from the design of the Reaction Control System. In particular, cross-coupling between translational and rotational motions significantly affected handling qualities as reflected by Cooper-Harper pilot ratings and pilot workload, as reflected by Task-Load Index ratings. This influence is masked but only slightly by the rotational control system mode. While rotational control augmentation using Rate Command Attitude Hold can reduce the workload (principally, physical workload) created by cross-coupling, the handling qualities are not significantly improved. The attitude and rate deadbands of the RCAH introduced significant mental workload and control compensation to evaluate when deadband firings would occur, assess their impact on docking performance, and apply control inputs to mitigate that impact.
In May 2007 the first US fully autonomous rendezvous and capture was successfully performed by DARPA's Orbital Express (OE) mission. Since then, the Boeing ASTRO spacecraft and the Ball Aerospace NEXTSat have performed multiple rendezvous and docking maneuvers to demonstrate the technologies needed for satellite servicing. MSFC's Advanced Video Guidance Sensor (AVGS) is a primary near-field proximity operations sensor integrated into ASTRO's Autonomous Rendezvous and Capture Sensor System (ARCSS), which provides relative state knowledge to the ASTRO GN&C system. This paper provides an overview of the AVGS sensor flying on Orbital Express, and a summary of the ground testing and on-orbit performance of the AVGS for OE. The AVGS is a laser-based system that is capable of providing range and bearing at midrange distances and full six degree-of-freedom (6DOF) knowledge at near fields. The sensor fires lasers at two different frequencies to illuminate the Long Range Targets (LRTs) and the Short Range Targets (SRTs) on NEXTSat. Subtraction of one image from the other image removes extraneous light sources and reflections from anything other than the corner cubes on the LRTs and SRTs. This feature has played a significant role for Orbital Express in poor lighting conditions. The very bright spots that remain in the subtracted image are processed by the target recognition algorithms and the inverse-perspective algorithms, to provide 3DOF or 6DOF relative state information. Although Orbital Express has configured the ASTRO ARCSS system to only use AVGS at ranges of 120 m or less, some OE scenarios have provided opportunities for AVGS to acquire and track NEXTSat at greater distances. Orbital Express scenarios to date that have utilized AVGS include a berthing operation performed by the ASTRO robotic arm, sensor checkout maneuvers performed by the ASTRO robotic arm, 10-m unmated operations, 30-m unmated operations, and Scenario 3-1 anomaly recovery. The AVGS performed very well during the pre-unmated operations, effectively tracking beyond its 10-degree Pitch and Yaw limit-specifications, and did not require I-LOAD adjustments before unmated operations. AVGS provided excellent performance in the 10-m unmated operations, effectively tracking and maintaining lock for the duration of this scenario, and showing good agreement between the short and long range targets. During the 30-m unmated operations, the AVGS continuously tracked the SRT to 31.6 m, exceeding expectations, and continuously tracked the LRT from 8.8 m out to 31.6 m, with good agreement between these two target solutions. After this scenario was aborted at a 10-m separation during remate operations, the AVGS tracked the LRT out 54.3 m, until the relative attitude between the vehicles was too large. The vehicles remained apart for eight days, at ranges from 1 km to 6 km. During the approach to remate in this recovery operation, the AVGS began tracking the LRT at 150 m, well beyond the OE planned limits for AVGS ranges, and functioned as the primary sensor for the autonomous rendezvous and docking.
The Advanced Video Guidance Sensor (AVGS) was the primary docking sensor for the Orbital Express mission. The sensor performed extremely well during the mission, and the technology has been proven on orbit in other flights too. Parts obsolescence issues prevented the construction of more AVGS units, so the next generation of sensor was designed with current parts and updated to support future programs. The Next Generation Advanced Video Guidance Sensor (NGAVGS) has been tested as a breadboard, two different brassboard units, and a prototype. The testing revealed further improvements that could be made and demonstrated capability beyond that ever demonstrated by the sensor on orbit. This paper presents some of the sensor history, parts obsolescence issues, radiation concerns, and software improvements to the NGAVGS. In addition, some of the testing and test results are presented. The NGAVGS has shown that it will meet the general requirements for any space proximity operations or docking need.
Agora software is a simulation of spacecraft attitude and orbit dynamics. It supports spacecraft models composed of multiple rigid bodies or flexible structural models. Agora simulates multiple spacecraft simultaneously, supporting rendezvous, proximity operations, and precision formation flying studies. The Agora environment includes ephemerides for all planets and major moons in the solar system, supporting design studies for deep space as well as geocentric missions. The environment also contains standard models for gravity, atmospheric density, and magnetic fields. Disturbance force and torque models include aerodynamic, gravity-gradient, solar radiation pressure, and third-body gravitation. In addition to the dynamic and environmental models, Agora supports geometrical visualization through an OpenGL interface. Prototype models are provided for common sensors, actuators, and control laws. A clean interface accommodates linking in actual flight code in place of the prototype control laws. The same simulation may be used for rapid feasibility studies, and then used for flight software validation as the design matures. Agora is open-source and portable across computing platforms, making it customizable and extensible. It is written to support the entire GNC (guidance, navigation, and control) design cycle, from rapid prototyping and design analysis, to high-fidelity flight code verification. As a top-down design, Agora is intended to accommodate a large range of missions, anywhere in the solar system. Both two-body and three-body flight regimes are supported, as well as seamless transition between them. Multiple spacecraft may be simultaneously simulated, enabling simulation of rendezvous scenarios, as well as formation flying. Built-in reference frames and orbit perturbation dynamics provide accurate modeling of precision formation control.
NASA's Orion Crew Exploration Vehicle (CEV) will provide transportation for crew and cargo to and from destinations in support of the Constellation Architecture Design Reference Missions. Discrete Event Simulation (DES) is one of the design methods NASA employs for crew performance of the CEV. During the early development of the CEV, NASA and its prime Orion contractor Lockheed Martin (LM) strived to seek an effective low-cost method for developing and validating human performance DES models. This paper focuses on the method developed while creating a DES model for the CEV Rendezvous, Proximity Operations, and Docking (RPOD) task to the International Space Station. Our approach to validation was to attack the problem from several fronts. First, we began the development of the model early in the CEV design stage. Second, we adhered strictly to M&S development standards. Third, we involved the stakeholders, NASA astronauts, subject matter experts, and NASA's modeling and simulation development community throughout. Fourth, we applied standard and easy-to-conduct methods to ensure the model's accuracy. Lastly, we reviewed the data from an earlier human-in-the-loop RPOD simulation that had different objectives, which provided us an additional means to estimate the model's confidence level. The results revealed that a majority of the DES model was a reasonable representation of the current CEV design.
The primal-dual interior-point algorithm implemented in G-OPT is a relatively new and efficient way of solving convex optimization problems. Given a prescribed level of accuracy, the convergence to the optimal solution is guaranteed in a predetermined, finite number of iterations. G-OPT Version 1.0 is a flight software implementation written in C. Onboard application of the software enables autonomous, real-time guidance and control that explicitly incorporates mission constraints such as control authority (e.g. maximum thrust limits), hazard avoidance, and fuel limitations. This software can be used in planetary landing missions (Mars pinpoint landing and lunar landing), as well as in proximity operations around small celestial bodies (moons, asteroids, and comets). It also can be used in any spacecraft mission for thrust allocation in six-degrees-of-freedom control.
In August 2006, NASA awarded Space Act Agreements (SAAs) for Commercial Orbital Transportation Services (COTS) under the Commercial Crew and Cargo Project Office at Johnson Space Center. One of the goals of the SAAs is to facilitate U.S. private industry demonstration of cargo transportation capabilities, ultimately achieving reliable, cost effective access to low-Earth orbit (LEO). Each COTS provider is required to complete International Space Stations (ISS) Integration activities, which includes meeting the physical and functional interfaces and interface requirements between the ISS and COTS vehicles. These requirements focus on the areas of risk to the ISS during rendezvous and proximity operations, as well as the integration operations while the COTS vehicle is berthed to the ISS. On December 23, 2008, NASA awarded Commercial Resupply Service (CRS) contracts to provide resupply services to the ISS, following the Shuttle retirement. In addition to performing any ISS Integration activities, NASA will be performing independent assessments of the launch vehicle and orbital vehicle to evaluate the readiness of the contractor to deliver NASA cargo safely to the ISS. This paper will address the activities NASA Centers, both JSC and KSC, in the oversight and insight function over commercial visiting vehicles to the ISS.
A simulation testbed architecture was developed and implemented for the integration, test, and development of a TRL-6 flight software set called Auto- GNC. The AutoGNC software will combine the TRL-9 Deep Impact AutoNAV flight software suite, the TRL-9 Virtual Machine Language (VML) executive, and the TRL-3 G-REX guidance, estimation, and control algorithms. The Auto- GNC testbed was architected to provide software interface connections among the AutoNAV and VML flight code written in C, the G-REX algorithms in MATLAB and C, stand-alone image rendering algorithms in C, and other Fortran algorithms, such as the OBIRON landmark tracking suite. The testbed architecture incorporates software components for propagating a high-fidelity truth model of the environment and the spacecraft dynamics, along with the flight software components for onboard guidance, navigation, and control (GN&C). The interface allows for the rapid integration and testing of new algorithms prior to development of the C code for implementation in flight software. This testbed is designed to test autonomous spacecraft proximity operations around small celestial bodies, moons, or other spacecraft. The software is baselined for upcoming comet and asteroid sample return missions. This architecture and testbed will provide a direct improvement upon the onboard flight software utilized for missions such as Deep Impact, Stardust, and Deep Space 1.
At present, no Cubesat has flown in space featuring propulsion. This was acceptable as long as CubeSats were flown mostly as university experiments. As CubeSats become of interest to other users in the government and industry communities as well, a larger range of capabilities may be required than exhibited so far, while maintaining the uniqueness of the Cubesat platform. Propulsion capability is crucial in increasing mission capabilities of future CubeSats, such as orbit change and raising, formation flying, proximity operations, fine attitude control, or drag-make-up and de-orbit. While some of these tasks may be accomplished with propellantless devices, their applications are limited, applicable mostly to a single task, and bear their own risks. In this study, a survey was conducted of propulsion technologies applicable to CubeSats. Only few off-the-shelf design solutions exist today. The survey was thus expanded to such devices as well that are under significant development, and are approaching the required design envelope for CubeSats with respect to mass, volume, and power. In some cases, such as electric propulsion devices, CubeSat architectures themselves may need to be adapted, required to feature deployable solar arrays to increase power capabilities. Given the vast scope of this survey, only thruster technologies could be surveyed. However, valves and other feed system components, as well as their integration, are equally important, but have to be left to a future survey. Three major propulsion technology areas applicable to CubeSats emerged when conducting this review: (1) Existing technologies, such as butane systems, pulsed plasma thrusters, and vacuum arc thrusters are applicable to CubeSats today with no or only minor changes, (2) New thruster technologies under significant development, such as hydrazine monopropellant systems, ion engines, or colloid thrusters could be adapted to CubeSats with some further development, especially also in other subsystem areas such as feed systems and power processing units. They will also require increased power capabilities, and (3) emerging technologies, such as micro electrospray arrays and micro cavity discharge arrays that offer even higher flexibility due to scalability for CubeSats, and enable compact integration.
The Space Shuttle navigation architecture was originally designed in the 1970s. A variety of on-board and ground based navigation sensors and computers are used during the ascent, orbit coast, rendezvous, (including proximity operations and docking) and entry flight phases. With the advent of GPS navigation and tightly coupled GPS/INS Units employing strapdown sensors, opportunities to improve and streamline the Shuttle navigation process are being pursued. These improvements can potentially result in increased safety, reliability, and cost savings in maintenance through the replacement of older technologies and elimination of ground support systems (such as Tactical Air Control and Navigation (TACAN), Microwave Landing System (MLS) and ground radar). Selection and missionization of "off the shelf" GPS and GPS/INS units pose a unique challenge since the units in question were not originally designed for the Space Shuttle application. Various options for integrating GPS and GPS/INS units with the existing orbiter avionics system were considered in light of budget constraints, software quality concerns, and schedule limitations. An overview of Shuttle navigation methodology from 1981 to the present is given, along with how GPS and GPS/INS technology will change, or not change, the way Space Shuttle navigation is performed in the 21 5 century.
A crewed mission to a Near-Earth Object (NEO) was recently identified as a NASA Space Policy goal and priority. In support of this goal, a study was conducted to identify the initial considerations for performing the navigation and flight dynamics tasks of this mission class. Although missions to a NEO are not new, the unique factors involved in human spaceflight present challenges that warrant special examination. During the cruise phase of the mission, one of the most challenging factors is the noisy acceleration environment associated with a crewed vehicle. Additionally, the presence of a human crew necessitates a timely return trip, which may need to be expedited in an emergency situation where the mission is aborted. Tracking, navigation, and targeting results are shown for sample human-class trajectories to NEOs. Additionally, the benefit of in-situ navigation beacons on robotic precursor missions is presented. This mission class will require a longer duration flight than Apollo and, unlike previous human missions, there will likely be limited communication and tracking availability. This will necessitate the use of more onboard navigation and targeting capabilities. Finally, the rendezvous and proximity operations near an asteroid will be unlike anything previously attempted in a crewed spaceflight. The unknown gravitational environment and physical surface properties of the NEO may cause the rendezvous to behave differently than expected. Symbiosis of the human pilot and onboard navigation/targeting are presented which give additional robustness to unforeseen perturbations.
The Sensor Test for Orion Relative-Navigation Risk Mitigation (STORRM) Development Test Objective (DTO) ew aboard the Space Shuttle Endeavour on STS-134, and was designed to characterize the performance of the ash LIDAR being developed for the Orion. This ash LIDAR, called the Vision Navigation Sensor (VNS), will be the primary navigation instrument used by the Orion vehicle during rendezvous, proximity operations, and docking. This paper provides an overview of the STORRM test objectives and the concept of operations. It continues with a description of the STORRM's major hardware compo nents, which include the VNS and the docking camera. Next, an overview of crew and analyst training activities will describe how the STORRM team prepared for flight. Then an overview of how insight data collection and analysis actually went is presented. Key ndings and results from this project are summarized, including a description of "truth" data. Finally, the paper concludes with lessons learned from the STORRM DTO.
To meet cost and safety objectives, space missions that involve proximity operations between two vehicles require a high level of autonomy to successfully complete their missions. The need for autonomy is primarily driven by the need to conduct complex operations outside of communication windows, and the communication time delays inherent in space missions. Autonomy also supports the goals of both NASA and the DOD to make space operations more routine, and lower operational costs by reducing the requirement for ground personnel. NASA and the DoD have several programs underway that require a much higher level of autonomy for space vehicles. NASA's Space Launch Initiative (SLI) program has ambitious goals of reducing costs by a factor or 10 and improving safety by a factor of 100. DARPA has recently begun its Orbital Express to demonstrate key technologies to make satellite servicing routine. The Air Force's XSS-ll program is developing a protoflight demonstration of an autonomous satellite inspector. A common element in space operations for many NASA and DOD missions is the ability to rendezvous, inspect anclJor dock with another spacecraft. For DARPA, this is required to service or refuel military satellites. For the Air Force, this is required to inspect un-cooperative resident space objects. For NASA, this is needed to meet the primary SLI design reference mission of International Space Station re-supply. A common aspect for each of these programs is an Autonomous Mission Manager that provides highly autonomous planning, execution and monitoring of the rendezvous, inspection and docking operations. This paper provides an overview of the Autonomous Mission Manager (AMM) design being incorporated into many of these technology programs. This AMM provides a highly scalable level of autonomous operations, ranging from automatic execution of ground-derived plans to highly autonomous onboard planning to meet ground developed mission goals. The AMM provides the capability to automatically execute the plans and monitor the system performance. In the event of system dispersions or failures the AMM can modify plans or abort to assure overall system safety. This paper describes the design and functionality of Draper's AMM framework, presents concept of operations associated with the use of the AMM, and outlines the relevant features of the flight demonstrations.
The Sensor Test for Orion Relative-Navigation Risk Mitigation (STORRM) Development Test Objective (DTO) flew aboard the Space Shuttle Endeavour on STS-134 in May- June 2011, and was designed to characterize the performance of the flash LIDAR and docking camera being developed for the Orion Multi-Purpose Crew Vehicle. The flash LIDAR, called the Vision Navigation Sensor (VNS), will be the primary navigation instrument used by the Orion vehicle during rendezvous, proximity operations, and docking. The DC will be used by the Orion crew for piloting cues during docking. This paper provides an overview of the STORRM test objectives and the concept of operations. It continues with a description of STORRM's major hardware components, which include the VNS, docking camera, and supporting avionics. Next, an overview of crew and analyst training activities will describe how the STORRM team prepared for flight. Then an overview of in-flight data collection and analysis is presented. Key findings and results from this project are summarized. Finally, the paper concludes with lessons learned from the STORRM DTO.