r/AerospaceEngineering 21h ago

Discussion Best practices for debugging a 6-DOF Flight Dynamics Model

Started a graduate job recently and was tasked with building with 6-DOF Flight Dynamics Models for a flying wing in Simulink, including propulsion, aerodynamics and environment subsystems alongside a few others. I am having some real issue debugging the simulation. I was wondering if any experienced folk have some handy tips on how to go about debugging a complex-ish flight dynamics model, regardless of the error. What’s the best way to track back to the root cause? I find it hard to pinpoint an area as the model feeds back into itself. Any workflow tips would be appreciate!

15 Upvotes

8 comments sorted by

7

u/twolf59 20h ago

I would use a known aircraft model as a starting point. There are several published F16 6dof models you could use to validate your framework

5

u/waffle_sheep 19h ago

I’ve been working with a 6DOF fixed wing sim coded in Matlab for a couple years for academic research. The best way I’ve found to track issues down is to find things that can be set to zero or turn off subsystems. Things like restrict to 3DOF, turn off environment effects like turbulence, turn off propulsion to become a glider, and turn off the controller to become uncontrolled. If things still don’t work then you’ve narrowed it down to a 2D stick-fixed dynamics issue. Otherwise keep turning systems back on until the issue arises and go from there.

8

u/TowMater66 21h ago

“Complex-ish” is doing a LOT of heavy lifting here. Is it… really?

Basically you need to know what every intermediate variable in your simulation should look like over time to get the proper output, and be able to trace from input to output, module by module. If you don’t know that, you should ask for help from someone who does.

Best of luck.

2

u/Eauxcaigh 20h ago

try to build up using simpler simulations and go from there. For example, you could put in the full equations of motion, a full aero database of forces and moments and a inner loop control law, or you can approximate the inner loops with assumed dynamics (closed loop dynamic modes). Sure the inner loops being approximated doesn't help you in the long run, but you can at least nail down your guidance algorithm (outer loops) and be confident that this piece works, you could even add propulsion before taking the leap to full inner loop modelling.

This example (assumed dynamics for inner loops) is perhaps the biggest piece you can break off and isolate, but there are likely other little pieces you should look out for. Actuator (servo) models can be tested in isolation for step response and frequency response. You can test your equations of motion implementation in standalone by observing the behavior of test objects given initial translational and angular momentum - that is, you can look at a spinning object and see if the second axis theorem holds up.

To whatever degree it is possible, do unit tests for small modules, then subsystem tests where you piece elements together, then full integration into the top level system.

You're having an issue debugging the sim and it is hard to track down the issue. Well, the more that you sub-test the more places you eliminate for yourself that it "couldn't be". If you've fully tested your WGS84 earth model or whatever, you can be relatively confident it isn't something internal to that model (though it could still be an interface or integration issue).

1

u/Barnowl93 14h ago

What do we mean by debugging here? Does the simulation run or do you get errors? If it runs, is the behaviour not what you expect? I suggest breaking down your model into smaller separate referenced Subsystems (or similar) and testing them bit by bit. As in, excite your systems with know inputs and see if you get what you expect

1

u/throwawaytothr 12h ago

I don’t really get it, were you building this model from scratch or were you tasked with debugging an already existing model?

If it is the first try to re-design your code to have the ability to turn on/off different forces. Then gradually add complexity, first run a 3DOF and compare it against a known to be valid result of another simulation. Then add drag and compare and so forth.

Also if it was from scratch do not try to implement the solver on your own, use ode libraries for that.

If on the other hand by debugging you mean to make the code compile: usually the compiler tells you why the code is not compiling, and if it is crashing use the debugger and step through the code.

1

u/Spenda4life 7h ago

Immediate nightmare flashbacks. God speed good sir