Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “autonomous platforms”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

477 records · Page 27

Design and Applications of Tethered Spacecraft Simulators

Small, tethered spacecraft, or space tugs, are a promising space capability. They can be deployed on tethers and used for a wide variety of in-space activities; a large portion of which fall under in-space servicing, assembly, manufacturing (ISAM) functions. This includes functions such as structural mating and assembly, servicing, proximity operations, capture, docking, mating, and relocation. However, there is a great deal of work to be done to raise the Technology Readiness Level (TRL) of the capabilities needed to fully realize these capabilities. The Flat Floor Robotics Lab (FFRL) at NASA’s Marshall Spaceflight Center (MSFC) has been working on space tug development for several years. The eponymous floor is 44 by 86 feet, made from a self-leveling epoxy. This creates an extremely smooth surface that air bearings can float on with very little friction, creating a simulation of zero gravity in a two-dimensional plane. The lab has several platforms of various sizes that act as vehicle simulators for testing sensors, control algorithms, mechanisms, etc. One of these platforms is a small spacecraft simulator, which can be tethered to simulate a space tug. In the last several months, the FFRL team has been working with MSFC’s welding group to conduct a laser beam welding demonstration on air bearing platforms. This demo is utilizing a space tug simulator to fly up to a floating weld platform, where two parts are clamped together and laser welded. The space tug simulator has an air bearing to provide float, as well as several actuated air thrusters to provide propulsion and make the simulator maneuverable. Currently, flights of this simulator are completed by a human operator. An RF hand controller sends signals to both actuate and fire three sets of thrusters on the simulator. This makes any maneuvers of the space tug highly subject to human error, and operators must have dedicated practice time before being able to perform maneuvers with any sufficient reliability. For the current laser welding demonstration, human operated performance is sufficient, but future implementations of in-space welding and other ISAM efforts will require higher precision, reliability, and autonomy. MSFC has funded a project that will allow a small team in the FFRL to develop the next generation of space tug simulator, which will be automated. Closed loop control will allow a user to command a position, or set of positions, that the simulator will be able to “fly” to on its own. This Maneuverable Automated Tethered Spacecraft (MATS) simulator will have configurable design, to allow a variety of payloads and mission configurations to be demonstrated on the air bearing floor. This will be an invaluable test bed for low and mid TRL advancement for space tether mission subsystems, such as more advanced demonstrations of in-space welding. Once one MATSS is constructed and demonstrated effectively, several more can be built, enabling more advanced tether missions; Electric Sail test beds, sensor arrays, and other science-enabling missions. This paper will detail the design and test of the FFRL’s MATS simulator, including efforts to establish closed loop control and autonomous capabilities. It will also detail use cases for this technology, and how it will further develop both develop science and exploration missions.

Space Tethers↗

Localization of Ad-Hoc Lunar Constellations in Communication Failure Modes for Distributed Spacecraft Autonomy

