Fixed wing craft fails to disarm after autoland mission about inav HOT 15 CLOSED

It switches out of WP mode when the Autoland starts. When Autoland state ends Nav will switch to whatever Nav mode is enabled, WP mode in this case, except in the case of WP mode it will fall back to RTH until the WP mode switch is reset, hence the reason it ends up in WRTH.

The problem is Autoland switches Nav to idle when it detects a landing when in fact it should just maintain the current state until the landing detector has disarmed the plane. Looking at the code again, it also shouldn't be using isLandingDetected() it should check for STATE(LANDING_DETECTED) instead. It needs to return NAV_FSM_EVENT_NONE rather than NAV_FSM_EVENT_SWITCH_TO_IDLE in the APPROACH, GLIDE and FLARE stages.

from inav.

Seems this is because the RTH landing phase (called by WP landing) wasn't picking up the fact this is a WP Landing so instead it defaulted to using the Safehome fwapproach config which happened to be set at the same landing spot.

OK here I am not fully getting what you describle. So the second mission had no Landing parameters set in fwapproach. Did the plane then try to land at the last waypoint location or at the safehome location? Safehome would be correct as after a WP mission INAV defaults to WRTH anyway and that should be handled the same way as RTH.

OK, I've fixed this issue. The second landing had no fwapproach config set but that was irrelevant because It didn't seem to pick up that the RTH Landing was being called from WP Landing so it thought it was a RTH landing and used the Safehome landing that was set at the same location (which was an Autolanding). Seems this is caused by using previousState == NAV_STATE_WAYPOINT_REACHED to check for WP Landing and although this worked OK for the first mission it didn't work for the second (not sure why exactly) even though the plane was disarmed before the second mission was loaded. Anyway it's better to just use FLIGHT_MODE(NAV_WP_MODE) to check if WP mission Landing is active and this works correctly now. The first issue mentioned above was only highlighted by this bug but shouldn't be an issue in fact so long as the landing headings are 0 and it's correctly picking which flight mode is active when the RTH Landing code is called.

The second issue mentioned above regarding the fwapproach config being overwritten incorrectly isn't right and needs fixing but I think that needs a separate fix in itself.

from inav.

I am just wondering why in some cases it disarms properly after a WP Mission autoland. I just asked my test pilots. They have seen it not disarm in early testing like half a year ago but not again. Personally I have never seen it happen during missions but one time so far after a normal RTH landing. So it seems this disarm skip only happens under special circumstances but not always. Neither during WP nor during RTH.

I suspect it's a timing issue between Autoland calling isLandingDetected and the Landing detector doing the same but out of sync with each other so sometimes Autoland detects a landing before the Landing detector causing the plane to switch to RTH causing it to power up and move thereby preventing the Landing detector from then also detecting the landing and disarming.

I'm thinking now that Autoland shouldn't be checking for landing detection at all, it should leave the Landing detector to handle it instead otherwise you get these timing conflicts arising.

from inav.

Additional info from my side: I have looked at the log and based on sensor data and velocity values, the auto disarm requirements should have been met.
Could the reason be that his throttle stayed up? I am sure my test landings also had throttle up on the radio and still disarmed automatically.

I had the same happen one time out of 4 or 5 autolands on my AR pro but unfortunately my SD card was corrupted.

from inav.

Interesting? Relevant? Coincidental?
Just before the end of the log, the craft is in Angle, current is < 1A

For the last few iterations, RTH is asserted, current jumps to c. 6.8A

from inav.

I think he actually found a bug here.
During normal RTH via RTH mode, the whole landing sequence should show the ANGLE mode flag, not rth.
I doublechecked that with my last T1 logs of my tests where I used RTH and not a waypoint mission.

It seems like the WP mission overrides the Flight mode flag and blocks the automatic disarm. But as soon as the WP mission ands by the landing detection, INAV falls back into the landing mode and skips the disarm trigger. But as the mode switch is in WP still, it immediately switches back into WP mode but into Waypoint RTH as the mission with landing at the end was completed.

@Scavanger can you confirm that?

I tested WP missions during development but usually I cut the throttle on my radio while the mission is active to notice if it aborts or something else goes wrong. That might have triggered the normal land detection disarm instead during my tests. Not sure how the other pilots handle that.

from inav.

I am just wondering why in some cases it disarms properly after a WP Mission autoland. I just asked my test pilots. They have seen it not disarm in early testing like half a year ago but not again. Personally I have never seen it happen during missions but one time so far after a normal RTH landing. So it seems this disarm skip only happens under special circumstances but not always. Neither during WP nor during RTH.

