What will happen, when RC & GPS signal lost? -- inav 6.1.1

[lida2003]

I have got a crash when RC & GPS signal lost.

it seems
Step 1: RC signal lost
Step 2: GPS signal lost
Step 3: inav enter emgergency landing

I don't know why it lost balance and crashed, when emergency?

https://www.bilibili.com/video/BV17V4y1h7is/

[Jetrell]

It looks like you had a hardware failure (regulator), based on the way the GPS signal dropped off at the same time the RX signal was lost.. It can't be coincidence that the two happened together... Then it appeared to try and RTH for a few seconds. Then shut the throttle down.

I haven't done any resent testing with MC emergency landing with loss of both RX and GPS, to see if it still works fine as it did a few releases back.
The baro was still active in the free fall.. So it should have attempted to make a powered descent..

[lida2003]

I'm back home now. Re-check my quad, which is recovered from crash site.

a) GPS and magmeter works fine.
b) 4 motor rotate correctly
c) 4 prop are intact
d) battery is right at the palce where it was suppose to when at crash site, as it's beeping...(That't great, it's in the tree, hard to find.

I re-checked video. The GPS is coming back when fall from the sky, but it's too late.

[breadoven]

Could also have been interference from those antennas on the mountain top. I'm sure directional dish antennas would cause problems if you flew into the beam. The signal did actually recover after the emergency landing started and it dropped, possibly because the quad fell out of the interference. Either that or someone zapped it with an anti drone device, makes no sense the Rx and GPS signal failed at the same time.

Not sure why the throttle dropped to 0. The altitude did still seem to be working but without a log it's impossible to know if it was still flagged as trusted, any log available ? What was failsafe_throttle set to ? I guess the only benefit of a controlled descent would have been that had a better chance of recovering the GPS or Rx signal before it hit the ground.

Would also be useful if someone could check the failsafe stuff using SITL and a flight sim that includes drones (X Plane doesn't). I did test failsafe altitude control due to Rx loss but probably not with GPS failure also. I guess this isn't something people are too keen to test that rigorously because things get broken or lost if it goes wrong.

[lida2003]

End up with acro??? I didn't touch anything

[breadoven]

I'm guessing you must have waggled the pitch/roll stick which would have cancelled the FS once the Rx signal came back. Emergency Landing would have self cancelled once the GPS signal came back. Makes you wonder if it would have recovered from the tumble given more height ... I'm guessing probably not.

Might be worth rechecking the throttle setting logic in the code when an Emergency Landing is triggered to avoid it dropping to zero causing a tumble.

[lida2003]

Humm... it need expertise for rechecking the throttle setting logic in the code.

2:08 [OSD RXLOSS]
2:10 [OSD GPS zero stars] hold for about 5 seconds
2:16 [OSD FS Emergency ]throttle down, trigger emergency landing, causing a tumble.
2:19 [OSD FS Emergency ]GPS 9 stars back
2:20 [OSD acro Emergency landing]GPS 15 stars back
2:21 hit tree, lost VTX signal

[Jetrell]

@breadoven It might be a good time to ask. Does Emergency Land only use Baro data, when the GPS fails. Or is it still using nav_mc_pos_z and nav_mc_vel_z estimation ?
My initial tests were never at the height this thing fell from.

Makes you wonder if it would have recovered from the tumble given more height .

Maybe if it had defaulted back to an level stabilized mode like ANGLE.

Might be worth rechecking the throttle setting logic in the code when an Emergency Landing is triggered to avoid it dropping to zero causing a tumble.

I've always had failsafe_throttle LAND set to a value.. But I'd have thought Emergency Landing with at least the Baro, should've kept the throttle active when under auto control. Unless the logic isn't doing what is should in this case.

[breadoven]

@Jetrell It just checks if Altitude status is trusted or not. If it isn't trusted it reverts to using the Failsafe LAND setting unless DROP has been set instead in which case it goes to throttle idle. If Altitude status is trusted it will control the landing descent based on current estimated vertical velocity and nav_emerg_landing_speed (default 5m/s).

If position is trusted it will hold position also.

It's possible the altitude wasn't trusted initially which would have reverted to the Failsafe LAND setting which in this case would have been 1000ms or 0 throttle. This would have initiated the tumble which I guess is probably unrecoverable. Maybe it's better to just use something like 90% of Hover throttle as the default throttle at the start of the emergency landing code which will be overwritten in the following code if better altitude descent control is possible,

There is possibly a bug in the emergency landing code that I'll fix. Don't know if it would have caused this because it could only possibly have caused this sort of tumble if Altitude status wasn't trusted. May as well fix it anyway together with the default throttle setting.

[Jetrell]

End up with acro??? I didn't touch anything

That was the flight mode you were in before the FS, so it went back to it.

Did you have Airmode enabled with ACRO ? I assume you must not have. Other wise it would have fought to prevent itself from tumbling.

[lida2003]

I didn't set any RC channel for airmode. BUT I found it have already enabled in configuration tab.

[Jetrell]

Looking at your video again.. Basing it on the voltage sag as the quad was tumbling.. It did look like the motors were pulsing, while trying to gain stability. But there was likely too little throttle_idle power available for Airmode to do any meaningful work.

[lida2003]

throttle_idle is 5%. I'm NOT sure about 5%, as betaflight using bi-dshot (I don't have to worry about this), inav only support dshot.

