Initial altitude in CRE

[OrxataEnFartons]

Hi again,
Because I am not using waypoints originally defined in the database, and defining them in the scn does not work for using the AT command (see my previous posts), what I do to change a waypoint constraint during the flight, is that I modify the scn and reload it again. But when I do that, I want the drone to keep its current altitude (to avoid a 'jump' when the constraint update arrives), so in the new scn:

00:00:00.00>CRE M6001, M600, 52.22023, 10.533871, 0, 30, 20

where the lat lon is the current position and that 30 is the current altitude. I do this overwriting of the scn programmatically. When you make a CRE in command line, the flight is created at the altitude indicated in the command. However, the behavior that I get is that, when the the scn is overwritten, it starts from 0 to reach that altitude in CRE.
Any idea to get what I want with the current commands? I mean, a way to force the aircraft to be created at that altitude.

[OrxataEnFartons]

I found a workaround for this. There it goes in case is of use for somebody.
When I want to change the plan during the flight, now I don't edit and reload the scn. In my case during the flight I receive instructions like: "change the altitude to +10 for the waypoints in the range [i, j] of the trajectory". Now I keep a dictionary: { waypoint_i: [list of commands] } that represents the commands to be executed once the drone passes the key waypoint.
When the drone arrives to i (or to i-1, that's up to you), I execute the commands associated, in this case an increase of the altitude.
When the drone passes j, I restore the original altitude with another command.

[jooste]

Thanks for the suggestion. It still seems to me that you are implementing functionality that is already part of bluesky. It could be that the current version has a bug that is preventing this functionality from working correctly, but then this is something that needs to be fixed!

[OrxataEnFartons]

Hi. I guess you refer to the comand AT. I have been doing all this mess because the AT command was not working for me if using on it points defined in the scn with DEFWPT.
Anyway this new way of changing the plan allowed me to fix another behavior that maybe is the expected one but not the one I needed.
Imagine you have some waypoints in the scn where the altitude is
wp0: 30- wp1: 30- wp2: 30- wp3: 30- wp4: 30- wp5: 30- wp6: 30- wp7: 30.
Then, while the drone is flying, still between wp0 and wp1, receives an instruction to modify the plan to :
wp0: 30- wp1: 30- wp2: 40- wp3: 40- wp4: 40- wp5: 30- wp6: 30- wp7: 30.

As we commented in other thread, when it reaches wp1 it starts climbing because is the expected behavior, ok.
But with the previous scn updating and reloading method, after climbing, it always continued at 40 until it passed the penultimate waypoint, wp6 here, and I want it to arrive to wp5 with 30, as defined in its ADDWPT. Now I add an ALT to be executed after passing wp4 to start descending to 30.

The following is an example of one of those modified plans.

00:00:00.00>DEFWPT M6001_DEST,52.306783,10.523382,FIX 00:00:00.00>DEFWPT M6001_WP0,52.231887,10.528944,FIX 00:00:00.00>DEFWPT M6001_WP1,52.237018,10.586552,FIX 00:00:00.00>DEFWPT M6001_WP2,52.245808,10.467696,FIX 00:00:00.00>DEFWPT M6001_WP3,52.257605,10.567834,FIX 00:00:00.00>DEFWPT M6001_WP4,52.26998,10.498063,FIX 00:00:00.00>DEFWPT M6001_WP5,52.278612,10.550374,FIX 00:00:00.00>DEFWPT M6001_WP6,52.289141,10.500978,FIX 00:00:00.00>CRE M6001,M600,52.22023,10.533871,0,0.0,20 00:00:00.00>ORIG,M6001,52.22023,10.533871 00:00:00.00>DEST,M6001,M6001_DEST 00:00:00.00>ADDWPT,M6001,M6001_WP0,98.4,38.88 00:00:00.00>ADDWPT,M6001,M6001_WP1,131.20839900000001,38.88 00:00:00.00>ADDWPT,M6001,M6001_WP2,131.20839900000001,38.88 00:00:00.00>ADDWPT,M6001,M6001_WP3,131.20839900000001,38.88 00:00:00.00>ADDWPT,M6001,M6001_WP4,98.4,38.88 00:00:00.00>ADDWPT,M6001,M6001_WP5,98.4,38.88 00:00:00.00>ADDWPT,M6001,M6001_WP6,98.4,38.88 00:00:00.00>LNAV,M6001,ON 00:00:00.00>VNAV,M6001,ON

[jooste]

The vertical navigation logic follows the implementation of conventional aircraft: climb early, descend late. The behaviour you describe in your example should only occur if the intermediate waypoints do not explicitly specify an altitude constraint. In this case, after passing the last waypoint with an altitude constraint, the FMS will look forward for the next altitude constraint. If that is a higher altitude it will immediately climb, if it is a lower altitude it will determine when it should start descending at the latest.

However, when I tried this example, with an additional 00:01:33.00>M6001 AT M6001_WP2 ALT 120, it indeed doesn't descend back to 100 when it gets near WP3. I think this is a bug. I've forwarded it to the maintainer of the bluesky FMS code!

[jooste]

Update: when I test this line: 00:00:00.00>CRE M6001, M600, 52.22023, 10.533871, 0, 30, 20, I get an aircraft properly starting at 30FT.

[ProfHoekstra]

Dear Miquel, Ok, I’ll check. For your info: It is now possible to switch off this FMS climbing and descending logic with the SWTOC and SWTOD command (see command reference). It will then climb/ descend in a mostly constant V/S between the altitude constraints. Best regards, Jacco Hoekstra From: Joost Ellerbroek ***@***.***> Sent: dinsdag 20 september 2022 11:12 To: TUDelft-CNS-ATM/bluesky ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [TUDelft-CNS-ATM/bluesky] Initial altitude in CRE (Discussion #417) The vertical navigation logic follows the implementation of conventional aircraft: climb early, descend late. The behaviour you describe in your example should only occur if the intermediate waypoints do not explicitly specify an altitude constraint. In this case, after passing the last waypoint with an altitude constraint, the FMS will look forward for the next altitude constraint. If that is a higher altitude it will immediately climb, if it is a lower altitude it will determine when it should start descending at the latest. However, when I tried this example, with an additional 00:01:33.00>M6001 AT M6001_WP2 ALT 120, it indeed doesn't descend back to 100 when it gets near WP3. I think this is a bug. I've forwarded it to the maintainer of the bluesky FMS code! — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/TUDelft-CNS-ATM/bluesky/discussions/417*discussioncomment-3688437__;Iw!!PAKc-5URQlI!9d09oPuRkm0r0vQ1sK9APsW_j3os9QNwutVGmNxzMZzkmPBoBAbVGirv3Gt1VQ2-5GyMISFgrh_nUasY5Mx8Z_bgUyf6jg$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/ABWT2BAUOCNRGLA7ZWVM74DV7F5VJANCNFSM57IBCBAQ__;!!PAKc-5URQlI!9d09oPuRkm0r0vQ1sK9APsW_j3os9QNwutVGmNxzMZzkmPBoBAbVGirv3Gt1VQ2-5GyMISFgrh_nUasY5Mx8Z_Z4W2-mEQ$>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>

[ProfHoekstra]

Indeed AT ALT should take care of this normally, I’ve got your scenario now and will check this soon. From: Miquel Angel ***@***.***> Sent: vrijdag 16 september 2022 20:40 To: TUDelft-CNS-ATM/bluesky ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [TUDelft-CNS-ATM/bluesky] Initial altitude in CRE (Discussion #417) I found a workaround for this. There it goes in case is of use for somebody. When I want to change the plan during the flight, now I don't edit and reload the scn. In my case during the flight I receive instructions like: "change the altitude to +10 for the waypoints in the range [i, j] of the trajectory". Now I keep a dictionary: { waypoint_i: [list of commands] } that represents the commands to be executed once the drone passes the key waypoint. When the drone arrives to i (or to i-1, that's up to you), I execute the commands associated, in this case an increase of the altitude. When the drone passes j, I restore the original altitude with another command. — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/TUDelft-CNS-ATM/bluesky/discussions/417*discussioncomment-3665035__;Iw!!PAKc-5URQlI!4KTB0EdbiNBTANXpXt3F8D593uC9f0W0d35uPCV2Ug7FRJeBAFuCK6vntQ41TRYujZtFzSBU4R8DLC_2XJFcCxgJjcaMYA$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/ABWT2BFNLQMEGAAFXWNMY5LV6S5ILANCNFSM57IBCBAQ__;!!PAKc-5URQlI!4KTB0EdbiNBTANXpXt3F8D593uC9f0W0d35uPCV2Ug7FRJeBAFuCK6vntQ41TRYujZtFzSBU4R8DLC_2XJFcCxjatvkavg$>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>