Metropolis 2 related feature ideas

[andubadea]

BlueSky will be used for the Metropolis 2 SESAR project to simulate the deployment of ATM systems for drones in urban environments.

Thus, use this thread to post suggestions and ideas for features that are needed or would be nice to have for the M2 project.

[andubadea]

Right now, we're working on the following features:

• street maps on city level for nice visualisation
• geofences for defining buildings
• a bug-fixing update for the autopilot
• GUI plugins

[ProfHoekstra]

More info on autopilot update we're working on:

Mostly source code maintenance, so improve code structure and readability and doing many tests. The autopilot uses the same vectorized expressions for very different use cases, from small UAVs to larger airliners, controlling 4D,3D and 2D, both in the air as well as on the ground.

So far we know of one bug in the autopilot, which will soon be fixed in the master version:

• in UAV mode sometimes at the end of the route the vehicle starts circling or turning back, even flying backwards in case of rotors. The end-of-route logic when passing a waypoint will be adapted to fix this while maintaining/improving the final approach & landing behaviour of airliners when the runway is the last waypoint in the route

In terms of enhancements, the currently basic taxi AP mode for airliners will be tested and also in general many test- and example-scenarios for AP and ASAS will be added and updated.

Also the documentation of the autopilot in the wiki will be expanded, as many reported issues turn out to be caused by misunderstanding the autopilot with its many lateral and vertical modes and logic. I'll post a link to this documentation and point to it in the ADDWPT explanation and other AP commands in the command reference.

If there are new features you would like for Metropolis 2, post them here.

If you come across any bugs in BlueSky, please report them not here but at the issues page.

[andubadea]

Idea for the autopilot: considering Metropolis 2 will deal with VTOL drones, it would be great to have a mode for the autopilot to reflect this. This would mean that waypoints are navigated slightly differently:

• Hover mode at waypoints: if aircraft is a drone, and hover is enabled at a waypoint, then the drone will stop and hover at that waypoint. Maybe even have a duration argument, so the drone hovers for a certain amount of simulation time.
• Altitude commands while hovering, so drones can change altitude while horizontal speed is 0.
• Strict altitude constraint mode at waypoints: if drone is about to pass by waypoint and it did not fulfil the altitude constraint, it enters hover mode, vertically climbs to the desired altitude, and then continues its path.

These will be needed to cover the full range of capabilities that VTOL drones (and even manned helicopters) can execute.

[ProfHoekstra]

This is all already possible with the current autopilot:

• check out updated AT wpinrte command as well as ATALT and ATSPD commands

Does the performance model allows SPD 0?

[ProfHoekstra]

P.S. I plan to update the documentation on the Wiki on the autopilot next week. A waypoint in a route has so many features for different use cases (for both UAVs and aircraft), that I think it needs a better explanation and with more examples.

[andubadea]

The way FLYTURN and TURNSPD work with the ADDWPT command is a bit awkward, and it's pretty difficult to use. This should be changed to a more intuitive syntax, like
ADDWPT AC1 WPT01 TURNSPD 20
which would then automatically set WPT01 of AC1 as a FLYTURN waypoint.

[ProfHoekstra]

TURNSPD and TURNRADIUS are however meant as switches for vehicle types, not as waypoint features, as they are typically set per vehicle not per waypoint. This avoids having to repeat it as it setts the mode of ADDWPT.

Problem with the proposed syntax is proposed that it is difficult to maintain downward compatibility. It would be nice to switch to a different syntax instead of argument position based.

But we could also add this per waypoint feature indeed. Maybe as an AT option for the above reasons.

[andubadea]

I think I understand now. I'll try writing a tutorial on how to use TURNSPD and TURNRADIUS once I fully figured them out.

[ProfHoekstra]

With conditional commands, I've noticed that the possibilities are relatively unknown. I will write a chapter on this in the wiki, but because this is very relevant to Metropolis 2, I post s short version of it here.

First, in addition to the above mentioned commands, Andrei and I have also added an ATDIST command to make the execution of commands dependent on crossing a distance from/to a position. (Like all conditional commands these work once and are removed from the conditions-stack of the vehicle when executed.)

