Clarify structure and API of estimators

[knmcguire]

Currently the extended Kalman filter is always initialized and taking up RAM, even if only the complementary filter is used. It is not really adding problems now, but if in the future more types of estimators are added, this might be a bit difficult to handle.

How about just starting one generic estimator task, where within we can switch between the Comp. filter, EKF or estimator number# ?

[jonasdn]

Is this something we want to pursue? If so, do we have a plan of attack?

[knmcguire]

To kind of give a background information: In the current state of the firmware, the kalman estimator is already initialized here in system.c and the rest of the estimators here in stabilizer.c . The kalman filter is currently now setup as a seperate task, but I think we should also do that with the complementary and the OOT one.

Technically, the kalman filter is not taking up RAM if the complementary filter is selected, as the loop is physically stopped here if the complementary filter is selected, so that was a wrong assumption from me, but... the general structure could be improved, starting with putting the complementary filter also in a task for starters

[jonasdn]

Re-branding this issue somewhat!

We want to create and/or clarify the estimator API, so that the following questions are easy to answer:

• which functions do a estimator need to supply?
• what is the expected ouput of an estimator?

We want it to be the estimators business whether a task is created or not, it should not be treated any different by surrounding code based on task or no task.

[knmcguire]

This would also be valid if we want to make python bindings of these api's like mentioned in #602

[krichardsson]

There is some documentation in the oot build section https://www.bitcraze.io/documentation/repository/crazyflie-firmware/master/development/oot/