Yes, by default short RC failsafe is circle AKA lets loiter without requiring GPS and try to get signal back.
2 Likes
Hi @tridge
The situation is that the compass works during the whole flight but the EKF3 system stops making estimates on magnetism.
This situation has been repeated in several flights.
Attached is a log.
Plane-4.5.6 has been released with a small number of changes from 4.5.5.
Changes vs 4.5.5 are in the release notes and also copied below
- Board specific enhancements and bug fixes
- 3DR Control Zero H7 Rev G support
- CUAV-7-Nano support
- FoxeerF405v2 servo outputs increased from 9 to 11
- Holybro Pixhawk6C hi-power peripheral overcurrent reporting fixed
- iFlight 2RAW H7 support
- MFT-SEMA100 support
- TMotorH743 support BMI270 baro
- ZeroOneX6 support
- Minor enhancements and bug fixes
- Cameras using MAVLink report vendor and model name correctly
- DroneCAN fix to remove occasional NodeID registration error
- GPS NMEA and GSoF driver ground course corrected (now always 0 ~ 360 deg)
- ICP101XX barometer slowed to avoid I2C communication errors
- IMU temp cal param (INSn_ACCSCAL_Z) stored correctly when bootloader is flashed
- IMU gyro/accel duplicate id registration fixed to avoid possible pre-arm failure
- Logging to flash timestamp fix
- OSD displays ESC temp instead of motor temp
- PID controller error calculation bug fix (was using target from prev iteration)
- Relay on MAIN pins fixed
1 Like
The problem is that you have significant interference from motor current, particularly on the Z axis. We can use compensation using the current reading, but much better to move the compass to a location where there is less interference.
Thanks for answering the question @Tridge.
I know about the interference problems with this compass. Using MagFit normally with the results of 2 or 3 flight records the compasses are perfectly calibrated. Although this is not the case with this Foxeer M10Q-180.
What I was surprised about was the “disappearance” of XKF4[0].SM, I was prepared to find values higher than 1 but not for there not to be any.
you’re right, that is a bit odd. I suspect it switched to GPS based yaw, but there is usually a message logged when that happens. For 4.6.x we log XKFS.MAG_FUSION which would tell us if it switched to GPS fusion.
You could enable replay logging with LOG_REPLAY=1 and LOG_DISARMED=3 and that would allow us to see what is happening if this happens again. Apart from that I can’t see the cause, sorry!
I provide log with parameters LOG_REPLAY=1 and LOG_DISARMED=3.
I notice that as soon as the unit is switched on, a compass error is displayed as resolved (Subsys,3 / Ecode,0).
As you said the moment XKF4[0].SM stops providing information the change to GPS based yaw occurs.
As always thanks in advance for your time.
The UAVLogViewer program is not working for me right now. After downloading the file, the .bin on the display shows the image that appears on the screenshot for a long time. Maybe the developers have changed this program and it works with new firmware? I have firmware 4.3.7 for the aircraft
Hi @tridge
Please, did you do something with the units displayed on OSD between 4.4.4 and 4.5.0 and higher? Because this is the difference (only reflashed from one version to another on Matek H743):
