RE: [Flightgear-devel] Propeller animation speed fix
Jon Berndt writes: I was remembering first how the F-16 sim at Link was run at 25 Hz, which is of course 0.04 seconds. Wait ... (thinking, this time). Yes, that's right ;-) Then, I went to the numpad on my keyboard and hit 0.01 as I was typing in the dt for 100 Hz. Only I missed. On purpose or accident I am not sure. Currently, we have FGSubsystem::update (int dt) where dt represents the elapsed time in ms since the last update. That puts a limit of 2^31 ms, or just under 600 hours, between updates. It has the advantage of keeping us in integer math, and the disadvantage of not being able to represent a granularity of under 1ms. That's OK for a simulator involving human interaction, since we cannot notice such a small difference, but it would obviously be a problem for other kinds of simulations such as rapid chemical reactions. So, what do we do? John mentioned that reporting in sec rather than ms is standard, so do we switch to FGSubsystem::update (double dt_sec) or do we simply rename dt to elapsed_ms FGSubsystem::update (int elapsed_ms) or do stick with ms but allow finer granularity FGSubsystem::update (double elapsed_ms) ? I don't see any harm in sticking with the integer value, but I agree that a better name, proper documentation, and some debugging is essential. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Propeller animation speed fix
? I don't see any harm in sticking with the integer value, but I agree that a better name, proper documentation, and some debugging is essential. This is true - particularly about documentation. Inline comments would help, too. I prefer (and we will continue to do this for JSBSim) that dt stands for delta T in seconds. It can be used directly that way, as it is in a prime unit. Jon smime.p7s Description: application/pkcs7-signature
RE: [Flightgear-devel] Propeller animation speed fix
On Fri, 2002-05-03 at 04:20, Jon Berndt wrote: ? I don't see any harm in sticking with the integer value, but I agree that a better name, proper documentation, and some debugging is essential. This is true - particularly about documentation. Inline comments would help, too. I prefer (and we will continue to do this for JSBSim) that dt stands for delta T in seconds. It can be used directly that way, as it is in a prime unit. That's delta seconds per frame, not total elapsed. Jon -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Propeller animation speed fix
David Megginson wrote: Jon Berndt writes: I was remembering first how the F-16 sim at Link was run at 25 Hz, which is of course 0.04 seconds. Wait ... (thinking, this time). Yes, that's right ;-) Then, I went to the numpad on my keyboard and hit 0.01 as I was typing in the dt for 100 Hz. Only I missed. On purpose or accident I am not sure. Currently, we have FGSubsystem::update (int dt) where dt represents the elapsed time in ms since the last update. That puts a limit of 2^31 ms, or just under 600 hours, between updates. It has the advantage of keeping us in integer math, and the disadvantage of not being able to represent a granularity of under 1ms. That's OK for a simulator involving human interaction, since we cannot notice such a small difference, but it would obviously be a problem for other kinds of simulations such as rapid chemical reactions. As soon as something depends on the dt it's quite likely that it involves floats. And one of the most common uses of dt is for integration. As integration summs the values up one wrong value is enough to make all following results wrong, too (*). So I want (as I wrote some time ago, too), that a float or double dt in the unit second gets passed to the update functions/methods. So, what do we do? John mentioned that reporting in sec rather than ms is standard, so do we switch to FGSubsystem::update (double dt_sec) Yes or do we simply rename dt to elapsed_ms FGSubsystem::update (int elapsed_ms) No, there we'll get problems when we need a accurate dt. And offering a int elapsed_ms as well as a double dt doesn't make much sense IMHO. or do stick with ms but allow finer granularity FGSubsystem::update (double elapsed_ms) No. Stick to the standard. And when I get ms I probably still want sec (or hour or µs or whatever). So let the modules do the work to get the correctly shaped value, we can only guess (and guess it wrong) ? I don't see any harm in sticking with the integer value, I do. but I agree that a better name, proper documentation, and some debugging is essential. That's definitely a requirement. 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] Propeller animation speed fix
I think I agree. When we go about fixing this up, I think we should pass a dt to the modules which would be in units = seconds and of type double. Regards, Curt. Christian Mayer writes: David Megginson wrote: Jon Berndt writes: I was remembering first how the F-16 sim at Link was run at 25 Hz, which is of course 0.04 seconds. Wait ... (thinking, this time). Yes, that's right ;-) Then, I went to the numpad on my keyboard and hit 0.01 as I was typing in the dt for 100 Hz. Only I missed. On purpose or accident I am not sure. Currently, we have FGSubsystem::update (int dt) where dt represents the elapsed time in ms since the last update. That puts a limit of 2^31 ms, or just under 600 hours, between updates. It has the advantage of keeping us in integer math, and the disadvantage of not being able to represent a granularity of under 1ms. That's OK for a simulator involving human interaction, since we cannot notice such a small difference, but it would obviously be a problem for other kinds of simulations such as rapid chemical reactions. As soon as something depends on the dt it's quite likely that it involves floats. And one of the most common uses of dt is for integration. As integration summs the values up one wrong value is enough to make all following results wrong, too (*). So I want (as I wrote some time ago, too), that a float or double dt in the unit second gets passed to the update functions/methods. So, what do we do? John mentioned that reporting in sec rather than ms is standard, so do we switch to FGSubsystem::update (double dt_sec) Yes or do we simply rename dt to elapsed_ms FGSubsystem::update (int elapsed_ms) No, there we'll get problems when we need a accurate dt. And offering a int elapsed_ms as well as a double dt doesn't make much sense IMHO. or do stick with ms but allow finer granularity FGSubsystem::update (double elapsed_ms) No. Stick to the standard. And when I get ms I probably still want sec (or hour or µs or whatever). So let the modules do the work to get the correctly shaped value, we can only guess (and guess it wrong) ? I don't see any harm in sticking with the integer value, I do. but I agree that a better name, proper documentation, and some debugging is essential. That's definitely a requirement. 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 -- Curtis Olson IVLab / HumanFIRST Program 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] Propeller animation speed fix
On Thu, 2 May 2002 23:23:53 -0500, Jon Berndt [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: This is ridiculous. dt is short for delta T. In a 100 Hz simulation, the corresponding dt is 0.04. For 120 Hz it's 0.00833. For people that do simulation for a living this is one of the *most* recognized parameters around. ..I the blacklisted aero engineer who turned gas guru... http://www.crest.org/discussion/gasification/199903/msg00055.html ...and newbie coder wanna-be, would have _guessed_ so. Or _assumed_ so. Etc. Which _is_ wrong. ..Andy, who coded Yasim here, figured something else he found (_too_) reasonable, so he used that. And yasim _works_. ..we come from _all_ walks of life. So we need to _know_. Not guess, believe, have faith in, assume etc. ..best way is to put it in the docs, along with all the other dumb questions. And ask everyone to read it, and holler if something is missing, or write then if we do know the missing answers. ;-) Jon almost assuredly meant dt = .01 for 100 Hz or dt = .04 for 25 Hz or he was testing us. :) I haven't been getting much sleep lately. ..famous last words. ;-) I was remembering first how the F-16 sim at Link was run at 25 Hz, which is of course 0.04 seconds. Wait ... (thinking, this time). Yes, that's right ;-) Then, I went to the numpad on my keyboard and hit 0.01 as I was typing in the dt for 100 Hz. Only I missed. On purpose or accident I am not sure. Thanks. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Propeller animation speed fix
Andy,
The original code assumed that dt was in milliseconds. The variable name
velocity_rpms presumably stood for revs per millisecond.
Your patch assumes that dt is in 1/120ths of a second. Is this linked to your frame
rate?
The meaning of dt needs to be consistent across the various instances of
FGSubsystem, and I don't think it is: see my post Propellor speed error due to
FGSubsystem::update(multi_loop), reproduced below.
- Julian
Andy Ross wrote:
Here's a patch to model.cxx that restores the proper rotation speed of
the propeller spin.
It just replaces the single 1/6 constant with one that is
(hopefully) more clearly derivable from basic principles. The
original number was off by a factor of 3/25; maybe something got
double-factored? One thing I didn't do is grab the 120 Hz update rate
from a real source; it's hardcoded instead. I forget where it comes
from.
Andy
diff -u -r1.10 model.cxx
--- model.cxx 20 Apr 2002 15:07:47 - 1.10
+++ model.cxx 30 Apr 2002 23:17:55 -
@@ -527,8 +527,9 @@
void
FG3DModel::SpinAnimation::update (int dt)
{
- float velocity_rpms = (_prop-getDoubleValue() * _factor / 6.0);
- _position_deg += (dt * velocity_rpms * 360);
+ float velocity_rpms = _prop-getDoubleValue() * _factor;
+ // 120Hz update, 60 sec/min, 360 degrees/revolution
+ _position_deg += (dt * (1/120.0) * (1/60.0) * velocity_rpms * 360);
while (_position_deg 0)
_position_deg += 360.0;
while (_position_deg = 360.0)
--
On 21 April Julian Foad wrote:
The error in the speed of the propellor, and other things that we might not have
noticed yet, is caused by the handling of the variable multi_loop in
main.cxx:fgUpdateTimeDepCalcs(). After being used to update the FDM, this
multi_loop value (or the value 1 in freeze mode) is passed to the various subsystem
update methods:
globals-get_model_mgr()-update(multi_loop);
globals-get_aircraft_model()-update(multi_loop);
globals-get_viewmgr()-update(multi_loop);
current_radiostack-update(multi_loop);
The model manager, at least, is expecting to receive the number of milliseconds that
have elapsed since the last call. The multi_loop number does not seem to be that.
Nor does the definition of FGSubsystem::update help:
/**
* Update the subsystem.
*
* pFlightGear invokes this method every time the subsystem should
* update its state. If the subsystem requires delta time information,
* it should track it itself./p
*/
virtual void update (int dt) = 0;
That looks wrong to me. Surely it should track it itself applied before the dt
parameter existed, and now the dt parameter is intended to provide the time
difference and should be defined here.
Anyone prepared to sort this out? If dt is to represent milliseconds, it would be
a good idea to rename it dt_ms (in the derived classes too). I haven't checked how
other classes interpret it.
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Propeller animation speed fix
Julian Foad wrote: The original code assumed that dt was in milliseconds. The variable name velocity_rpms presumably stood for revs per millisecond. Your patch assumes that dt is in 1/120ths of a second. I believe, although I am not authortative on this, that the dt parameter specifies an integer number of iterations to perform, and not a time value per se. Under normal usage, dt will equal one. This is consistent with the multi_loop name it sometimes goes by. The 120 Hz update frequency (which is not frame rate dependant) is specified in the /sim/hz property I believe. I hard-coded it here out of laziness. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Propeller animation speed fix
Andy Ross writes: I believe, although I am not authortative on this, that the dt parameter specifies an integer number of iterations to perform, and not a time value per se. Under normal usage, dt will equal one. This is consistent with the multi_loop name it sometimes goes by. That confusion is my fault. For the FDMs use a multiloop with the number of iterations to run; the general subsystems use a dt for elapsed time in milliseconds. This needs some architectural repair and documentation. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Propeller animation speed fix
So, is dt recording elapse time or set to the current step time? If a sharp programmer like Andy is getting confused about what dt really is, then perhaps the variable should be called ms_elapsed or t_stepsize, etc.? This is ridiculous. dt is short for delta T. In a 100 Hz simulation, the corresponding dt is 0.04. For 120 Hz it's 0.00833. For people that do simulation for a living this is one of the *most* recognized parameters around. Jon smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] Propeller animation speed fix
On Thu, May 02, 2002 at 10:22:22PM -0500, Jon Berndt wrote: So, is dt recording elapse time or set to the current step time? If a sharp programmer like Andy is getting confused about what dt really is, then perhaps the variable should be called ms_elapsed or t_stepsize, etc.? This is ridiculous. dt is short for delta T. In a 100 Hz simulation, the corresponding dt is 0.04. For 120 Hz it's 0.00833. For people that do simulation for a living this is one of the *most* recognized parameters around. Jon almost assuredly meant dt = .01 for 100 Hz or dt = .04 for 25 Hz or he was testing us. :) -- James (Jay) Treacy [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Propeller animation speed fix
This is ridiculous. dt is short for delta T. In a 100 Hz simulation, the corresponding dt is 0.04. For 120 Hz it's 0.00833. For people that do simulation for a living this is one of the *most* recognized parameters around. Jon almost assuredly meant dt = .01 for 100 Hz or dt = .04 for 25 Hz or he was testing us. :) I haven't been getting much sleep lately. I was remembering first how the F-16 sim at Link was run at 25 Hz, which is of course 0.04 seconds. Wait ... (thinking, this time). Yes, that's right ;-) Then, I went to the numpad on my keyboard and hit 0.01 as I was typing in the dt for 100 Hz. Only I missed. On purpose or accident I am not sure. Thanks. smime.p7s Description: application/pkcs7-signature
[Flightgear-devel] Propeller animation speed fix
Here's a patch to model.cxx that restores the proper rotation speed of
the propeller spin.
It just replaces the single 1/6 constant with one that is
(hopefully) more clearly derivable from basic principles. The
original number was off by a factor of 3/25; maybe something got
double-factored? One thing I didn't do is grab the 120 Hz update rate
from a real source; it's hardcoded instead. I forget where it comes
from.
For those wondering why I bothered working on this instead of the more
important stuff I'm supposed to be doing (flap drag bug in YASim
clickable virtual panel), I offer no excuse. It was low-hanging
fruit, and my other stuff is hard.
Andy
diff -u -r1.10 model.cxx
--- model.cxx 20 Apr 2002 15:07:47 - 1.10
+++ model.cxx 30 Apr 2002 23:17:55 -
@@ -527,8 +527,9 @@
void
FG3DModel::SpinAnimation::update (int dt)
{
- float velocity_rpms = (_prop-getDoubleValue() * _factor / 6.0);
- _position_deg += (dt * velocity_rpms * 360);
+ float velocity_rpms = _prop-getDoubleValue() * _factor;
+ // 120Hz update, 60 sec/min, 360 degrees/revolution
+ _position_deg += (dt * (1/120.0) * (1/60.0) * velocity_rpms * 360);
while (_position_deg 0)
_position_deg += 360.0;
while (_position_deg = 360.0)
--
Andrew J. RossNextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
Men go crazy in conflagrations. They only get better one by one.
- Sting (misquoted)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
