Went to the park again today to test my new angles calculation; complete garbage – with Phoebe whizzing 25m forward before I killed the flight. The change to the angles had left me worried about calibration, specifically for the accelerometer, and to be honest I still do, but luckily I can leave that for another day: after checking the stats, the cause is quite clearly the complementary filter.

As I mentioned, the flight had Phoebe whizzing forwards across the park – i.e. nose down, and that’s quite clear from the integrated gyro pitch angle (i-pitch); it’s not surprising that it’s not visible in e-pitch, the Euler angles, but the fact the complementary filter (c-pitch) had effectively ignored the i-pitch clearly shows the problem. The tau was set to 0.25s but quite clearly from the graph the i-pitch contains critical, accurate information for at least a few seconds without obvious signs of drift. I think I need to start playing with tau at nearer 2.5s!

Just for comparison, I’ve dug out some stats from when I first added the complementary filter; in this test, the blades were not running, I was just manually tilting Phoebe – look how the i-pitch and e-pitch track each other, while the filter output (c-pitch) cancels out the gyro integral drift (i-pitch) – all shown in shades of blue:

Hopefully with tau sorted, I can go back to checking my new angles and putting my mind at rest about whether gravity calibration is correct / useful – more on that once I’ve made a decision.

Just an afterthought: it’s clear from the tests that the accelerometer Euler angles are varying wildly, so perhaps it’s better, at the same time as (say) doubling up tau to 0.5, I also increase the dlpf to 5Hz. Only testing will tell.

P.S. The big downward spike at the end was Phoebe doing a forward roly-poly at the end of the flight as her front legs clipped the ground while she was still travelling at several mph. Funny to watch and zero damage.

Hi Dave,

the euler angle seems too affected by vibrations.

Are yuo sure you are calculating it correctly?

Cannot find your last code.

That’s what I’m using:

def getAngleAcc(self):

“return the angle calculated on the accelerometer.”

pi=3.141592

#ATTENTION atan2(y,x) while in excel is atan2(x,y)

r=math.atan2(self.y_acc,self.z_acc)*180/pi

p=math.atan2(self.x_acc,self.z_acc)*180/pi

#Note that yaw value is not calculable using acc info

#function returns a value just for keep a consistent structure

y=0

where x_acc, y_acc, and z_acc are normalized values (if drone is placed on teh floor they are [0,0,9.8]

Oscar

Hi Oscar,

I’ve got my x’s, y’s and z’s the same way as yours but my overall calculation is different – for pitch it finds the angle between x axis and the (yz) plane – I picked it up off an accelerometer data sheet months ago about how to do Euler’s and never questioned it) – yours does seem to make more sense for measuring the angles in the pitch and roll planes. I’ll try it and see.

Thanks.

Andy

P.S. There is a math.pi constant defined in Python to save you defining your own – it won’t really change anything, but I thought I’d share.

Hi again,

I’ve just re-read the application note, and think my method of calculation is the right way – have a look at this:

Using an Accelerometer for Inclination Sensing

Your way comes back with angles for a spherical space, whereas the way I use produces angles for the (0, 0, 1) reference space that we are using.