As lunar missions increase in complexity inspired by NASA’s Artemis Program, they will require reliable and sufficient capability of the Position, Navigation, and Timing (PNT) system to support their scientific objectives. In addition, NASA's Commercial Lunar Payload Services (CLPS) program initiates the proliferation of public and private exploration partnerships using small satellites from commercial and private organizations, expanding traditionally confined low Earth orbit to be used for missions beyond geosynchronous orbit (Zucherman et al., 2022). Therefore, the Lunar PNT system is also required to provide navigation services compatible with the smaller platforms being sent by the public and private sectors, like CubeSats. However, traditional approaches to deep space missions’ navigation based on ground radio facilities have difficulties in providing sufficient support for the increasing number of users and communication at a distance from the Earth (Kaplev et al., 2022). In particular, the existing Lunar navigation technologies such as weak signal global positioning system (GPS) and deep space network (DSN) are not able to ensure operations of the upcoming small-scale Lunar missions due to their limitations in localization performance as well as capacity aspects. Another way to provide Lunar PNT service is to create a dedicated Lunar global navigation satellite system (GNSS) constellation, like GNSS systems on Earth. Space agencies like NASA, ESA, and JAXA are now developing the lunar communications relay and navigation systems (LCRNS) and Lunar navigation satellite systems (LNSS). In their systems, satellites will be deployed in moon orbits to provide the communication, positioning, navigation, and timing (CPNT) service at the lunar south pole region where the Artemis base camp will be expected (Murata et al., 2022). Meanwhile, common challenges considered in lunar PNT research arise from poor geometry of the terrestrial GNSS satellites when seen from the lunar user, highly perturbed lunar orbits, and limitations in power, size, and cost of the equipment on lunar satellites (Iiyama et al., 2023). It is also not clear if there will be enough Lunar users to support the cost and resources this would require as the Low-cost surface missions may not be able to support the large power, mass, and weight requirements that these navigation solutions entail (Niemoeller et al., 2022). As an alternative, existing Lunar science and exploration assets could be used to create a low-cost, autonomous, ad-hoc, and on-demand mission-centric Lunar PNT swarm capable of providing PNT services to these low-cost lunar missions (Hagenau et al., 2021). Introducing the non-dedicated and ad-hoc Lunar navigation constellation gives a way to provide PNT services on-demand. The non-dedicated swarm assets of Lunar constellations are designed to localize themselves with minimal interaction with Earth by adding cooperative autonomous localization to lunar missions, freeing up valuable bandwidth and ground segment resources. An autonomous localization of Lunar constellations is based on the concept of the decentralized PNT system with a distributed extended Kalman filter (DEKF) approach to state estimation for minimal onboard operating costs. In the distributed data processing algorithm, computation is broken down and assigned to each satellite, resulting in a considerably decreased computational amount while maintaining the accuracy of the orbit ephemeris and clock offsets as the result of centralized data processing (Wen et al., 2019). The DEKF requires spacecraft to perform two-way ranging operations with each other to communicate simultaneously, leveraging neighbor two-way intersatellite link (ISL) measurements such as pseudoranges to, and relative velocities between, visible satellites as sensor values (Frank et al., 2021). The Lunar autonomous PNT simulation (LAPS) demonstrated the feasibility of orbital asset localization among ad-hoc Lunar small-sat constellations based on the DEKF in Hagenau et al. (2021) and evaluated the matching algorithm proposed by Frank et al. (2021) in scheduling position estimation updates. In previous papers, all assets and measurements are assumed to be always available without consideration of the impact of intermittent and permanent communication failure. This study presents localization performance with increasing levels of network degradation for swarm assets and users to demonstrate the robustness of the decentralized Lunar PNT service in more realistic scenarios. Main issues arising from communication failure include spacecraft permanent or transient loss, antenna failures, message delays, etc. We tested four possible reasons for network degradation for 7 days in 21 satellites frozen with an altitude of 5500 km, evenly spaced around 3 circular, 40 inclination orbital planes where each spacecraft has two directional antennas. As anchor nodes with an independent estimate of their position are required in the DEKF approach, two ground nodes in each pole and one node in the gateway were implemented in the simulation. First, the most probable failure scenario involves the loss of a single spacecraft due to solar interference and technical malfunctions of the assets. Losing the availability of a single spacecraft means losing the two-way ISL measurement of the asset in the DEKF update. In order to provide the best possible quality of PNT service with limited time and resources, the distributed Lunar constellations must schedule the communication activities. The scheduler leverages mixed-integer linear programming (MILP) for the coordination and scheduling of the desired “as-needed” localization service (Niemoeller et al., 2022). We assume the scheduler has completely excluded the spacecraft information before the DEKF update in the failure scenario. When a random spacecraft has been turned off at a specific time, the robustness of the autonomous Lunar PNT system is evaluated. The simulation results give an 11.5% degradation in median position accuracy compared to the idealized performance excluding the asset loss. Second, a large number of assets may vanish due to major hardware problems or meteor strikes around the moon. A multiple spacecraft loss can degrade the localization performance very fast by losing the communication ability to do cross-plane measurements and in-plane measurements in a 3-plane constellation. When the matching-based scheduler is aware of ISL availability, we investigate a large number of in-plane and cross-plane asset vanishments both in close proximity and equally spaced throughout the orbital plane. According to the simulations, the loss of in-plane measurements gives 40.2% degradation while cross-plane measurements degrade 50.5% of asset localization performance among available assets. Therefore, it is concluded that cross-plane measurements are more important in improving the position estimation accuracy. Third, spacecraft failure information can be lost due to the internal message delay, resulting in the DEKF update scheduler to solve the matching problem with unavailable assets. The DEKF update cycle is comprised of network setup, communication, and computations where a global broadcast network and a 2-way ISL network setup take 6 minutes in total (Frank et al., 2021). Once the broadcast network successfully transmits and receives information, a random spacecraft may lose its availability right before solving the matching problem. This means the matching solution is no longer optimal, resulting in degradation in the localization performance. A numerical assessment shows the matching-based scheduler with knowing failure holds 11.5% of position accuracy degradation, whereas the scheduler without knowing failure gives 34% degraded localization performance without asset loss. Fourth, a transient loss of a single or multiple spacecraft may occur due to their antenna outages. After losing the two-way ISL availability for a few DEKF update cycles, the availability of spacecraft can easily be recovered as their states have been independently updated using measurements from anchor nodes. It is likely that the longer failure will result in worse localization performance. We have tested the transient failure of a random single asset for 30 min in the simulation, which is losing 3 update cycles in the DEKF system. From the simulation results, the position accuracy has been degraded to 4.84% which is better than the degraded localization performance of 11.5% from the permanent loss scenario among available assets. In conclusion, the autonomous Lunar PNT system based on the DEKF approach shows the ability to maintain resilience and robustness in the possible communication failure scenarios, ensuring that localization accuracy is preserved across various network degradation and outages. Future studies on investigating user localization performance near the South Pole and the broadcast network system will be continued in the following months.

