Discussion - Acro flight performance enhancements

[theArchLadder]

I just tried betaflight, wow! Very impressive, so locked in compared to fp-pid. It felt like i became a twice as good pilot!

Could we get this performance in inav? Why having to compromise between nav and acro performance! :stuck_out_tongue_winking_eye: The default looptime on betaflight is 500 and even i could notice a difference when switching to 1000 like i have on inav. 500 made it feel a little bit more sharp. Would it be possible to get inav to run at 500 on F3 targets?

But the most important difference is that the attitude was so locked in! Perhaps i'm a terrible tuner but no matter what i do i can't get the attitude to be locked in on fp-pid, and to high I-gains starts to ruin the performance... Is there to much anti-windup or what is going on here? Attitude on betaflight was very locked in even on 1000 looptime. Fp-pid changes the attitude all the time without me telling it to, that makes acro flying very hard.

As usual i'm more than happy to make my custom builds and flight test them, just give me some ideas on what to try! What else could we borrow from betaflight to improve acro flight?

[borisbstyle]

@andre92 On F3 and F4 boads it is 1khz.....on F1 boards it is slower depending of your PID/gyro speed

[WaspFPV]

@borisbstyle I figured I can at least try to split up the pid loop into seperate tasks and run them all at a different rate. I like the idea of only handling acro controller in main pid loop and seperate attitude and navigation as you did in Betaflight, I'll see how that works out in Inav. Probably they can all run at 1khz on F3 targets, but I would really like to have gyro and acro controller at 1khz on a F1. Just something to try for myself first.

[borisbstyle]

@andre92 I run gyro fast just because I use lpf of 256hz. When you sample too slow you will get aliasing artifacts.

Typical motor noise is between 200 and 400hz. To get a good sampling quality you would need to sample x10 to be able to see the noise properly and filter it. I think the minimum sampling rate is than 400*10=4k

[WaspFPV]

Ok here's what I did. I pulled acc, attitude, position and navigation updates out of the main loop and made them into seperate tasks. Their period is set to masterconfig.looptime, so I can play around with the looptime setting for their period. So far it seems to work with gyro/pid/motors at 1khz and looptime = 3000. (gyro_sync and emf_avoidance ON) I'll try to fly it tomorrow. I made a fork with my changes, test at your own risk.

[digitalentity]

Another suggestion - get rid from synchronous motor update and stick with unsynched, at 490Hz for PWM and, i.e. 2kHz for OneShot. As @DzikuVx mentioned, motors are not going to change thrust much for 500usec anyhow.

[digitalentity]

IMO sampling acc at least at 500Hz rate is a must for reducing effects of aliasing. Basically, we need 3 rates of sampling: 1) gyro 2) acc 3) PID And as far as I'm concerned only gyro should be read in a synchronous manner, the rest can tolerate some jitter without noticable side-effects.

[digitalentity]

@borisbstyle your expertise on this matter is greatly appreciated - you have similar separation in Betaflight for ages now. :smile:

[borisbstyle]

@digitalentity I indeed agree about the motors side. It is only the delay what improves, but thats really marginal compared to real PID perforamance variables. There are other variables too what affect the acro performance even more.

I didnt have much time to dig into your current state of the code, but I will soon once I finish 3.0 what needs some attention now.

[kronosol]

Hey, to improve the Acro flight performance,.. how about supporting OneShot42 or better Multishot? Multishot Raceflight FW Edit: Multishot & 4k4k Mode

[digitalentity]

@kronosol

397 will open possibility to implement OneShot42 or MultiShot. Unsynched mode may introduce slight delay in transitioning command to motors, however it's really marginal as @DzikuVx pointed out that motor thrust doesn't change that quickly anyway.

[DzikuVx]

@digitalentity @kronosol probably delay from unsynched motor update will be much much lower than gain of at least 3 times faster update of OneShot42 comparing to OneShot125.

[digitalentity]

@DzikuVx update rate is defined by motor_pwm_rate, OneShot125 can be dialed as fast as almost 8kHz, why would you need to go faster than that? I might be wrong, but I really don't see a benefit of using OneShot42 or Multishot over OneShot125.

[DzikuVx]

@digitalentity yes, OneShot125 can be executed at ~8kHz. Still, it takes up to 125us to push data to motor. With OneShot42 it takes up to 42us. 80us less delay. How much delay async motor update can introduce?

[digitalentity]

@DzikuVx in theory as much as motor_pwm_rate period (half of that on average). If OneShot42 can be updated faster than 8kHz - we need it, if not - drop it and stick with OneShot125 as it's more noise-tolerant. EDIT: This delay is totally independent of used protocol - OS42 and OS125 both will have ~62us delay on average if run at 8kHz rate.

[digitalentity]

@DzikuVx based on your math even 2kHz rate (500us delay) doesn't matter much, how much 62us would hurt in terms of flight performance? Also bear in mind that MPU6500 alone running with gyro_lpf=256HZ has an inherent delay of 970us.

[DzikuVx]

@digitalentity now I'm referring to smth completely different. I'm not talking about changing motor speed at 2kHz. I'm talking about how long it takes for a motor to start reacting to new value.

With PWM at 490Hz it takes ~2000us to notify ESC about a change. This is only delay introduced by protocol. So, with PID loop at 500Hz and up to 2000us of protocol delay, ESC can start to react 4ms (worst case) after gyro got a change (2000us waiting for next PID loop and 2000us to transfer data to ESC.

With OneShot125 and looptime 2000 it is only 2150us (assuming motors were synced right after PID loop). With OneShot42 is is only 2042us and so on.

[digitalentity]

Ok, I think this is solved now

[alexrjohnston]

Hi guys, sorry to grave dig. Just a quick note that the code below transformed my 330 with 8" dji props from a wobbly wreck to a locked in beast of a machine on inav 1.3:

set gyro_sync_denom = 12 set gyro_lpf = 256hz set gyro_sync = ON set gyro_soft_lpf_hz = 75 looptime 1k on sp racing f3

We also have a 650 hex im going to try the same settings with once we have rebuilt the air frame. Before making the above changes both machines had a slow oscillation during hover even in manual mode that I could never seem to tune out without backing everything off too far. Big thanks to everyone who has contributed to this awesome project.

[digitalentity]

@alexrjohnston you are welcome! Indeed high values of gyro_lpf make a big difference. I wonder why PixHawk devs think otherwise...

[DzikuVx]

@alexrjohnston I'm very glad to hear I liked how your quad behaved. Only bear in mind, that if you have bigger propellers, gyro noise frequency will go down and you might want to lower gyro_soft_lpf_hz. My 600mm quad on 12" props required gyro_soft_lpf_hz of < 60

[alexrjohnston]

great info, thanks for the advice! I also tried gyro_sync_denom = 8 yesterday on the f3 with pos and alt hold and it flew even nicer. is there any danger doing this? the cpu seemed fine until gyro_sync_denom = 4 which it couldn't handle. - Al.

[DzikuVx]

Generally, the lower the better. As long as CPU can hold the looptime with GPS and stuff, it is fine

[alexrjohnston]

ideal, thanks again! seriously impressed with inav since making these adjustments.