Re: [Flightgear-devel] Autopilot tuning
Wonderful, brilliant stuff Giuseppe, The way that the autopilot works with those patches is the way I expected. Hope this stuff makes its way into CVS so at least there's a good reference implementation. pete Giuseppe Venanzoni wrote: > Hi! > > I would like to join the discussion about AP tuning. I recently posted > a message on the forum > (http://www.flightgear.org/forums/viewtopic.php?f=4&t=6853) for > b1900d. With enclosed files, action is quite smooth and autopilot > seems stable, at least on my conputer. > For vertical stabilization (selected altitude holding) I used an > approach very similar to the one proposed by LeeE, with a first stage > that controls vertical speed (I used a proportional only stage with > ). I also managed the configuration in such a > way to share as much stages as possible for different modes, using a > flag which activates these stages. > I also used several noise-spike filters in order to avoid abrupt changes. > For the problem of bouncing during transition between modes, I > modified the script flightdirector.nas in such a way that when pilot > switches on AP or changes mode all internal variables of the autopilot > are reinitialized with the current attitude of the plane. In fact, for > velocity mode PIDs the memory of the past is only contained in these > variables, since there isn't an integrator. > > I hope that it can be useful. > > Giuseppe > > > leee wrote: > >> The large initial deflections you can get when switching between >> different controller cascades seems to occur because on the first >> iteration the controller sees an error but has no 'trend history' >> to know how effective its correction is, and so may command the max >> correction. As the aircraft responds to the initial correction >> though, the controller gets feedback upon which it then gauges the >> correction for the next iteration. >> >> There are a number of ways around this, from limiting the flight >> control surface rate, either in the FDM config, or by inserting a >> filter between the output from the controller and the control axis >> input of the FDM, to filtering the target inputs, to using common >> pid controllers in the control hierarchy. >> >> I ended up using a three controller hierarchy in some aircraft, with >> the same lower-level controllers being used by all modes and which >> were always engaged; only the top level controllers were switched. >> >> For example, for altitude-hold I might have the following hierarchy: >> >> Altitude-hold: generates a target climb-rate in FPS from the >> difference between the current altitude and the target altitude. >> >> Climb-rate-hold: generates a target pitch angle from the >> difference between the current climb-rate and the target >> climb rate generated by the Altitude-hold controller. >> >> Pitch-hold: generates an elevator deflection from the >> difference betwen the current pitch and the target >> pitch generated by the Climb-rate-hold controller. >> >> but then I'd use the same Climb-rate-hold and Pitch-hold controllers >> for the glideslope-hold hierarchy and just switch the Top level >> Altitude hold controller off instead of duplicating the entire >> hierarchy again. >> >> Because the lower-level controllers are running continuously and are >> not switched on and off they've got some trend history data to be >> working with and this seems to ameliorate the problem by >> effectively buffering the top-level input change. >> >> This type of hierarchy isn't without its own problems though; at low >> airspeeds you might need the Pitch-hold controller to be pretty >> brutal and almost driving into oscillation but at high speeds you >> need it to be much more delicate. However, judicious use of >> filters and variable gains can usually get you around most >> problems. >> >> There is one type of autopilot problem that's more difficult fix >> though: the autopilot controllers and filters should run at a >> constant rate and although a parameter was added and >> initially worked, I think it may have become broken at some point >> and the rate at which the controllers and filters operate depends >> more upon the frame rate than anything else. Because the rate at >> which the controllers work is critical, depending upon the gains >> used, a controller that might be stable on one system might become >> unstable on a slower, or even sometimes a faster system (I've seen >> this sort of problems happen both ways). >> >> LeeE >> > > -- > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > ___ > Flightgear-devel mailing list > Flightgea
[Flightgear-devel] Stencil operations for effects and new "light cone"
Hi!
The attached patch adds support for stencil operations in effects.
Patches are for simgear's scene/material/Effect.cxx and flightgear's
Main/CameraGroup.cxx. I did them with "cvs diff " against latest
CVS version. Hope that is correct way.
The format of stencil operations in effect file is following:
...
...
...
...
...
...
Where function can be never, always, less, less-or-equal, equal,
not-equal, greater-or-equal or greater.
Value is the reference value used in stencil operations and mask is the
stencil bit mask.
Stencil-fail, z-fail and pass are stencil operations if stencil test
fails or stencil-test passes but z-test fails or both passes. Possible
functions are zero, keep, replace, increase, decrease, invert,
increase-wrap and decrease-wrap.
I think one has to know something about stencil buffers to use this ;)
I also added a new general tag 1 0 0
1 that allows only writing to certain channel (in this
example only to red and alpha channel.
As an example, I attached new version of the light-cone.eff I posted few
days ago. This one does the same thing but with stencil operations.
The .ac model used with this should be almost transparent or it will be
too bright.
This version has some issue if there is more than 5 light models
simultaneously. I don't know if this is a OSG issue about rendering
orders or something? But please test and comment.
Lauri, a.k.a. Zan
--
Lauri Peltonen
lauri.pelto...@gmail.com
Index: CameraGroup.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/CameraGroup.cxx,v
retrieving revision 1.18
diff -r1.18 CameraGroup.cxx
157c157
< camera->setClearMask(GL_DEPTH_BUFFER_BIT);
---
> camera->setClearMask(GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT);
205c205
< camera->setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
---
> camera->setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT);
216c216
< camera->setClearMask(GL_DEPTH_BUFFER_BIT);
---
> camera->setClearMask(GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT);
Index: Effect.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/material/Effect.cxx,v
retrieving revision 1.29
diff -r1.29 Effect.cxx
53a54
> #include
255a257,274
> struct ColorMaskBuilder : PassAttributeBuilder
> {
> void buildAttribute(Effect* effect, Pass* pass, const SGPropertyNode* prop,
> const osgDB::ReaderWriter::Options* options)
> {
> const SGPropertyNode* realProp = getEffectPropertyNode(effect, prop);
> if (!realProp)
> return;
>
> ColorMask *mask = new ColorMask;
> Vec4 m = getColor(realProp);
> mask->setMask(m.r(), m.g(), m.b(), m.a());
> pass->setAttributeAndModes(mask);
> }
> };
>
> InstallAttributeBuilder installColorMask("color-mask");
>
477a497,589
>
> EffectNameValue stencilFunctionInit[] =
> {
> {"never", Stencil::NEVER },
> {"less", Stencil::LESS},
> {"equal", Stencil::EQUAL},
> {"less-or-equal", Stencil::LEQUAL},
> {"greater", Stencil::GREATER},
> {"not-equal", Stencil::NOTEQUAL},
> {"greater-or-equal", Stencil::GEQUAL},
> {"always", Stencil::ALWAYS}
> };
>
> EffectPropertyMap stencilFunction(stencilFunctionInit);
>
> EffectNameValue stencilOperationInit[] =
> {
> {"keep", Stencil::KEEP},
> {"zero", Stencil::ZERO},
> {"replace", Stencil::REPLACE},
> {"increase", Stencil::INCR},
> {"decrease", Stencil::DECR},
> {"invert", Stencil::INVERT},
> {"increase-wrap", Stencil::INCR_WRAP},
> {"decrease-wrap", Stencil::DECR_WRAP}
> };
>
> EffectPropertyMap stencilOperation(stencilOperationInit);
>
> struct StencilBuilder : public PassAttributeBuilder
> {
> void buildAttribute(Effect* effect, Pass* pass, const SGPropertyNode* prop,
> const osgDB::ReaderWriter::Options* options)
> {
> if (!isAttributeActive(effect, prop))
> return;
>
> const SGPropertyNode* pmode = getEffectPropertyChild(effect, prop,
> "mode");
> if (pmode && !pmode->getValue()) {
> pass->setMode(GL_STENCIL, StateAttribute::OFF);
> return;
> }
> const SGPropertyNode* pfunction
> = getEffectPropertyChild(effect, prop, "function");
> const SGPropertyNode* pvalue
> = getEffectPropertyChild(effect, prop, "value");
> const SGPropertyNode* pmask
> = getEffectPropertyChild(effect, prop, "mask");
> const SGPropertyNode* psfail
> = getEffectPropertyChild(effect, prop, "stencil-fail");
> const SGPropertyNode* pzfail
> = getEffectPropertyChild(effect, prop, "z-fail");
> const SGPropertyNode* ppass
>
Re: [Flightgear-devel] 777: patches and bug
> *as you said, LNAV doesn't follow a course, but you fixed it > I'll commit tonight... > > *I couldn't dial a V/S unless the AP is engaged and V/S mode is engaged > too. Is it supposed to be that way ? > Yes ... if I remeber right the digits shouldn't display at all until in V/S / FPA mode. > I would expect to be able to dial a vertical speed while, for instance, > holding altitude, then engage V/S to descent/climb at the desired rate. > Thats what the FLCH (flight level change ) and CLM/CON(climb control) are meant for if I understand you correctly.Not yet implemented This is an airliner , meant for point A to Point B flight , and most of this is programmed in the FMS... at least that's what Ive read to date ...could be wrong. Maybe I missed something Your using recent cvs ? I'll take another look , it worked fine a few days ago... *I didn't find a way to display a ADF needle On the controller directly above the PFD , are 2 switches that say ADF L / VOR L and ADF R / VOR R . these switch on pointers on the ND in MAP mode. *I couldn't display VOR R or ILS R, only L worked. not implemented yet ? Only NAV 1 is used until I find the proper switching method. *Is there really no radio stack on the board ? Yes , but need a bit more researcg ... it doesnt use the comm1 comm2 nav1 nav2 method I hope this all doesn't sound picky, I know the plane is in development, but I wanted to point out those things I noticied. Awesome plane besides this !! Thank you On 26/01/2010 08:13, Pete Morgan wrote: Attached is a patch that adds filters to the 777 autopilot's Heading, LNAV and Altitude Major bug is LNAV. The 777 currently doesn't fly on a LNAV/CRS properly. The aircraft ends up on the correct heading, but with no correction, ie parallel to predicted path and not correcting. The values in the PID are completely different to other observed aircraft, so am unsure what the problem is atmo. Also this warning message is output below, not sure when it starts but its goes on forever Warning: State::drawQuads(0, 58464) too large handle in remapping to ushort glDrawElements. Warning: State::drawQuads(0, 58468) too large handle in remapping to ushort glDrawElements. Warning: State::drawQuads(0, 58468) too large handle in remapping to ushort glDrawElements. Warning: State::drawQuads(0, 58468) too large handle in remapping to ushort glDrawElements. regards pete -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list flightgear-de...@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot tuning
I wouldnt spend too much time on the b1900d , as Ive already redone most of it ,and added the CLM /DSC modes , and will probably commit tonight . The main problem i found on that is the yaw damper was fighting any turn in roll modes,so at the moment Ive disabled it. I'm still tuning the pitch modes , i get the extreme elevator offset on mode initiaization now... Cheers -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Segmentation fault
Hi, I built the latest version of flightgear from cvs yesterday. When I tried to run c172p and 777-200ER, I got following message: FGMultiplayMgr - No receiver port, Multiplayermode disabled loading scenario 'nimitz_demo' Segmentation fault can anyone help me thanks -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear release candidate for windows 2.1 available through bittorrent
Hi Torsten, On Tuesday 26 January 2010 06:15:49 pm Torsten Dreyer wrote: > Just grabbed the torrents to seed for some time. While the 32bit version is > 291MB, the 64bit version is just 13.4MB. Is that plausible? > Thanks! Yes, those sizes are correct. The regular package includes the data as well, whereas the 64 bit version is binaries only. FWIW, I also left bittorrent running on my work machine, which has a direct connection to the university network, and should be pretty fast. Cheers, Durk -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear release candidate for windows 2.1 available through bittorrent
> Dear all, > > please find a new (and hopefully semi-final) release candidate for > FlightGear available for bittorrent download: > > http://www.xs4all.nl/~dtalsma/fgsetup-2.0.0-RC2.1.exe.torrent > > Note that there is also a 64-bit version of executable available here: > http://www.xs4all.nl/~dtalsma/fgsetup64-2.0.0-RC2.1.exe.torrent Just grabbed the torrents to seed for some time. While the 32bit version is 291MB, the 64bit version is just 13.4MB. Is that plausible? Torsten -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
> It's been a long time since I (re-)wrote the random object code for OSG, but > my > recollection is that we use the same random number seed when generating random model placements, to ensure that a building is in the same place on > every computer. > I suspect that part of the problem with the water-tower may be an artifact of > the > random number generator, though having one every 300,000 m^2 was also a bit much! > However, I've never investigated sufficiently to determine if that > is the case. Stuart: What happened is that towns are usually defined as points, which get interpreted by the scenery-generation system as the landcover type "town". Back when the water tower was first implemented, towns were turned into squares about 1km on a side and there was one water tower per town. As myself and others have improved on the quality of the scenery, these "towns" went from small squares with one church, water tower, house, etc to much larger expanses with many churches, water towers, et cetera. I like those shared German and Dominicaian houses in the shared model directory for town autogen... perhaps those could be substituted in the water tower's wake? However, I don't have cvs privileges... has someone stepped up to the plate and fixed this yet? Cheers John -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Autopilot tuning
Hi! I would like to join the discussion about AP tuning. I recently posted a message on the forum (http://www.flightgear.org/forums/viewtopic.php?f=4&t=6853) for b1900d. With enclosed files, action is quite smooth and autopilot seems stable, at least on my conputer. For vertical stabilization (selected altitude holding) I used an approach very similar to the one proposed by LeeE, with a first stage that controls vertical speed (I used a proportional only stage with ). I also managed the configuration in such a way to share as much stages as possible for different modes, using a flag which activates these stages. I also used several noise-spike filters in order to avoid abrupt changes. For the problem of bouncing during transition between modes, I modified the script flightdirector.nas in such a way that when pilot switches on AP or changes mode all internal variables of the autopilot are reinitialized with the current attitude of the plane. In fact, for velocity mode PIDs the memory of the past is only contained in these variables, since there isn't an integrator. I hope that it can be useful. Giuseppe leee wrote: > > The large initial deflections you can get when switching between > different controller cascades seems to occur because on the first > iteration the controller sees an error but has no 'trend history' > to know how effective its correction is, and so may command the max > correction. As the aircraft responds to the initial correction > though, the controller gets feedback upon which it then gauges the > correction for the next iteration. > > There are a number of ways around this, from limiting the flight > control surface rate, either in the FDM config, or by inserting a > filter between the output from the controller and the control axis > input of the FDM, to filtering the target inputs, to using common > pid controllers in the control hierarchy. > > I ended up using a three controller hierarchy in some aircraft, with > the same lower-level controllers being used by all modes and which > were always engaged; only the top level controllers were switched. > > For example, for altitude-hold I might have the following hierarchy: > > Altitude-hold: generates a target climb-rate in FPS from the > difference between the current altitude and the target altitude. > > Climb-rate-hold: generates a target pitch angle from the > difference between the current climb-rate and the target > climb rate generated by the Altitude-hold controller. > > Pitch-hold: generates an elevator deflection from the > difference betwen the current pitch and the target > pitch generated by the Climb-rate-hold controller. > > but then I'd use the same Climb-rate-hold and Pitch-hold controllers > for the glideslope-hold hierarchy and just switch the Top level > Altitude hold controller off instead of duplicating the entire > hierarchy again. > > Because the lower-level controllers are running continuously and are > not switched on and off they've got some trend history data to be > working with and this seems to ameliorate the problem by > effectively buffering the top-level input change. > > This type of hierarchy isn't without its own problems though; at low > airspeeds you might need the Pitch-hold controller to be pretty > brutal and almost driving into oscillation but at high speeds you > need it to be much more delicate. However, judicious use of > filters and variable gains can usually get you around most > problems. > > There is one type of autopilot problem that's more difficult fix > though: the autopilot controllers and filters should run at a > constant rate and although a parameter was added and > initially worked, I think it may have become broken at some point > and the rate at which the controllers and filters operate depends > more upon the frame rate than anything else. Because the rate at > which the controllers work is critical, depending upon the gains > used, a controller that might be stable on one system might become > unstable on a slower, or even sometimes a faster system (I've seen > this sort of problems happen both ways). > > LeeE -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Setting position via property tree
Hi Petr,
Here's a little snippet of some perl code I use to do this sort of thing
(it's from the backend of some perl-tk gui code, and unfortunately I can't
share the whole thing since I developed it for a proprietary project):
$HASH{ "/sim/presets/airport-id" } = $aptid;
$HASH{ "/sim/presets/runway" } = $rwyno;
$HASH{ "/sim/presets/vor-id" } = $vor_id;
$HASH{ "/sim/presets/vor-freq" } = $vor_freq;
$HASH{ "/sim/presets/ndb-id" } = $ndb_id;
$HASH{ "/sim/presets/ndb-freq" } = $ndb_freq;
$HASH{ "/sim/presets/fix" } = $fix;
$HASH{ "/sim/presets/longitude-deg" } = "-.0";
$HASH{ "/sim/presets/latitude-deg" } = "-.0";
$HASH{ "/sim/presets/offset-distance-nm" } = $dist;
$HASH{ "/sim/presets/offset-azimuth" } = $bearing;
$HASH{ "/sim/presets/heading-deg" } = $heading;
$HASH{ "/sim/presets/altitude-ft" } = $tmpalt;
$HASH{ "/sim/presets/glideslope-deg" } = $gs;
$HASH{ "/sim/presets/airspeed-kt" } = $airspeed;
There's a little loop that dumps all these things to FlightGear via the
"telnet" property interface, and the finishes by calling:
run presets-commit
It is probably helpful to review the presets code that sorts out all the
different preset options depending on the values in this tree. That will
give you an idea of what values you should leave empty, and what values to
set to -.0 (for example) in order to effect the right startup mode.
(The logic is a bit complex, so have patience when you work your way
through that code.)
Note, it appears (as best as I can see) that in air startups are broke and
probably haven't worked for a while with JSBSim and YASim. They do however
continue to work fine with an external proprietary fdm I've been using for
another project.
Regards,
Curt.
On Sat, Jan 23, 2010 at 4:40 PM, ing. Petr Ondra wrote:
> Hi,
> Please how can I set corretly position (on ground/in air) via property
> tree? (lat,lon,alt )
>
> THX
>
> mamucz
>
>
> --
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for
> Conference
> attendees to learn about information security's most important issues
> through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
I was wondering what those giant mushrooms were :P -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot: NAV/Localiser
Curtis Olson wrote: > On Tue, Jan 26, 2010 at 2:36 AM, syd adams wrote: > > > It works, but the behaviour is unexpected, or I got it wrong > about VOR > navigation. > > > Sounds like it could be a faulty config file ,,, but the proper > way to do a VOR navigation is : > Set your (VOR/LOC) frequency set your desired course / radial. > Set your heading bug to intercept the course ... most autopilots > ive been studying go into heading hold automatically if your > outside the capture range ... then NAV engages when your in range > of the course (not the station). > > > I would say be a little careful about what config file you use as an > example. There is some slightly goofy stuff that has crept into some > autopilots over the years. There are some stages that could easily be > "P" only, but are written as PID which leads to more hunting and > oscillations or long term errors than otherwise would be necessary I fixed the ocillations on a couple of aircraft, however all the aircraft have this NAV1/VOR slow correcting error which is completely unrealistic imho, such as following a SID or STAR as the aircraft doesnt really get on course until near the VOR station. (red in the image below). http://imgur.com/LL6b9 What this implies is that say I am 100nm away from a VOR, and just within the 30 degree correction, then it would take 100nm to correct that final 30 degree. Is there a way to sort this with a PID. And as Syd pointed out with the "car" and "road" analogy, then the car would be in the ditch most of the time ! pete -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
One airport in BC has a water tower directly at the end of the runway , (after Ifixed the scenery) ..and I discovered they are solid :) . Even one tower per town seems a bit much , I haven't seen anything quite like it in real life. Cheers -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 777: patches and bug
Hello ! I tried the 777 yesterday, and a few things appeared strange to me : *as you said, LNAV doesn't follow a course, but you fixed it *I couldn't dial a V/S unless the AP is engaged and V/S mode is engaged too. Is it supposed to be that way ? I would expect to be able to dial a vertical speed while, for instance, holding altitude, then engage V/S to descent/climb at the desired rate. In the same idea, say you descend at some rate with V/S engaged, then you want to reach an altitude. I didn't manage to arm altitude hold, instead I had to manually dial 0 on V/S when reached the altitude, and only then, hold my alt. I don't know how the real thing is, but it seemed odd to me. Maybe I missed something *I didn't find a way to display a ADF needle *I couldn't display VOR R or ILS R, only L worked. not implemented yet ? *Is there really no radio stack on the board ? I hope this all doesn't sound picky, I know the plane is in development, but I wanted to point out those things I noticied. Awesome plane besides this !! Thank you On 26/01/2010 08:13, Pete Morgan wrote: > Attached is a patch that adds filters to the 777 autopilot's Heading, > LNAV and Altitude > > Major bug is LNAV. > The 777 currently doesn't fly on a LNAV/CRS properly. > The aircraft ends up on the correct heading, but with no correction, > ie parallel to predicted path and not correcting. The values in the > PID are completely different to other observed aircraft, so am unsure > what the problem is atmo. > > Also this warning message is output below, not sure when it starts but > its goes on forever > Warning: State::drawQuads(0, 58464) too large handle in remapping to > ushort > glDrawElements. > Warning: State::drawQuads(0, 58468) too large handle in remapping to > ushort > glDrawElements. > Warning: State::drawQuads(0, 58468) too large handle in remapping to > ushort > glDrawElements. > Warning: State::drawQuads(0, 58468) too large handle in remapping to > ushort glDrawElements. > regards > pete > > > -- > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > > > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot: NAV/Localiser
On Tue, Jan 26, 2010 at 2:36 AM, syd adams wrote: > > It works, but the behaviour is unexpected, or I got it wrong about VOR >> navigation. >> > > Sounds like it could be a faulty config file ,,, but the proper way to do a > VOR navigation is : > Set your (VOR/LOC) frequency set your desired course / radial. > Set your heading bug to intercept the course ... most autopilots ive been > studying go into heading hold automatically if your outside the capture > range ... then NAV engages when your in range of the course (not the > station). > I would say be a little careful about what config file you use as an example. There is some slightly goofy stuff that has crept into some autopilots over the years. There are some stages that could easily be "P" only, but are written as PID which leads to more hunting and oscillations or long term errors than otherwise would be necessary. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
J. Holden wrote: > I don't know if we've gone final with everything yet, but if we haven't, > would > it be possible for somebody here to: > * double-check to see if the "mushroom" water-towers still exist under the > town > definition in materials.xml; and, if so, > * remove them. > > As we'll have a lot more areas defined as "town" in the upcoming scenery > build, > and there are far too many water towers per square > land-area-measurement-category) in FG as it is, and it looks tacky. After the > release, I'll try and look at improving the randomly generated scenery. It's been a long time since I (re-)wrote the random object code for OSG, but my recollection is that we use the same random number seed when generating random model placements, to ensure that a building is in the same place on every computer. I suspect that part of the problem with the water-tower may be an artifact of the random number generator, though having one every 300,000 m^2 was also a bit much! However, I've never investigated sufficiently to determine if that is the case. -Stuart -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
Martin Spott wrote: > Hi Erik, > > Erik Hofman wrote: > >> It would also be nice to have some more different small(ish) buildings. > > Feel invited to have a look at the "Models/Residential/" folder, there > you'll find the content of this chapter: > > http://scenemodels.flightgear.org/modelbrowser.php?shared=2 Nice, I've reorganized the town section a bit with this in mind. Thanks! Erik -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
Hi Erik, Erik Hofman wrote: > It would also be nice to have some more different small(ish) buildings. Feel invited to have a look at the "Models/Residential/" folder, there you'll find the content of this chapter: http://scenemodels.flightgear.org/modelbrowser.php?shared=2 Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
J. Holden wrote: > As we'll have a lot more areas defined as "town" in the upcoming scenery > build, and there are far too many water towers per square > land-area-measurement-category) in FG as it is, and it looks tacky. After the > release, I'll try and look at improving the randomly generated scenery. It would also be nice to have some more different small(ish) buildings. Erik -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
On Tuesday 26 January 2010 04:09:15 J. Holden wrote: > I don't know if we've gone final with everything yet, but if we haven't, > would it be possible for somebody here to: * double-check to see if the > "mushroom" water-towers still exist under the town definition in > materials.xml; and, if so, * remove them. > As we'll have a lot more areas defined as "town" in the upcoming scenery > build, and there are far too many water towers per square > land-area-measurement-category) in FG as it is, and it looks tacky. Actually this is something I strongly agree with - I have never seen any part of the world so heavily populated with ugly water towers as every minor village appears to be in FG. They spoil the scenery so much that for years I've made sure the water tower model here is replaced by something more appropriate and less visually offensive (like a church or house). Cheers, AJ -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot: NAV/Localiser
> It works, but the behaviour is unexpected, or I got it wrong about VOR > navigation. > Sounds like it could be a faulty config file ,,, but the proper way to do a VOR navigation is : Set your (VOR/LOC) frequency set your desired course / radial. Set your heading bug to intercept the course ... most autopilots ive been studying go into heading hold automatically if your outside the capture range ... then NAV engages when your in range of the course (not the station). The only way I can describe it is imagine the course as a road and your driving parallel , off the road . you turn on the autopilot and point the car towards the road ... when your close enough to the road the autopilot takes over and pulls you onto the road ... And now I'm off to design an autopilot for my car ;) Cheers -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