Yeji Kim↗

Cloud Absorption Radiometer Autonomous Navigation System - CANS

CAR (cloud absorption radiometer) acquires spatial reference data from host aircraft navigation systems. This poses various problems during CAR data reduction, including navigation data format, accuracy of position data, accuracy of airframe inertial data, and navigation data rate. Incorporating its own navigation system, which included GPS (Global Positioning System), roll axis inertia and rates, and three axis acceleration, CANS expedites data reduction and increases the accuracy of the CAR end data product. CANS provides a self-contained navigation system for the CAR, using inertial reference and GPS positional information. The intent of the software application was to correct the sensor with respect to aircraft roll in real time based upon inputs from a precision navigation sensor. In addition, the navigation information (including GPS position), attitude data, and sensor position details are all streamed to a remote system for recording and later analysis. CANS comprises a commercially available inertial navigation system with integral GPS capability (Attitude Heading Reference System AHRS) integrated into the CAR support structure and data system. The unit is attached to the bottom of the tripod support structure. The related GPS antenna is located on the P-3 radome immediately above the CAR. The AHRS unit provides a RS-232 data stream containing global position and inertial attitude and velocity data to the CAR, which is recorded concurrently with the CAR data. This independence from aircraft navigation input provides for position and inertial state data that accounts for very small changes in aircraft attitude and position, sensed at the CAR location as opposed to aircraft state sensors typically installed close to the aircraft center of gravity. More accurate positional data enables quicker CAR data reduction with better resolution. The CANS software operates in two modes: initialization/calibration and operational. In the initialization/calibration mode, the software aligns the precision navigation sensors and initializes the communications interfaces with the sensor and the remote computing system. It also monitors the navigation data state for quality and ensures that the system maintains the required fidelity for attitude and positional information. In the operational mode, the software runs at 12.5 Hz and gathers the required navigation/attitude data, computes the required sensor correction values, and then commands the sensor to the required roll correction. In this manner, the sensor will stay very near to vertical at all times, greatly improving the resulting collected data and imagery. CANS greatly improves quality of resulting imagery and data collected. In addition, the software component of the system outputs a concisely formatted, high-speed data stream that can be used for further science data processing. This precision, time-stamped data also can benefit other instruments on the same aircraft platform by providing extra information from the mission flight.

Kahle, Duncan↗

CLINICAL DECISION SUPPORT: PATH TO FUNCTIONAL REQUIREMENTS

