Skip to content
This repository has been archived by the owner on Sep 4, 2021. It is now read-only.

Flight Factory Setup

Jump to bottom
Stefan deBruyn edited this page Sep 27, 2019 · 5 revisions

Flight Factory allows running flight computers through mock flights that generate realistic sensor data. This is particularly useful for testing state estimation, airbrake control, and general code correctness.

Contents

Preliminary Setup

These setup instructions assume a Linux distribution. We recommend Ubuntu 16.04 because it plays nice with GCC. If you insist on using Windows, you'll need a GNU toolset like Cygwin.

Download an Ubuntu 16.04 image here (note that 64-bit Intel processors also need the AMD64 image). Instructions for installing Ubuntu from a bootable USB can be found here.

Installation

First, collect the dependencies.

sudo apt-get install git build-essential python3.6 matplotlib

Then, clone the repository into your location of choice.

git clone https://github.com/longhorn-rocketry/flight-factory
cd flight-factory

Pull the contents of all submodules.

git submodule update --init --recursive

Flight Factory is built with make. The make.py script will automatically generate a makefile from the contents of submodules and the src and include directories. This search is recursive.

The makefile must be generated anew when adding new source files.

python3 make.py /path/to/sketch

/path/to/sketch is the root of the Arduino sketch being simulated. The sketch's dependencies, if not elsewhere in the repository, must be in this folder as well. This path must also contain a configuration file .ff. The format of this file is covered further below.

Then, build and run.

make clean; make ff; ./ff /path/to/sketch

Alternatively, fly.sh will do all of the above for you. This is your go-to compile & run one-liner.

./fly.sh /path/to/sketch

build.sh, an almost identical script that simply omits the execution of the final binary, may be preferable in some debugging cases.

Writing Configuration Files

The configuration file, a plaintext file named .ff in the sketch root, describes the simulation and the rocket being simulated.

Configuration files follow the basic INI format, with a few exceptions. Valid sections and keys are as follows:

  • simulation - Simulator and environment parameters
    • initial_altitude - Launchpad altitude
    • target_altitude - Target altitude
    • type - One of (dof1); simulator type
    • t_ignition - Time of motor ignition
    • dt - Time resolution
    • stop_condition - One of (impact, apogee); simulation stop event
  • rocket - Physical rocket properties
    • mass - Mass without motors
    • radius - Body tube radius
    • surface_area - Surface area exposed to air stream; auto uses body tube cross section
    • airbrake_surface_area - Airbrake surface area exposed to air stream at 100% extension
    • drag_coefficient - Static rocket Cd or one of (profile, plane) for profiled and planar Cd scheduling, respectively (see relevant sections)
    • nose_cone_length - Length of nose cone
    • fineness - Rocket fineness ratio
    • skin_roughness - Rocket skin finish
  • cd_profile - Rocket drag coefficient profile
    • A list of M Cd pairs with monotonically increasing Mach numbers M mapped to drag coefficients Cd
  • cd_plane - Rocket drag coefficient plane
    • src - Fully-qualified path to plane source file
  • motor - Physical motor properties
    • wet_mass - Loaded mass
    • dry_mass - Burnout mass
    • A list of t F pairs with monotonically increasing timesteps t mapped to thrust scalars F
  • noise - Noise distributions for environment and sensors
    • Values for keys in this section may be one of the following distributions:
      • normal v m - Normal distribution with variance v and mean m
      • uniform a b - Uniform distribution with lower bound a and upper bound b
    • sensor_accel - Accelerometer noise
    • sensor_pressure - Pressure sensor noise
    • sensor_tempeprature - Temperature sensor noise
    • physics_accel - Vehicle acceleration noise

Lines which begin with # are comments. An example config file is shown below.

[simulation]
dt=0.1
stop_condition=impact
# Altitude of Truth or Consequences, NM
initial_altitude=1293.876
type=dof1
t_ignition=1.0

[rocket]
mass=25
radius=0.0762
surface_area=auto
airbrake_surface_area=0.0070866
drag_coefficient=profile

[cd_profile]
# M/Cd profile derived from OpenRocket
0 0.46
0.5 0.55
0.9 0.67
1.0 0.91
1.1 0.76
1.4 0.55
2 0.23

[motor]
# Massing and thrust profile for an N2200-PK
wet_mass=11.356
dry_mass=5.048
0 0
0.05 2750
0.2 2450
1.0 2550
2.0 2600
4.0 2200
4.7 2100
5.25 500
6 0

[noise]
sensor_accel=normal 0.25 0
physics_accel=normal 0.22 0.03

For best results, we recommend using the planar drag model. Exactly how this works is some secret sauce; talk to the experimental team if you want the know-how.

Writing Factory-Compliant Arduino Sketches

There are many ways to write code that interfaces with Flight Factory. Our preferred method is using Photic's hardware abstractions to create virtual and physical I/O that can be toggled between with a single #define. For example:

#define GROUND_TEST // TODO: REMOVE BEFORE FLIGHT

#include "ff_arduino_harness.hpp"

...

photic::Imu* imu =
#ifdef GROUND_TEST
  // A fake IMU attached to the Flight Factory simulation
  new VirtualImu();
#else
  // A real IMU attached to the flight computer
  new BNO055Imu();
#endif

This idea can be generalized to any dependency that may need to change between real and simulated flights.

The goal is to have Flight Factory equivalents of all common Arduino classes like Serial and Servo to maximize interoperability. Any unsupported Arduino code will have to be toggled away with preprocessor directives.

Clone this wiki locally