Es/FlightGear Newsletter December 2013

From FlightGear wiki
Revision as of 19:33, 5 January 2014 by Wallkon (talk | contribs) (Alternative camera control: traducido)
Jump to navigation Jump to search
Magagazine.png
Welcome to the FlightGear Newsletter!
Please help us write the next edition!
Enjoy reading the latest edition!


Nos gustaría enfatizar que el boletín de noticias mensual no podría ser posible sin los aportes de los usuarios de FlightGear y los desarrolladores. Cualquiera con una cuenta wiki (con libertad para registrarse) puede editar el boletín y toda contribución es bienvenida. Si conoces acerca de alguna noticia o proyecto relacionado a FlightGear tales como por ejemplo una actualización del escenario o alguna aeronave, porfavor siéntete invitado a añadir esas noticias al boletín.

Noticias del proyecto

Integración con osgEarth

Este video muestra un vuelo corto desde Raron (LSTA) hasta Sion (LSGS) en Suiza, en un Robin DR400 mediante FlightGear. La escena del terreno es generada desde la librería de C++ osgEarth, que genera en tiempo real toda la Tierra. El terreno generado por osgEarth puede ser activado o desactivado mientras se vuela.

En este ejemplo, las imágenes del terreno son enviadas desde ArcGis WMS (Web Mapping Service, o Servicio Web de Mapas). osgEarth soporta una amplia variedad de fuentes desde donde obtener las imágenes del terreno.

Actualmente, osgEarth está integrado en una rama de desarrollo para la versión 2.99 de FlightGear. Los cambios de integración, actualmente están siendo enviados para aprobación para la próxima mayor versión de FlightGear.

Mejoras a NavDisplay

Gijs, ha comenzado a extender el framework NavDisplay para soportar modos de pantalla adicionales, que comúnmente se pueden encontrar en aeronaves modernas de Boeing:

Creación de Aeronaves Basado en Asistentes

Aircraft-template-wizard-intro.png

Cuando se llega al desarrollo de una aeronave, una de las áreas que la gente considera frustrante es que las características usadas por los desarrolladores de aeronaves serán documentadas en la Wiki, pero los detalles son tan mínimos que puede ser difícil o casi imposible conseguir que algo funcione porque a los ejemplos publicados les faltan detalles o no muestran importantes variaciones sobre cómo programar cierta característica.

Hemos llegado a la conclusión de que, el mejor paso hacia la solución de estos problemas, es tener un conjunto de plantillas para configuraciones comunes de aeronaves (mono propulsor, multi propursor, mono reactor, multi reactor con copiloto, etc). Estas plantillas tendrían todos los componentes mínimos para armar una aeronave para "producción" (de acuerdo a la guía de calificación).

Hemos estado considerando esa idea por un tiempo, por ejemplo, mantener un proyecto de "plantillas" para cosas como aeronaves, para así asegurar que la gente tenga alguna forma de guiarse sin apoyarse excesivamente en el copiar/pegar - en realidad sólo necesitamos alguien que comience con una aeronave "de prueba", con muchos comentarios y opciones (Nasal, sonidos, canvas, ayudas, checklists, tutoriales). De hecho, sería incluso posible proporcionar asistentes (wizards) para ayudar a personalizar esas plantillas, por ejemplo, para cambiar nombre/autor/status, modelos 3D, nombres de archivo (sonidos, texturas).

La idea es que podríamos tener un conjunto de plantillas estándar para aeronaves, o algún medio más sofisticado para generar skeletons de aeronaves basadas en datos ingresados por el usuario. Estas plantillas tendrían todos los archivos necesarios y el código para implementar una simple pero completa aeronave de una configuración determinada (mono motor, multi reactor, etc), y posiblemente los stubs para mejoras comunes. Mejoras estándar (checklists, pilotos automáticos, etc) podrían ser incluidas como comentarios, indicando dónde el código necesita ser añadido. Esto haría que las aeronaves de FG fueran más consistentes, pero también ayuda a los desarrolladores de aeronaves primerizos a superar el obstáculo inicial de entender cómo unir todo. Pienso que esto nos ayudaría a salvar el problema de tener tantos aviones en varios estados de pre-producción.

