Re: [Flightgear-devel] auto-coordination broken
-- From: leee l...@spatial.plus.com Sent: Tuesday, December 22, 2009 10:05 PM To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] auto-coordination broken On Tuesday 22 Dec 2009, Alan Teeder wrote: [snip...] The Ercoupe and certain other aircraft (e.g. TSR2) may have an aileron-rudder interconnect, but this is very aircraft specific and should be part of the aircraft FCS model. The YASim BAC-TSR2 doesn't/didn't/shouldn't have an aileron-rudder interconnect. Sorry, I should have been clearer. I was referring to the real aircraft, not your YASim model. It was needed to counteract the yaw due to the tailerons. Alan -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generic autopilot issues
On 22 Dec 2009, at 14:51, Curtis Olson wrote: With the old route manager, the first way point is where I want to go for my first destination, because I just put it in there with that specific goal in mind. The 2nd waypoint is also where I want my second destination to be, again, because I just put it there. Same for all the other way points. Another nice feature we used to have in the original route manager was the ability to insert and delete waypoints from the middle of the route, allow us to update and change the route in mid-flight if we changed or mind (or something like weather changed it for us.) What I liked about the old route manager is I could decide I want to fly to A then B then C then D, I added those waypoints and off I go. I feel like I have to fight the new system to get it to do something like that, and then every time I open up the dialog box, I'm never sure if it's going to change the route on me or add the original airport back in again (even if it might already be there.) I haven't tried using the route manager in a few weeks now, so perhaps some of these things were bugs that are now resolved. I think there was a simplicity and a determinism in the original system (as unrealistic as that was) and I struggle with the new system trying to understand how to get it to work and not make unexpected changes or additions to the route. I'm surprised by this - partly because it doesn't fit with my intentions, or what I experience using the code daily here, but also because if the system is behaving as badly as you suggest, why haven't you (or other people) made more of an issue of it, here? There were some initial issues right after the commit at the start of October, and I thought I'd resolved those to people's satisfaction, and that the code was working fine for people who use it. To find out now, that that's not the case, is unfortunate. To be clear, the current code: - adds the departure / destination runways if specified, otherwise the corresponding airports, if specified, ONLY when you click 'activate'. That is the *only* time it modifies the waypoint list, and I'm happy to limit that behaviour further if it's really causing problems for people. (I am considering splitting the flight-planning functionality into a separate, new dialog, which uses the same waypoints, but enforces my stricter requirements as regards flight-plans) - Allows inserting / deleting waypoints exactly as with the old code - I use this feature all the time - Allows waypoints to be entered A/B/C/D as you suggest, hit activate, and you should be done. The only additional step is hitting 'activate', and the code is supposed to be completely deterministic. (I guess you can see from that list why I'm so surprised!) Fundamentally, the new code's public API is almost unchanged - there's some (big) structural changes, and new features, but I am quite dismayed that it would be described as complex or non-deterministic - especially when that's at odds with what I see. Of course my expectations are different to other people's, since I wrote the code. As ever, I'd be happiest if people would file bug-report type emails, that gave a precise series of steps, expected results, and actual results. (Obviously the 'activate-adds-departure-and-destination-waypoints' thing is causing some issues, but I find it hard to ascribe all the problems you mention to that one thing ... especially since it's been discussed before, and is documented in the wiki pages for the route manager) The alphajet has it's own autopilot configuration. I wouldn't characterize it as generic since it is specific for this aircraft. Perhaps some of the gains could be tweaked, but it behaves pretty well for me. That's not what I'm seeing in CVS data - thought it would explain why I became so confused in trying to test the Alphajet autopilot yesterday. If there's a non generic autopilot config for the Alphajet, where is it? I've just looked through the Aircraft/Alphajet dir, and don't see an autopilot .XML file. Regards, James -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
Hi, With the aircraft I test with, that's what I see - the C172, the Seneca, the B1900 and, to a lesser degree, the 777-200 (though it has some other problems). I guess the problem may be, that all of those aircraft have quite well developed, non-generic autopilots. Unfortunately they are only few ones Aside from the GPS setting true-heading-hold when it shouldn't, what problems are people seeing with heading-hold and nav1-hold? Please let me know the specific aircraft, steps to reproduce, expected behaviour and actual behaviour. I will assume people are testing with latest data/ and FG/SG sources. Regards, James I can't use the latest data and sources, but just as compare and help: 737-300 (Using the autopilot.panel via F11)- in 19.1 the 737-300 was the airliner with the best autopilot behavior recommended for ILS-approaches done by ap. with my last built from 11/27/2009 the aircraft didn't responded anymore on NAV1-Hold and GS. Cheers HHS P.S.:I'm beware of that the actually 737-300 needs a own written flightdirector like the Citation Bravo and other aircrafts from Syd has to be real - but how to write one? __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Committing conditional compile patch for ATCDCL
On Wed, Dec 23, 2009 at 1:53 AM, Durk Talsma d.tal...@xs4all.nl wrote: Hi All, As we've discussed before, I'm working on merging the old ATC/AI code from David Luff (ATCDCL) with our AIModels system. As part of the rewrite, I have added a new --disable-atcdcl option to my configure script. The default behavior is that ATCDCL will be enabled. Disabling the build of this library currently results in a broken compile, because the alternate code isn't ready yet. Since the default behavior doesn't really affect the compile process, I'm wondering whether there would be any objections to committing it to CVS. I'm asking, because I recently saw some patches being applied to ATCDCL, and I don't want my development tree to get out of sync too much. I don't see any obvious negative side effects, but this seems to my a case of better being safe than sorry. :-) Probably the biggest thing to worry about is if you introduce a new #define is the folks doing windows builds. Configure takes care of keeping everything consistent for unix builds, but depending on how this is done it could cause weird breakage for windows builds if the developers aren't aware they need to add a new define to their build environment. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination broken
On Wednesday 23 Dec 2009, Alan Teeder wrote: -- From: leee l...@spatial.plus.com Sent: Tuesday, December 22, 2009 10:05 PM To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] auto-coordination broken On Tuesday 22 Dec 2009, Alan Teeder wrote: [snip...] The Ercoupe and certain other aircraft (e.g. TSR2) may have an aileron-rudder interconnect, but this is very aircraft specific and should be part of the aircraft FCS model. The YASim BAC-TSR2 doesn't/didn't/shouldn't have an aileron-rudder interconnect. Sorry, I should have been clearer. I was referring to the real aircraft, not your YASim model. It was needed to counteract the yaw due to the tailerons. Alan Aha - thanks. I didn't know that. LeeE -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
On 23 Dec 2009, at 11:42, Heiko Schulz wrote: 737-300 (Using the autopilot.panel via F11)- in 19.1 the 737-300 was the airliner with the best autopilot behavior recommended for ILS-approaches done by ap. with my last built from 11/27/2009 the aircraft didn't responded anymore on NAV1-Hold and GS. Okay, that's a useful data point, I'll take a look at that in the next few days (in between eating too much...). I assume all interactions with the system are occurring through the radios and autopilot *dialogs* (F12 and F11), not the cockpit panel? These are the kind of things that people don't mention, but make a big difference in testing. Do other autopilot modes work? Do the VNAV modes work, aside from NAV1-GS hold? P.S.:I'm beware of that the actually 737-300 needs a own written flightdirector like the Citation Bravo and other aircrafts from Syd has to be real - but how to write one? Take a look at Syd's scripts? The core flightdirector.nas scripts are pretty clear, though as always I wish less copying of files into each aircraft went on. If you want help understanding what the scripts do, and how they are structured, I'm happy to (try to) help. (Actually I think the scripts could be simplified quite a bit, but Syd may disagree - he knows better than me!) The flight-drector issue is complicated because the generic autopilot doesn't provide anything in this area. I have briefly wondered about writing a C++ generic flight director, but I don't think it's a good idea - people who want an accurate flight-drector for a real aircraft will find it much easier to write a specific one in Nasal (to go with a custom autopilot) than try to work with a generic C++ one, I think. I'd also be happy to start collecting an 'autopilot internals' wiki page, to collect information about this kind of thing in a proper place, and to go alongside my existing route-manager and GPS/FMS internals documents. Regards, James -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Some bugs
Passing along some random information in case anyone recognizes the issues. In a CVS from 12/13 - -all starts show a spawn location off the coast of Nigeria, quite often with a different call sign, and the google we don't have imagery for zoom at this level default. If you zoom out you find the location, and then the a/c symbol disappears. If you refresh the browser your call sign will show up in the correct location. This happens every time, without fail. Once refreshed it works fine. -the sound is fine in the cockpit and a few views, but from the tower viewpoint (listen to a flyby) and from the model viewpoint (I think there are 3 actually), the sound is corrupted. While I don't know why, what I did discover was if you moved your location one step in any direction (up or down, left or right), the sound returned to normal. This is one step from the default viewpoint, such as tower, model, fly-by, etc. -the route manager sometimes will open with 36000 feet in the hold altitude box, and 7240 kts in the hold speed box. Any attempt to change them will default back to these amounts. I am trying to see if relates to any particular aircraft, but to date it's been pretty random. Hope that helps - Peter -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
