Azorean Groundnets with FGAirports

[AzulProfundo]

Hi Folks,

I have decided to do this "wider" post, giving that to test a minimum set of traffic, I will have to edit no less than four airports in the Azores. Just to complete two circuits starting and ending in LPPD Ponta Delgada (the local hub). I have created a small traffic file for SATA Air Azores, with just those flights, covering LPPD, LPFL Flores, LPLA Lajes and LPHR Horta.

There are discrepancies between the existing apt.dat and the scenery in Terrasync, at least in LPFL and LPHR. The ones where I started to work in FGAirports.

The pictures below show the situation for LPHR Horta (Island of Faial).

1. Current TerraSync scenery, using parking in the custom groundnet file (user in DHC6; AI is the Dash8)


2. Official airfield parking chart


3. LPHR groundnet currently in FGAirports and custom folder


As with LPFL Flores, I am ignoring the outdated taxiways in the apt.dat and following the OSM map background. It almost agrees with the TerraSync scenery, although there is a small deviation in position.

Furthermore, the checks are complaining about "two many taxiway routes for each pushback node", the rest being OK. Looking at the layout, I do not understand where is the problem.
Flightgear reads the traffic file and puts the AI plane in one parking, and starts the taxing at the correct time, but then the plane just follows in a straight line to the runway end and disappears (crashes?)

I will still do a similar test in Flores, to see if there the AI traffic has a better fate...

FGAirports has been working great and even shows the flights departing and arriving to the airport. Just don't know what the button "Generate Testtraffic" is doing.

[portreekid]

Glad you like FGA

Furthermore, the checks are complaining about "two many taxiway routes for each pushback node", the rest being OK. Looking at the layout, I do not understand where is the problem.

https://wiki.flightgear.org/AI_Traffic#Refining_the_network:_Pushback_routes

The Pushback point must be an dead end.

The generate Testtraffic will/should generate a file with lots of flights to saturate the airport with departing flights. It's not quite there yet.

[AzulProfundo]

Well, I definitely have to correct my pushback routes! Apart from that, also it is said that the last segment must have the same direction as the parking...

In LPFL, the AI traffic correctly lands and goes do the parking position, but when is departing, makes a full circle. And when reaches the runway, instead of going to the threshold, accelerates right away and lifts off!!? I will redo both groundnets and do new tests on the AI, and post here the (hopefully) better results.

[portreekid]

Where exactly does the loop happen? I am in the process of fixing these loops. The current AI code has three bugs

1. If the first segment from a push forward parking is too short it will loop
2. A push forward will always take the leaving route with the lowest ID. Use a one way for entry!
3. Sharp corners can cause problems.

All these can be avoided in the ground net.

[BecOzIcan]

when reaches the runway, instead of going to the threshold, accelerates right away and lifts off!!

See "Backtracking" in the wiki

Backtracking: Certain airports do not have taxiways along the runway and aircrafts will 'backtrack' on the runway itself to reach the threshold (often circling on a turnaround area to align for take off). In this scenario, you still need a route to guide your aircraft all the way to the take off node by placing nodes and segments on the runway and the the turnaround loop area. Make sure your loop starts (exits the runway) ahead of passing the final take off node: see an example HERE : https://wiki.flightgear.org/File:Using_ ... eshold.jpg

Ian

[portreekid]

when reaches the runway, instead of going to the threshold, accelerates right away and lifts off!!

See "Backtracking" in the wiki

Backtracking: Certain airports do not have taxiways along the runway and aircrafts will 'backtrack' on the runway itself to reach the threshold (often circling on a turnaround area to align for take off). In this scenario, you still need a route to guide your aircraft all the way to the take off node by placing nodes and segments on the runway and the the turnaround loop area. Make sure your loop starts (exits the runway) ahead of passing the final take off node: see an example HERE : https://wiki.flightgear.org/File:Using_ ... eshold.jpg

While testing I found out this also seems to happens when the available runway list is empty. Is there a RWYUSE file?

[BecOzIcan]

While testing I found out this also seems to happens when the available runway list is empty. Is there a RWYUSE file?

Confused. Runways should be defined in the APT file, what do you refer to as "available runway list" ?

The RWYUSE file is only here to assign priorities where, for a given wind direction/condition, more than one threshold could be used (Multiple runways available) . In fact I never used a RWYUSE on a single runway airport because, in essence for a given wind direction, only one of the thresholds is optimum, if it makes sense.

Or am I getting your message wrong?

Cheers
Ian

[portreekid]

Ah sorry. Too much context inside my brain and too little outside.

bool FGAIFlightPlan::createTakeOff()

seems to be the culprit. I also have a flight that taxies to the runway and takes off without doing a nice roll.

