How should be eulerActual graphs in correctly working CF firmware

[Yaro]

Hi all,

I've some dubpt on how should be eulerActual output on CF firmware when Attitude(Angle) is enable on Roll and Pitch. I've performed some test with different combination on IMU ouput values sings.

Changes in signs of IMU output values was made inside void imu6Read function in imu.c:

Code: Select all

void imu6Read(Axis3f* gyroOut, Axis3f* accOut)
{
	mpu6500GetMotion6(&accelMpu.y, &accelMpu.x, &accelMpu.z, &gyroMpu.y, &gyroMpu.x, &gyroMpu.z);

	//Here I change IMU output sings
	gyroMpu.y = -gyroMpu.y;
	gyroMpu.z = -gyroMpu.z;
		
	accelMpu.y = -accelMpu.y;
	accelMpu.x = -accelMpu.x;
	accelMpu.z = -accelMpu.z;
	
	...
	

Flag for IMU Biasing #define IMU_TAKE_ACCEL_BIAS was enabled and disabled in each signs combination.
Also, changes was made in distributePower to enable correct motors, note that this will not affect eulerActual values.
No other changes was made on CF Fw code.

Movement I've performed are in order: Pitch rotation forward, back to level position, backward then Roll rotation on right, back to level position, left then Yaw with CCW movement, back to pervious position, CW movement.

I've performed the first two test with IMU on top side as default without changes on IMU signs. First test is with Acc. Biasing disabled, second with Acc. Biasing enabled.
This are result:




As you can see in the second case I've "Spikes" on Pitch; If I perform a Pitch movement with a forward rotation I've a spike in opposite direction, then Pitch slowly goes to correctly position. What amazes me is difference in Pitch and Roll output when Acc.Bias is enabled and this "Spikes".

After that I've started to perform test with IMU on bottom side since my first intention is to make CF FW works in this orientation. I've performed sign combination test only on Acc output with Gyro y and z fixed inverted to follow right hand rule.

Here's results that are more significant:














I've never seen how should be a correct output graph, but I suppose it should be the n.3 with Acc.Biasing disabled.
Note the stange thing when I activate with n.3(Gyro: -y, -z | Acc: -y, -z) configuration Acc. Biasing, Roll acts as previous but Pitch have "Spikes".

In graph n.16(Gyro: -y, -z | Acc: -y, -x, -z) I've again, as I suppose, correct eulerActual output with Acc.Biasing enabled, but if I disable Acc.Biasing with this sign configuration(n.16 Gyro: -y, -z | Acc: -y, -x, -z) I've "Spikes" on Pitch and Roll acts as previous.

n.3 and n.16 configuration are somehow related.

Strange thing is with graph n.12 where I've something what I call "Attenuation", If I change Roll or Pitch with a small rotation this values remain constant over time if I hold position but when I perform more rotation I've an "Attenuation" on values even if I hold position. Also, I've a spike when I back to level(but not when perform rotation like in other graphs).

About rateDesired in graph n.16 I've found that after after I've performed a rotation and after that back to level position, rateDesired of Roll or Pitch never goes back to 0.

I've thought that CF FW is ready to fly when you load it, so I can't find where is the error. Also I've supposed that when you enable/disable Acc. Biasing you shouldn't change also IMU output, so this is somehow strange.

Someone have tips on what I'm seeing?
Also, can someone post me correct graphs of eulerActual and rollDesired from CF with respectively Acc.Bias enabled and Acc.Bias disabled(moving pitch forward and backward then roll left and right and then yaw CW and CCW)?

Thank you for any help!

[theseankelly]

Hey Yaro

Tons of awesome data here. I'm deeply interested in this area. Life is pretty busy right now and I haven't had a chance to really dig in to your findings, but I have every intention of doing so.

Couple things off the top of my head:
- Measuing accel bias is going to be a very hard thing to get right. You're basically measuring how far off the copter is from the true gravity vector. This measurement, if done correctly, will account for electrical bias as well as bias incurred by the physical mounting of the IMU. The problem is "if done correctly" -- the crazyflie needs to be on a *perfectly* level surface to get bias measurements correct. If the crazyflie, the table it's sitting on, the foundation for the house the table is sitting inside, etc are not perfectly level, you'll measure incorrect bias. Really the best way to to measure bias is to do so from hover, since there are few external factors other than gravity. Long story short: simply turning on accel bias measurements might be throwing your IMU off more than it was ordinarily.

- I do recall seeing similar spikes in the euler angles as you're seeing. Haven't dug in yet. If I remember correctly, I did NOT see the same spikes on the raw gyro or accel data, which suggests the Mahoney algorithm is to blame. There are a couple gains you can play with on that algorithm that might be incurring the overshoot.

[Yaro]

Thank you for your answer. Recently I've performed fly tests on each of this configuration and found problems in all except two. Some of them had a high increasing drift on roll "left side" and some had very large oscillations that prevented to fly.

I've found that with Acc.Bias disabled, graph 3. is the correct graph with Gyro z and y inverted. When Acc.Bias is enabled, graph 16. is the correct graph with Gyro z and y inverted, and Acc x, y and z inverted. With this two configurations I can fly stable and without problems.

It's strange that I was unable to get a correct RP graph with code getted as it is, but probably it's becouse code I've used is very old (CF FW 08/2015).

It's also strange that rateDesired doesn't go to 0 when drone back to level(but probably this have a sense), and also that max. and min. values of Roll and Pitch in rateDesired goes down to -1000 but never over +250 if I manually rotate drone. But, since it flies correcty and this values are too high for a normal fly, this doesn't create any problem.