Hi Christof,
I did not solve this problem.
I found out that the clipping not only occurs with the KISS esc's and the firmware compiled by Menno, but also with ESC32 V2 and the regular firmware. It also doesn't matter if I'm using Quatos or regular PID control. Furthermore I tested with an AQ6 board and a M4 board on different frames, so I guess it's not a problem of frame design or an individual flightcontroller.
The clipping occurs at a frequency of 5 Hz and coincides with the update of the GPS data. This is what Bill offered as an explanation:
Seems you've been quite through in your investigation of this matter. Without looking too closely, I suspect that what you are seeing (hearing) is a result of poorly calibrated (or possible bad) IMU sensors. That's the short explanation.
I think you are correct to suspect a link to the GPS update rate of 5Hz as part of the problem. What I think is happening is that as you start to see some non-zero vertical velocity from the GPS, the UKF then has some new (and conflicting) information about the actual vertical velocity. This manifests itself as relatively large corrections in the velocity estimates at a rate of 5Hz. Normally this would not be visible, but when you are in PH (or mission) mode, the nav system has control of the throttle trying to match the estimated vertical velocity to the desired target. When the velocity estimate jumps, it translates directly into a proportional change in throttle and you get your resulting effect.
To back up, I said that it is likely your ACC as the source of the problem. Since the ACC is mostly responsible for maintaining the time step to time step estimation of velocity, if its bias was off or drifting, the result would be a biased velocity estimate. The system would eventually (a few seconds or less) account for the discrepancy, but probably not by properly estimating the bias as there is not enough information coming from the GPS when you are not moving. In a steady state, all is apparently well, but everything is upset when you start to get vertical velocity data from the GPS (and to some extent, the pressure sensor.)
I have seen this to different degrees before, but usually not with a well calibrated IMU.
With this information in mind I spent some time zooming in on my data and found the following:
I've looked at the logged ACC_BIAS values (graph attached) and I think they are very low during the time of the flight (picture attached). There is some drift in the ACC_BIAS_Z but the amount and extent of the spikes in the logged MOT_THROTTLE values are constant.
You were right about the spikes coinciding with GPS updates.
Based on the assumtion that the motor ouput is calculated from UKF_VELD, UKF_POSD and IMU_ACCZ, I zoomed in on several small and large spikes in the logged MOT_THROTTLE values en looked at the sensor values for the same period. There seems to be no visually detectable pattern in it. No strange jumps or extreme values.
When zooming in on just one spike (graphs attached) you can see that it's just one MOT_THROTTLE value thats out of order and then the throttle output continues where it left of before. If there is a shift in sensor data I'd expect the MOT_THROTTLE values to continue at another level. To me it seems more like some parameter used to calculate motor output is changed after a GPS update.
This is where communication between Bill and me stopped and I gave it a rest.
Maybe you could confirm the clipping does not occur with a well calibrated board. I've not been able to perform a good full temp range calibration that performed better than the simple onboard one.
It would be nice though if a solution would become available.
Best regards,
Jan Willem
The Netherlands
