Menu
▾
▴
1 Attachments
#2358 AI Traffic not taking off
Hi,
The problem is that quite often, but not always, AI traffic will taxi to the departure runway but never take off.
After enabling rwy->printdepartureQueue in flightgear/src/ATC/trafficcontrol.cxx (line 988) i can see that a 'ghost' a/c with callsign FG-8075 seems to block the runway:
27.20 [DBUG]:atc FG-8075 3
27.20 [DBUG]:atc 48.6768 9.19912233.261 1257.69
27.21 [DBUG]:atc Currently at leg : 3
27.21 [DBUG]:atc name of previous waypoint : Accellegend
27.21 [DBUG]:atc Currently under control of EDDS-tower
27.21 [DBUG]:atc Departure queue for 07:
27.21 [DBUG]:atc FG-8075 3
27.21 [DBUG]:atc 48.6768 9.19913233.208 1257.69
27.21 [DBUG]:atc Departure queue for 07:
27.21 [DBUG]:atc FG-8075 3
27.21 [DBUG]:atc 48.6768 9.19913233.261 1257.69
27.23 [DBUG]:atc Currently at leg : 3
27.23 [DBUG]:atc name of previous waypoint : Accellegend
The Airport/Runway is EDDS/07 with ~20 AI flights scheduled in ~30sec/1min. intervalls. This is for testing a groundnet i'm working on. But it also happens for a lot less AI flights.
OS: Ubuntu 18.04 LTS
FG: 2020.2.1 compiled using download_and_compile.sh
The full, looong logfile is attached.
Let me know if you need any further information.
Bye, Stefan
Thanks for the detailed report. The trafifc code is unfortunately unmaintained, so these kind of bugs do hang around. We have a short-term plan to start adding automated testing though, and collecting test-cases like this will help with that.
BTW, if you can find /any/ pattern to when the aircraft gets stuck in the departure queue, it would help. I was actually looking at a crash in this code yesterday and the departure queue code is really a bit bad, probably needs a re-write.
As it turned out the ghost aircraft blocking the runway is the UFO that is, as i understand, represented as an AI a/c. I was using the UFO all the time to check the AI traffic flow.
What happens is that the AI a/c representing the UFO (callsign FG-8075) takes a live of itself and often?/always? gets added to the departure queue:
21.27 [DBUG]:atc Checking state 0 for FG-8075
21.27 [DBUG]:atc creating message for FG-8075
21.27 [DBUG]:atc transmitting for: FG-8075Leg = 2
21.30 [DBUG]:atc Currently at leg : 2
21.30 [DBUG]:atc name of previous waypoint : 711
21.30 [DBUG]:atc Currently under control of EDDS-ground
21.30 [DBUG]:atc Checking state 0 for FG-8075
21.30 [DBUG]:atc creating message for FG-8075
21.30 [DBUG]:atc transmitting for: FG-8075Leg = 2
sfr: aRwy departureQueue new callsign: FG-8075
Scheduling FG-8075 for takeoff
21.31 [DBUG]:atc FG-8075 You are number 1 for takeoff
21.31 [DBUG]:atc Position: 747
21.31 [DBUG]:atc Checking state 0 for FG-8075
21.31 [DBUG]:atc creating message for FG-8075
sfr: HoldPosition 21.31 [DBUG]:atc transmitting for: FG-8075Leg = 2
FG-8075
Sometimes it takes off (location/distance changes) and eventually signs off from the tower controller. (ATC/trafficcontrol.cxx). AI traffic flows as intended in this case.
Note that the UFO was hovering in the vicinity of the runway but not changing location.
But sometimes this signOff step doesn't happen and the UFO remains forever in the departure queue.
299.21 [DBUG]:atc Currently at leg : 3
299.21 [DBUG]:atc name of previous waypoint : gear-up
299.21 [DBUG]:atc Currently under control of EDDS-tower
299.21 [DBUG]:atc Departure queue for 07:
299.21 [DBUG]:atc FG-8075 3
299.21 [DBUG]:atc 48.6772 9.198930.333333 1290.5
^LONG ^LAT ^Distance?
On one occasion where the signOff didn't happen i moved the UFO for a certain distance and eventually it signed off from the controller. AI traffic then started to flow as well.
This particular issue might be specific to the usage of the UFO. I don't know/understand why it is added to the departure queue in the first place.
I haven't yet checked if this also happens when using a 'real' aircraft.
Ah there is this 'fake AI' aircraft which represents the user in the ATC system. The details of how it tracks as you fly are a bit confusing. The position in syncxhronized every frame of course, but in terms of the ground/tower controller ATC, it's liely it might 'miss' the UFO, and hence it gets stuck in the departure queue and never signs off,
Again, all of this really needs some proper unit-tests so we can fix it without breaking other cases.
There is currently no way for the user aircraft shadow to sign off from the tower controller. I see two options one automatic as soon as you leave the proximity of the runway or a gui option.
I would be very non-keen on a GUI option, it will be confusing in the extreme. I'd suggest using a distance from the runway check, could be quite generous (2nm or even more so people stay with tower when doing circuits?)
I'll implement a multi level solution. >2nm in line of runway and 0.1 nm when not in line of runway.
Please retest with a nightly
Presumably fixed per [b8d173].
Related
Commit: [b8d173]