Results for “Docking” — Page 51

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↗

NASA NTRSDate not supplied

Recovering from On-orbit Anomalies on the Astrobee Free Flyers and its Systems

Since 2019, NASA has been operating three Astrobee free flying robots on board the International Space Station (ISS) providing an autonomous and flexible research platform for national and international payload developers in microgravity and serving as a robotic assistant for astronauts on the ISS. During its use on the ISS, in particular with over 750 hours of free-flyer operation as of March 2022, Astrobee and its Docking Station have encountered multiple software and hardware anomalies. These anomalies were either resolved remotely via software and firmware updates, or, where not possible, with hardware replacements on orbit or by the return of the faulty unit to NASA’s ground facilities for its repair. Despite being inherently designed to be repaired or replaced on orbit, Astrobee and its systems can still suffer anomalies that would be complex enough to disassemble, cause risks of hardware damage, or use excessive crew time to perform the repair in orbit. That was the case for the anomaly the Astrobee unit ‘Honey’ encountered, reason why it needed to be down-massed for repair. One of the most common points of failure was found to be the SD card, which is used for the different Astrobee processors and for the Dock Station. Other comparable SD card anomalies were found also on the Astrobee ground units, which provided useful data in the effort of upgrading their systems. This presentation will focus on 1) The overview of the different faults and anomalies on Astrobee and its systems on orbit and on the ground 2) The processes and procedures implemented to resolve the anomalies 3) The implementation of software updates and hardware upgrades in order to reduce the risk on returning anomalies 4) The lessons learned in increasing Astrobee’s robustness and resilience to such anomalies.

International Space Station↗

NASA NTRS2022

SpaceX-26 Animation - Operations from MAGIK AI-4177: SpX-26 (Launch-6)

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)-26 flight. The animation also displays the current ISS configuration at the time of the flight. Flight SpX-26 includes a SpaceX Cargo Dragon vehicle docked to Node 2 Zenith (N2Z) International Docking Adapter (IDA) and consists of the delivery of the ISS Roll Out Solar Array (IROSA) mounted to an 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.

ISS↗

NASA NTRSDate not supplied

Gateway at the Crossroads of Sustainable Lunar Exploration

The Gateway Program has made substantial design and development progress toward delivering a small, human-tended lunar space station purposefully designed to enable sustainable human exploration. The Program integrates partners and providers organizationally and physically as part of the spacecraft. The Power and Propulsion Element (PPE) and the Habitation and Logistics Outpost (HALO) with the European System Providing Refueling, Infrastructure and Telecommunications (ESPRIT) HALO Lunar Communications System (HLCS) have begun manufacturing the long lead components and will be launched first as a Co-Manifested Vehicle (CMV). The International Habitat (I-Hab) and ESPRIT Refueling Module (ERM) are passing life cycle milestones and include capabilities key for human crewmembers, such as windows, private sleeping quarters, and galley functions. The Logistics Module (LM) may provide a variety of services to Gateway depending on each mission. Requirements for the airlock have been developed, including requests that it support the integrated spacecraft with functions like augmenting heat rejection capabilities, and interfaces with new spacesuits will soon be developed in more detail. As a critical element of the architecture for solar system exploration, Gateway implements key tenets and features of international interoperability standards necessary to operate with multiple visiting vehicles and lunar assets, especially avionics, communications, and docking. Specific choices such as software architecture and standards, power standards, and robotics standards make it possible to utilize heritage or proprietary technology, yet still operate as one spacecraft. Engineering teams are evaluating many possible future missions to be executed at or utilizing the Gateway. The system architecture protects for an evolvable, extensible, and flexible capability. Designing systems robust enough to serve as a cornerstone of exploration activities for decades while remaining adaptable is not without its challenges. The detailed integration activities have revealed challenges and the need to mature key technologies. Refueling is a key component of achieving long life for Gateway, with unique operations to plan, safety concerns to mitigate, and risk reduction activities to conduct to better understand the system. The constraints and impacts of the design of visiting vehicles is also an important concern, with orientation constraints, control of attitude and orbit of the Gateway with docked visiting vehicles. Tradeoffs between robust maintainable systems and lightweight, compact systems must be balanced. Opportunities still exist for adding additional advanced capabilities to increase and extend Gateway’s benefits, such as intravehicular robotics, autonomous Guidance Navigation and Control (GN&C), and augmented control propulsion, heat rejection, or other services.

Molly S Anderson↗

NASA NTRSDate not supplied

Astrobee: Completed, Current, and Future Research using Free Flying Robots on the International Space Station