Durante la discusión en el foro, llegamos a la idea de poder tener una plantilla de aeronave y parametrizarla dinámicamente al interior de FlightGear - después de todo, el 95% está programado como un XML PropertyList, por ejemplo, puede ser leído/manipulado y escrito por medios estándar de FlightGear/Nasal - en otras palabras, podrías tomar una ventana PUI existente y convertirla en un "asistente para aeronaves", donde el usuario podría especificar cosas como 1) nombre del archivo, 2) descripción, 3) tipo de FDM, 4) status, 5) miniatura (thumbnail) y así sucesivamente - todo esto es sencillo de hacer, simplemente implica usar setprop() después de haber volcado el template en el property tree mediante io.read_properties(), en cuyo punto podría mostrarse una simple interfaz de usuario para agilizar el proceso de desarrollo de aeronaves en un estilo "paso a paso" (como un wizard). La mayoría del código ya existe, incluyendo una ventana para seleccionar el archivo - lo que falte puede ser implementado mediante extensiones de Canvas.

Idealmente, este asistente no debería ser implementado como un diálogo XML "hardcodeado", sino más bien como un sub módulo de Nasal que dinámicamente crea "páginas" para cada paso en el asistente. Nada de esto es difícil, en realidad sólo involucra 1) el árbol de propiedades, 2) leer/escribir las propiedades mediante io.nas y 3) Nasal básico (setprop/props.nas) para modificar el template de la aeronave. Además, el asistente podría fácilmente programarse para reconocer las versiones de FG, y los usuarios ingresarían este dato en el asistente para, por ejemplo, omitir ciertas características como soporte para Canvas, o efectos, etc.

Un primer prototipo, muy básico, está disponible y esperando a ser adoptado por algún colaborador de la comunidad para ayudar a hacer crecer este "asistente", por ejemplo, añadiendo funciones, pero también agregando nuevos templates, para diferentes características de las aeronaves, tales como checklists, tutoriales, vistas, etc.

Dado que la mayoría de nosotros ya parecemos malabaristas con tantos proyectos, estamos buscando gente a los que les gustaría unirse a este de alguna forma.

Referente al código, actualmente son sólo cerca de 150 líneas de código Nasal muy simple, copiado de varios otros diálogos y tutoriales de la wiki. Por lo tanto, saber Nasal sería un plus, pero si tienes cualquier otra experiencia en programación/scripting, eso también servirá. Entonces, si estás interesado en programar para Flightgear y simplificar el desarrollo de aeronaves para los principiantes, por favor contáctanos mediante el foro o la wiki.

Continúa leyendo en Aircraft Generation Wizard...

Implementando VNAV - Una lluvia de ideas

Ventana de administración de ruta con nuevo soporte para exportar a JSBSim o hacia archivos XML FGScript

Recientemente, hemos tenido otra discusión en el foro acerca de implementar VNAV (Vertical Navigation) en FlightGear. En comparación con otros simuladores de vuelo, desde el primer día a FlightGear le ha faltado soporte para simular funciones VNAV comunes en muchos aviones modernos.

Hasta ahora, el consenso general ha sido que simplemente no es posible implementar adecuadamente VNAV en FlightGear porque VNAV depende de datos de rendimiento específicos de la aeronave para proporcionar los cambios de cabeceo/empuje adecuados para cumplir los límites de altitud/velocidad/tiempo calculados por VNAV, lo que en realidad se reduce a una falta de apoyo de los FDMs (JSBsim/YaSim).

Como proyecto abierto, no tenemos acceso a los correspondientes datos de vuelo o tales datos de performance, e incluso si los tuvieramos, probablemente no podríamos hacer uso fácil de tales datos debido a su naturaleza propietaria.

Además, una base de datos de performance real probablemente no nos serviría de mucho, porque nuestras configuraciones de FDM también son a la medida - por ejemplo, los datos de rendimiento necesitarían coincidir con los de la aeronave simulada.

Así, una base de datos de performance idealmente sería proporcionada por el propio FDM. Ya sea en una forma pre-creada, por ejemplo compilada durante una "prueba de vuelo" offline, o de preferencia durante la ejecución corriendo una simulación del FDM al interior del FDM real.

Hemos comenzado a recopilar toda la información de discusiones anteriores acerca de VNAV para llegar a una tormenta de ideas y determinar cómo implementar los componentes que se requieren para soportar VNAV en FlightGear (YaSim/JSBSim). Cualquier aporte será muy agradecido.

