Bitcraze Forums

Dear all,

I experience a weird bug/problem with my crazyflie. I am using the flowdeck and experience the following. When sending setpoints via the python cflib (x,y,z,yawangle) the height varies between flights.

When I install a new battery on the crazyflie it follows my commands " perfectly" and so flies to the commanded heights and that can be seen in the state estimate logging. Then when I switch the drone off/on and run the exact same flight the crazyflie follows the commands but approximately 10/15 cm lower than the commanded height. Although the height by visual is way off the state estimate logging shows that the crazyflie thinks that it conducted the same flight and reached the correct altitude.

This bug happens everytime a new battery is installed. So first flight is correct, every flight afterwards is 10/15 cm lower. But the state estimate logging is the same everytime.

I hope my story is clear enough. Otherwise contact me on discord or arrange a meeting.

That is a very weird behavior. Is it the same behavior if you don't restart the Crazyflie? It sounds like the ranging sensor (VL53L1x) is reporting the wrong height.

Dear Tobias,

I just tested what you said. And when I do not switch the cf on and off the height stays correct. But when switching the cf on and of without changing the battery the bug comes up. As I said it still thinks that it flies to the same altitude but in reality its not.

Greetings
Max

I tried to reproduce it but couldn't. Could you share some more detailed instructions and possible if you have any script that you run.

My theory is that there is a large enough voltage dip to put the ranging sensor in a bad state during take off. Is it a particular battery that is problematic? Can you try the battery test in the console tab in the cfclient?

Dear Bitcraze,

The problem still exists, and i did the battery test after updating the client. I am running the latest firmware and the problem is still there. When I put in a charged battery the first flight is okay as seen in the right figures. The flight is commanded to go towards 0.4 and afterwards 5cm measured from the ceiling, which is also estimated at the correc +/- 70cm. But when I switch the cf off and on, without changing anything and running the same flight code. The flight is different as seen on the left figures, the 0.4 height command is still fine, but afterwards the ceiling distance of 5cm is reached but the height it thinks it is flying on is different as well as the ceiling height estimation, which now suddenly became 80+ cm.
What could this problem be?

Greetings
Max

Could you share the script? It is hard to debug without have a known failure case.

In the graphs the command z behaves very differently on the left side. It slowly rises after reaching 70cm.

def run_sequence(scf, sequence):

if INDI_outer == False:
Commander(scf.cf).set_client_xmode(True)
print('Pos format is (roll,pitch,yawrate,zheight) [deg,deg,deg/s,m].')
for position in sequence:
print('Setting position {}'.format(position))
for i in range(250):
Commander(scf.cf).send_zdistance_setpoint(position[0],
position[1],
position[2],
position[3])

if INDI_outer == True:
for position in sequence:
cf = scf.cf
print('Setting position {}'.format(position))
for i in range(50):
cf.commander.send_position_setpoint(position[0],
position[1],
position[2],
position[3])
time.sleep(0.05)

for i in range(100):
print('Setting position {}'.format([0,0,RBF_1_data[5]-ceiling_distance,0]))
cf.commander.send_position_setpoint(0,
0,
RBF_1_data[5]-ceiling_distance,
0)
time.sleep(0.05)

for i in range(100):
print('Setting position {}'.format([0,0,RBF_1_data[5]-ceiling_distance_2,0]))
cf.commander.send_position_setpoint(0,
0,
RBF_1_data[5]-ceiling_distance_2,
0)
time.sleep(0.05)

for i in range(25):
cf.commander.send_position_setpoint(0,0,0.5,0)
time.sleep(0.05)

for i in range(25):
cf.commander.send_position_setpoint(0,0,0.2,0)
time.sleep(0.05)

cf.commander.send_stop_setpoint()

This is the python code sending the setpoints. Its similar for both cases so somehow the value obtained from the state estimate z, which comes from the kalman filter differs.

I also tried it using PID control and a similar effect is seen. First flight flies to certain altitude, second flight same code and battery but switched on and off flies to a lower altitude.

If its maybe easier to understand the problem I can do a discord call or something similar.

In the left plot the commended z is rising, do you know why that is?

The way I command the crazyflie is the following.

When the upper sensor senses a distance of less than 0.5 meters my ceiling distance estimation is switched on. This estimation is as follows it takes the measurement from the upper sensor when switched on and adds the displacement measured by the state z each time step. When the upper sensor gets a new measurement this estimate is corrected using a gain.

To estimate the total heigth from ground to ceiling I add the state_z + ceiling estimate. This value is send to the python code and from there I can command the crazyflie to fly a certain distance from the ceiling.

Somehow with the second flight it senses the ceiling to be at 0.8 meters, using the state and the ceiling estimate. But when it reaches the setpoint where it should fly at the desired distance from the ceiling it measures that the ceiling is still further away then wanted. Thus it measures that the ceiling is higher than it thought and thus gets send a new setpoint making it rise until all measurements stabilize.

This is weird as in one flight it measures the height correct at 0.7 meters and flies "perfectly" towards the desired height. Then in the second flight the ceiling is higher and when it climbs towards it this height keeps increasing.

With the position_z being solely the state estimate z from the kalman filter. So the height from the kalman filter is different between the 2 flights even though the surroundings did not change.

Could you try to plot the distances from the ranger sensors that you use in the same examples you showed? They should be called range.zrange and range.up.