We tested today GPS yaw in the first source and GSF in the second one. The source of position and velocity was GPS for both set of sources; we did not use source 3. When we switched to source 2 it was like the correction, fusion, of yaw stopped even if the GSF was running since the innovation remained constant for long periods of time:
It eventually started getting out of control as it can be seen in the position control, and we switched back to source 1 for avoiding to crash. As it can be seen in the plot below, we tried it several times and eventually even the EKF sent an error message.
We have tried with compass as first source and it worked very good, but here it seems that it is just not using the GSF for correction. It is still running.
Something worthwhile noticing in that log that we discovered today is that the GSF algorithm seems to not be working in the lane 1; in the lane 2 it is working since it looks very similar to the yaw of the two F9 GPS:
Possibly a tuning vs IMU data quality issue. If you can reproduce with LOG_DISARMED=1 and LOG_REPLAY=1 then I can replay the log and come up with a fix. TXS.
Something else to remember when looking at GSF yaw data is that the algorithm also outputs a 1-sigma uncertainty which is logged in XKY0.YXS. The main EKF won’t use the yaw when the 1-sigma uncertainty is above 15 degrees.
We enabled the LOG_REPLAY and LOG_DISARMED. Please find the log in the link below:
Something worthwhile mentioning is that we had great results flying with the GSF in small quadcopters of 10 inches propellers. This log and the previous one were acquired flying a Hexacopter of 23 inches propellers.
I can replay your log on beta5. When using beta 6 the replayed EKF-GSF yaw data for the replay is not being logged so will get that fixed first. We have made a number of improvements between beta5 and beta6 including double precision processing on H7 autopilots which would be relevant for your hardware. Thanks for letting me know about the size of your quad. The Cube Orange internal isolator assembly amplifies vibration between 90 and 130 Hz and attenuates it above that. It is likely your blade passage frequency (2 x motor RPM x 60) is in this range. The GSF will be sensitive to lower frequency vibration immediately after arming when the uncertainty in yaw is high and the log shows it gets a wrong intial estimate that takes several seconds to fix. Will get back to you when I have the GSF replay data for beta6.
I wonder if the harmonic notch filter can help to prevent this situation from happenning. In the past, we had run vibrations tests on a similar hexacopter with the same propellers, and found that the harmonics in the range you mention sometimes do not entirely match the magnitude between the different IMUs. That may explain why it does not happen in all the lanes.
As an alternative, do you think is a good idea to tune the three-state Kalman filter process noise? If the low vibrations after arming are a problem, we think it may help to increase it. I believe, if this is a good idea, that it needs to happen on the source code itself since there are not EK3_XXXX_P_NSE parameters unless they are shared with EK3_ACC_P_NSE and EK3_GYRO_P_NSE.
I’ll be looking at the process noise when I do the replay. We may need to make it user adjustable. The EKF runs on a slower update rate internally using integrated and down sampled data so I wouldn’t expect a notch filter to make a difference. Also from memory I don’t think its in the signal patch for the delta velocities used by the EKF.
There is a known issue where the notch filter plays very badly with flow hold because I think it messes with the expected update latency. It would be nice to make the EKF and notch play nicely together but that’s above my level of expertise!
