Results for “Docking” — Page 49

NASA NTRS2014

FLASH LIDAR Based Relative Navigation

Relative navigation remains the most challenging part of spacecraft rendezvous and docking. In recent years, flash LIDARs, have been increasingly selected as the go-to sensors for proximity operations and docking. Flash LIDARS are generally lighter and require less power that scanning Lidars. Flash LIDARs do not have moving parts, and they are capable of tracking multiple targets as well as generating a 3D map of a given target. However, there are some significant drawbacks of Flash Lidars that must be resolved if their use is to be of long-term significance. Overcoming the challenges of Flash LIDARs for navigation-namely, low technology readiness level, lack of historical performance data, target identification, existence of false positives, and performance of vision processing algorithms as intermediaries between the raw sensor data and the Kalman filter-requires a world-class testing facility, such as the Lockheed Martin Space Operations Simulation Center (SOSC). Ground-based testing is a critical step for maturing the next-generation flash LIDAR-based spacecraft relative navigation. This paper will focus on the tests of an integrated relative navigation system conducted at the SOSC in January 2014. The intent of the tests was to characterize and then improve the performance of relative navigation, while addressing many of the flash LIDAR challenges mentioned above. A section on navigation performance and future recommendation completes the discussion.

Brazzel, Jack↗

NASA NTRS2010

Preliminary Design of the Guidance, Navigation, and Control System of the Altair Lunar Lander

Guidance, Navigation, and Control (GN&C) is the measurement and control of spacecraft position, velocity, and attitude in support of mission objectives. This paper provides an overview of a preliminary design of the GN&C system of the Lunar Lander Altair. Key functions performed by the GN&C system in various mission phases will first be described. A set of placeholder GN&C sensors that is needed to support these functions is next described. To meet Crew safety requirements, there must be high degrees of redundancy in the selected sensor configuration. Two sets of thrusters, one on the Ascent Module (AM) and the other on the Descent Module (DM), will be used by the GN&C system. The DM thrusters will be used, among other purposes, to perform course correction burns during the Trans-lunar Coast. The AM thrusters will be used, among other purposes, to perform precise angular and translational controls of the ascent module in order to dock the ascent module with Orion. Navigation is the process of measurement and control of the spacecraft's "state" (both the position and velocity vectors of the spacecraft). Tracking data from the Earth-Based Ground System (tracking antennas) as well as data from onboard optical sensors will be used to estimate the vehicle state. A driving navigation requirement is to land Altair on the Moon with a landing accuracy that is better than 1 km (radial 95%). Preliminary performance of the Altair GN&C design, relative to this and other navigation requirements, will be given. Guidance is the onboard process that uses the estimated state vector, crew inputs, and pre-computed reference trajectories to guide both the rotational and the translational motions of the spacecraft during powered flight phases. Design objectives of reference trajectories for various mission phases vary. For example, the reference trajectory for the descent "approach" phase (the last 3-4 minutes before touchdown) will sacrifice fuel utilization efficiency in order to provide landing site visibility for both the crew and the terrain hazard detection sensor system. One output of Guidance is the steering angle commands sent to the 2 degree-of-freedom (dof) gimbal actuation system of the descent engine. The engine gimbal actuation system is controlled by a Thrust Vector Control algorithm that is designed taking into account the large quantities of sloshing liquids in tanks mounted on Altair. In this early design phase of Altair, the GN&C system is described only briefly in this paper and the emphasis is on the GN&C architecture (that is still evolving). Multiple companion papers will provide details that are related to navigation, optical navigation, guidance, fuel sloshing, rendezvous and docking, machine-pilot interactions, and others. The similarities and differences of GN&C designs for Lunar and Mars landers are briefly compared.

Lee, Allan Y.↗

NASA NTRS2016

Structural Design Considerations for a 50 kW-Class Solar Array for NASA's Asteroid Redirect Mission