Long-duration, deep-space exploration missions present significant challenges to crew health and performance. These challenges include the individual and combined effects of microgravity, radiation exposure, isolation, limited resources (mass, volume, power, data and crew time), limited options for evacuation and those associated with delayed or constrained communications, all of which demand greater crew autonomy. Specifically, as the communication delays intensify the further we explore space, the unqualified need for Earth-independent medical operations focused on autonomous diagnosis, treatment and prevention will be key to mission continuation and success. To augment the requisite knowledge, skills and abilities (KSAs) of a time-constrained crew operating under stressful conditions, combatting fatigue, and facing a potential medical crisis, a robust clinical decision support system (CDSS) is a probable solution that would facilitate, guide and inform Earth-independent medical operations, while assisting crewmembers through various clinical presentations. The Exploration Medical Capability (ExMC) Element of the Human Research Program (HRP) is expanding the boundaries of space medical systems to advance the care of astronauts on future exploration missions beyond low Earth orbit. ExMC is actively identifying and testing next-generation medical care and crew health maintenance technologies. The Clinical Decision Support (CDS) project addresses gap Medical-701 within the Inflight Medical Conditions risk: “Enhance medical capabilities within an exploration medical system.” Though mass, volume, and power will face increasing constraints, the projected computational capabilities of spacecraft systems will increase exponentially as information technology continues to advance this decade and beyond. Hence, data, software and computational resources will play an essential and synergistic role in maintaining crew health, wellness and performance in deep space missions. The focus of the CDS project is to develop recommended requirements for an in-vehicle CDSS that acts as a ‘virtual assistant’ for delivering optimal health, performance and medical care during exploration missions. The CDSS is envisioned as an integrated, software-based tool deployed on a laptop computer or handheld device. The CDSS will assist the crew and ground support when interacting with knowledge/databases (e.g. records, pharmacy, schedule), instrumentation (e.g. imaging, physiological monitoring devices), and habitat (e.g. wellness system, task performance system) and vehicle systems (e.g. environmental system, communication system). In addition, the human interface will employ a context-based approach that accounts for the crew’s situation. Thus, extraneous and clinically/operationally non-relevant information are reduced to avoid an increase in cognitive load. The framework of an ideal spaceflight CDSS is to include core and advanced analytical features that incorporate work from collaborators yet maintain a flexible platform for integrating new technology in the future. In fiscal year 2021 (FY21), the CDS project identified requirements through two primary mechanisms: (i) the development of software implementation prototypes and (ii) the application of systems engineering processes. The CDS project developed and tested a series of increasingly complex system prototypes that were based on use cases derived from the CDSS concept of operations (ConOps). These software implementations yielded insights on CDSS functionality as well as lessons learned that provided the initial requirements for CDSS capability. By applying a systems engineering (SE) approach, medical scenarios provided in the ConOps and the use cases for software implementation underwent functional decomposition to identify CDSS functionality. Also, systems-based modeling language (SysML) tools such as activity diagrams were developed from the same ConOps and use cases to identify CDSS functionality. The lessons learned from software implementation defined both specific requirements and broad areas of requirements. Within these defined broad requirement areas, further analysis of the SE products identified specific capability that resulted in the final functional requirements. In summary, the software prototypes, functional decomposition of the ConOps and use cases, and SysML diagrams provided the basis for the CDSS requirements developed in FY21. In the upcoming year, these requirements will be refined for their final ExMC baseline review in latter FY22.

clinical decision support↗

Clinical Decision Support: Path to Functional Requirements

