Telemmetry slanted, but fly on straight surface

[fluxion]

It might be a problem with the MPU6050 sensor. First can you try the FW from this post that will print the self test values and post the values here. From them we can probably tell if there is something wrong with the sensor. Be sure to power it on when placed on a stable surface to get correct readings and then connect to the Crazyflie and look into the console output in the cfclient.

If there is a problem with the sensor Seeedstudio should cover it (either fix it or replace the unit) but it might take some time (shipping etc) so it is better to try to find the potential problem first before involving them.

Thanks a lot for the suggestion! Here's the output with the firmware you linked to. It looks like some of the lines are overwriting each other when they're sent or printed to the console, but i did 2 of them with a full device reset (on level surface) and reconnect between them, which between the 2 seems to provide the full set of data.

Code: Select all

p) CLEAN
SYS: I am 0x871910375552864966FFF48 and I have 128KB of flash!
IMU: MPU6050 I2C connection [OK].
IMU: HMC5883 I2C connection [OK].
IMU: MS5611 I2C connection [OK].
MPU6050: Self test gyro X. low: 10.0, high: 105.0, measured: 45.34
MPU6050: Self test gyro Y. low: -105.0, high: -10.0, measured: -47.72
MPU6050: Self test gyro Z. low: 10.0, high: 105.0, measured:MPU6050: Self test acc X. low: 0.30, high: 0.95, measured: 0.48
MPU6050: Self test acc Y. low: 0.30, high: 0.95, measured: 0.50
MPU6050: Self test acc Z. low: 0.30, high: 0.95, measured: 0.64
MPU6050: Self test [OK].
HMC5883L: Self test [OK].
MS5611: Self test [OK].

Code: Select all

ng!
SYS: Build 37:75f398b2283a (tip) CLEAN
SYS: I am 0x871910375552864966FFF48 and I have 128KB of flash!
IMU: MPU6050 I2C connection [OK].
IMU: HMC5883 I2C connection [OK].
IMU: MS5611 I2C connection [OK].
MPU6050: Self test gyro X. low: 10.0, high: 105.0, measured: 45.34
MPU6050: Self test gyro Y. low: -105.0, high: -10.0, measureMPU6050: Self test gyro Z. low: 10.0, high: 105.0, measured: 57.37
MPU6050: Self test acc X. low: 0.30, high: 0.95, measured: 0.49
MPU6050: Self test acc Y. low: 0.30, high: 0.95, measured: 0.50
MPU6050: Self test acc Z. low: 0.30, high: 0.95, measured: 0.64
MPU6050: Self test [OK].
HMC5883L: Self test [OK].
MS5611: Self test [OK].

Not sure how to interpret the data, but it doesn't seem to be too off from the data in the post you linked to. About to try the stable firmware as suggested in that post. Wish me luck!

[fluxion]

Not sure how to interpret the data, but it doesn't seem to be too off from the data in the post you linked to. About to try the stable firmware as suggested in that post. Wish me luck!

No go Retried with the firmware at the page below and problem seems to remain:

http://wiki.bitcraze.se/projects:crazyf ... ries:index

If it's not the sensors or firmware, what else could it be? Perhaps the PC client itself?

edit: went ahead and switched to stable PC client for linux, but no luck there either.

[tobias]

The self-test values seem to be fine but that might not mean that the sensor is fully functional. If the pitch and roll values don't read out as around 0 when placed on a level surface it is probably the accelerometer that is having problems. You can try tapping the Crazyflie on a table edge with the corner of the Crazyflie PCB to try to "un-lock" the accelerometer (if that could be causing it).

So the virtual horizon in the cfclient doesn't seem to follow the real Crazyflie movement at all or is it just "tilted"?

[tobias]

I have put together a FW (rename to .bin) that will print gyro and accelerometer values to the cfclient console. The cfclient console doesn't scroll with the output which is a bit annoying and should be fixed but it should be good enough to work with.

When the Crazyflie is placed level it should print something like this:

Code: Select all

IMU: GX:0.0	GY:0.1	GZ:0.0	AX:0.0	AY:0.0	AZ:1.0

[fluxion]

The self-test values seem to be fine but that might not mean that the sensor is fully functional. If the pitch and roll values don't read out as around 0 when placed on a level surface it is probably the accelerometer that is having problems. You can try tapping the Crazyflie on a table edge with the corner of the Crazyflie PCB to try to "un-lock" the accelerometer (if that could be causing it).

True, could still be the sensors, just seemed unlikely since I hadn't seen anyone else with a problem that couldn't be diagnosed with the self-test, but looks like that may be the case after all...

initial pitch/roll/yaw values hover around 1.3/-56/-10

I did actually try tapping it on it's sides last night after seeing some posts about that, also removed the battery and tapped on the sensor chip directly, but didn't seem to help unfortunately

So the virtual horizon in the cfclient doesn't seem to follow the real Crazyflie movement at all or is it just "tilted"?

It's a little of both: it's initially titled as if I'm doing a roll to the left, but responds as expected to changes in orientation, just everything shifted. However, over the span of a couple seconds it will start moving back to the tilted orientation no matter what the actual orientation is.

