Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FAILSAVE RTH -> DISARM #4900

Closed
mooiweertje opened this issue Jul 5, 2019 · 66 comments

Comments

Projects
None yet
7 participants
@mooiweertje
Copy link
Contributor

commented Jul 5, 2019

Current Behavior

Wing disarms in areas where RXLOSS is often accuring

Steps to Reproduce

  1. install 2.2
  2. use below configuration
  3. fly in area/distance where RXLOSS occurs

Expected behavior

The plane will return home

Suggested solution(s)

Stop further development. Increase degree of testing to level two or three. It's level one now which is too low for aviation. Continuing this way will cause nasty accidents.

Additional context is the configuration before upgrading to 2.2. Version was 2.2 when the wing was lost.

version

INAV/OMNIBUSF7V2 2.1.0 Feb 25 2019 / 16:56:33 (65b0ec1)

GCC-7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]

reset configuration to default settings

defaults noreboot

resources

mixer

mmix 0 1.000 0.000 0.000 0.000

servo mix

smix 0 3 0 100 0
smix 1 3 1 50 0
smix 2 4 0 -100 0
smix 3 4 1 50 0

servo

servo 3 976 1976 1463 -100
servo 4 1006 2006 1472 80

feature

feature -TX_PROF_SEL
feature VBAT
feature MOTOR_STOP
feature GPS
feature PWM_OUTPUT_ENABLE
feature FW_LAUNCH

beeper

map

serial

serial 5 2 115200 115200 0 115200

aux

aux 0 0 0 1300 2100
aux 1 1 2 900 1300
aux 2 3 1 1300 1700
aux 3 3 0 1700 2100
aux 4 9 1 1300 1700
aux 5 8 1 1700 2100
aux 6 35 0 1700 2100
aux 7 27 3 1300 1700
aux 8 28 3 1700 2100
aux 9 32 5 1200 1500
aux 10 33 5 1500 1800
aux 11 34 5 1800 2100

adjrange

rxrange

temp_sensor

osd_layout

osd_layout 0 0 23 0 H
osd_layout 0 1 1 14 V
osd_layout 0 3 8 6 H
osd_layout 0 4 8 6 H
osd_layout 0 6 23 14 V
osd_layout 0 7 12 14 V
osd_layout 0 9 0 7 V
osd_layout 0 13 24 1 V
osd_layout 0 14 1 1 H
osd_layout 0 15 25 7 V
osd_layout 0 16 7 2 H
osd_layout 0 17 7 3 H
osd_layout 0 22 14 4 V
osd_layout 0 23 24 2 H
osd_layout 0 26 25 7 H
osd_layout 0 28 23 14 H
osd_layout 0 31 1 1 V
osd_layout 0 34 10 2 H
osd_layout 0 46 23 1 H
osd_layout 0 53 13 12 H
osd_layout 0 55 2 12 H
osd_layout 1 1 1 14 V
osd_layout 1 6 23 14 V
osd_layout 1 7 12 14 V
osd_layout 1 9 0 7 V
osd_layout 1 13 25 3 V
osd_layout 1 14 1 1 V
osd_layout 1 15 25 6 V
osd_layout 1 16 7 2 H
osd_layout 1 17 7 3 H
osd_layout 1 22 14 4 V
osd_layout 1 23 24 2 V
osd_layout 1 25 24 5 V
osd_layout 1 26 25 7 V
osd_layout 1 28 23 14 H
osd_layout 1 30 1 13 V
osd_layout 1 31 1 2 V
osd_layout 1 46 23 1 V
osd_layout 1 53 13 12 H
osd_layout 1 55 2 12 H
osd_layout 2 1 1 14 V
osd_layout 2 3 8 6 V
osd_layout 2 4 8 6 V
osd_layout 2 6 23 14 V
osd_layout 2 7 12 14 V
osd_layout 2 9 0 7 V
osd_layout 2 13 25 3 V
osd_layout 2 14 1 1 V
osd_layout 2 15 25 6 V
osd_layout 2 16 7 2 H
osd_layout 2 17 7 3 H
osd_layout 2 20 9 2 V
osd_layout 2 21 9 1 V
osd_layout 2 22 14 4 V
osd_layout 2 23 24 2 V
osd_layout 2 25 24 5 V
osd_layout 2 26 25 7 V
osd_layout 2 28 23 14 H
osd_layout 2 30 1 13 V
osd_layout 2 31 1 2 V
osd_layout 2 46 23 1 V
osd_layout 2 53 13 12 H
osd_layout 2 55 2 12 H
osd_layout 3 1 1 14 V
osd_layout 3 3 8 6 V
osd_layout 3 4 8 6 V
osd_layout 3 6 23 14 V
osd_layout 3 7 12 14 V
osd_layout 3 9 0 7 V
osd_layout 3 13 25 3 V
osd_layout 3 14 1 1 V
osd_layout 3 15 25 6 V
osd_layout 3 16 7 1 V
osd_layout 3 17 7 2 V
osd_layout 3 22 14 4 V
osd_layout 3 23 24 2 V
osd_layout 3 25 24 5 V
osd_layout 3 26 25 7 V
osd_layout 3 28 23 14 H
osd_layout 3 30 1 13 V
osd_layout 3 31 1 2 V
osd_layout 3 46 23 1 V
osd_layout 3 53 13 12 H
osd_layout 3 55 2 12 H

