Comments (15)
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.
inav/src/main/navigation/navigation.c
Line 2396 in cea4397
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.
Related Issues (20)
- H743 CPU Clock HOT 2
- Inav 8 artificial horizon not working HOT 14
- SUMD not working with inav 7.1.2 and HACKRCKD722 HOT 1
- FC FIRMWARE7.0.0 [AOCODARCF7MINI_V1] output S5 S6 S7 S8 issues. HOT 15
- Safehome either RTH or FS not both HOT 2
- Missing telemetry sensor data
- Add support for the TBS LUCID FC HOT 1
- (GoFilm 20) Happymodel Super F405HD ELRS AIO support possible? HOT 2
- Fuataba FASSTest 12 channel mode does not work
- Waypoint Jump Command does not work properly HOT 2
- Ukrainian language for INAV version 7.1.1 HOT 2
- Show issues on github-issues channel HOT 1
- No motors show up, in outputs tab. Just flashed to INAV from betaflight speedybee f405 v3 HOT 4
- GPS Baro Conflict HOT 10
- Magnetometer problem. Cannot calibrate compass/Magnetometer light is red instead of blue Speedybee f405 v3 / Flywhoo Goku M10 PRO v3 QMC5883 HOT 2
- No Satelites are locking on gps Flywoo goku M10 pro V3 HOT 2
- Motor number 7 wont spin and gives beeps after shifting from betaflight to INAV HOT 9
- Variables in the configurator are mixed up. HOT 2
- Airspeed ADC fail cal check
- Serial gimbal does not work with Walksnail Gimbal firmware V3.2 HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from inav.