Re: [Flightgear-devel] Direct Draw Surface Scenery Textures
Hi Thorsten, Hmm, but this actually means you have a brake problem after all. Only the brake temperature is simulated - smoke is triggered for overheated disc brakes. It's almost impossible that the parking brake is set (unless your both, deaf and blind...) but it seems like your brakes are slightly tightened after all. That's a safety critical issue - better tell maintenance personnel to check your flight gear - maybe the pedals are stuck... ;) Yeah, I'm afraid it is a problem like that. It were indeed the pedals I needed to recalibrate, but I originally discarded that as a problem. js_demo gave zero readings when they were completely untouched. I will have a closer look tnoight thought. In any case sorry for the noise and thanks for the help. Cheers, Durk -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Any alpha testers with a bit of extra time on their hands?
Not convenient we chose Vinson because the deck is indeed identical to Nimitz. Vivian -Original Message- From: Curtis Olson [mailto:curtol...@gmail.com] Sent: 22 September 2011 23:21 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Any alpha testers with a bit of extra time on their hands? I went with the Vinson because it is spiffier. Everything should (theoretically) work the same and just as well from the Nimitz. I believe the deck geometries are identical in FlightGear (conveniently.) ;-) Curt. On Thu, Sep 22, 2011 at 5:02 PM, Arnt Karlsen a...@c2i.net wrote: On Thu, 22 Sep 2011 22:36:45 +0200, Citronnier wrote in message 4e7b9c5d.6080...@gmail.com: Le 22/09/2011 22:04, Arnt Karlsen a écrit : On Thu, 22 Sep 2011 14:00:49 -0500, Curtis wrote in message CAHtsj_crOGWDX43J5oKw7F6g12AWsRePoceNGW=a1b0txod...@mail.gmail.com: On Thu, Sep 22, 2011 at 1:25 PM, Geoff McLane wrote: You seem to be deliberately holding its speed down around 150 - I see air-brakes come up when greater than this, and throttle back - and although flaps (I think full flap?) are still applied, 150 must be quite 'low' for this sleek bird... Normal landing approach in the real aircraft I believe is about 120 kts? I fly 135 kt approaches in the simulator. It should be able to hold 150 kts with the flaps down pretty easily. ..the Navy guys fly approaches using AOA, not speeds, AFAIK. And a max 6000 lbs fuel in the tanks. FG's f-14b is quite tricky to fly with what is *supposed* to be the right AoA for approach. Side departure happen easily if your aren't smooth enough in your final turn. ..and it does not like to T/O and climb on idle power, all Launch!!! button action I see is wild pre-crash oscillations, the Reset button tosses me into the cockpit rather than in the camera. ..Curtis, any reason your demo needs the USS Vinson, rather than a renamed USS Nimitz copy? ..Alexis, any changes to the f-14b since FG-1.9.1? Curt, I didn't test yet, sorry, lake of time, but the last mods on properties in engines.nas and instrument.nas should be comited soon. Happy to see you all playing with the beast :-) Alexis -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Any alpha testers with a bit of extra time on their hands?
Hi Curt, Ok, removed my joystick, and entered a '5', but still crashed while just in 'circle' mode - no route entered ;=(( As usual Atlas provides a good 'view' as to what happened - added - ATLAS=--atlas=socket,out,IP,5500,udp to output to Atlas running in a 2nd machine... See - http://geoffair.org/tmp/uas-01.jpg for a graph of the flight... The two blips in the graphs show the first stall, but it recovers and begins to climb back, and the 2nd the second stall, this time too low to recover, so into the drink ;=(( CRASH! This is a view of the 'crazy' flight track http://geoffair.org/tmp/uas-02.jpg Obviously the pig-tail loops are the 'stalls'... remember with NO joystick attached and starting with centered controls (NumPad 5)... And if you want to load this track into Atlas, or further study speeds, etc, then this is the Atlas track data :- http://geoffair.org/tmp/uas-01.txt Then on the NEXT flight I tried :- IO=--generic=file,out,10,uas-02.csv,playback Then I added a header line, to help analyze it in say an OpenOffice spreadsheet import - see - http://geoffair.org/tmp/uas-02.csv On this 2nd flight, this crash took longer, since it (randomly) turned left first, where as mentioned it holds more stable, but then eventually went into a right turn, stalled, recovered, stalled again, and CRASHED... And as you know well, downloading this file, and using say - $ ./fgfs --fg-root=/point/to/fgfs/data --timeofday=noon \ --aircraft=f-14b-uas --carrier=Vinson \ --generic=file,in,10,uas-02.csv,playback --fdm=external you too can enjoy this fateful flight ;=)) In 'chase' view, you can clearly see the right roll increase, the nose coming up, and the stall, recovery, then repeated, and BANG, into the water... I know it is difficult to work on, debug, fix something that obviously does not happen in your case... Maybe if you do not enter any route, or something... And this is all with SG/FG git of 2011-09-14... Any other ideas? Regards, Geoff. On Thu, 2011-09-22 at 14:00 -0500, Curtis Olson wrote: On Thu, Sep 22, 2011 at 1:25 PM, Geoff McLane wrote: Hi Curt, A pleasure, and FUN ;=)) Yes, I know a low frame rate can play havoc when you are trying to fine control an aircraft from its attitude feedback, and I should have mentioned my rate, but is always in the high 50-70 fps range in this Ubuntu machine... so should NOT be a factor... Ok, 50-70 should be perfect. I just did another few runs, and this time it crashed just while circling... it was in a right bank, which got too much and the nose came up, and it stalled... I am mostly in the 'chase' view... This is really strange. I have seen nothing like this except when I inadvertantly applied external control inputs through a strange combination of linux virtual desktops and flightgear capturing the hotkey to come back to the FlightGear virtual desktop. So two thoughts here. If you have a joystick connected, could you try unplugging it to see if that helps? Could you also press 5 on the numeric keypad to make sure all the flight control inputs are centered. Because of the way the F-14b FCS is wired together in combination with the yasim flight surfaces, you can still input elevator and aileron and trim and cause conflicts that you might not see in other simpler aircraft that use aileron and elevator directly. The first time this happened at 2000 feet, it caught itself - leveled a bit and bumped the throttles, and began climbing back... But a little later, 20-30 secs, it happened again, and this time was still too low to recover, and SPLASH... I had not previously let it fly in the 'circle' mode for too long, but now note if I leave it in circling mode, it will eventually end up in the water... seldom lasts more than 5 or 10 minutes... You seem to be deliberately holding its speed down around 150 - I see air-brakes come up when greater than this, and throttle back - and although flaps (I think full flap?) are still applied, 150 must be quite 'low' for this sleek bird... Normal landing approach in the real aircraft I believe is about 120 kts? I fly 135 kt approaches in the simulator. It should be able to hold 150 kts with the flaps down pretty easily. The point of slowing way down when circling is to keep the circle radius small enough so you can see what you are looking at. If you fly the circle at 600 kts, your radius will be 20 miles (just guessing) :-) and you won't be able to see anything. And I am not sure how many degrees each marking on the hud bottom bank indicator represents, and while it starts the banking in between the 1 and 2 of the 'big' marks, at the
Re: [Flightgear-devel] Any alpha testers with a bit of extra time on their hands?
Hi Geoff, I'm starting to run low on ideas here. I assume you don't have any crazy/severe turbulence turned on or your plots would be all over the place. Are you running out of fuel and your engines dying? If you open the autopilot dialog (F11) you can see the target speed and if you have the hud turned on you can see the actual speed in any view. If you are circling with a target speed of 150 and your airspeed is less than than and you are decending, then definitely check your engine output. There is a fuel dialog box under the f-14b menu and you might double check that to see if you have any fuel in your tanks. For what it's worth, I'm rock solid in circling and the only time I have ever stalled out of the sky or really got out of kilter is when I've had severe turbulence turned on. Moderate turbulence at all levels is actually pretty interesting because despite getting thrown all over the sky, I still hit the carrier deck pretty spot on every time. Curt. On Fri, Sep 23, 2011 at 9:35 AM, Geoff McLane wrote: Hi Curt, Ok, removed my joystick, and entered a '5', but still crashed while just in 'circle' mode - no route entered ;=(( As usual Atlas provides a good 'view' as to what happened - added - ATLAS=--atlas=socket,out,IP,5500,udp to output to Atlas running in a 2nd machine... See - http://geoffair.org/tmp/uas-01.jpg for a graph of the flight... The two blips in the graphs show the first stall, but it recovers and begins to climb back, and the 2nd the second stall, this time too low to recover, so into the drink ;=(( CRASH! This is a view of the 'crazy' flight track http://geoffair.org/tmp/uas-02.jpg Obviously the pig-tail loops are the 'stalls'... remember with NO joystick attached and starting with centered controls (NumPad 5)... And if you want to load this track into Atlas, or further study speeds, etc, then this is the Atlas track data :- http://geoffair.org/tmp/uas-01.txt Then on the NEXT flight I tried :- IO=--generic=file,out,10,uas-02.csv,playback Then I added a header line, to help analyze it in say an OpenOffice spreadsheet import - see - http://geoffair.org/tmp/uas-02.csv On this 2nd flight, this crash took longer, since it (randomly) turned left first, where as mentioned it holds more stable, but then eventually went into a right turn, stalled, recovered, stalled again, and CRASHED... And as you know well, downloading this file, and using say - $ ./fgfs --fg-root=/point/to/fgfs/data --timeofday=noon \ --aircraft=f-14b-uas --carrier=Vinson \ --generic=file,in,10,uas-02.csv,playback --fdm=external you too can enjoy this fateful flight ;=)) In 'chase' view, you can clearly see the right roll increase, the nose coming up, and the stall, recovery, then repeated, and BANG, into the water... I know it is difficult to work on, debug, fix something that obviously does not happen in your case... Maybe if you do not enter any route, or something... And this is all with SG/FG git of 2011-09-14... Any other ideas? Regards, Geoff. On Thu, 2011-09-22 at 14:00 -0500, Curtis Olson wrote: On Thu, Sep 22, 2011 at 1:25 PM, Geoff McLane wrote: Hi Curt, A pleasure, and FUN ;=)) Yes, I know a low frame rate can play havoc when you are trying to fine control an aircraft from its attitude feedback, and I should have mentioned my rate, but is always in the high 50-70 fps range in this Ubuntu machine... so should NOT be a factor... Ok, 50-70 should be perfect. I just did another few runs, and this time it crashed just while circling... it was in a right bank, which got too much and the nose came up, and it stalled... I am mostly in the 'chase' view... This is really strange. I have seen nothing like this except when I inadvertantly applied external control inputs through a strange combination of linux virtual desktops and flightgear capturing the hotkey to come back to the FlightGear virtual desktop. So two thoughts here. If you have a joystick connected, could you try unplugging it to see if that helps? Could you also press 5 on the numeric keypad to make sure all the flight control inputs are centered. Because of the way the F-14b FCS is wired together in combination with the yasim flight surfaces, you can still input elevator and aileron and trim and cause conflicts that you might not see in other simpler aircraft that use aileron and elevator directly. The first time this happened at 2000 feet, it caught itself - leveled a bit and bumped the throttles, and began climbing back... But a little later, 20-30 secs, it happened again, and this time was still too low to recover, and SPLASH... I had not previously let it fly in the 'circle' mode for too long, but now note if I leave it in circling
Re: [Flightgear-devel] FG hangs on loading scenery when using many objects
Hi cannot find it. grep -r nor Qtcreator find it, which files are those or how
should i search?
I gets worse on my PC. I've several sceneries that hang so I need to
investigate.Thanks
--- On Thu, 9/22/11, Csaba Halász csaba.hal...@gmail.com wrote:
From: Csaba Halász csaba.hal...@gmail.com
Subject: Re: [Flightgear-devel] FG hangs on loading scenery when using many
objects
To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net
Date: Thursday, September 22, 2011, 3:13 AM
On Wed, Sep 21, 2011 at 11:07 PM, Thomas Albrecht ra...@web.de wrote:
On machine (much slower than yours: Pentium 4 2.4 GHz, 1.5GB DDR), FG hangs
when using ~2300 objects.
Here, with AMD 605e 2.3GHz, it hangs at around 5800 objects, with the
CPU behaviour you described. Going slightly higher, from around 6000,
FG starts to burn CPU again, but nevertheless won't get any result.
Looking into the problem, seems the scenery is loaded eventually, but
the fdm is not initialized so this check never passes:
if (globals-get_tile_mgr()-isSceneryLoaded()
fgGetBool(sim/fdm-initialized)) {
Now, the FDM init code has this:
if (globals-get_scenery()-scenery_available(geod, range)) {
SG_LOG(SG_FLIGHT, SG_INFO, Scenery loaded, will init FDM);
That in turn ends up at:
simgear::CheckSceneryVisitor csnv(getPagerSingleton(), toOsg(p),
range_m, framestamp);
// currently the PagedLODs will not be loaded by the DatabasePager
// while the splashscreen is there, so CheckSceneryVisitor force-loads
// missing objects in the main thread
get_scene_graph()-accept(csnv);
if(!csnv.isLoaded())
Finally we arrive at:
void SGPagedLOD::forceLoad(osgDB::DatabasePager *dbp, FrameStamp* framestamp,
NodePath path)
{
//SG_LOG(SG_GENERAL, SG_ALERT, SGPagedLOD::forceLoad(
//getFileName(getNumChildren()) ));
And now the crazy part! If I uncomment this logging, everything
suddenly works, even with 20k objects:
http://i53.tinypic.com/wwn12f.png
Sounds like some timing/threading issue to me.
--
Csaba/Jester
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Any alpha testers with a bit of extra time on their hands?
On Fri, 23 Sep 2011 09:47:35 -0500, Curtis wrote in message cahtsj_edpuscxjf3m8_fbzzx4+-m8ugdahhcx9nfk+43zwd...@mail.gmail.com: Hi Geoff, I'm starting to run low on ideas here. I assume you don't have any crazy/severe turbulence turned on or your plots would be all over the place. Are you running out of fuel and your engines dying? If you open the autopilot dialog (F11) you can see the target speed and if you have the hud turned on you can see the actual speed in any view. ..what's your autopilot, fuel load etc settings? The works, please, I suspect you have something set that we guinea pigs are missing. Is e.g. your script actually controlling both jet engines? If you are circling with a target speed of 150 and your airspeed is less than than and you are decending, then definitely check your engine output. There is a fuel dialog box under the f-14b menu and you might double check that to see if you have any fuel in your tanks. For what it's worth, I'm rock solid in circling and the only time I have ever stalled out of the sky or really got out of kilter is when I've had severe turbulence turned on. Moderate turbulence at all levels is actually pretty interesting because despite getting thrown all over the sky, I still hit the carrier deck pretty spot on every time. Curt. On Fri, Sep 23, 2011 at 9:35 AM, Geoff McLane wrote: Hi Curt, Ok, removed my joystick, and entered a '5', but still crashed while just in 'circle' mode - no route entered ;=(( As usual Atlas provides a good 'view' as to what happened - added - ATLAS=--atlas=socket,out,IP,5500,udp to output to Atlas running in a 2nd machine... See - http://geoffair.org/tmp/uas-01.jpg for a graph of the flight... The two blips in the graphs show the first stall, but it recovers and begins to climb back, and the 2nd the second stall, this time too low to recover, so into the drink ;=(( CRASH! This is a view of the 'crazy' flight track http://geoffair.org/tmp/uas-02.jpg Obviously the pig-tail loops are the 'stalls'... remember with NO joystick attached and starting with centered controls (NumPad 5)... And if you want to load this track into Atlas, or further study speeds, etc, then this is the Atlas track data :- http://geoffair.org/tmp/uas-01.txt Then on the NEXT flight I tried :- IO=--generic=file,out,10,uas-02.csv,playback Then I added a header line, to help analyze it in say an OpenOffice spreadsheet import - see - http://geoffair.org/tmp/uas-02.csv On this 2nd flight, this crash took longer, since it (randomly) turned left first, where as mentioned it holds more stable, but then eventually went into a right turn, stalled, recovered, stalled again, and CRASHED... And as you know well, downloading this file, and using say - $ ./fgfs --fg-root=/point/to/fgfs/data --timeofday=noon \ --aircraft=f-14b-uas --carrier=Vinson \ --generic=file,in,10,uas-02.csv,playback --fdm=external you too can enjoy this fateful flight ;=)) In 'chase' view, you can clearly see the right roll increase, the nose coming up, and the stall, recovery, then repeated, and BANG, into the water... I know it is difficult to work on, debug, fix something that obviously does not happen in your case... Maybe if you do not enter any route, or something... And this is all with SG/FG git of 2011-09-14... Any other ideas? Regards, Geoff. On Thu, 2011-09-22 at 14:00 -0500, Curtis Olson wrote: On Thu, Sep 22, 2011 at 1:25 PM, Geoff McLane wrote: Hi Curt, A pleasure, and FUN ;=)) Yes, I know a low frame rate can play havoc when you are trying to fine control an aircraft from its attitude feedback, and I should have mentioned my rate, but is always in the high 50-70 fps range in this Ubuntu machine... so should NOT be a factor... Ok, 50-70 should be perfect. I just did another few runs, and this time it crashed just while circling... it was in a right bank, which got too much and the nose came up, and it stalled... I am mostly in the 'chase' view... This is really strange. I have seen nothing like this except when I inadvertantly applied external control inputs through a strange combination of linux virtual desktops and flightgear capturing the hotkey to come back to the FlightGear virtual desktop. So two thoughts here. If you have a joystick connected, could you try unplugging it to see if that helps? Could you also press 5 on the numeric keypad to make sure all the flight control inputs are centered. Because of the way the F-14b FCS is wired together in combination with the yasim flight surfaces, you can still input elevator and aileron and trim and cause conflicts that you might not see in other simpler aircraft that
Re: [Flightgear-devel] Any alpha testers with a bit of extra time on their hands?
Hi Curt, Using real weather fetch... no particular turbulence... Have HUD on, and holding 150, steady... as indicated in auto-target (F11), and as shown by the speed (kts) graph... Not descending, in fact usually still climbing to target 2000, or holding steady at 2000... as the Altitude and Climb Rate graphs show... Got more than 1100 lbs of fuel... from f-14b menu item... in the stall see and hear the engines come up due to the rapid speed drop from too steep of AOA... As the playback shows, in a right bank, quite quickly the nose pitches up, putting it in a stall... If in the cockpit at the time, you hear what I think is a stall warning... Takes about 1200-1400 feet to recover... if it has that altitude at the time... and will have more than 170+ at recovery, due to engine increase... lots of fuel... And in more tries, using the 'gohome' before this stall problem happens, get a smooth landing only about 1 out of 5 or 10 ;=(( Into the back (little too low), into the superstructure (little too high), into the water after touching the deck at a 30-40 degree off runway line diagonal ;=(( Ok, I too am out of ideas... I guess the scenario only works for some ;=)) will leave it for now... this 'bunny' is dying... Maybe others will have better luck... and FUN... Regards, Geoff. On Fri, 2011-09-23 at 09:47 -0500, Curtis Olson wrote: Hi Geoff, I'm starting to run low on ideas here. I assume you don't have any crazy/severe turbulence turned on or your plots would be all over the place. Are you running out of fuel and your engines dying? If you open the autopilot dialog (F11) you can see the target speed and if you have the hud turned on you can see the actual speed in any view. If you are circling with a target speed of 150 and your airspeed is less than than and you are decending, then definitely check your engine output. There is a fuel dialog box under the f-14b menu and you might double check that to see if you have any fuel in your tanks. For what it's worth, I'm rock solid in circling and the only time I have ever stalled out of the sky or really got out of kilter is when I've had severe turbulence turned on. Moderate turbulence at all levels is actually pretty interesting because despite getting thrown all over the sky, I still hit the carrier deck pretty spot on every time. Curt. On Fri, Sep 23, 2011 at 9:35 AM, Geoff McLane wrote: Hi Curt, Ok, removed my joystick, and entered a '5', but still crashed while just in 'circle' mode - no route entered ;=(( As usual Atlas provides a good 'view' as to what happened - added - ATLAS=--atlas=socket,out,IP,5500,udp to output to Atlas running in a 2nd machine... See - http://geoffair.org/tmp/uas-01.jpg for a graph of the flight... The two blips in the graphs show the first stall, but it recovers and begins to climb back, and the 2nd the second stall, this time too low to recover, so into the drink ;=(( CRASH! This is a view of the 'crazy' flight track http://geoffair.org/tmp/uas-02.jpg Obviously the pig-tail loops are the 'stalls'... remember with NO joystick attached and starting with centered controls (NumPad 5)... And if you want to load this track into Atlas, or further study speeds, etc, then this is the Atlas track data :- http://geoffair.org/tmp/uas-01.txt Then on the NEXT flight I tried :- IO=--generic=file,out,10,uas-02.csv,playback Then I added a header line, to help analyze it in say an OpenOffice spreadsheet import - see - http://geoffair.org/tmp/uas-02.csv On this 2nd flight, this crash took longer, since it (randomly) turned left first, where as mentioned it holds more stable, but then eventually went into a right turn, stalled, recovered, stalled again, and CRASHED... And as you know well, downloading this file, and using say - $ ./fgfs --fg-root=/point/to/fgfs/data --timeofday=noon \ --aircraft=f-14b-uas --carrier=Vinson \ --generic=file,in,10,uas-02.csv,playback --fdm=external you too can enjoy this fateful flight ;=)) In 'chase' view, you can clearly see the right roll increase, the nose coming up, and the stall, recovery, then repeated, and BANG, into the water... I know it is difficult to work on, debug, fix something that obviously does not happen in your case... Maybe if you do not enter any route, or something... And this is all with SG/FG git of
Re: [Flightgear-devel] anyone compiled vasFMC for fgfs?
I've heard someone did that for an older vasfmc version? Do they support FlightGear ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Any alpha testers with a bit of extra time on their hands?
Le 23/09/2011 16:47, Curtis Olson a écrit : Hi Geoff, I'm starting to run low on ideas here. I assume you don't have any crazy/severe turbulence turned on or your plots would be all over the place. Are you running out of fuel and your engines dying? If you open the autopilot dialog (F11) you can see the target speed and if you have the hud turned on you can see the actual speed in any view. If you are circling with a target speed of 150 and your airspeed is less than than and you are decending, then definitely check your engine output. There is a fuel dialog box under the f-14b menu and you might double check that to see if you have any fuel in your tanks. For what it's worth, I'm rock solid in circling and the only time I have ever stalled out of the sky or really got out of kilter is when I've had severe turbulence turned on. Moderate turbulence at all levels is actually pretty interesting because despite getting thrown all over the sky, I still hit the carrier deck pretty spot on every time. Curt. Still no tests yet but just a though, In normal use (without the UAV script) I know that after TO (flaps down) you have to rise the flaps in before engaging the attitude autopilot mode. If you rise the flaps after engaging attitude autopilot mode, the a/c start to pitch up consistently. This has to be documented or fixed. I'll try to bring the maintainer to his workstation ASAP. Alexis On Fri, Sep 23, 2011 at 9:35 AM, Geoff McLane wrote: Hi Curt, Ok, removed my joystick, and entered a '5', but still crashed while just in 'circle' mode - no route entered ;=(( As usual Atlas provides a good 'view' as to what happened - added - ATLAS=--atlas=socket,out,IP,5500,udp to output to Atlas running in a 2nd machine... See - http://geoffair.org/tmp/uas-01.jpg for a graph of the flight... The two blips in the graphs show the first stall, but it recovers and begins to climb back, and the 2nd the second stall, this time too low to recover, so into the drink ;=(( CRASH! This is a view of the 'crazy' flight track http://geoffair.org/tmp/uas-02.jpg Obviously the pig-tail loops are the 'stalls'... remember with NO joystick attached and starting with centered controls (NumPad 5)... And if you want to load this track into Atlas, or further study speeds, etc, then this is the Atlas track data :- http://geoffair.org/tmp/uas-01.txt Then on the NEXT flight I tried :- IO=--generic=file,out,10,uas-02.csv,playback Then I added a header line, to help analyze it in say an OpenOffice spreadsheet import - see - http://geoffair.org/tmp/uas-02.csv On this 2nd flight, this crash took longer, since it (randomly) turned left first, where as mentioned it holds more stable, but then eventually went into a right turn, stalled, recovered, stalled again, and CRASHED... And as you know well, downloading this file, and using say - $ ./fgfs --fg-root=/point/to/fgfs/data --timeofday=noon \ --aircraft=f-14b-uas --carrier=Vinson \ --generic=file,in,10,uas-02.csv,playback --fdm=external you too can enjoy this fateful flight ;=)) In 'chase' view, you can clearly see the right roll increase, the nose coming up, and the stall, recovery, then repeated, and BANG, into the water... I know it is difficult to work on, debug, fix something that obviously does not happen in your case... Maybe if you do not enter any route, or something... And this is all with SG/FG git of 2011-09-14... Any other ideas? Regards, Geoff. On Thu, 2011-09-22 at 14:00 -0500, Curtis Olson wrote: On Thu, Sep 22, 2011 at 1:25 PM, Geoff McLane wrote: Hi Curt, A pleasure, and FUN ;=)) Yes, I know a low frame rate can play havoc when you are trying to fine control an aircraft from its attitude feedback, and I should have mentioned my rate, but is always in the high 50-70 fps range in this Ubuntu machine... so should NOT be a factor... Ok, 50-70 should be perfect. I just did another few runs, and this time it crashed just while circling... it was in a right bank, which got too much and the nose came up, and it stalled... I am mostly in the 'chase' view... This is really strange. I have seen nothing like this except when I inadvertantly applied external control inputs through a strange combination of linux virtual desktops and flightgear capturing the hotkey to come back to the FlightGear virtual desktop. So two thoughts here. If you have a joystick connected, could you try unplugging it to see if that
Re: [Flightgear-devel] Mapping Airspace
Here's another fun way of mapping airspace: You can get sectional charts in the form of .tif files from: http://www.aeronav.faa.gov/index.asp?xml=aeronav/applications/VFR/chartlist_sect You can then read them into QGIS ... and then overlay them with whatever other information you want, perhaps from apt.dat and nav.dat and/or elsewhere. (Reading the same .tif file into GRASS doesn't work. GRASS tries and fails, with no error or warning messages. The resulting map has no pixels at all, according to d.histogram. So this is another reason to use QGIS.) On 09/21/2011 06:10 PM, J. Holden wrote: Admittedly I work with GRASS solely on the text-based side - rarely if ever touching the GUI Roger that. I, too, rely almost exclusively on the command-line interface to GRASS. I occasionally use the GUI to give me hints about what CLI commands I need to use. The stuff I need to do involves so many GRASS commands that I could not possibly remember them all, let alone do them reliably, so I use a script. I hope I didn't misinterpret what you're writing, and hopefully that was of some help. You definitely understood the questions (even though I now realize the questions were not entirely clear) ... and you have been very helpful. 3. You CAN do raster reprojection on the fly. However, your results won't be anywhere near as clean as a vector reprojection as a result of the different format type. Also, there are some rules - I believe the projection has to be in the current region of the location you're reprojecting to, and also the resolution must be sufficient in order to handle the map. Well, YMMV but I can't get the instance I'm running to do raster reprojection. It tries and fails. I have an example where there are two rasters in the same location, with slightly different projections, plus some vector data. If I switch projections in my project workspace, one raster or the other goes to all-white. The zoom to layer button zooms to the right place, but the image is still all-white. The vector data stays where it belongs, so that is working. This is a low priority for me, because I am content to reproject all rasters to a common SRS using gdalwarp. That does everything I need it to do. 1) it's probably easiest to continue to use d.his and then display the resulting map using the GRASS plugin - QGIS doesn't really have many (if any?) raster tools, while GRASS was created primarily to deal with raster features (and added vectors later). That sounds good, but I haven't figured out how to get a map /out/ of d.his. I think of d.his as a display function, not a map-calculation function. I don't know how to find the resulting map produced by d.his, not in any useful form anyway. And here is a possibly-related question: what colormap are the Sectional Aeronautical Charts using, and how do I specify it? They show up in QGIS in beautiful natural color. In particular, in QGIS, if I change the colormap on one of those charts, there does not appear to be any way to change it back to the beautiful original colormap. I assume there is some clever colormap that the QGIS backend knows about but the GUI does not. I mention this because I reckon I could solve several interesting problems by using this colormap, using r.mapcalc if necessary to format the pixels. This includes the drape operation, which produces very nice-looking results by taking the hue from one layer and the intensity from another. Or maybe somebody can write a r.calc.drape module. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] pthread error compiling simgear under ubuntu 11.10 (beta2)
Hi, I am trying to take one step ahead, and start adapting the script to work with the upcoming ubuntu relase of october. after a little modification (libapr1-dev needed and renaming libboost1.46-dev) I failed to succeed cause simgear does not compile, it complains about pthread during compilation: g++ -g -O2 -Wall -D_REENTRANT -L/home/francesco/fgfs/install/simgear/lib -L/home/francesco/fgfs/install/OpenSceneGraph/lib -o socktest socktest.o libsgio.a ../../simgear/structure/libsgstructure.a ../../simgear/threads/libsgthreads.a ../../simgear/debug/libsgdebug.a ../../simgear/bucket/libsgbucket.a ../../simgear/misc/libsgmisc.a -lz -lOpenThreads -lrt -lm -lrt -lm -lrt -lm ../../simgear/threads/libsgthreads.a(SGThread.o): In function `~PrivateData': /home/francesco/fgfs/simgear/simgear/simgear/threads/SGThread.cxx:194: undefined reference to `pthread_detach' ../../simgear/threads/libsgthreads.a(SGThread.o): In function `SGThread::PrivateData::start(SGThread)': /home/francesco/fgfs/simgear/simgear/simgear/threads/SGThread.cxx:209: undefined reference to `pthread_create' ../../simgear/threads/libsgthreads.a(SGThread.o): In function `SGThread::PrivateData::join()': /home/francesco/fgfs/simgear/simgear/simgear/threads/SGThread.cxx:222: undefined reference to `pthread_join' ./configure says that pthread is availeable and he can find it. what makes me worry is this (generated during ./configure): checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking for library containing pthread_exit... none required looks like the configure thinks he does not need pthread at all, so it does not add it to g++ calls. (This is my noob c++ opinion). is there a solution ? I even tried with: export LIBS=-lpthread before launching the configure, but no success at all... Thanks in advance. Cheers Francesco -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mapping Airspace
On Fri, 23 Sep 2011, John Denker wrote: Here's another fun way of mapping airspace: You can get sectional charts in the form of .tif files from: http://www.aeronav.faa.gov/index.asp?xml=aeronav/applications/VFR/chartlist_sect John, do you know if they provide a version of that data that can be zoomed infinitely without pixelating? (ie. a vector based version of the same map) tnx! g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Direct Draw Surface Scenery Textures
On 23 Sep 2011, at 00:43, ThorstenB wrote: Hmm, but this actually means you have a brake problem after all. Only the brake temperature is simulated - smoke is triggered for overheated disc brakes. It's almost impossible that the parking brake is set (unless your both, deaf and blind...) but it seems like your brakes are slightly tightened after all. That's a safety critical issue - better tell maintenance personnel to check your flight gear - maybe the pedals are stuck... ;) It looks like this is indeed what is happening. I've been having some calibration problems ever since upgrading to Suse 11.4, and it looks like the normalized values for the toe-brakes can only be 0 or one, being zero when I'm not touching them. I wasn't aware of that yesterday, but it looks like the toe brakes should operate in the range of -1 to 1, so that 0 means that the breaks are half pressed. It looks like both my FlightGear desktop and my old laptop (both running opensuse 11.4) are showing the same problem, while the pedals are working correctly on my (work) macbook; obviously, I would almost add. I hope I can get this to work, because this looks like a nagging little problem. If not, I might be facing a kernel upgrade, or downgrade Cheers, Durk In any case, sorry about the noise... -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Any alpha testers with a bit of extra time on their hands?
Geoff and Arnt and anyone else who is interested. I just updated the zip file overlay with a few changes. Geoff: you may be getting tired of being a bunny, but I played around with the roll controller and limited max target roll angle to +/-35 degrees. I also dialed down the gains a bit on final approach which will hopefully slow down the wild swings. More adjustment may be necessary, but I'd be interested in hearing if any of this helps your situation. I also set the default carrier speed to zero so if we get a few people out there playing around with this, we should be able to see each other via MP. That could be an additional fun element. I was just out there dodging XIII who trailed me around the pattern and let me live thankfully. :-) Here is the link with the zip file overlay download + installation and operation instructions: http://www.flightgear.org/uas-demo/ MP Call Sign: Shrike :-) Maybe see a few of you out there? Curt. On Fri, Sep 23, 2011 at 1:12 PM, Citronnier - Alexis Bory wrote: Le 23/09/2011 16:47, Curtis Olson a écrit : Hi Geoff, I'm starting to run low on ideas here. I assume you don't have any crazy/severe turbulence turned on or your plots would be all over the place. Are you running out of fuel and your engines dying? If you open the autopilot dialog (F11) you can see the target speed and if you have the hud turned on you can see the actual speed in any view. If you are circling with a target speed of 150 and your airspeed is less than than and you are decending, then definitely check your engine output. There is a fuel dialog box under the f-14b menu and you might double check that to see if you have any fuel in your tanks. For what it's worth, I'm rock solid in circling and the only time I have ever stalled out of the sky or really got out of kilter is when I've had severe turbulence turned on. Moderate turbulence at all levels is actually pretty interesting because despite getting thrown all over the sky, I still hit the carrier deck pretty spot on every time. Curt. Still no tests yet but just a though, In normal use (without the UAV script) I know that after TO (flaps down) you have to rise the flaps in before engaging the attitude autopilot mode. If you rise the flaps after engaging attitude autopilot mode, the a/c start to pitch up consistently. This has to be documented or fixed. I'll try to bring the maintainer to his workstation ASAP. Alexis On Fri, Sep 23, 2011 at 9:35 AM, Geoff McLane wrote: Hi Curt, Ok, removed my joystick, and entered a '5', but still crashed while just in 'circle' mode - no route entered ;=(( As usual Atlas provides a good 'view' as to what happened - added - ATLAS=--atlas=socket,out,IP,5500,udp to output to Atlas running in a 2nd machine... See - http://geoffair.org/tmp/uas-01.jpg for a graph of the flight... The two blips in the graphs show the first stall, but it recovers and begins to climb back, and the 2nd the second stall, this time too low to recover, so into the drink ;=(( CRASH! This is a view of the 'crazy' flight track http://geoffair.org/tmp/uas-02.jpg Obviously the pig-tail loops are the 'stalls'... remember with NO joystick attached and starting with centered controls (NumPad 5)... And if you want to load this track into Atlas, or further study speeds, etc, then this is the Atlas track data :- http://geoffair.org/tmp/uas-01.txt Then on the NEXT flight I tried :- IO=--generic=file,out,10,uas-02.csv,playback Then I added a header line, to help analyze it in say an OpenOffice spreadsheet import - see - http://geoffair.org/tmp/uas-02.csv On this 2nd flight, this crash took longer, since it (randomly) turned left first, where as mentioned it holds more stable, but then eventually went into a right turn, stalled, recovered, stalled again, and CRASHED... And as you know well, downloading this file, and using say - $ ./fgfs --fg-root=/point/to/fgfs/data --timeofday=noon \ --aircraft=f-14b-uas --carrier=Vinson \ --generic=file,in,10,uas-02.csv,playback --fdm=external you too can enjoy this fateful flight ;=)) In 'chase' view, you can clearly see the right roll increase, the nose coming up, and the stall, recovery, then repeated, and BANG, into the water... I know it is difficult to work on, debug, fix something that obviously does not happen in your case... Maybe if you do not enter any route, or something... And this is all with SG/FG git of 2011-09-14... Any other ideas? Regards, Geoff. On Thu, 2011-09-22 at 14:00 -0500, Curtis Olson wrote: On Thu, Sep 22, 2011 at 1:25 PM, Geoff McLane wrote:
Re: [Flightgear-devel] FG hangs on loading scenery when using many objects
Hey Csaba,
hey Geoff,
thanks a lot for looking into this!
void SGPagedLOD::forceLoad(osgDB::DatabasePager *dbp, FrameStamp*
framestamp, ? ? ? ? ? ? ? ? ? ? ? ? ???NodePath path)
{
? ? //SG_LOG(SG_GENERAL, SG_ALERT, SGPagedLOD::forceLoad(
? ? //getFileName(getNumChildren()) ));
And now the crazy part! If I uncomment this logging, everything
suddenly works, even with 20k objects:
Same here -- uncommenting this part in simgear/scene/model/SGPagedLOD.cxx
fixes the issue for me, too. 20k objects were loaded within 10 sec on my P4
2.4 GHz, though frame rate is ~5 then...
Cheers,
Tom
signature.asc
Description: This is a digitally signed message part.
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Any alpha testers with a bit of extra time on their hands?
Le 22/09/2011 05:03, Curtis Olson a écrit : I have something here that I think is kind of fun. Yup, I confirm this is plenty fun :-) It worked like a charm here. However with local weather, cold front, rough day condition, the challenge is there. Due to heavy turbs the system entered huge pitch oscillations at one mile or so in approach, but recovered stability just in time, doing a step descent (at least from chase view). Then it missed the wires, but well I think the bolter function is not there yet :-) Whit acceptable weather every thing worked as expected for the two first attempts. Then, as I was continuing this mail, the thing started to try turning the hardest possible, +/- 75deg roll and 43 AoA, ending in the water. the last attempt was aborted due to dinner time but I noticed that the switch between climbout and circle induced also a serious oscillation phase, that is AP overacting during 10 or 20 secs. (fps around 20). Then after dinner a long serial of perfect runs. I've no idea yet about what could help solving those problems. Actually there are 2 birds flying mostly the same pattern 150KTS@2000FT above the Vinson !!! That's Shrike. Some ideas: - Key 'Enter' closes the control window, it shouldn't. - The engineering HUD would be more appropriate with aircraft reference instead of f-16 like with camera reference, at least to have an idea of the controls setting. - Why not simply add the camera view with a high view number so it take place in the original numbering scheme between RIO and Pilot's view, thus keeping the usual shortcuts available ? - This kind of well formed approach would be very nice: http://www.maison-capestang.com/fg/a6/A-6E-carrier-landing-pattern-ng.png - The Downwind to Final switch is a bit rough and the gear is downed at the same time, this has a weird visual effect. - Moving target detection on mouse click and lock. - A 3D control panel in the cockpit, looking a bit custom, with red tape and big labels, like those you can see on test beds... I wonder who could do that. - Readable Nasal ??? Conclusion: AWESOME !!! Thanks a lot for sharing this, Alexis I've been fiddling with this off and on since last fall and decided it was time to clean it up a bit and quit hording all the fun for myself. Basically I have taken the F-14b and created a high performance Navy drone out of it. It can auto-launch from a carrier, auto fly a route (if you've input one) and can do circle holds (compensating for wind.) I've added a simulated gyro stabilized camera that will point at anything you click on and then hold that view steady no matter what the airplane does (similar to what real uav's can do.) Finally, you can command it to return home and it will find the carrier, setup a reasonable approach and nail the landing perfectly every time (factoring in wind, carrier speed, etc.) I put together a quick web page that includes more of an explanation and description of what the demo does. I have a link to a zip file you need to download. This must be extracted over the top of the existing f-14b as per the installation instructions on the following web site: http://www.flightgear.org/uas-demo/ I'm hoping to get a few people that would like to try this and report back on a couple things: - were you able to get it to work? Were there any missing files or major blunders in the .zip file package? - are there places where my web page instructions stink, and can you help me write better or more accurate instructions, especially for the Mac - I already know my instructions for setting up the vinson demo aren't good, but it's been so long since I tried to do this on windows I forget all the fgrun details. Maybe there is an easier way now? - finally, what do you think? general impressions? things you thought were especially cool, or especially stupid? You probably can think of a dozen feature requests, and I have some things in the pipeline already. (For instance I have a refueling mode that is currently disabled, but almost is close to working. And I've done some preliminary work on adapting all of the auto-land logic for runway landings.) - if you happen to go look at the nasal code that does all the magic, please don't judge me (quoting Eskeletor from nacho libre) -- that was actually a fun sub-project (for a former computer scientist.) :-) - Oh, and eventually I'd like to add pictures to the instructions. If you happen to catch an especially cool looking view (weather, clouds, time of day, sun, sun glint, scene composition, etc.) then please feel free to send me a picture or two (or even a youtube movie) so I can make the instructions prettier and more exciting. :-) If I can get this demo all cleaned up and generally running pretty well, I have another UAS demo that is similar, but centered around the ATI Resolution-3 airframe (which is a 92 2.33m composite marinized
Re: [Flightgear-devel] Any alpha testers with a bit of extra time on their hands?
Le 23/09/2011 23:12, Curtis Olson a écrit : Geoff and Arnt and anyone else who is interested. I just updated the zip file overlay with a few changes. Geoff: you may be getting tired of being a bunny, but I played around with the roll controller and limited max target roll angle to +/-35 degrees. I also dialed down the gains a bit on final approach which will hopefully slow down the wild swings. More adjustment may be necessary, but I'd be interested in hearing if any of this helps your situation. I also set the default carrier speed to zero so if we get a few people out there playing around with this, we should be able to see each other via MP. That could be an additional fun element. I was just out there dodging XIII who trailed me around the pattern and let me live thankfully. :-) Here is the link with the zip file overlay download + installation and operation instructions: http://www.flightgear.org/uas-demo/ MP Call Sign: Shrike :-) Woot :-) so I missed the update, I just read this post after posting the previous one. And was wondering who was flying around there ! Model view ought to be interesting in case of one other tester just encounter problems. Greetings, Alexis Maybe see a few of you out there? Curt. On Fri, Sep 23, 2011 at 1:12 PM, Citronnier - Alexis Bory wrote: Le 23/09/2011 16:47, Curtis Olson a écrit : Hi Geoff, I'm starting to run low on ideas here. I assume you don't have any crazy/severe turbulence turned on or your plots would be all over the place. Are you running out of fuel and your engines dying? If you open the autopilot dialog (F11) you can see the target speed and if you have the hud turned on you can see the actual speed in any view. If you are circling with a target speed of 150 and your airspeed is less than than and you are decending, then definitely check your engine output. There is a fuel dialog box under the f-14b menu and you might double check that to see if you have any fuel in your tanks. For what it's worth, I'm rock solid in circling and the only time I have ever stalled out of the sky or really got out of kilter is when I've had severe turbulence turned on. Moderate turbulence at all levels is actually pretty interesting because despite getting thrown all over the sky, I still hit the carrier deck pretty spot on every time. Curt. Still no tests yet but just a though, In normal use (without the UAV script) I know that after TO (flaps down) you have to rise the flaps in before engaging the attitude autopilot mode. If you rise the flaps after engaging attitude autopilot mode, the a/c start to pitch up consistently. This has to be documented or fixed. I'll try to bring the maintainer to his workstation ASAP. Alexis On Fri, Sep 23, 2011 at 9:35 AM, Geoff McLane wrote: Hi Curt, Ok, removed my joystick, and entered a '5', but still crashed while just in 'circle' mode - no route entered ;=(( As usual Atlas provides a good 'view' as to what happened - added - ATLAS=--atlas=socket,out,IP,5500,udp to output to Atlas running in a 2nd machine... See - http://geoffair.org/tmp/uas-01.jpg for a graph of the flight... The two blips in the graphs show the first stall, but it recovers and begins to climb back, and the 2nd the second stall, this time too low to recover, so into the drink ;=(( CRASH! This is a view of the 'crazy' flight track http://geoffair.org/tmp/uas-02.jpg Obviously the pig-tail loops are the 'stalls'... remember with NO joystick attached and starting with centered controls (NumPad 5)... And if you want to load this track into Atlas, or further study speeds, etc, then this is the Atlas track data :- http://geoffair.org/tmp/uas-01.txt Then on the NEXT flight I tried :- IO=--generic=file,out,10,uas-02.csv,playback Then I added a header line, to help analyze it in say an OpenOffice spreadsheet import - see - http://geoffair.org/tmp/uas-02.csv On this 2nd flight, this crash took longer, since it (randomly) turned left first, where as mentioned it holds more stable, but then eventually went into a right turn, stalled, recovered, stalled again, and CRASHED... And as you know well, downloading this file, and using say - $ ./fgfs --fg-root=/point/to/fgfs/data --timeofday=noon \ --aircraft=f-14b-uas --carrier=Vinson \
Re: [Flightgear-devel] Any alpha testers with a bit of extra time on their hands?
On Fri, 23 Sep 2011 23:44:02 +0200, Citronnier wrote in message 4e7cfda2.7060...@gmail.com: Le 23/09/2011 23:12, Curtis Olson a écrit : Geoff and Arnt and anyone else who is interested. I just updated the zip file overlay with a few changes. Geoff: you may be getting tired of being a bunny, but I played around with the roll controller and limited max target roll angle to +/-35 degrees. I also dialed down the gains a bit on final approach which will hopefully slow down the wild swings. More adjustment may be necessary, but I'd be interested in hearing if any of this helps your situation. ..a wee bit, now takes off and makes it ~1000 feet up, then it rolls to the right and makes it ~200 feet into the drink, and repeats the stunt seated in the cockpit (rather than in the camera), uncommanded on Reset button pushes. ..it's trying to orbit the carrier in the vertical plane? ..trying the operator click mode on targets like the merchantman near the Nimitz, works, until the demo is airborne, then it picks the Carrier target and tries a vertical orbit around it. ..refetching the merchantman with the operator mouse click mode, dives the demo into the drink between the 2 vessels. ..debug idea for Curtis: try the Nimitz too. I also set the default carrier speed to zero so if we get a few people out there playing around with this, we should be able to see each other via MP. That could be an additional fun element. I was just out there dodging XIII who trailed me around the pattern and let me live thankfully. :-) Here is the link with the zip file overlay download + installation and operation instructions: http://www.flightgear.org/uas-demo/ MP Call Sign: Shrike :-) Woot :-) so I missed the update, I just read this post after posting the previous one. And was wondering who was flying around there ! Model view ought to be interesting in case of one other tester just encounter problems. Greetings, Alexis Maybe see a few of you out there? Curt. On Fri, Sep 23, 2011 at 1:12 PM, Citronnier - Alexis Bory wrote: Le 23/09/2011 16:47, Curtis Olson a écrit : Hi Geoff, I'm starting to run low on ideas here. I assume you don't have any crazy/severe turbulence turned on or your plots would be all over the place. Are you running out of fuel and your engines dying? If you open the autopilot dialog (F11) you can see the target speed and if you have the hud turned on you can see the actual speed in any view. If you are circling with a target speed of 150 and your airspeed is less than than and you are decending, then definitely check your engine output. There is a fuel dialog box under the f-14b menu and you might double check that to see if you have any fuel in your tanks. For what it's worth, I'm rock solid in circling and the only time I have ever stalled out of the sky or really got out of kilter is when I've had severe turbulence turned on. Moderate turbulence at all levels is actually pretty interesting because despite getting thrown all over the sky, I still hit the carrier deck pretty spot on every time. Curt. Still no tests yet but just a though, In normal use (without the UAV script) I know that after TO (flaps down) you have to rise the flaps in before engaging the attitude autopilot mode. If you rise the flaps after engaging attitude autopilot mode, the a/c start to pitch up consistently. This has to be documented or fixed. I'll try to bring the maintainer to his workstation ASAP. Alexis On Fri, Sep 23, 2011 at 9:35 AM, Geoff McLane wrote: Hi Curt, Ok, removed my joystick, and entered a '5', but still crashed while just in 'circle' mode - no route entered ;=(( As usual Atlas provides a good 'view' as to what happened - added - ATLAS=--atlas=socket,out,IP,5500,udp to output to Atlas running in a 2nd machine... See - http://geoffair.org/tmp/uas-01.jpg for a graph of the flight... The two blips in the graphs show the first stall, but it recovers and begins to climb back, and the 2nd the second stall, this time too low to recover, so into the drink ;=(( CRASH! This is a view of the 'crazy' flight track http://geoffair.org/tmp/uas-02.jpg Obviously the pig-tail loops are the 'stalls'... remember with NO joystick attached and starting with centered controls (NumPad 5)... And if you want to load this track into Atlas, or further study speeds, etc, then this is the Atlas track data :-
[Flightgear-devel] fgpanel build error on openSUSE
# ./configure --prefix=/usr/local/lib64 --includedir=/usr/local/include --bindir=/usr/local/bin --with-threads --with-simgear=/usr/local --libdir=/usr/local/lib64 --with-plib=/usr/lib64 --datarootdir=/usr/local/share/FlightGear/data --enable-atcdl --with-osg=/usr/local/lib64 Problem is with the fgpanel Makefile. /usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/ld: panel.o: undefined reference to symbol 'glTranslated' /usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/ld: note: 'glTranslated' is defined in DSO /usr/lib64/libGL.so.1 so try adding it to the linker command line /usr/lib64/libGL.so.1: could not read symbols: Invalid operation slipstream:/home/lancelot/ftp/sep11/FGFS/flightgear # vi utils/fgpanel/Makefile Changed the LDFLAGS line and fgpanel builds. LDFLAGS = -L/lib64 -L/usr/lib64 -L/usr/local/lib64 -L/usr/X11R6/lib -lGL -lz It needed -L/usr/lib64 and -lGL for the libGL.so.1 problem and -L/lib64 and -lz for the libz.so.1 follow-on problem. I also changed /usr/local/lib to /usr/local/lib64 make[2]: Entering directory `/home/lancelot/ftp/sep11/FGFS/flightgear/utils/fgpanel' g++ -DPKGDATADIR=\/usr/local/share/FlightGear/data/flightgear\ -g -O2 -Wall -I/usr/local -D_REENTRANT -L/lib64 -L/usr/lib64 -L/usr/local/lib64 -L/usr/X11R6/lib -lGL -lz -o fgpanel main.o FGGLApplication.o FGPanelApplication.o FGPNGTextureLoader.o FGRGBTextureLoader.o FGPanelProtocol.o FGFontCache.o panel.o panel_io.o -lGLU -lglut -lsgmath -lsgprops -lsgio -lsgdebug -lsgmisc -lsgstructure -lsgxml -lsgtiming -lplibpu -lplibfnt -lplibul -lsgthreads -lrt -lpng -losgFX -losgParticle -losgSim -losgViewer -losgGA -losgText -losgDB -losgUtil -losg -lOpenThreads make[2]: Leaving directory `/home/lancelot/ftp/sep11/FGFS/flightgear/utils/fgpanel' make[2]: Entering directory `/home/lancelot/ftp/sep11/FGFS/flightgear/utils' make[2]: Nothing to be done for `all-am'. make[2]: Leaving directory `/home/lancelot/ftp/sep11/FGFS/flightgear/utils' make[1]: Leaving directory `/home/lancelot/ftp/sep11/FGFS/flightgear/utils' make[1]: Entering directory `/home/lancelot/ftp/sep11/FGFS/flightgear' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/lancelot/ftp/sep11/FGFS/flightgear' slipstream:/home/lancelot/ftp/sep11/FGFS/flightgear # Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
