Board index FlightGear Development Aircraft Autopilot and route manager

FIX 717 AND A320 AUTOPILOTS!!!

Designing a stable autopilot is one of the hardest things. Need help?

FIX 717 AND A320 AUTOPILOTS!!!

Postby Captain LaForest » Sun Sep 27, 2015 5:56 pm

Ok I have one BIG complaint about two of my favorite airliners. I hate how in either the Boeing 717 or the A320 autopilot performs when turning at a waypoint. For example,in both the 717 and the A320, the airplane will reach a waypoint, and the waypoint is suppossed to just turn the aircraft to the right, but instead it will start to turn left and then quickly turn in the right direction. This isn't the only bug with the autopilots, and I hope someone can fix this problem. Thanks!
Captain LaForest
 
Posts: 37
Joined: Tue Jun 02, 2015 6:35 pm
OS: Windows 8.1

Re: FIX 717 AND A320 AUTOPILOTS!!!

Postby CaptB » Sun Sep 27, 2015 7:27 pm

Around here, the best way to have something fixed is to "Just do it!" ;)
Ongoing projects(3D modelling): A320, MD-11, A350, B767
FG767: https://fg767.wordpress.com/
CaptB
 
Posts: 685
Joined: Thu May 23, 2013 7:36 pm
Callsign: EKCH_AP
IRC name: CaptB
Version: next
OS: Xubuntu

Re: FIX 717 AND A320 AUTOPILOTS!!!

Postby sanhozay » Sun Sep 27, 2015 8:10 pm

The problem is that the switching of leg happens close to the waypoint. Just before the switch, the aircraft can end up homing aggressively to the waypoint before adjusting the heading to the next leg. This is why you get the left/right or right/left wiggle at the transition. One solution is to switch early, ideally calculating the time to switch based on the predicted turn radius so there is a smooth arc to the next leg.

Ideally this would be done in the C++ code that drives the route manager, or using property rules in the autopilot. It is possible to do it in Nasal, and I have a script that does so, but I was told, rightly so, that a general Nasal sclution would not be accepted into FGDATA because of garbage collection issues with Nasal running so intensively. Many aircraft do it this way, however.

If you want to try it, let me know and I'll set out the steps, subject to the paragraph above. This would be for a change to your private copy only.
sanhozay
 
Posts: 1207
Joined: Thu Dec 26, 2013 12:57 pm
Location: EGNM
Callsign: G-SHOZ
Version: Git
OS: Ubuntu 16.04

Re: FIX 717 AND A320 AUTOPILOTS!!!

Postby legoboyvdlp » Sun Sep 27, 2015 8:42 pm