Long-duration, deep-space exploration missions present significant challenges to crew health and performance. These challenges include the individual and combined effects of microgravity, radiation exposure, isolation, limited resources (mass, volume, power, data and crew time), limited options for evacuation and those associated with delayed or constrained communications, all of which demand greater crew autonomy. Specifically, as the communication delays intensify the further we explore space, the unqualified need for Earth-independent medical operations focused on autonomous diagnosis, treatment and prevention will be key to mission continuation and success. To augment the requisite knowledge, skills and abilities (KSAs) of a time-constrained crew operating under stressful conditions, combatting fatigue, and facing a potential medical crisis, a robust clinical decision support system (CDSS) is a probable solution that would facilitate, guide and inform Earth-independent medical operations, while assisting crewmembers through various clinical presentations. The Exploration Medical Capability (ExMC) Element of the Human Research Program (HRP) is expanding the boundaries of space medical systems to advance the care of astronauts on future exploration missions beyond low Earth orbit. ExMC is actively identifying and testing next-generation medical care and crew health maintenance technologies. The Clinical Decision Support (CDS) project addresses gap Medical-701 within the Inflight Medical Conditions risk: “Enhance medical capabilities within an exploration medical system.” Though mass, volume, and power will face increasing constraints, the projected computational capabilities of spacecraft systems will increase exponentially as information technology continues to advance this decade and beyond. Hence, data, software and computational resources will play an essential and synergistic role in maintaining crew health, wellness and performance in deep space missions. The focus of the CDS project is to develop recommended requirements for an in-vehicle CDSS that acts as a ‘virtual assistant’ for delivering optimal health, performance and medical care during exploration missions. The CDSS is envisioned as an integrated, software-based tool deployed on a laptop computer or handheld device. The CDSS will assist the crew and ground support when interacting with knowledge/databases (e.g. records, pharmacy, schedule), instrumentation (e.g. imaging, physiological monitoring devices), and habitat (e.g. wellness system, task performance system) and vehicle systems (e.g. environmental system, communication system). In addition, the human interface will employ a context-based approach that accounts for the crew’s situation. Thus, extraneous and clinically/operationally non-relevant information are reduced to avoid an increase in cognitive load. The framework of an ideal spaceflight CDSS is to include core and advanced analytical features that incorporate work from collaborators yet maintain a flexible platform for integrating new technology in the future. In fiscal year 2021 (FY21), the CDS project identified requirements through two primary mechanisms: (i) the development of software implementation prototypes and (ii) the application of systems engineering processes. The CDS project developed and tested a series of increasingly complex system prototypes that were based on use cases derived from the CDSS concept of operations (ConOps). These software implementations yielded insights on CDSS functionality as well as lessons learned that provided the initial requirements for CDSS capability. By applying a systems engineering (SE) approach, medical scenarios provided in the ConOps and the use cases for software implementation underwent functional decomposition to identify CDSS functionality. Also, systems-based modeling language (SysML) tools such as activity diagrams were developed from the same ConOps and use cases to identify CDSS functionality. The lessons learned from software implementation defined both specific requirements and broad areas of requirements. Within these defined broad requirement areas, further analysis of the SE products identified specific capability that resulted in the final functional requirements. In summary, the software prototypes, functional decomposition of the ConOps and use cases, and SysML diagrams provided the basis for the CDSS requirements developed in FY21. In the upcoming year, these requirements will be refined for their final ExMC baseline review in latter FY22.

Clinical decision support↗

Spaceflight Biospecimen and Data Sharing in Support of Science Discovery and Exploration

For decades, NASA and international partners have conducted biological experiments in space to understand effects of spaceflight and address potential hazards. To enable spaceflight back to the Moon, and then to Mars and beyond, it is imperative to further understand basic science and health risks associated with spaceflight, along with developing countermeasures. The sending of experiments and organisms into space is a costly endeavor. To maximize scientific return, sharing with the scientific community both space-flown biospecimens and data from completed experiments is essential. New fundamental, applied, and bioinformatic science insights can be gained from specimen and data sharing efforts. Data reuse enables spaceflight health risk modeling, analyzing adverse outcomes across spaceflight hazards, and deep space autonomous support for the flight medical officer. Space-flown biospecimens not required by mission Principal Investigators are regularly archived and made available for scientific request. The largest biorepository of these samples are found within NASA’s Institutional Scientific Collection at Ames Research Center (ISC-ARC), which stores over 32,000 specimens mostly from Shuttle and International Space Station (ISS) missions, but also some ground-based analog samples. The Ames Life Sciences Data Archive manages the ISC-ARC. Tissues are predominantly from mice and rats, though samples are also available from bacteria and quail. Only a handful of other similar collections exist worldwide. Rodent biospecimens exposed to simulated space radiation at Brookhaven National Laboratory are archived under the purview of NASA HRP Space Radiation Element. Microbial collection and analyses from 20 years of routine environmental monitoring of air, surfaces, and water systems of the ISS were performed to ensure a safe environment for astronauts. Samples from the ISC-ARC, space radiation and microbial collections are searchable and requestable through the NASA Life Sciences Data Archive (LSDA). Decades of planetary protection microbial isolates derived from spacecraft bioburden are archived in JPL’s microbial collection. Rodent biospecimens from spaceflight investigations conducted by the Japan Aerospace Exploration Agency (JAXA) are archived and available at the JAXA Biorepository at Tsukuba Space Center. The Russian Institute of Biomedical Problems also has a collection of animal, microbial, cellular, and fungi available for research from ground analog experiments. Several data repositories exist for scientists to utilize. The LSDA is the primary NASA source of life sciences research data and information. It contains decades of spaceflight and ground-analog research involving human, microbial, cellular, plant, and animal subjects. Data is collected from NASA-funded investigations through the Human Research Program and the Space Biology Program. The NASA Lifetime Surveillance of Astronaut Health collects and grants access to clinical and occupational health monitoring data from astronauts, with a list and description of data collected available for request through the LSDA. NASA GeneLab at ARC collects genomic, transcriptomic, proteomic, and metabolomic data from any species. It is a repository and platform for collaborative open-science bioinformatic approaches. JAXA is establishing an ‘omics-based repository in collaboration with the Tohoku Medical Megabank (ToMMo), called the JAXA-ToMMo Integrated Biobank for Space Life Science. Overall, the sharing of these biospecimen and data resources can assist researchers worldwide in understanding spaceflight effects on biology, along with enabling next generation data science applications for space exploration platforms. Websites: https://lsda.jsc.nasa.gov/ ; https://www.nasa.gov/ames/research/space-biosciences/isc-bsp ; https://www.nasa.gov/ames/research/space-biosciences/alsda