master

set looptime = 500
set gyro_hardware_lpf = 256HZ
set gyro_lpf_hz = 40
set acc_hardware = MPU6000
set acczero_x = 53
set acczero_y = 18
set acczero_z = -90
set accgain_x = 4068
set accgain_y = 4102
set accgain_z = 4051
set mag_hardware = NONE
set mag_declination = 110
set magzero_x = 91
set magzero_y = -130
set magzero_z = -71
set baro_hardware = BMP280
set pitot_hardware = NONE
set min_throttle = 1100
set max_throttle = 1900
set motor_pwm_rate = 2000
set motor_pwm_protocol = ONESHOT125
set failsafe_procedure = RTH
set platform_type = AIRPLANE
set model_preview_type = 8
set servo_pwm_rate = 330
set small_angle = 180
set gps_sbas_mode = AUTO
set nav_rth_allow_landing = FS_ONLY
set nav_rth_altitude = 8000
set nav_rth_home_altitude = 6000
set nav_fw_launch_velocity = 200
set nav_fw_launch_thr = 1500
set nav_fw_launch_idle_thr = 1111
set nav_fw_launch_motor_delay = 100
set nav_fw_launch_spinup_time = 500
set nav_fw_launch_timeout = 10000
set osd_video_system = PAL
set name = SkyShadow

profile

profile 1

set fw_p_pitch = 4
set fw_i_pitch = 9
set fw_ff_pitch = 44
set fw_p_roll = 2
set fw_i_roll = 5
set fw_ff_roll = 24
set max_angle_inclination_rll = 600
set max_angle_inclination_pit = 600
set nav_fw_pos_xy_p = 74
set tpa_rate = 20
set tpa_breakpoint = 1600
set roll_rate = 66
set pitch_rate = 28

profile

profile 2

profile

profile 3

battery_profile

battery_profile 1

set bat_cells = 4

battery_profile

battery_profile 2

battery_profile

battery_profile 3

restore original profile selection

profile 1
battery_profile 1

save configuration

save


  • FC Board name and vendor: SPRACINGF3/NOX/OmnibusF7v2/ALL?
  • INAV version string: 2.1/2,2

@issue-label-bot issue-label-bot bot added the BUG label Jul 5, 2019

@issue-label-bot

This comment has been minimized.

Copy link

commented Jul 5, 2019

Issue-Label Bot is automatically applying the label BUG to this issue, with a confidence of 0.64. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

@digitalentity

This comment has been minimized.

Copy link
Member

commented Jul 5, 2019

Please provide details of your setup. Exact RC receiver model, FC model etc.

Also, you refer to the issue as "often occuring", so you probably have a scenario to reproduce. So, please reproduce and provide logs so we could look into what's happening under the hood.

Maybe you also have DVR recording of the video feed. I'm interested in the period near the disarm moment (a few seconds before/after).

@digitalentity

This comment has been minimized.

Copy link
Member

commented Jul 5, 2019

Moving to "Support" label until we confirm the bug.

@digitalentity digitalentity added Support and removed BUG labels Jul 5, 2019

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 5, 2019

Steps to reproduce are where they are suppose to be and so is the FC.
RC receiver is FrSkyXM+/DevoSBUS/ALL?

