Foro x-plane.es

Saludos a todos!

Vengo con un problema exótico, o, al menos, eso creo. Me explico y después os planteo las preguntas y solicitudes... ¡ojo! el correo es largo, ya que os explico toda la situación que ha motivado esta consulta... Por lo tanto, doy gracias a los lectores pacientes que se atrevan a llegar hasta el final.

En el trabajo estamos desarrollando un software de integración precisa de trayectorias. ¿Qué es eso?

A partir de las observaciones de diferentes sensores embarcados en aviones (inerciales, GPS...) los cuales nos dan información sobre aceleraciones tanto lineales como angulares del aparato, así como posiciones de menor precisión (el GPS, sin procesar, no da para mucho) INTEGRAMOS la trayectoria recorrida. Esta trayectoria busca tener precisiones entre centimétricas y, a ser posible, milimétricas. Eso es la integración precisa; integración, porque a partir de medidas esencialmente de aceleración y usando las ecuaciones clásicas del movimiento, pasamos a obtener velocidades y después posiciones; precisa porque buscamos una precisión alta (esto último es de perogrullo, ¡vaya!) que no se obtiene ni mucho menos solamente con GPS.

La necesidad de la precisión viene dada por el tipo de aplicaciones a desarrollar posteriormente (típicamente, relacionadas con el mundo de la cartografía y disciplinas asociadas).

Mmmmm.... ¿Y qué pinta X-plane en todo esto? A ello voy.

He dicho antes: "a partir de las observaciones de diferentes sensores embarcados en aviones...". Embarcados implica volar; volar es muy caro, y no nos podemos permitir - ni de lejos - hacer vuelos reales cada dos por tres (ni cada uno por dos) para obtener datos crudos de los sensores.

Por ello, seguimos un camino indirecto para obtener esos datos en crudo (aceleraciones o posiciones GPS). Usamos la simulación.

Primero, nos inventamos una trayectoria (luego vuelvo a esto). A partir de esta trayectoria, pasamos un software, tambien nuestro, que conocemos como "generador de señales". Este "generador" toma esa trayectoria y, a partir de ella, crea las "pseudo-observaciones" que habrían generado los diferentes sensores en cuestión si realmente hubiesen estado volando esa trayectoria.

A partir de aquí, tenemos esas observaciones simuladas que, usando el integrador, nos permiten volver a regenerar la trayectoria y cotejarla con la original. ¡¡¡Espero que haya quedado claro!!!

Solamente comentar que toda la parafernalia previa, la invención de la trayectoria y la generación de las correspondientes pseudo-observaciones de los sensores NO son más que una manera de paliar la imposibilidad de obtener información a partir de vuelos reales debido a su elevado costo. Lo que realmente estamos desarrollando y nos interesa es el software de integración precisa de trayectorias.

Vuelvo con la "invención" de la trayectoria, tal y como prometía antes. Hasta hace bien poco generábamos trayectorias "sintéticas". Definíamos manualmente las coordenadas de unos cuantos puntos de paso obligado ("waypoints") y a partir de ellos hacíamos una interpolación matemática que generaba una trayectoria que pasaba por ellos.

Funcionar, funcionaba. Pero las trayectorias eran demasiado "suaves" como para parecerse a la realidad, con lo cual, es difícil asegurar que el integrador pudiera absorber la dinámica de situaciones en vuelo real.

Entonces, hace unas semanas, se me ocurrió que podíamos usar la opción de volcado de datos de X-plane para obtener trayectorias afectadas de dinámicas de vuelo, diremos, mucho, muchísimo más próximas a la realidad. Ya he hecho dos de esos vuelos, empleando aviones con dinámicas muy distintas: la Baron de awall en primer lugar y el Cirrus Vision SF50 que viene por defecto en X-Plane 10. La idea era tener trayectorias originadas por aviones a hélice y a reacción.