[code ]
// Get the current active runway, based on code from David Luff
// This should actually be unified and extended to include
// Preferential runway use schema's
// NOTE: DT (2009-01-18: IIRC, this is currently already the case,
// because the getActive runway function takes care of that.
if (firstFlight) {
const string& rwyClass = getRunwayClassFromTrafficType(fltType);
double heading = ac->getTrafficRef()->getCourse();
apt->getDynamics()->getActiveRunway(rwyClass, 1, activeRunway,
heading);
}
[/code]

This will be the problem in my case since it's the second flight. It's actually a YBBN -> YSSY -> YBBN flight and it taxies to 16L and leaves directly from the threshold. Active runway will still be 19 and that doesn't exist.


P.S. I'm slowly getting there

[BecOzIcan]

Hmm. There is a RWYUSE file for Sydney but it is quite broken (will have a look over the weekend) : it instruct all traffic to depart from and arrive at 16R.

[portreekid]

Why does the "ga" flight taxi to 16L then? Hmm

[AzulProfundo]

I had indeed a problem with missing backtracks on both runways. Neither Flores nor Horta have parallel taxiways like larger airports. When I added those to the groundnets, the problem of AI planes taking off straight away disappeared. Now the problem that remains is the pushback loops, but could well be due to the short segments, because the parking areas are rather small.

And there is another issue, but this time has nothing to do with FGAirports. What is happening is that when a plane reaches the farthest segment in a circuit, its flight number changes. The plane should be the same, and now has to return to the hub. But the Traffic Manager creates a new plane instead! So, you can imagine there is a problem in Flores, with just one parking spot.

Just to give one example (omitting the week day and time):

Flight SP564: LPPD - LPLA - LPHR - LPFL /Plane: DH4, CS-TRE
Flight SP565: LPFL - LPHR - LPLA - LPPD / Plane: DH4, CS-TRE; the same, but Traffic Manager designates CS-TRD, and there are excess planes in the circuit!!

If you know what to do in the traffic file, there will be one problem less.

[BecOzIcan]

Flight SP564: LPPD - LPLA - LPHR - LPFL /Plane: DH4, CS-TRE
Flight SP565: LPFL - LPHR - LPLA - LPPD / Plane: DH4, CS-TRE; the same, but Traffic Manager designates CS-TRD, and there are excess planes in the circuit!!

If you know what to do in the traffic file, there will be one problem less.

Yes the root cause is likely to be the traffic file. I cannot troubleshoot further as I cannot find any SATA (SAT) or Azores Airlines (RZO) traffic file in FG Next. If you are running your own traffic refer to the AI wiki page or provide a link to the file.

Cheers
Ian

[AzulProfundo]

Dear BecOzlcan,
This is a small traffic file I created just for testing the groundnets. In fact, there is none in the FlightGear folder, at least for flights among the islands.

So, I provide here a link (don't know if there are problems accessing google drive) to an editable version of the file:
https://drive.google.com/file/d/16JA3pvTIh082-pcrgLzQFX1tCdK4wiGJ/view?usp=sharing

I had to use linux commands chown and chmod to put a working copy it in the flightgear folder (user is root), but probably you already know that.

[BecOzIcan]

Dear BecOzlcan,
This is a small traffic file I created just for testing the groundnets.

I ll have a look and let you know.

Cheers
Ian

[BecOzIcan]

Reviewed and nothing you can do about it.

The issue comes from the discrepancy between your schedule and the way traffic manager handles aircrafts. In short, since V2, TM no longer associate a particular aircraft to a particular flight number but allocate aircrafts, from its stock of available ones to each of the flights to be operated until running out of available aircrafts.

At 11h10, in Flores your first DH4 lands and parks. Transponder goes off. flight SP564 is complete.

At 11h35 SP565 is scheduled to depart. Your second aircraft is still in Ponta Delgada where it won't be used before 12h55. TM will grab this aircraft (so to maximize the fleet usage) and place it in Flores, to operate SP565.

I would then expect that at 13h55 when a DH4 will be needed to operate SP544 from Ponte Delgada to Lajes, your first aircraft (which is no longer in use and is the only DH4 not currently operating a flight) will vanish from Flores and appear in Ponte Delgada.

Yes, I know, it would make more sense to grab the first aircraft which is also technically available at 11:35 to operate SP565 but .... TM is trying to replicate the real world and mimimize all aircrafts time on the ground, obviously it fails if, like in your test case, your aircrafts stay parked for a full week.

You could work around the problem by assigning DP544 and SP545 to the DH3 aircraft you also have declared in the file, and remove your second DH4. TM would not be able to assign the DH3 to SP565 and I would expect it would then reuse the DH4 sitting in Flores.


Hope this makes some sense

Cheers
Ian