scenarioAttitudePythonPD

Overview

This script demonstrates how to stabilize the tumble of a spacecraft orbiting the Earth that is initially tumbling, but uses 3 separate threads, one of them written in python. The simulation sets up a 6-DOF spacecraft which is orbiting the Earth. This setup is similar to the scenarioAttitudeFeedbackRW, but here the dynamics simulation and the Flight Software (FSW) algorithms are run at different time steps. The scenario runs two different cases. The first is with the nominal MRP_PD (c-code), the second is with the same module coded into a python process. Identical results should be obtained.

The script is found in the folder src/examples and executed by using:

python3 scenarioAttitudePythonPD.py

It is assumed at this point that you are familiar with how to set up simulations in Basilisk and that you have a good understanding of processes/Tasks/models/etc. This document tries to call out the unique changes that are needed for python processes.

The simulation layout is broken up into three different processes. In the nominal sim (with MRP_PD c-code), the processes contain the following contents:

  1. Dynamics and control leading up to MRP_PD

  2. MRP_PD (c-code)

  3. RWA control based on MRP_PD outputs

For the simulation with the python task, the scenario is broken up as follows:

  1. Dynamics and control leading up to MRP_PD

  2. MRP_PD (python-code)

  3. RWA control based on MRP_PD outputs

The process, task, and model settings for the standard models follow a procedure identical to the other tutorials. Then for Python processes, the spin up procedure closely mirrors that of the regular processes.

For the python processes, the creation step is almost identical to the creation step for standard C/C++ processes. Instead of:

scSim.dynProcessSecond = scSim.CreateNewProcess(scSim.simControlProc, 2)

we use:

scSimPy.dynProcessSecond = scSimPy.CreateNewPythonProcess(scSimPy.simControlProc, 2)

With this process, we’ve embedded Py in most of the naming, but that is an arbitrary user choice, the only thing that matters is the CreateNewPythonProcess instead of CreateNewProcess. Note that the prioritization is the same procedure as is used for standard tasks.

Then, models are created using model classes that have been defined (more on this later). These models are then attached to the python task which has been attached to the python process. Again the same prioritization procedures are used for the python tasks as are used for the standard tasks.

When the simulation completes 3 plots are shown for the MRP attitude history, the differences between the attitude history, and the differences between the RWA commands. The attitude history should show a clean overlay, and there should be zero differences.

Illustration of Simulation Results

show_plots = True, useJitterSimple = False, useRWVoltageIO = False
../../_images/scenarioAttitudePythonPD100.svg../../_images/scenarioAttitudePythonPD200.svg
class scenarioAttitudePythonPD.PythonMRPPD(modelName, modelActive=True, modelPriority=- 1)[source]

Bases: Basilisk.utilities.simulationArchTypes.PythonModelClass

This class inherits from the PythonModelClass available in the simulationArchTypes module. The PythonModelClass is the parent class which your Python BSK modules must inherit. The class uses the following virtual functions:

  1. selfInit: The method that creates all of the messages that will be written by the python model that is implemented in your class.

  2. crossInit: The method that will subscribe to all of the input messages that your class needs in order to perform its function.

  3. reset: The method that will initialize any persistent data in your model to a common “ready to run” state (e.g. filter states, integral control sums, etc).

  4. updateState: The method that will be called at the rate specified in the PythonTask that was created in the input file.

Additionally, your class should ensure that in the __init__ method, your call the super __init__ method for the class so that the base class’ constructor also gets called to initialize the model-name, activity, moduleID, and other important class members:

super(PythonMRPPD, self).__init__(modelName, modelActive, modelPriority)

You class must implement the above four functions. Beyond these four functions you class can complete any other computations you need (Numpy, matplotlib, vision processing AI, whatever).

scenarioAttitudePythonPD.runRegularTask(show_plots, useJitterSimple, useRWVoltageIO)[source]

The scenarios can be run with the followings setups parameters:

Parameters

  • show_plots (bool) – Determines if the script should display plots

  • useJitterSimple (bool) – Specify if the RW jitter should be modeled

  • useRWVoltageIO (bool) – Specify if the RW voltage interface should be modeled