Since it's a 5 inch quad, I use default settings mostly, just see this link for configurations: https://blog.csdn.net/lida2003/article/details/131547407

Battery/throttle_idle should be ok with flips(pitch/roll), see https://www.bilibili.com/video/BV1ag4y1w7nt just start from 6:10; and the quad seems ok to keep it's attitude, https://www.bilibili.com/video/BV17u411h77q?p=7

[lida2003]

PS: #9169

Just keep the notes

[lida2003]

[lida2003]

@Jetrell @breadoven After crash, I have checked quad. It seems quite OK with battery/airmode/GPS/RC signal.

https://www.bilibili.com/video/BV17V4y1h7is?p=2

[breadoven]

Well seems there is a problem here because this shouldn't have lost control the way it did. Even with the throttle at zero it should have maintained control. Angle is active during an Emergency Landing, but this lost control completely so don't think that is the issue. I suppose it's possible the interference also affected the electronics but that seems unlikely.

The OSD flashed up conflicting messages also. It seems to have gone into an Emergency Landing after the GPS signal dropped, then RTH appears again even though the GPS signal still doesn't appear to have recovered, before Emergency Landing flashed up again. Could be a conflict between the FS RTH and the Emergency Landing control. Should also happen on a fixed wing if that's the case so can be checked using HITL.

Is it possible to skip frame by frame with bilibili videos ? (, and . commands for Youtube)

[lida2003]

I'm NOT sure about bilibili frame by frame features.
Well i'm sorry for not switching on blackbox, try this youtube link https://youtu.be/vw9xnmJPCB8

[breadoven]

Looking at the video again various things are behaving strangely. The Lat/Lon coordinates keep updating even though 0 satellites are indicated. Not aware there's any filtering of these values, they come straight from the GPS so you'd imagine they would remain stuck on the last good value unless the GPS itself is doing something. The Roll and Pitch indications remain pretty well unchanged from the moment the Failsafe starts. I'd have thought there should be some variation throughout the tumbling. Makes you wonder if the gyro was working correctly or perhaps was affected by whatever caused the interference to the GPS signal. Obviously if the gyro wasn't working it would explain the loss of control. Are gyros compatible with microwaves ?

Perhaps the issue here is more related to severe interference than anything else. Without a log it's hard to know. I'll check the Emergency Landing/FS RTH stuff on HITL for a fixed wing but if there's nothing obvious from that it's going to be difficult to know what happened.

[lida2003]

GPS BN880 module is working at 230400 baud rate/ublox protocl/5Hz update rate.

The Roll and Pitch indications remain pretty well unchanged from the moment the Failsafe starts. I'd have thought there should be some variation throughout the tumbling.Makes you wonder if the gyro was working correctly or perhaps was affected by whatever caused the interference to the GPS signal. Obviously if the gyro wasn't working it would explain the loss of control. Are gyros compatible with microwaves ?

Good point!
a) I found roll/pitch unchanged(very little ~0.1 changes) the right moment entering emergency landing.
b) roll/pitch was changing when RC signal lost or GPS signal lost.
c) Accelerometer/Gyroscope is using MEMS (Micro-Electro-Mechanical Systems) technology, which is quite different from RC signal and GPS signal interference.

[breadoven]

Checking with a fixed wing on HITL, logging at 100% rate, there is nothing unexpected when you switch off the transmitter and then set the the satellite count to 0. Failsafe RTH is initiated when the Rx signal is lost and Emergency Landing starts 5s after cutting the GPS signal. It simply switches to Emergency Landing and maintains it. Altitude control is available because the Baro still works so altitude status remains trusted. Roll, Pitch and Yaw behave as expected. Not a direct comparison with a multirotor but shows there is no obvious odd interaction between FS RTH and the Emergency Landing. The "(RTH)" message that pops up on the OSD after the Emergency Landing starts is just caused by the fact the FS RTH is still active, just failed to an Emergency Landing due to the lack of a valid position.

