Morpheus Lander Testing Campaign

NASA s Morpheus Project has developed and tested a prototype planetary lander capable of vertical takeoff and landing designed to serve as a testbed for advanced spacecraft technologies. The Morpheus vehicle has successfully performed a set of integrated vehicle test flights including hot-fire and tether tests, ultimately culminating in an un-tethered "free-flight" This development and testing campaign was conducted on-site at the Johnson Space Center (JSC), less than one year after project start. Designed, developed, manufactured and operated in-house by engineers at JSC, the Morpheus Project represents an unprecedented departure from recent NASA programs and projects that traditionally require longer development lifecycles and testing at remote, dedicated testing facilities. This paper documents the integrated testing campaign, including descriptions of test types (hot-fire, tether, and free-flight), test objectives, and the infrastructure of JSC testing facilities. A major focus of the paper will be the fast pace of the project, rapid prototyping, frequent testing, and lessons learned from this departure from the traditional engineering development process at NASA s Johnson Space Center

Morpheus Vertical Test Bed Flight Testing

NASA's Morpheus Project has developed and tested a prototype planetary lander capable of vertical takeoff and landing, that is designed to serve as a testbed for advanced spacecraft technologies. The lander vehicle, propelled by a LOX/Methane engine and sized to carry a 500kg payload to the lunar surface, provides a platform for bringing technologies from the laboratory into an integrated flight system at relatively low cost. Morpheus onboard software is autonomous from ignition all the way through landing, and is designed to be capable of executing a variety of flight trajectories, with onboard fault checks and automatic contingency responses. The Morpheus 1.5A vehicle performed 26 integrated vehicle test flights including hot-fire tests, tethered tests, and two attempted freeflights between April 2011 and August 2012. The final flight of Morpheus 1.5A resulted in a loss of the vehicle. In September 2012, development began on the Morpheus 1.5B vehicle, which subsequently followed a similar test campaign culminating in free-flights at a simulated planetary landscape built at Kennedy Space Center's Shuttle Landing Facility. This paper describes the integrated test campaign, including successes and setbacks, and how the system design for handling faults and failures evolved over the course of the project

A Comparison Between Orion Automated and Space Shuttle Rendezvous Techniques

The Orion spacecraft will replace the space shuttle and will be the first human spacecraft since the Apollo program to leave low earth orbit. This vehicle will serve as the cornerstone of a complete space transportation system with a myriad of mission requirements necessitating rendezvous to multiple vehicles in earth orbit, around the moon and eventually beyond . These goals will require a complex and robust vehicle that is, significantly different from both the space shuttle and the command module of the Apollo program. Historically, orbit operations have been accomplished with heavy reliance on ground support and manual crew reconfiguration and monitoring. One major difference with Orion is that automation will be incorporated as a key element of the man-vehicle system. The automated system will consist of software devoted to transitioning between events based on a master timeline. This effectively adds a layer of high level sequencing that moves control of the vehicle from one phase to the next. This type of automated control is not entirely new to spacecraft since the shuttle uses a version of this during ascent and entry operations. During shuttle orbit operations however many of the software modes and hardware switches must be manually configured through the use of printed procedures and instructions voiced from the ground. The goal of the automation scheme on Orion is to extend high level automation to all flight phases. The move towards automation represents a large shift from current space shuttle operations, and so these new systems will be adopted gradually via various safeguards. These include features such as authority-to-proceed, manual down modes, and functional inhibits. This paper describes the contrast between the manual and ground approach of the space shuttle and the proposed automation of the Orion vehicle. I will introduce typical orbit operations that are common to all rendezvous missions and go on to describe the current Orion automation architecture and contrast it with shuttle rendezvous techniques and circumstances. The shuttle rendezvous profile is timed to take approximately 3 days from orbit insertion to docking at the International Space Station (ISS). This process can be divided into 3 phases: far-field, mid-field and proximity operations. The far-field stage is characterized as the most quiescent phase. The spacecraft is usually too far to navigate using relative sensors and uses the Inertial Measurement Units (IMU s) to numerically solve for its position. The maneuvers are infrequent, roughly twice per day, and are larger than other burns in the profile. The shuttle uses this opportunity to take extensive ground based radar updates and keep high fidelity orbit states on the ground. This state is then periodically uplinked to the shuttle computers. The targeting solutions for burn maneuvers are also computed on the ground and uplinked. During the burn the crew is responsible for setting the shuttle attitude and configuring the propulsion system for ignition. Again this entire process is manually driven by both crew and ground activity. The only automatic processes that occur are associated with the real-time execution of the burn. The Orion automated functionality will seek to relieve the workload of both the crew and ground during this phas