@digitalentity

This comment has been minimized.

Copy link
Member

commented Jul 5, 2019

@mooiweertje please provide details about exact setup that is having the issue. Referring to "ALL" is not helpful.

@giacomo892

This comment has been minimized.

Copy link
Collaborator

commented Jul 5, 2019

@mooiweertje
are you able to describe your full setup?
FC, Receiver and what do you use on the ground, even the Radio settings

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 5, 2019

To me it seems that the issue is not related to hardware but software logics. I also saw someone else reporting this is and thought is wat related to the GPS.

@giacomo892

This comment has been minimized.

Copy link
Collaborator

commented Jul 5, 2019

Are you running a so secret setup that you cannot share with us? Or what?
You opened an issue, now we do questions and you provide answers.

@digitalentity

This comment has been minimized.

Copy link
Member

commented Jul 5, 2019

@mooiweertje recently you are the only one who's reporting RTH/failsafe/disarm issue. The rest are flying happily without problems. It's likely related to a combination of hardware pieces, most likely your RX receiver and/or your radio.

If you fail to provide details about specific setup we won't be able to help

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 5, 2019

@mooiweertje please provide details about exact setup that is having the issue. Referring to "ALL" is not helpful.

With all I mean all my setups and friends as well. Three examples are SPRACINGF3,NOX and OmnibusF7v2. So I think it is ALL really, which is meant to be helpful.

@digitalentity

This comment has been minimized.

Copy link
Member

commented Jul 5, 2019

With all I mean all my setups and friends as well. Three examples are SPRACINGF3,NOX and OmnibusF7v2. So I think it is ALL really, which is meant to be helpful.

Now the new question - what are all of your friends' setups have in common? Same receiver model? Same radio failsafe settings?

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 5, 2019

My RADIO is a T8SG plus. Receiver Devo SBUS.

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 5, 2019

Me and friends have nothing in common and they may have different issues. Forget about friends for now.
Maybe it is radio related since I have an exotic radio setup.

@digitalentity

This comment has been minimized.

Copy link
Member

commented Jul 5, 2019

Make sure your receiver is set to "no pulses" or at least is configured to keep channel values on failsafe. SBUS protocol has a specific flag to signal a failsafe, but if you configure specific channel values - FC will happily execute what it's told to do by your radio receiver.

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 5, 2019

It is set to no pulse on FrSky. On the Devo SBUS receivers I have no influence on the way it failsafes. I use SBUS and PPM and both have this issue.

@digitalentity

This comment has been minimized.

Copy link
Member

commented Jul 5, 2019

My RADIO is a T8SG plus. Receiver Devo SBUS.

It is set to no pulse on FrSky

This doesn't seem to make sense to me.

My current assessment is either faulty hardware (RC receiver) or misconfiguration of RC receiver.
Please provide either a log or a DVR recording of the issue so we can know the reason for disarm from FC perspective)

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 5, 2019

Make sure your receiver is set to "no pulses" or at least is configured to keep channel values on failsafe. SBUS protocol has a specific flag to signal a failsafe, but if you configure specific channel values - FC will happily execute what it's told to do by your radio receiver.

You are saying I should be aware of the failsafe value of the arm switch/channel? I'll have a look at that,

@digitalentity

This comment has been minimized.

Copy link
Member

commented Jul 5, 2019

You are saying I should be aware of the failsafe value of the arm switch/channel? I'll have a look at that,

Obviously. If your receiver is telling FC to disarm, FC will execute.

@Pairan

This comment has been minimized.

Copy link

commented Jul 5, 2019

perhaps this one helps?

set failsafe_throttle_low_delay = 0

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 5, 2019

You are saying I should be aware of the failsafe value of the arm switch/channel? I'll have a look at that,

Obviously. If your receiver is telling FC to disarm, FC will execute.

Yes, I checked the settings and they are correct. But I had a feeling it is related to something like this. It's popping in and out of failsafe and something is timed wrong and picking up the channel of the arm switch wrong. I'll try to find out how the Devo SBUS receiver tells the FC it has lost connection.

Maybe it lowers all channels and INav is sometimes picking up the arm channel before the the signal it failsaves on.

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 5, 2019