NASA is planning an Asteroid Redirect Mission (ARM) to take place in the 2020s. To enable this multi-year mission, a 40 kW class solar electric propulsion (SEP) system powered by an advanced 50 kW class solar array will be required. Powered by the SEP module (SEPM), the ARM vehicle will travel to a large near-Earth asteroid, descend to its surface, capture a multi-metric ton (t) asteroid boulder, ascend from the surface and return to the Earth-moon system to ultimately place the ARM vehicle and its captured asteroid boulder into a stable distant orbit. During the years that follow, astronauts flying in the Orion multipurpose crew vehicle (MPCV) will dock with the ARM vehicle and conduct extra-vehicular activity (EVA) operations to explore and sample the asteroid boulder. This paper will review the top structural design considerations to successfully implement this 50 kW class solar array that must meet unprecedented performance levels. These considerations include beyond state-of-the-art metrics for specific mass, specific volume, deployed area, deployed solar array wing (SAW) keep in zone (KIZ), deployed strength and deployed frequency. Analytical and design results are presented that support definition of stowed KIZ and launch restraint interface definition. An offset boom is defined to meet the deployed SAW KIZ. The resulting parametric impact of the offset boom length on spacecraft moment of inertias and deployed SAW quasistatic and dynamic load cases are also presented. Load cases include ARM spacecraft thruster plume impingement, asteroid surface operations and Orion docking operations which drive the required SAW deployed strength and damping. The authors conclude that to support NASA's ARM power needs, an advanced SAW is required with mass performance better than 125 W/kg, stowed volume better than 40 kW/cu m, a deployed area of 200 sq m (100 sq m for each of two SAWs), a deployed SAW offset distance of nominally 3-4 m, a deployed SAW quasistatic strength of nominally 0.1 g in any direction, a deployed loading displacement under 2 m, a deployed fundamental frequency above 0.1 Hz and deployed damping of at least 1%. These parameters must be met on top of challenging mission environments and ground testing requirements unique to the ARM project.

solar arrays↗

NASA NTRS1972

Apollo 16 Press Kit

The Apollo 16 spacecraft is scheduled for launch on Apr. 16, 1972 from Complex 39A at the Kennedy Space Center, Florida by the Saturn V launch vehicle. Crewmen are mission commander John W. Young, command module pilot Thomas K. Mattingly II and lunar module pilot Charles M. Duke Jr. Objectives of the mission, to last up to 12 days, as outlined by NASA: to perform selenological inspection, survey and sampling of materials in a preselected region of Descartes using a lunar roving' vehicle; deploy and activate Apollo surface experiments; develop man's capability to work in the lunar environment; obtain photographs of candidate exploration sites; and toconduct inflight experiments and photographic tasks in lunar orbit. Following launch, the spacecraft will reach Earth Parking Orbit and remain in orbit for about two and one-half revolutions prior to Translunar Injection. Next, the Command and Service Module docks with the Lunar Module and the spacecraft "coasts" to the moon. In orbit around the moon, the Command and Service Module/Lunar Module combination will descend to within 50,000 feet of the lunar surface before undocking. The Lunar Module will continue to descend while the Command and Service Module returns to an orbit approximately 60 miles high. Stay time on the lunar surface is scheduled for approximately 73 hours. The ascent stage of the Lunar Module then lifts the astronauts back into lunar orbit where they will dock with the Command/Service Module. The Lunar Module is jettisoned and Transearth Injection follows. Just prior to reentry into the earth's atmosphere, the Service Module is jettisoned, and the astronauts in the Command Module splashdown in the Pacific Ocean. The target point for end-of-mission splashdown is at 05 degrees 0 minutes north latitude and 158 degrees 40 minutes west longitude or approximately 985 nautical miles south of Honolulu, Hawaii. Splashdown is scheduled for Apr. 28, 1972 at 10:30 a.m. Hawaiian Standard Time (2:30 p.m. CST). Recovery forces for Apollo 16, stationed in both the Atlantic and Pacific Oceans, will consist of three ships, nine aircraft and nearly 1,700 personnel. CTF-130 (Manned Spacecraft Recovery Force, Pacific) forces will be stationed south of Hawaii. Three ships, eight helicopters and three Air Force HC-130H aircraft, and nearly 1,100 personnel, will take part. Task Force 140 (Manned Spacecraft Recovery Force, Atlantic), comprising one ship, six HC-130H aircraft, three helicopters and approximately 300 personnel, will be positioned for possible launch abort operations. Two ships in the Atlantic will also be used for acoustical testing. Other forces, primarily aircraft and personnel of the Air Force Aerospace Rescue and Recovery Service will be on alert around the world for contingency recovery support.

Source record↗

NASA NTRS2017

Robust Targeting for the Smartphone Video Guidance Sensor

