ProfHoekstra
commented
3 years ago Yes, a FLYOVER waypoint does indeed have the effect that the aircraft flies over it. ;)
The problem is partly the specific design of the fight plan: having legs shorter than the turn radius/distance. The guidance logic is only concerned with the active waypoint for a reason: The actual speed can be unknown so it not possible to calculate this beforehand. This is also the reason that other performance calculations are restricted to the active leg (or use speed constraints when given).
To maintain this adaptability, using the current speed might be possible, when no speed is given. This might have quite an effect on the computation speed of all guidance, also for more regular flight plans, as calculations currently only done for the active leg and to achieve the behaviour you mention, they would have to be expanded to future legs as well.
Also in some situations it might be unexpected and even unwanted that the autopilot decides to skip a waypoint before a turn because of later turns, especially using the current speed, and especially with a waypoint specified as FLYOVER. e.g. when the user controls the speed tactically and it is not necessary to skip it. So I'm not fully sure whether adding this logic as a universal change is actually a good idea for all use cases. Only if I can think of a way that works for all use cases. And it seems rather specific to this type of design. Could this also be solved by adapting the flight plan design to cope with this? That might still be a better solution to avoid adverse behaviour in flight plans with more standard layout, despite being more work for this specific case.
andubadea
jooste
Within the Metropolis 2 project, we are trying to use road networks to navigate between buildings. Due to this, in order to ensure that drones follow the road curvatures, we need to provide drones with many waypoints to approximate such curvatures.
The problem comes when the road is curved before an intersection (example below).
In this case, the drone needs to turn at waypoint D3004, which is defined as a turn waypoint. Waypoints D3002 and D3003 are defined as flyover waypoints. Thus, because the distance between D3003 and D3004 is so small, the drone doesn't have time to slow down for D3004 and thus overshoots it.
One way to solve this is from the pre-processing, to put speed constraints on waypoints ahead of a turn waypoint. However, this would be a complex task as the drone type and its performance parameters would need to be taken into account. Thus, I think this could be solved from within Bluesky, which already does the performance calculations.
Bluesky would have to calculate the distance to the next turn waypoint at any time, not only when the turn waypoint is the active waypoint. Thus, aircraft would be able to take turns ahead of a turn waypoint even if there are several other waypoints defined in between. This way, the aircraft would be able to decelerate in time (for example, at the red mark in the picture below).