# fused IMU BN0055 or mpu60xx Autopilot

Thread Starter

#### dachbauer

Joined Mar 22, 2019
3
Hi,
Im trying to get as much info on imu design.
I have tried a bno055 in NDOF mode with and without fast cal. and also in ACC-MAG-GYRO mode, really at best it worked in the ndof mode. I used eulerangles.
For an autopilot, I am interested in a stable z axis, meaning pitch and roll, but mainly roll. to keep the craft upright. For now Im into planes.
When I put the Arduino with an LCD indicating roll pitch and a heading, in my car, I was not vey happy, with quickly losing calibration, showing wrong all the axis. I have now replaced the heading sensol with a hmc5883L, that improved the heading. After reading through some foren, I found that eveybody has those problems.
Then I read about quaternions, and rotation matrixes, to improve stability.
Does someone know how to work with quaternions in a rotation matrix? is it as simple as to update the matrix with fresh w, x, y, and z values comming from the sensor? Or do I have to do some calculations befor I even can use those values to put them into the Matrix.
And then I dont understand what should happen next. Why do I put those values in the Matrix, what happens after? What I want, is to get Angles theta, phi, psi. I could convert w, x, y, z quats right away, as they come from the sensor.
There is a bno055 library, called quaternion.h, it seems to have everything needed for a rotation matrix using quaternions, to get stable angles at the end. I couldnt find any codes samples that would interface it though.
An other thing is, maybe it isnt really necessary to go through all the math required, just to have a few more seconds accurate readings, if I have to use some reset procedure any way.
For example I sure know that the plane is wings level, when the compass changes its trend, same for pitch with an accurate baro sensor. Also groundspeed from gps can be used with gyroscopes, to correct for centrifugal force.
Appreciate any help,

#### Mark Hughes

Joined Jun 14, 2016
409
Hi @dachbauer,
Glad you joined the site -- happy to have you here!
So first off, the problem that you are seeing has more to do with the mechanics than it does with the math. Airplanes are noisy environments -- vibrations caused by the propeller/engine are transmitted along the fuselage to wherever you have the sensor-board mounted, then through the board to the sensor. I found this resource if you want to read more about how vibrations affects MEMS sensors (the type of sensor in the BNO055 are MEMS based).
So step 1 -- mechanically isolate the sensor from the rest of the plane -- this might be as simple as suspending the sensor in a cavity in the fuselage with some thick, barely taut rubber-bands.

The second issue is that even if you put the sensor on a 1-ton granite slab on solid ground, the gyroscope will still drift -- this is shown in the datasheet as bias stability (or bias instability). All MEMS gyroscopes drift -- and the amount of drift is unpredictable. So you have to employ techniques to deal with it. Gyroscopes are used to sense short-term rotational acceleration.
Typically what is done to deal with drift is intermittent recalibration -- in the case of the BNO055, I imagine that the designers make use of the compass for that. If you pull the raw data off of the sensor (3-axis Acc, 3-axis Gyro, 3-axis Mag), you've got to develop your own algorithms, which is a royal PITA. If you use the fuser core, BOSCH should be doing all the hard work for you -- that's the absolute orientation part -- it combines the information from the gyro/mag/acc to find a solution.

So -- now the good news -- for what it sounds like you are going to do -- you might not need a gyroscope. Sure, you'd need one if you were doing acrobatics, or using a fancy 3-axis gimbal camera. But if all you are doing is trying to fly straight from one point to the next, you might be fine using the accelerometer and magnetometer. (Accelerometer for pitch & roll, magnetometer for heading)

Also -- I found the ardupilot.org/ardupilot community -- it looks like they've solved all of your problems and it appears to be open source. http://ardupilot.org/ardupilot/

Hope this helps!
Best,
Mark

Thread Starter

#### dachbauer

Joined Mar 22, 2019
3
Hi@Marc Hughes

Thanks for your thorough reply!
First of all, I wanted to let you know, that Im not completely new to autopilots, Im just not a very good programmer, but working on that.
My first autopilot, just stabilising a plane, I built with 2 fluxgates, at a time the mems technology first started. Gps costed at that time 500\$ up.
Of course I know about ardupilot.
Now I have an other question.
I agree to your thought, that for stabilizing a plane, accelerometers only would be enough, without gyros, but one would need to know centrifugal force. Without knowing centripedal force, one would not be able to estimate attitude, for example in a coordinated turn, the overall resulting forces would set the z axis perfectly straight, pointing to the bottom of the plane, reading a false wings level attitude.
There are many ways to correct for such false estimates, one could subtract centrifugal force, an other approach could be taking changing direction into account, that would always occure when the wings are banked. The turnrate could also be sensed with a magnetometer. (Fluxgates are much more expansive today hihi).
Right now I have another question, about converting back from quaternions to angles I read up on it already.
Here the question:
Accelerometers dont drift. A little error in quantisation, or thermal drift doesnt matter much, the output voltage would always resemble the analog value, at a present time.
Rate of turn sensors can also resmble accurate rate at any moment, but in order to get an angle, the output has to be summed up, i.e integrated.
In the early days of gyro mems, the output was an analog voltage, something between 1-4V. That rate of turn voltage fed into an analog hardware integrator, like an op with a feedback capacitor, resulted in a voltage that resembled an angle. Without any drift, except thermal.
Todays rate gyros, with analog output are not available. The output of bno055, or mpu60xx is eulerangles, degrees/sec, or rate/sec.
Neither degrees/s, nor rate/sec is of any use, when comming itterated over spi or i2c, summing those values up must result in a very unacurate angle. And about the eulerangle output we don`t even know how its calculated. The mayor part of drift in a gyro comes from digitalisation, converting a analog signal in a time discrete one. see:

Is that, my approach, correct? Just theoretically? If I could integrate turnrates in hardware analog, then I could estimate attitude with a much higher accuracy, and over longer periods of time, without any math?
Of course eventually the gyros owuld have to be alligned somehow anyway.

#### Mark Hughes

Joined Jun 14, 2016
409
@dachbauer,
First of all -- I haven't flown a model plane since I was a teenager -- and I promptly crashed it (Hadn't even reached the end of the runway yet). I'm going to use that traumatic event as my excuse for forgetting the relevance of centripetal force on accelerometer readings! I wonder if there are other sensors that we aren't thinking of that might be of use.
And yes -- your approach appears valid theoretically -- but you might run into other issues in implementation. For example you might have to run the data through a 2 or 3 pole filter (maybe moving average?) to mitigate spurious readings.
Also -- I'm helping another user in this thread with the Quaternion question: https://forum.allaboutcircuits.com/...ithin-limited-area.158194/page-2#post-1376545 I'm just about to start working on some graphics that should help clarify things. It might be of interest to you. But really, unless you are doing acrobatics in your plane, you likely don't need to worry about gimbal lock.
Hope this helps.
Mark

Similar threads