The Smartphone Video Guidance Sensor (SVGS) is a miniature, self-contained autonomous rendezvous and docking sensor developed using a commercial off the shelf Android-based smartphone. It aims to provide a miniaturized solution for rendezvous and docking, enabling small satellites to conduct proximity operations and formation flying while minimizing interference with a primary payload. Previously, the sensor was limited by a slow (2 Hz) refresh rate and its use of retro-reflectors, both of which contributed to a limited operating environment. To advance the technology readiness level, a modified approach was developed, combining a multi-colored LED target with a focused target-detection algorithm. Alone, the use of an LED system was determined to be much more reliable, though slower, than the retro-reflector system. The focused target-detection system was developed in response to this problem to mitigate the speed reduction of using color. However it also improved the reliability. In combination these two methods have been demonstrated to dramatically increase sensor speed and allow the sensor to select the target even with significant noise interfering with the sensor, providing millimeter level precision at a range of two meters with a 1U target.

Carter, C.↗

NASA NTRS2017

Robust Targeting for the Smartphone Video Guidance Sensor

The Smartphone Video Guidance Sensor (SVGS) is a miniature, self-contained autonomous rendezvous and docking sensor developed using a commercial off the shelf Android-based smartphone. It aims to provide a miniaturized solution for rendezvous and docking, enabling small satellites to conduct proximity operations and formation flying while minimizing interference with a primary payload. Previously, the sensor was limited by a slow (2 Hz) refresh rate and its use of retro-reflectors, both of which contributed to a limited operating environment. To advance the technology readiness level, a modified approach was developed, combining a multi-colored LED target with a focused target-detection algorithm. Alone, the use of an LED system was determined to be much more reliable, though slower, than the retro-reflector system. The focused target-detection system was developed in response to this problem to mitigate the speed reduction of using color. However, it also improved the reliability. In combination these two methods have been demonstrated to dramatically increase sensor speed and allow the sensor to select the target even with significant noise interfering with the sensor, providing millimeter level accuracy at a range of two meters with a 1U target.

Carter, Christopher↗

NASA NTRS2019

System and Method for Modular Unmanned Aerial System

A modular Unmanned Aerial System (UAS) has first and second flight configurations, and includes an Unmanned Aerial Vehicle (UAV) parent module and a plurality of UAV child modules. The parent module may have a fuselage, forward and aft wings connected to the fuselage, and a first plurality of flight propulsion devices. The child modules have a corresponding second plurality of flight propulsion devices. Each child module docks wingtip-to-wingtip with the parent module or an adjacent edge of a child module using the docking mechanisms. The child modules undock and separate from the forward wing and each other, and achieve controlled flight independently of the parent module while in the second flight configuration. A method for controlling the modular UAS is also disclosed.

Quinlan, Jesse R.↗

NASA NTRS2019

The Shapeshifter: A Morphing, Multi-Agent, Multi-Modal Robotic Platform for the Exploration of Titan

In this report, we present a robotic platform, the Shapeshifter, that allows multi-domain and redundant mobility on Saturn's moon Titan - and potentially other bodies with atmospheres. The Shapeshifter is a collection of simple and a affordable robotic units, called Cobots, comparable to personal palm-size quadcopters. By attaching and detaching with each other, multiple Cobots can shape-shift into novel structures, capable of (a) rolling on a at surface, to increase the traverse range, (b) flying in a flight array formation, and (c) swimming on or under liquid. A ground station, called the Home-base, complements the robotic platform, hosting science instrumentation and providing power to recharge the batteries of the Cobots. Our Phase I study had the objective of providing an initial assessment of the feasibility of the proposed robotic platform architecture, and in particular (a) to characterize the expected science return of a mission to the Sotra-Patera region on Titan; (b) to verify the mechanical and algorithmic feasibility of building a multi-agent platform capable of flying, docking, rolling and un-docking; (c) to evaluate the increased range and efficiency of rolling on Titan w.r.t to flying; (d) to define a case-study of a mission for the exploration of the cryovolcano Sotra-Patera on Titan, whose expected variety of geological features challenges conventional mobility platforms.

Agha-mohammadi, Ali-akbar↗

NASA NTRSDate not supplied

Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey↗

NASA NTRS2020

MAGIK Animation of Robotic Operations for Flight SpaceX-21 to ISS

