Cuando abres un mybinder del repositorio, PyFME no viene instalado (porque no está en el environment.yml). Hace falta ejecutar esto:

/home/main/anaconda2/envs/python3/bin/pip install git+https://github.com/AeroPython/PyFME.git

Pronto necesitaremos algunas funciones nuevas.

Podemos hacer un nuevo paquete dentro de utils que se llame, si os parece adecuado, anemometry.py y que contenga funciones relacionadas con velocidades aerodinámicas. Creo que cuadra más en utils que en environment porque son funciones genéricas y no modelos físicos (como una atmósfera, una ráfaga, un modelo gravitatorio...).

De momento, es previsible que hagan falta (hay que elegir también los nombres):

• Cálculo de ángulo de ataque (alpha), de resbalamiento (betha) y velocidad verdadera (TAS) a partir de las velocidades con respecto al viento. De momento no hay ningún tipo de viento en el simulador (las velocidades con respecto a tierra coinciden con respecto a las aerodinámicas), más adelante incorporaremos vientos y habrá que tener en cuenta el darle a cada función los inputs que correspondan (la cosa se complicará más cuando planteemos las ecuaciones el sistema geocéntrico inercial...). Los inputs por tanto podrían ser la velocidad con respecto a tierra en ejes cuerpo y las velocidades del viento en ejes cuerpo (fijadas a cero por defecto).
• Cálculo del número de Mach a partir de la velocidad aerodinámica y la altura. Llamará a la ISA por debajo. Otra opción sería llamar a la ISA antes y pasar la velocidad del sonido en vez de la altura. Tendría la ventaja de que sería más fácil cambiar de atmósfera luego... ¿opiniones?
• Cálculo de la presión dinámica (q_inf) a partir de:
  • la densidad y la velocidad aerodinámica (TAS).
  • la presión y el número de Mach. Como implica andar pasando el gamma (que es un parámetro de la atmósfera) y en principio siempre vamos a tener la TAS de momento la dejo en el aire y nos quedamos con la primera sólo.
• Cálculo de la velocidad del sonido (a_inf) en función de la altura. La necesita la función anterior, ¿la metemos en la ISA o en anemometry?.

Otras:

• Cálculo de la altitud presión.
• Cálculo de CAS y EAS.
• ¿ideas?

¿Quién se anima?

JSBSim utiliza ficheros xml para crear sesiones, aeronaves, estado inicial... Evaluar ventajas e inconvenientes con respecto a json.

Relacionado con: issue #2

Hay que tomar una decisión al respecto:

• Cambiar theta, phi, psi en las cabeceras por euler_angles.
• Cambiar gamma, mu, chi en las cabeceras por ¿?
• alpha y beta pueden quedar como alpha y beta o llamarlos aero_angles (pero a lo mejor es menos explícito).

Otra opción es dejarlo como está y llamar a la función desempaquetando los ángulos:

from pyfme.utils.coordinates import wind2hor

angles = (1, 1, 1)
vector = (1, 1, 1)

wind2hor(vector, gamma=1, mu=1, chi=1)
Out[4]: array([ 1.38682227,  1.27032352, -0.09489569])
wind2hor(vector, *angles)
Out[5]: array([ 1.38682227,  1.27032352, -0.09489569])

¿Qué pensáis? Para no condicionar vuestra respuesta me ofrezco a cambiarlo si hace falta

Tarea de documentación que igual nos resulta útil. Id rellenándolo, yo iré añadiendo cosas cuando vaya teniendo algún rato. Igual esto sirve de inspiración: http://suave.stanford.edu/develop/

Aquí la página de la wiki que queremos ir completando:
https://github.com/AeroPython/PyFME/wiki/Tutorial-paso-a-paso-del-flujo-de-trabajo

Como primer paso conviene definir cómo se va a estructurar el código. Una posible división sería funcional al estilo del Aerospace Blockset de Simulink. Una posible propuesta sería:

