Page 1 of 1

Different Positioning types

Posted: Thu Jan 09, 2020 12:27 pm
by chopin
Hello everyone.
I am logging the position using the Kalman logging variables, the problem is it appears to be over drafting when I am stopping to move.
Here is an example of this:
The orange is the Loco positioning and the green is the real-life positioning. As you can see the error is pretty big and I'm trying to understand why (The graph is in meters).
Is there any way I can access the Kalman filter itself and change the predictions or is there any way I can access the raw data of the positions and not the Kalman prediction or a way to customize the predictions?
Thanks in advance.

Re: Different Positioning types

Posted: Thu Jan 09, 2020 1:28 pm
by kristoffer

Not exactly sure what you are seeing. I would expect some noise on top of the signal, around +-0.1 m, but it looks like there is an overshoot as well that I don't understand.
Are you using a mocap as a ground truth? Were you flying when recording the data or did you move the Crazyflie around by hand?

If you want to poke in the firmware, the kalman filter is implemented in src/modules/src/kalman_core.c and src/modules/src/estimator_kalman.c.
If you want to stay on the python side, search for PARAM_ADD in those files to find all parameters that you can play with.

The LPS handing is implemented in a bunch of files, depending on algorithm (TWR, TDoA2 or TDoA3), which one are you using?
The raw data is not available over radio sine it is a bit too much data, and if you want to examine it you will probably have to do something in the firmware to analyze it. There are some log data available for slightly more refined data (ranges and TDoA), but again that depends on which algorithm you are using.

Re: Different Positioning types

Posted: Sun Jan 12, 2020 6:37 am
by chopin
I am using a mocap as ground truth. I am using a Roadrunner so I can't fly it, I'm moving it by hand.
I am using TWR.
Thanks for the response.

Re: Different Positioning types

Posted: Wed Jan 15, 2020 8:39 am
by kristoffer
It is possible that the estimator can be improved :-)
The only idea I have at this point is that it might be related to accelerometers. Maybe some sort of scaling or calibration would improve the performance?