iNavFlight
Unable to cancel RTH after FS.
Current Behavior
I am using a build of iNav (with unrelated customizations) based on 4.1. I've made some code changes in a personal build that I've shared with friends.
Matek F405 MiniTE, Caddx Vista Digital Air Unit, TBS Tracer Micro TX, EdgeTX on Jumper T16.
Because of a number of limitations:
- I'm unable to access the Blackbox logs because of an issue with this flight controller (https://github.com/iNavFlight/inav/issues/7719)
- Recorded flight video doesn't show OSD or error messages. Limitation of DJI goggles.
- EdgeTX log doesn't include flight mode - see attached
I'm unable to provide many details of what happened. I'm looking for suggestions on how to diagnose this further. I'm comfortable looking at code, if pointed at some.
I've had two recent flights where the flight mode switched to RTH for some reason. The first flight I tried to enable WP mode, but didn't have a mission loaded. There must be some logic that switches to RTH after a WP mission. This flight ended with iNav landing the plane. The landing was expected. I have that setting enabled. However, I expect to be able to abort RTH and the landing.
With the most recent flight today (log attached), RTH was triggered for some reason. If there was a message, I didn't notice it. I wasn't flying far, but there could have been a momentary radio glitch. However, after RTH was started, I was only able to regain control by switching to Manual mode. If I switched out of Manual to Angle, it resumed RTH. I ended up landing in Manual mode.
Talon 250g-2022-05-23-172023.csv
Additional context
https://pastebin.com/pVnQs3mv
- FC Board name and vendor:
- INAV version string:
version
INAV/MATEKF405TE 4.1.100 Feb 25 2022 / 23:01:15 (611d26f4) <- THIS IS A PERSONAL BUILD NUMBER based on 4.1
Thanks in advance for any input
The flight mode is probably a bug in EdgeTX's logger . If you passthrough the CRSF (e.g. on TX16S) and save it to a file, then the FM field is correctly populated. So it would appear that INAV is providing it (visible using mwp's CRSF mode or if the telemetry stream is recorded to a file, in mwp's crsf_test tool).
WP mode falls back to RTH if no valid mission is loaded. Been like this for a while. Switching WP mode off stops the RTH ... as does selecting Manual mode. Which is why the second RTH you mention sounds WP mode fall back related again because you could cancel it by switching to Manual. WP mode is overridden by Manual mode whereas RTH selected by RTH mode switch isn't. So if you select WP mode without a valid mission it will fall back to RTH but only if Manual mode isn't selected. RTH mode on the other hand will always work regardless of the other mode selections.
The OSD mode selection should have said "WRTH" during the WP triggered RTH rather than the usual "RTH".
WP mode falls back to RTH if no valid mission is loaded. Been like this for a while. Switching WP mode off stops the RTH ... as does selecting Manual mode. Which is why the second RTH you mention sounds WP mode fall back related again because you could cancel it by switching to Manual. WP mode is overridden by Manual mode whereas RTH selected by RTH mode switch isn't. So if you select WP mode without a valid mission it will fall back to RTH but only if Manual mode isn't selected. RTH mode on the other hand will always work regardless of the other mode selections.
The OSD mode selection should have said "WRTH" during the WP triggered RTH rather than the usual "RTH".
In the second flight, a valid mission was in progress when RTH was triggered. Again, I don't know the cause for RTH, since I missed the FS message if there was one. It wasn't because it reached the end of the mission. However, I don't recall turning off WP mode when I was trying to regain control.
When the FS condition clears, will the aircraft resume WP mode or is RTH expected in this situation?
I also don't recall seeing WRTH in the OSD, although that might not appear in the DJI OSD. Many of the flight modes aren't mapped 1 to 1. Because of the EdgeTX FM bug, I don't see that in the log.
I have something to look at next time it happens. I'll look for WRTH in Lua Telemetry. I'll try disabling WP mode to see if I regain control.
WP mode falls back to RTH if no valid mission is loaded. Been like this for a while. Switching WP mode off stops the RTH ... as does selecting Manual mode. Which is why the second RTH you mention sounds WP mode fall back related again because you could cancel it by switching to Manual. WP mode is overridden by Manual mode whereas RTH selected by RTH mode switch isn't. So if you select WP mode without a valid mission it will fall back to RTH but only if Manual mode isn't selected. RTH mode on the other hand will always work regardless of the other mode selections. The OSD mode selection should have said "WRTH" during the WP triggered RTH rather than the usual "RTH".
In the second flight, a valid mission was in progress when RTH was triggered. Again, I don't know the cause for RTH, since I missed the FS message if there was one. It wasn't because it reached the end of the mission. However, I don't recall turning off WP mode when I was trying to regain control.
When the FS condition clears, will the aircraft resume WP mode or is RTH expected in this situation?
I also don't recall seeing WRTH in the OSD, although that might not appear in the DJI OSD. Many of the flight modes aren't mapped 1 to 1. Because of the EdgeTX FM bug, I don't see that in the log.
I have something to look at next time it happens. I'll look for WRTH in Lua Telemetry. I'll try disabling WP mode to see if I regain control.
Ah maybe something got missed where you have a RTH Failsafe during a WP mission, something that locks in the RTH based on the WP mode selection. Need to check it.
I think this is probably a bug caused by:
https://github.com/iNavFlight/inav/blob/cee90edce56a9ec9408181b69d7904889b702d3c/src/main/navigation/navigation.c#L3409
canActivateWaypoint gets set false when RTH is active during Failsafe and even though the RTH gets cancelled and NAV set to idle when the Failsafe is cancelled canActivateWaypoint remains set false and can only get set true by:
https://github.com/iNavFlight/inav/blob/cee90edce56a9ec9408181b69d7904889b702d3c/src/main/navigation/navigation.c#L3433
However, the first bit of code above will reinitiate RTH preventing canActivateWaypoint being reset true so you end up stuck in RTH mode.
Not sure this is desired on the basis it's better to remain in RTH than restart the WP mission ... or a bug. I have the feeling it was intended this way ... although it's a bit confusing. It does at least ensure the craft returns home regardless.
Thanks breadoven.
iNav 4.0/4.1 has the ability to continue WP missions. To me, that would be the ideal behavior when the failsafe condition clears.
Based on what you see, would I be able to regain normal control by turning off WP mode? Would that allow me to cancel the RTH?
I've increased failsafe_delay to 10 (one second) from 5 hoping this will avoid this problem happening from short glitches.
The flight mode is probably a bug in EdgeTX's logger . If you passthrough the CRSF (e.g. on TX16S) and save it to a file, then the FM field is correctly populated. So it would appear that INAV is providing it (visible using mwp's CRSF mode or if the telemetry stream is recorded to a file, in mwp's
crsf_testtool).
Thanks @stronnag I've reported it as an issue for EdgeTX: https://github.com/EdgeTX/edgetx/issues/1991
@tonyyng thanks, I think I know why this happens; as I don't have the hardware and couldn't test I was reluctant to generate either an issue or PR.
Thanks breadoven.
iNav 4.0/4.1 has the ability to continue WP missions. To me, that would be the ideal behavior when the failsafe condition clears.
Based on what you see, would I be able to regain normal control by turning off WP mode? Would that allow me to cancel the RTH?
I've increased failsafe_delay to 10 (one second) from 5 hoping this will avoid this problem happening from short glitches.
Would make sense to allow the WP mission to continue and it would be easy enough to do this. There is also the option to allow a Mission to continue during Failsafe using failsafe_mission.
Turning WP mode off would cancel the RTH. There's a system message shown that states this when WP mode is causing the RTH. Are system messages not available for the digital OSD ?
Is this the system message you are referring to? "CANCEL WP TO EXIT RTH" https://github.com/iNavFlight/inav/blob/8156a56a27f97cac9dc4649bde385b0f80303943/src/main/io/osd.c#L4290
I don't recall seeing this message. The DJI OSD messages are shown in the craftname field and alternates quickly, so I might have missed it. I also can't review video from the goggles to check because OSD fields aren't in recorded video.
The line of code I linked above is in a function "osdGetSystemMessage" that also sets the system message for AUTOLAUNCH and AUTOTUNE modes. Based on similar logic in this function in the DJI OSD code: https://github.com/iNavFlight/inav/blob/8156a56a27f97cac9dc4649bde385b0f80303943/src/main/io/osd_dji_hd.c#L984
I'm guessing that the line of code that adds the OSD_MSG_WP_RTH isn't used for DJI OSD.
Yes that's the message.
I think the DJI OSD code probably needs updating where possible, seems to have fallen behind changes made to the analogue OSD.
I keep hearing rumors of DJI supporting a canvas mode for OSD. When that happens, perhaps there will be just one code base to support the OSD.
For this particular issue, I have my solution (turn off WP to exit RTH).
Earlier, you said:
Would make sense to allow the WP mission to continue and it would be easy enough to do this.
If the cause of FS has cleared, it makes sense to me. Do you need this issue open to make this change? Otherwise, I'll close it.
Seems there are a couple of options here. Allow the mission to auto resume if failsafe ends or allow the mission to continue for a set time period after failsafe is triggered before initiating the failsafe procedure.
The second option seems better and could be done by changing the failsafe_mission setting so it defines a time delay between failsafe occurring and the set failsafe procedure starting. If set to 0 then the WP mission would continue regardless of failsafe (same as the current OFF) otherwise a delay would be set which would allow the mission to continue allowing some time margin for the failsafe to reset before aborting the mission. Default time delay could be a second.
The second option sounds like this existing setting: https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#failsafe_delay https://github.com/iNavFlight/inav/blob/master/docs/Failsafe.md#failsafe_delay
The default is half a second.
The description only describes rx channel data though. Is that the only FS cause that is relevant?
Failsafe delay is just the time delay between Rx signal loss and failsafe triggering. You could increase that setting but it would apply in all cases which you may not want if you only wanted an increased delay for WP missions.
Option 2 above is similar to failsafe_mission being set OFF but limited in duration rather than applying for the entire mission. It would prevent a mission aborting during brief Rx signal loss but could be set longer to give more time to recover the signal in certain circumstances, e.g. to prevent aborting due to transient line of sight problems etc. You could just set failsafe_mission to OFF but maybe some people are a bit wary of using option that on longer missions. The option 2 change also appears to be a very simple change to make.
So if failsafe_delay was set to 5 (default), option 2 would take effect failsafe_mission + 0.5s, assuming FS was RX signal loss?
What you've suggested sounds more flexible.
Roughly 1 out of 20 times i activate WP inav 4.1 will not go into WP but some strange WRTH mode (I'd have to look it up exactly next time). No chance of activating any WP mission on that flight. Once landed and the battery is unplugged/FC reboot, the WP missions work well for the next 19 flights (roughly - did not do a exact count). I currently have 3 planes on 4.1 and it happens to all of them. Not so on my 2.6.1 planes. There is something wrong with 4.1 and WP missions and it's not because there is no valid mission loaded.. unless the startup screen is lying :)
Today i was testing some antenna setup with my test plane and did about 10 flights. Running 4.1 on a F722-Wing and CRSF. Now and then I test RTH in order to fine tune the planes behavior and to make sure it will work. so today a number of times. On flight 10 however the plane would not come home as usual. When i've noticed and wanted to abort RTH the whole FC went into a freeze! unable to regain control as i've watched the plane crash...
This could be a hardware failure. However i do take my soldering tasks very seriously, always put capacitors on and have done over 10h with this plane in over 50 flights. In all these years this has never happened to me. So just a hardware failure or really a bug in 4.1??? I've never seen so many RTH problem tickets as now in v4. Seems that I'm not the only one and it kinda scares me as i was about to update my remaining planes to 4.1/5.0. Maybe less fancy but saver to stay on 2.6.1 until the bug is found??
https://youtu.be/L73tAnIXxLk
Roughly 1 out of 20 times i activate WP inav 4.1 will not go into WP but some strange WRTH mode (I'd have to look it up exactly next time). No chance of activating any WP mission on that flight. Once landed and the battery is unplugged/FC reboot, the WP missions work well for the next 19 flights (roughly - did not do a exact count). I currently have 3 planes on 4.1 and it happens to all of them. Not so on my 2.6.1 planes. There is something wrong with 4.1 and WP missions and it's not because there is no valid mission loaded.. unless the startup screen is lying :)
WRTH just means RTH triggered by WP mode. It appears if RTH is active having been set for a WP during a WP mission and also if no valid WP mission is loaded and you try selecting WP mode. In the latter case selecting WP mode falls back to RTH rather than doing nothing if there is no mission to fly. No valid mission is either no correct end of mission flag (last WP flag must = 165) or there are simply no waypoints to load from FC memory. Startup screen is arming screen or something else ?
Was this a single mission only that was loaded ?
Was the mission set to load on boot using nav_wp_load_on_boot ?
Today i was testing some antenna setup with my test plane and did about 10 flights. Running 4.1 on a F722-Wing and CRSF. Now and then I test RTH in order to fine tune the planes behavior and to make sure it will work. so today a number of times. On flight 10 however the plane would not come home as usual. When i've noticed and wanted to abort RTH the whole FC went into a freeze! unable to regain control as i've watched the plane crash...
This could be a hardware failure. However i do take my soldering tasks very seriously, always put capacitors on and have done over 10h with this plane in over 50 flights. In all these years this has never happened to me. So just a hardware failure or really a bug in 4.1??? I've never seen so many RTH problem tickets as now in v4. Seems that I'm not the only one and it kinda scares me as i was about to update my remaining planes to 4.1/5.0. Maybe less fancy but saver to stay on 2.6.1 until the bug is found??
https://youtu.be/L73tAnIXxLk
Sorry this ended in a crash. Looks like it started to RTH but something locked up with the frozen OSD.
Was the Failsafe triggered using Failsafe mode or was it caused by signal loss ?
A Diff would be useful and a log file would help a lot assuming you recovered the plane of course.
@StuweFPV Can you open a new issue for the crash problem. Needs special attention if it was an FC lockup caused by a bug.
Startup screen is arming screen or something else ? Yeah sorry meant "arming screen" where it now reads "mission loaded" which is super handy
Was this a single mission only that was loaded ? Was the mission set to load on boot using
nav_wp_load_on_boot? Single mission and yes load on boot and gets confirmed when arming. But that does not mean that he will actually fly the mission but abort and go over to RTH for whatever reason. As described before it happens to me about every 20th flight, NO biggie but it does happen regularly. Next time i'll get it on DVR i'll post it
@StuweFPV Can you open a new issue for the crash problem. Needs special attention if it was an FC lockup caused by a bug.
Ok done #8055 - Thanks for your help!