Re: [Flightgear-devel] Autopilot and violent roll
On Sunday 11 Oct 2009 4:30:08 pm Curtis Olson wrote: I think that your premise that autopilots need to run at very high frame rates is not realistic. When I first got into autopilots and simulation, back in the 60´s, all of our models had as the final element a 0.1 second low pass filter which simulated the control surface actuator. This turns out to be a reasonable approximation for most actuators and is very simple to implement both in a analogue computer (which is all we had then) and in digital ones. As there is such a filter in the inner loop means that there is no need to simulate anything which has a faster response time than this. Therefore there is no need to run the autopilot at high frame rates. 10 or 20 per second is perfectly adequate. Many of the outer loops (e.g. the heading mode) of the autopilot can in practice be run at much slower frame rates as the response of the aircraft is quite slow. I think what Lee(e) may be observing is that when you tune an autopilot to behave well when the update rate is 60hz, and then fly into an area of complex scenery + effects the frame rate in FlightGear can drop substantially. In this situation, the autopilot (which is running at the same update rate as the graphics) can go unstable, leading to wild oscillations. Presumably this is an entirely different issue than what Pete is dealing with, and neither of these contradict anything you have said. Interesting. I would have imagined that the autopilot logic were synchronized with the FDM and hence slow downs should not cause an issue as they would both slow down together. But it seems that the autopilot logic is synchronized with GUI frame paining code. Is there any literature that lists out the sequence? I'm curious to know how the network IO is synchronized. Not having a common time base reference for the various subsystems can lead to varying performance based on the underlying hardware on which flightgear is run. The PID/Autopilot tuning for a given model should not vary based on the hardware on which flightgear is run. Should it? Or did I get this all wrong? -- Cheers! Kishore -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] gitorious repositories for FlightGear and SimGear
On Friday 18 Sep 2009 7:26:12 pm Curtis Olson wrote: Github wrote us back saying: Git doesn't work very well with large amounts of binary assets. They didn't offer further explanation to where the problems might be? Maybe they were just putting the brakes on and didn't want to offer to allocate us the large space that we needed? Are there any real potential issues with large repositories of binary assets with git? This is (was?) true for 'single' large binary files. I had trouble when trying to push/pull a video file that was about 2GB in size. I also had several videos under 1GB which worked just fine. This was over LAN. I am not sure about the bandwidth utilization. -- Cheers! Kishore -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug in jsclient
On Tuesday 10 Mar 2009 7:46:53 pm Kishore wrote: There appears to be a bug in jsclient code that causes it to fail on linux 64 bit since a long is 64 bit long. In any case i think it is safer to use fixed width typedefs when the code depends on the size of the datatype. Patch attached. Hi could someone comment on this? If the patch is correct can it be applied upstream? -- Cheers! Kishore -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bug in jsclient
There appears to be a bug in jsclient code that causes it to fail on linux 64
bit since a long is 64 bit long.
In any case i think it is safer to use fixed width typedefs when the code
depends on the size of the datatype. Patch attached.
--
Cheers!
Kishore
diff --git a/src/Network/jsclient.cxx b/src/Network/jsclient.cxx
index 1fff200..23ce067 100644
--- a/src/Network/jsclient.cxx
+++ b/src/Network/jsclient.cxx
@@ -91,11 +91,11 @@ bool FGJsClient::process() {
if ( io-get_type() == sgFileType ) {
if ( io-read( (char *)( buf), length ) == length ) {
SG_LOG( SG_IO, SG_DEBUG, Success reading data. );
- long int *msg;
- msg = (long int *)buf;
+ int32_t *msg;
+ msg = (int32_t *)buf;
for( int i = 0; i 4; ++i )
{
- axis[i] = ((double)msg[i] / 2147483647.0);
+ axis[i] = (msg[i] / 2147483647.0);
if ( fabs(axis[i]) 0.05 )
axis[i] = 0.0;
if( axisdefstr[i].length() != 0 )
@@ -105,13 +105,13 @@ bool FGJsClient::process() {
} else {
while ( io-read( (char *)( buf), length ) == length ) {
SG_LOG( SG_IO, SG_DEBUG, Success reading data. );
- long int *msg;
- msg = (long int *)buf;
+ int32_t *msg;
+ msg = (int32_t *)buf;
SG_LOG( SG_IO, SG_DEBUG, ax0 = msg[0] ax1 =
msg[1] ax2 = msg[2] ax3 = msg[3]);
for( int i = 0; i 4; ++i )
{
- axis[i] = ((double)msg[i] / 2147483647.0);
+ axis[i] = (msg[i] / 2147483647.0);
if ( fabs(axis[i]) 0.05 )
axis[i] = 0.0;
if( axisdefstr[i].length() != 0 )
diff --git a/src/Network/jsclient.hxx b/src/Network/jsclient.hxx
index a25c623..9c54a88 100644
--- a/src/Network/jsclient.hxx
+++ b/src/Network/jsclient.hxx
@@ -41,7 +41,7 @@ class FGJsClient : public FGProtocol {
char buf[256];
int length;
-double axis[4];
+float axis[4];
SGPropertyNode_ptr axisdef[4];
string axisdefstr[4];
bool active;
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
