Proyecto: Script Auto Flare Universal
kha29096335:
Ante la imposibilidad que tengo de contribuir en la sección Proyectos y todas sus subsecciones, ruego que algún moderador mueva la presente contribución a un lugar apropiado (Preferiría una sección de plugins, pero como no la hay creo que la mas apropiada es Proyectos: Aviones). Gracias.
Hola,
El presente proyecto que os presento no se trata de un proyecto individual "per se", si no que es una ínfima parte de un proyecto mayor que llevo realizando desde hace unos años, a mi ritmo, sin prisas, a medida que voy sacando tiempo libre y me apetece, de ahí lo de que "llevo años haciéndolo" y aún no ha sido presentado nada al público. Por otra parte, dicho proyecto ha sufrido algún cambio de dirección en cuando a qué SDKs usar en su implementación por lo que esto muchas veces ha derivado en aún más retrasos.
Cómo el título del hilo dice, se trata de un sistema de Auto Flare Universal, usable para cualquier avión. Evidentemente tendrá más sentido en unos que en otros, y también los resultados serán mejores en unos que en otros.
Los objetivos del presente proyecto son los siguientes:
-Independencia del código de la versión y tipo del sistema operativo.
-Universalidad del sistema. El sistema debe funcionar para cualquier avión, con la única restricción de que éste incorpore sistema ILS (AP, NAV, LOC y GS).
-Automatismo completo. El sistema debe controlar por si solo la tasa de descenso sin intervención del piloto, cuando las condiciones idóneas sean detectadas.
-El afinamiento del sistema, para adaptarlo a peculiaridades y especificaciones de un avión en particular, no debe conllevar la modificación del código a nivel funcional.
El sistema que os comento está actualmente prácticamente finalizado, solo quedan algunos detalles por pulir, como la posibilidad de cancelación del Flare e inicio automático de un "motores y al viento". Esto está actualmente contemplado en el sistema, y probado hasta cierto punto, aunque cambios de última hora hacen que fuese necesario volver a probarlo, por lo que no puedo decir si esta parte concreta de la cancelación es operativa al 100%, lo tendré que probar de nuevo.
Para llevar a cabo los objetivos he tomado las siguientes medidas:
-El desarrollo se basa en la edición libre de SASL, mediante scripts en LUA, de modo que es independiente del sistema operativo.
-El sistema se basa en el análisis de datos telemétricos del vuelo, en tiempo real de la simulación, los cálculos se realizan de forma relativa a los datos de entrada, de modo que es independiente del tipo y características del avión, no se usan tablas fijas preprocesadas.
-El sistema monitoriza altitud, estado del AP, del GS, de la energía, etc, de modo que es totalmente automático.
-El sistema usa dos constantes definidas al principio del script para "afinar" su comportamiento y que no sea necesario variar el código para que funcione con cualquier avión.
Licencia:
La licencia de distribución es GPL v3 http://www.gnu.org/licenses/gpl-3.0.html
Estado:
Trátese todo este código como código en estado BETA
Por qué lo he hecho:
Bueno, primero, evidentemente, porque he querido, pero una circunstancia me ha influenciado mucho en mi decisión. Viendo los aterrizajes ILS con el piloto automático de X-Plane y observando el resultado de un plugin que indica si el aterrizaje ha sido correcto, duro, muy duro o para morirse. Supongo que ése plugin que indica la calidad del aterrizaje, a estas alturas, todos lo conoceréis. Bueno, a mi siempre, o un 90% de las veces, me dice que nos hemos matado todos, y cuanto mayor es el avión, peor es el "aporrizaje" y X-Plane todos sabemos lo permisivo que es en esto. Yo creo que esto no debería ser así y, desde luego, no deseaba que mi desarrollo se sintiese tan "bruto" aterrizando; por otra parte el avión que estoy haciendo es bastante futurista, de modo que pensé en incluir un sistema que suavizase en la medida de lo posible los aterrizajes, dándole una cierta aura Hi-Tech.
Yo ya tenía encarrilado todo esto cuando en x-plane.org vi esta contribución: http://forums.x-plane.org/index.php?showtopic=51973&hl=%2Bflare+%2Bplugin en el que creo que un miembro de nuestra comunidad estaba interesado en que alguien realizase un plugin de Auto Flare. Como siempre, las respuestas en ese lugar fueron lo que siempre suelen ser en un lugar en el que los que saben cierran filas entre si para no desvelar a nadie sus oscuros secretos. Básicamente al final infieren que es imposible, debiendo ser un plugin especial para cada avión, y eso como mucho. Pues bien querido Carlos, aquí tienes tu sistema de Auto Flare, sin excusas, sin circunloquios, sin la pátina de "magia negra" que en según qué sitios quieren dar a lo que hacen. Como digo, no fue ése hilo el que me hizo hacerlo, entre otras cosas porque ya lo tenía hecho, pero si ha sido el que me ha hecho compartirlo tempranamente. Espero sinceramente que os sea útil y, como siempre, vuestros comentarios y preguntas serán bienvenidos.
Cómo funciona el sistema -o al menos se pretende-:
Yo no quería tener que escribir todo un sistema de piloto automático completo, partiendo de cero, para inhabilitar el propio de X-Plane y sustituirlo por el mío. Primero, porque no creo tener los conocimientos necesarios para acometer tal tarea, segundo, porque me hubiese llevado una ingente cantidad de tiempo con un resultado cuestionable y no menos importante, porque es lo que me hubiesen dicho en x-plane.org que hiciera. Si el piloto automático de X-Plane ya hace un buen trabajo manteniendo la orientación horizontal y el Glide Slope, ¿por qué cambiar algo que funciona?
Lo que hice fue lo que cualquier piloto hace para realizar un flare. Nada mas y nada menos que "tirar" de los cuernos. Así de fácil, bueno, más o menos. Como podréis imaginar es más fácil decirlo que hacerlo porque, para tirar de los cuernos del avión automáticamente, antes me tuve que tirar yo de mis pelos y partirme los propios. Mi sistema básicamente lo que hace es detectar que estamos realizando una aproximación por ILS con GS bloqueado, detecta cuando el propio piloto automático de X-Plane corta los motores, monitoriza la energía del avión y la altitud, lo que le da una indicación de la tasa de descenso, estadísticamente calcula una previsión de cuantos ciclos de ejecución del código va a haber antes de que el avión toque el suelo y lo va ajustando tratando de reducir desviaciones. ¿Suena fácil?, lo es, solo que había que averiguar cómo.
Tras mucho investigar, mirar y remirar por los numerosos Data Refs del simulador, vi que existía la posibilidad de "sobreescribir" el control del joystick / yoke por parte del usuario, y que por código podíamos moverlo a voluntad, de modo que eso es lo que hice. Mi código toma el control del yoke en el momento adecuado y tira, en la medida adecuada, para dejar de controlarlo al tocar tierra.
A continuación os indico los Data Refs básicos que uso y para qué. Obviamente quien sepa algo de programación básica de plugins lo podrá analizar con mayor profundidad en el propio código.
sim/cockpit2/gauges/indicators/airspeed_kts_pilot --> El sistema solo se activa por debajo de los 210 nudos.
sim/cockpit/autopilot/autopilot_mode --> El sistema solo se activa si está activo el piloto automático y los servos.
sim/cockpit/autopilot/autopilot_state --> El sistema solo se activa cuando detecta que el AP corta motores en la aproximación.
sim/cockpit/switches/HSI_selector --> Usado para saber que NAV (1 o 2) debe comprobar para saber el tipo de señal (VOR, ILS, etc), el sistema solo se activa cuando tenemos sintonizada una señal ILS.
sim/cockpit/switches/gear_handle_status --> Usado para saber si el tren está abajo o no, el sistema solo se activa con el tren bajado y se cancela al subirlo, si se cancela durante el flare se entra en modo AUTO GO AROUND.
sim/cockpit2/gauges/indicators/radio_altimeter_height_ft_pilot --> Usado para conocer la altura hasta tierra, el sistema solo se activa por debajo de los 50 pies.
sim/cockpit2/gauges/indicators/vvi_fpm_pilot --> Tasa de descenso en pies por minuto. El sistema solo se activa si detecta que estamos en descenso.
sim/joystick/yoke_pitch_ratio --> Posición del yoke (vertical). Usado para mover (tirar) del yoke.
sim/operation/override/override_joystick_pitch --> Flag para poder sobreescribir la posición del yoke mediante el yoke pitch ratio.
sim/cockpit2/gauges/indicators/total_energy_fpm --> Energía total del avión en pies/minuto. Usado para calcular cuanto tirar del yoke según la tasa de descenso.
Obviamente se usan más Data Refs, pero básicamente estos son los que gobiernan todo el sistema.
Y básicamente es eso. El sistema comprueba que el AP controla los servos, que el avión está en vuelo, que tenemos como fuente del HSI un ILS, que vamos a menos de 210 nudos, que estamos por debajo de los 50 pies, que el tren de aterrizaje está extendido, que estamos en descenso y en estas condiciones monitoriza la energía del descenso, para ir compensando tirando del yoke una cantidad determinada estadísticamente según como vamos descendiendo y según la posición del yoke.
Enlaces de descarga:
Sistema Auto Flare (scripts LUA para SASL):
https://docs.google.com/file/d/0BwgpgdeBe7gOa0Mxamd2b2VNLTA/edit?usp=sharing
Descomprimir en el directorio del avión para el que se quieran instalar. SASL debe residir en el directorio Plugins del avión.
Configuración: En el script flare_control.lua hay dos constantes, desired_energy y max_yoke_pitch_ratio. desired_energy es la energía que deseamos sea la de descenso, debe ser siempre negativo, cuanto más cercano a cero, mayor se intentará suavizar el descenso. max_yoke_pitch_ratio es la deflexión maxima a la que se puede poner el yoke. El máximo debe ser 1 que indica el yoke totalmente hacia atrás.
Plugin SASL licencia libre (compatible 32/64 bits):
https://docs.google.com/file/d/0BwgpgdeBe7gOSGxkaUJNRVZRV28/edit?usp=sharing
Descomprimir dentro del directorio Plugins del avión en el que se desee implementar SASL
Aviones de ejemplo (alguno es free, otros se incluyen con X-Plane por lo que no creo que haya problema en su distribución):
https://docs.google.com/file/d/0BwgpgdeBe7gOeU83ZnphYnc5Wms/edit?usp=sharing
https://docs.google.com/file/d/0BwgpgdeBe7gOUGdrWUFTcDJvZ2M/edit?usp=sharing
https://docs.google.com/file/d/0BwgpgdeBe7gObWtNR0lJdFZIWW8/edit?usp=sharing
https://docs.google.com/file/d/0BwgpgdeBe7gOYnQ2TEc3d01tZDg/edit?usp=sharing
Como descargar de Google Drive:
Cualquier problema que tengáis con las descargas, decídmelo, trataré de solucionarlo.
Un saludo y deseo os sea todo esto de ayuda. Preguntas sobre como funciona o peticiones de explicación del código son bienvenidas.
CarlosGarcia:
Sr kha29096335
Gracias...
Descargando ahora... Muchas Gracias ... :)
Carlos Garcia
Nota : Reportare en este foro, algunas pruebas con los aviones de SSG en especial el E170 y E190
kha29096335:
Cita de: CarlosGarcia en 23 Abril, 2013, 14:55:20
Sr kha29096335
Gracias...
Descargando ahora... Muchas Gracias ... :)
Carlos Garcia
Nota : Reportare en este foro, algunas pruebas con los aviones de SSG en especial el E170 y E190
De nada, espero lo puedas disfrutar. Prueba primero con viento a 0, porque tal vez haya que ir ajustando esas dos constantes que cito. Si al final, antes del touch down el avión levanta en demasía el morro, establece el valor de max_yoke_pitch_ratio a un valor decimal entre 0 y 1, por ejemplo 0.8 Y si aún lo levanta demasiado, ve bajandolo de décima en décima hasta encontrar uno adecuado. Si debes cambiar uno de esos valores, empieza tocando solo ese.
La constante desired_energy es eso, un deseo. Según las condiciones del descenso, viento, peso, etc, puede ser que el sistema se vea incapaz de conseguir exactamente ese valor, pero en general, esta constante determina lo agresivo que es el sistema al intentar suavizar el descenso. Juega con ámbos valores, pero siempre ajusta primero el max_yoke_pitch_ratio.
En algunos de los aviones de ejemplo que he puesto para descarga ya están ajustadas estas constantes. Tómalas como guía.
cescll:
Enhorabuena por el trabajo y gracias por compartirlo. ;)
Un par de dudas:
-En teoría, ¿sería posible aplicar el plugin a aeronaves IA? La idea sería generar un tráfico propio en un lugar determinado independiente del generado por el propio simulador.
-¿Qué tal se trabaja con SASL + Lua? ¿Es una combinación útil para plugins más generalistas, 'externos' a las aeronaves? ¿Cómo es su curva de aprendizaje? (Buf, ya van cuatro!)
Felicidades otra vez
kha29096335:
Cita de: cescll en 23 Abril, 2013, 23:20:25
-En teoría, ¿sería posible aplicar el plugin a aeronaves IA? La idea sería generar un tráfico propio en un lugar determinado independiente del generado por el propio simulador.
En teoría algo se puede hacer, hay que sustituir los Datarefs que yo he usado por los equivalentes en la sección sim/multiplayer/autopilot/ y sim/multiplayer/controls/ algunos no son los exactos, y otros ni siquiera existen, concretamente no hay dataref específico para saber si el avión IA tiene sintonizado un ILS, pero quizá un flag en el Dataref autopilot_state que sí existe para cada uno de los aviones IA pudiera usarse. Para otras cosas habría que usar la imaginación, pero básicamente habría que añadir un bucle para que el código controlase y mantuviese traza de los valores de todos los aviones IA (solo de los activos).
Por otro lado la IA pilota, literalmente, tan horripilantemente mal, que no creo que merezca la pena hacer una cosa así si no se pasa a controlar tambien todo lo demás por cada avión. Cuando veo los porrazos que se meten los aviones IA al aterrizar o las barbaridades que hacen al despegar -sobre todo los grandes en condiciones meteorológicas adversas- me llevo las manos a la cabeza.
Cita de: cescll en 23 Abril, 2013, 23:20:25
-¿Qué tal se trabaja con SASL + Lua? ¿Es una combinación útil para plugins más generalistas, 'externos' a las aeronaves? ¿Cómo es su curva de aprendizaje? (Buf, ya van cuatro!)
De todos los sistemas que he probado SASL es con el que más cómodo me encuentro. Lo ideal es hacerlo en C++ puro, pero entonces tienes que tener entorno para cada una de las plataformas, Windows, Linux y Mac, y en sus dos vertientes 32 y 64 bits, demasiado para desarrollos no profesionales.
Durante un tiempo también probé Pithon Interface, pero necesitas tener Pithon instalado, el adecuado a tu plataforma, junto con el plugin que ejecuta tus scripts en Pithon, la depuración es un problema y no es de muy alto nivel. Prácticamente lo único que hace es transformar las llamadas del SDK de X-Plane de C a Pithon, pero tienes que hacer prácticamente los mismos pasos, lo único que te facilita es la independencia de la plataforma.
SASL es de mayor alto nivel, te automatiza el tener que estructurar llamadas específicas a funciones del SDK para ciertas cosas. La depuración, en comparación con Pithon, es una maravilla, no porque sea buena si no porque la de Pithon Interface es demencial. Yo el SASL es el sistema que recomiendo, LUA tiene sus cosillas particulares, pero es cuestión de aprenderlo poco a poco y, además, hay buenas referencias en Internet.
Lo único malo que tiene SASL es que su versión libre y gratuíta está algo, bueno, yo diría que totalmente, abandonada por su creador, el cual se ha apuntado al carro de "hago esto gratis, y cuando todo el mundo lo use, me pongo a cobrar", abandonando lo que era gratis, algo que me parece absolútamente vergonzoso, así que todos que usamos SASL dependemos de otras personas que tengan a bien mejorar y compilar el sistema para las distintas plataformas.
Yo solo he usado SASL para avionica, de hecho a ello va dirigido, debiendo residir los scripts en el mismo directorio del avión para el que se han implementado. Seguro que puedes hacer cosas más generales, pero no existe, que yo sepa, un sistema para ponerlo a funcionar para todos los aviones, lo que hagas debe ir en el propio directorio del avión, y se carga y descarga al cargar o cambiar de avión.
Navegación
[#] Página Siguiente