Hello, Friends !
My question is not to hard but for me important. Hope for your experience and solutions.
I had set on one of the the switchers RTH and it is work perfectly, but when quad loses connection with receiver he stops the motors and fall like a stone.
In the failsafe tab selected GPS Rescue as you can see on the screens.
I'll be pleasure to read your advises how to solve this problem with dropping.
P.S. using Betaflight Configurator.

When GPS Rescue is triggered from a failsafe it runs the following sanity checks first and if any of those checks fail it just drops the quad to the ground rather than trying to fly it back to the home point:-

1. GPS receiver is still connected to the FC
   
2. GPS receiver is sending a valid GPS Fix
   
3. Quad has not experienced a big shake (probably due to a crash)
   
4. Number of Sats is equal or above gps_min_sats
   
5. Quad is further away than the minimum configured distance to home (gps_rescue_min_dth)
   
6. Quad gets closer to the home point after reaching initial altitude
   

Looking at your DVR footage you are less than 100m from the home point when the quad failsafes so number #5 will be the reason why it just dropped to the ground instead of trying to fly back home.

You can change the minimum distance to home to anything you like. The minimum value you can use is 50 metres. You can set that by running the following command in the CLI...


Just remember with that minimum value set your quad will still just drop to the ground if it failsafes within 50 metres of the take-off point.

(10-Sep-2022, 09:43 PM)SnowLeopardFPV Wrote: When GPS Rescue is triggered from a failsafe it runs the following sanity checks first and if any of those checks fail it just drops the quad to the ground rather than trying to fly it back to the home point:-

1. GPS receiver is still connected to the FC
   
2. GPS receiver is sending a valid GPS Fix
   
3. Quad has not experienced a big shake (probably due to a crash)
   
4. Number of Sats is equal or above gps_min_sats
   
5. Quad is further away than the minimum configured distance to home (gps_rescue_min_dth)
   
6. Quad gets closer to the home point after reaching initial altitude
   

Looking at your DVR footage you are less than 100m from the home point when the quad failsafes so number #5 will be the reason why it just dropped to the ground instead of trying to fly back home.

You can change the minimum distance to home to anything you like. The minimum value you can use is 50 metres. You can set that by running the following command in the CLI...

Code:

set gps_rescue_min_dth = 50
save

Just remember with that minimum value set your quad will still just drop to the ground if it failsafes within 50 metres of the take-off point.

First of all thank you for your respond SnowLeopardFPV !
But my issue is not case 5, because it is already on 50 meters min_dth.

1. GPS receiver is still connected to the FC (As I understand it, if there is not gps then failsafe gps_rescue not working) Don't know what do you mean.  
   