Continúa leyendo en Implementing VNAV support in FlightGear...

Alternativa para el control de la cámara

Marius_A, usuario de la comunidad de FlightGear, ha creado una cámara virtual para FlightGear que está escrita en Nasal, la cual añade funciones similares al addon para FSX: la cámara EZdok.

Continúa leyendo en el foro...

Unirse como programador

Desafortunadamente, la mayoría de los desarrolladores activos de FG actualmente están muy agobiados con sus otras responsabilidades, lo cual afecta a cuanto realmente podemos hacer. Fundamentalmente, necesitamos más desarrolladores del núcleo.

Si estás interesado en aportar como un desarrollador del núcleo, por favor lee Comenzar como desarrollador del núcleo.

Building from Source

Thanks to work done by Seatbutler, the Howto:Build FlightGear with NetBeans using CMake article has recently been updated and verified to still work.

Hardware development

Project computer2cockpit

Following design changes suggested by FlightGear users, the computer2cockpit's flight yoke design has been extended with:

  • Map holder
  • Additional rocker switch and push button switches on right side of the yoke
  • Additional push to talk switch

Curent activities:

  • Prototype manufacturing preparation - setting up the CNC router
  • Talking with suppliers to lower the initial costs and production price

DIY hardware panel for FlightGear

At least five projects exist where FlightGear users build their own hardware panels with real switches and knobs to interface with the FlightGear software to improve the flying experience. Follow the build progress of ludomotico's and pommesschranke's panels on this forum thread.

In the hangar

New Aircraft

Junkers JU-288, and Caudron Type 'C' biplane, from Lester Boffo

Two new aircraft from my 'Hangar', such as it is. The first one is a Junkers JU-288 Bomber-Interceptor/Bomber presented to the Luftwaffe in 1942 as a hedge against the expected US Bombing campaign and the new Boeing B29. Being as it is with all things bomber-ish in the WWII German air war, the politics of who's company got the funding, and go ahead with production, also doomed this aircraft to only a few prototypes and variants. That it relied upon the then promising Jumo 222 water-cooled inline/radial, only hastened it's demise, as the Jumo's development was rushed, and then the Jumo engine factory was destroyed by Allied bombing in 1944. Finding literature covering this aircraft was a bit hard to find, but with some help from FMG, I was able to source some drawings and spec's. I'm not sure when this plane will be finished, but the basic 3D is done and a rudimentary cockpit is in place.

Secondly is a small, pre WWI early aircraft from Rene Caudron and sibling, his Type 'C' biplane. The first of his 'Public Domain' designs that he released to the early aviation community. This aircraft was to go on to more development as the G series of trainers and observation/bombers during WWI. This particular aircraft was also known as the '10 meter Caudron', it was interesting to note that it employed along with it's wing warping roll control, an enhanced roll control from the divided stab/elevator, which could be flexed with up and down, twisting deflections in addition to it's normal pitch control. It was praised for it's high rate of climb, lightness, and manoeuvrability, on a modest 45 h.p. Anzani 6 cylinder radial. The aircraft is releasable and is under a GPL license. Images of these two aircraft.

Updated aircraft

North American P-51D Mustang

The JSBSim P-51D is undergoing some significant improvements. The most interesting of these is the fully functional K-14A lead computing gun sight. The screen shot below shows the gun sight in action with the aircraft rolled over and pulling about 5G. You can see that there are two reticles. The small cross in the upper center of the reflector glass is the center cross of the fixed reticle and it's sight line corresponds with where the guns would shoot in straight and level flight (IE. slightly below the bore line of the guns). The fixed reticle has been masked so that only the center cross is visible. The reticle consisting of a center dot and six surrounding diamonds is the reticle that is controlled by the gyroscope which is what gives this sight it's lead computing functionality. In the screen shot on the left, the gyro reticle is displaced a significant distance from the fixed reticle and this distance is known as the deflection. Note also that the tracers from the guns are converging near the center of the gyro reticle giving an indication of how effective the new gun sight is when doing deflection shots.

The screen shot on the right is of a ground attack mission using HVAR rockets. In this case the gyro reticle is turned off and the fixed reticle is unmasked. You can see the center cross along with the 70 mil outer circle and the so called rocket ladder in the lower center of the outer circle. This attack missed the target high and to the right mostly because I was distracted by taking the screen shot. But you can see that the flight path traced out by the rockets smoke is right where they should have been relative to the rocket ladder.