Ryan T. Scott↗

Tracking Object Existence From an Autonomous Patrol Vehicle

An autonomous vehicle patrols a large region, during which an algorithm receives measurements of detected potential objects within its sensor range. The goal of the algorithm is to track all objects in the region over time. This problem differs from traditional multi-target tracking scenarios because the region of interest is much larger than the sensor range and relies on the movement of the sensor through this region for coverage. The goal is to know whether anything has changed between visits to the same location. In particular, two kinds of alert conditions must be detected: (1) a previously detected object has disappeared and (2) a new object has appeared in a location already checked. For the time an object is within sensor range, the object can be assumed to remain stationary, changing position only between visits. The problem is difficult because the upstream object detection processing is likely to make many errors, resulting in heavy clutter (false positives) and missed detections (false negatives), and because only noisy, bearings-only measurements are available. This work has three main goals: (1) Associate incoming measurements with known objects or mark them as new objects or false positives, as appropriate. For this, a multiple hypothesis tracker was adapted to this scenario. (2) Localize the objects using multiple bearings-only measurements to provide estimates of global position (e.g., latitude and longitude). A nonlinear Kalman filter extension provides these 2D position estimates using the 1D measurements. (3) Calculate the probability that a suspected object truly exists (in the estimated position), and determine whether alert conditions have been triggered (for new objects or disappeared objects). The concept of a probability of existence was created, and a new Bayesian method for updating this probability at each time step was developed. A probabilistic multiple hypothesis approach is chosen because of its superiority in handling the uncertainty arising from errors in sensors and upstream processes. However, traditional target tracking methods typically assume a stationary detection volume of interest, whereas in this case, one must make adjustments for being able to see only a small portion of the region of interest and understand when an alert situation has occurred. To track object existence inside and outside the vehicle's sensor range, a probability of existence was defined for each hypothesized object, and this value was updated at every time step in a Bayesian manner based on expected characteristics of the sensor and object and whether that object has been detected in the most recent time step. Then, this value feeds into a sequential probability ratio test (SPRT) to determine the status of the object (suspected, confirmed, or deleted). Alerts are sent upon selected status transitions. Additionally, in order to track objects that move in and out of sensor range and update the probability of existence appropriately a variable probability detection has been defined and the hypothesis probability equations have been re-derived to accommodate this change. Unsupervised object tracking is a pervasive issue in automated perception systems. This work could apply to any mobile platform (ground vehicle, sea vessel, air vehicle, or orbiter) that intermittently revisits regions of interest and needs to determine whether anything interesting has changed.

Wolf, Michael↗

The Iodine Satellite (iSat) Propellant Feed System - Design and Demonstration