I've been looking at what happens while connected to the configurator receiver tab when I turn of the transmitter. It holds all channels and the red parachute turns on.
When I change failsafe settings in the transmiiter nothing changes in the behavior of the receiver.
As far I can see in the configurator receiver tab.

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 5, 2019

failsafe_throttle_low_delay

I have never changed that option.

Entering CLI Mode, type 'exit' to return, or 'help'

# get failsafe_throttle_low_delay
failsafe_throttle_low_delay = 0
Allowed range: 0 - 300

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 5, 2019

Are you running a so secret setup that you cannot share with us? Or what?
You opened an issue, now we do questions and you provide answers.

I have 7 setups running iNav and they all have this issue.

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 5, 2019

I have 2 setups with similar hardware running ArduPilot without issues.

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 5, 2019

Moving to "Support" label until we confirm the bug.

What can I do to prove this is a bug?

I agree it is possible the bug can be in the receiver. I have 13 of these receivers and they all behave the same though.

I am a programmer and looked into the code quickly but there is lot going on when failsafe initiates so I only spend an hour digging through the labyrinth.

@digitalentity

This comment has been minimized.

Copy link
Member

commented Jul 5, 2019

What can I do to prove this is a bug?

I agree it is possible the bug can be in the receiver. I have 13 of these receivers and they all behave the same though.

Record a blackbox log + DVR of the issue.

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 5, 2019

What can I do to prove this is a bug?
I agree it is possible the bug can be in the receiver. I have 13 of these receivers and they all behave the same though.

Record a blackbox log + DVR of the issue.

I just saw one LoRa wing disappear into a suburban area so I need some time to mentally recover from this event before triggering it on purpose.

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 6, 2019

@teckel12
You have my settings. Bla bla. This is the third time you make me wonder why you don't read carefully what I write here.
This issue is quite serious.

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 6, 2019

        case FAILSAFE_LANDED:
            ENABLE_ARMING_FLAG(ARMING_DISABLED_FAILSAFE_SYSTEM); // To prevent accidently rearming by an intermittent rx link
            disarm(DISARM_FAILSAFE);
            failsafeState.receivingRxDataPeriod = millis() + failsafeState.receivingRxDataPeriodPreset; // set required period of valid rxData
            failsafeState.phase = FAILSAFE_RX_LOSS_MONITORING;
            failsafeState.controlling = false;  // Failsafe no longer in control of the machine - release control to pilot
            reprocessState = true;
            break;

image

You want to see the reason of disarm? It's in the stats in OSD. Why didn't you ask about this? I told you I have seen the stats.

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 6, 2019

Googling on this shows I am not the only one having issues with disarming on failsafes. I think you should take this more serious. It can be there is a mis between my receiver (Devo RX-SBUS) and iNav. But who is to fix this mishap? Do I have to fix it or can you help?

@fiam

This comment has been minimized.

Copy link
Member

commented Jul 6, 2019

@teckel12
You have my settings. Bla bla. This is the third time you make me wonder why you don't read carefully what I write here.
This issue is quite serious.

Consider this your first, last and final warning. This kind of attitude is not welcome here.

You want to see the reason of disarm? It's in the stats in OSD. Why didn't you ask about this? I told you I have seen the stats.

You only told us you had no logs and no DVR, you didn’t mention you had seen the disarmed screen until a couple of comments ago.

You need to understand that a flight controller is a quite complex piece of software with literally hundreds of edge cases. The more information you tell us, the more likely we’ll be able to find the root cause of the problem (which might be a bug, might be unclear documentation, might be hardware failure, might be user error, or any combination of those).

So if you saw the disarmed screen. Can you let us know the following details?

  • Can you confirm that the disarm reason was “FAILSAFE”?
  • Did you see any system messages before or after the disarm?
  • How many GPS satellites was the OSD showing?
  • What was the HDOP value?
  • Was the distance to home drecreasing or increasing while this happened?
  • Was the aircraft entering and exiting failsafe several times or just permanently in failsafe and waiting for you to regain control?
@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 6, 2019

@teckel12
You have my settings. Bla bla. This is the third time you make me wonder why you don't read carefully what I write here.
This issue is quite serious.

Consider this your first, last and final warning. This kind of attitude is not welcome here.

My ways are progressive and direct as is my attitude. My attitude is fine.

