LPS update rate is slow, being inaccurate

[Sexydove]

I'm using 6 anchor mode LPS nodes with LPS deck.
I've used TWR, TDoA mode with reference 6 anchor configuration.
(The firmware of 6 anchors is up to date, and I've already confirmed that all of anchors are configured as anchor mode by picocom)
(I've already set the individual position of LPS node with cfclient)
The problem is that kalman.stateX with Y Z axis is inaccurate due to the delayed update of LPS.

To be precise, I used cfclient to observe the data of crazyflie's lopo but it was very slow as it was dripping.
Also, of course, I thought that this may be due to the overhead of plotting on the plot, so I plotted it with opengl(which has very low overhead).
I have graphically shown the process from moving manually by hand way (0,0) to (0,1) and (1,1), but I was disappointed that result plot was not like my intend)

The graph clearly had to show a right angle, but what was actually observed was a circular graph with delayed observation.

Don't mind the title of plot, it consists of vector of kalman.stateT
My conclusion is one. The lps is being very slow and the observations are distorted. Not only is it distorted, but the total observation time is also dramatically increased. I tried both TWR and TdoA modes but it became same result. I want to know how to speed up the LPS update rate.

I have to pay the result, but it is really hurried because it is blocked in this part. Help me.

[arnaud]

Hi,

How fast are you logging the data?

The Crazyflie state estimator, a Kalman filter, is running at 100Hz and does not exhibit a lot of delay: if there was any significant delay in the state estimation the Crazyflie would not be able to fly autonomously. The delay might be caused by a slow log or packet buffered somewhere.

How are you moving the Crazyflie? Are you moving it manually or is the Crazyflie flying by itself. The Kalman filter has two different behaviour for these two modes.

[Sexydove]

Sorry for late reply, I was not able to answer while finishing my job presentation about using crazyflie.

>How fast are you logging the data?
>>Doesn't know, but all I know about is that kalman state update rate is slower than that of stabilizer acc
I contain a real time plot testing xyz axis accelerometer data with opengl.


>The Crazyflie state estimator, a Kalman filter, is running at 100Hz and does not exhibit a lot of delay: if there was any significant delay in the state estimation the Crazyflie would not be able to fly autonomously. The delay might be caused by a slow log or packet buffered somewhere.

>>Can debug mode detect the sort of slog logging or packet buffer? I want LPS based maneuver without flow deck, but it may not able to be done when this logging buffer still exists.


>How are you moving the Crazyflie? Are you moving it manually or is the Crazyflie flying by itself.

>> I move crazyflie with autonomous flight(pylib).
I use two thread(thread 1: flow deck motor control, thread 2:logging data callback, main: opengl plot)
Additionally, the lps works well in the specific situation like stiff hovering, drawing horizontal circle.



>The Kalman filter has two different behaviour for these two modes.

>>I wonder the difference between two modes.
Is it related to the situation where the LPS coordinate suddenly change and back to their original position when you turn the angle of drones in
the same place?
I wonder why anchor - tag relationship is affected by accelerate changes.
When only one of the LPS anchors is on, crazyflie was exactly fixed(and some correction feedback moving) at a certain position when the
send_position_setpoint was entered. Does the location estimate of the LPS 'directly' involve the crazyflie's movement? Does it just help crazyflie's
3 dimension coordinate mapping?

PS. I'm using TWR(or TdoA) 6 anchor LPS with dimension 2.7m x 3.6m x 2.5m (x y z). Is this dimension too large to detect precise position and update?