-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extract kalman filter into separate task #495
Milestone
Comments
krichardsson
added a commit
that referenced
this issue
Nov 5, 2019
krichardsson
added a commit
that referenced
this issue
Nov 5, 2019
krichardsson
added a commit
that referenced
this issue
Nov 5, 2019
krichardsson
added a commit
that referenced
this issue
Nov 5, 2019
krichardsson
added a commit
that referenced
this issue
Nov 5, 2019
krichardsson
added a commit
that referenced
this issue
Nov 5, 2019
krichardsson
added a commit
that referenced
this issue
Nov 5, 2019
krichardsson
added a commit
that referenced
this issue
Nov 5, 2019
krichardsson
added a commit
that referenced
this issue
Nov 5, 2019
Just a quick FYI: we were testing the head revision of the firmware as of today and #368 is still not solved after moving the Kalman filter to a separate task; the UWB deck on 1 out of 6 Crazyflies that we have turned on has stopped after a while. We did not implement the modification in #368 yet as it seems to be a bit fragile, but we will try to test it soon(ish). |
Thanks for the info! |
matejkarasek
added a commit
to matejkarasek/crazyflie-firmware
that referenced
this issue
Jan 10, 2020
Fixing a typo introduced in bitcraze@bf8a584
krichardsson
added a commit
that referenced
this issue
Jan 13, 2020
…ld to make sure that code is built in the future.
cafeciaojoe
pushed a commit
to cafeciaojoe/crazyflie-firmware
that referenced
this issue
Sep 27, 2024
(bitcraze#396) updated the flashing firmware and moved cold boot to seperate …
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The kalman filter is running as a part of the stabilizer loop at 1000 Hz. This usually works fine, but if there are a lot of updates to handle it might require more work than can be done in 1 ms which delays the stabilizer loop. The current implementation relies on a sort of cooperative multitasking where the kalman estimator is supposed to not spend too much time. Since the stabilizier task runs at a high task level, long running jobs in the kalman filter blocks other tasks which is bad for timing.
I propose to move the kalman filter into a task that runs independently from the stabilizer loop. Benefits would be:
#368 might be related to this but it is unclear at this time.
The text was updated successfully, but these errors were encountered: