Can Julia land on the Moon? On the development of a GNC simulation framework for the Argonaut lunar lander

Introduction to the show: ident: Robotics Radio. Generated commentary on the latest robotics and control papers.

Rosa: Today's paper: "Can Julia land on the Moon? On the development of a GNC simulation framework for the Argonaut lunar lander".

Dev: The gist: No, the Julia programming language cannot land on the Moon — but it can play a crucial role in designing and analysing the Guidance, Navigation,

Rosa: First, who's behind it and why it matters.

Title and authors: Rosa: We started by looking at the title of this paper, "Can Julia land on the Moon? On the development of a GNC simulation framework for the Argonaut lunar lander," and it immediately makes you think about testing if this language is serious enough for deep space applications.

Dev: That title sets up a big question right away, asking whether Julia can actually be used to build a complete system for landing on the Moon. It frames the entire paper around that feasibility check.

Taro: It’s not just about whether Julia can run calculations; it’s about whether you can use it to design and analyze all the guidance, navigation, and control algorithms needed for a real lunar landing.

Rosa: The authors are showing us that they developed something called ATLAS, which is this modular suite of tools specifically designed for analyzing and simulating the entire descent and landing phase of the Argonaut lander.

Dev: And ATLAS integrates a lot—it’s not just one part—so it brings in high-fidelity translational dynamics, rotational dynamics, varying mass properties, propellant sloshing, detailed sensor models, and actuator models all together.

Taro: So they’re not just simulating the physics; they are simulating the entire complex environment that a real spacecraft faces during landing. That level of detail is crucial for testing autonomy decisions under stress.

Rosa: They also include flight-representative GNC algorithms within this framework, which means it’s not just running abstract math; it’s using actual control logic that mimics what you'd actually need in a mission.

Dev: It frames the whole thing as an exploration of whether using a different programming language, like Julia, could offer tangible benefits over established tools like MATLAB or Simulink.

Taro: So the motivation here is really about seeing if switching languages for simulation can give us something practical, especially when simulation speed is a major factor in GNC development work.

Rosa: That’s the core tension they are exploring—the ambition of using Julia to replace established methods while still delivering the high fidelity needed for space missions.

Dev: So, it’s not a definitive yes or no on landing on the Moon with Julia, but rather a deep dive into what Julia *can* do in this specific domain.

Taro: I think that’s the right way to look at it; we are looking at its potential role in the design and analysis side of complex autonomous systems.

Rosa: And that leads us into what they actually present in terms of their summary of this work.

The paper's summary: Dev: So, the paper summarizes how they built ATLAS to be a modular suite covering the complete descent and landing phase of Argonaut. It’s structured around four main phases: a braking burn phase, a pitch-up phase, a powered descent for those final few hundred meters to get above the site, and then the vertical descent.

Rosa: They emphasize that ATLAS is designed to be modular so you can separate out the flight software—the GNC part—from the sensor suite, actuators, and dynamics models. This separation is key for making sure different parts can be developed independently.

Taro: I think that modularity helps a lot when you’re building autonomy systems because it lets you test the guidance module separately from the control architecture or the vehicle dynamics.

Dev: The GNC module inside ATLAS includes a mission and vehicle manager to implement that system state machine, followed by a navigation function based on a six-degrees-of-freedom error-state Schmidt–Kalman filter.

Rosa: That Kalman filter is how it estimates the lander's position and attitude using sensor data, which is essential for knowing where you are and which way you’re pointing during the descent.

Taro: So when we think about autonomy, that navigation function provides a solid foundation—if the state estimation is accurate, then whatever guidance or control decisions you make based on that estimate will be more reliable.

Dev: Then there's a guidance module that generates the reference trajectory, which outputs position, velocity, attitude profiles for all those mission phases. This feeds into a control architecture with four SISO control channels: one for vertical translation, one for roll, and two lateral channels controlling coupled attitude-position motion.

Rosa: Those four control channels have a specific structure where the lateral channels use a cascaded structure to convert forces from the outer position loops into attitude commands.

Taro: That cascading structure sounds like it’s trying to manage how different physical movements—like moving forward versus changing orientation—interact in real time.

Dev: The whole system then translates those control demands into actuator-level commands, including main-engine thrust levels and RCS on-times, which are generated by an algorithm inspired by simplex allocation for the main engine.

