Re: [Flightgear-devel] Generic autopilot issues
On Wed, Dec 23, 2009 at 5:25 AM, James Turner wrote: > 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) > Here are a couple questions: I'm testing all of this from within the alphajet. Is there a way to not select a departure runway? When I bring up the dialog box, it's already filled in. Even after takeoff, it's filled in so the departure airport appears to always be added to the route, even if you setup the route and click activate after take off. Also I noticed that my target altitude which I already setup gets reset to something seemingly a bit random and close to the ground when I clicked "Activate". There was a cruise altitude set to 10,000' in the route mgr dialog box, but this seems to be ignored. If there is already a target altitude, would it make sense to leave it alone? What is the current rules for how the target altitude is set? - Allows inserting / deleting waypoints exactly as with the old code - I use > this feature all the time > Ok, my bad, I saw a lot of changes to the dialog box, focused in on what didn't make sense, and didn't pay close enough attention to what was still there. > - 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. > What specifically does "activate" do? After I clicked activate, I still have to type "F6" to turn on route following for the autopilot to follow the route. > (I guess you can see from that list why I'm so surprised!) > I was filing a "bug" report from not-very-fresh-memory so I apologize for any reporting mistakes I made. > 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. Hmmm, I may have been mistaken on that one. I don't see a specific configuration setup for the alphajet either. I swear it used to have one, but maybe I am misremembering that? The "generic" autopilot configuration then in this case is reasonable stable around slow to moderate flight speeds. So to summarize my questions: How do I de-select the departure runway? Or how can I avoid having the departure airport included in the route by default? What does "activate" specifically do? This is a non-intuitive portion of the interface that I do not fully understand. I see that if I press "activate", it inserts the departure and arrival waypoints into the route. If I then clean up the route so it is what I really want, then if I happen to press activate again, it re-inserts the departure and arrival airports into the routes and I have to manually clean up my route again. The answer might be don't press activate twice, but not fully understanding what the button is supposed to
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] Generic autopilot issues
On Tue, 2009-12-22 at 14:10 +, James Turner wrote: > A few things that will certainly help: > - not adding the departure airport if no runway is selected > - not adding the departure airport for an in-air route activation Perhaps a quicker workaround, just set the /autopilot/route-manager/current-wp to a higher value, I think it is better to be consistent with what WPs are always in the route, and so it should always contain a departure/arrival airport. S. -- 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
James, >From what I've read, and like the original, your route manager uses the >airport center point as the destination. What is the reason for selecting a >runway? If the destination point is center-runway of the specified runway, >I'm not sure of the benefit over center-airport. Like you mentioned I would >tend to break off to enter a manual approach. An option to consider : At the moment if I were to choose a runway, my preference would be to have the destination point be the turn-in point for an ils approach, for both ils equipped and non- precision approach equipped airports. (The documentation would need to reflect the difference in points so the user realized it) Just a thought- Peter Sent from Smooth Water Sports, your Malibu Boat Dealer -Original Message- From: James Turner Date: Tue, 22 Dec 2009 14:10:25 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Generic autopilot issues On 21 Dec 2009, at 18:55, Curtis Olson wrote: > What do you think would be a sensible course of action, in the situation you > describe? Even if I choose not to add the departure airport for in-air route > activation, there's no guarantee that the first route waypoint is where you > actually want to be going. > > Conceptually, including the starting point in the route seems like it could > always be problematic.The "airport location" is some random point on the > airport grounds (probably the average of the center points of the runways.) > Even if you haven't taken off yet, it would be possible in some circumstances > to not fly close to the center of the airport on take off. Then you would > get routed back to the starting point before you could continue on to the > next way point. I think we are just getting "lucky" when we fly close enough > to the center of the airport in most situations for most runways to satisfy > the route manager and it clicks on to the next waypoint. The KSFO airport > layout is very friendly in this regards, but other airports like DFW and DEN > are more sprawling. That's really an orthogonal issue - I only use the airport location if you neglect to specify a runway. For using these features as a flight planning tool, the first waypoint is my departure runway, which sequences when you cross the threshold / midpoint (not perfectly, I have a known bug to fix in that area). Adding the *destination* airport as a waypt seems useful, even if no runway is selected, because it yields a useful trip distance estimate (and hence, ETA), and I assume people can thus navigate to the vicinity of their destination, and conduct whatever kind of approach they like. A few things that will certainly help: - not adding the departure airport if no runway is selected - not adding the departure airport for an in-air route activation I'll do these today (hopefully) - I already fixed the GPS -> autopilot drive, and have been doing some reading and testing with the generic autopilot XML, dialog and code. There's quite a few things behaving strangely (especially in the Alphajet), and I don't think most of them are my fault - famous last words! - but I'm getting to grips with it. Will post back here once I have some more definite conclusions, especially regarding why heading hold is being so strange. Incidentally, the PID parameters in the generic autopilot are pretty bad for the alphajet (and many other aircraft, I guess). It'd be lovely if there was a way to tune the response rates for a particular aircraft, but still inherit the basic controller structure (i.e the control laws) from the generic definition. I don't suppose the Autopilot XML loading code could cope with that? 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 -- 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 Tue, Dec 22, 2009 at 8:10 AM, James Turner wrote: > What do you think would be a sensible course of action, in the situation > you describe? Even if I choose not to add the departure airport for in-air > route activation, there's no guarantee that the first route waypoint is > where you actually want to be going. > 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. > That's really an orthogonal issue - I only use the airport location if you > neglect to specify a runway. Ok, for the original route manager when you specified an airport as a waypoint, you got this computed center point (average or runway center points.) > For using these features as a flight planning tool, the first waypoint is > my departure runway, which sequences when you cross the threshold / midpoint > (not perfectly, I have a known bug to fix in that area). Adding the > *destination* airport as a waypt seems useful, even if no runway is > selected, because it yields a useful trip distance estimate (and hence, > ETA), and I assume people can thus navigate to the vicinity of their > destination, and conduct whatever kind of approach they like. > Right ... I've always flown with the mindset of the route manager getting me to the airport and then at some point I'll break off the route and setup the approach to my own chosen runway and land manually. > A few things that will certainly help: > - not adding the departure airport if no runway is selected > - not adding the departure airport for an in-air route activation > > I'll do these today (hopefully) - I already fixed the GPS -> autopilot > drive, and have been doing some reading and testing with the generic > autopilot XML, dialog and code. There's quite a few things behaving > strangely (especially in the Alphajet), and I don't think most of them are > my fault - famous last words! - but I'm getting to grips with it. > > Will post back here once I have some more definite conclusions, especially > regarding why heading hold is being so strange. > > Incidentally, the PID parameters in the generic autopilot are pretty bad > for the alphajet (and many other aircraft, I guess). It'd be lovely if there > was a way to tune the response rates for a particular aircraft, but still > inherit the basic controller structure (i.e the control laws) from the > generic definition. I don't suppose the Autopilot XML loading code could > cope with that? > 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. One thing to note is that many YASim jet aircraft can be over speeded at lower altitudes and if you do that, you can get really weird negative stall type effects ... especially if you have flaps deployed. This has always been a gripe of mine with the YAsim flight dynamics engine. Generic autopilots are difficult. Different aircraft have wildly different systems and capabilities. Different types of sensors, actuators, etc. A generic autopilot would be about as realistic as our original route manager. :-) And then stuffing in about 50-60 tunable parameters into a generic structure also sounds pretty messy. I've always preferred the autopilot to be defined on a per-aircraft basis, and if the aircraft author wants to copy a config file from another similar aircraft as a starting point, that's fine. 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 su
Re: [Flightgear-devel] Generic autopilot issues
On 21 Dec 2009, at 18:55, Curtis Olson wrote: > What do you think would be a sensible course of action, in the situation you > describe? Even if I choose not to add the departure airport for in-air route > activation, there's no guarantee that the first route waypoint is where you > actually want to be going. > > Conceptually, including the starting point in the route seems like it could > always be problematic.The "airport location" is some random point on the > airport grounds (probably the average of the center points of the runways.) > Even if you haven't taken off yet, it would be possible in some circumstances > to not fly close to the center of the airport on take off. Then you would > get routed back to the starting point before you could continue on to the > next way point. I think we are just getting "lucky" when we fly close enough > to the center of the airport in most situations for most runways to satisfy > the route manager and it clicks on to the next waypoint. The KSFO airport > layout is very friendly in this regards, but other airports like DFW and DEN > are more sprawling. That's really an orthogonal issue - I only use the airport location if you neglect to specify a runway. For using these features as a flight planning tool, the first waypoint is my departure runway, which sequences when you cross the threshold / midpoint (not perfectly, I have a known bug to fix in that area). Adding the *destination* airport as a waypt seems useful, even if no runway is selected, because it yields a useful trip distance estimate (and hence, ETA), and I assume people can thus navigate to the vicinity of their destination, and conduct whatever kind of approach they like. A few things that will certainly help: - not adding the departure airport if no runway is selected - not adding the departure airport for an in-air route activation I'll do these today (hopefully) - I already fixed the GPS -> autopilot drive, and have been doing some reading and testing with the generic autopilot XML, dialog and code. There's quite a few things behaving strangely (especially in the Alphajet), and I don't think most of them are my fault - famous last words! - but I'm getting to grips with it. Will post back here once I have some more definite conclusions, especially regarding why heading hold is being so strange. Incidentally, the PID parameters in the generic autopilot are pretty bad for the alphajet (and many other aircraft, I guess). It'd be lovely if there was a way to tune the response rates for a particular aircraft, but still inherit the basic controller structure (i.e the control laws) from the generic definition. I don't suppose the Autopilot XML loading code could cope with that? 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