• utils: cambios de sistema de referencia, parámetros de vuelo (TAS, CAS, EAS, Mach, Dynamic Pressure), conversión de unidades...
• environment: atmósfera estándard, modelos de viento...
• aerodynamics: calcular fuerzas con distintos modelos...
• engine: modelo de motor
• planes: cargar datos del avión (aerodinámica, masas, motor...)
• dynamics: distintos modelos de dinámica del avión (ecuaciones linealizadas, no lineales...), distintos integradores...
• actuators
• autopilot
• pilot
• ¿...?
• TESTS

El código se presta a tener una estructura orientada a objetos, de modo que se pueda definir un objeto aircraft (que se encargue de cargar los datos del modelo seleccionado y contenga las variables que determinan el estado del avión durante la simulación), un objeto engine (idem), un objeto ¿integrator? (que permita cambiar fácilmente parámetros de la integración del problema o las propias ecuaciones a integrar)...

Por supuesto, esto supone definir las interfaces entre distintas partes del código en una etapa inicial.

Dar con una arquitectura óptima en ambos aspectos supone un gran reto en este momento, pero es una de las grandes claves para que el código sea fácilmente desarrollable (definición de objetivos y tareas), mantenible, atractivo, eficiente....

Como hemos hablado en la reunión, a veces es necesario tener los cambios que otra persona ha hecho en una rama propia y que está todavía en proceso de pull request; unas veces para contribuir al pull request y otras para incorporar funcionalidades nuevas que requieren de otras que no están en la rama master todavía.

Me quedo encargado de hacer una entrada detallada en la wiki que explique el proceso.

@Juanlu001, ¿qué opinas del siguiente proceso?

Para contribuir a un pull request:

• Añadir al remote el fork del usuario que ha iniciado el pull request y hacer fetch.
• Crear una rama propia partiendo de la rama a la que se quiere contribuir.
• Hacer cambios, hacer push al repositorio remoto propio.
• Hacer pull request a la rama del usuario que hizo el pull request inicial User/PyFME/rama.

Para iniciar una rama nueva partiendo de una que está en proceso de revisión y no se ha integrado en el master (aunque pueda ser peligroso):

• Añadir al remote el fork del usuario que ha iniciado el pull request y hacer fetch.
• Crear una rama propia partiendo de la rama que está en proceso de revisión.
• Funcionamiento normal haciendo pull request a AeroPyton/PyFME.

Hola a todos,

Estaría bien, de cara a poder ir probando casos en los que metamos perturbaciones con los mandos que tuviésemos un nuevo module dentro del paquete utils, de nombre algo así como input_generator.py (u otro que se os ocurra) que contenga funciones para generar funciones del estilo de un salto escalón, un doblete, una entrada harmónica...

las cabeceras podrían ser algo así como:

doublet(t_ini, T, A, t, offset=0, var=None)

t_ini: tiempo inicial; T: Periodo o duración de la perturbación; A: amplitud pico-pico; t: vector de tiempos de la simulación; offset: cte a sumar a la perturbación; var: vector con una perturbación anterior, por ejemplo un seno, que se superpone al doblete.

La salida sería una vector del tamaño de t que da en cada instante el valor de la perturbación.

Cosa a tener en cuenta, pero innecesaria de momento:
Hacer de esto un generador y dejarlo preparado así para que si en algún momento el dt en la simulación va cambiando en función de lo que diga el integrador, se puedan ir genrando los inputs.

¿Alguien se anima?

Harían falta al menos:

• Doblete (se puede construir con dos escalones).
• Escalón
• Entrada harmónica

Otras:

• Entrada en rampa
• Triángulo (se puede construir con dos rampas).
• Parábola
• Exponencial

Escribir en funciones las ecuaciones que deben ser integradas:

• Fuerzas y momentos.
• Relaciones cinemáticas angulares.
• Ecuaciones de navegación.