Rosa: And finally, the actuator module handles high-fidelity models of the three main engines and the RCS thrusters. It’s a complete loop from decision to physical action.

Taro: It makes sense that they put all those pieces together because in real autonomy, you need that entire sequence—from sensing to deciding to act—to be integrated smoothly.

Dev: This whole structure is designed for multi-rate simulation, which lets components operate at different frequencies through internal triggering and delay management mechanisms.

Rosa: So the summary boils down to a complete closed-loop simulation framework that tests the entire descent process end-to-end within one environment. It’s very comprehensive for what it aims to achieve with this paper.

The paper's improvements: Taro: Now let’s talk about how the authors suggest improving this work, because they point out some areas where the framework could be even stronger than what they currently have.

Rosa: They focus on using Julia’s strengths—its ability to handle complex systems through composite types, or structs—as a fundamental architectural principle for representing engineering systems made of multiple interacting subsystems.

Dev: That means they are leaning into Julia’s structure to create a design that feels more like flight software than those older block-diagram simulators, which is a big architectural improvement in my book.

Taro: If the architecture is closer to actual flight software, it means better deterministic execution order and better traceability when you're debugging issues down the line.

Rosa: They also highlighted the simulation step function, simStep!, which orchestrates everything by sequentially calling functions for DKE propagation, sensor execution, GNC execution, and actuator execution.

Dev: That sequential orchestration is what allows them to manage components operating at different frequencies through internal triggering and delay management mechanisms. It’s a smart way to handle the time differences between things running at different rates.

Taro: So they are emphasizing the need for modular, testable simulation components so that when you're building autonomy software, you have clear interfaces defined between those parts.

Rosa: They also mentioned that the development experience with Julia can be improved by encouraging a code-based paradigm where interfaces are clearly defined and data types are consistent across all subsystems.

Dev: That consistency in data types is crucial because if the language allows for subtle errors like inadvertent aliasing through references, having strict conventions helps prevent those hard-to-find bugs.

Taro: So the authors are pushing for a workflow where you build things in a way that makes them inherently testable, which directly supports the goal of creating reliable autonomy software.

Rosa: They are also noting that this approach democratizes access because someone can clone the repository, install Julia, and immediately run a high-fidelity simulation without needing to request expensive licenses for every step.

Dev: That’s a huge win for prototyping; it means engineers don't have to wait for lengthy setup processes before they can start their analysis cycles.

Taro: So the idea is that this code-based approach makes the development process less about configuration and more about writing good, structured code from the beginning.

Rosa: Ultimately, these improvements suggest that Julia is a credible path for high-performance simulation and prototyping in the pre-development stages of a program.

Conclusion: Dev: So to wrap up on this discussion about "Can Julia land on the Moon? On the development of a GNC simulation framework for the Argonaut lunar lander," we’ve seen that Julia delivers excellent runtime performance for large-scale GNC analyses when you optimize it correctly.

Rosa: It’s a modular, closed-loop simulation framework that covers everything from dynamics and sensor models to actuator commands in one place, which is really powerful for high-fidelity testing.

Taro: For autonomy research, this means we have a tool capable of supporting rapid iterations between controller design and Monte Carlo validation because the simulation speed allows for routine accessibility.

Dev: The paper shows that while Julia has challenges with its language semantics, like default reference handling, it can still be a strong contender for pre-development phases.

Rosa: So the conclusion is that Julia provides a way to unify high-level expressiveness and low-level performance for complex GNC analysis, even if full industrial adoption isn't proven yet.

Taro: For autonomy development, this means we have a high-performance simulation ground available for testing control algorithms right now, provided we focus on the structural improvements the authors suggested.

Dev: So in short, ATLAS is a powerful framework for exploring GNC design and analysis for missions like Argonaut. It’s a tool that can be used effectively in those early prototyping activities.

Rosa: We’ve talked about how this paper presents the ATLAS framework as a high-fidelity closed-loop simulation environment developed entirely in Julia.

Taro: I just want to say that it opens up a path for us to seriously explore these kinds of tools for future autonomy development efforts.

Dev: Agreed, it’s a credible alternative for high-performance simulation and prototyping, especially when you focus on optimizing the execution speed.