https://alexs12.github.io/FlightMechanics.jl/latest/#FlightMechanics.quaternion2euler-NTuple{4,Any}

No references to aircrafts are found in doc. Add a brief description in overview and dedicated sections in docs

Current situation
Right now the optimization process for trimming an aircraft does not use the control surfaces limits to constrain the results.

Objective

Tests for F16 trimming against Stevens passing without iterating out of controls surfaces ranges. Even if all the trimming validation done against Stevens for F16 converges to the same values. High Angle Of Attack (HAOA) cases require to iterate with out of range values to converge.

Avoid mutable struct for FCS As the FCS must be configured to allow out of range iteration and set back to the original values in the trimmer, it is now a mutating structure. Some other solutions to this situation may be proposed, but this would indirectly be solved if trimmer does not need out of range values.

Hey, found this repository from the discourse. Looks nice! It looks like a very small modification would need to be done for something like:

https://github.com/AlexS12/FlightMechanics.jl/blob/master/src/dynamics/sixdof_quaternion_fixed_mass.jl

to call the DifferentialEquations.jl ODE solvers. I think it would lead to some nice demos to have that setup. Note that in terms of the package, you can directly depend on the ODE solvers (OrdinaryDiffEq.jl) to reduce the dependency size.

After 08eec8e, probably some tests in test/aircraft will pass with a smaller tolerance because they were affected by this bug.

Try to adjust tolerances.

Some dynamic systems need more configurable attributes

• configure Earth rotation speed as an optional argument with the current default value to SixDOFECEFQuaternionFixedMass at least for testing purposes
• allow optional arguments to dynamic systems that are not currently considered, such as: lambda, Earth rotation speed or ellipsoid.

Are non-canonical convert methods acceptable?

Some convert methods in the project do not follow the "canonical" rule of receiving a type and an instance, but receive two instances. I think this can cause trouble at some point and maybe these methods shouldn't be called convert. Ie. conversion and promotion rules cannot be applied.

See #59 for examples of the problem

Current situation
models/state.jl is mostly undocumented

Solution proposal
Generate docstring documentation for constructors (at least).
Is also desirable to include getters.
It would be convenient to have an entry in documentation describing the objective of the State struct (serving as an interface between different dynamic models and the simulator).

Current situation
No generalized way in the package to generate typical inputs to controls.

Objective
Being able to generate typical inputs such as: step, doublet, ramp and harmonic. In a generalized way.

Solution proposal
Create a new file under Models module able to generate this inputs. Each input could be a struct storing its characteristic parameters (amplitude, duration...) then the input value could be calculated in a calculate_input(input, time) function.

Current situation
models autodoc is not rendered in documentation web page.

Objective
Make it appear together with the rest of the autogenerated doc.

Julia 0.7 and Julia 1.0 have been launched. It is recommended to port firstly to 0.7 son incompatibility warnings will be raised and move to 1.0 afterwards.

Some tests are not passing in the nightly build because of this change, so this needs some attention.

Current situation
A set of differences that are enumerated in src/simulator/aircrafts/F16/aerodynamics.jl were found between Stevens and Morelli implementations. Currently, just Stevens implementation is in use and any check against Morelli is performed with wider tolerances.

Objective
Even if differences found are small having both implementation would be benefital for:

• rigorous validation purposes
• example of architecture of one aircraft whith several aerodynamic models associated

Solution proposal
Any solution should take place after #26 and #23

This is an easy task after issues above are solved

Current situation
Environment is an important piece for the simulator. however it does not have an entry where its roll and its entities (wind, gravity and atmos) are explained.

Solution proposal
Create an Environment entry in the documentation where it is described, as well as atmos, wind and gravity.

Code is now ready to fill this values

Current situation
Inputs to FCS are applied immediately, however many real systems are simulated with a first order delay. A first example could be F16 Engine power demand with throttle.

Objective

