Stabilizer never completes calibration, appears to have started after changing radio channel

Post here to get support
Post Reply
super_flie_guy
Beginner
Posts: 2
Joined: Thu Aug 20, 2020 10:26 pm

Stabilizer never completes calibration, appears to have started after changing radio channel

Post by super_flie_guy »

Hey all, I'm pretty new to the Crazyflie(2.1) platform so perhaps this is just user error... but I've hit a bit of a conundrum and tried everything I could think to do with the python client, logging the results over crazy radio (all zeroes from the stabilizer) and leaving them on the stablest surface I could find until they could calibrate. No matter what I do, the problem drones always report the following output to console in the python client.
SYS: ----------------------------
SYS: Crazyflie 2.1 is up and running!

SYS: Production release 2020.06

SYS: I am 0x20383347344D5008002D0057 and I have 1024KB of flash!

CFGBLK: v1, verification [OK]

DECK_CORE: 0 deck(s) found

IMU: BMI088 Gyro I2C connection [OK].

IMU: BMI088 Accel I2C connection [OK]

IMU: BMP388 I2C connection [OK]

ESTIMATOR: Using Complementary (1) estimator

CONTROLLER: Using PID (1) controller

MTR-DRV: Using brushed motor driver

EEPROM: I2C connection [OK].

IMU: BMI088 gyro self-test [OK]

STAB: Wait for sensor calibration...

SYS: Free heap: 13216 bytes
With it just ending there and never completing the process as it normally would (and does) for the other drones I acquired, which I was able to compare it to.
SYS: ----------------------------

SYS: Crazyflie 2.1 is up and running!

SYS: Production release 2020.06

SYS: I am 0x20383347344D50070039004A and I have 1024KB of flash!

CFGBLK: v1, verification [OK]

DECK_CORE: 0 deck(s) found

IMU: BMI088 Gyro I2C connection [OK].

IMU: BMI088 Accel I2C connection [OK]

IMU: BMP388 I2C connection [OK]

ESTIMATOR: Using Complementary (1) estimator

CONTROLLER: Using PID (1) controller

MTR-DRV: Using brushed motor driver

EEPROM: I2C connection [OK].

IMU: BMI088 gyro self-test [OK]

STAB: Wait for sensor calibration...

SYS: Free heap: 13216 bytes

