Servers by jDrones

GPS yaw and GSF in different sources

Hello everyone,

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.

Please find attached the log in the link below:

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.

1 Like

Hi @sbaccam,

I guess this is very similar to this earlier report? We haven’t really looked into this much yet but hopefully we will in the coming week or two.

Txs again for your testing and this hasn’t been forgotten.

Good afternoon @rmackay9 ,

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:

However, the yaw in the lane 1 looks very noisy and unoconsistent:

And it makes sense, since the yaw banks on the GSF that runs with the IMU0 that not have the shape of the yaw provided by the GPS:

Take a look how the different three states Kalman filters of the GSF converge using the IMU1:

1 Like

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.

Good afternoon @priseborough,

We were able to replicate the behavior where it fails in one lane and the other one not:

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.


Thank you for your explanation @priseborough !

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.

1 Like

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.

1 Like

It’s not in the signal path.

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!

1 Like


Thanks for that info. Any chance of raising an issue for this? I’m worried that it will be forgotten if we don’t write it down.

Servers by jDrones