CUBESATS are relatively new spacecraft platforms that are typically deployed from a launch vehicle as a secondary payload, providing low-cost access to space for a wide range of end-users. These satellites are comprised of building blocks having dimensions of 10x10x10 cm3 and a mass of 1.33 kg (a 1-U size). While providing low-cost access to space, a major operational limitation is the lack of a propulsion system that can fit within a CubeSat and is capable of executing high Delta V maneuvers. This makes it difficult to use CubeSats on missions requiring certain types of maneuvers (i.e. formation flying, spacecraft rendezvous). Work has been performed investigating the use of iodine as a propellant for Hall-effect thrusters (HETs) that could subsequently be used to provide a high specific impulse path to CubeSat propulsion. One of the systems under development to support such a technology is the propellant feed system, which must be capable of storing solid iodine propellant, applying heat to sublime the stored solid into the vapor phase, and then control the flow of low-pressure gaseous iodine to both the thruster and cathode. In a test conducted in 2016, a first-generation iodine propellant feed system was integrated with a cathode and Hall thruster. While this test had to be terminated, the feed system in this first test was able to support both cathode and integrated cathode and thruster operation prior to the termination of the test. In the present paper, we describe work performed since that initial integrated test. The effort uses lessons learned from the previous integrated test, retiring risk associated with the iodine propellant feed system, answering open design-space questions, and demonstrating iodine flow control in an integrated system. The work is undertaken at both the component level and then at the integrated subsystem level to systematically improve the feed system design, improving the hardware fidelity so the appearance and operation of the system are as flight-like as possible. At the component level, the work focuses on the propellant tank, the feed system tubing, the valves used to control the flow to the cathode and thruster, and the heaters that maintain the temperature of the flowpaths and keep iodine from redepositing and clogging the system. Work on the propellant reservoir focuses on fabricating a tank that matches the geometry of the flight design, which allows for the identification of flight tank fabrication issues that may arise and permits thermal testing of a tank possessing the same size and thermal mass as the flight design, which can be used to anchor thermal modeling of the component. This is critical for finalizing the tank heater power requirements that feed into the heater design. All metallic materials in the feed system are hastelloy or Inconel, as these materials are resistant to chemical attack by the highly-reactive iodine vapor. The tubing in the iodine feed system must possess ports to permit a neutral gas purge of the system that clear impurities after iodine is loaded into the propellant tank. A procedure is discussed whereby these ports are crimped and sealed after the purge process is completed so as to not re-expose the iodine system to air. The valves are a critical component for control of the flow to the thruster and the cathode. Significant effort has gone into upgrading the materials of the valves to make them more resistant to chemical attack and into developing an understanding of the use of these valves during the startup and operation of the cathode and thruster. The heaters that line the entire feed system are designed to draw minimal power from the power processing unit (PPU) while still having the capacity to maintain all the feed system components at the temperatures required to discourage iodine deposition inside components downstream of the propellant tank exit. The heaters possess two separate resistive traces, giving the design redundancy should a failure occur in the primary heater circuit of one of the heater zones. The task of operating a feed system in conjunction with a thruster and cathode is undertaken in a series of sub-steps. The system is first assembled and operated on xenon gas, using the valves for cathode startup and thruster control based on measurement of the discharge current. After startup and control on xenon are demonstrated, the thruster will be transitioned to iodine operation, demonstrating thruster startup and feed system control while using a xenon-fed cathode. Finally, the last step is to integrate an iodine-compatible cathode with the system, demonstrate autonomous cathode start-up with open-loop control and thruster start-up with closed-loop control for multiple cycles.

Polzin, Kurt A.↗

A Notional Artemis Lunar Surface Exploration Package (ArLSEP) based on the Gandalf Staff Platform

