RE: [Flightgear-devel] msvc6 - 0.7.9 release
Christian Mayer writes: Norman Vine wrote: Christian Mayer writes: Norman Vine wrote: Well if you just wanted to drift with the wind and be 'cheesy' you could use the simgear direct geodetic solver to get a new lat lon based on current position speed and course int geo_direct_wgs_84 ( double alt, double lat1, double Need anything else ?? Thnks, that should do the job. The 'Brakes' could work as a simulated 'tethering device' anchor while on the ground :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] msvc6 - 0.7.9 release
Norman Vine writes: Christian Mayer writes: Norman Vine wrote: Christian Mayer writes: Norman Vine wrote: Well if you just wanted to drift with the wind and be 'cheesy' you could use the simgear direct geodetic solver to get a new lat lon based on current position speed and course int geo_direct_wgs_84 ( double alt, double lat1, double Need anything else ?? Thnks, that should do the job. The 'Brakes' could work as a simulated 'tethering device' anchor while on the ground :-) One thing I've noticed (from the magic carpet mode) is that if you call geo_direct_wgs_84() with zero distance and zero direction (i.e. zero velocity) you don't get *exactly* the starting lat/lon back because of numerical precision issues. This is not a big deal at higher velocities, but is a problem at very slow velocities. Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6 - 0.7.9 release
Curtis L. Olson wrote: Norman Vine writes: Christian Mayer writes: Norman Vine wrote: Christian Mayer writes: Norman Vine wrote: Well if you just wanted to drift with the wind and be 'cheesy' you could use the simgear direct geodetic solver to get a new lat lon based on current position speed and course int geo_direct_wgs_84 ( double alt, double lat1, double Need anything else ?? Thnks, that should do the job. The 'Brakes' could work as a simulated 'tethering device' anchor while on the ground :-) One thing I've noticed (from the magic carpet mode) is that if you call geo_direct_wgs_84() with zero distance and zero direction (i.e. zero velocity) you don't get *exactly* the starting lat/lon back because of numerical precision issues. This is not a big deal at higher velocities, but is a problem at very slow velocities. Thanks, I'll take care of that (although they are used to race balloons aren't that fast...) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] msvc6 - 0.7.9 release
Curtis L. Olson writes:
One thing I've noticed (from the magic carpet mode) is that if you
call geo_direct_wgs_84() with zero distance and zero direction
(i.e. zero velocity) you don't get *exactly* the starting lat/lon back
because of numerical precision issues. This is not a big deal at
higher velocities, but is a problem at very slow velocities.
Good Point
lets see 1.0e-6 degrees should be close enough for 'government work'
a minute is 2000 meters and there are 60 minutes in a degree so
1.0*e-6 degrees is around 10 cm
so I guess one could always check
somthing like
my_geo_direct( new_lat, new_lon, lat, lon. dir, dist )
static double old_lat = 1000;
static double old_lon = 1000;
#define CLOSE_ENOUGH 1.0e-6
if( fabs(old_lat-lat) CLOSE_ENOUGH
fabs(old_lon-lon) CLOSE_ENOUGH ) {
geo_direct_wgs_84(new_lat, new_lon lat, lon)
} else {
new_lat = lat;
new_lon = lon;
}
old_lat = new_lat;
old_lon = new_lon;
}
FWIW for those who want REAL ACCURATE placement at small
scale I ALWAYS reccommend doing everything in XYZ on a local
plane then converting your positions into 'spherical space'.
This will work for distances of up to 'several' miles with no noticeable
loss in accuracy due to differences between chord and arc distance
Now how small is epsilon ?
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6 - 0.7.9 release
Norman Vine wrote: Christian Mayer writes: Geoff McLane wrote: My exe crashed on ada and just 'sat' on the runway in 'balloon'. But with magic the system soared. Well, the balloon lacks one significant thing for an FDM: enable the plane to move around. The balloon model works nicely for raising and sinking (just give full throttle...), but as I wrote it I didn't have a clue how to change my horizontal position (and still haven't got one). Well if you just wanted to drift with the wind and be 'cheesy' you could use the simgear direct geodetic solver to get a new lat lon based on current position speed and course The drifting is moddeled correctly and returnes me a displacement in meters in the north-south and east-west axis (so it'S easy to convert that to a direction and a distance). So all I need is a function that takes the current position in WGS84 and my displacement and returns me a new WGS84 position. I'm sorry, but I don't understand the input parameters of the geo_direct_wgs_84 function, so it might be that that's the right one - I just don't know. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] msvc6 - 0.7.9 release
Christian Mayer writes: Norman Vine wrote: Well if you just wanted to drift with the wind and be 'cheesy' you could use the simgear direct geodetic solver to get a new lat lon based on current position speed and course The drifting is moddeled correctly and returnes me a displacement in meters in the north-south and east-west axis (so it'S easy to convert that to a direction and a distance). So all I need is a function that takes the current position in WGS84 and my displacement and returns me a new WGS84 position. Exactly * @param alt (in) meters -- current altitude above sea-level * @param lat1 (in) degrees - current latitude * @param lon1 (in) degrees - current longitude * @param az1 (in) degrees - course in degrees * @param s (in) distance in meters - distance in degrees * @param lat2 (out) degrees - new latitude * @param lon2 (out) degrees - new longitude * @param az2 (out) return course in degrees - course back to starting location */ int geo_direct_wgs_84 ( double alt, double lat1, double lon1, double az1, double s, double *lat2, double *lon2, double *az2 ); Need anything else ?? Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6 - 0.7.9 release
Geoff McLane wrote: YASim, and it all went well ... I had a 'reasonable' flight, 'stuttering' along, but some moments when it came together ... Andy asked: YASim shouldn't be stuttering, certainly. Which aircraft were you using? What were the symptoms? I was using the c172-yasim, and more recently c310-yasim ... but 'stuttering' here means that the exe (flightgear) here in my pc system has more disk io work to do than there is real time ... So while 'real' time marches forward, my next visual update might show me ten's of metres down the runway, and the speed past v1. Unfortunatel my js input is not read for several more seconds, after more disk io, and just one video io, then I am in the air with a left roll, but more disk io prevents the right js input to be read until ... Sometimes, after accidently establishing a relatively smooth climb, and outside is mostly sky, while there is still continuous disk io the video update re-acts gentle and immediately to a small js l input ... the model is humming ... i mean flying ... :- bliss ... This begins at a modest fps of abt 5 and can be sustained, sometimes for many real time seconds, until perhaps we have climbed or moved such that another pieces of scenery must be located and loaded ... into the big-io-chache already kept ... An idea I have is for the model to have a mode to not to calculate the next 'position', 'height', lat, lon, etc in relation to system clock time, but from time kept only by cycles through fgMainLoop, thus includes sound and video updates (// redraw display = fgRenderFrame(); ). I will call this m_time. So if fgMainLoop fps is greater than say 5, then model time (m_time) would march forward exactly per system clock time (+warp). But when the fps falls below this then model time (m_time) slows up ... m_time could be kept in say 100 ns units, or usecs, or ... The current speed and heading times m_time would be less than real. That means engine thrust times m_time would be less, thus accellerating the aircraft less ... The left roll vector I mentioned above is only applied for this smaller amount of m_time so the model will have a chance to 'see' my small js correction ... Of course this should be an on/off switch. Such 'slowing' of real time is like have a less than 1 rate in MSFS, and is only used to show how software can co-operate with the pc system around it and produce smooth model animation, albiet at the cost of running 'slow' ... I originally thought porting threads to WIN32 might help, but I now think 'not really'. I have tried say running the 'sound'.update() on a separate thread, but unless I elevate its priority it will simply not receive enough cpu cycles to run at some minimum chosen hz. Anyway, at this point still mainly try to reach a stable msvc6 0.7.9 exe with available fdm's and aircraft ... Rgds, Geoff. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6 - 0.7.9 release
Geoff McLane wrote: When running your fgfs.exe the log ends abruptly with * Before globals-saveInitialState() ... first thing ... is delete initial_state; but initial_state ... 0 Q Can you delete a NULL pointer? A ... deleting a pointer with a value of zero... is guaranteed to be harmless. (ibid., Page 499) Wow? What is programming about? It should not be a question as to whether it is ok to delete a null! Any allocator/deallocator of memory can or may not have such 'testing' before commitment ... entirely implementation dependant. You programmed the machine - you 'know' if it is the 1st time thru, or an iteration - clean up your own mess. Do not trust the 'compiler' to do what you want!!! Write what you want in code ... A function should not conceptually begin with, well I better try to clean up what I didn't clean up before, before I start ... Even if(p) delete p; is horrific if you do not know what is in p! As mentioned msvc debug will fill an unitialised class ptr p with a value cdcdcdcdcd! Like the man who took his dog for a walk, only to find out he did not have a dog :-)) Its ok, I'll just delete him that does not exist! I really look forward to an exe update I can try. I have now had a chance to try a few other FDM's, and am now totally sold on 'magic'. This is 'flying'. --fdm=magic My exe crashed on ada and just 'sat' on the runway in 'balloon'. But with magic the system soared. For the very first time I saw sustained fps rates in excess of - dare I say it - 20s+. Fluid js actions ... the works. Those of you who have machines that do this all the time must be bored with my whining about 'stuttering' ... sorry. There is a GREAT flight simulator here, but how to make it 'co-operatively' work on the current pc system it is running in? A step closer we hope ... rgds, Geoff. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] msvc6 - 0.7.9 release
Christian Mayer writes: Geoff McLane wrote: My exe crashed on ada and just 'sat' on the runway in 'balloon'. But with magic the system soared. Well, the balloon lacks one significant thing for an FDM: enable the plane to move around. The balloon model works nicely for raising and sinking (just give full throttle...), but as I wrote it I didn't have a clue how to change my horizontal position (and still haven't got one). Well if you just wanted to drift with the wind and be 'cheesy' you could use the simgear direct geodetic solver to get a new lat lon based on current position speed and course distance below = windspeed * time /** * Given a starting position and an offset radial and distance, * calculate an ending positon on a wgs84 ellipsoid. * @param alt (in) meters * @param lat1 (in) degrees * @param lon1 (in) degrees * @param az1 (in) degrees * @param s (in) distance in meters * @param lat2 (out) degrees * @param lon2 (out) degrees * @param az2 (out) return course in degrees */ int geo_direct_wgs_84 ( double alt, double lat1, double lon1, double az1, double s, double *lat2, double *lon2, double *az2 ); Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6 - 0.7.9 release
Geoff McLane writes: A ... deleting a pointer with a value of zero... is guaranteed to be harmless. (ibid., Page 499) Wow? What is programming about? It should not be a question as to whether it is ok to delete a null! Any allocator/deallocator of memory can or may not have such 'testing' before commitment ... entirely implementation dependant. No it's not -- I think you might be confusing it with C/Posix free. In C++, delete is an operator specified to be a no-op with a 0 argument. On every platform. Period. We use this standard C++ idiom a lot in SimGear and FlightGear, and I haven't heard of any problems to date. In classes with lazy implementations (i.e. the pointer may or may not be zero), it might make me more of a man to write if (foo != 0) delete foo; if (bar != 0) delete bar; and so on, but it doesn't accomplish anything; I might as well type if (foo 3 foo 5) do_something(); Both are redundant. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] msvc6 - 0.7.9 release
Norman Vine wrote:
Geoff McLane writes:
When running your fgfs.exe the log ends abruptly with
...
/autopilot
/PropertyList
* After fgSaveFlight()
* Before globals-saveInitialState()
Aha this is my xtra instrumentation in fg_init()
bool fgInitSubsystems( void ) {
...
#define TEST_SAVE_INITIAL_STATE 1
#ifdef TEST_SAVE_INITIAL_STATE
// ADDED NHV
SG_LOG( SG_GENERAL, SG_INFO, * Before fgSaveFlight() );
fgSaveFlight(cout);
SG_LOG( SG_GENERAL, SG_INFO, * After fgSaveFlight() );
#endif
SG_LOG( SG_GENERAL, SG_INFO, * Before
globals-saveInitialState() );
globals-saveInitialState();
SG_LOG( SG_GENERAL, SG_INFO, * After
globals-saveInitialState() );
return true;
}
DaveM
Have you any idea why whe fgSaveFlight() succeeds saveInitialState() won't
or perhaps some insight as to how Goeff can best debug this as to what is
bogus
in the properties
Goeff
Can you put a breakpoint at the globals-saveInitialState(); call
and then inspect the properties tree for a BOUGUS value ??
Cheers
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6 - 0.7.9 release
Have you tried my Windows binary http://www.vso.cape.com/~nhv/files/fgfs/fgfs.exe.gz Initially JSBSim went crazy during the cfg xml read ( JSBSim Flight Dynamics Model v0.9.1 [cfg v1.57]) but this is caused by the cvs update adding things like the following to %FG_ROOT%\Aircraft\c172\c172.xml - About line 73 - c172.xml AC_GEAR NOSE-6.8 0.0 -20.0 1800 600 0.5 0.8 0.02 STEERABLE NONE 20 ... c172.xml AC_GEAR NOSE-6.8 0.0 -20.0 1800 600 0.5 0.8 0.02 STEERABLE NONE 20 ... === AC_GEAR NOSE-6.8 0.0 -20.0 1800 600 0.5 0.8 0.02 STEERABLE NONE 20 FIXED ... AC_GEAR RIGHT_TIP 43.2 214.8 59.4 1 2000 0.2 0.2 0.2 FIXED NONE 0 FIXED 1.36 === 1.31 I have read others mentioning this cvs 'feature', but do not seem to remember seeing how to 'avoid' it - or indeed what to do when it does happen = detection! But after I 'fixed' the above c172.xml I got a page fault. The 'ugly' thing about this is the stack dump shows - 30303030 30303030 30303030 30303030 30303030 onwards ... I always have to laugh :-) at the little MS message - If the problem persists, contact the program vendor. hahaha But just before it 'crashed' the out log showed - ... Initializing joystick bindings Joystick 0 not found No bindings for joystick 1 ... which reminded me I must now get back my joysticks.xml which has mappings for the 2nd js js n=1 ... Then the log shows - * After current_input.init() * Before fgSaveFlight() ?xml version=1.0? PropertyList ... etc - big dump of properties. The last 5 lines of the log is - /control-overrides /autopilot /PropertyList * After fgSaveFlight() * Before globals-saveInitialState() then POOF! Running my own compiled debug\flightgear.exe works fine - with JSBSim and YASim at least - on exactly the same base ??? (D:\FG78\fgfsbase) Stuttering in WIN32 notwithstanding, sometimes I can see the 'outside' view sway gently to the l/r touch of the js - very smooth and great - but then disk io gets heavy, and it can sometimes be parts of a minute before 'stabalising' ... then I will get another few seconds of 'smooth' flying ... Can I send you my exe to try? It zips to abt 2 MB, and expands to a 6.5 exe ... I note your exe is dated 5th January, 2002 - I have seen quite a number of maybe important code updates since then but then again the src of my exe is also 2-3 days back - say 11-12th Jan. I have 'looked' into the small diff between my updated CVS (today), and the src (11-12) of my exe, and am now exactly per cvs except for FlightGear.dsp. And thanks Jon for the FGMatrix.cpp info, which I have now seen in the maekfile.am thus will be in our dsp ... As mentioned previously I have 'switched' all libraries - the plib set, simgear - and thus Simgear.dsp to Debug Mutithreaded DLL, per the default of metakit ... thus my DSP must say /MdD on the ADD CPP line. Hope this helps ... Rgds, Geoff. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] msvc6 - 0.7.9 release
Geoff McLane writes: Have you tried my Windows binary http://www.vso.cape.com/~nhv/files/fgfs/fgfs.exe.gz Initially JSBSim went crazy during the cfg xml read ( JSBSim Flight Dynamics Model v0.9.1 [cfg v1.57]) but this is caused by the cvs update adding things like the following to %FG_ROOT%\Aircraft\c172\c172.xml - About line 73 - c172.xml AC_GEAR NOSE-6.8 0.0 -20.0 1800 600 0.5 0.8 0.02 STEERABLE NONE 20 ... c172.xml AC_GEAR NOSE-6.8 0.0 -20.0 1800 600 0.5 0.8 0.02 STEERABLE NONE 20 ... === AC_GEAR NOSE-6.8 0.0 -20.0 1800 600 0.5 0.8 0.02 STEERABLE NONE 20 FIXED ... AC_GEAR RIGHT_TIP 43.2 214.8 59.4 1 2000 0.2 0.2 0.2 FIXED NONE 0 FIXED 1.36 === 1.31 I have read others mentioning this cvs 'feature', but do not seem to remember seeing how to 'avoid' it - or indeed what to do when it does happen = detection! My binaries are made against the 'then current' fgfsbase CVS files Trying to run them against older base files is disaster If you are trying to use the CVS sources against the 0.78 fgfsbase files you are bound to have problems too !! YOU MUST USE THE CURRENT BASE FILES IN CVS inorder to run the CURRENT CVS SOURCE !! FWIW there is a newer executable at the web address above THIS NEEDS the CURRENT FGFS BASE package http://rockfish.net/fg Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
