The forum thread is a bit hard to understand all the issues, can you summarise it here? Is it /all left turns/ on the ground? And they seem to work a bit? But slowly?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's mostly all left turns on the ground following the groundnet, the longer wide turns seem to be ok.
The first half of the first video shows what happens if the AI turn left onto the main taxiway after pushback and the second half shows a right turn onto the taxiway. The right turn operates correctly but the left turn tries to turn right before turning left, this usually results in the AI detaching itself from the groundnet and either attaching to the groundnet elsewhere or taxiing directly to the active runway.
The AI behaviour has been problematic for several years but I had not noticed the left turn problem before.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This may be related to another behaviour we noticed where arriving flights park at an angle ie not in line with the parkpos heading, They seem to aim for the right side
My 2 cents gutfeel. This is a rounding error based on :
Heading is right when not calculated (Aircraft already on parkpos on startup)
We have noticed the issue is more obvious on smaller distances
To calculate the taxiing heading (Where do I go next) you need to run a trigonometric rule based on the LAT LON of both your current and next node, the smaller the distance the more imnprecise the result.
One thing I',m getting from this and the pushback bug: I need to devise a way, to unit-test this code, i.e have you create some test groundnets, and then have a single Traffic aircraft follow a route, and verify it. Since debugging this inside FGFS is a total &%^@^%^@!!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Super frustrating day of testing 'roll forward from parkpos'. I can see the left turn bias described in real conditions but cannot replicate in test conditions (single airline)
Last edit: Yves Tolosa-Joas 2020-07-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Issue reproduced on first try in FG 2020.2.0 with B738. Will provide a full pack with test material, scenarios and results once gone through the rest of testing (and managed to bring my laptop to video record)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If it was about the max turn rate, why is it assymetric left/right? I more suspect a fauly 'angular value wrapping' where all turn angles become positive, when some should be negative. This could depend on the initial heading, final heading, original aircraft heading or more, many ways to screw it up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Un freakin believable! Got one finally. Taxi-speed in the performance db is behind the ATR 72 overshooting on left turn. I couldn't get why the Saab 340 (same specs) did not have the issue, I went to the extend of changing the pitch of in the main.xml ....
No aircraft but ATR and Twin Otter have custom taxi speed in the perf db, they fallback to the generic 15kts. ATR has 20, DHT has 25 cause I like my propellers fast. For lack of time I just tested that removing the custom tag fixed the beheviour.
Unlikely to be the sole issue not root cause as I have seen some 738 behaving badly, just not on this very particular test case (Leave parkspo rolling forwarf, turn after 12 meters).
This is going to be a veryyyyy long testing campaign.
Default values are too low anyway (from wikipedia: taxi speeds are typically 30 to 35 km/h (16 to 19 kn). But in any case Left vs Right turn behaviour should not differ for a given speed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It would help with your tests if one could see the Aircraft type of a AI Object in the property tree and PHI. I was planning a AI debugger to FGA and that way you could see radii or bad aircraft.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have set up my test bench for the LHS bug and I am working with one aircraft type per test and a single traffic file so need here BUT it is an awesome idea. In debug/Poperties/AI you just see numbered list of aircraft. It would make sense to bring here data from one level down (Callsign is my candidate) but flighttype would defintely help as well
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This seems to be speed related, I just repeated my test with the GA aircraft with taxi speed set to 10kts and they behaved more or less as they should with only a couple of minor deviations but they still tend to cut the corners.
Also found a bug in the performancedb, <type>light</type> should be <type>light_aircraft</type>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Confirming the Left Overshoot is not linked to taxi speed override but the speed itself ie if I set the default taxi speed to 20 for the class but have an override at aircraft level. every aircraft in the 'class" will overshoot when turning BUT the one with the 15kt override
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wait, so if a tight turn is requested, the AI aircradft don't slow down? That seems .. mental. Surely for turns of more than say 30 degrees, there should be a 'ground manovering speed' that is more like 5 or 8kts?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Looking at the AI flightplan code, the flightplans are set up to perform all taxiing at the performance-DB taxi speed, with no allowance for the turn angle. So we could add something to use a slower speed if if the angle is too acute (perhaps a dot-product of the two legs?).
That doens't explain why there is a difference depending on whether the turn is to the right or to the left however. Looking in the code for AI Aircraft there's a frankly horrible looking function
FGAIAircraft::updateHeading(double dt) (AIAircraft.cxx line 1082) with some very convoluted caluclations, many of which are commented out! I suspect there's some normalization problems somewhere within this code.
However I'm not brave enough right now to re-write it.
-Stuart
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm increasingly of the opinion we need to get the AI/traffic code unit-tested, then we can do re-writes or fixes with a bit more confidence and a lot less testing agony. Will start working on some pieces for this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For AI, there is not much to help you at all, but it's something I am doing some 'fun' hacking on during my vacation. To create an AIManager, traffic controllers, schedules etc in a unit-test.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The forum thread is a bit hard to understand all the issues, can you summarise it here? Is it /all left turns/ on the ground? And they seem to work a bit? But slowly?
It's mostly all left turns on the ground following the groundnet, the longer wide turns seem to be ok.
The first half of the first video shows what happens if the AI turn left onto the main taxiway after pushback and the second half shows a right turn onto the taxiway. The right turn operates correctly but the left turn tries to turn right before turning left, this usually results in the AI detaching itself from the groundnet and either attaching to the groundnet elsewhere or taxiing directly to the active runway.
The AI behaviour has been problematic for several years but I had not noticed the left turn problem before.
This may be related to another behaviour we noticed where arriving flights park at an angle ie not in line with the parkpos heading, They seem to aim for the right side
https://forum.flightgear.org/viewtopic.php?f=23&t=37130&hilit=lowl
Last edit: Yves Tolosa-Joas 2020-07-17
My 2 cents gutfeel. This is a rounding error based on :
I am going to grab a groudnet with a long straight taxiway and break it in a zillion mini segments to confirm the theory
One thing I',m getting from this and the pushback bug: I need to devise a way, to unit-test this code, i.e have you create some test groundnets, and then have a single Traffic aircraft follow a route, and verify it. Since debugging this inside FGFS is a total &%^@^%^@!!!
Not a problem, will design some test scenarios and coordinate with Brett
The fact that bigger circles work better presumably has to do with the max 30°/s turn rate.
Super frustrating day of testing 'roll forward from parkpos'. I can see the left turn bias described in real conditions but cannot replicate in test conditions (single airline)
Last edit: Yves Tolosa-Joas 2020-07-19
Issue reproduced on first try in FG 2020.2.0 with B738. Will provide a full pack with test material, scenarios and results once gone through the rest of testing (and managed to bring my laptop to video record)
If it was about the max turn rate, why is it assymetric left/right? I more suspect a fauly 'angular value wrapping' where all turn angles become positive, when some should be negative. This could depend on the initial heading, final heading, original aircraft heading or more, many ways to screw it up.
Un freakin believable! Got one finally. Taxi-speed in the performance db is behind the ATR 72 overshooting on left turn. I couldn't get why the Saab 340 (same specs) did not have the issue, I went to the extend of changing the pitch of in the main.xml ....
No aircraft but ATR and Twin Otter have custom taxi speed in the perf db, they fallback to the generic 15kts. ATR has 20, DHT has 25 cause I like my propellers fast. For lack of time I just tested that removing the custom tag fixed the beheviour.
Unlikely to be the sole issue not root cause as I have seen some 738 behaving badly, just not on this very particular test case (Leave parkspo rolling forwarf, turn after 12 meters).
This is going to be a veryyyyy long testing campaign.
Last edit: Yves Tolosa-Joas 2020-07-20
Default values are too low anyway (from wikipedia: taxi speeds are typically 30 to 35 km/h (16 to 19 kn). But in any case Left vs Right turn behaviour should not differ for a given speed
It would help with your tests if one could see the Aircraft type of a AI Object in the property tree and PHI. I was planning a AI debugger to FGA and that way you could see radii or bad aircraft.
I have set up my test bench for the LHS bug and I am working with one aircraft type per test and a single traffic file so need here BUT it is an awesome idea. In debug/Poperties/AI you just see numbered list of aircraft. It would make sense to bring here data from one level down (Callsign is my candidate) but flighttype would defintely help as well
Yeah didn't see the forest because of the trees. Callsign should be unique and sufficient for a lookup of type of aircraft and size.
This seems to be speed related, I just repeated my test with the GA aircraft with taxi speed set to 10kts and they behaved more or less as they should with only a couple of minor deviations but they still tend to cut the corners.
Also found a bug in the performancedb, <type>light</type> should be <type>light_aircraft</type>
This would be expected as the max turn rate is not speed adjusted. This would lead to understeering.
Confirming the Left Overshoot is not linked to taxi speed override but the speed itself ie if I set the default taxi speed to 20 for the class but have an override at aircraft level. every aircraft in the 'class" will overshoot when turning BUT the one with the 15kt override
Wait, so if a tight turn is requested, the AI aircradft don't slow down? That seems .. mental. Surely for turns of more than say 30 degrees, there should be a 'ground manovering speed' that is more like 5 or 8kts?
Nominal Taxi Speed in Performance DB is 15Kts. Observed Speed from Debug Panel is 10kts for 2 first segments, 15kts after that including in turns, 45 90 and 135 degrees tested. Video here http://www.mediafire.com/file/a13trip4tjv1rf3/Test_F5_777.mp4/file
Last edit: Yves Tolosa-Joas 2020-07-22
Looking at the AI flightplan code, the flightplans are set up to perform all taxiing at the performance-DB taxi speed, with no allowance for the turn angle. So we could add something to use a slower speed if if the angle is too acute (perhaps a dot-product of the two legs?).
That doens't explain why there is a difference depending on whether the turn is to the right or to the left however. Looking in the code for AI Aircraft there's a frankly horrible looking function
FGAIAircraft::updateHeading(double dt) (AIAircraft.cxx line 1082) with some very convoluted caluclations, many of which are commented out! I suspect there's some normalization problems somewhere within this code.
However I'm not brave enough right now to re-write it.
-Stuart
I'm increasingly of the opinion we need to get the AI/traffic code unit-tested, then we can do re-writes or fixes with a bit more confidence and a lot less testing agony. Will start working on some pieces for this.
How far is the "test framework" Basically sufficient to know where the tests should reside.
For AI, there is not much to help you at all, but it's something I am doing some 'fun' hacking on during my vacation. To create an AIManager, traffic controllers, schedules etc in a unit-test.