13
$\begingroup$

I'm a software engineer and I've always loved Orbiter (also here). However I feel that it's growing a bit antiquated, and it would be nice to have a more modern, open source, or otherwise hackable engine. There are a lot of riffs on "realistic space sim" that would be great to explore.

I've been playing with the idea of attempting this as a side project, but I have zero interest in implementing my own orbital dynamics engine. Scientists far smarter than I have done the legwork here, and re-creating their work would likely add a year or two to my ETA. I have some background knowledge in physics, but I am a relative amateur in the field.

Ideally the library would be implemented in C, or have a C interface. If I start this project, I'll be doing it in Rust due to personal preference, which has great FFI compatibility with C. A secondary choice would be C++, which is marginally less supported. There may be a way to do it in a traditional engine like Unity or UE4 with some hacks, but those would have very similar source language requirements. (see clarification below for more specificity)

It would also ideally be licensed to be openly distributable, since it would need to be integrated and redistributed as part of the simulator.

I've looked briefly at the SPICE toolkit, which seems old-school but has the bindings I need.

I've also looked at GMAT, which seems to provide higher-level routines but seems to be primarily oriented around mission planning and less well-maintained. I'm not clear if it provides the bindings I would need to run a sim.

Of these, I know very little about what their real-time performance would be like, since they are typically built for mission analysis more that simulation.

Does anyone more experienced that I know what libraries would be suitable for this type of application (if any)?

EDIT: In response @uhoh's comment:

I'm addressing this in the body since my response requires more characters than a comment allows for.

If "SPICE toolkit" has "the bindings I need" (does it really?) then why does it matter if it "seems old-school"? It's not like we need "fresh code" because the old stuff goes rotten. Also, could you elaborate more on exactly what "this type of application" is? Specifically what features do you need that GMAT does not have for example? You haven't really specified your problem very clearly yet as far as I can tell. What exactly do you mean by "real time"? A mission to Mars needs to take six months to execute?

From your comment I see two main points:

  1. You want more specificity on what I intend to make.
  2. You want more information on my evaluation criteria for SPICE and GMAT.

Problem Specification

I will assume you are familiar with Orbiter and Kerbal Space Program, as these are the contemporary games that simulate vehicular space travel. As stated above, I would intend to build an open source engine and base game similar to those above. Specifically, I would aim for something closer to Orbiter than KSP. I think there are a lot of fun ways you could "gamify" Orbiter (such as dynamic missions, mutliplayer), and I want to explore these concepts.

Specifically, I would aim to create an open source video game engine that can act as a starting point for interactive space simulation games. This differs from mission planning / analysis by its interactive component. The key differentiation is that a real time space simulation needs to accept course corrections to simulated entities, and update the object's orbital propagation with very low latency (roughly 8 ms). When I discuss a "real-time" simulation, this is what I mean.

These simulators generally propagate state at a pace in-sync with the wall clock, but also provide a time acceleration feature. There is generally a loss in simulation accuracy under time acceleration due to the engineer increasing the step size of their propagator. However with a sufficiently efficient propagator, it may be possible to make accuracy improvements by computing multiple physics steps from frame to frame.

The general architecture would be a graphical frontend responsible for "game loop" code, such as rendering and player input handling. However for orbital propagation, the frontend would outsource the work to an orbital dynamics module that simulates gravitational influences for all entities in the simulation. This would be augmented with a Newtonian physics engine for close-range interactions between objects.

In this post, I am trying to evaluate the viability of existing orbital dynamics libraries to fulfill this role. This would hopefully lead to less dev work for me, and a more accurate or optimized orbital dynamics component.

If you would like more specificity, I am happy to elaborate. However beyond this I am unclear what questions you have.

Toolkit Selection Criteria

I am specifically interested in leveraging existing toolkits to manage the orbit propagations of in-game entities. For the sake of scope I am limiting this to orbital dynamics, and not considering aerodynamics (although that would be pretty cool too). Because the role this is filling is primarily one of convenience, I am primarily looking for something where I can offload as much work as possible, with a bias towards developer usability.

The ideal toolkit would let me pass it a system of entities to simulate, preferably with the option of setting a propagator on an entity-by-entity basis (so that I can make latency-accuracy tradeoffs). I could then step it with sub-second time steps and have results ready in below 12ms (ideally 8ms). At any time I could apply a force vector to an object to adjust its trajectory.

Another requirement is redistributability (and ideally an open source license). A number of NASA packages (such as OTIS) are export-controlled, only available on request, and therefore are not viable as embedded components of software intended for the general public.

Many of the toolkits I have looked into so far are primarily intended for mission analysis. Therefore it is not necessarily true that they provide an interface to propagate a mission interactively. Many seem to instead follow a pattern of specifying constraints and initial conditions up front, then performing a batch compute process to identify optimal mission parameters. This would be useful as a navigational aid, but lack the interactivity to use it as the backbone of a simulation game.