So seemingly no obvious reason for the loss of control unfortunately. A SITL test with Realflight would be useful in this case to see if it's repeatable.

[lida2003]

I think the procedure of emergency landing for multicopter is different from fixed wing.

taskMainPidLoop(fc_core.c)
 └──> applyWaypointNavigationAndAltitudeHold(navigation.c)
     └──> applyMulticopterNavigationController(navigation_multicopter.c)
         └──> applyMulticopterEmergencyLandingController(navigation_multicopter.c)
             └──> resetMulticopterAltitudeController(navigation_multicopter.c)  // which is suppose to go wrong according to osd, wait 5seconds and then resetMulticopterAltitudeController, fall from sky.

taskMainPidLoop(fc_core.c)
 └──> applyWaypointNavigationAndAltitudeHold(navigation.c)
     └──> applyFixedWingNavigationController(navigation_fixedwing.c)
         └──> applyFixedWingEmergencyLandingController(navigation_fixedwing.c)

applyMulticopterNavigationController according to OSD, RTL(no GPS) hover for about 5 seconds, then fall from sky.
It comments "reset altitude controller", I'm not sure if it's related with some thing wrong, as I didn't know much details of the code.

resetMulticopterAltitudeController it sets throttle = 0(hard coded), some expertise needed here for further investigation.

[breadoven]

resetMulticopterAltitudeController will reset the throttle but only for 1 loop. It does this every time you switch from ACRO to AltHold or PosHold etc so nothing that should cause the loss of control seen here. I don't think the throttle dropping to zero is the issue with this it's a problem with attitude control at the point the Emergency Landing started. Either rcCommand[ROLL] or rcCommand[PITCH] weren't set correctly or something odd happened in the PID loop possibly caused by the gyro doing something unexpected.

[lida2003]

is it possible to simulate copter with sitl/hit, when rc/gps signal lost?

[Jetrell]

is it possible to simulate copter with sitl/hitl, when rc/gps signal lost?

If you have RealFlight RC simulator.. Otherwise no, with X-Plane simulator.. Which was mentioned by Breadoven in earlier posts.

[lida2003]

is it possible to simulate copter with sitl/hitl, when rc/gps signal lost?

If you have RealFlight RC simulator.. Otherwise no, with X-Plane simulator.. Which was mentioned by Breadoven in earlier posts.

any links avaliable for the simulation? Or anyone with the expertise, time, env can take a look at this case?

Anyway, I have found some info in docs, try to setup an env.

• SITL
• SITL/RealFlight

So we need this ???? really have no idea about how to setup the environment. Is there any free software for simulation?

[lida2003]

Add a link #9184 (comment)

[lida2003]

@breadoven I have reviewed #9169

a) currentBatteryProfile->nav.mc.hover_throttle which is initialized .hover_throttle = SETTING_NAV_MC_HOVER_THR_DEFAULT in pgResetFn_batteryProfiles. But I can't find the definition of SETTING_NAV_MC_HOVER_THR_DEFAULT, where is it?

b) Is currentBatteryProfile->nav.mc.hover_throttle updated when flying (affected by wind/battery sag etc.), I didn't find the code assign value to hover_throttle? Any key words to find those code?

[breadoven]

SETTING_NAV_MC_HOVER_THR_DEFAULT is generated at compile time from fc/settings.yaml. This generates settings_generated.h in the build folder for the target board (inav\build\src\main\target\target_name\target_name).

currentBatteryProfile->nav.mc.hover_throttle is a setting defined in fc/settings.yaml.

[lida2003]

Thanks @breadoven . That's great to know those params.

fc/settings.yaml

      - name: nav_mc_hover_thr
        description: "Multicopter hover throttle hint for altitude controller. Should be set to approximate throttle value when drone is hovering."
        default_value: 1500
        field: nav.mc.hover_throttle
        min: 1000
        max: 2000

settings_generated.h
#define SETTING_NAV_MC_HOVER_THR_DEFAULT 1500

[lida2003]

failsafe_throttle is the throttle set during the failsafe LAND procedure. However, it's also used during an emergency landing if there is no autonomous control possible and Failsafe procedure has NOT been set to DROP. It's supposed to be set to a value that will give a reasonable descent rate. However, by default it's 1000 which might be OK for a fixed wing but isn't much use for a quad. It should be set to slightly below hover throttle.

https://github.com/iNavFlight/inav/blob/master/docs/Failsafe.md#failsafe_throttle

