Results for “DOCKING” — Page 45

NASA NTRS2014

NASA's Asteroid Redirect Mission: A Robotic Boulder Capture Option for Science, Human Exploration, Resource Utilization, and Planetary Defense

NASA is examining two options for the Asteroid Redirect Mission (ARM), which will return asteroid material to a Lunar Distant Retrograde Orbit (LDRO) using a robotic solar electric propulsion spacecraft, called the Asteroid Redirect Vehicle (ARV). Once the ARV places the asteroid material into the LDRO, a piloted mission will rendezvous and dock with the ARV. After docking, astronauts will conduct two extravehicular activities (EVAs) to inspect and sample the asteroid material before returning to Earth. One option involves capturing an entire small (~4 - 10 m diameter) near-Earth asteroid (NEA) inside a large inflatable bag. However, NASA is also examining another option that entails retrieving a boulder (~1 - 5 m) via robotic manipulators from the surface of a larger (~100+ m) pre-characterized NEA. The Robotic Boulder Capture (RBC) option can leverage robotic mission data to help ensure success by targeting previously (or soon to be) well- characterized NEAs. For example, the data from the Japan Aerospace Exploration Agency's (JAXA) Hayabusa mission has been utilized to develop detailed mission designs that assess options and risks associated with proximity and surface operations. Hayabusa's target NEA, Itokawa, has been identified as a valid target and is known to possess hundreds of appropriately sized boulders on its surface. Further robotic characterization of additional NEAs (e.g., Bennu and 1999 JU3) by NASA's OSIRIS REx and JAXA's Hayabusa 2 missions is planned to begin in 2018. This ARM option reduces mission risk and provides increased benefits for science, human exploration, resource utilization, and planetary defense. Science: The RBC option is an extremely large sample-return mission with the prospect of bringing back many tons of well-characterized asteroid material to the Earth-Moon system. The candidate boulder from the target NEA can be selected based on inputs from the world-wide science community, ensuring that the most scientifically interesting boulder be returned for subsequent sampling. In addition, the material surrounding the boulder can be collected from the surface, thus providing geological contextual information and additional samples of NEA regolith. The robotic manipulators used for capturing the boulder will ensure some of the surface remains undisturbed and that the boulder will retain its structural integrity, which will preserve the context of any samples collected by the astronauts and ensure a high level of science return. Human Exploration: Due to the coherent nature of the boulder that will be collected, entire encapsulation of the asteroid material is not required. This facilitates exploration and sample collection of the boulder by astronauts in a variety of ways. The total time for EVA during the crew portion of the mission is very limited. Current estimates are that each of the two EVAs will only last four hours. The RBC option will allow crew members to have good situational awareness of the work site and quickly identify sample sites of interest. In addition, the samples to be collected can be readily accessed without having to deal with removal of an encapsulation system, which adds extra complexity and risk for the astronauts during EVA. Resource Utilization: One of the most crucial aspects for resource utilization is the identification and collection of appropriate materials (e.g., volatiles, organics, metals, etc.) that contain components of interest. Prior characterization of NEAs is required in order to increase the likelihood that appropriate materials will be returned. Ground-based observations of small (<10 m) NEAs are challenging, but characterization efforts of larger targets have demonstrated that NEAs with volatiles and organics have been identified. Two potential targets for the RBC option (Bennu and 1999 JU3) have been previously identified as potentially rich in resources, and both are already targets of currently planned robotic missions that will characterize their physical properties in great detail. Planetary Defense: The RBC option involves interaction with a well- characterized potentially hazardoussized NEA that would enable NASA to conduct one or more planetary defense demonstrations. The primary method would use the collected boulder to augment the mass of the ARV and perform an Enhanced Gravity Tractor (EGT) demonstration on the NEA. Additionally, other approaches could be demonstrated during the mission, such as Ion Beam Deflection (IBD) and/or observation of a Kinetic Impactor (KI). The relative effectiveness of a slow push-pull method such as the EGT or IBD could be directly compared and contrasted with the results of the more energetic KI method on the target NEA. Conclusions: This boulder option for NASA's ARM can leverage knowledge of previously characterized NEAs from prior robotic missions, which provides more certainty of the target NEA's physical characteristics and reduces mission risk. This increases the return on investment for NASA's future activities with respect to human exploration, resource utilization, and planetary defense.

Abell, P.↗

NASA NTRS2014

NASA's Asteroid Redirect Mission: The Boulder Capture Option

NASA is examining two options for the Asteroid Redirect Mission (ARM), which will return asteroid material to a Lunar Distant Retrograde Orbit (LDRO) using a robotic solar-electric-propulsion spacecraft, called the Asteroid Redirect Vehicle (ARV). Once the ARV places the asteroid material into the LDRO, a piloted mission will rendezvous and dock with the ARV. After docking, astronauts will conduct two extravehicular activities (EVAs) to inspect and sample the asteroid material before returning to Earth. One option involves capturing an entire small (approximately 4-10 m diameter) near-Earth asteroid (NEA) inside a large inflatable bag. However, NASA is examining another option that entails retrieving a boulder (approximately 1-5 m) via robotic manipulators from the surface of a larger (approximately 100+ m) pre-characterized NEA. This option can leverage robotic mission data to help ensure success by targeting previously (or soon to be) well-characterized NEAs. For example, the data from the Hayabusa mission has been utilized to develop detailed mission designs that assess options and risks associated with proximity and surface operations. Hayabusa's target NEA, Itokawa, has been identified as a valid target and is known to possess hundreds of appropriately sized boulders on its surface. Further robotic characterization of additional NEAs (e.g., Bennu and 1999 JU3) by NASA's OSIRIS REx and JAXA's Hayabusa 2 missions is planned to begin in 2018. The boulder option is an extremely large sample‐return mission with the prospect of bringing back many tons of well‐characterized asteroid material to the Earth‐Moon system. The candidate boulder from the target NEA can be selected based on inputs from the world‐wide science community, ensuring that the most scientifically interesting boulder be returned for subsequent sampling. This boulder option for NASA's ARM can leverage knowledge of previously characterized NEAs from prior robotic missions, which provides more certainty of the target NEA's physical characteristics and reduces mission risk. This increases the return on investment for NASA's future activities with respect to science, human exploration, resource utilization, and planetary defense

Abell, Paul A.↗

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↗