crazyflie drop problem and deck fail in LPS
Posted: Sat Mar 11, 2017 3:15 pm
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?
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?