• To be able to apply inputs with first order delays.
• Complete F16 model.

Solution proposal

• Implement a new struct under controls.jl which acts like a Range control with a first order delay.
• Look for existing Julia Packages that can be useful for this tasks.

hi Alex, i changed src/aircrafts module here https://github.com/parthp08/FlightMechanics.jl/tree/master/src/aircrafts.
what do you think about this way. it passed all tests locally and on travis cl.

Current situation
Most of the functions are non-mutating and use Base.Array

Objective
Although it performance is not a problem yet. Code would execute much faster using mutating functions to avoid reallocation and static arrays (https://juliaarrays.github.io/StaticArrays.jl/latest/pages/quickstart/)

Solution proposal

• Implement some benchmarks on the current situation. Is there anything in julia like pytest benchmarks? (https://pytest-benchmark.readthedocs.io/en/stable/
  9
• Try to find the current bottle necks with a profiler (https://docs.julialang.org/en/v1/manual/profile/) (https://mitmath.github.io/18337/lecture18/code_profiling)
• Decide what is easier to implement first: mutating functions / StaticArray
• Extra protect with tests functions to be refactored
• Run benchmarks & profiler again

From #65:

My idea was to implement some plotting, save, load... methods on that type. However, I think that could be accomplished on the Vector also...

It would be cool to pop up a plot of a trajectory whenever a ResultsStore is returned.

However, using ResultsStore as the primary mechanism for visualization has a few problems:

1. If someone else wants to use your fancy plotting code, they have to understand and create everything in ResultsStore, like Aircraft, etc.
2. Visualization typically involves many visualization-specific configuration options, for example velocity_vector_color="blue". It doesn't seem appropriate to store these options in ResultsStore.

In my opinion, a better pattern is to have a visualize_trajectory (or similar) function that takes in a trajectory along with visualization options and returns a displayable object. We can talk about more details if you decide to pursue this pattern.

Current situation
After reading https://white.ucc.asn.au/2020/04/19/Julia-Antipatterns.html, I realised that, currently, this situation occurs for some types in the code:
https://github.com/AlexS12/FlightMechanics.jl/blob/master/src/models/aerodynamics.jl#L24
https://github.com/AlexS12/FlightMechanics.jl/blob/master/src/models/dynamic_systems.jl#L10
https://github.com/AlexS12/FlightMechanics.jl/blob/master/src/models/propulsion.jl#L5

More may be found...

Objective
Adopt language paradigms and really obtain helpful error messages

Solution proposal
As suggested in: https://white.ucc.asn.au/2020/04/19/Julia-Antipatterns.html

MethodError indicates this quite well and as shown gives a more informative error message than you will write. An often overlooked feature is that you can declare a function without providing any methods.

When one is in this situation, defining a interface that another package would implement, one can provide a test-suite for testing it was implemented correctly. This is a function they can call in their tests to at least check they have the basics right. This can take the place of a formal interface (which Julia doesn’t have), in ensuring that a contract is being met.

The tag name "V0.0.0" is not of the appropriate SemVer form (vX.Y.Z).
cc: @AlexS12

Current situation
Right now the FCS is made up of Control elements which are responsible ie, for range check .

The FCSis Control elements are set with a set_controls(fcs, controls) method, where controls::Controls (notice final "s").

At least naming (Controls and Control) is confusing. This is an indication that something this types and their interaction might have duplicates in their function. In fact, and just as an example the values in Controls, are afterwards saved in FCS in different Control elements.

Objective

Develop a simple but functional FCS structure which can serve (at the present moment) to manage a Reversible control system. This will need to be refined to introduce a real FCS, AP, SAS...

Solution proposal
Some ideas to be explored are:

• Use Control elements in Controls that could afterwards stored in FCS.
• Store Controlsdirectly in FCS

Current situation
No documentation of reference frame description, axis direction and sign conventions

Solution proposal
Documentation of getter and constructo methods of position.jl.
Section on reference frames in project docs

Implementation of atmosphere_f16 produces results different from atmosphere_isa (see test\atmosphere.jl. Apparantly the model is the same and only units change. However, tests used for validation of F16 model relying on data from

Stevens, B. L., Lewis, F. L., & Johnson, E. N. (2015). Aircraft control
and simulation: dynamics, controls design, and autonomous systems. John Wiley
& Sons.

do not pass if ISA1978 is used.

Some investigations must be performed in order to determine the reason of the differences found.

Possible candidates:

• Unit conversion factors
• Model coefficients

According to Documenters.jl documentation, the following code shold create a navigation bar with the references 'Home', 'Api Reference' and 'Basics' :

makedocs(authors="Alejandro Saez Mollejo",
         pages = [
         "Home" => "index.md",
         "API Reference" => ["api-reference.md"],
         "Basics" => [
           "isa.md",
           "coordinate-systems.md",
           "dynamic_models.md",
           "anemometry.md",
           "kinematics.md"
         ],
         ])

However, the folliwng panel is obtained:

It seems to be working for other packages such as: https://github.com/juliohm/GeoStats.jl/blob/master/docs/make.jl and http://docs.juliadiffeq.org/latest/index.html#Supporting-and-Citing-1

Current situation
Currently only constant vertical gravity has been implemented.

Low priority

Objective

• Provide a variable gravitation with height model
• Provide a gravitation model taking J2 into account
• Incorporate centrifugal effect in non-constant models

Solution proposal

• Implementation of a gravity.jl file under flight mechanics with this functionality.
• Make it available under models/gravity.jl

Current situation

Modules organization

• FlightMechanics

  • Simulator
    • Aircrafts
    • Models

• It is imposible to define the same variable or function for different aircrafts:

  • If DE_MAX or Sw is defined for one aircraft, it cannot be defined for another one, because every ac file is included in the same module.
  • funcitons like Cnda(aero::F16Aerodynamics, α, β, da) are redirected for each aircraft with the aero type. However, it could be easier to have Cnda(α, β, da) for each aircraft in a different module.

• To access some variables like mac, Sw, the aircraft must be created first. This is sometimes a problem. For example, FCS might need to access surfaces limits before aircraft is created.

Objective

• Being able to define variables and functions with the same name for different aircrafts without the need of using method dispatch based on a type that is not used inside.
• Have a more modularized library: using Aircrafts.F16 is more clear than using.Simulator.Aircrafts

Solution proposal
Structure:

• FlightMechanics
  • Models
  • Aircraft
    • F16
    • C310

From #65:

Well, the aircraft type is still messy. It is used to dispatch on different methods depending on the aircraft type itself and also, it is composed of other types that store current value variables and are also used for dispatch in some cases:

• total forces and moments
• the flight control system: I would like to implement autopilots, stability augmentation systems... here in the future. It also stores control values and aerodynamic surfaces deflections.
• Propulsion system
• Aerodynamics

One important thing to think about is separation of static parameters and dynamic state. In my opinion, every dynamic state variable (e.g. actuator position for an actuator with lag, FCS memory, fuel, flow separation, dynamic stall) should be stored in a state that is separate from the static configuration parameters of the aircraft.

Some big advantages of this are:

1. Everything can be immutable, resulting in more efficient, understandable, and differentiable code.
2. There is less redundancy/confusion in storage - you only need to store the static parameters once and the state at every timestep.
3. I think this will make solving the ODEs to propagate dynamics more natural.

Let me know what you think of this and we can discuss details about design patterns, modularity, and scaling from very simple aircraft to very complex ones.

Current situation
no windows build

Solution proposal
https://github.com/ararslan/Jackknife.jl/blob/master/.travis.yml

Hi Alex

Thanks for your work. I am currently using JSBSim and its python interface to simulate the taxing of an aircraft. Would I be able to do the same with current master of FlightMechanics.jl

Thanks

Hey,

I would like to join this project and add code for autopilot/stabilization.

Current situation
Current trimmer version has demonstrated to work and has been validated against Stevens examples. However, some improvements can be accomplished.

Objective

• Introduce trimming variables (alpha, beta and controls) limits in optimization algorithm.
• Improve integrity: re-initialization of non-converged cases with different initial conditions.
• Capacity to interact with optimization method arguments.
• Capacity to load predefined trimmed cases that can be used for initialization guess
• Use tas, alpha, beta dynamic model instead of u, v, w
• (optional) other trimming capabilities such as calculate tas given the alpha.

Solution proposal

None

Current situation
If maximum and minimum deflection limits are not symmetric, the stick position for zero deflection is not zero. This is related to the implementation of FCS: C310FCS and F16FCS.

Objective

• Make the zero stick and pedals position produce zero deflection
• Make deflection limits correspond to stick and pedals -1 and 1 positions

Solution proposal

Current situation

Currently in dynamic_systems.jl when dynamic system state (x) is transformed to a complete State the position attribute is not updated completely:

• SixDOFEulerFixedMass and SixDOFQuaternionFixedMass only update PositionEarth

Objective
Have a full State in each integration step, particularly, a complete position.

Solution proposal

I can see three options:

• Add a new argument to convert methods including State before the integration step, so the position could be updated with the difference.

  • 🟢 seems easy to implement
  • :red: convert would change it semantics. converting from two things into one iof one to one.

• As PositionEarth is realtive compared to PositionLLH and PositionECEF another option would be to add an initial_position argument to PostitionEarth, which could be a PositionLLH or PositionECEF This would avoid passing steta before to convert.

  • 🟢 would make PositionEarth absolutely referenced (no difference with the others). Does not modify convert semantics.
  • 🔴 kind of more verbose perhaps.

• Use dynamic system derivatives to calculate displacement instead of passing step before.

  • 🔴 needs time step information, probably accumulates error...

Hi, @parthp08. Let's open an issue here and talk about possible collaboration in the implementation of a Julia Flight Mechanics package.

My name is Alex and I am from Spain. I am an aerospace engineer, currently working at Airbus. I have always been passionate about scientific programming specially in Python, although lately I have become very interested in Julia. I can also do some Fortran and Matalb. For me this project is just a nice way to continue learning both programming and Flight Mechanincs. Being able to program and reproduce many of the methods described in Stevens is for me a very rewarding way of learning, but I don't always have all the time I would like to do it.

My main idea when I started this repo was to develop a flight simulator similar to what you already saw in PyFME (https://github.com/AeroPython/PyFME) while learning and practicing Julia. I performed a big sprint last Christmas (this is just a personal project for me) and implemented some of the basic reference frame conversions, the F16 Steven's model and the trimmer. I spent quite a big time on testing and I would say that's the most valuable part of the project until now. In fact, I checked that the error you found in PyFME is not present here 😅

The next step I had in mind was the implementation of the propagation, so "the aircraft could start flying" finally!

As this was my first "big project" in Julia, I feel less proud of the code structure:

• I don't really see now if the models (src/models) I created are useful, make sense and generalize
• I don't really trust the modules structure I implemented at first
• Some methods are not exported where they should be and maybe some includes don'r really make sense.
  So I think there is still a lot of effort on making out of this repo a nice and useful package.

I will take some time to explore https://github.com/parthp08/Aircraft-Control-and-Simulation but I have seen you have progressed much more than me in the integration and control subjects. Is that the part you are more interested in? I have always wanted a control loop in the simulators I have implemented, but I have always got lost in the previous details.

I guess some collaboration would really lead to a more continuous, sustainable and promising development. 😃

Would you like to share some info about your background, objectives, roadmap for the project... or any other thing you consider important?

To avoid obtaining different results on aircraft retrimming (cf1a110#diff-8e408ab9a35ce54481575395d19d78e3R73) a factor needed to be applied to the g_tol passed to the optimization method (cf1a110#diff-c1e986153ebd20572e1a0361e3ee60b2R123).

It seems that the optimization is sometimes finishing with a result.minimum greater than the demanded g_tol. When running trimmer.jl and setting show_trace = true in stready_state_trim, the following output is obatined:

Iter     Function value    √(Σ(yᵢ-ȳ)²)/n 
------   --------------    --------------
     0     1.970477e+02     1.936188e+02
 * time: 2.5987625122070312e-5
   100     2.927562e-01     3.709745e-03
 * time: 0.26558709144592285
   200     6.327670e-04     2.926142e-04
 * time: 0.27391600608825684
   300     1.285786e-08     5.180261e-09
 * time: 0.28388404846191406
   400     3.355999e-13     2.090312e-13
 * time: 0.2951359748840332
   500     1.262379e-17     2.479054e-18
 * time: 0.3080861568450928
   600     6.494414e-22     2.076720e-22
 * time: 0.3211390972137451
 * Status: success

 * Candidate solution
    Minimizer: [3.74e-02, 4.44e-15, 5.00e-01,  ...]
    Minimum:   1.681096e-25

 * Found with
    Algorithm:     Nelder-Mead
    Initial Point: [1.25e-01, 0.00e+00, 4.70e-01,  ...]

 * Convergence measures
    √(Σ(yᵢ-ȳ)²)/n ≤ 1.0e-25

 * Work counters
    Seconds run:   0  (vs limit Inf)
    Iterations:    675
    f(x) calls:    1201

Notice that Minimum: 1.681096e-25 while g_tol = 1e25

src/dynamics/*.jl contains the dynamic systems.

Some tests must be written for this part. However, it is difficult to find independent validation values.

Another way of writing some of these tests would be to test one model against some others in equivalent conditions. For examples, six_dof_euler_fixed_mass is supposed to provide similar results as six_dof_quaternion_fixed_mass if the attitude is not extreme (theta near 90º)

Some projects test the full simulator response: once an aircraft is implemented they integrate a solution for the aircraft response to a given input. Even if this this is not a unit test, this might be useful at some point.

Current situation
Currently, each aircraft implements its own structure as it is a mean to dispatch the adequate method for functions like: get_arp, get_empty_cg, get_fuel_tanks... This is nonsense because:

• some of this methods need to be called before or during the aircraft object construction (see ugly workarounds in: C310() and F16())
• even there is a struct for each aircraft, they share the same attributes
• some ac variables are stored in methods to benefit from constant propagation (http://www.stochasticlifestyle.com/type-dispatch-design-post-object-oriented-programming-julia/) but this prevents from making variations in these parameters (ie. empty cg position is changed in many F16 validation examples)

Objective

• Create a unique struct to be shared by every aircraft
• Separate aircraft parameters in a different struct that will be part of the aircraft object.
  • These parameters struct can be specific to each aircraft until a good generalization is found. However, a set of general methods to access common attributes must be provided.
  • For each aircraft a default configuration will be provided.

Solution proposal

abstract type Parameters end

get_name(p) = p.name
get_wing_area(p) = p.wing_area
get_wing_span(p) = p.b
get_chord(p) = p.mac
get_arp(p) = p.arp

struct Aircraft
    parameters::T where T<:Parameters
    mass_props::RigidSolid
    pfm::PointForcesMoments
    aerodynamics::T where T<:Aerodynamics
    propulsion::Propulsion
end

F16(params, mass_props, pfm, aero, prop) = Aircraft(params, mass_props, pfm, aero, prop)

function F16()
    # default initialization of params, mass_props, pfm, aero, prop
    # ...
    Aircraft(params, mass_props, pfm, aero, prop)
end

Concerns
This will not benefit from constant propagation anymore.

The REQUIRE file could not be found.
cc: @AlexS12