The MAGIK Robotic analysis team provides kinematic feasibility assessments for the ISS and has produced an animation to evaluate Extravehicular Robotics (EVR) activities for SpaceX (SpX)-21 flight. Flight SpX-21 includes a Dragon 2 vehicle docked to Node 2 Zenith (N2Z) International Docking Adapter (IDA) and consists of the delivery of the NanoRacks Airlock Assembly (NRAL). Robotic operations shown include Space Station Remote Manipulator System (SSRMS) Trunk extraction of the NRAL and maneuvering through the ISS Port Corridor to Node 3 Port (N3P). Extravehicular Activities not shown will complete the install to N3P. There is no disposal payload for this flight.

Alexander Radford Fryer↗

NASA NTRS2020

MAGIK Animation of Robotic Operations for Flight SpaceX-22 to ISS

The MAGIK Robotic analysis team provides kinematic feasibility assessments for the ISS and has produced an animation to evaluate Extravehicular Robotics (EVR) activities for the SpaceX (SpX)-22 flight. The animation also displays the current ISS configuration at the time of the flight. Flight SpX-22 includes a SpaceX Cargo Dragon vehicle docked to Node 2 Zenith (N2Z) International Docking Adapter (IDA) and consists of the delivery of the ISS Power Augmentation (IPA) Carrier. Robotic operations shown include the Space Station Remote Manipulator System (SSRMS) Trunk extraction of the IPA Carrier and maneuvering to the install position on the Payload ORU (Orbital Replacement Unit) Accommodation (POA). There is no disposal payload for this flight.

Alexander Radford Fryer↗

NASA NTRSDate not supplied

Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C. Dempsey↗

NASA NTRSDate not supplied

Automated Software for Crewed Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey↗

NASA NTRS2021

Visualization of Upcoming ISS Changes - Featuring MLM Install

The MAGIK Robotic analysis team provides kinematic feasibility assessments and robotic visualizations for the ISS. The latest visualization displays ISS planned operations in increments 65 and 66 as of the 7/6/21 flight plan. Featured events include the arrival of the Multipurpose Laboratory Module (MLM) and surrounding visiting vehicle actions. The complete list of actions shown include: Repeated ISS attitude adjustment maneuvers from: starting position with positive X Velocity Vector (+XVV), yaw to -XVV, and pitch to final position with -ZVV. Then subsequent return to -XVV and nominal position +XVV. Crew-2 relocation from Node 2 Forward (N2F) to Node 2 Zenith (N2Z). 77 Progress with Docking Compartment 1 (DC1) undock and departure. MLM install. Boe-OFT2 arrival and departure at N2F. NG-16 arrival and berth at Node 1 Nadir (N1N). SpX-23 arrival at N2F. 64 Soyuz relocation and fly-around. SpX-23 departure from N2F. 65 Soyuz approach and dock to MRM-1. 64 Soyuz undock and departure. 78 Progress relocation.

ISS↗

NASA NTRSDate not supplied

A Multi-Functional, Two-Chamber Airlock Node for a Common Habitat Architecture

An airlock is generally considered a necessity for any large, habitable spacecraft. While suitports, docked rovers, and external robotics can reduce the need for airlock operations, at some point it is necessary to move both crew and equipment from a habitat interior to the exterior environment. The Common Habitat is a large, long-duration habitat that uses the Space Launch System (SLS) Core Stage Liquid Oxygen tank as the primary structure (similar to Skylab) and has an internal architecture compatible with microgravity, lunar gravity, and Mars gravity, such that identical versions of the same design can be used in all three environments. It needs an airlock that is similarly appropriate for both surface and microgravity environments. After a brief survey of prior airlocks, the two-chamber node airlock concept applied to the Common Habitat architecture is described. This includes benefits of the dual chamber and node approaches, dimensions, hatches and docking ports, utilities connections, hatch covers, suit storage, EVA stowage, subsystems, and gravity-specific external attachments. Additionally, the functions of each chamber and reconfiguration capabilities are explained. Finally, conclusions and follow-on work are discussed.

Robert L Howard↗

NASA NTRSDate not supplied

Automated Software for Crewed Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a unique private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed along with evolution of the system in preparation for the second uncrewed test flight. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies.

Robert C. Dempsey↗

NASA NTRSDate not supplied

Relative Navigation for Spacecraft in Nearly Rectilinear Halo Orbits