Captain, is the bug in the A320neo? That A320-family is good enough -- but it is awful compared to the neo.
Try www.github.com/FGMEMBERS/A320neo/ (just because I do not know where else it is kept, so don't start yelling curt/thorsten/hooray/whoever)
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: FIX 717 AND A320 AUTOPILOTS!!!

Postby skyop » Sun Sep 27, 2015 8:59 pm

I developed both autopilots. They haven't been touched since (except for one or two emergency fixes) and are in need of modernization.
Aircraft: [ CRJ700-family | DC-10-30 ] Scenery: [ KBFL ]
skyop
 
Posts: 3040
Joined: Mon Jun 14, 2010 1:40 am
Location: Austin, Texas, USA
IRC name: skyop
Version: next
OS: Fedora 23/Windows 10

Re: FIX 717 AND A320 AUTOPILOTS!!!

Postby bugman » Sun Sep 27, 2015 9:02 pm

Hi Legoboy,

If you follow that link, you'll see that Israel documents his sources and provides this original link for the Omega hangar:


Omega has a MediaFire link there for version 4 of the Airbus A320neo Series (319, 320 and 321), to download the zip file. The gitorious link is currently dead, but should appear on the Internet Archive in the future.

Regards,

Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: FIX 717 AND A320 AUTOPILOTS!!!

Postby legoboyvdlp » Sun Sep 27, 2015 9:05 pm

@bugman, correct, although artix has improved on omegas, and currently works in a GPL fork of the omegahangar plane, which omega amde GPL (with an email to prove it). So, the FGMEMBERS plane is a fork of artixs, with his updates, besides others by CaptB (?). I have no other location for the IMPROVED version.
Regards,
Jonathan
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: FIX 717 AND A320 AUTOPILOTS!!!

Postby bugman » Sun Sep 27, 2015 9:22 pm

Well, if it's the Artix version, then that's also pretty simple. The original source is:


Regards,

Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: FIX 717 AND A320 AUTOPILOTS!!!

Postby legoboyvdlp » Sun Sep 27, 2015 9:47 pm

bugman wrote in Sun Sep 27, 2015 9:22 pm:Well, if it's the Artix version, then that's also pretty simple. The original source is:


Regards,

Edward


Although the FGMEMBERS one DOES have some updates, that one is indeed artixs own repository.
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: FIX 717 AND A320 AUTOPILOTS!!!

Postby bugman » Sun Sep 27, 2015 9:57 pm

legoboyvdlp wrote in Sun Sep 27, 2015 9:05 pm:...which omega amde GPL (with an email to prove it)...


One very important point here - a private email is generally considered insufficient for copyright licensing in the open source world. The normal expected standard is a publicly archived message written by the original author who owns the copyright. Private mails can be lost, or the recipients may disappear from the project in the future. So for the future protection of the FlightGear community, a permanently archived statement that is accessible to all is the gold standard (emails to a public mailing list being the safest traceable option).

Regards,

Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: FIX 717 AND A320 AUTOPILOTS!!!

Postby legoboyvdlp » Sun Sep 27, 2015 10:05 pm

bugman wrote in Sun Sep 27, 2015 9:57 pm:
legoboyvdlp wrote in Sun Sep 27, 2015 9:05 pm:...which omega amde GPL (with an email to prove it)...


One very important point here - a private email is generally considered insufficient for copyright licensing in the open source world. The normal expected standard is a publicly archived message written by the original author who owns the copyright. Private mails can be lost, or the recipients may disappear from the project in the future. So for the future protection of the FlightGear community, a permanently archived statement that is accessible to all is the gold standard (emails to a public mailing list being the safest traceable option).

Regards,

Edward


See
viewtopic.php?f=4&t=26400&hilit=Omega+GPL#p244825
Would it suffice?
:)
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: FIX 717 AND A320 AUTOPILOTS!!!

Postby bugman » Sun Sep 27, 2015 10:35 pm



Unfortunately not. It's a remote image at https://i.imgur.com/LTSoIGm.jpg, so it is not part of the archived FlightGear infrastructure. Such things disappear with time (look at old forum threads to see this). Also, such a screenshot is not really traceable. On the other hand, an archived email to a mailing list is very traceable as it has a highly detailed header with routing information which is stored in the backed up mbox email archive. That's why an email will often be asked for.

Regards,

Edward

Edit: I strongly recommend that this not be used as a justification to port Naru (omega95)'s changes into FGAddon!
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: FIX 717 AND A320 AUTOPILOTS!!!

Postby legoboyvdlp » Sun Sep 27, 2015 11:11 pm

Hmm, then probably a Facebook post would not suffice..
It is actually a closed group, so you need to log in and ask to join. So, maybe we should send him an email for official permission!
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: FIX 717 AND A320 AUTOPILOTS!!!

Postby daweed » Mon Sep 28, 2015 8:59 am

You should not insist legoboyvdlp, problems that you have recently met should make you think a little ...

As Artix will not be clear here that work is open and free ... it should not be done in reference to another repository that of the author (here for the latest version of Artix) even if there is indeed the new features and improvements in the one found in the filing that angry all the world ...

The only deposit you should therefore indicated that indicates that bugman

https://github.com/artix75/A320neo
Windows 10 / Linux Mint 20
AMD Ryzen 7 3700X |32 Go RAM GeForce RTX 3070 Ti 8 Go
FG Interface
Lyon Saint Exupery Scenery

ATC on LFLL on Friday 19:00 UTC => 22:00 UTC
daweed
 
Posts: 398
Joined: Thu Dec 11, 2014 11:45 am
Location: LFKP LFLL
Callsign: daweed
OS: Linux Mint 20

Re: FIX 717 AND A320 AUTOPILOTS!!!

Postby clrCoda » Tue Sep 29, 2015 9:10 pm

