[Flightgear-devel] Janes' helicopter data

2006-12-05 Thread wim van hoydonck

Hi all,


Attached is a file (OpenOffice spreadsheet) containing performance
data and geometrical parameters of most commercial helicopters, found
in Janes All the World Aircraft and Prouty's Helicopter Performance,
Stability and Control.


I collected these data for a literature survey on preliminary design
of helicopters. Maybe someone can use these figures to tune existing
helicopters in Flightgear or create new ones.


Greetings,

Wim


heli_params.ods
Description: application/vnd.oasis.opendocument.spreadsheet
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] Initial conditions at reset

2006-12-05 Thread Thomas Biwer


I just want to gently push this back to top, since I figured out more
strange behaviours which I really dont know the cause of...

First, as I didnt notice before, the plane is hovering a few feet above the
runway at start as soon as I specify an initial velocity. If I specify the
initial velocity as zero, it stands on the ground, just as normal. By using
the --notrim option in the command line, it shows up a few inches below the
runway (similar as it is when specifiying --fdm=NULL). Whats the reason for
this? Could it be somewhee in the trimming code?

Second, I m still not seeing clearly in the way the reset is processed...
Could anyone give me a hint as to where the FDM is initialized during the
reset process? Is the Initialize()-function in the FGState.cpp file still
involved at all? And if it is not, where does FG take its starting values
from and where could I tell it to load my initial conditions at reset, too?
(while running FG with --notrim option)

Any thoughts or help are much appreciated indeed.

Best,
Thomas




 Hello,

 I want to start FlightGear with a bunch of Initial Conditions Settings
and
 I noticed that they dont seem to be loaded when restarting the simulator
 with File-Reset.
 It rather looks like FG is taking the values for pitch, alpha, and so on
 off of the last session, i.e. if I crashed the plane almost in a 90 deg
 angle to the earth and then press reset, it starts with the plane heading
 towards ground in almost a 90deg angle. By pressing pause at startup
and
 comparing the values in the property tree I indeed figured out that the
 values are exactly the same.
 I am using FG 0.9.10 release version and noticed this behaviour with the
 c172 and f16. I am loading the IC in from an external input file. I
 therefore modified the code in FGState.cpp, in the Initialize() function
 with a rather simple routine to read in the values and used the
 FGIC-SetBlahBlah() method of the FGInitialConditions class in order to
 save them.

 All works fine as long as I am NOT specifying --notrim in the command
 line. As soon as I specify this option, the above described behaviour
 occurs.

 Anyone might be able to shed some light in this matter? Where can I find
 the functions that are responsible for the reset process in the code?
Could
 it be that FG restarts different than its actual starting process is?

 Thanks a lot for your help.

 Best,
 Thomas



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Initial conditions at reset

2006-12-05 Thread Jon S. Berndt
 First, as I didnt notice before, the plane is hovering a few feet
 above the
 runway at start as soon as I specify an initial velocity. If I specify the
 initial velocity as zero, it stands on the ground, just as
 normal. By using
 the --notrim option in the command line, it shows up a few inches
 below the
 runway (similar as it is when specifiying --fdm=NULL). Whats the
 reason for
 this? Could it be somewhee in the trimming code?

If you are not trimming, then the aircraft may be placed initially at an
inappropriate altitude, considering where it's CG is defined, and where the
landing gear are defined to be touching. I'm assuming this is for some
JSBSim aircraft. The altitude that the aircraft is initially placed at
should be the vertical distance from the CG to the landing gear location.

 Second, I m still not seeing clearly in the way the reset is processed...
 Could anyone give me a hint as to where the FDM is initialized during the
 reset process? Is the Initialize()-function in the FGState.cpp file still
 involved at all? And if it is not, where does FG take its starting values
 from and where could I tell it to load my initial conditions at
 reset, too?
 (while running FG with --notrim option)

Have you looked inside JSBSim.cxx? That's the interface between FlightGear
and JSBSim.

Jon


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Initial conditions at reset