The following screen shot on the left is a ground view of the aircraft with the new drop tanks, bomb racks and propeller. In addition you can see the back of the gun sight in the cockpit. The pink area on the back of the gun sight is the silica gel pack that keeps the internals of the gun sight dry.

The bomb ranks and rocket wing mounts were modeled using the factory blue prints and are accurate to within perhaps 0.1mm. The propeller and drop tanks were modeled based on published measurements and have similar levels of accuracy. The gun sight 3D models are based on drawings and dimensions from the USAAF K-14A maintenance manual.

There are other improvements to the FDM and other areas that have been pushed to fgdata. To try out the new features you will need the Aircraft/p51d and Aircraft/Instruments-3d/computing-gun-sights directories. I tested these updates with FG 2.12.1 but it should be OK with any version from 2.4 on.

fgdata also has the new check list functionality that was setup by Stuart Buchanan. I made some additions to the check lists to reflect changes in the FDM that affected the start up procedure. From that experience I know that Stuart spent a significant amount of time getting this in place. Thank you Stuart.

The plan going forward is to continue to improve the external 3D model based on the factory blue prints. So over the next few months you can expect to see things get even better.

Please feel free to give this a try and provide constructive feedback on the FlightGear forum.

Wiki updates

Major changes in the wiki help pages

During November and December many of the help pages have been moved around and extended, and a few new help pages have been created, Help:Tables and Help:Glossary.

These changes were made to improve the help mostly for entirely new users, but will probably also be helpful some of the regular editors as well. The rewritten pages now also have links to more advanced help primarily at the MediaWiki Wiki, the wiki of the developers of the the wiki software used by the FlightGear Wiki.

In summary, the following changes have been made:

Help:Templates – Rewritten and extended
Help:Formatting – Rewritten and extended
Help:Tutorial
– Rewritten and extended

The work is not complete yet though. Most of all the translations of these pages needs to be moved and/or translated, and a couple of pages, Help:Categories and Help:Tutorial, could still need a rewrite (though on a much smaller scale).

And finally, a style guide (as in a guide, not a manual) is something there is a growing need for. Any suggestions and opinions are welcome at Help talk:Style guide, as well as additions to Help:Style guide, which is currently (very) incomplete.

Translators required

En.gif The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multi-language then start at Help:Translate.
De.gif Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki Mehrsprachig zu machen, dann fang doch mit Help:Übersetzen an.
Nl.gif De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij Help:Vertalen.
Es.gif La FlightGear wiki todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en Help:Traducir.

And finally ...

Contributing

One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.

For ideas on starting to contribute to FlightGear, you may want to check out: Volunteer.

To learn more about how the project works, please see this short essay written by Thorsten, for a more detailed article see How the FlightGear project works.

YASim looking for a new maintainer

Cquote1.png There are some pending merge requests to add some Yasim features, but we have an issue that since none of the current C++ developers own, or are experts in Yasim, we're reluctant to be the person who merges such changes, and potentially introduces subtle regressions.

Obviously this is chicken-and-egg, since no one can become expert enough in the code to become a maintainer :)

So, I'm more than happy to apply patches *providing* I can be convinced they are sane+reasonable from a pure code perspective (happy to help with that, too, if people are new to C++), and providing we have some assurance that a representative sample of yasim aircraft are unchanged or improved by the patch. Suggestions for that means in practice, are most welcome!

Otherwise I worry, given the nature of the solver, we'll keep optimising the solver for some aircraft, and making other existing aircraft worse - until someone tests them, and announced that they're no longer working.[1]
— James Turner
Cquote2.png
Cquote1.png I am still broadly happy to answer questions if posed (as long as I remember enough to come up with a meaningful answer). Just cc: me if you do, because my

latencies here are measured in weeks.

Bugs can always be fixed. What YASim needs is a maintainer, not really expertise per se. The latter comes from the former.[2]
— Andy Ross
Cquote2.png
  1. James Turner (Fri, 05 Oct 2012 03:54:43 -0700). YASim and documentation.
  2. Andy Ross (Fri, 05 Oct 2012 03:54:43 -0700). YASim and documentation.