Cada grupo de ecuaciones anteriores deber estar en una función distinta, ya que se pueden integrar secuencialmente.

Ecuaciones 6dof no lineales para avión rígido.
Ecuaciones de navegación en ejes tierra y con horizonte local siempre paralelo a dichos ejes.
Sin viento

Definir inputs, outputs, nomenclatura.

@DLpadilla había empezado esta parte.

El objetivo inicial del simulador es menos ambicioso que desarrollar un simulador con gráficos y, en principio, se centra en el motor de mecánica de vuelo. Sin embargo, ya que Flight Gear es un simulador libre que, aunque por defecto, trabaja con JSBSim como motor de mecánica de vuelo, permite elegir otro, sería muy interesante buscar la forma de integrar nuestro trabajo con este motor gráfico.

Antecedentes: http://es.mathworks.com/help/aeroblks/view-simulation-results.html

Al hilo del último pull request (#81) ha surgido la duda de si poner las referencias de todas las constantes que tenemos disponibles en models/constants. Parece una idea sensata y llevadera, ahora que todavía no hay muchas cosas ahí. Así que, generamos la tarea. Puedes ser tú mismo @miqlar, si te apetece, quien la haga. Te la asigno en principio y nos dices.

Dad la bienvenida a Lord DATCOM 😆

Quedan añadidos a la función (sea ramp, doublet...) durante toda la simulación cuando su utilidad se ciñe al intervalo t = (t_init, t_init + T).

Propongo cambiar las funciones para limitar la suma del offset al intervalo de interés.

De momento creo que no es un problema, pero estaría bien para evitar sorpresas, definir el entorno que tenemos que configurar en conda para trabajar todos con los mismos paquetes.

Ahora mismo los ejemplos están en forma de scripts:

https://github.com/AeroPython/PyFME/tree/2d4c4018/examples

Estaría bien tenerlos en formato notebook, como mínimo por tener las gráficas visibles. Además se podrían crear galerías de ejemplos como esta:

http://mybinder.org/repo/poliastro/poliastro

La tarea sería partir el código en celdas de forma ordenada y dejar las gráficas visibles al final. Puntos extra si incluimos algún widget interactivo 😄

@martosc está investigando un modelo de motor más complejo, que involucre parámetros de control y tomando las ecuaciones reales.

Ahora mismo ya hay código escrito pero no tiene licencia.

http://choosealicense.com/licenses/

You retain all rights and do not permit distribution, reproduction, or derivative works. You may grant some rights in cases where you publish your source code to a site that requires accepting terms of service. For example, publishing code in a public repository on GitHub requires that you allow others to view and fork your code.

Sería conveniente elegir alguna. Por ejemplo, JSBSim es Lesser GPL versión 2:

http://sourceforge.net/p/jsbsim/code/ci/master/tree/COPYING

Por otra parte, lo más habitual en proyectos de Python es usar MIT o BSD de 2 cláusulas. Aquí por qué cambié de una a otra en poliastro:

poliastro/poliastro#41

Como ya sabéis, se trata de decidir entre un modelo permisivo o uno copyleft:

http://es.stackoverflow.com/a/363/74

En pyfme/utils/coordinates.py, la función check_theta_phi_psi_range(theta, phi, psi) comprueba que el valor de los ángulos de Euler está dentro de rango. Sin embargo, al integrar si el avión tiene orientación psi=0.05 y en el siguiente instante psi=-0.05 se lanza un ValueError porque psi está fuera de rango. Esto fue una idea de @JuanMatSa y mía al implementar los cambios de coordenadas, pero está haciendo que se interrumpa la integración cuando el avión pasa de por este valor de psi.

Existen varias opciones para arreglarlo:

1. Tras cada paso de integración el valor de los ángulos de Euler se mete dentro de rango: psi=-0.01 --> psi=2pi - 0.01
2. Eliminar comprobación de rango. En mi opinión no es buena idea: si no se tienen en cuenta las restricciones en el dominio de los ángulos de Euler a una misma posición del avión le pueden corresponder varia combinaciones de ángulos (por ejemplo: psi=180, theta=60, phi=180, sería igual que psi=0, theta=120, phi=0, sólo la primera es válida).
3. Otras que podáis proponer.

Hasta que se haga merge de #65 el error se puede reproducir poniendo en oop_example.py turn_rate != 0.0 # rad/s e integrando durante tiempo suficiente.

Creo que es interesante, crear un breve tutorial o un diagrama con los pasos que ha dado @AlexS12 para ejecutar algunos casos de ejemplo, ya que creo que esto facilitaría que cualquiera entienda el funcionamiento del simulador completo. ¿Qué os parece?

Esto hereda del trabajo que comenzamos hace ya tiempo. Ver https://github.com/AeroPython/aeropy/tree/master/aeropy/atmosphere ¿Vamos a utilizar ese paquete o vamos a ir definiendo esas cosas a parte?

En este caso, no necesitaríamos trabajar con arrays de alturas, porque en cada paso de integración tendremos sólo una altura. El número de capas también puede ser menor.

Right now the control surfaces inputs have no delay (they go from 0 to 1 in no time). A transfer function for the actuators would be interesting to add, I have a branch where I propose a first idea.

As you can see in line 53, what I simply do is multiply the signal by (1 - exp(-deltat/tau)) to simulate a 1st order transfer function, previously modifying the input function to add the argument tau (line 16)

He empezado a implementar para que sirva como ejemplo (aunque seguro que hay cosas que se pueden mejorar) pyfme/utils/coordinates.py. De momento sólo hay dos funciones que cambian de coordenadas en horizonte local a ejes cuerpo y viceversa.

• La documentación está con el estilo de numpy que es bastante recomendable que usemos en la medida de lo posible.
• En el archivo pyfme/utils/tests/test_utils.py están los test para esas funciones. Para pasarlos hay que tener instalado pytest (conda install pytest) y desde la carpeta pyfme del repositorio escribir py.test en una ventana de comandos. Teníamos esto sobre cómo hacerlo en windows.

Os animo a que le echéis un vistazo a lo que he hecho, lo critiquéis todo lo que queráis para mejorarlo y a que vayáis completando el resto de cambios de coordenadas que faltan (tarea sencillita y más cerrada que otras que tenemos =P).

Como ya empezamos a discutir en la reunión anterior, necesitamos implementar un trimador. Su función es calcular los inputs en los mandos que tienen que ser aplicados en el instante inicial para que la condición de vuelo que se fija en este instante sea estacionaria.

Tenemos bastante información en las referencias que estamos consultando

Pues eso.

Ecuaciones que proporcionen las fuerzas aerodinámicas (dimensionales o adimensionales), dadas las deflexiones de mando (y presión dinámica y superficie mojada en caso de que sean dimensionales).

Modelo lineal, estacionario, para avión rígido.

Hemos visto que algunas precisiones no están bien ajustadas a los resultados, vamos a echar un vistazo a ver si se puede afinar un poco.

La variable psi no se está comprobando:

https://github.com/AeroPython/PyFME/blob/11fc5865f/src/pyfme/utils/coordinates.py#L24

Hay que corregir el error y añadir los tests correspondientes.

Abro este issue para ver si se os ocurren ideas para testear algún caso de integración...

Yo había pensado que podíamos comparar con un caso de JSBSim, pero... no tenemos implementadas las mismas ecuaciones, probablemente tampoco el mismo integrador y ni de coña el mismo modelo de avión.

Vamos a tener que ser un poco originales para ir haciendo algún tipo de validación más seria que esto:

La altitud que entra en la isa es la geopotencial. Se me ocurre que quizá esté bien tener dentro del paquete utils, un módulo altimetry.py que se encargue de conversiones de altitud.

• Altitud geométrica (h): sería la distancia al centro de la tierra menos el radio (medio) de la tierra.
• Altitud barométrica: es la altitud que en la atmósfera estándar corresponde al valor de presión que lee el barómetro del avión en vuelo.
• Altitud geopotencial (H): es la altitud geométrica considerando la gravedad constante. Para obtener la geométrica a la que corresponde: se busca la altitud (geométrica y con gravedad dependiente de la altura) que tiene el mismo potencial que la altitud geopotencial dada. Acaba siendo: h = r_t * H / (r_t - H)

Podemos ir implementando el módulo con conversiones del estilo: geopotential2geométrical(h)...

En el libro 📚 Stevens, BL and Lewis, FL, "Aircraft Control and Simulation", Wiley-lnterscience 📚 vienen datos para un modelo de F-16 💥 . El modelo de avión está hecho en subrutinas de Fortran 70 en el Anexo A y la descripción del modelo aerodinámico en la sección 2.3. La verdad es que estaría chulo implementarlo pero es una tarea gorda que igual requiere de un par de personas trabajando en ello. ¿Qué os parece?

Me parece recordar que @LUIS92AERO estaba interesado en los temas de aerodinámica y no sé si a @olrosales le sigue tirando el tema de los modelos de avión o prefiere hacer otra cosa.

Me gustaría también que nuestro experto en licencias (y muchas otras cosas), @Juanlu001, nos comentase si sería un problema implementar ese modelo, por el hecho de que ya esté hecho en Fortran 70 en el libro.

Antes de que alguien se ponga a ello, hay algunos temas sobre cómo estructurar el modelo de cada avión que me gustaría comentaros y que decidiésemos entre todos.

Como hablamos, estaría bien poder generar la documentación de manera automática con Sphinx. @Juanlu001 tiene experiencia en el asunto, con lo cual, para él. Si nos dejas a mano alguna fuente, guay!

Vamos a crear además del avión una esfera para ir haciendo tests. Aunque la parte que se refiere a actitud no tenga mucho sentido para una esfera (sobre todo porque como gire locamente vamos a tener gimbal lock) vamos a implementar una para casos de prueba.

La idea es hacer algo parecido al issue #5 (pull request #23). Simplemente habría que definir una función que devuelva la resistencia. Podemos dar sustentación en función de la velocidad angular (hay modelos sencillitos en papers por internet... lo que he econtrado está en nuestras referencias) y si nos venimos arriba podemos dar un momento que provenga de la fricción y que tenderá a disminuir la velocidad angular.

Como siempre, cuanto más mejor, pero pasito a pasito.

Como a raíz de #65 se introdujeron una serie de clases: Simulation, System, Aircraft, Environment, Gravity, Wind, Atmosphere convendría hacer una serie de tests unitarios para garantizar que la cadena de ".update()" funciona ahora y sigue funcionando cuando toquemos cosas.

Como esta parte es complicada para quien acabe de llegar, me asigno la tarea y de paso documento las cosas que quedaron pendientes. Si jugáis con el código y veis que falta documentación o no está bien en algún lado, ponedlo por aquí porfa 😃 (o cambiadlo vosotros mismos si os veis con ganas!).

He visto el código de Juan sobre coordinates.py y me pareció interesante escribirlo de otra forma. En vez de tener que definir mu, gamma y la X fancy (otra matriz infumable con senos y coseno) como los ángulos de Euler ( ya sea para la actitud de un avión o del vector velocidad) son una composición de rotaciones elementales voy a refactorizar el código y mutliplicar matrices elementales de rotaciones sobre cada eje para todos los cambios entre los ejes (wind, body, horizon).

La forma de Juan es mas rápida pq la multiplicación ya está echa de forma analítica y también tiene tests y todo así que a priori este módulo estaría flotando por si solo. Simplemente escribí este side project para volver a pensar en ejes y probar un par de tests. Quizá en el futuro nos venga bien.

¿Alguien se anima a hacer un logo?

Ver:
#42 (comment)
Básicamente, la documentación no se muestra del todo bien debido a algunos errores de formato (espacios, saltos de línea...)
Hay que revisar la documentación y aprovechar la pasada para subsanar otros posibles errores.

Desde el punto de vista del simulador, la aeronave se compone de:

• un estado: variables que determinan su posición, actitud, posición de los mandos y otros parámetros (masa, inercia...). Bueno, habría que diferenciar entre los datos de un avión y el estado propiamente.
• unos parámetros: aerodinámicos, del motor, de las masas, del tensor de inercia. Estos datos son usados en los modelos físicos para actualizar el estado en cada paso de integración ¿cómo cambia el coeficiente de sustentación con el ángulo de ataque? ¿cómo varía el tensor de inercia al variar la masa? ...

Normalmente estos parámetros son leídos desde unos ficheros al iniciarse el programa. Otra de las grandes tareas que condicionará el desarrollo del simulador es la estructura de estos ficheros. Dado que existen en la actualidad numerosos simuladores, una buena idea es estudiar qué tipo de archivos y estructuras utilizan y tratar de adoptar una forma estándar, de modo que podamos beneficiarnos de herramientas ya desarrolladas para crear aeronaves, así como de aeronaves ya creadas.

• FlightGear:
  • http://wiki.flightgear.org/Howto:Make_an_aircraft
  • http://wiki.flightgear.org/Aircraft-set.xml
• Datcom:
  • https://en.wikipedia.org/wiki/United_States_Air_Force_Stability_and_Control_Digital_DATCOM
  • http://es.mathworks.com/help/aeroblks/digitaldatcomforcesandmoments.html
• ¿Otros?

¿Qué os parece si dejamos implementado un módulo que represente las soluciones y las entradas? Cualquier usuario puede hacer eso fácilmente pero de esta manera, nos resultará más cómodo para lanzar casos. En caso de que os parezca bien, ¿Qué ponemos?

Puede ser definido en un archivo .py con sus propiedades másicas, aerodinámicas... escritas en él.
Hay que definir como se cargan los datos de este avión en el archivo main de prueba.

Se pueden obtener datos de alguno de los aviones ya creados en FlightGear almacenados en xml's: http://sourceforge.net/p/jsbsim/code/ci/master/tree/aircraft/ pero debe ser un avión sencillo.

Más adelante se pasará a un archivo con el formato acordado y se creará una clase que lo cargue.

La mayoría de los coeficientes pueden ser, de momento, constantes con el número de Mach y esas cosas... Vamos a intentar coger una avioneta y volar en subsónico.

Comenzamos con las nuevas tareas!

Por el momento tenemos implementadas las funcionalidades básicas, a falta de que se terminen de fusionar los cambios en #23 (first aircraft @olrosales) y #20 (anemometry @martosc).
Conviene que en cuanto incorporemos estas ramas se pueda empezar a trabajar en algún ejemplo "más serio" que el que tenemos del avión volando. Probablemente nos demos cuenta de algunos fallos...

Podéis proponer maniobras y tratar de implementarlas. Cuantas más tengamos, mejor. Por otro lado estaría bien que todos los que estamos desarrollando hagamos algún caso. De este modo seremos nuestros propios usuarios y podremos ir viendo cómo de cómodo es usar el paquete que estamos haciendo, qué tal funciona, qué necesidades tenemos...

Podemos probar tanto con el avión como con la pelota (con y sin efecto magnus).

he empezado un pequeño script que incluye el cambio entre angulos de euler y quaterniones

Proximamente: mas información y el pull request de lo que llevo hasta ahora =D

Cada module (cada .py) que tenemos tiene un pequeño docstring al principio con una breve descripción. Spyder pone automáticamente el autor y la fecha. Deberíamos ponernos de acuerdo sobre qué incluir en cada uno y dejarlos todos con el mismo formato. Más que nada porque se usan para generar la documentación.

¿Propuestas? Podemos buscar lo que se incluye en los docstrings de otros paquetes y fijar en base a eso nuestro estilo.

Me encargo de cambiarlos una vez que lleguemos a un acuerdo.

Sería una buena idea hacer una entrada en la wiki que presentara el proyecto a gente que pasa por aquí. Para nosotros es más o menos obvio, pero para alguien que viene de pasada, todo es un misterio. Creo que lo estamos haciendo bastante bien con la wiki, así que puestos a mejorar...

La entrada debería contar:

• qué hace el simulador hasta ahora.
• qué está previsto que haga próximamente y a largo plazo.
• qué tipo de tareas necesitamos llevar a cabo desde un punto de vista general (para el detalle ya tenemos los issues).
• email de contacto o similar.
• link al flujo de trabajo.

Podemos poner el link a esa página en el readme o directamente, todo ahí.

¿Se os ocurren más cosas? ¿Alguien se anima a ir poniendo algo en la wiki?

Según las indicaciones de pytest, no es recomendable tener un init.py en la carpeta de test.

avoid “init.py” files in your test directories. This way your tests can run easily against an installed version of mypkg, independently from the installed package if it contains the tests or not.

No obstante, no he conseguido correr los test sin él. Al intentarlo daba un error de importación: no module named pyfme.

He visto que @Juanlu001 no tiene el init.py en la carpeta de tests y que tiene un testing.py en la carpeta principal de poliastro y una función test en el init.py de polisastro. No he conseguido los porqués.

Ya que estamos con los tests. No sé si la manera más organizada es irlos metiendo en carpetas separadas dentro de cada uno de los subpaquetes o tenéis alguna idea mejor.

De momento no pasa nada (lo pongo para aquí para acordarnos), pero para la siguiente vez que nos juntemos deberíamos llegar a un acuerdo sobre como pasar los argumentos que son vectores, si como arrays o por cada una de sus componentes. De momento tenemos ejemplos de ambas:

linear_and_angular_momentum_eqs(time, vel, mass, inertia, forces, moments)

body2hor(body_coords, theta, phi, psi)

otra opción más avanzada, como comentaba @Juanlu001 en el grupo de Telegram, sería hacer algo parecido a lo que hace SymPy o usarlo directamente.

Si no va dentro de anemometry, podría encargarme de esto

Análisis de los mejores inputs para el trimador

Este fichero provisional será el que utilicemos para hacer las primeras simulaciones.

En él se cargarán los datos del avión, se configurará el estado inicial y se irán integrando las ecuaciones.

• Las fuerzas (aerodinámicas, gravitatorias, motor) serán generadas por funciones externas.
• Las ecuaciones estarán definidas en funciones externas.
• Las funciones auxiliares (como cambios de sistema de referencia estarán definidas por funciones externas.
• Las funciones relacionadas con atmósfera estarán también definidas externamente.

Se pueden definir varias maniobras de prueba.

Definición de la nomenclatura en la página de la wiki (modificar al antojo, todo lo que hay ahora mismo son ejemplos). Llegar a acuerdo por parte de @AeroPython/pyfme

Véase:

CL0, CLa, CLde, CLdih = Long_coef_matrix[0,:]
CD0, CDa, CDde, CDdih = Long_coef_matrix[1,:]
CYb, CYda, CYdr = Lat_coef_matrix[0,:]

Cmfull = Cm0 + Cma * alpha + Cmde * deltae + Cmdih * ih
Clfull = Clb * beta + Clda* deltaail + Cldr * deltar
Cnfull = Cnb * beta + Cnda* deltaail + Cndr * deltar 

 m = 4600 * 0.453592   # ¿ponemos unidades aquí?
 Ixxb = 8884 * 1.3558179
 Iyyb = 1939 * 1.3558179
 Izzb = 11001 * 1.3558179
 Ixzb = 0 * 1.3558179

Sw = 16.258   # ¿Los alargamos?
c = 0.4450056
b = 3.428122