@Jetrell @breadoven I'm quite confused. Please check https://github.com/iNavFlight/inav/wiki/Failsafe#setting-up-failsafe-with-return-to-home

Does this mean Failsafe procedure has NOT been set to DROP, but it will surprise the multicopter to drop????

Is there any logic related to the code?

[Jetrell]

Does this mean Failsafe procedure has NOT been set to DROP, but it will surprise the multicopter to drop????

The old method of LAND was only based on a fixed throttle value and an operation timer.. I guess its not surprising that setting the throttle to zero, would start a timer that essentially dives zero throttle for that period of time. LOL... So yes, it effectively become FS DROP.

@breadoven Concerning your changes to set the LAND throttle on 90% of the hover throttle value.. What happens if a new user doesn't change hover throttle, and leaves it at the rather high 1500uS default.. Would it send an overpowered quad skyward, instead of landing ?

[Jetrell]

Being a long time INAV user. I've always just entered a THROTTLE and TIMER value into the FS LAND procedure, based on the quads requirements, even if LAND is not selected.
But the fact that both or either are set to zero by default, for MC LAND, is the same as selecting DROP... A new user has to understand how the function works, and add a value to both the Throttle and the Timer. Or the RTH Emergency Land (fall-Back) will not work.. And from years of looking at peoples DIFF settings. I've very rarely seen either setting changed, if RTH procedure is selected.

For multicopter use. It would seem better to have two conservative default settings appear when LAND or RTH procedures are selected, than having both set to off.
failsafe_throttle = 1150
failsafe_off_delay = 70

[lida2003]

Good point, especially for long range copter.

As now I have met this RC & GPS lost issue, I hope/try to find out the root cause. I think what @Jetrell has mentioned above is really a good point. Maybe the configurator should do more about GUI settings for RTL, e.g. when RTL is selected, those essential params(nav_mc_hover_thr/failsafe_throttle/failsafe_off_delay etc.) should be poped up for users to configure, so anyone will NOT miss those rare cases for flight safty.

From what we have got here：
a) fell from the sky when entering emergency land
b) OSD altitude is OK all the time, which means baro is working fine
c) pitch/roll attitude was kind of freezed to 0.0 ~ 0.3, even it's tumbling, which means fc doesn't know it's tumbling.
d) throttle is NOT always zero (it changes) all the way down to the tree (fc deemed descending too fast????)
e) last moment ( close to the tree) RC might triggered acro mode, throttle back to 44%
f) airmode is enabled

I still try to understand what I have missed here or just a protential bug (well compicated, not only a single factor)

[breadoven]

@breadoven Concerning your changes to set the LAND throttle on 90% of the hover throttle value.. What happens if a new user doesn't change hover throttle, and leaves it at the rather high 1500uS default.. Would it send an overpowered quad skyward, instead of landing ?

If hover throttle hasn't been changed from default it's likely to result in a climb in many cases. I guess it's a question of what's better from a safety point of view, a quad climbing and endangering aircraft or dropping and hitting things on the ground. I guess if it climbs it will run out of battery eventually and drop anyway so maybe the change I made needs rethinking to avoid an uncontrolled climb. You could check if hover throttle is still set to the default and revert to the Emergency Landing throttle setting for FS DROP, i.e. idle throttle. NOTE: There is a bit of confusion here because an Emergency landing with FS set to DROP but no Failsafe active (so just position loss during Nav) reduces throttle to idle whereas an actual Failsafe set to DROP simply disarms. Unfortunately this would be a problem for quads that do hover at 1500 ... so I'm not sure what the ideal solution would be here in that case.

Ideally if a user has failed to set things up INAV should default to the safest overall action for 3rd parties which is to just drop during an Emergency Landing, a penalty I guess for not checking settings properly, especially Failsafe settings, which should be a priority, and Hover settings which you'd think would be fundamental on a quad.

[lida2003]

I guess it's a question of what's better from a safety point of view, a quad climbing and endangering aircraft or dropping and hitting things on the ground.

Does default(1000) value of failsafe_throttle will cause tumble (prop stall???), and then uncontrolled drop? Or just eliminate the rootcause of tumble, prop stall or something else.

@Jetrell mentioned about failsafe_throttle = 1150 might be a nice default value????which can be changed in fc/settings.yaml.

I guess if it climbs it will run out of battery eventually and drop anyway so maybe the change I made needs rethinking to avoid an uncontrolled climb.

How about current method of emergency landing procedure? Is it just same as "old method of LAND, which is only based on a fixed throttle value and an operation timer"?

[lida2003]

Much more detailed info, please check here #9184