SPICE

This is why it matters that SPICE is "old school". Even the function names in its C API follow an archaic character-limited naming scheme, where names must be looked up and memorized as they rarely clarify what the function is doing. This slows down coding and is less than ideal. I suspect it provides functional primitives at a lower level, but does not simulate a system of objects in the way I would hope. I could be wrong here, and would be delighted to hear that I am. The upside is that it seems to be an industry standard, well documented, and very powerful. This is currently my most promising option. However it is such a vast project that I am still discovering what its capabilities are.

GMAT

GMAT is neat, and seems to be a higher-level mission planning interface built on top of SPICE, but I have struggled to find documentation on it. I discovered it through the NASA Software Catalog, however their recommended support site (gmatcentral.org) is down with a 503 error. What little material I have found primarily speaks to how to use its graphical interface, rather than how to embed it as a component in a program. It is promising, as it's open source and seems to propagate an assembly of entities as part of mission planning. It is less promising in that it seems poorly documented, and tightly coupled to its current graphical interface. My hope is that since it's built on top of SPICE, a lot of the core simulation technology can be found in SPICE instead if I know where to look.

$\endgroup$
10
  • $\begingroup$ KSP is very hackable, and with the Realism Overhaul suite of mods, is surprisingly realistic. I know a lot of people consider it a toy, but depending on your goals it may fill the bill. $\endgroup$ Commented Jun 5, 2019 at 23:06
  • $\begingroup$ @uhoh: I have replied to your comment in the body of my post (needed extra characters) $\endgroup$ Commented Jun 6, 2019 at 0:34
  • $\begingroup$ @RussellBorogove: I love KSP. It may indeed be better to implement some of my ideas as mods there. However, I'm primarily exploring the notion of rolling my own right now (for fun and profit). $\endgroup$ Commented Jun 6, 2019 at 0:38
  • $\begingroup$ @AxelMagnuson super, well done, thanks! $\endgroup$
    – uhoh
    Commented Jun 6, 2019 at 0:52
  • $\begingroup$ It’s not quite usable yet, but check out spacecraft-vr.com $\endgroup$ Commented Jun 6, 2019 at 12:41

2 Answers 2

5
$\begingroup$

Rust is an excellent language for many reason, and I don't think I have to convince you to use it.

What I can say however, is that it'll be extremely difficult to use the SPICE bindings in that language. I've tried (and have a few other people in different languages), and the main problem with SPICE is that it's not thread safe. In their defense, SPICE was designed before multicore processors were even researched...

At the company I work for, we are currently designing a GPS-like system around the Moon, and we validate the flight software implementation with two different tools. One of them is my own Rust toolkit for spacecraft propagation and estimation: https://docs.rs/nyx-space . It's a work in progress, which I've only recently picked up again, but eventually it'll be high fidelity dynamics (in the next few months hopefully). For now, you can propagate an orbit around any celestial body available in the DE438s SPICE file, and it's easily scalable to N spacecraft at once. It is built on top of the linear algebra library in Rust called "nalgebra."

I hope that is useful, and reach out to me if the documentation isn't clear or if you need any support.

$\endgroup$
6
  • 1
    $\begingroup$ Oh hey! I've checked out your work before and it was my first pick for a while! The last time I looked at nyx, I think I discounted it as unmaintained. If you're looking to expand it, I'll probably start playing around with it. Do you have any plans for handling multiple gravitational bodies? I definitely want eventually include things like planetary transfers. $\endgroup$ Commented Jul 20, 2019 at 20:17
  • $\begingroup$ Yes, multibody dynamics is planned for this upcoming week actually as I need it for a project internally. It'll also include multibody spacecraft estimation (for the same project). Eventually, I'll also be adding estimation of gravitational parameters, but that may only come later. $\endgroup$
    – ChrisR
    Commented Jul 21, 2019 at 4:20
  • $\begingroup$ @AxelMagnuson, with some delay, the multi body dynamics is finally supported in version 0.0.10: crates.io/crates/nyx-space . Code is on gitlab.com/chrisrabotin/nyx . $\endgroup$
    – ChrisR
    Commented Aug 5, 2019 at 0:39
  • $\begingroup$ Awesome! It looks like github.com/ChristopherRabotin/nyx also has 0.0.11. Are they mirrored? $\endgroup$ Commented Aug 8, 2019 at 20:54
  • 1
    $\begingroup$ Just seeing this now. This effort is taking a backseat to some other priorities at the moment. However I will reach out to you on GitLab. $\endgroup$ Commented Sep 10, 2019 at 23:31
2
$\begingroup$

From the comments, two potential toolkits have emerged as top contenders.

  • TUDAT is available today, and as far as I can tell satisfies my requirements.
  • Spacecraft VR may be even more in line with my goals, and give me even more for free. However I believe it is very early in development, closed source, and I have yet to hear back from its maintainers.
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.