Simulation

Overview

As a middleground between unit testing and uploading our code to the aircraft to see if it works, we’re implementing simulations into our pipelines. At a very high level, the simulation code interacts with our ZeroPilot code and produces step by step graphs of various aircraft metrics over time, to give an idea of how a real airplane might behave.

What’s going on ?

You can think of the entire simulation setup as being made up of 4 components.

1. The DatCom files

2. The Simulink model

3. The generated C++ files

4. The ZeroPilot-SW hooks

The Datcom files

We need some way of translating an aircraft geometry into a usable description of how that aircraft behaves under different circumstances in the air. Digital DatCom (data compendium) is a program developed by the US air force that does just that. It was made open source for the public to use years ago.

The compiled digital datcom exe exists in Simulink-Sim\Spike\SimulinkModel\datcomFiles. Linux and MaCos versions exist, but only the windows executable is in our repo.

The program takes as input a “.in” file (at this time we are using cessna172.in) that describes the aircraft’s geometry and outputs a file named datcom.out which contains tables of the coefficients that describe the aerodynamics of the aircraft. these coefficients are calculated for multiple altitudes, angles of attack, mach numbers, actuator positions and a few other things. Scroll through this file to see the tables, it’s pretty cool. Matlab can import the datcom.out file into it’s workspace.

A quick explanation of what these coefficients are:

It turns out that it’s actually extremely difficult to determine things like lifting force, drag force, torquing moments, etc, of an aircraft analytically, so the way the aerospace engineers do it is with coefficients. Take for example the coefficient of lift. Multiply this coefficient by the wing area and the dynamic pressure, and you get the lifting force on the aircraft. Likewise, multiply the pitching moment coefficient by the dynamic pressure, the wing area and the wing chord and you get the pitching moment. Datcom uses a compendium of experimental data (thus the name ) to estimate the coefficients for basic aircraft shapes.

A quick explanation of how the datcom input file is structured:

http://wpage.unina.it/agodemar/DSV-DQV/Digital_Datcom_Users_Manual_1.2.pdf is the manual that explains everything.

http://wpage.unina.it/agodemar/DSV-DQV/DATCOM_Tutorial_I.pdfis a quick start example.

Reading through that second link should allow you to understand what’s going on. The couplethings that are missed are the SYMFLP and ASYFLP (synchronous and asynchronous flaps) that are used to describe the elevator and ailerons. Unfortunately, datcom does not provide this capabillity for rudders.

The other thing you might find weird is that our datcom file has 2 cases even though we are just describing 1 aircraft. This was a hack; for some reason, having aileron and elevators in the same case did not give out all the coefficients, so I created 2 cases, one with ailerons and one with elevators. matlab knows about this, that’s why the lookup tables that use aileron reference aero{2} and those that use elevator reference aero{1}.

The Simulink model

Inside Simulink-Sim\Spike\SimulinkModel, is a file named Spike.slx. This file contains the Simulink model. open it with Matlab to see the block model. Here’s the summary of what’s going on:

• Import Datcom file into the workspace

  • This is currently a manual process and needs to be done once everytime the model is opened. TO do it, cd into Simulink-Sim\Spike\SimulinkModel\Utilities from the matlab comand line, and run “aero = importAndFixDatcomData()”.

  • For curiosity’s sake, the “fix” part of the function is there because for some bizarre reason, Datcom fails to generate a very few number of coefficients. So what is done is the in those cases, the coefficients that fail to generate are replaced with the coefficient of the previous altitude.

• Read ZeroPilot-SW commands

  • On the top left of the model, there are a series of blocks named read*. These blocks read the latest actuator and throttle commands that the autopilot produces and feed them into the model at every time step. The whole SeperateYawAndPitch block is there because our code thinks it’s controling Spike, which is an airplane with ruddervators, while the model models a cessna 172, which is an aircraft with a conventional tail.

    

• Figure out the appropriate coefficients.

  • You’ll notice that the read* blocks feed into a block named aerodynamic coefficients. If you double click it, you can take a look.The appropriate coefficients are determined by using the data about actuator position, altitude, mach number, etc, and performing a linear interpolation inside the datcom tables.

    

• From those coefficients, determine the forces and moments

  • The coefficients that were just determined are fed into a block named aerodynamic forces and moments. This is a built in Simulink block. It doesent actually do anything special. Once you have the coefficients, getting the forces and moments is just a matter of multiplying each one with the wing area (or reference span or some other area) and the dynamic pressure. Now we know the 3D forces and moments that act on the aircraft as result of the actuators.

    

• At the same time, the coefficients that occur as a result of non actuator related reasons are computed.

  • In the bottom left of the model, there’s a bunch more lookup tables that feed into another aerodynamic forces and moments block. This accounts for the forces that act on the aircraft that are not related to the actuators. Things like the lift produced by the wings and the drag force resulting from the aircraft flying through the air. I just didnt put these in a clean simulink subsystem yet, which is why the lookup tables are exposed rather than in a block.

    

• The actuator and non actuator forces and moments, aswell as the propulsion and gravity forces are summed together.

  • Couple notes here. The gravity vector needs to be converted from the inertial to the body reference frame, so it is multiplied by the appropriate direction cosine matrix. The throttle force always points “forward” as far as the aircraft is concerned so no adjustment is necessary. Also, since both the gravity and throttle vectors point through the center of gravity of the aircraft, neither force produces a moment.

    

• The position, orientation, velocity vector, and all kinds of other stuff about the aircraft are computed.

  • The summed forces and moments are fed into the 6 dof block. This block is pretty magical. with all kinds of integration and other crap that doesent actually need to be known by the person using it, it figures out how that body behaves. THis block also contains the initial state of the body. Information like initial velocity, initial orientation, initial position, mass and moment of inertia tensor are specified here.

    

• The information output by the 6 dof block is fed into the writeToFile block.

  • This block just writes all the important info that gets fed back into our ZeroPilot-SW to files.

    

• Side note: there are a couple of blocks in the left middle of the model. They do very simple processing to calculate airspeed, mach number and dynamic pressure.

  

The generated C++ files

If you click the the generate code button on Simulink,

it outputs a zipped folder. The contents of that folder are unzipped and stored inside Simulink-Sim\Spike\GeneratedCCode. The only interesting files to look through are Simulink-Sim\Spike\GeneratedCCode\SimulinkModel\Spike_grt_rtw\Spike.h and Simulink-Sim\Spike\GeneratedCCode\SimulinkModel\Spike_grt_rtw\Spike.cpp. Although they are not very readable, so it’s not necessary to understand them, they do the same thing as the simulink model. And everytime Spike.step() is called, one step is performed. (The time that one step corresponds to can be changed inside the simulink model, before the code is generated).

The ZeroPilot-SW hooks

These “hooks” are c++ files that provide a way for the autopilot Sw to communicate with the simulation files without actually knowing that that it’s not talking to real hardware. They exist in Simulink-Sim\Spike\ZeroPilotSwHooks. They are implementations of the sensor classes and the SendToSafety functions. THey are pretty simple, so looking at the files should explain what they do, but long story short, the sendToSafetyIntercept implementation writes the actuator and throttle commands to files that the generated C++ files read and the sensor intercepts collect the data from the files that the generated C++ code writes to.