Kalman filter (full dynamic implementation)

[adrianmiriuta]

@apocolipse @kidBrazil @LexioTech

Hi, I am working on a clean, full dynamic, implementation of the Kalman filter into Butterflight, using the gpl released IMU-F code from heliorc.

anyone interested ?

[kidBrazil]

That would be pretty awesome! Have you taken a look at Pegasus yet?

[adrianmiriuta]

@kidBrazil not yet (I am a cli user)

I already submitted PR #237 #251 but there seems to be no active replay from anyone.

I would like to go forward with ButterFlight development, I would like to get merge rights to the project.

[robert-b]

i am planning to add a dynamic fft filter. just a few tabs in the lower frequency band.

[adrianmiriuta]

@butterSnake awesome, at last, someone alive ...

[robert-b]

you shouldn't use the word kalman ;-) i haven't checked the mcu runtime for the dynamic thing. but a simpler calculation using stdev calculation might do the trick as well.

[butterSnake]

Ohh no the return of the mad one 😂

[robert-b]

you should face it. even 32k is dead ;-)

[butterSnake]

It’s ok 32k is a dead end 🤷‍♂️

[adrianmiriuta]

@robert-b it is Kalman (or Markov if you want ...) I have a testing draft. It is the helio IMU-F implementation without cross axes measurement noise variance. On a CLRACING F7 it needs 1% more CPU (at 8Khz Gyro and PID loop).

I never used 32K.

[robert-b]

32k is the mechanical resolution. a ride on a gear wheel makes no sense.

[adrianmiriuta]

@robert-b what do you mean with mechanical resolution ?

The MEMS operating frequencyes are X = 33+/-3 kHz, Y = 30+/-3 kHz, and Z = 27+/-3 kHz

and the maximal Output Data Rate for the ICM series is 8K . there is no 32K ...

[robert-b]

mechanical resolution is the mechanical resolution. now you have some sort of mcu inside. would you dynamically adjust the reading frequency?

33k +-3k is 32k which will prob. change with every production run. as it did happen with the analog variants.

the word mechanical resolution was used and introduced by a tdk man.

[adrianmiriuta]

@robert-b

mechanical resolution of what ?

the MEMS operating frequency has nothing to do with Output Data Rate.

[iggut]

I am glad to see there might be more to come for Butterflight. I love my helio boards and wish I had the skills to help out here hehe Thanks for all that do the work!

[iggut]

I am no programmer or even sure I understand this so bear with me.

Would it not be a good idea to try using the BF4 rpm filter, but run it on the IMU-F or some sort of implementation of the dshot bidirectional communication to get RPM in real time for filter use (unsure how this part works)

[adrianmiriuta]

@iggut this entire gyro filtering mania is just a band-aid, and has taken ridiculous proportions (36 notch filters).

All this band-aids try to fix the reality ... that the PID controller is not suitable for controlling highly nonlinear systems.

All this filtering is killing the dynamic of the quad, you get the best handling with lowest filtering. It is crucial to pick a low noise frame-esc-motor-prop combination, with less filtering it will fly the best.

[adrianmiriuta]

@butterSnake Thx for your advice, but there is always another way to do things. You can use what U like it's all GPL. But please stop the trolling, you're not in the kindergarten.

[adrianmiriuta]

@apocolipse @kidBrazil @LexioTech

PR with Kalman implementation is ready. some smaller F3 do not have enough RAM for it.

[theSkonk]

@adrianmiriuta its was good enough for the butter devs at the beginning of this project... love how quickly people forget their own shit behaviour... good to see this project is a massive dead end still :P

[robert-b]

not true. but pls. have a look at the code conduct at the beta fligth site. in the mean time i know you a bit better.

[theSkonk]

@iggut this entire gyro filtering mania is just a band-aid, and has taken ridiculous proportions (36 notch filters).

All this band-aids try to fix the reality ... that the PID controller is not suitable for controlling highly nonlinear systems.

All this filtering is killing the dynamic of the quad, you get the best handling with lowest filtering. It is crucial to pick a low noise frame-esc-motor-prop combination, with less filtering it will fly the best.

what a total load of shit... the rpm notch filters can be run at a Q that for all intense produces no phase delay, combined with a static pt1 filter on gyro you can achieve gyro latency as low as 1ms on a nice clean airframe.. with a clean setup it is possible to achieve total system phase delay that is 2-3ms.. substantially less than any thing else out there.. the accuracy of the rpm filtering provides pretty much eliminates all motor based noise. for racing the ability to handle bent props at motor by motor level is something very special and then there is the connected feel of the quad when your gyro is 1ms behind the action.. it would never come to butter flight any way as first someone would have to get Dshot to work...

love that you can 't even let this shitty project die with any grace adrianmiriuta.. still taking chops at the code you've been copy and pasting all along...

[robert-b]

dear skonk, my thinking says iggut is right. what you love is a piece of over engineered software. when you state that a filter has no phase delay then this is the biggest bullshit i've ever read.

[Quick-Flash]

@adrianmiriuta have you heard about the Emuflight project?