Infrastructure for the new PSim

[kylekrol]

Infrastructure for the new PSim

This PR contains most of the C++ infrastructure code and the Bazel build system for the PSim. It's structured as a library of "models" that will later be linked into small PyBind11 packages which will be used to test GNC software and run the simulation with PTest.

To jump right in and run some tests, execute the following commands from the root of the PSim repository:

python37 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
bazel test //:test/psim:all

This will compile the GNC library, PSim library, and link both of those into the current set of PSim unit tests written with GoogleTest. The Python virtual environment is required for the model interface autocoder (more on this later).

To get intellisense working with the Bazel build system, take a look at the tools/bazel-compilation-database.sh file.

Motivation

The following outlines the new features we're looking for out of a simulation written in C++ and why we're moving away from MATLAB:

• Work with an architecture that helps prevent negative work. Previously with the MATLAB simulation, rewriting the truth orbit propagator meant writing over the existing code. This had the added implication that the old code was entirely lost and we were rewriting some of the simpler orbit propagators over and over again when this wasn't fully necessary.
• Better simulation support for multiple use cases. The MATLAB simulation wasn't very modular at all and when working with the simulation, many changes ended up being breaking. For example, without GNC being fully integrated into flight software, we weren't allowed to add sensor models into the simulation because it'd break things downstream. We need a modular design for simulation models to allow them to be easily swapped in and out.
• Support a wide range of telemetry but don't needlessly calculate information if it's not needed for the sake of better performance. Essentially, this means we'd like to support lazy evaluation which wouldn't be that easy to handle in MATLAB.
• MATLAB can't be run in CI.

In addition to the above grievances, we're striving for some other features as well:

• A clean configuration system to provide initial conditions to the sim and handle other constants (sensor noises, et cetera).

Architecture

As alluded to above, PSim will be written as a collection of "models". These models will interact with the other two main components of PSim when integrated into a full simulation: the configuration and the state field systems.

Configuration

At a high level, the configuration system is responsible for parsing configuration files (simple key-value text files) into a set of "parameters" that can be read in by models during sim initialization.

See the following files for more details:

include/psim/core/configuration.hpp
include/psim/core/parameter*.hpp
src/psim/core/configuration.cpp

State Fields

State fields and a simulations state registry are responsible for tracking and providing access to the state of the simulation as it evolves over simulation steps (doesn't necessarily have to be forward in time but it pretty much always is).

State fields can be registered to the simulation state in two fashions: either as a writable field or a plain state field (presented as a read-only field). A writable field can be written from outside the simulation or another model (say a reaction wheel actuator model that's supposed to present a wheel torque to the attitude dynamics model). Fields registered as read-only can only have telemetry pulled from them from outside the simulation or by another model.

There is one kind of read-only field I'd like to draw special attention to and that's the template <typename T> class StateFieldLazy<T>. This field holds a std::function<T ()> that can be called if/when the state field is accessed. This helps handle the "support a wide range of telemetry" requirement as we can "teach" the sim how to evaluate a bunch of parameters that may only be accessed once in a blue moon.

See the following files for more details:

include/psim/core/state*.hpp
src/psim/core/state.cpp

Models

Models are where the bulk of future simulation development will be happening. They're responsible for adding there state fields to the simulation state, retrieving additional fields from the state they may need, and specifying how these fields relate and should be stepped forward.

As one could imagine, writing all of the "wiring" code over and over again would get a little annoying. To help combat this and standardize how models should interact with the simulation at large, all model interfaces are to be specified in a YAML file which will then be autocoded into a model base class. This base class interface could have multiple implementations in the form of many derived classes.

Last quick thing to note, a model can also be an ordered list of other models. We call this a ModelList and it will be helpful in assembling complex simulations into a single model (important for creating a simulation).

See the following files for more details:

include/psim/core/model*.hpp
include/psim/truth/*
src/psim/core/model*.cpp
src/psim/truth/*
tools/autocoder.py

Simulation

The last stop on the architecture overview is the full on simulation! The only thing the simulation class as a whole does is bring together the configuration, model, and state field systems into a functioning simulation.

See the following files for more details:

include/psim/core/simulation.hpp
src/psim/core/simulation.cpp

[kylekrol]

Description is in progress. I definitely recommend looking at it commit by commit!

[athena255]

Nice, this is really clean.