I had a pleasant talk with digitalentity and I now know what to look for first. I didn't think of the receiver maybe doing something odd when close around RXLOSS, since I have used Devo for many years with 0 issues, which doesn't mean there are none. So thanks digitalentity.

You want to see the reason of disarm? It's in the stats in OSD. Why didn't you ask about this? I told you I have seen the stats.

You only told us you had no logs and no DVR, you didn’t mention you had seen the disarmed screen until a couple of comments ago.

No I mentioned it earlier. But that's ok.

You need to understand that a flight controller is a quite complex piece of software with literally hundreds of edge cases. The more information you tell us, the more likely we’ll be able to find the root cause of the problem (which might be a bug, might be unclear documentation, might be hardware failure, might be user error, or any combination of those).

I know. I said before I am a programmer and looked into the code but there is lot going on when failsafe initiates so I only spend an hour digging through the labyrinth.

So if you saw the disarmed screen. Can you let us know the following details?

  • Can you confirm that the disarm reason was “FAILSAFE”?

The reason does not look like failsafe. iNav went directly from normal AIR flight to disarm. Now after reading source code I realize this info is very useful and next time this happens I will check the disarm screen what the reason of disarm is.
It probably said SWITCH because I probably would have noticed it saying something else since I have seen this screen a million times.

I've had this disarm problem a few weeks ago at 200m range because the receiver antenna was broken so I have a little experience with the condition, I was able to gain control then by holding the transmitter high above my head and rearming. This is why I am sure this DISARM issue is related to RXLOSS. I think that around 1/5 RXLOSS end up in DISARM iso FAILSAVE.
LoRa holding the transmitter above my head doesn't help to regain signal unfortunately.

  • Did you see any system messages before or after the disarm?

No messages directly before or after the disarm.

  • How many GPS satellites was the OSD showing?

around 20

  • What was the HDOP value?

around 1.1

  • Was the distance to home decreasing or increasing while this happened?

increasing, 2,5 up

  • Was the aircraft entering and exiting failsafe several times or just permanently in failsafe and waiting for you to regain control?

The aircraft had entered failsafe about three times. I took over by moving sticks. There must have been something on the ground in that area interfering with my radio signal. In Km
First RXLOSS ranging at 3
Second RXLOSS at 2,7
Third at 2.3
disarm at 2.5, attempting to fly away from the source of interference on the ground.

@digitalentity

This comment has been minimized.

Copy link
Member

commented Jul 6, 2019

You have my settings. Bla bla. This is the third time you make me wonder why you don't read carefully what I write here.

I agree with @teckel12 - this behavior is borderline. We all are trying to help you here, but we have ZERO data about the issue and since you don't have any recordings of the issue we would appreciate any tiny detail you can share.

The reason does not look like failsafe.

Stats screen show a line named "Disarm reason". If that reason says "SWITCH", then firmware executed a legitimate switch disarm, meaning this is exactly what your receiver (or radio) was sending and it has nothing to do with failsafe. If you are sure you didn't touch the arming switch, then it's most likely your receiver starts sending odd channel values when repeatedly going into failsafe and out.

A mitigation could be to set disarm_kill_switch to OFF - this way you will only be able to disarm when throttle is at zero. This is less secure for emergencies, but more reliable.

There's also an option to have an airplane always armed (via fixed_wing_auto_arm setting).

However, I would dig more into trying to reproduce the issue on the bench with BB enabled.

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 6, 2019

You have my settings. Bla bla. This is the third time you make me wonder why you don't read carefully what I write here.

I agree with @teckel12 - this behavior is borderline. We all are trying to help you here, but we have ZERO data about the issue and since you don't have any recordings of the issue we would appreciate any tiny detail you can share.

I'm sorry about that but I said a few times I will try to reproduce next week, with BB log and DVR. I have to go into a large open space to reproduce this issue. On my bench this issue does not occur.

The reason does not look like failsafe.

Stats screen show a line named "Disarm reason". If that reason says "SWITCH", then firmware executed a legitimate switch disarm, meaning this is exactly what your receiver (or radio) was sending and it has nothing to do with failsafe. If you are sure you didn't touch the arming switch, then it's most likely your receiver starts sending odd channel values when repeatedly going into failsafe and out.

A mitigation could be to set disarm_kill_switch to OFF - this way you will only be able to disarm when throttle is at zero. This is less secure for emergencies, but more reliable.