from inav.

It switches out of WP mode when the Autoland starts. When Autoland state ends Nav will switch to whatever Nav mode is enabled, WP mode in this case

After reading the autoland process, I want to add something I changed from default. Maybe this is why it is not happening for others.

set nav_wp_mission_restart = START

from inav.

that setting just defines what happens if you switch WP mode off and back on again.
in your case it did a WRTH (happens when you switch to WP mode with no mission loaded). That's not the cause.

from inav.

I tested this with the isLandingDetected code removed from the Autolanding Approach, Glide and Flare phases and it still detects landing and disarms as expected. So this is the simple solution here.

I was trying to work out why this happens given the landing detector updates at 100Hz and Nav mode changes update at Rx update rate which is nominally 50Hz ... then realised that newer RC systems update much faster. In this case it was updating at 142Hz so it's possible to switch out of Autolanding to Nav Idle and then back to WRTH before the landing detector updates. When the landing detector does update it won't do anything useful because it only looks for a possible landing during the RTH landing phase.

from inav.

@breadoven Just had a chat with Andi. He is sick right now and can't work at that but Pawel wants to finalize 7.1.1
Andi said if that helps to remove the Autoland-Land detection it should be fine and not cause side effects. Can you provide a build for @chasdabigone to test with his exact config and setup as he has a 100% reproduction rate on that plane? If we can confirm it works we have a fix for the patch.

EDIT: I would assume that he made this Land-Detection because initially this feature was meant to be based on a custom 6.1.1 where the built in landing detection was not that good yet. So this might be just a leftover code from that anyway.

from inav.

I'm OK doing a fix for this issue but in the process of testing I've found other issues that need fixing. One of them is the fwapproach configuration doesn't appear to be set correctly when editing multi missions in Configurator. Not sure if this is a Configurator problem or INAV. I noticed that if you have a first mission set to Autoland then add a second mission and set the last WP to just Land with no Autolanding it still includes this second mission in the fwapproach configuration (not actually sure if this is as intended but I'd thought not). Then if you delete this second mission and upload to eeprom, all the WP mission fwapproach configs get deleted so if you check the first mission Land WP in Mission Control you'll find the approach headings have been reset to 0. However, if you save the 2 missions to file when first set up and then reload the file the fwapproach config seems to be correct, i.e. there is no fwapproach config defined for the second mission, only the first. I also then found that even with the config set correctly running the second mission resulted in an Autolanding even though it shouldn't. Seems this is because the RTH landing phase (called by WP landing) wasn't picking up the fact this is a WP Landing so instead it defaulted to using the Safehome fwapproach config which happened to be set at the same landing spot.

So a few more bugs to iron out here.

@b14ckyy Can you confirm the above issues by setting up multi missions in Configurator and checking how editing/changing/deleting affects the fwapproach config in the CLI ?

from inav.

I noticed that if you have a first mission set to Autoland then add a second mission and set the last WP to just Land with no Autolanding it still includes this second mission in the fwapproach configuration (not actually sure if this is as intended but I'd thought not).

This is actually intended. The fwapproach array IDs are hard wired to the mission ID. as long as the headings are 0, the fwapproach is inactive though.

Then if you delete this second mission and upload to eeprom, all the WP mission fwapproach configs get deleted so if you check the first mission Land WP in Mission Control you'll find the approach headings have been reset to 0.

This on the other hand is a bug and I am sure its on INAV side. I requested Andi to implement that an fwapproach string is reset if a Safehome or Land Waypoint is sent to the FC without fwapproach data directly following. This was for safety reasons in case someone changes a safehome in a 7.0 Configurator or a 3rd party app that does not support safehomes with landing. Otherwise a remainder of a previous approach could lead to a crash on a new location. Its possible that he accidently deletes the wrong fwapproach line?

Seems this is because the RTH landing phase (called by WP landing) wasn't picking up the fact this is a WP Landing so instead it defaulted to using the Safehome fwapproach config which happened to be set at the same landing spot.

OK here I am not fully getting what you describle. So the second mission had no Landing parameters set in fwapproach. Did the plane then try to land at the last waypoint location or at the safehome location? Safehome would be correct as after a WP mission INAV defaults to WRTH anyway and that should be handled the same way as RTH.

from inav.

Yeah lets just focus on safety related fixes. the wipe of the land data on deleting a mission is more an inconvenience. Andi can look into that later when he is fit again. Thanks for looking into it @breadoven

from inav.

Fix merged. Closing

from inav.