crazyflie drop problem and deck fail in LPS

All discussions related to the Loco Positioning system
Post Reply
Hank
Beginner
Posts: 5
Joined: Mon Jan 16, 2017 9:04 am

crazyflie drop problem and deck fail in LPS

Post by Hank »

Hi, all

Recently, i got the LPS for the crazyflie to fly without drift, but something is not great, so here i have some question to ask you:
1.after running the modified dwm_loc_ekf_hover.launch with keyboard teleop and set the target x:= 3.4 y:=1.5 z:=1, then i take off
the crazyflie to the target, the following results in /crazyflie/log_kfpos maybe like below:
[3.40] [1.54] [1.00]
[3.40] [1.53] [0.98]
[3.40] [1.52] [0.96]
.
.
[3.40] [1.50] [0.80]
[3.40] [1.50] [0.82]
[3.40] [1.52] [0.80]
.
.
[3.40] [1.50] [0.60]
[3.40] [1.50] [0.62]
[3.40] [1.50] [0.65]
.
.
[3.40] [1.50] [0.80]
[3.40] [1.50] [0.82]
.
.
[3.40] [1.50] [0.90]
[3.40] [1.50] [0.88]
.
.
[3.40] [1.50] [0.80]
the rough results of above are in "flightmode/posSet" mode without changing target or changing to landing. It shows that the
crazyflie usually drop and no immediate correction and hard to up to the target since the end of taking off. i'm very confused
why the correction in x and y direction are great but in y direction is bad not similar to the LPS video in wiki.
Is there any possible problem in my environment setting or the firmware problem? and why the crazyflie has drop problem?

p.s. My anchors are set as TWR anchors and placed at indoor:
anchor0_pos: [5.36, 0.00, 0.57]
anchor1_pos: [5.36, 0.00, 2.31]
anchor2_pos: [5.43, 3.39, 0.57]
anchor3_pos: [5.43, 3.39, 2.22]
anchor4_pos: [1.01, 3.37, 2.22]
anchor5_pos: [1.01, 0.00, 0.57]

2.In order to find the problem, i try to study estimator_kalman.c and do something different, also get some confusion:
1)why the position update and body-velocity update only consider acceleration in z direction while flying.
2)if i just wanna the position update from LPS and remove position update in stateEstimatorPredict function, the detected position
seems still right, but why the crazyflie will up and down between the target height, ex: target z=0.5, then detected position
between 0.1 and 0.9

3.It is usually that the signal of deck will fail after running the python client or dwm_loc_ekf_hover.launch for a while, does anyone
have the same problem?
sali0
Beginner
Posts: 24
Joined: Wed Oct 19, 2016 7:53 pm

Re: crazyflie drop problem and deck fail in LPS

Post by sali0 »

Hello,
I just want to let you know that my team and I have actually been seeing the same issue with the Z axis being way off from what we command the drone to do. Will be monitoring this post as well.
arnaud
Bitcraze
Posts: 2538
Joined: Tue Feb 06, 2007 12:36 pm

Re: crazyflie drop problem and deck fail in LPS

Post by arnaud »

Hi,

To answer your questions:
1)why the position update and body-velocity update only consider acceleration in z direction while flying.
This is because the Kalman filter is using the quadcopter dynamic to predict its state, and a quadcopter can only produce force in the Z direction.

Mike (the EKF author) has added a drag component in its latest version of the EKF, it is not merged yet but it helps a bit with X/Y velocity estimation, the drag should use X/Y acceleration as well.
2)if i just wanna the position update from LPS and remove position update in stateEstimatorPredict function, the detected position
seems still right, but why the crazyflie will up and down between the target height, ex: target z=0.5, then detected position
between 0.1 and 0.9
This is problematic. It might be that the PID is not tuned well enough.

Something I have observed recently is that the velocity estimate in Z of the EKF is wrong, it is usually over estimated. This can be observed by controlling the Crazyflie in velocity only: asking for 0 m/s in Z will anyway result in the crazyflie going down. I wonder if it is not the cause of what you are observing: the velocity is over-estimated so the velocity loop will constantly under-power the motors.

Maybe adding some ki to the Z PID would solve the contant error.
3.It is usually that the signal of deck will fail after running the python client or dwm_loc_ekf_hover.launch for a while, does anyone
have the same problem?
I do not undertand and I have not seen consistend failure of the deck after some time. What is happening exactly, does the deck stops communicating?
Hank
Beginner
Posts: 5
Joined: Mon Jan 16, 2017 9:04 am

Re: crazyflie drop problem and deck fail in LPS

Post by Hank »

Hi, arnaud

Thank you for your reply. It seems reasonable and i'll try your suggestions later.

Yes, all LEDs on the deck turn off and stop communication then restart the crazyflie without blinking the LEDs, so i have to restart the crazyflie again to see the LED signals on the deck. By now i just have a guess that my expansion connector pins can not be connected perfectly or there is something wrong because the deck will be easily separated from the crazyflie after any crash.
arnaud
Bitcraze
Posts: 2538
Joined: Tue Feb 06, 2007 12:36 pm

Re: crazyflie drop problem and deck fail in LPS

Post by arnaud »

Hi,

Yes it looks like a connection problem, maybe you can try using the longer pins for a while to see if it solves the problem (ie. trying to distribute the pin lenght between the top and the bottom.
Post Reply