There's also an option to have an airplane always armed (via fixed_wing_auto_arm setting).

Sounds like a solution. Thanks.

However, I would dig more into trying to reproduce the issue on the bench with BB enabled.

I'm sorry about that but I said a few times I will try to reproduce next week, with BB log and DVR. I have to go into a large open space to reproduce this issue. On my bench this issue does not occur.

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 7, 2019

I was imagining. Maybe when the radio signal gets weaker the receiver misses a few pulses but doesn't see it as RXLOSS yet. It might send a low pwm value to the fc for the channel the pwm pulse was missing.

If that is so I could reverse the arm channel on the radio and mode in INav. So INav is armed when pwm is low and disarmed when high.

I hope to reproduce the issue soon and confirm our hypothesis.

@teckel12

This comment has been minimized.

Copy link
Contributor

commented Jul 7, 2019

@mooiweertje I would suggest:

set disarm_kill_switch = OFF
set switch_disarm_delay = 250

To avoid accidental disarm by switch. Also, if you do disarm, be sure to lower throttle to re-arm.

But getting blackbox logs and FPV video will confirm what's going on for sure.

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 7, 2019

Hey this switch_disarm_delay...
Thanks. Once we know what exactly is going on and the timing of events I feel confident there will be a secure solution to this issue.

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 8, 2019

I'm preparing the test session setting up blackbox. I looked at a log but can't find the channel where the arm switch is on. Channel 5.

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 8, 2019

I've got a DVR now. Unfortunately my BB is only 2MB and it's full every time the problem kicks in.
The wing is a meter avove ground on some shrubbery. I'm walking in and out of range about 5 meters up and down. When in FS I wiggle the sticks. I'm not touching any switches.
Remarkable is that is goes from manual mode to angle just before the the disarm screen.
https://youtu.be/Hd7KlnVdMaM
I'll try again tomorrow.

@stronnag

This comment has been minimized.

Copy link
Collaborator

commented Jul 8, 2019

How long does it take?

set blackbox_rate_denom = 512

Gives you c. 90 minutes on 2MB. On my SPRF3 it was 32% full after 30 minutes today. We don't need event loop precision to see what's happening.

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 8, 2019

The last log I recorded about three mins is here: https://we.tl/t-69adcvieaN
Maybe there is something interesting in there..?

I can't find RC channel 5 which is the channel to ARM/DISARM.

There seem to be some ARM state changes during the FAILSAFE state.

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 8, 2019

I got a complete one now BB and DVR. It happens after about 45 seconds.

https://youtu.be/6T-rTiG0zso

blackbox_log_2019-07-08_211338.TXT

@stronnag

This comment has been minimized.

Copy link
Collaborator

commented Jul 8, 2019

$ inav_modes.rb /tmp/blackbox_log_2019-07-08_211338.TXT
blackbox_log_2019-07-08_211338.TXT: INAV 2.2.0 (5e5551bd3) NOX
Iteration	Time(s)	Elapsed(s)	State
        0	 549.8	(   0.0)	nav_state_undefined (0)
    27488	 563.9	(  14.0)	F/S=RETURN_TO_HOME (1505,1507,1489,1092);(0,1)
    27488	 563.9	(  14.0)	nav_state_emergency_landing_in_progress (23)
    59264	 579.9	(  30.1)	F/S=IDLE (1504,1869,1490,1092);(1,1)
    59264	 579.9	(  30.1)	nav_state_idle (1)
    83104	 592.1	(  42.3)	end of log
Disarmed by: SWITCH

silly RX ...

OTOH, other than wasting our time, I don't really get what something sitting on the ground in manual really shows.

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 8, 2019

It seems to drop at least channel 5 and 7 very shortly sometimes,which is arm and flight mode (ANGLE/AIR/MANUAL) switch, when it has bad signal.
Can I see the value of channel 5 in the log?

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 8, 2019

