Single Orbit Simulation in Python

[kylekrol]

Overview

There is a lot of stuff going down in this PR so i am going to take it commit by commit.

Updated lin Pointer

This is pretty self explanatory. The reason for the update was to avoid naming collisions on MacOS with the Bazel BUILD file and some file Python's setup tools likes to create.

Build System Updates

There we a lot of build system updates this time around but here are the highlights:

• All *.bzl files were centralized in the bazel/ directory (this was done because of the large number of build files added on this PR).
• A repository rule was added to make the Python development headers available to Bazel during pybind11 builds. In short, this rule creates a new repository that has a symlink to the system headers (which are detected dynamically) and adds that path as an include path for builds.
• A C++14 compliant std::variant implementation was added to help handle passing dynamic types between Python and C++ at runtime. This gets plugged into the Python binding code later on.
• Build flags were updated in .bazelrc to enable optimizations! It makes a huge difference and I opened a ticket to add explicit support for debug and release builds.
• More PSim specific build commands were created for convenience. I tried leaving links as sources where appropriates (i.e. the Python extensions build command).

GNC Updates to the Fixed Step Size Integrators

Per the section header. The integrators were updated to also take a void pointer to allow the end user to pass arbitrary data to the integration step. This will be useful for more complex PSim implementations.

PSim Bugs

We were missing a return statement in a few assignment operators and was why build issues were seen on MacOS.

Earth Ephemeris Model

This is the first model that will pretty much run in every simulation and is just downstream of the time model. It's responsible for outputing information about Earth's attitude and angular rate (i.e. all the information that's needed to transform between ECI and ECEF).

The interface was initially implemented here using existing GNC functions but should be revisited later per #236.

Point Mass Orbit Model

This is a generic interface for a point mass orbit propagator. The orbit propagator can work in whatever frame it wants to and a vector transformer should be added later to abstract away this fact - these will be touched on later.

The orbit propagator implemented here just relies on GNC functions.

Vector Transform Functions

The general idea here is to add a layer of abstraction that abstracts away the particular frame and orbit model, environment model, et cetera is operating in. These models take in a vector vector.lookup.name and output the vector in different frames: vector.lookup.eci, ...

Environment Models

This model generates magnetic field and sun vector truth values for a satellite and should be supplemented with vector transformers.

Single Orbit Simulation

Simply created a model list here with the proper arguments to create a simple simulation of a single point mass orbiting Earth.

Python!!!

If you aren't familiar, I would highly recommend taking a look through the pybind11 docs here. It's a super slick way to interface C++ with Python and it's what's being used here for PSim.

In short, the PSim configuration and single orbit simulations were wrapped and made available to Python. A simple model was thrown together and you can run the simulation currently with the following:

bazel run //python:single_orbit

You should get these plots! This was tested on Arch Linux and MacOS.

There is plenty more work to be done to clean up the Python side of things a little bit.

[kylekrol]

Commit by commit this should be pretty easy to do! Up until 8415076 are "original" commits on this PR.

[tanishqaggarwal]

For the sake of reducing how distributed implementations are, are these functions (defined in gnc/environment.hpp) eventually going to move their implemenations into this class?

[kylekrol]

Most likely no because these are also shared by the flight computer. If we implement more complex models to be run only by the truth model, they may be moved in here.

PSim can consume the GNC flight software implementation as a library but not the other way around.

[tanishqaggarwal]

Are r and v lazily evaluated here, is that why they get xf?

Why are they lazily evaluated? Shouldn't they be computed on each timestep for the integrator to work?

[kylekrol]

Position and velocity are not being lazily evaluated in the orbit model because they are integral to the state of the simulation. This is also why they're required to be initialized from config.

[tanishqaggarwal]

The lazy evaluation concern I brought up seems related to the changes made in this test.

[kylekrol]

The integrators don't employ any lazy evaluation? They just take the function to calculate dx/dt.