Lunar orbit missions are of great interest to the space exploration community. This paper is focused on the research, development, and feasibility of spacecraft docking within Nearly Rectilinear Halo Orbits (NRHO). In this work, a proximity estimation algorithm is developed using the Circular Restricted Three Body Problem (CR3BP) equations of motion, which can be used to estimate the proximity between a follower spacecraft and leader spacecraft while docking in NRHOs around the Moon. Promising initial simulation results are provided and discussed. This proximity estimation algorithm is shown to to provide useful tracking estimates which can be fed to the spacecraft control system and will help ensure mission success.

Luke J. Miller↗

NASA NTRS2022

Moon to Mars (M2M) Habitation Considerations: A Snap Shot As of January 2022

The following NASA Technical Memorandum (TM) is intended to provide a snapshot in time of NASA’s current considerations (ground rules and assumptions, functional allocations, logistics) for habitation systems for the lunar surface (non-roving) and Mars transits. As NASA continues to refine the reference designs to meet the needs of an evolving architecture, it is expected that this information will also be updated as a result. Where appropriate, relevant publicly released documents will be referenced to provide further detail. NASA’s human lunar exploration plan under the Artemis program calls for achieving the goal of sending the first woman and first person of color to the surface of the Moon in the mid- 2020s and working toward sustainable exploration by the end of the decade. Working with both commercial and international partners, NASA will establish a permanent human presence on the Moon to uncover new scientific discoveries and lay the foundation for private companies to build a lunar economy. Longer duration missions on the lunar surface and in lunar orbit will also serve as a test bed for technologies to support future Mars exploration campaigns. The agency will use what we learn on the Moon to prepare for humanity's next giant leap – sending astronauts to Mars. NASA intends to establish a sustained lunar presence with the development of the Artemis Base Camp to prove technologies and capabilities that will one day enable humans to live and work on Mars, beginning with core elements including the Lunar Terrain Vehicle (LTV), the Pressurized Rover (PR), the lunar Surface Habitat (SH), power systems, and in-situ resource utilization (ISRU) systems. For in space operations and eventual transport of humans to Mars, NASA will utilize a Mars Transit Habitat (TH). Following deployment, the TH will complete a series of longer duration missions and shakedown testing while docked at Gateway, leveraging Gateway’s habitation redundancy for safety measures. Proposed Gateway-TH missions will far exceed the longest duration cislunar human missions to date. They will be the first operational readiness tests of our long-duration deep space systems, and of the split crew (two crew on the surface, two crew in space) operations that are vital to the approach for the first human Mars mission. Both the SH and TH are major architectural elements of NASA’s Moon to Mars (M2M) approach, each with very different concepts of operation. The SH is intended for use on the lunar surface as a home for astronauts, surface operations base, science facility, hub for communications, extravehicular activity (EVA) equipment repair site, waste processing facility, and supply hub. It serves as an enabler for a sustained surface presence and preparation for partial gravity operations during Mars missions. The SH will be designed to be self-sufficient for operations on the lunar surface. The SH will independently provide several functions, including its own power generation, energy storage capability, sleep quarters, hygiene areas, work areas, and dining areas. It will be capable of communicating with surface assets, orbital assets, and directly with Earth ground stations. It is planned to operate with two crew in the habitat for ~28- day stays with crew swap-outs in which the PR crew of two trades places with the habitat crew. During the swap-out, the habitat will nominally support four crew for a short period of time. For contingency scenarios, the habitat must also be capable of supporting four crew for up to 7 days. The TH will be designed to be capable of up to ~1,200-day Mars missions with the ability to carry all food and supplies needed to support a crew of four for this duration. An assumed Mars mission profile for the TH is to carry crew and supplies for ~850-day roundtrips between Earth and Mars orbit that allows 30-day stays on the Martian surface. To test the systems for this long journey, the TH will be used to extend the duration of missions at Gateway, enabling the orbiting outpost to be used as a Mars analog. These analog missions will be accomplished by attaching the TH to Gateway and conducting lunar surface operations from the TH. The TH may also need to perform free-flying shakedown missions to test out all systems prior to leaving for Mars. The habitat provides many critical functions including: a contingency airlock, crew quarters, galley, hygiene areas, safe haven capability, and science equipment. It can receive docked items from either axial end or on a radial port.

Habitat↗