$ inav_modes.rb /tmp/blackbox_log_2019-07-08_211338.TXT
blackbox_log_2019-07-08_211338.TXT: INAV 2.2.0 (5e5551bd3) NOX
Iteration	Time(s)	Elapsed(s)	State
        0	 549.8	(   0.0)	nav_state_undefined (0)
    27488	 563.9	(  14.0)	F/S=RETURN_TO_HOME (1505,1507,1489,1092);(0,1)
    27488	 563.9	(  14.0)	nav_state_emergency_landing_in_progress (23)
    59264	 579.9	(  30.1)	F/S=IDLE (1504,1869,1490,1092);(1,1)
    59264	 579.9	(  30.1)	nav_state_idle (1)
    83104	 592.1	(  42.3)	end of log
Disarmed by: SWITCH

silly RX ...

OTOH, other than wasting our time, I don't really get what something sitting on the ground in manual really shows.

It shows that it disarms while I am not touching any switches.

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 8, 2019

Often when rxSignalReceived becomes true it disarms and changes flight mode. Normally this would be while it is in failsafe and it is not a problem but in this scenario rxSignalReceived becomes false and true so quickly that failsafe has not been executed yet, so it disarms.

I can not find the actual channel 5 value in the log so I can not determine if the receiver is giving the wrong value or this model receiver is just faster switching rxSignalReceived than other models.

Can I see the value of RC channel 5 in the log?

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 8, 2019

What do you suggest to do to workaround this RX flaw?

failsafe_delay = 0 // Could work!?!
set switch_disarm_delay = 1000 // Could work!?!
set disarm_kill_switch = OFF // Won't work..? Throttle may also be ZERO in the flawed state.

@digitalentity

This comment has been minimized.

Copy link
Member

commented Jul 9, 2019

TL;DR: this is working as intended from firmware side.

Firmware trusts the receiver to send consistent data and if the receiver is setting odd channel values and odd failsafe flag, there is nothing you can really do to fix the issue on firmware side rather than disabling possibility to disarm alltogether (with auto-arming or high switch_disarm_delay).

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 9, 2019

Is it possible to see the actual value of RC channel 5 in the log?

@digitalentity

This comment has been minimized.

Copy link
Member

commented Jul 9, 2019

No, we don't log auxiliary channels

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 9, 2019

Can you confirm the bug is in the RX? I will address this issue to Walkera.

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 9, 2019

Thanks all for your help and sorry for the snarky or whatever attitude. I've got a trauma on this accident and having nightmares crashing with airplanes into cities for three nights in a row.
I got a few solutions to this problem thanks to your support.

Without knowing the exact implementation I think failsafe_delay = 0 is the most secure solution which I will try first.

@digitalentity

This comment has been minimized.

Copy link
Member

commented Jul 9, 2019

The only possible sequence of events that could cause a DISARM_SWITCH event is when all of the following conditions are satisfied for 250 ms or more (250ms is default value for switch_disarm_delay):

  1. Receiver is reporting a valid RX signal via non-set S.BUS failsafe flag (bit mask 0x08 of sbus packet flag field)
  2. Receiver is reporting a arming channel value that doesn't match ARMING flight mode.
  3. Failsafe procedure is not executing.
  4. Throttle is low or disarm_kill_switch is set (by default disarm_kill_switch is set).

Considering your current configuration - the real problem is that receiver drops arming channel low when entering or exiting failsafe.

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 9, 2019

@digitalentity

This comment has been minimized.

Copy link
Member

commented Jul 9, 2019

This is what probably happen:
image

See those gaps between arming channel going low before/after receiver signals failsafe - if those are bigger than 250ms - your plane will disarm. From firmware perspective - that's WAI

This is how the good receiver should behave:
image

or like this:
image

Setting failsafe_delay = 0 won't solve the problem, since disarm can only happen when receiver tells the firmware that the signal is valid (not in failsafe). So, from firmware perspective there is no reason to enter failsafe at all.

Please don't confuse receiver failsafe (which is receiver telling the FC that signal is lost) and INAV failsafe (which is firmware executing an emergency procedure). Disarm can only happen when neither receiver not INAV is in failsafe mode.

@mooiweertje

This comment has been minimized.

Copy link
Contributor Author

commented Jul 9, 2019

But this is what really happens analyzing the log:
Unsafe

If iNav failsafe would immediately go into failsafe the disarm would not have any affect.

image

I now know what the issue is. I reported this at Walkera. Let's see what they say about it.
I reversed the arm channel so lower channel now is arming and upper is disarm. Should prevent things to go bad.

Thanks for your help!!

@mooiweertje mooiweertje closed this Jul 9, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.