This script sets up two 3-DOF spacecraft orbiting the Earth. The goal of the scenario is to

  1. highlight how the BSK_Sim structure of a formation flying tutorial is different from the basic orbit scenario,

  2. demonstrate how to create a formation flying scenario, and

  3. how to customize the and files.

The script is found in the folder basilisk/examples/BskSim/scenarios and executed by using:


The simulation mimics the basic simulation in the earlier tutorial in scenario_BasicOrbit.

The flight software mode is set to inertial3D. The goal of this mode is to align the body axes of the spacecraft with an inertial 3D point guidance coordinate system defined in BSK_FormationFsw. However the flight software mode can also be set to “standby”.

The simulation layout is shown in the following illustrations.


Configuring the scenario file

The simulation layout is very similar to the one used for the scenario_BasicOrbit file. Two simulation processes are created: one which contains dynamics modules, and one that contains the Flight Software (FSW) modules. First of all, it can be observed that the Dynamics- and FSW files used are the BSK_FormationDynamics and BSK_FormationFsw files. These two files have been created for this specific formation flying implementation into Basilisk.

After initializing the interfaces and making sure that the scenario_BasicOrbitFormation class inherits from the BSKSim class, it is time to configure the initial conditions using the configure_initial_conditions method. It can be observed that two sets of orbital elements are created. Each set corresponding to one spacecraft. After that the initial conditions are set for each spacecraft.

After that the function that logs the outputs can be observed. Again this looks very similar to the log_outputs method in the scenario_BasicOrbit file, however one discrepancy can be noticed. Looking at the code below it can be observed that two instances of the simpleNavObject are logged (simpleNavObject and simpleNavObject2 respectively). Each object corresponds two one of the spacecraft. The same is true for the FSW objects. More on this will be discussed later.

The same is true for the pull_outputs method. Also in this function, it can be observed that the outputs of two instances of a specific object are pulled.

BSK_FormationDynamics file description

Looking at the BSK_FormationDynamics file, it can be observed that the dynamics process consists of two tasks named DynamicsTask and DynamicsTask2 respectively. These tasks are added to the dynamics process and to each task, an instance of a specific object is added.

The gravity body (Earth in this case) is created using the gravBodyFactory and is attached as a separate object to each spacecraft.

After that each object is added to the corresponding task. Something that is very important is the message names. In case multiple spacecraft are implemented in Basilisk it is necessary to manually connect an output message of one module to the input of a different module. This can be seen in the module-initialization methods in the file.

BSK_FormationFsw file description

The setup of the FSW file ( in case of formation flying is very similar to the setup of the dynamics file. Also in this case, an instance of each task is initialized that corresponds to one of the two spacecraft. Furthermore, it is necessary to manually set the input- and output message names for the FSW modules. In order to make this tutorial work properly its is very important to set the self.mrpFeedbackRWsData.Ki and self.mrpFeedbackRWsData2.Ki variables in BSK_FormationFsw to -1. Otherwise the orientation and rates of both spacecraft will not converge!

Illustration of Simulation Results

showPlots = True

The scenarios can be run with the followings setups parameters:


showPlots (bool) – Determines if the script should display plots

class scenario_BasicOrbitFormation.scenario_BasicOrbitFormation[source]

Bases: BSK_masters.BSKSim, BSK_masters.BSKScenario


Developer must override this method in their BSK_Scenario derived subclass.


Developer must override this method in their BSK_Scenario derived subclass.


Developer must override this method in their BSK_Scenario derived subclass.