Search NASA⌕ Search

Engineering topics

Evan J Anzalone

Publications and source records attributed to Evan J Anzalone.

Safe and Precise Landing at Lunar Sites

The Artemis missions will land astronauts on the lunar surface to leverage the unmatched capabilities of human explorers. These landings will commence long-term exploration and utilization of the Moon by NASA, industry, and international partners for the benefit of all.

Tamra George↗

Hardware Verification and Validation for a Navigation Sensor Software Model in Support of Flight Vehicle Performance Analysis

… or, “It’s in the details, how to make complicated software perform like complicated hardware.” In attempts to minimize development time and quickly build an operational vehicle, NASA’s Space Launch System (SLS) has had to be intentional about integrated testing. Constraints on budget and schedule have required balance between testing needs and the desire for an integrated flight vehicle as soon as possible. To provide key insights early in design and analysis cycles, a large amount of effort has shifted into maturing and validating models at the component level with integrated testing as a means to validate their integration. In terms of SLS Navigation, this, and the model-based design approach have pushed explicit requirements for sensor models to be validated against flight hardware to high precision. This paper covers the approach taken to verify and validate the models for the two key navigation sensors on the SLS vehicle, the Redundant Inertial Navigation Sensor and the Rate Gyro Assembly. These models are used in performance evaluation, fault detection, and operations development extensively. Using a mix of data from hardware vendor documentation and testing reports, limited in-house testing, and integration activities, these models were able to be validated against flight hardware at multiple levels, from the internal software design to statistical behavior at the raw sensor and integrated box levels. The high level of insight into the hardware elements is instrumental to support flight certification activities and building confidence in SLS Navigation capability. Focused testing enabled additional insight and validation that proved invaluable and the resulting insights were used to focus and mature models. Additionally, of having validated performance-based hardware models enables a wide breadth of activities including detailed fault detection studies and integration into future vehicle frameworks, such as an upper stage and provide a valuable asset to continued SLS analysis and design.

Evan J Anzalone↗

Hardware Verification and Validation for a Navigation Sensor Software Model in Support of Flight Vehicle Performance Analysis

… or, “It’s in the details, how to make complicated software perform like complicated hardware.” In attempts to minimize development time and quickly build an operational vehicle, NASA’s Space Launch System (SLS) has had to be intentional about integrated testing. Constraints on budget and schedule have required balance between testing needs and the desire for an integrated flight vehicle as soon as possible. To provide key insights early in design and analysis cycles, a large amount of effort has shifted into maturing and validating models at the component level with integrated testing as a means to validate their integration. In terms of SLS Navigation, this, and the model-based design approach have pushed explicit requirements for sensor models to be validated against flight hardware to high precision. This paper covers the approach taken to verify and validate the models for the two key navigation sensors on the SLS vehicle, the Redundant Inertial Navigation Sensor and the Rate Gyro Assembly. These models are used in performance evaluation, fault detection, and operations development extensively. Using a mix of data from hardware vendor documentation and testing reports, limited in-house testing, and integration activities, these models were able to be validated against flight hardware at multiple levels, from the internal software design to statistical behavior at the raw sensor and integrated box levels. The high level of insight into the hardware elements is instrumental to support flight certification activities and building confidence in SLS Navigation capability. Focused testing enabled additional insight and validation that proved invaluable and the resulting insights were used to focus and mature models. Additionally, of having validated performance-based hardware models enables a wide breadth of activities including detailed fault detection studies and integration into future vehicle frameworks, such as an upper stage and provide a valuable asset to continued SLS analysis and design.

Thomas Park↗

Architecture Options for Navigation in Cislunar Space for Human Landing System Vehicles

As part of architecture studies and insight analysis focused on requirements development into Human Landing System lunar architecture designs, multiple studies are underway to understand the sensitivities and options for achieving high precision landing on the lunar surface. The baseline approach utilizes a combination of multiple sensors to capture autonomous state observations of the lander with respect to the lunar surface. These systems are typically constrained in terms of operational altitudes by parameters such as onboard map size, camera focus, or sensor transmitted power (for altimeter observations). While these sensor suites do enable high precision landing, they are typically very complex and expensive. For a human-rated vehicle, fault detection algorithms are needed in addition to redundant sensors drive additional design complexity. Conversely, for these early missions, mass performance is key, so extended analysis is required to identify numbers of sensors, their ideal placement, and integration algorithms. A key part of this analysis is to help identify key sensor suites and options to help alleviate this design tension. An alternate approach is to take advantage and build out in-situ assets to allow for GPS-like navigation within the lunar regime through the use of navigation references or beacons. This can be achieved through the integration of navigation services into potential relays and pre-placed lunar surface assets. This research focuses on the capability of this infrastructure to support navigation in all areas of cislunar space such as: approach to the moon, in orbit around the moon, and ascent/descent operations to the surface. An augmented state linear covariance analysis (LinCov) and navigation state covariance analysis (NavCov) tools were used to assess a variety of navigation reference locations and how they can support vehicle operations through both understanding of state uncertainties and trajectory dispersions. This research helps to supplement existing studies focused on communication link analysis by providing additional insight into specific vehicle operational scenarios that are tied closely to potential Human Landing System scenarios. Key aspect of this analysis focus on the sensitivity to state knowledge of the references, the accuracy of inter-asset measurements, and placement in support of the various scenarios.

