First ADDWPT ignored

[OrxataEnFartons]

Hi,
I am getting a strange behaviour and maybe the reason is I am doing something wrong.
I load this scenario:
00:01:05.00>CRE M6001,M600,52.22023,10.533871,0,0.0,20
00:01:05.00>ORIG,M6001,52.22023,10.533871
00:01:05.00>DEST,M6001,52.306783,10.523382
00:01:05.00>ADDWPT,M6001,52.231887,10.528944,98.4,38.88
00:01:05.00>ADDWPT,M6001,52.237018,10.586552,98.4,38.88
00:01:05.00>ADDWPT,M6001,52.245808,10.467696,98.4,38.88
00:01:05.00>ADDWPT,M6001,52.257605,10.567834,98.4,38.88
00:01:05.00>ADDWPT,M6001,52.26998,10.498063,98.4,38.88
00:01:05.00>ADDWPT,M6001,52.278612,10.550374,98.4,38.88
00:01:05.00>ADDWPT,M6001,52.289141,10.500978,98.4,38.88
00:01:05.00>LNAV,M6001,ON
00:01:05.00>VNAV,M6001,ON

And then before it arrives the first ADDWPT I send commands to keep the trajectory but change the altitude in some of those waypoints. So I do:
HOLD
DELRTE acid
DEST,M6001,52.306783,10.523382
ADDWPT,M6001,52.231887,10.528944,98.4,38.88
ADDWPT,M6001,52.237018,10.586552,131.20839900000001,38.88
ADDWPT,M6001,52.245808,10.467696,131.20839900000001,38.88
ADDWPT,M6001,52.257605,10.567834,131.20839900000001,38.88
ADDWPT,M6001,52.26998,10.498063,98.4,38.88
ADDWPT,M6001,52.278612,10.550374,98.4,38.88
ADDWPT,M6001,52.289141,10.500978,98.4,38.88
LNAV ON
VNAV ON
OP

Then the same trajectory, just changing the altitude in three points. The problem is that, when I load these changes, the aircraft flights directly to the second point, ignoring the first one:

Besides, it starts the increase of altitude immediately. I would like to have that new altitude when reaching the second waypoint. I understand it needs a certain time beforehand to reach the 2nd wp with that altitude, but I find it does it too soon. The aircraft is a drone and reaches that altitude in a few seconds, quite before reaching wp2.
What am I missing?

UPDATE:
I fixed that of going to wp2 by adding a DIRECT to the first wp. However, trying to fix that of the immediate change of speed, I tried to use the ALT command instead of editing and reloading the whole plan. But my wps are defined with lat lon and that command requires only waypoint names, so I tried this, for the fourth wp:
AT M6001,M6001004, 32.808399

And even it does not complain, it does not change the altitudes when it arrives to the affected wps.

[jooste]

Hi @OrxataEnFartons,

The reason that the first waypoint is skipped could be because it is too nearby, and the route following logic detects it as 'reached'. By default waypoints are 'fly-by', which means that instead of flying exactly over each waypoint, the aircraft flies at some distance relating to the turn radius, connecting the previous straight leg with the next.

The reason that the aircraft starts climbing as soon as it does is intended behaviour: The way a conventional FMS works is to 'climb early, descend late'. It will try to reach an altitude constraint before the waypoint is reached, by climbing as soon as possible, and descending as late as possible. If any previous waypoints don't specify explicit altitude constraints the start of climb can carry over multiple waypoints.

All this is not always the intended behaviour when simulating drones though. Forks like that of the Metropolis 2 project have made adaptations to the AP logic to change this.

[OrxataEnFartons]

That explains everything. I will take a look to Metropolis 2 fork, Thanks for the tip!

However there is something I would like to note. Searching workarounds to make it work as I wanted, and since I read this in the Command Reference about the AT command: "Sadly, this option only accepts an wpname and not, for instance, an index of the waypoint as given in the scn, or at least with reference to the next/past wp. This forces us to overwrite the remaining plan. ", to provide waypoints with name to AT I did the following:

1. Defined names for the waypoints in the scenario file, with DEFWPT, before creating the aircraft, (If defined them with stack.stack before loading the scenario these were not recognized by the ADDWPT command of the scn)
2. while running the scenario I send a change of altitude for a waypoint ahead
3. I check with AT that the constraint in that WP has been correctly updated.
   However, the drone never changes its altitude before/after reaching the waypoint.

So I am going back to the previous method: deleting the whole scenario and reloading it with the new constraints (taking care of removing the past waypoints). Even with the behavior you mentioned, at least it applied the new constraints.

Regards.

[ProfHoekstra]

And the master version AP will also be equipped with a Top-of-climb (SWTOC) and Top-of-descend switch (SWTOD) to disable this default behaviour. From: Joost Ellerbroek ***@***.***> Sent: dinsdag 16 augustus 2022 17:11 To: TUDelft-CNS-ATM/bluesky ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [TUDelft-CNS-ATM/bluesky] First ADDWPT ignored (Discussion #412) Hi @OrxataEnFartons<https://urldefense.com/v3/__https:/github.com/OrxataEnFartons__;!!PAKc-5URQlI!6zjPOrmavVKwNpD-YrmJezWeAWllKah1rUsVcuY2tr3SnKnulHVA4uGeN81x31RaMlhpfqMtUp3NHEp5nxPBBBheD6nXIw$>, The reason that the first waypoint is skipped could be because it is too nearby, and the route following logic detects it as 'reached'. By default waypoints are 'fly-by', which means that instead of flying exactly over each waypoint, the aircraft flies at some distance relating to the turn radius, connecting the previous straight leg with the next. The reason that the aircraft starts climbing as soon as it does is intended behaviour: The way a conventional FMS works is to 'climb early, descend late'. It will try to reach an altitude constraint before the waypoint is reached, by climbing as soon as possible, and descending as late as possible. If any previous waypoints don't specify explicit altitude constraints the start of climb can carry over multiple waypoints. All this is not always the intended behaviour when simulating drones though. Forks like that of the Metropolis 2 project have made adaptations to the AP logic to change this. — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/TUDelft-CNS-ATM/bluesky/discussions/412*discussioncomment-3407512__;Iw!!PAKc-5URQlI!6zjPOrmavVKwNpD-YrmJezWeAWllKah1rUsVcuY2tr3SnKnulHVA4uGeN81x31RaMlhpfqMtUp3NHEp5nxPBBBgTbKB56w$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/ABWT2BFSPQKAKNG6TVS6ED3VZOVP7ANCNFSM56RKGRBQ__;!!PAKc-5URQlI!6zjPOrmavVKwNpD-YrmJezWeAWllKah1rUsVcuY2tr3SnKnulHVA4uGeN81x31RaMlhpfqMtUp3NHEp5nxPBBBisoAV8TQ$>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>