Helicopter model-stitching simulation, part 1 (and last for now)

I've been working on a helicopter simulator as a university interim project for some time. I'm actually doing only an implementation - the concept has been defined by Eric Tobias and Mark Tischler in their paper (and it seems like they also have handled the implementation themselves, but since they're working for the military, you can't download the software).

Left: Top level simulation architecture from Tobias/Tischler paper, right: my final top level simulation architecture in Simulink.

Introduction

Top level simulation architecture schematic from Tobias/Tischler paper

The basic idea is relatively simple. Doing tons of calculations in real time is either incredibly computationally expensive (especially when simulating a helicopter), or calculations are heavily dumbed down for real-time simulation. The workaround is to compute several states of the aircraft (flight at certain flight conditions in major forward directions (and backwards and hover for helicopter and VTOLs)) as accurately as possible, and during the real-time simulation just interpolate between those states. Now the state doesn't immediately give you the solution, but allows to calculate forces acting on an aircraft, which we then put into the equations of motion and integrate to get 6-DOF variables like velocities and orientation in space. A collection of states for a single flight condition is called "anchor point" by the authors and I am going to follow this nomenclature.

Distribution of anchor points for a helicopter simulation used by paper authors.
To simplify, I am only doing forward flight ("stitching in U") at first.

These interpolated aircraft anchor points can contain from a few states for a fixed-wing aircraft to dozens. The authors used 26 (below), and I am using 24. These higher-order states are treated differently in the simulation, but they do have an influence on the result.

A single interpolation "anchor point" including higher-order states.

Speaking in control theory terms, the usual state-space representation is used: $$\dot{x}=A|_{U_0} x + B|_{U_0} u$$ To be fair, \(\dot{y}=C|_{U_0} x + D|_{U_0} u\) is also mentioned in the paper, but I honestly am not sure whether it has any influence later in the paper. The equation above though is further represented in matrix notation: $$\dot{X}=A|_U (X-X_0|_U) + B|_U (U-U_0|_U)$$ Where  components denoted by \(|_U\)  are interpolated values of tabulated trim data and stability  and control derivatives.

Flightlab

Now, let's take a look at my implementation attempt. Unlike the paper authors, I obtained helicopter data from the Flightlab software developed by Advanced Rotorcraft Technology. Sort of. It's an incredibly capable software, but the learning curve is not even steep - it's literally impossible to learn it without significant help from someone experienced. My advisor has over a decade of experience with the flightlab and he is still shocked and surprised how badly have the developers neglected the user experience of the program. The scripting language has virtually no documentation, the error messages tell you nothing and the output variables are saved to text files in reshaped matrices and weird order.

UH-60 Black Hawk. Source: wikipedia.org

We used one of the models provided with Flightlab by default - a basic helicopter with articulated rotor. Funny enough, we could call it Black Hawk as well - the dimensions of the model closely follow the real thing which according to my advisor is caused by Black Hawk's popularity among researchers which in turn means that it's dimensions are no longer a secret.
I modified one of the advisor's older scripts to generate several flight cases, linearize necessary states and save them into a text file for further processing in MATLAB. This was somewhat problematic, because of two issues. The first is that because of being old, Flightlab saves the matrices in three columns, no matter the size of the matrix you want to save. The other and much worse was that Flightlab doesn't really save the requested states in order of them being selected in a script. We still haven't solved the latter. Unfortunately, as I can't claim the full ownership of the Flightlab code, I can't share it.

For anyone looking into working with this software, matrices \(A\)  and \(B\)  are represented in Flightlab as FR and GR.

MATLAB

Data exported by Flightlab have to be processed in order to be used in Simulink. I wrote a MATLAB script to read all output files and gather the data into data structures expected by Simulink lookup tables. The entire code is public at my Github repository here.
So, the files generated by Flightlab look like this (it's just an excerpt for readability): We can see that's basically in the format name-real_matrix_size-some_description-data_in_3_columns. So because MATLAB allows multi-argument and multi-result functions, I wrote a function that extracts and reshapes the data in specified arrays. What I do here is basically scan the file looking for familiar array names, then get the arrays, reshape and repeat the process. Please excuse low quality in a few places - I was really rushing to make this barely working at that time, this will definitely get refactored. Then it could be used like this: Or this: The rest of the code is rather boring so I'll skip it.

Simulink

The last part was to recreate the simulation from schematics and equations used in the paper. All non-Simulink blocks contain subsystems which mostly deal with specific equations from the paper. You can get the .slx file from the same repository where my MATLAB code is.

Top-level schematic in Simulink. Click on the picture for full-size view.

There is really not any magic in this part. I had to think a bit about what to use where at the top-level diagram, but that was it. All subsystems are just equations. The equations of motion (top-left turquoise block) were particularly cumbersome:

 What's next?

While the vast majority of the work has been already completed, there is still some work to do. I have to crack Flightlab's way of matrix output ordering to reorder them and there are definitely some bugs in the Simulink model as this is the most complicated model I've ever done. And as always, then there is testing which as we all know, always uncovers something overlooked. Nevertheless, I'm feeling optimistic. Maybe after the proof of concept is finally working, we can streamline the process so user can edit some parameters in Flightlab and a click or command after that notice the change of helicopter's behavior in the simulation.

Sadly, because I need to focus on my theses from Aerospace Eng and Comp Sci, the next update to this project won't come in next few months.

Also, as this is my first such post, I have definitely made some beginner's mistakes. Please let me know about them in the comments or on Twitter.

Also, once the project is finished, I'll write a more technical paper and post it here as well.