ATDIST can for example be used to execute a SPD command to start decelerating before reaching a waypoint, resulting in a hover at the waypoint. Then using AT or ATSPD you can also execute an altitude command. Then using ATALT you can have this followed by a SPD command again, all the while leaving LNAV on for route following. You'll have to switch on VNAV again if you would want the standard VNAV logic (based on manned aircraft) for altitudes and speeds in the flight plan, but using AT wpt SPD or AT wpt ALT might work just as well, and even better for UAVs.

Note how conditional commands can also be combined with other commands (CALL, DELAY or other conditional commands) to make complete programs at e.g. at waypoints. IN the example below for "AT wpt", you can also read "ATALT alt", "ALTSPD spd", "ATDIST pos dist":

acid AT wpinroute DO DELAY 20 cmdline
The result: when acid arrives at wpinroute then a timer of 20 seconds starts, after which cmdline will be executed.

acid AT wpinroute DO ATALT alt cmdline
Stringing them together is like nested commands: The result is: when arriving at this waypoint, it sets the conditional command ready for when this aircraft reaches the given altitude. Note how the aci argument is omitted in the ATALT command. Because it expects an acid as first argument and none is given, it will use the first acid of the AT command. When you explicitly use an acid you can also issue commands to other aircraft.

acid AT wpinroute CALL scenfile acid
When acid arrives at wpinroute the scenario file scenfile or scenfile.scn will be call with as one argument acid. Note how CALLing scenario files work like calling functions in a programming language. These arguments are inserted in the scenario file for %0 (first argument) %1 (seconds argument etc.). See EHAM/SID-04-ANDIK.SCN for an example. In a called scenario file, of course new conditional or delayed commands can be issued, etc..

In this way an endless amount of dependencies can be created and also flight plans can become complete programs instead of just a route to follow.

Also dependences between different aircraft can be created, because with any conditional command, the condition can refer to one aircraft/flight plan, but the resulting command can refer to any other aircraft. In this way, aircraft can wait or each other to pass certain waypoints, altitude, speeds, positions or ranges around positions.

[ProfHoekstra]

Note that I will also add it as an option to the AT command, I think this makes it easier to use it in the way you wanted to use it. - Jacco From: andubadea ***@***.***> Sent: dinsdag 25 mei 2021 09:47 To: TUDelft-CNS-ATM/bluesky ***@***.***> Cc: Jacco Hoekstra - LR ***@***.***>; Comment ***@***.***> Subject: Re: [TUDelft-CNS-ATM/bluesky] Metropolis 2 related feature ideas (#266) I think I understand now. I'll try writing a tutorial on how to use TURNSPD and TURNRADIUS once I fully figured them out. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_TUDelft-2DCNS-2DATM_bluesky_discussions_266-23discussioncomment-2D779814&d=DwMCaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=5JxzVuDw_d0JV-kYyto54d3K2zKNIvniSIeVeSDtif4&m=CHlChxjs3OTnILj6dIgn82AGi2rFfCeNDG9X-8XuMUA&s=G_akHmN35L7ZVzM7-dvqx51TIB4d7Ifonb-bZtbXuRc&e=>, or unsubscribe<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ABWT2BH2IWO3RZRS5XANZ6TTPNIWLANCNFSM42Y2A6EQ&d=DwMCaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=5JxzVuDw_d0JV-kYyto54d3K2zKNIvniSIeVeSDtif4&m=CHlChxjs3OTnILj6dIgn82AGi2rFfCeNDG9X-8XuMUA&s=WTFlalEBwE-9hoLQ3rDawo7HPaVe4ZFEaDJg9WmwxGY&e=>.

[andubadea]

Would it be possible to have more information about the waypoints available as class attributes?

For example, in Autopilot, the distance to each active waypoint for each aircraft is computed, but it is a local variable. Would it be possible to make it a class variable so it is available globally?

There are other such variables that would be useful to have, such as the distance to the next speed constraint (right now, there is only the distance to the next alt constraint in activewpdata), or a variable in activewpdata that says what kind of waypoint it is, or the waypoint index in its route.

[jooste]

If these variables are already calculated during updates as function locals it should be a small change to make them into member variables. Could you make a proposal in a pull request?

[andubadea]

Certainly! Will do.

[andubadea]

I think the last major to-do for the Metropolis 2 project is the command streamlining. Right now, if a lot of stack commands are used in a scenario (100k or more commands for instance), Bluesky the stutters a lot and for long periods of time whenever a command needs to then be issued.