Introduction: The Artemis program is planning to deliver crew and cargo to the lunar surface, but there is no current package for supporting lunar in-struments and experiments similar to the Apollo Lunar Surface Exploration Package (ALSEP). This abstract provides a possible concept for such a package using the Gandalf Staff Platform as a common core. Gandalf Staff: The Gandalf Staff is an early prototype system developed over FY’21/FY’22 using NASA Science Technology Mission Directorate (STMD) Center Information Fund (CIF) grants to de-sign, build and test “proof-of-concept” components. These components include a 24v battery powered monopole that powers a suite of subsystems, including a Graphical User Interface (GUI) for crew, surface voice and data communications, Lunar Search and Rescue (LunaSAR) navigation and communications, LiDAR, field site external lighting, 360-degree camera, and a geothermal instrument for measuring sub-surface temperature gradient. The staff can be carried independently by an Extra-Vehicular Activity (EVA) astronaut, or can be mounted into a tripod for “hands free” support at a surface site being investigated. The staff can be attached to an external solar array and power storage system for long-duration operations. [1,2] ALSEP: An ASLEP flew on each mission Apollo 12 to Apollo 17. For Apollo 11, a simplified packaged called the Early Apollo Scientific Experiments Pack-age (EASEP) was flown. Each package included a “Central Station” that provided the power and communications connected to a variety of instruments and sensors. The power was provided by a Radioisotope Thermoelectric Generator (RTG) fueled by Plutoni-um-238 generating 70 watts of power (initially, decayed over time) [3]. The communications system provide for direct to Earth data transfer from the lunar surface. Each pack-age was stowed externally in the Lunar Module (LM) Scientific Equipment (SEQ) bay with a mass up to 163 kg (Apollo 17). The crew unloaded the ALSEP from the LM and deployed the instruments on the lunar surface. Although designed to operate for only 1 year, many sites operated for up to 8 years successfully [4]. The Active Seismic Experiment (ASE) included 3 geophones for detecting seismic waves created by mortars and thumpers deployed by the crew. Other active experiments measured the lunar atmosphere, the heat flow in the subsurface, the lunar gravity and potential gravity waves, the lunar magnetic field, the solar wind and plasma interactions in cislunar space. Passive experiments included collectors for dust and cosmic rays, and retroreflectors for precise measurements of distance using a laser from Earth. The ALSEP program continues to generate insights into lunar formation and evolution. ArLSEP Concepts: The lunar surface science package for the Artemis program will hopefully exceed the capability of the ALSEP. There are multiple issues for discussion leading to the design of a new ArLSEP, needing requirements definition from the science community, NASA mission architecture, and NASA budget planners. 1. Delivery Mechanism Two possible projects currently provide capability to deliver scientific cargo to the lunar surface: 1) the Commercial Lunar Payload Services (CLPS) [5] and the Human Landing System (HLS) [6, 7]. Each project is controlled by a different organization within NASA and budgeted with different criteria although both support lunar exploration. The HLS system delivers crew (and potentially cargo) to human landing sites. If an ArLSEP is “predeployed” to such a site, the design must include power (either from the vehicle or independently) to keep the electronics functioning until deployed by the crew. If an ArLSEP is delivered on a vehicle after the crew is present on the lunar surface, safety protocols require adequate distance from the humans for impact from descent propelled sur-face regolith ejecta. This distance can not exceed the capability of the crew to walk (if no rover) to the vehicle for ArLSEP deployment. 2. Overall Guidelines The general design of ArLSEP will likely follow the ALSEP with a common system for communications and power; however, significant architecture differences between Apollo and Artemis exist. Power: The RTG will not be available for early Artemis missions nor likely follow-on Lunar Exploration Transportation Services (LETS) missions [8]. Thus, ArLSEP power must be supplied by solar arrays with sufficient battery capability to “keep alive” necessary electronics during any lunar surface eclipse period. Communication: The Artemis program is developing a series of communications satellites for lunar orbit to provide surface transmission of data and voice to Earth. Called “LunaNET”, this network is component useful for ArLSEP since south polar locations may not always have direct “line-of-sight” to Earth [9]. 3. Concept of Operations (ConOps) The general ConOps for ArLSEP is to deliver the package to lunar surface before the crew arrives, and then have the crew deploy the package after some period of time. This requires coordinated design (for power systems) and launch window (for schedule) on both the cargo and crew missions. Once the ArLSEP is deployed, it will operate autonomously for a number of years. It should be designed to be EVA compatible for crew maintenance and upgrade. 4. Notional Design (for discussion purpose only) The landing site near the South Pole is expected to have no eclipse cycle exceeding 5 days, so the “keep alive” power is 144 hours (6 days to include margin). A 12v ArLSEP will use rechargeable LiFePO4 cells, which are common in the Electric Vehicle (EV) industry. With a current of 5 amps and a 125 watt system, the mass is about 90kg. The comm. system and structure adds another 10kg, thus the “Central Station” is approximately 100kg. The solar power is collected on four arrays (each 2m above the surface), and the entire ArLSEP is designed to stow in a 2m x 1m x 1m volume. The experiment and instrument design will vary for each installation and add mass to the total (although they are expected to fit within the 2m3 volume). Seismic wave generation will likely not be provided with mortars, thus an electric “thumper” will be required. Active instruments such as imaging systems and sensing instruments will benefit from the additional power and communication capability provided by ArLSEP. Passive systems such as retroreflectors, witness plates, and cosmic dust collectors can be added to either the landing vehicle and/or the ArLSEP. With repeated HLS missions to the same human site, the ArLSEP can be expanded and easily maintained for long duration science collection on the lunar surface.

ALSEP↗