I have put together a FW (rename to .bin) that will print gyro and accelerometer values to the cfclient console. The cfclient console doesn't scroll with the output which is a bit annoying and should be fixed but it should be good enough to work with.

When the Crazyflie is placed level it should print something like this:

Code: Select all

IMU: GX:0.0	GY:0.1	GZ:0.0	AX:0.0	AY:0.0	AZ:1.0

Here's what I have:

Code: Select all

SYS: Build 37:75f398b2283a (tip) CLEAN
SYS: I am 0x871910375552864966FFF48 and I have 128KB of flash!
IMU: MPU6050 I2C connection [OK].
IMU: HMC5883 I2C connection [OK].
IMU: MS5611 I2C connection [OK].
MPU6050: Self test [OK].
HMC5883L: Self test [OK].
MS5611: Self test [OK].
IMU: GX:0.1	GY:-0.0	GZ:0.0	AX:0.0	AY:-1.4	AZ:0.9
IMU: GX:0.0	GY:-0.0	GZ:0.0	AX:0.0	AY:-1.4	AZ:0.9
IMU: GX:0.0	GY:0.0	GZ:0.1	AX:0.0	AY:-1.4	AZ:0.9
IMU: GX:0.0	GY:-0.0	GZ:0.0	AX:0.0	AY:-1.4	AZ:0.9
IMU: GX:0.0	GY:0.0	GZ:-0.1	AX:0.0	AY:-1.4	AZ:0.9
IMU: GX:0.0	GY:-0.1	GZ:-0.1	AX:0.0	AY:-1.4	AZ:0.9
IMU: GX:0.0	GY:0.0	GZ:-0.0	AX:0.0	AY:-1.4	AZ:0.9

Would those values correspond to the incorrect pitch/roll/yaw inputs?

[tobias]

IMU: GX:0.1 GY:-0.0 GZ:0.0 AX:0.0 AY:-1.4 AZ:0.9

The accelerometer Y axis which has a value of -1.4g is definitely off, it should be close to 0.0. It could probably be "calibrated" away as it seem to be an offset error since the self-test is passing but it is not the right solution. You should contact Seeedstudio customer support to have them fix it for you.

I have attached a FW that should take the accelerometer bias during startup. The Crazyflie must be placed on a level surface for it to work. I have not tested it my self though so it might not work at all but it could be worth a try.

[fluxion]

IMU: GX:0.1 GY:-0.0 GZ:0.0 AX:0.0 AY:-1.4 AZ:0.9

The accelerometer Y axis which has a value of -1.4g is definitely off, it should be close to 0.0. It could probably be "calibrated" away as it seem to be an offset error since the self-test is passing but it is not the right solution. You should contact Seeedstudio customer support to have them fix it for you.

I have attached a FW that should take the accelerometer bias during startup. The Crazyflie must be placed on a level surface for it to work. I have not tested it my self though so it might not work at all but it could be worth a try.

ok, this is crazy...it seems to work perfectly with this latest bios! did this actually set the bias to +1.4? i thought this was just to get a bias reading, but i don't see any extra data printed to the console, but it works perfectly!

if i switch back to the latest stable firmware it resorts to the old behavior.

if you could help identify/post what the fix might be it would be greatly appreciated, i don't mind too much needing to carry a small patch to build a working firmware. thanks!

[tobias]

If you are talking about the latest test FW I sent "cflie-accel-bias-calibration-b49p.zip" it takes the accelerometer bias (offset) during start-up. I just defined the IMU_TAKE_ACCEL_BIAS in top of the imu.c file. By doing this, when the Crazyflie is stable, it will take that orientation as being level. So if you put it on a non level surface it will take the bias wrong and it will drift a lot in the air when hovering. It would be possible to hard code the wrong bias value (+1.4) to avoid this.

[fluxion]

If you are talking about the latest test FW I sent "cflie-accel-bias-calibration-b49p.zip" it takes the accelerometer bias (offset) during start-up. I just defined the IMU_TAKE_ACCEL_BIAS in top of the imu.c file. By doing this, when the Crazyflie is stable, it will take that orientation as being level. So if you put it on a non level surface it will take the bias wrong and it will drift a lot in the air when hovering. It would be possible to hard code the wrong bias value (+1.4) to avoid this.

i see, so it should work fine now as long as i turn it on a flat surface, and if i want a more general solution i would leave IMU_TAKE_ACCEL_BIAS undefined and do something like this at the same spot in imuread()?:

Code: Select all

if (!accelBias.isBiasValueFound) {
  accelBias.bias.y += 1.4;
  accelBias.isBiasValueFound = TRUE;
}

Or would I still need to leave isBiasValueFound == FALSE so it will continue to add in the values from accelMpu earlier on in imuread()? If so, maybe just this?

Code: Select all

static bool hardCodedAccelBiasHackActivated = FALSE;
if (!hardCodedBiasHackActivated) {
  accelBias.bias.y += 1.4;
  hardCodedAccelBiasHackActivated = TRUE;
}

[tobias]

To hard code it you can just leave IMU_TAKE_ACCEL_BIAS undefined and in the imu6Init function place in the bottom:

Code: Select all

 accelBias.bias.y = int16_t(-1.4 / IMU_G_PER_LSB_CFG);

Since the accelBias.bias.y hasn't been converted to G yet it must be divided by the constant.