Today I had a bad crash with my Plane. It changed the flightmode from an auto mission to manual flight mode and crashed,
I had a look at the telemetry log and I am very confused. It changed to Circle on time and if I look at the RC_CH input (CH 8 is my flightmode channel) the PWM does not change. How can that be?
At the end of my second telemetry log, the PWM changes on its own from roughly 1300 ms to 1800 ms which induced the change to manual flight mode. But I did not touch the TX nor the GCS.
FC: Pixhawk 4 with ArduPlane 3.9.4 installed.
TX: FrSky Taranis X9D+ SE D16 mode with failsafe set to âno pulsesâ
RX: FrSky RX8R
This is, where you find the tlogs from the flight. https://www.dropbox.com/sh/qc5dhaqca46kogl/AAD_NEUhue1279R2vTdzKulRa?dl=0
Maybe someone of you gus has an answer what happened here? Do I need to set up my Taranis differently?
I played you tlog until the crash watching the channel 8 input. It was steady until near the end. There were a few glitches where it changed to 1921 ms eventually triggering the mode change. You were far away and maybe had some trees blocking the signal. Your telemetry was also dropping out a lot. I must conclude that your receiver failsafe settings are not as you intended them to be. You must test the receiver behavior when the Tx is shut off. Monitor the receiver outputs on the RC calibrate tab in Mission Planner and see what channel 8 does on signal loss.
Hi Greg,
thanks for letting me know. Yeah I had some Telemetry and RC losses but that shouldnât affect the plane and should not change the flightmode either. If you have a close look at the tlog you find sometimes PWM changes to for example 1400 ms.
I followed your hint and had a look at the RC calibration screen. I switched off the transmitter and nothing happens to the PWM value.
MP then tells me it is in Failsafe.
I had the same problem some days ago except I was lucky because the mode change was from auto to q_hover (quadplane hover).
I also have a X8R rx and my mode channel is also channel 8.
When the mode change happened the plane was behind trees and when I looked at my log I found a lot of glitches concerning all channels until the one that changed the mode. I came to the conclusion that the X8R failsafe does not work properly when connected through SBUS so I have connected the X8R through pwm output and cppm converter.
I confirm, when the x8r is connected to the pixhawk with SBUS the pwm channel 3 value remains unchanged when I switch off the TX despite the failsaife is correctly set. But when connected with cppm, behavior is correct.
The weird thing is when I switch off the TX with the plane flying, the RTL is correctly triggered whatever cppm or SBUS (test made from FBWA mode).
I tried out the all the modes and FS with my TX again and if I do it on the bench, everything works fine. So if I switch off the TX, Pixhawk goes into failsafe mode and switched into Circle if I had it in manual mode when it was switched on. @losawing What I recognised was the same as on your Pixhawk: CH3 often seems not to change. But: is this a problem if Pixhawk recognises the failsafe???
All other channels seemed to have glitches as you mentioned as well! Thats why it crashed so badly. It tipped the nose fully down and the aileron on full left or right!
The X8R should send the preset position whenever the signal is lost, not send glitches, this is why I think the x8r is faulty at least when it is connected with SBUS. I did not make a test to go far and loose the signal since I have connected my X8R with cppm converter so I cant say. I think I will make the test on the ground using the transmitter range check feature.
If I switch the TX off it does not send glitches. The glitches appeared only in the log when the plane crashed. CH 1 and 2 go to 1500 ms PWM and the rest seems to stay at the last position. I did not check CH4.
Btw I have a RX8R but I think that makes no difference.
Good hint: I will try the range check out and see what happens!
Hi Konrad, look at RCIN.C1 to C14. From the beginning, all channels show serious glitches. You would not have been able to perform a manual flight (see C1âŚC4).
@KadaverJoe the problem was you were using the generic âfmuv5â firmware not the Pixhaw4 firmware. When I released 3.9.4 I put in a fix for the Pixhawk4 SBUS issue, but I only put it in the Pixhawk4 firmware, as it was not needed for the other two fmuv5 boards.
As several people made the mistake that you made and used fmuv5 on a Pixhawk4 I have since applied the same fix to the fmuv5 generic build for the 3.9.5 and 3.9.6 releases.
My apologies for the confusion!
One thing I forgot on the test: I updated my Pixhawk 4 to the designated Pixhawk 4 fw. So the problem shouldnât appear again but my test was kinda useless for that questionâŚBut I think tridge answered the question anyway.
@tridge the problem for me was that I updated my Pixhawk 4 over MP and it doesnât suggest the designated firmware. And I could not find any information about that as a âwarningâ or something. So it would be great to have an info about that. It problably would have saved an RC planes live
Or is there any info I did not see?
right, and this is indeed a problem. The Pixhawk4 bootloader that comes with the board doesnât actually give any indication to MP that it is a Pixhawk4. It just says âfmuv5â.
I have asked Michael to add a drop down listing boards when there are multiple that match, but meanwhile I have changed fmuv5 so that it is safe on Pixhawk4.
This really was our screw-up, as we should have realised this could happen. Sorry!
Thanks for letting me know! Could you let the user know in the future release notes if this software is usable for Pixhawk 4 or if there will be a different one specially for Pixhawk 4? That would save a lot of confusion
The current stable release and all future stable releases will be good on the Pixhawk4. Once we knew of the problem we put out a new stable release to fix it.