STAB: Ready to fly.
I speculated that it might be a some sort of hardware error, but thinking back it seems to have occurred the same way to two of my drones (which I then learned not to try on the others): I changed the radio channel from the default 80 to some other one following the upload of the newest firmware(https://github.com/bitcraze/crazyflie-r ... 020.06.zip) via the boot loader, which immediately caused them to go from sending telemetry data while connected to none at all. Switching back to the default channel unfortunately did not restore telemetry data, which prompted me to start trying to figure out why and then clued me into the stabilizer not calibrating. I'm not really certain what I could have done to bust the stabilizer otherwise, or how to return them to their original out of the box state (tried the python EEPROM script, no luck) so any advice you all could provide on what might have gone wrong or what I might be overlooking in the crazyflie that's accessible by Python would be super appreciated.
kimberly
Bitcraze
Posts: 1050
Joined: Fri Jul 06, 2018 11:13 am

Re: Stabilizer never completes calibration, appears to have started after changing radio channel

Post by kimberly »

Hi!

It is odd since the IMU test passed according to the debugprints....


Have you tried looking at the raw IMU values in the plotter of the cfclient?
super_flie_guy
Beginner
Posts: 2
Joined: Thu Aug 20, 2020 10:26 pm

Re: Stabilizer never completes calibration, appears to have started after changing radio channel

Post by super_flie_guy »

kimberly wrote: Mon Aug 24, 2020 9:45 am Hi!

It is odd since the IMU test passed according to the debugprints....


Have you tried looking at the raw IMU values in the plotter of the cfclient?
Hey there, sorry for not responding quicker, The plotter tab only provides the same output for both the working and non working drones when I connect them to the client (see the attached). It might be different for the one that can fly once it gets airborne, but I didn't test that since the other can't fly right now anyway. On the other hand the terminal logs for the cf client seem to show a slight difference between the drones. Here is the output of the working version vs the never stabilizing one. I can see that the extra bit refers to the loco deck (which I do not have, and never tried to configure) but is it possible I somehow put it into a loco deck seeking mode with the boot loader? I did not have the loco position tab open when connecting to the bugged out drone, and also didn't when I first flashed the firmware, but again any insights you all could provided would be super appreciated.

Normal output
INFO:cflib.drivers.cfusb:Looking for devices....
INFO:cflib.crazyflie:Callback->Connection initialized[radio://0/80/2M]
INFO:cflib.crazyflie:We are connected[radio://0/80/2M], request connection setup
INFO:cflib.crazyflie:Callback->Connected to [radio://0/80/2M]
INFO:cflib.crazyflie.platformservice:Procotol version: 4
INFO:cflib.crazyflie.toc:TOC for port [5] found in cache
INFO:cflib.crazyflie:Log TOC finished updating
INFO:cflib.crazyflie.mem:9 memories found
INFO:cflib.crazyflie:Memories finished updating
INFO:cflib.crazyflie.toc:TOC for port [2] found in cache
INFO:cflib.crazyflie:Param TOC finished updating
INFO:cflib.crazyflie:Callback->Connection setup finished [radio://0/80/2M]
INFO:cfclient.utils.logconfigreader:Parsing [stabilizer.json]
QObject::connect: Cannot queue arguments of type 'QList<QPersistentModelIndex>'
(Make sure 'QList<QPersistentModelIndex>' is registered using qRegisterMetaType().)
QObject::connect: Cannot queue arguments of type 'QList<QPersistentModelIndex>'
(Make sure 'QList<QPersistentModelIndex>' is registered using qRegisterMetaType().)
QObject::connect: Cannot queue arguments of type 'QList<QPersistentModelIndex>'
(Make sure 'QList<QPersistentModelIndex>' is registered using qRegisterMetaType().)
INFO:cfclient.ui.tabs.LEDTab:Memory: id=1, type=LED driver, size=24
INFO:cfclient.ui.tabs.locopositioning_tab:Crazyflie connected to radio://0/80/2M
INFO:cfclient.ui.tabs.locopositioning_tab:Requesting loco deck parameter
INFO:cfclient.ui.main:LED write done callback
QObject::connect: Cannot queue arguments of type 'QList<QPersistentModelIndex>'
(Make sure 'QList<QPersistentModelIndex>' is registered using qRegisterMetaType().)
QObject::connect: Cannot queue arguments of type 'QList<QPersistentModelIndex>'
(Make sure 'QList<QPersistentModelIndex>' is registered using qRegisterMetaType().)
QObject::connect: Cannot queue arguments of type 'QList<QPersistentModelIndex>'
(Make sure 'QList<QPersistentModelIndex>' is registered using qRegisterMetaType().)
INFO:cfclient.ui.tabs.FlightTab:[imu_sensors.BMP388]: 0
INFO:cflib.crazyflie.log:Have successfully started logging for id=1
INFO:cflib.crazyflie.log:Have successfully started logging for id=3
INFO:cflib.crazyflie.log:Have successfully started logging for id=4
INFO:cfclient.ui.tabs.FlightTab:[imu_sensors.HMC5883L]: 0
INFO:cflib.crazyflie.log:Have successfully started logging for id=5
INFO:cfclient.ui.tabs.FlightTab:[imu_sensors.MS5611]: 0
Never stabilizes output
INFO:cflib.drivers.cfusb:Looking for devices....
INFO:cflib.crazyflie:Callback->Connection initialized[radio://0/80/2M]
INFO:cflib.crazyflie:We are connected[radio://0/80/2M], request connection setup
INFO:cflib.crazyflie:Callback->Connected to [radio://0/80/2M]
INFO:cflib.crazyflie.platformservice:Procotol version: 4
INFO:cflib.crazyflie.toc:TOC for port [5] found in cache
INFO:cflib.crazyflie:Log TOC finished updating
INFO:cflib.crazyflie.mem:8 memories found
INFO:cflib.crazyflie:Memories finished updating
INFO:cflib.crazyflie.toc:TOC for port [2] found in cache
INFO:cflib.crazyflie:Param TOC finished updating
INFO:cflib.crazyflie:Callback->Connection setup finished [radio://0/80/2M]
INFO:cfclient.utils.logconfigreader:Parsing [stabilizer.json]
QObject::connect: Cannot queue arguments of type 'QList<QPersistentModelIndex>'
(Make sure 'QList<QPersistentModelIndex>' is registered using qRegisterMetaType().)
QObject::connect: Cannot queue arguments of type 'QList<QPersistentModelIndex>'
(Make sure 'QList<QPersistentModelIndex>' is registered using qRegisterMetaType().)
QObject::connect: Cannot queue arguments of type 'QList<QPersistentModelIndex>'
(Make sure 'QList<QPersistentModelIndex>' is registered using qRegisterMetaType().)
INFO:cfclient.ui.tabs.LEDTab:Memory: id=1, type=LED driver, size=24
INFO:cfclient.ui.tabs.locopositioning_tab:Crazyflie connected to radio://0/80/2M
INFO:cfclient.ui.tabs.locopositioning_tab:Requesting loco deck parameter
INFO:cfclient.ui.main:LED write done callback
QObject::connect: Cannot queue arguments of type 'QList<QPersistentModelIndex>'
(Make sure 'QList<QPersistentModelIndex>' is registered using qRegisterMetaType().)
QObject::connect: Cannot queue arguments of type 'QList<QPersistentModelIndex>'
(Make sure 'QList<QPersistentModelIndex>' is registered using qRegisterMetaType().)
QObject::connect: Cannot queue arguments of type 'QList<QPersistentModelIndex>'
(Make sure 'QList<QPersistentModelIndex>' is registered using qRegisterMetaType().)
INFO:cfclient.ui.tabs.FlightTab:[imu_sensors.BMP388]: 0
INFO:cflib.crazyflie.log:Have successfully started logging for id=1
INFO:cflib.crazyflie.log:Have successfully started logging for id=3
INFO:cflib.crazyflie.log:Have successfully started logging for id=4
INFO:cfclient.ui.tabs.FlightTab:[imu_sensors.HMC5883L]: 0
INFO:cflib.crazyflie.log:Have successfully started logging for id=5
INFO:cfclient.ui.tabs.FlightTab:[imu_sensors.MS5611]: 0
INFO:cfclient.ui.tabs.locopositioning_tab:No Loco deck installed
QObject::connect: Cannot queue arguments of type 'QVector<int>'
(Make sure 'QVector<int>' is registered using qRegisterMetaType().)
QObject::connect: Cannot queue arguments of type 'QVector<int>'
(Make sure 'QVector<int>' is registered using qRegisterMetaType().)
INFO:cfclient.ui.tabs.FlightTab:Changed effect to 0
Attachments
working.png
working.png (10 KiB) Viewed 2741 times
kimberly
Bitcraze
Posts: 1050
Joined: Fri Jul 06, 2018 11:13 am

Re: Stabilizer never completes calibration, appears to have started after changing radio channel

Post by kimberly »

Unfortunately the cfclient terminal output will not give that much useful information, only the 'console tab' is supposed to do that.

I don't see any value plotted in the plotter tab though. Please checkout the guide. The drones don't need to be flying for this.

You can check also if you are getting the same problem if you connect the crazyflie through microUSB to your computer
dominik.natter
Beginner
Posts: 17
Joined: Tue Jun 01, 2021 6:38 am

Re: Stabilizer never completes calibration, appears to have started after changing radio channel

Post by dominik.natter »

Hey everyone,

I felt like my problem fits best into this post. I have 10 Crazyflies and 9 of them work fine. One, however, does not ramp its motors (neither when running examples/ramp.py nor when connecting via my smartphone). So I started to investigate.

I saw that the M1 LED blinks only red every 2 seconds, thus I checked the console log for a potentially missing calibration. Judging from the log the IMU is fine (i.e., there's no IMU-related error), but the calibration still never takes place. This is the exact same behavior as in @super_file_guy's case. Here's my log (I removed all decks to be sure it's not a problem of the decks):

Code: Select all

SYS: Crazyflie 2.1 is up and running!
SYS: Production release 2020.04
SYS: I am 0x20303743575350170020004E and I have 1024KB of flash!
CFGBLK: v1, verification [OK]
DECK_CORE: 0 deck(s) found
IMU: BMI088 Gyro I2C connection [OK].
IMU: BMI088 Accel I2C connection [OK]
IMU: BMP388 I2C connection [OK]
ESTIMATOR: Using Complementary (1) estimator
CONTROLLER: Using PID (1) controller
MTR-DRV: Using brushed motor driver
EEPROM: I2C connection [OK].
IMU: BMI088 gyro self-test [OK]
STAB: Wait for sensor calibration...
SYS: Free heap: 13216 bytes
So from what I can tell the line

Code: Select all

STAB: Ready to fly.
is missing.

I further used the cfclient to create a log block with the IMU (accelerometer and gyro), which I then printed in the plotter. For a working Crazyflie this outputs a nice graph like here,
working_cf_IMU.png
but for the problematic Crazyflie the sensor values simply do not change at all as seen here
problematic_cf_IMU.png

Did a solution to this problem arise in the last few months? Please let me know if there's anything else I shall test with the problematic Crazyflie.

Thanks a lot,
Dominik
tobias
Bitcraze
Posts: 2339
Joined: Mon Jan 28, 2013 7:17 pm
Location: Sweden

Re: Stabilizer never completes calibration, appears to have started after changing radio channel

Post by tobias »

Sounds like a problem with the BMI088 IMU and that is unable to calibrate. Can you check the logging varables:

Code: Select all

LOG_GROUP_START(gyro)
LOG_ADD(LOG_INT16, xRaw, &gyroRaw.x)
LOG_ADD(LOG_INT16, yRaw, &gyroRaw.y)
LOG_ADD(LOG_INT16, zRaw, &gyroRaw.z)
LOG_ADD(LOG_FLOAT, xVariance, &gyroBiasRunning.variance.x)
LOG_ADD(LOG_FLOAT, yVariance, &gyroBiasRunning.variance.y)
LOG_ADD(LOG_FLOAT, zVariance, &gyroBiasRunning.variance.z)
LOG_GROUP_STOP(gyro)
These should output data even though it is not calibrated. Check especially the variances. They all need to go below 10000 for the gyro to calibrate.
dominik.natter
Beginner
Posts: 17
Joined: Tue Jun 01, 2021 6:38 am

Re: Stabilizer never completes calibration, appears to have started after changing radio channel

Post by dominik.natter »

Hi Tobias,

thanks for the quick reply. Your conjecture was correct: the variances are pretty high as seen here.
gyro_variances.png
For the sake of completeness I also tracked the raw gyro values and rotated the Crazyflie around all 3 axes (first roll, then pitch, then yaw). The motion is measured by the gyro indeed (I cannot give a statement on whether the values are correct or not though).
gyro_values.png
Now we know the culprit. I wonder is there also a fix for this or is it simply malfunctioning hardware that we have to live with?

Furthermore, as a suggestion from a Crazyflie-newcomer: if there's such a fixed threshold (10,000) implemented already would it be possible to tell the user in this case something like "waiting for gyro variances to go below the threshold of 10,000"? Maybe that could help to find out the problem more quickly.
kristoffer
Bitcraze
Posts: 630
Joined: Tue Jun 30, 2015 7:47 am

Re: Stabilizer never completes calibration, appears to have started after changing radio channel

Post by kristoffer »

Hi Dominik!

It looks like your IMU is broken, send us an email at support@bitcraze.io and we will handle it there.

- Kristoffer
dominik.natter
Beginner
Posts: 17
Joined: Tue Jun 01, 2021 6:38 am

Re: Stabilizer never completes calibration, appears to have started after changing radio channel

Post by dominik.natter »

Hi Kristoffer,

thanks a lot for your help! I have sent you guys an email.

Best,
Dominik
Post Reply