2006-12-05 Thread Thomas Biwer
Thank you for your help Jon,

Is there a way to fix this problem with the altitude on the runway? And
yes, I am using JSBSim planes.

Yes I did take a look in JSBSim.cxx - but without success. I tried to set
the initial conditions within the FGJSBSim()-function as well as within the
init(9 function - none of it worked.
Where should I place it?

Best,
Thomas



[EMAIL PROTECTED] escribió: -


Para: FlightGear developers discussions
flightgear-devel@lists.sourceforge.net
De: Jon S. Berndt [EMAIL PROTECTED]
Enviado por: [EMAIL PROTECTED]
Fecha: 05/12/2006 13:49
Asunto: Re: [Flightgear-devel] Initial conditions at reset

 First, as I didnt notice before, the plane is hovering a few feet
 above the
 runway at start as soon as I specify an initial velocity. If I specify
the
 initial velocity as zero, it stands on the ground, just as
 normal. By using
 the --notrim option in the command line, it shows up a few inches
 below the
 runway (similar as it is when specifiying --fdm=NULL). Whats the
 reason for
 this? Could it be somewhee in the trimming code?

If you are not trimming, then the aircraft may be placed initially at an
inappropriate altitude, considering where it's CG is defined, and where the
landing gear are defined to be touching. I'm assuming this is for some
JSBSim aircraft. The altitude that the aircraft is initially placed at
should be the vertical distance from the CG to the landing gear location.

 Second, I m still not seeing clearly in the way the reset is processed...
 Could anyone give me a hint as to where the FDM is initialized during the
 reset process? Is the Initialize()-function in the FGState.cpp file still
 involved at all? And if it is not, where does FG take its starting values
 from and where could I tell it to load my initial conditions at
 reset, too?
 (while running FG with --notrim option)

Have you looked inside JSBSim.cxx? That's the interface between FlightGear
and JSBSim.

Jon


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] fgfs + gaia (google earch client) = moving map

2006-12-05 Thread Melchior FRANZ
* Melchior FRANZ -- Saturday 25 November 2006 12:41:
 * Melchior FRANZ -- Thursday 23 November 2006 15:47:
  Bright future ahead. (Until Google's attorney rings,
  that is. ;-)
 
 Which was yesterday:  http://gaia.serezhkin.com/   :-(

The good news: the author did the only reasonable thing: he removed
Google Earth support and added NASA World Wind support.  :-)

SF Project page:
  http://sourceforge.net/projects/gaia-clean/
ChangeLog:
  http://sourceforge.net/project/shownotes.php?group_id=183522release_id=468497
Homepage:
  http://gaia.serezhkin.com/

m.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] How to drive the Flight Gear airplanes by radar data

2006-12-05 Thread Curtis Olson

On 12/4/06, 唐勇 wrote:



 Hi,the Flight Gear can be drived by Keyboard,Mouse,Joystick etc.But my
question is that how can I drive the Flight Gear by my ATC radar data.Myradar 
data contains the flight position(lon,lat,alt) and
oritation(pitch,roll,heading).I want to know how to input these data to the
Flight Gear,and make  many airplanes fly automatically.
Thank u very much!!!



I have done some work capturing IMU/GPS data from a live UAV and playing it
live (or replaying it later) in FlightGear ... optionally with the
multiplayer features turned on so we can track the uav in google maps/earth.

There are a variety of ways you could pull this off, but here is one
suggestion.