Evan J Anzalone↗

Ground-Testing of One-Way Ranging from a Lunar Beacon Demonstrator Payload (Lunar Node -1)

Similar to lighthouses providing navigation aids and awareness to ships sailing along the coast, in-situ navigation beacons can be used to provide redundancy, awareness, and improved onboard position knowledge for vehicles operating in and around the lunar sphere of influence. Lunar Node - 1 is a radio frequency navigation beacon that is manifested on Intuitive Machines' NOVA-C lunar lander flight in 2022 for operation during cruise and from a mid-latitude landing location. This payload utilizes commercial components developed for Low Earth Orbit applications and packages them into an integrated package to provide a navigation reference signal as part of a large lunar-centric navigation network. As part of its operations, Deep Space Network ground stations will operate as the notional "user" of this service, allowing for performance characterization, calibration, and operation of the beacon payload. This paper provides an overview of the payload, how its fits into a large concept of operations, and ground testing results. A specific focus is on ground testing of the payload with DSN ground receivers as part of Radio Frequency (RF) Compatibility Testing. A primary goal of this testing was to characterize a pseudo-noise ranging code sequence generated by the payload. The results in this paper define the testing sequence, unique operational constraints with two-way ranging ground equipment, and applications of the ground-derived error model to predicted in-flight performance of the ranging code.

Evan J Anzalone↗

Lunar Node – 1: Initial Flight Results and the Role of Surface Psuedolites in Lunar Navigation

On February 22, 2024, Intuitive Machines NOVA-C lander, nick-named Odysseus, landed on the lunar surface, carrying with it a cadre of NASA scientific and technology demonstration payloads. These payloads and missions marked the first delivery of NASA instruments to operate from the lunar surface since the Apollo landings. One of these payloads is Lunar Node -1 (LN-1), a navigation beacon demonstration mission. The payload was designed and built by NASA’s Marshall Space Flight Center. The payload’s main goal was to demonstrate and provide insight into the use of lunar surface-based radio navigation aids. As part of the mission, LN-1 successfully conducted multiple one-way transmissions from the NOVA-C vehicle to Deep Space Network ground receivers using its onboard S-band transmitter, while being disciplined by an onboard Space Chip Scale Atomic Clock. LN-1 transmitted to DSN on an almost daily basis during transit to the moon, including two surface passes. The payload was originally plan to conduct 7-10 days of surface operation as an always-on beacon. These passes focused on evaluating two main navigation approaches: performance and stability of ranging using time-based transfer techniques on a cubesat size and grade platform, as well as one-way psuedonoise ranging approaches. To assess performance, the measurements were compared to independent navigation solutions using multiple approaches including: one-way Doppler tracking, two-way Doppler Tracking, and visual verification of the landing location provided by visual observations from orbital platforms. While the mission only conducted limited surface operations, the data provides some initial insight to performance form the lunar surface. These results are compared with initial ground-based testing as well as continued evaluation of the flight-space platform using multiple grades of oscillators for maintaining clock and frequency stability. These focus on the timing stability of platform in a deep-space environment as well variations in state determination. Given these insights, this paper provides additional description and evaluation of how this approach can be utilized as part of a broader lunar navigation architecture, such as being developed and deployed across multiple international space agencies. Analysis is provided to develop overall timing requirements and assessment of operational scenarios, such as orbit and surface location determination. In addition, the results support discussion as to how surface pseudolites could best be used within existing standard signal definitions, such as defined in the LunaNet Interoperability Specifications. This will consider concerns such as the near-/far- problem as well as operational considerations, including whether a beacon is better suited as two- or one-way ranging platform. The use cases are focused on how these psuedolites can provide additional coverage to augment and support planned operational coverage. For example, this analysis provides analysis of mid-latitude surface missions, where there may be limited geometry and availability of orbital relays. The results will show how these navigation psuedolites can fit within the developing architecture to provide additional robustness, capability, and support multiple use cases. Lastly, the paper will discuss challenges and next steps to be addressed in the implementation and testing of a follow-on payload and a continued path towards demonstration and integration of this capability into Lunar PNT architectures.

Evan J Anzalone↗