My FFT change is merged but disabled on all 1Mb boards apart from KakuteF7Mini and KakuteF7. The concern is that on F405 boards the CPU won’t be able to keep up even at default settings.
If you have flown successfully with my FFT on a 1mb board and are reasonably confident that it is working well, please can you let me know which board so that I can enable it for that board (ideally with a log if possible). Thanks.
I tested (little indoor flight) your small-copter-4.1 branch on my 3 inch copter with revo-mini (F405). The copter is really really stable and the little revo-mini has no problems with double harmonic notch and dynamic FFT.
Thanks a lot for all your hard work.
Thanks, the load looks good at about 60% max, which is quite high but I guess manageable.
I’m a little disconcerted by the dropouts on the detected frequency, I think that may be because my algorithm to detect harmonics could be improved. I suspect you don’t notice much difference, but I would like to get it picking the harmonics more predictably, perhaps by adding a low-pass filter on the multiplier.
I have flown the FFT notch on an Omnibus nano w/out any problems… But that was a while ago and I don’t have any logs to share… I switched to ESC based soon after I tried the FFT one.
It looks like what I really need to see is whether there are any slips reported when SCHED_DEBUG = 2 unfortunately the output is not logged, it will only show up in the console - so might be difficult to tell
You are looking for this message: Scheduler slip task[%u-%s] (%u/%u/%u)\n but it will only show up on the console as its a printf. You could consider changing to a mav message in AP_Scheduler.cpp if that’s easier to see.
Interesting that it’s mainly sample_gyros(). What is your FFT_WINDOW_SIZE? if you change line 85 in AP_Vehicle.cpp to 100us (rather than 50us) does that help?
It could also be a cascading effect of printing messages - as soon as you print one you will delay the next, probably better to try and use mavproxy to display the output and continue to use printf()
My FFT_WINDOW_SIZE is 32, I removed writing to gcs (previously added) and tried 100us in line 85 of AP_Vehicle.cpp but the result is the same: a lot of “slip task[51-sample_gyros] (2/1/100)”.
Now I am using mavproxy to display console output.
It’s possible this is expected - sample_gyros() is supposed to run at the loop rate, so if anything gets missed it will. We actually don’t report anything in the fast loop anyway, it always runs so maybe we should just ignore slips for loop rate tasks.
@wicked1 I finally have the props on my rebuilt Gecko. I think it has the leans like yours - I see significant accel offsets, will investigate more.
I definitely think this is voltage related. My initial calibration was on USB power and that is what resulted in horrible offsets. I re-calibrated with the battery connected and it was a totally different copter - before it was pretty much unflyable, after it hovered beautifully.
Is yours still leaning?
I’m almost positive I calibrated while powered w/ battery… I know I have done it both ways in the past. I’ll recalibrate and see if it makes any difference.
The leaning is odd… It’s not always the same. Some flights are horrible, and I have to land after a minute because I can’t compensate anymore. Other times it’s almost fine, w/ no changes to the copter or configuration. Although, temperature, GPS signal, magnetic interference, etc, are all out of my control… Still, it doesn’t really seem to be related to any of that… I can reboot a few times in the same place and time, and it could be fine, or it could be worse.
I hate to put the curse of the leans on you, but I’m kind of glad to see other people w/ the problem. I’ve been trying to figure it out for years, and have made little progress. Hopefully if others can reproduce it, we can figure it out.