RC Failsafe Trigger Update

[bozkurthan]

Describe problem solved by the proposed pull request
RC Failsafe isn't triggered when PPM signal is valid. These changes update Failsafe trigger logic for RC input. RF Modules keep sending valid PPM signal when the RC Transmitter is lost.
RF Modules which are in the air send PPM signal with same type when lost the signal from ground.

Test data / coverage
The discussion on testing and log can be seen on this topic #12381 .

[hamishwillee]

So how does the fix work? ie RC is lost and the receiver keeps on sending the same values it had at that point. How does PX4 recognise that these values are no longer valid and trigger the failsafe?

[bozkurthan]

Hello @hamishwillee ,
Well, RF Receiver module receives PPM signal ground RF Transmitter module which is connected to RC. But when we lost signal from ground receiver sends these values (After 286. line):

When RF module lost its communication, 8 channels PPM signal turns 16 channels. Also, First 12 channels have valid signal (1000 microseconds) and last 4 channels have 0 value signal. And I tried to switch number of channels from 8 to 12 and 14, also these statements send same PPM signal when RF lost its communication. So, I added code fragment to rc_update.cpp, which controls to this problem.

PX4 checks PPM signal after this statement:
https://github.com/PX4/Firmware/blob/bc9fb26ccd6fd00406a6e8c47a54d803804cb3f8/src/modules/sensors/rc_update.cpp#L230-L234

Then if it recognizes 16 channels:

-Firstly, checks first 12 channels' value. If they all have values between 1000 and 1005 microseconds it is going to the second step. between 1000 and 1005 microseconds it is going to the second step. Else, i.e. channel 2 has 1200 microseconds value which is valid value for PX4, it changes signal_lost flag to true and bypass the remaining operations with break.

-Secondly, checks last 4 channels' value. If their all values are 0, then signal_lost flag turns true. Else, it is same as above process.

[hamishwillee]

@bozkurthan So do all receivers have this behaviour? Or more importantly, are there any cases where this check will give a false positive on other receivers?

@julianoes I know we can't make check on receiver type at this level, but could we make some checks at driver level and modify output so that they make sense at this level? That would seem "cleaner".

[bozkurthan]

@hamishwillee Yes, you are right. I mentioned before on this issue #12381 about what we can do.

Furthermore it should be configurable for RC types (e.g. RFD900 radios send 12 chs and 1000 pwm per ch). When we choose RC type, failsafe scenario can be change by itself. Also, we have type of RC in message system which detected by driver module.

https://github.com/PX4/Firmware/blob/12fcddd288911a32060b7fd2a52c22ab65290535/msg/input_rc.msg#L3-L17

[hamishwillee]

Thanks very much @bozkurthan . As long as @julianoes is happy that this can't break anything else :-)

[julianoes]

@dagar what's up with Jenkins?

[julianoes]

Thanks, this looks correct.

Could you add the specific Rx model in the comment for a future reader?

[hamishwillee]

@julianoes Just a ping to remind you about this. I sort of stalled on the associated docs. It isn't clear to me why this fix couldn't be lower in the stack.

[julianoes]

@bozkurthan could you please rebase this on master and force push? Hopefully CI will pass.

[bozkurthan]

Ops. I think I did something wrong @julianoes . Too many files are changed by selecting Rebase. I can create new PR with newest master for this.

[bozkurthan]

git rebase master gives following error.. I don't want to skip this.

hanco@CRT-boi:~/Firmware$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: Update RC Input Failsafe
Applying: Update RC Input Failsafe
Applying: uORB::Subscription minor API cleanup
Using index info to reconstruct a base tree...
M	src/modules/commander/Commander.cpp
M	src/modules/mavlink/mavlink_orb_subscription.cpp
M	src/modules/uORB/Subscription.cpp
M	src/modules/uORB/Subscription.hpp
M	src/modules/uORB/SubscriptionCallback.hpp
M	src/modules/uORB/SubscriptionInterval.hpp
M	src/modules/uORB/uORBDeviceMaster.cpp
M	src/modules/uORB/uORBDeviceNode.cpp
M	src/modules/uORB/uORBDeviceNode.hpp
M	src/systemcmds/tests/test_microbench_uorb.cpp
Falling back to patching base and 3-way merge...
Auto-merging src/modules/uORB/SubscriptionCallback.hpp
CONFLICT (content): Merge conflict in src/modules/uORB/SubscriptionCallback.hpp
error: Failed to merge in the changes.
Patch failed at 0003 uORB::Subscription minor API cleanup
Use 'git am --show-current-patch' to see the failed patch

Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".

I followed instruction from this GIT Examples

[bozkurthan]

Closed, unable to merge because of jenkins problem.

[julianoes]

It just looks like the style check failed. I will run make format and try to force push.

[julianoes]

Ok, this is a git mess, cherry-picked the commits into: #13218.