I have written/adapted a couple utilities that can load a saved data file or
read the data in live from a serial port and then pass it along to
FlightGear.  This code lives in the FlightGear CVS repository under
.../source/utils/GPSsmooth/  (the naming of this directory doesn't exhibit a
lot of forethought, but that's what it is right now.)

If you wanted to use this option, you would mostly likely have to adapt the
MIDGsmooth or UGsmooth application to parse your own data format, but
everything else should pretty much be the same.

If nothing else you can explore this directory to get a few ideas.

You could probably reformat the data so it could be loaded and replayed by
flightgear directly, but I haven't fiddled with that end of flightgear in a
*long* time so someone else might be able to offer more current advice for
doing that.

Regards,

Curt.
--
Curtis Olson - University of Minnesota - FlightGear Project
http://baron.flightgear.org/~curt/  http://www.humanfirst.umn.edu/
http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear on Linux.com

2006-12-05 Thread Melchior FRANZ
* On 12/4/06, Joe Barr wrote: 
 http://www.linux.com/article.pl?sid=06/11/20/0533247

Now announced on linuxtoday.com. May provoke some comments there:

  http://www.linuxtoday.com/news_story.php3?ltsn=2006-12-05-025-26-RV-GM-SW

m.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] How to drive the Flight Gear airplanes by radar data

2006-12-05 Thread Robin van Steenbergen
Curtis Olson schreef:
 On 12/4/06, *唐勇* wrote:

 Hi,the Flight Gear can be drived by Keyboard,Mouse,Joystick
 etc.But my question is that how can I drive the Flight Gear by my
 ATC radar data.My radar data contains the flight
 position(lon,lat,alt) and oritation(pitch,roll,heading).I want to
 know how to input these data to the Flight Gear,and make many
 airplanes fly automatically.
 Thank u very much!!!


 I have done some work capturing IMU/GPS data from a live UAV and
 playing it live (or replaying it later) in FlightGear ... optionally
 with the multiplayer features turned on so we can track the uav in
 google maps/earth.

 There are a variety of ways you could pull this off, but here is one
 suggestion.

 I have written/adapted a couple utilities that can load a saved data
 file or read the data in live from a serial port and then pass it
 along to FlightGear. This code lives in the FlightGear CVS repository
 under .../source/utils/GPSsmooth/ (the naming of this directory
 doesn't exhibit a lot of forethought, but that's what it is right now.)

 If you wanted to use this option, you would mostly likely have to
 adapt the MIDGsmooth or UGsmooth application to parse your own data
 format, but everything else should pretty much be the same.

 If nothing else you can explore this directory to get a few ideas.

 You could probably reformat the data so it could be loaded and
 replayed by flightgear directly, but I haven't fiddled with that end
 of flightgear in a *long* time so someone else might be able to offer
 more current advice for doing that.

 Regards,

 Curt.
Wouldn't it be possible to use either the 'Generic' protocol over a
socket / serial link or convert the data coming from the ATC console
into NMEA format? That way FG can read it without any problems. (I have
yet to try my own GPS receiver with FG but I'm certain it will work)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] helplinefoo\nbar/line/help

2006-12-05 Thread Melchior FRANZ
line statements in a help block are now split at
new-lines. So it's no longer necessary to write every line
in extra line.../line tags. This should be enough
(full example):

  help
  titleThis is my little aircraft/title

  key
  namec/name
  desclet attendant make coffee/desc
  /key

  line!-- leading spaces aren't stripped yet :-/ --
some
meaningless
lines
  /line

  text
some
longer
text in a
scrollbox
  /text
  /help


Note the use of keyname/namedesc/desc/key for
key definitions. Those should *ALWAYS* use such a block,
and not informally be mixed into normal text.

m.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Linux - Solaris AMD64-SPARC64 interfacing

2006-12-05 Thread Martin Spott
Hi Vikas,

Vikas N Kumar wrote:

 I tried for a while to build OpenSceneGraph on Solaris 7 with my
 version of X11 and using GNU compilers but there was something wrong
 with X11 and using Sun's OpenGL. So I reinstalled Solaris 10 and have
 now installed the Sun Studio 11 Compilers as well.
 I will restart compiling everything again -- plib, OpenThreads,
 Producer and OpenSceneGraph, Simgear and finally FlightGear.

You might rest at least one day or so, I'm still waiting for Don Burns
to put yet another patch against his Producer 'makedefs' files into
CVS, that allows building on SunOS with SunStudio. He already added
several changes that I sent him so I think it'll be just a matter of
time,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] OSG point lights

2006-12-05 Thread Mathias Fröhlich

Hi Tim,