Years ago, when I had the original posters problem closing in on a waypoint I used to reach up into the autopilot menu and pop the way point early.

As time progressed, eventually I talked epilot into implementing an early waypop for the 733-classic.

When he finished his custom version, I stripped it down for generic autopilots and have tested it on a few planes. The DHC8-400q by maverickalex Park shared at global has it. DrDavid and myself have it installed on the Tecnum P2006T, on our private copies, and I put it on the Global version of the MD-81, to name a few planes.

For planes with a generic autopilot I tend to copy the generic autopilot in data/Aircraft/Generic and move it into the plane in question because I am adding a filter to that file that is a part of a chronometer by e-pilot that is used to calculate the time to the next waypoint.

e-pilot wrote another file called popway.nas which sets the listener that checks to see if we are with-in 2 tenths of a minute ( or 12 seconds) from the next waypoint in which case it pops the waypoint to the next one.

This 12 seconds is enough to keep the plane from turning into the waypoint as the plane passes it.

A line of code added to -set.xml in the nasal tag section connects everything together. Another line in -set.xml points to the autopilot.xml that was copied into the plane from generic and had the chronometer filter added.

Here's the chronometer filter that gets added to a copy of generic autopilot and moved into the plane.
Code: Select all
  <!-- These filters create internal variables for the Instrument Panel Chronometer -->
  <filter>
    <name>ETE-DRIVER:Hour</name>
    <debug>false</debug>
    <type>gain</type>
    <gain>1</gain>
    <input>
      <expression>
   <div>
     <property>/autopilot/route-manager/wp/dist</property>
     <property>/velocities/groundspeed-kt</property>
   </div>
      </expression>
    </input>
    <output>
      <prop>/autopilot/internal/eta-wp-hr</prop>
    </output>
  </filter>
  <filter>
    <name>ETE-DRIVER:Minute</name>
    <debug>false</debug>
    <type>gain</type>
    <gain>1</gain>
    <input>
      <expression>
   <mod>
     <product>
       <div>
         <property>/autopilot/route-manager/wp/dist</property>
         <property>/velocities/groundspeed-kt</property>
       </div>
       <value>60</value>
     </product>
     <value>60</value>
   </mod>
      </expression>
    </input>
    <output>
      <prop>/autopilot/internal/eta-wp-min</prop>
    </output>
  </filter>


That just gets copy/paste into autopilot.xml just above the ending </PropertyList> tag of autopilot.xml. If the plane has a copy of the generic autopilot with it ( uses the generic autopilot dialog is a good hint, not custom autopilot, other work has to go into this to accomodate custom autopilots to get this to work, please see 737-300CHT for instance ) ... with it then usually this filter can be installed into that autopilot.

If we have used a copy of the generic autopilot for this then that file should go into the planes systems folder and then we make sure to point to that proper autopilot.xml. Typically the path looks like this:
Code: Select all
    <systems>
        <electrical>
            <path></path>
        </electrical>
        <autopilot>
            <path>Aircraft/dhc8-400/Systems/autopilot.xml</path>
        </autopilot>
    </systems>


You need a copy of popway.nas so copy paste this and call it popway.nas and put it in your planes nasal folder:
Code: Select all
var popway = func {

# Next Waypoint
    if (getprop("autopilot/internal/eta-wp-hr") < 1) {
        if (getprop("autopilot/internal/eta-wp-min") < .2) {
            
        var curwp = getprop("autopilot/route-manager/current-wp");
        var nextwp = curwp + 1;
        setprop("autopilot/route-manager/current-wp", nextwp);
        }
    }
}
setlistener("/autopilot/route-manager/flight-time", popway, 0, 0);



and then add the tags to the -set.xml...



Code: Select all
      <popway>
         <file>Aircraft/dhc8-400/Nasal/popway.nas</file>
      </popway>
   </nasal>

I added the file to the nasal section of the plane just before the </nasal> tag and put the file ref under new <popway></popway> tags in the -set.xml file of the plane.

This makes route flying much much more stable.

Thanks
Ray
Ray St. Marie
clrCoda
 
Posts: 1225
Joined: Wed Apr 07, 2010 12:04 pm

Next

Return to Autopilot and route manager

Who is online

Users browsing this forum: No registered users and 0 guests