If I pick my sensor board off the floor, the MPU6050 Z-axis accelerometer detects this.
Once off the floor and no longer rising, if I move forwards, and then to the left, the X and Y accelerometers do not detect this.
I've got the sensor set at +/- 2g, so with 16 bit ADC that gives a resolution of about 0.6mm /s/s which is fine enough to detect change in forward motion from 0 to about 0.5m/s
- dlpf set to 4 - 20Hz ish
- sample update rate at 500Hz.
- X, Y, and Z accelerometers all read 1g when pointed down so are working fine.
To me, this suggests a deadzone around 0g for small changes in horizontal (X, Y axis) acceleration.
Anyone else come across this?
Is there another interpretation of what I'm seeing?
Is there a solution for what I'm seeing?
Thanks,
Andy
Graphs etc @ www.pistuffing.co.uk
Replies
I have a dozen MPU6050 and none of them have a dead zone around zero in the X and Y axis.
If you rotate the x or y axis to point vertically, do you see gravity effect the reading? If no, then your sensor is bad or it's not being read correctly.
Your filtering is set oddly high (or low, if you look at Hz), but that shouldn't prevent gravity from effecting the readings as you tilt the sensor. Might not hurt to set the dlpf to ~250Hz while testing to make sure that is not part of the problem.
One (unrelated) questions? Why set dlpf as high as 250Hz? I'd always assumed that nearly everything above 10Hz was just going to be prop / motor noise - I'd assumed acceleration due to movement was not noisy once the props / motor noise was filtered out simply because of weight / momentum of the body. Hence that's why the dlpf is down at 20Hz
The lag induced by the high dlpf is so extreme that keeping the copter stable will be challenging to impossible.
The key to tight quadcopter stability is very low lag in the gyro. Since the MPU6050 ties the dlpf of both the accelerometer and gyro together, you're generally better off not filtering much on the MPU so that you get a faster gyro signal and then filtering the accelerometer more in the software if you need to. The gyro is not nearly as sensitive to noise as the accelerometer, so this works well.
In my own quadcopter code, I currently rotate the accelerometer vector from the aircraft frame into the earth frame before applying more filtering. This allows me to filter out vibrations while not filtering out aircraft movements that appear to be legitimate. I then use the cross product of the accelerometer vector and a vertical vector to detect error in my orientation estimate.
As a side note, it is ALWAYS better to eliminate as much physical vibration as possible. Digital filters removing noise are never ever as good as not having the noise to begin with.
Thanks Phillip, useful background
I'll have a go with trying higher frequency dlfp - it makes a lot of sense - I already have lots of code integrating / averaging both sets of sensor readings much like you describe so it should be relatively safe to up the dlpf frequency and see the results 'on time' rather than delayed.
Physical isolation from noise has always been a problem - I use a DJI F450 frame, and there just isn't much space for physical rubber standoffs for my controller near the center of gravity - double sided foam sticky tape (3mm thick) is the best I can do at the moment.
Of couse, I am making this hard for myself by only using a Raspberry Pi + Python code - no Arduino etc.
Best holiday wishes,
Andy
Thanks Phillip,
I tried pointing X and Y axes down, and they did show 1g as expected, so as you say they were fine - after a bit of thinking and digging around, I found a bug in my code that was creating the dead-zone (related to subtracting gravity from acceleration and how to get angles to rotate gravity correctly). Once the angles were right, then the results were much better.
Thanks,
Andy