After four years on the International Space Station (ISS), the Astrobee Research Facility, has completed over 130 Test Sessions logging over 1000 hours of operations. Managed by the NASA ISS Program OZ office and supported by NASA Ames Research Center (ARC) in California, the Astrobee Team maintains three identical free-flying Astrobee robots for research on the ISS. As a technology demonstration platform, the Astrobee Robots are available for Guest Scientists to use for a spectrum of research capabilities. Astrobee, propelled by battery-operated fans, is designed to autonomously operate throughout most of the USOS (US Orbital Segment), with the objective of minimizing astronaut support. Astrobee carries a suite of six cameras, a two degree-of-freedom (DOF) arm with a gripper that can grasp ISS handrails and other objects, and three payload bays that provide power and data for guest science hardware. Astrobee can autonomously execute hours-long flight plans or be teleoperated from the ground or by astronauts. While the Astrobee Team continues to improve mapping and autonomous flight capabilities, one of the main goals of Astrobee Robots is to provide research opportunities for Guest Scientists. The Astrobee Robot Software (ARS) makes extensive use of the open-source Robot Operating System (ROS). The ARS can be used interchangeably with an Astrobee Simulator or as Astrobee’s onboard software. ARS features include autonomous docking and perching, real-time teleoperations from the ground, plan based autonomous tasks, multi Astrobee communication, among other capabilities. Through simulation software and ground testing laboratories, the Astrobee Team is available to support Guest Scientists during development and testing and lead real-time ISS operations. Guest Scientists can participate in this research opportunity following the Guest Science Lifecycle (GSL) shown in Figure 1: Guest Science Lifecycle below. The Astrobee Team and Guest Scientists have complete research including Gecko materials studies, RFID and sound sensing capabilities, student Robotics Programming Challenges, and Free Flyer formation flight investigations. Current science with the Astrobee Robots includes Free Flyer self-toss studies, new docking capabilities, advanced mapping resolution capabilities, and high resolution panoramic imagery. Future Guest scientists and Astrobee Team research will focus on robotics applications for future NASA missions such as Gateway and Artemis and potential experiments involving human-robot interactions. This presentation will focus on four main subjects, 1) completed, current, and future planned research using the Astrobee robots, 2) how Guest Scientist get from conception to the ISS, 3) Astrobee Facility resources available for Guest Science ground testing and real-time ISS operations support, and 4) lessons learned from four years of ISS operations.

Astrobee↗

NASA NTRSDate not supplied

Design, Development, and Use of a Lunar Lander Simulation for NASA's Artemis Program

This paper describes the design, development, and initial use of a generalized and configurable lunar lander simulation to support NASA’s Artemis Program. This simulation is being developed for the Crew Compartment Office (CrewCo) in the Human Landing Systems (HLS) program and is called the HLS CrewCo Lander Simulation (HCLS). The HCLS provides insight into the challenges associated with returning humans to the Moon and the particular difficulties of operating at the Lunar South Pole. The simulation models a generalized integrated lunar landing spacecraft based on a government reference design but can and has been adapted to model vendor specific designs as well. The simulation architecture and tool sets provide a flexible framework that allows for quickly prototyping and evaluating various aspects of a piloted lunar landing system. This includes the modeling of all principal human controlled flight phases: rendezvous and docking with crew transfer systems; docked orbital outpost operations; undocking and lunar transfer; lunar orbital operations; lunar deorbit, descent, and landing (DDL); lunar surface operations; lunar ascent; and return to the orbital outpost. The flexibility of the simulation allows for the integrated evaluation of potential vehicle subsystems, crew displays, guidance and control modes, and trajectory designs. The purpose of the HCLS is not to design the ideal lunar lander, but rather to understand and the strengths and weaknesses of vehicle design choices. This paper describes the basic simulation architecture and discusses the tool sets used to develop the HCLS. This includes a number of open source tool sets and publicly available data sets. This paper also describes some of the early use cases and findings. The primary focus of early HCLS use has been on the manual piloting task to safely get the crew to the desired landing site in case of a failure in the automated guidance system. Several guidance modes and cues have been implemented which allow a pilot to manually fly the vehicle to the targeted landing site starting anywhere from powered descent initiation. It has been a valuable tool for understanding what is required to manually fly a lunar lander as well as giving a sense of the vehicle dynamics, which are much different than anything that is flown on Earth. A number of experienced test pilots have participated in manual piloting evaluations using the HCLS and provided valuable feedback on the piloting task which has been very beneficial to NASA and the HLS program.

James Michael Gentile↗

NASA NTRS2023

Magik Animation of Robotic Operations for Flight SpaceX-29 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)-29 flight. The animation also displays the current ISS configuration at the time of the flight. Flight SpX-29 includes a SpaceX Cargo Dragon vehicle docked to Node 2 Forward (N2F) International Docking Adapter (IDA) and consists of the delivery of AWE (Atmospheric Waves Experiment) and Integrated LCRD LEO User Modem Amplifier optical communications Terminal (ILLUMA-T). Robotic operations shown include the Special Purpose Dexterous Manipulator (SPDM) Trunk extraction of ILLUMA-T and maneuvering to the JEM RMS Handoff position, the SPDM Trunk extraction of AWE, maneuvering to Express Logistics Carrier (ELC) 1 Site 3 to remove Space Test Program - Houston 5 (STP-H5), and the installation of AWE to ELC-1 Site 3. There is no disposal payload for this flight.

EVR↗