as log shows, AP decided to roll the plane to the left extreme - desired roll suddenly dipped to -40 and actual roll followed, ALL despite of lack of such input from RC and a very stable horizontal flight.
this was then accompanied by this message: EKF2 IMU0 yaw aligned to GPS velocity
and immediately followed by erradic pith variations (looks like vibration on the video). things stabilized afterwards.
You lost your RC signal. In the log you can see how they just go flat and unchaining. Then the roll input drops to 987, probably min value. Because the FC didnāt acknowledge what should have been a failsafe condition it figured thatās what you wanted so thatās what you got. I would suggest you check the wiring and look for any kind of physical fault in the setup, and also verify that your RX/TX failsafes are setup correctly. I didnāt include it in the image but the RX.ERRORS value goes very high at the same time.
I think the vibrations are just the PID tuning. The plane is still on stock tuning, and probably just needs time either going thought the autotune procedure or manual tuning. Auto tune only works with full stick deflection and needs at least 20 cycles.
Thanks @Allister , this is very helpful. Couple of questions if thatās okay:
How do you select rx:errors for the visualization?
With crossfire what failsafe mode would you suggest? Hold , if it exists? Btw, under normal conditions when I disconnected tx the failsafe behaved fine. Channels stayed fixed until RTL kicked in after a second or two (after a beep)
Wiring is solid. Could this be possibly interference from 1.3ghz vtx? Its my first setup of this sort.
I figured oscillations were related to P tuning. Do you guys have any presets I could look at?
RX Errors are under the radio or RAD tab on the telemetry viewer in both Mission Planner and APM2. The image below is from APM2 on a Mac, but I just looked at MissionPlanner on my PC and itās pretty much the same.
Iām going to defer the Crossfire failsafe question to someone who knows more about it. Iāve never used it so I donāt want to give you bad advice.
Interference from your VTX is possible. I know from other experiences that 1.3ghz VTX systems will have issues with 900MHz RC systems like Crossfire. If everything check out okay on the ground then you could try a LOS flight with the VTX disabled. Then compare the RSSI telemetry values in the log between the flights and see if things improved.
I think you should be able to run an autotune on that plane just fine. I go full stick deflection and hold it for about a second, then full opposite deflection. At least 20 cycles for pitch, and 20 cycles for roll. If someone has some values to give you a head start thatās great but youād still need to fine tune it for your build.
careful, guys, donāt jump to conclusions prematurely ā¦
the ārollā issue has been reported now by āmanyā people ā¦ with varying setups ā¦ the one commonality seems to be a roll jump, not pitch, not yaw, always roll
so look at all evidence not just an isolated point
Thanks, good point @olliw42. This now reminds me of an experience I had with arducopter when my drone was returning from a long range mission, coming back into the radio range (frsky in that case). During that recovery period AC code would for a moment revert to channel defaults, induced yaw left and in my case also disarm the drone using the arming switch channel default, unfortunately drone fell to the ground.
AC team were able to create a patch for me.
I will dig out that thread later.
Since then I switched to failsafe HOLD on all frsky RXs and turnoff radio immediately after takeoff and just prior to RTL land stage.
Iām going to concede and say I think youāre on to something. I havenāt been following the issues with the H743 boards since Iām still using different Matek F405 boards. But looking at things again the only things I notice that are frozen are the RCIN and DESPITCH/DESROLL. Things like IMU, Gyros, ACC, RCOUT all still seem to be active. I donāt know if thatās consistent with the problems others are having but maybe itās more evidence for solving a bigger problem on the H743.