The Orion GN and C Data-Driven Flight Software Architecture for Automated Sequencing and Fault Recovery

The Orion Crew Exploration Vehicle (CET) is being designed to include significantly more automation capability than either the Space Shuttle or the International Space Station (ISS). In particular, the vehicle flight software has requirements to accommodate increasingly automated missions throughout all phases of flight. A data-driven flight software architecture will provide an evolvable automation capability to sequence through Guidance, Navigation & Control (GN&C) flight software modes and configurations while maintaining the required flexibility and human control over the automation. This flexibility is a key aspect needed to address the maturation of operational concepts, to permit ground and crew operators to gain trust in the system and mitigate unpredictability in human spaceflight. To allow for mission flexibility and reconfrgurability, a data driven approach is being taken to load the mission event plan as well cis the flight software artifacts associated with the GN&C subsystem. A database of GN&C level sequencing data is presented which manages and tracks the mission specific and algorithm parameters to provide a capability to schedule GN&C events within mission segments. The flight software data schema for performing automated mission sequencing is presented with a concept of operations for interactions with ground and onboard crew members. A prototype architecture for fault identification, isolation and recovery interactions with the automation software is presented and discussed as a forward work item

Methodology for Prototyping Increased Levels of Automation for Spacecraft Rendezvous Functions

The Crew Exploration Vehicle necessitates higher levels of automation than previous NASA vehicles, due to program requirements for automation, including Automated Rendezvous and Docking. Studies of spacecraft development often point to the locus of decision-making authority between humans and computers (i.e. automation) as a prime driver for cost, safety, and mission success. Therefore, a critical component in the Crew Exploration Vehicle development is the determination of the correct level of automation. To identify the appropriate levels of automation and autonomy to design into a human space flight vehicle, NASA has created the Function-specific Level of Autonomy and Automation Tool. This paper develops a methodology for prototyping increased levels of automation for spacecraft rendezvous functions. This methodology is used to evaluate the accuracy of the Function-specific Level of Autonomy and Automation Tool specified levels of automation, via prototyping. Spacecraft rendezvous planning tasks are selected and then prototyped in Matlab using Fuzzy Logic techniques and existing Space Shuttle rendezvous trajectory algorithms

Methods for Determining the Level of Autonomy to Design into a Human Spaceflight Vehicle: A Function Specific Approach

The next-generation human spaceflight vehicle is in a unique position to realize the benefits of more than thirty years of technological advancements since the Space Shuttle was designed. Computer enhancements, the emergence of highly reliable decision-making algorithms, and an emphasis on efficiency make an increased use of autonomous systems highly likely. NASA is in a position to take advantage of these advances and apply them to the human spaceflight environment. One of the key paradigm shifts will be the shift, where appropriate, of monitoring, option development, decision-making, and execution responsibility from humans to an Autonomous Flight Management (AFM) system. As an effort to reduce risk for development of an AFM system, NASA engineers are developing a prototype to prove the utility of previously untested autonomy concepts. This prototype, called SMART (Spacecraft Mission Assessment and Replanning Tool), is a functionally decomposed flight management system with an appropriate level of autonomy for each of its functions. As the development of SMART began, the most important and most often asked question was, How autonomous should an AFM system be? A thorough study of the literature through 2002 surrounding autonomous systems has not yielded a standard method for designing a level of autonomy into either a crewed vehicle or an uncrewed vehicle. The current focus in the literature on defining autonomy is centered on developing IQ tests for built systems. The literature that was analyzed assumes that the goal of all systems is to strive for complete autonomy from human intervention, rather than identifying how autonomous each function within the system should have been. In contrast, the SMART team developed a method for determining the appropriate level of autonomy to be designed into each function within a system. This paper summarizes the development of the Level of Autonomy Assessment Tool and its application to the SMART project