Utilicé la opción de volcado de datos ("Data input & output", si no recuerdo mal ahora) seleccionando para su escritura latitud, longitud, altura, heading, pitch y roll. Además (por temas de modelización de vibraciones del motor) también volqué las RPM de éste. Los datos se capturaron con una frecuencia de una medida por segundo.

Tengo que decir que los resultados que hemos obtenido han sido muy satisfactorio (y que han puesto a prueba los diferentes algoritmos del simulador).

NO OBSTANTE, y por fin llegamos a las preguntas y solicitudes, HEMOS DESCUBIERTO que la información relativa al ROLL (y SOLAMENTE AL ROLL) muestra un comportamiento bastante antinatural, por así decirlo. Mientras que la latitud, o el heading, o la altura (en realidad el resto de las magnitudes capturadas) muestran un comportamiento CONTINUO (es decir, van variando sin saltos), el ROLL sigue un patrón que no se ajusta en absoluto a la realidad, dando saltos en los valores que no - a mi entender - se pueden corresponder en absoluto con el giro alrededor de este eje.

Os he añadido una gráfica para que lo veáis: (http://s29.postimg.org/ac67y31vb/roll_cirrus_vision_sf50.jpg)

En el eje horizontal está el tiempo; el el vertical los grados de roll. Observaréis un patrón bastante característico y repetitivo en el que el roll va cambiando progresivamente de valor y, después, de repente, da un salto repentino. Además, la tasa de cambio del roll parece ser siempre la misma; así parece demostrarlo la pendiente de las líneas en el gráfico. Sencillamente, increíble.

Por fin, LA PREGUNTA. ¿Alguien de vosotros ha capturado datos y ha observado este fenómeno? Ya me imagino que será difícil que alguien lo haya hecho, pero antes de pasar a la solicitud posterior, tenía que preguntarlo.

La solicitud está motivada porque no sé si este comportamiento del roll se debe a una de dos posibles razones: (1) el rendimiento del ordenador donde he realizado los vuelos, un portátil Acer i3 de primera generación (quadcore, no obstante) con 4Gb de RAM y una ATI relativamente sencilla, corriendo X-plane 10.25 o bien (2) y lo más temido y probable, que X-plane tenga un "bug" en este componente de volcado de datos.

¡Ah! Este fenómeno se produce tanto en el vuelo con la Baron de awall como con el Cirrus de X-plane. Por tanto, de entrada, descarto que el avión en sí sea el problema.

Lo que quisiera pediros es, si alguien es tan amable, si es posible que realiceis un vuelo con el Cirrus que viene con X-plane capturando longitud, latitud, altura, heading, pitch, roll y RPMs. Frecuencia de captura: una medida por segundo. No es necesario que el vuelo sea largo, ya que este fenómeno del roll se produce de principio a fin del vuelo. Con 10 minutos será más que suficiente (así, también, se reduce el tamaño del archivo data.txt).

En fin, si más no, tengo que agradeceros la paciencia por haber llegado a leer hasta este punto. Sé que puedo ser soporífero escribiendo...

Si alguien se anima a hacer la prueba, puede enviarme el archivo a mi cuenta de correo (comprimido será más fácil). Como las normas del foro prohiben dar direcciones en claro en los posts, os doy los medios para deducirla.

Primero va mi nick, que encontraréis en este mensaje. Obviamente, hay que añadir una arroba. El servidor es el famosísimo gmail, acabado en com.

Bien, GRACIAS a todos!!!

Bleriot13.

Se observa que los saltos son tanto positivos como negativos, pero parece que las continuidades siempre son negativas, aunque cuando aumenta la frecuencia de los saltos no se ve claro en el gráfico. ¿Los vuelos han sido realizados con viento? Supongo que ese gráfico representa un vuelo recto y nivelado conducido por el piloto automático, ¿verdad?

Disculpa, es solo curiosidad.

d_acheb,


es un vuelo recto y nivelado en su mayoría. Responde a un vuelo real saliendo de San Sebastian, yendo hasta Perpignan por la cara norte de los Pirineos y bajando hasta Barcelona por Begur y Calella.

No hay piloto automático, pero el vuelo del Cirrus es muy estable; en otras palabras, no hay bandazos ni acrobacias.

Gracias por el interés.

¿Y has hecho un vuelo o dos con piloto automático, vuelo recto y nivelado y ausencia de vientos para obtener un blanco? Es lo que yo hubiese hecho.

Me llama la atención que todas las continuidades sean negativas o descendentes; quizá al principio, en el cuarto o quinto salto, puede que haya una continuidad positiva. Pero no estoy seguro por la brevedad de la continuidad, y puede que no sea tal.

¿Que valor tienes en "modelos de vuelo por frame"?

(http://s27.postimg.org/grfuvu1rj/image.jpg) (http://postimg.org/image/grfuvu1rj/)

Quizás el ordenador sea un poco justo para ejecutar correctamente X-Plane, subiendo este parámetro a 4 o 5 haces que se destine mas tiempo de CPU para el modelo de vuelo -importantísimo- y menos en el render en general, y afecta sobretodo a los aviones ligeros.

Para lo que estáis haciendo lo mejor sería correr el X-Plane con las opciones de render al mínimo para que sea los mas estable posible, y así poder dedicar mas tiempo de CPU al modelo de vuelo el cual se procesará correctamente y tendría que quedar bien reflejado en la salida de datos.

EDITO:

Acabo de hacer un vuelo de LESU a LECD con la B58 de Awall (unos 10 minutos) y la información del ROLL la veo bastante constante (sin esos saltos que muestras).
Sin PA, siguiendo el valle a 4000 pies y con viento, por lo que hay virajes.

DATA.txt (https://dl.dropboxusercontent.com/u/59143574/Data_LESU-LECD_B58.7z)

d_acheb,


no, no he probado el vuelo nivelado, sin viento y con piloto automático, ya que el objetivo de la recogida de datos era precisamente generar dinámicas no "perfectas" para poner a prueba la algorítmica del integrador de trayectorias en recorridos "no suaves".

No obstante, lo probaré. Gracias por la sugerencia y el interés!

Bleriot.

grrr05,


Pues tengo 2 modelos de vuelo por frame nada más. A pesar de eso no he notado el efecto de "encabritado" (flutter) del que hablan en la FAQ de x-plane.com, con lo cual supongo que es suficiente; la actitud de los aviones es aparentemente correcta.


Probaré otro vuelo subiéndolo a 3, otro a 4, etc. A ver que pasa. No obstante, la totalidad del resto de los datos, como decía en mi primer post, es perfectamente continua, solamente tengo problemas con el roll; eso es lo que me hace pensar más en un bug que en un problema de rendimiento de mi máquina. Además, sucede así en las dos pruebas hechas (Baron 58, Cirrus Vision SF50).

Abundando más en el tema, la distribución de los valores del roll no parecen apuntar a que haya una falta de modelos por unidad de tiempo; si fuese así, creo que lo que vería són valores más dispersos, no mostrando una situación en la que, según la gráfica, el roll arranca, repetidamente, de un valor alrededor de +1.75 grados (aproximadamente) y baja, sistematicamente (con saltos) hasta los -1.75, volviendo entonces, de golpe y sin continuidad, a los 1.75.

Este movimiento, en la realidad, se correspondería con un giro alrededor del eje longitudinal de un lado a otro cubriendo esos 1.75 + 1.75 grados de recorrido, volviendo, sistemáticamente, a empezar otra vez.

Teorías aparte, seguiré tu consejo y probaré tal y como dices.


Gracias por la prueba!!! Ya he descargado los datos y, el lunes, cuando esté en el trabajo, haré una gráfica tiempo vs. roll. Ya te adelanto que en el caso de la Baron 58 de awall el fenómeno se notaba MENOS, pero aún así, si se ponía en una gráfica, también se veía.

Por cierto: con cuantos modelos por segundo lo has hecho? Y con qué frecuencia has recogido los datos? Con el segundo que comenté????

Gracias de nuevo!!!

Bleriot.

Turbulencias, es perfectamente normal que aparezcan esos ligeros alabeos, estamos hablando de +-1.5º.
He hecho algunas pruebas con el Cirrus TheJet a intervalos de 1s en condiciones CAVOK sin vientos ni nada y con Heading activado en el AP para obtener un vuelo lo más estable posible para descartar fallos en el vuelco de datos y viendo el data.txt las variaciones son mínimas, de -0.06753º a -0.07584º

Si pongo un mínimo de turbulencias (apenas desplazar el selector) aparecen alabeos de -2.70098º a 2.11872 poco más o menos lo que aparece en el gráfico.

zxplane,


gracias por la respuesta y el interés.

Entiendo que aparezcan esos alabeos debido a las turbulencias, y 2 grados en un sentido u otro es realmente poco. ¿A ti también te siguen el patrón aparentemente DISCONTINUO? (salto del valor más negativo al más positivo DE GOLPE???).

Quiero decir: me imagino que, evidentemente, el avión se mueve, que el roll no es algo inamovible cuando hay turbulencias, pero no debería seguir más bien un patrón tipo onda sinusoidal, donde, cuando has llegado a un valle entonces remontas con suavidad hacia la cresta????

Vamos, algo así:

(http://s30.postimg.org/foje9ra2p/sinusoidal.jpg)

No tiene por qué ser tan perfecto como en la ilustración, pero el sentido común me dice que si el avión "rola" de 2 a -2 grados... para volver a llegar a los 2 des de el -2, tiene que pasar antes por -1.9, -1.8.... 1.9 y finalmente llegar al 2. Eso es lo que NO se ve en el gráfico original.

Gracias!

El simulador lo tengo configurado a 5 y la frecuencia de los datos la puse a un segundo.

Bleriot, yo creo que este tema sería mejor que lo tratases diréctamente con Laminar, sobre todo dado que es de naturaleza científica y de desarrollo serio.

Tienes razón en que deberían ser transiciones más continuas, pero como no sabemos como X-Plane cachea los datos antes de volcarlos, a saber que ocurre y por qué se dan esos saltos, porque puede ser cualquier cosa, desde un bug en el modelo de vuelo, un bug en el volcado o hasta un "trampeo" en los cálculos para no consumir más CPU y que el efecto en el simulador sea suficiente, sin ser exacto, o incluso algo particular en tu equipo.

La discontinuidad es, en definitiva, una zona (o tiempo) de no recolección de datos.

-Se emiten y no se recogen: (problema de software)
-No se emiten, ergo, no se recogen (problema de hardware, a priori)

¿cuánto tiempo suele estar si recoger datos?

Sería interesante en una misma gráfica...comparar dos rutas iguales (al menos el mismo tramo) con la Baron y el Cirrus y solapar la gráfica de alabeo para ver "in situ" en qué momento hay un valor no deseado.

Primeramente, tal como te indica d_acheb, prueba en blanco...no vayamos a introducir, además, errores de tipo personal. Vamos a pensar que es el software/hardware es el que comete el error.

-Acotación de errores: tienen la misma frecuencia de discontinuidad realizando la misma acción? --->...(siempre que viro a la izq. aparece el error cada x tiempo, por ejemplo). Cuántas veces has hecho la prueba?, otras rutas? mismo peso, combustible, posición de CG,..?.

...y el hardware?...está calibrado?...siempre el mismo hardware?...no hay que dar por sentado que éste no pueda introducir errores!

P.D.: para el alabeo, con AP: on, tengo fluctuaciones de +- 0.03º a 6000 ft/200knt ...tal vez algo mas (+-0.04) al acercarme a las montañas

Cuanto tienes puesto la zona muerta del joy en el eje "roll" ?? podría ir por ahi como comenta qumake

A todos (muchos) los que habéis contestado,

disculpad que durante el día de ayer no apareciese por el foro; era domingo y tuve responsabilidades familiares que atender. Eso sí, no dejé de pensar que seguro estaríais ahí dándome respuestas  :)

Recojo todas vuestras sugerencias:

- En un rato haré un plot del vuelo de grrr05 para ver si muestra el mismo fenómeno. Postearé el gráfico durante la mañana para compartir resultados.
- En cuanto pueda (será el próximo fin de semana, ya que tengo que montar cuernos, pedales, etc. en el salón y los laborables llego tarde a casa) haré un vuelo con AP para ver si se reproduce el problema.
- Pude hacer un vuelo con 3 modelos por frame el sábado. No obstante, este era un vuelo "acrobático" que me habían pedido en el trabajo para poner al límite las capacidades del integrador. Hay mucha pirueta y no sé si es lo mejor para comprobar las discontinuidades. También generaré un plot y lo posteraré.
- Sobre el calibrado del joystick... ay, no recuerdo a cuanto lo tengo; creo recordar que AUMENTÉ la null zone hace tiempo para evitar este tipo de problemas, pero ahora mismo no consigo recordar la cifra. También lo comprobaré el fin de semana.
- Si todas la pruebas no consiguen eliminar el problema, intentaré contactar com Laminar. Creo que hay un correo o formulario de contacto en el .com

A mi, no obstante, me sigue mosqueando que el problema solamente aparezca en el roll y en ninguna otra magnitud... llevo más de 30 años en el mundo de desarrollo de software y sé que los bichitos (bugs) se cuelan en cualquier parte; y el volcado de datos no debe ser precisamente una de las opciones más usadas... con lo cual, tal vez, sea de las menos testeadas... Sí, sí, soy tozudo, lo sé!!!  :D

Gracias de nuevo a todos! Os mantendré informado de los resultados de las pesquisas y os pasaré los plots lo antes posible.

Bleriot.

Como decía, hace años, la orquesta platería....

"la vida te da sorpresas, sorpresas te da la vida, "ay Dios!"...

Avanzo, antes de entrar en materia, que al procesar el vuelo acróbatico (o lo que yo considero acrobático dadas mis condiciones como piloto de simulador) el problema del roll ha desaparecido. De momento, os pongo las gráficas que he prometido para que les echeis un vistazo.

A continuación, el vuelo en características ideales de grr05. Solo muestro el roll:

(http://s29.postimg.org/t2wpff9rb/grr05.jpg)

Tal y como grr05 avanzaba en su post, no hay problemas de ningún tipo. Todo es perfectamente continuo.

Ahora el roll de todo mi vuelo acrobático (unos 25 minutos de datos a 1Hz):

(http://s10.postimg.org/z8tds79nd/aerobatics1.jpg)

Fijáos en que el roll sigue un patrón parecido al de grr05 hasta más o menos el segundo 775. Ahí empieza el baile. Acaba, aproximadamente, alrededor del segundo 1180 - 1190. Ahí decidí que ya había capturado suficientes datos para el sofware de integración y, como muestra el resto de la gráfica, el roll vuelve a normalizarse en mi ruta en vuelo "sensato" hasta el aeropuerto.

A continuación un zoom de la parte más "festiva":

(http://s16.postimg.org/jwnaaymqt/aerobatics2.jpg)

A pesar de las perrerías hechas al volar, la continuidad se mantiene. No os dejéis engañar por los grandes picos que van desde arriba de todo (aproximadamente, 180 grados) hasta abajo de todo (aproximadamente -180 grados) o viceversa. Estos se deben a el "cambio de fase" de los valores angulares del roll. En otras palabras, si se está girando alrededor de este eje, aproximándonos a 180 grados y se continua con el giro, de golpe se pasa de 180 a -180 (o viceversa) con lo cual es normal que estos saltos se produzcan.

Hay diferencias en el "setup" con respecto al vuelo que motivó este post.

- Primero, he subido el número de modelos por frame de 2 a 3 (SOLAMENTE a 3).
- Segundo, he volado SIN conectar un segundo terminal, donde, en el primer vuelo, tenía en marcha el programa "Navigation" de foufou para tener un seguimiento en tiempo real del plan de vuelo.
- Tercero, he eliminado la captura de las RPM, ya que en este reactor (Cirrus Vision SF50) siempre salen a 0... por no haber revoluciones que medir.
- Cuarto: no se cambiaron las condiciones de rendering.

Por lo tanto, por un lado he reducido carga de trabajo (segundo monitor con Navigation corriendo simultáneamente, grabación de RPMs) i por otro la he subido, pidiendo un 50% más de cálculos de modelos por frame.

No sé si han sido estos los factores que hayan podido girar las tornas o no, pero el caso es que ahora tengo datos más que razonables habiendo incluso volado de forma salvaje.

Para los curiosos, ahí va una última gráfica; es el plot de la trayectoria en 3D. Así os hareis una idea de como transcurrieron las cosas y de las condiciones del vuelo. Las círculos más o menos concéntricos responden a los 10 minutos (más o menos) de ascensión, procurando mantener la vertical sobre LEBL. Después empieza la fiesta.

(http://s8.postimg.org/n48kd6jc5/aerobatics3.jpg)

No sé si este éxito es una falsa ilusión o no; no me atrevo a marcar el problema como solucionado hasta que haga más pruebas. En cualquier caso, seguiré la configuración que os he comentado, incrementando si es necesario el número de modelos por frame y manteniendo la eliminación de aplicaciones paralelas como el Navigation de foufou...

Ya os diré alguna cosa más en el futuro...

Gracias por todo.

Bleriot.

¿Y no has pensado en reducir el tiempo de registro de datos en 0.1s? Yo continúo viendo que es normal la primera gráfica que publicas.

Como dices que solo te pasa en el roll, quizá tengas transitorios es ese eje, por la conexión usb o por el propio joy. Una forma rápida de saberlo es ir al menú especial y luego a Show control deflections, dejas los mandos y tienes que ver tres líneas completamente horizontales y sin fluctuaciones, luego lo mueves poco a poco para hacer un alabeo y tienes que ver un flujo continuo.

Volviendo a la gráfica, en el eje Y tienes divisiones de 2º y en el eje X divisiones de 200s (10 veces mayor) la gráfica sale comprimida.
Si se toman muestras cada segundo en este transcurso de tiempo puede haber un alabeo pero este no se registra hasta que ha alcanzado su punto más alto, por eso esos saltos tan bruscos. Te lo muestro con una imagen del Data see de x-plane. Con turbulencia Moderada-Fuerte, en un momento dado está con un alabeo de -3º pero antes de un segundo se encuentra en un valor positivo de 6º, los puntos intermedios no se han volcado al data.txt ya que el tramo dura menos de un segundo.

(http://s9.postimg.org/3k1iuy5sr/Data_See_2.jpg) (http://postimg.org/image/3k1iuy5sr/)

Otra cosa que puedes hacer es interpolar con una spline los datos de la gráfica para que sea más suave, si no te interesa tomar datos entre décimas de segundo.

Ahora bien, si tú no desde el exterior no ves moverse el avión (2.5º pueden ser 15-20 cm. en el extremo del ala) en vuelo recto o nivelado, creo que el problema es de los mandos.

zxplane,

el próximo fin de semana pensaba hacer otro vuelo subiendo la frecuencia de captura a al menos 5 Hz, es decir, con una separación entre muestras de solamente 0.2 segundos. Tu me sugieres que incluso la suba a 10Hz. Probaré, a ver si el pobre Acer aguanta.

Lo que dices tiene mucho, mucho sentido, la verdad, ya que lo que estoy haciendo es discretizar una magnitud a intervalos concretos de tiempo y esa discretización puede ser más o menos apropiada en determinadas condiciones de vuelo. De hecho,  se ha puesto muy de manifiesto que la frecuencia de 1Hz no es en absoluto suficiente para virajes muy cerrados cuando hemos procesado el vuelo acrobático del que hablaba ayer y de ahí los planes de incrementar la frecuencia.

Solamente el hecho de que fuese el roll y nada más el que diese problemas es lo que me ha despistado. ¿Tal vez el pitch y el heading no varían tanto en condiciones de turbulencia y por eso no muestran ese comportamiento? Lo pregunto como ignorante que soy de las cuestiones de aerodinámica (y eso que delante de mi trabajo hay una escuela de aeronáutica!) El vuelo en cuestión lo realicé el 17 de marzo, con una tramontana (que avivó el incendio que se produjo en Vall-Llobrega ese mismo día) que me pilló cuando encaraba Perpìgnan y no me soltó hasta que pasé Begur. No es que fuese un tifón, ni mucho menos, pero algo me sacudió, todo hay que decirlo.

Respecto a la posible avería hardware, probaré lo que comentas de las deflecciones, puesto que es tan sencillo de hacer. No descarto que pase algo raro, ya que, en el control de gases / pitch / mezcla que tengo, una de las palancas está un poco tocada y genera datos un poco a saltos. No veo por qué no puede haber pasado algo así con los cuernos. Así pues, lo comprobaré.

Por cierto, ¿como funciona el Data see de X-plane? He visto alguna vez que estaba ahí, pero no le he prestado demasiada atención. Hay algún procedimiento a seguir para hacer el "setup"? ¿Cómo escojo lo que quiero ver?

EDITO: Ya he visto como enviar información al Data See, usando el panel de Data Input & Output. Lo que no sé es CUANDO puedo ver esta información. ¿Durante el vuelo? ¿Posteriormente, habiendo salvado esos datos de alguna manera? El manual de X-Plane no es nada explícito al respecto, la verdad. De hecho solamente hay una referencia a esta pestaña en todo el texto.

EDITO: Nuestro software de integración ya usa splines para interpolar entre dos puntos dados.

Gracias!!!!!

Bleriot.

Saludos a todos de nuevo.

Tal y como comentaba en posts anteriores, este fin de semana hice un vuelo nuevo para intentar comprobar si el problema con el roll volvía a manifestarse.

Sobre el tema de la NULL ZONE, confirmar que la tenía al 10%.

Sobre el tema de las deflecciones de los controles, no hay problema aparente. He procedido según comentaba zxplane para comprobarlo y todo tiene una pinta magnífica.

El vuelo lo he realizado a 10Hz, es decir, tomando 10 muestras de datos por cada segundo de vuelo. No hay plugins, no hay programas externos interaccionando con X-Plane (como el Navigator de Foufou, usado en las primeras pruebas). El vuelo es acrobático, para forzar una trayectoría con una gran dinámica.

El número de modelos por frame lo he puesto a 5, siguiendo otra sugerencia anterior (el penúltimo lo hice a 3 o 4, ahora no lo recuerdo).

Los resultados vuelven a ser impecables, sin ningún tipo de discontinuidad; X-Plane aguanta perfectamente esta tasa de captura / modelado sin despeinarse, ofreciendo una simulación (ahora, visualmente hablando) continua y sin saltos o paradas.

Entiendo, por tanto, que, esencialmente, el problema se soluciona debido a (1) la mayor tasa de captura de datos (muestras por segundo) que impiden que se pierda información importante y (2) la mayor precisión obtenida por la generación de más modelos por frame. No descarto otros factores, pero al menos, actuar e este sentido ha dado resultados positivos.

Por tanto, doy el problema por solucionado y AGRADEZCO A TODOS LOS QUE HAN COLABORADO su interés y ayuda.

Un saludo,

Bleriot.