MicroArduCopter, 3" props, Omnibus Nano, Success!

Great. I see it is also in small copter branch, will try soon.

@andyp1per I tested it on a 3 inch quadcopter with revo-mini.

Here are some results with INS_GYRO_RATE=0 (normal 1KHz sampling)

Similar of what I already seen (without PR 14423) with PkAvg around 330Hz and BwAvg around 150Hz.

Then I set INS_GYRO_RATE=1 (2KHz sampling) and I see something I don’t understand completely

It seems to me to see more noise passing in the post-filter FFT and more “spread” of PkAvg and BwAvg with BwAvg frequently near PkAvg.

I have a doubt regarding FFT_MINHZ and FFT_MAXHZ, must they be set to see the fundamental only or also the harmonics?

In the above tests I set them in this way:
FFT_MINHZ = 180
FFT_MAXHZ = 480

Is it OK or have I to set FFT_MAXHZ near 700Hz (in the case with INS_GYRO_RATE=1) ?

You only need to try and capture more harmonics if you are using INS_HNTCH_OPTS=2 otherwise just finding the first harmonic is fine.

Interesting that your second harmonic is so pronounced.

I think probably what you are seeing is the effect of the raw sample rate going from 1Khz to 8Khz rather than the backend rate going to 2Khz. It would also be worth doing a comparison at 1kHz with fast sampling on and off.

That said the post sample noise around 100Hz seems to be higher than pre-sample indicating that it is being added by the notch. One thing to note - when you go from 1Khz to 2Khz your FFT bins will double in width reducing the accuracy. You could increase the FFT length to 64 to compensate.

Here with FFT_WINDOW_SIZE = 64

Is more evident the difference in PkAvg, BwAvg plot then in FFT spectrum.

That looks pretty good. The BW will be mainly because - 2000 / 32 = 62Hz, so the BW will only ever be at minimum 62hz * 3 = 185Hz. At 64 your resolution is suddenly 31Hz.

What kind of frame do you have? My suspicion is that the noise at the low end is frame resonance.

Also be careful - on an F4 with 64 FFT and 2k gyros you are beginning to push the limits.

Thanks for explaining.

It is possible, is a cheap frame with prop guard, rpi zero, rpi camera, many things that could vibrate.

I use it for this kind of experiment:

Anyway it is quite stable.

PM.Load max 70% in little indoor flight.

Unfortunately PM.Load is not a good indicator that your gyro rate is too fast. I haven’t figured out a good way to estimate this, perhaps the most reliable is when you lose logging.

@andyp1per
When I set the gyro rate at anything above 2k, as soon as telemetry should start transmitting (when I turn on my RC radio, which is currently doing SBUS, as well as a traditional mavlink telemetry stream), the copter locks up… (By that I mean it is completely unresponsive, the OSD doesn’t update, etc).
If I turn the transmitter off, the copter starts responding again.

Running the omnibus small copter build off your dropbox.

I’ve not seen that. Trying to run 4k on an F4 is futile IMO - you will be killing the CPU I suspect. That’s not necessarily the issue, but it seems unlikely that the gyro rate is at fault here.

I’ll see if I can find any other pattern… At least test if it does it if I disable telemetry, so we know if it’s sbus or telemetry specifically causing it… Or something w/ the combination.

I had been running a 2 or 3 week old copy you compiled for me, which was to test the crossfire/sbus changes, and I think the double harmonic notch was new in that build as well. It worked fine.

Nothing to report at 2k… It worked. FFT goes to 1000 instead of 500. Everything looks and performs well.

Just FYI I recently fixed (with @Leonardthall help) a tuning problem on my 3". Autotune gave me good PIDs except YAW would oscillate at low throttle - not always, but a bit of propwash and high MIX_MAN was enough to set it off. I had to reduce MOT_THST_EXPO to 0.45 and that really seems to have sorted the problem.

1 Like

Thanks,
That is one of the remaining issues I was having trouble with too. I can’t quite get it perfect yet.
And mine breaks in to oscillations once I lower the throttle after a high speed run occasionally. And, just the occasional twitch… Seemingly for no reason, it will twitch several degrees. I wouldn’t care, other than sometimes I’m trying to film video…

They’re all subtle and only occasional, but I’d love to get it perfect.

Once I have logs that clearly show the issues, I’ll post them… Haven’t had a lot of flying time this summer, unfortunately.

1 Like

Ok apologies there was actually a bug which was why the sample rate looked wrong for accels. This also meant we were sampling the same accel value multiple times. Note sure what effect this has but I’ve fixed now in my small copter branch.

@wicked1 I am just updating my KakuteF7Mini and OmnibusNanoV6 builds

1 Like

Thanks for info, I will test asap.

I’ve also added https://github.com/ArduPilot/ardupilot/pull/14891 which could possibly make the FFT a little more accurate.

I did an outdoor flight with my 3 inch copter with omnibus v6 nano and small-copter-4.1 (built 5 days ago) with gyro_rate 1KHz (so nothing special).

I had Potential Thrust Loss errors, never seen before, where do I have to investigate? Battery, ESC, …?

Here the log:
https://drive.google.com/file/d/1KMcnSnuUzRrfgFW86CwTiytZ9y8FSpnh/view?usp=sharing

[Edit]
As battery I use 2 18650 Li-ion cell (Sony / Murata US18650VTC5 2600mAh - 30A), they could go down to 3V each without problems.
Maybe they are a little bit old, too much charge - discharge cycles?

It must be because your desired alt deviates so much from the actual altitude. Did you check that the baro alt is the same?

BAlt is similar to Alt (obviously with more error).

Did the RCOUT drop at the same time or stay high?

@andyp1per returning to your last PR on gyro rate I tested your last small-copter-4.1 (as of today) with my other 3 inch copter with revo-mini, same config as post #871

INS_GYRO_RATE = 1
FFT_WINDOW_SIZE = 64

[Edit]
Changed image, it was the wrong one.