2. GPS receiver is sending a valid GPS Fix (The same, I don't understand what do you mean, if it is fix so process should start 'gps_rescue')
   
3. Quad has not experienced a big shake (probably due to a crash) (The same I don't see connection between shaking, losing signal and droping instead of gps_rescue)
   
4. Number of Sats is equal or above gps_min_sats (Number of sats was above it's good ? Why it is bad ? But not less than gps_rescue_min_sats value)
   
5. Quad is further away than the minimum configured distance to home (gps_rescue_min_dth) (You can see added screenshot)
   
6. Quad gets closer to the home point after reaching initial altitude (This is the same, as 5th reason ?)
   

I cheked, many times, always, when the signal is lost, it drops ...

Maybe, you or somebody else saw kind of problem like this one, need your help and knowledge, thanks for every advice.

What would happen if you switched off sanity checks? Would it RTH on failsafe regardless of the situation?

Thank you, I will try to turn off sanity_checks, maybe, really this is the problem ...

Without a sanity check the quad may fly away to another dimension if the home position or anything else is wrong

I read about this (fly to another part of the planet), what do you think it's if this is not sanity? ?

(11-Sep-2022, 08:17 PM)Gleb Wrote: First of all thank you for your respond SnowLeopardFPV !
But my issue is not case 5, because it is already on 50 meters min_dth.

1. GPS receiver is still connected to the FC (As I understand it, if there is not gps then failsafe gps_rescue not working) Don't know what do you mean.  
   
2. GPS receiver is sending a valid GPS Fix (The same, I don't understand what do you mean, if it is fix so process should start 'gps_rescue')
   
3. Quad has not experienced a big shake (probably due to a crash) (The same I don't see connection between shaking, losing signal and droping instead of gps_rescue)
   
4. Number of Sats is equal or above gps_min_sats (Number of sats was above it's good ? Why it is bad ? But not less than gps_rescue_min_sats value)
   
5. Quad is further away than the minimum configured distance to home (gps_rescue_min_dth) (You can see added screenshot)
   
6. Quad gets closer to the home point after reaching initial altitude (This is the same, as 5th reason ?)
   

I cheked, many times, always, when the signal is lost, it drops ...

#5 and #6 are different:-

• #5 means that Betaflight checks the minimum distance between the quad and the home position BEFORE it initiates GPS Rescue and if that condition isn't met it won't even initiate GPS Rescue and will just cut power to the motors.
  
• #6 means that GPS Rescue has already been initiated but if the quad doesn't get closer to the home point while it is automatically flying back it will terminate GPS Rescue and cut power to the motors.
  

I can't see what else it can be other than one or more of the sanity checks failing, but as already mentioned be cautious about switching those checks off because if there is something weird going on with the GPS coordinates which leads Betaflight to think there is an issue, with the safety net of those checks switched off your quad could end up flying off to somewhere it thinks is the home point which isn't, and with an RXLOSS condition there will be nothing whatsoever you can then do to stop that other than just watch helplessly as your quad flies off into the sunset until the battery eventually dies and it crashes somewhere kilometres away where you will never find it.

Do you have a blackbox log of the flight? If you do then please post it as there might possibly be some clues in that.

Can you please also run both the "dump" and "diff all" commands in the Betaflight Configurator CLI tab and copy/paste the results back here so we can check all your GPS related settings.

(12-Sep-2022, 09:30 AM)SnowLeopardFPV Wrote: #5 and #6 are different:-

• #5 means that Betaflight checks the minimum distance between the quad and the home position BEFORE it initiates GPS Rescue and if that condition isn't met it won't even initiate GPS Rescue and will just cut power to the motors.
  
• #6 means that GPS Rescue has already been initiated but if the quad doesn't get closer to the home point while it is automatically flying back it will terminate GPS Rescue and cut power to the motors. 
  

Ok, thank you for your explainings and patience, I'm beginner and can ask simple questions.
Hope this is correct file .bbl,(blackbox - save flash to file) downloaded from betaflight.
https://drive.google.com/file/d/1PNlqeRQ...sp=sharing
Also, this "diff all" and "dump" settings saved in two .txt files.

That's why I became interested in this question, because of breaking the cam after fall (crash.jpg).



 

All of your Betaflight GPS settings look to be fine. You also have sanity checks switched on permanently so the sanity checks will be executed even when you manually trigger GPS Rescue from a switch and not just when a failsafe event occurs.

There are 40 logs in that blackbox file:-

• 12 have a disarm event that was triggered following a GPS Rescue event, but those GPS Rescue events were all manually triggered by the GPS Rescue mode switch and not by an RXLOSS (failsafe) event. None of those blackbox logs seem to correlate with the DVR you posted which appears to disarm after a flight time of 51 seconds.
  • Log #09 -> 9.8 seconds
    
  • Log #15 -> 5 seconds
    
  • Log #24 -> 3 seconds
    
  • Log #25 -> 0.9 seconds
    
  • Log #26 -> 0.9 seconds
    
  • Log #29 -> 0.6 seconds
    
  • Log #31 -> 3.8 seconds
    
  • Log #32 -> 28 seconds
    
  • Log #33 -> 4.2 seconds
    
  • Log #34 -> 4.9 seconds
    
  • Log #35 -> 4.3 seconds
    
  • Log #36 -> 5.5 seconds
    
    
• The other 28 logs show a disarm event that was triggered by the disarm switch.
  

So those logs are likely from when you were trying to test GPS rescue on the ground without taking off. Maybe the blackbox flash memory is full up and didn't capture your issue when it actually happened. When the flash memory fills up it doesn't get cleared automatically which means that logging just stops until you clear some space or completely wipe the flash memory.

Looking at your Betaflight configuration you also have the Warnings OSD element positioned outside the boundaries of the screen which means if you get any warnings like "Rescue N/A" and "RXLOSS" you won't see them. I recommend that you move the Warnings OSD element back into view somewhere prominent in your displays so you will see immediately if there are any problems with GPS Rescue.

Interesting. Just like you I have tested GPS RTH by switch and it works fine. I have not tested loss of signal but after reading your post I will by turning RC off when very close to the ground at least 100 meters away from home point.

There are GPS settings that simply do not work in Betaflight versions earlier than 4.3. One of my quads is running 4.2.11 just like yours and I could not get READY_BEEP (ring a tone when GPS is locked and ready) to work. It turns out that the code for this function was not implemented. On January 29 someone asked about this feature, and it was not until April 13 it was discovered that the code for this function did not exist: https://github.com/betaflight/betaflight/issues/11367
Because of the time it took to even realize it wasn't in the code makes me believe that GPS functions in Betaflight 4.2.11 and earlier are not that thoroughly tested.

Now it's raining heavily here but hopefully tomorrow it will be dried up and I will perform a signal loss test with GPS RTH as failsafe and see if it is working for me. If it is we can compare some settings. If not, then I am just as interested in solving this as you are.

GPS Rescue works fine in Betaflight 4.2.11. I have that version on my GPS equipped quads and have tested multiple times that it works with both a manual trigger of GPS Rescue and during a failsafe condition. To date I've never had any problems (knock on wood) and it works as expected by initiating GPS Rescue and flying the quad back towards the home point.

You don't need to switch off your transmitter to cause a failsafe condition which can be nerve-racking knowing that it will take some time to boot back up again and (hopefully) re-establish an RC link. Simply set up the FAILSAFE mode on a switch which then allows you to manually trigger / emulate a failsafe (RXLOSS) condition by flicking that switch during flight. If you do that you need to switch it back off again in order to get back manual control of the quad (i.e. emulate an RC link restored condition). If GPS Rescue already kicked in as part of the failsafe procedure, then even if you switch failsafe back off the quad will continue its automated GPS Rescue flight. To get back manual control you then just need to deflect one of the roll, pitch or yaw stick axis to > 30% from the centre position. Once you've successfully tested failsafe using the switch method, I recommend you then delete that mode so you don't inadvertently flick that switch during a normal flight.

(13-Sep-2022, 10:19 AM)Mike C Wrote: Interesting. Just like you I have tested GPS RTH by switch and it works fine. I have not tested loss of signal but after reading your post I will by turning RC off when very close to the ground at least 100 meters away from home point.

There are GPS settings that simply do not work in Betaflight versions earlier than 4.3. One of my quads is running 4.2.11 just like yours and I could not get READY_BEEP (ring a tone when GPS is locked and ready) to work. It turns out that the code for this function was not implemented. On January 29 someone asked about this feature, and it was not until April 13 it was discovered that the code for this function did not exist: https://github.com/betaflight/betaflight/issues/11367
Because of the time it took to even realize it wasn't in the code makes me believe that GPS functions in Betaflight 4.2.11 and earlier are not that thoroughly tested.

Now it's raining heavily here but hopefully tomorrow it will be dried up and I will perform a signal loss test with GPS RTH as failsafe and see if it is working for me. If it is we can compare some settings. If not, then I am just as interested in solving this as you are.

But better to try it, without turning off radio. SnowLeopardFPV's post is open and deep explanation, check it before you will try to do this.

Today, I read that we can check this (failsafe) in modes we have option to check gps_rescue. (modes Failsafe add ... - it's imitation of losing signal)
Here, is this the article, I advice you to read it so the quad does not fly away, stay safe !
https://oscarliang.com/setup-gps-rescue-...etaflight/

(12-Sep-2022, 04:52 PM)SnowLeopardFPV Wrote: So those logs are likely from when you were trying to test GPS rescue on the ground without taking off. Maybe the blackbox flash memory is full up and didn't capture your issue when it actually happened. When the flash memory fills up it doesn't get cleared automatically which means that logging just stops until you clear some space or completely wipe the flash memory.

Looking at your Betaflight configuration you also have the Warnings OSD element positioned outside the boundaries of the screen which means if you get any warnings like "Rescue N/A" and "RXLOSS" you won't see them. I recommend that you move the Warnings OSD element back into view somewhere prominent in your displays so you will see immediately if there are any problems with GPS Rescue.

Yes, you absolutely right, memory is full  (Next time, I'll check with enabled Failsafe mode (seted up the FAILSAFE mode on a switch) and cleaned, erased Dataflash memory)

Warnings OSD element positioned, I fixed this position, now it's beside to center of the screen, thank you !

(13-Sep-2022, 12:52 PM)Gleb Wrote: Today, I read that we can check this (failsafe) in modes we have option to check gps_rescue. (modes Failsafe add ... - it's imitation of losing signal)
Here, is this the article, I advice you to read it so the quad does not fly away, stay safe !
https://oscarliang.com/setup-gps-rescue-...etaflight/

I have read that before. I set up my GPS rescue with that page some time ago.

I'm not quite understanding the concern about turning off the radio. I have tested GPS rescue by button and it works. Where does the concern that the quad will fly away come from? I'm a missing something? Are there reports that GPS Rescue initiated by failsafe can cause fly away on quads where GPS Rescue by button works fine?

What I am somewhat concerned about is Steve's question to Oscar in the comments section:

"I tested failsafe by switching off my radio while the copter was about 5 meters in the air. I noticed that there was about a 1 second pause between when the motors stopped spinning and the GPS rescue kicked in, causing the copter to fall a few meters towards the ground before rising up again. How can I set it up so that the instant the signal is lost the GPS rescue will activate before the motors stop spinning?"

I don't quite understand Oscar's suggestion to fix it. I would have thought that GPS rescue initiation would be instant instead of 1 second of motors stalling.