I did not find the time to look into that this weekend. These evenings are my 
friend.

On Thursday 30 November 2006 10:03, Tim Moore wrote:
 I'm not sure about faster but, as far as I can tell, equivalent. By
 the way, it would be very nice to have some more timing information
 available than just the frame rate. I don't know if the easiest way to
 get there is to move to Producer so we can get its nice rendering stage
 statistics, wait for Robert to duplicate that in his new osgViewer
 stuff, do it ourselves, or what.
Yep, that must happen at some time that we have that cull and draw times on 
the screen ...

  I do not want to remove the old implementation that was happening
  completely on the GPU in favour to an CPU based one if we end up slower.
 
  Anyway, can we keep the old implementation instead of just a plain OpenGL
  point based one. That means the old one that used triangles that are
  backface culled and draw points for the front side where two of them are
  transparent?

 I don't mind adding the old implementation back in as an option, except
 for the VASI lights, where it really would have no advantage over the
 OSG lights. One would lose some features, such as point size scaled by
 intensity, fading alpha with distance, and blink sequence animations for
 the approach lights.
No, I do not think that we loose such features completely, we just need to 
implement exactly what we need ourselves. The VASI in the osgSim 
implementation has some problems. The size of the lights are something that I 
do not comment on here. The just need to be adjusted somehow.
But I have objections in the basic way it is done.
We had a smooth transition phase where the lights went smooth from red to 
white. The osgSim one just switches hard. I do also not see how the osgSim 
api will allow to change the color of a point in a smooth way. We can just 
render both in a transition area and hope that blending does our trick - but 
that is a really bad idea IMO.
So especially for the vasi I do definitely want to use an own implementation 
that has nothing to do with osgSim.

Also the current osgSim implemntation does directional lights with a hard 
switch off when the eye point moves beyond 90 deg to the normal.
The previous implementation faded away nicely. That could be done with 
osgSim's sector but I still wonder if it is then slower...

The only place where I can see osgSim as a *real* benefit is for the rabbit 
time sequences.

Given that I would like to have a common appearance for all lights I would 
favor doing all of them ourselves.

  Like I stated before in some private mails I would like to have the osg
  version only as an alternative to the old implementation if it is faster
  than the GPU/triangle based one. May be not exactly the old
  implementation but an implementation that does nothing on the CPU but
  does all lightging decisions on the GPU.

 I would like to see some comparisons between the two approaches on a
 low-end machine. You may be overestimating the cost of the CPU based
 approach and underestimating the costs of triangle approach. As I said 
 in private email, the old approach uses a fairly exotic rendering path
 -- polygons rendered in point mode with a texture environment -- which
 very well may be done on the CPU on a low-end machine.
I don't think that I overestimate that - we just have plenty of those lights. 
What we definitely gain if we put such computations onto the GPU is 
additional CPU time where we can do something we cannot do on the GPU - not 
yet, but definitely then when we have cull and draw on an other cpu.

... hold on, I see, this also holds if the draw cpu will compute the light 
intensities instead of waiting for the gpu to do that.
In the single threaded case we gain nothing with this argument ...
Hmm ...

 Yes, I think that is a great project, but more work than I have time for
 right at the moment. It would be good for people to learn about OSG's
 support for shading programs *hint*hint* :)
I will send you my hackery on that today evening.

  For that we still need some factory methods that will provide now the old
  implementation or the osg::LightPoint based one and later when I have the
  time to merge my tests into simgear the shader based one.
 
  So we need to he able to decide between implementations based on
  capabilities of the GPU and settings from the user anyway. Can we set up
  together such an infrastructure and put the old triangle based approach
  as other alternative below?

 We? :) Seriously, I would be happy to look at getting the OpenGL
 extensions available from OSG and making that available to fg in an
 elegant way, but goes way beyond to scope of light points, so for now
 exposing the choice to the user is probably the best way. Automatically
 benchmarking the user's machine and putting it into slow /fast
 categories would be an interesting project too.
Hmm. I believe that what osg does for us in this area is silently switch of