There's for example the Kalman filter (pretty complicated) and the complementary filter - the one I used. Remember the math? We wanted an integral, we approximated.
After a minute or so you will probably see a considerable error. You can get in a similar way the yaw using the Z-axis.īut is this enough? Better than the accelerometer? Well it's pretty precise. Now remember, for roll you use the X-axis of the gyroscope.Īnd with this you got Roll and pitch on the gyroscope. (100) //wait 100ms, let's imagine this is the time between measurements G_Y = Get_Y_measurement() //returns in º/s If you have a cycle doing this math, and the time between measurements (can be defined by the sensor measure rate) times the angular velocity will give you the angular displacement between measurements, right? Keep adding that and you will get a approximation of the integral (with a error of course, the smaller intervals, the better, but for example the MPU6050 can do more than 8KHz). Well we can't integrate but we can do sums, that's pretty close right? Very well, if you remember calculus, just integrate angular velocity to get the angle in a time interval. The problem with this is, quick movements will throw off the calculations, since there will be acceleration besides gravity. The cosine will be 0 (dividing by 0 is not a good idea), so you should avoid doing the Roll math if that's the case and just set Roll to 0º. Being X and Y the values from the accelerometer axes: Pitch = asin(-X) īe careful, if the pitch module is 90º. To get the angles I really liked ST's application note approach. Stand still (or just keep it moving at constant speed) and only gravity will be detected - which points always to the same direction: down. For this you use both the accelerometer and the gyroscope to compensate each others problems. Pitch and roll we're much more reliable to calculate. The gyroscope can be used to help out in a similar manner that will be shown for pitch and roll but I had problems with the turning point from 1º to 359º. For more info I think " Using LSM303DLH for a tilt compensated electronic compass " from ST is pretty good.
So for this project I will leave it here just to show a bit of yaw on the interface. I did implement some tilt compensation and a bit of hard metal and soft metal interference (look, already some concepts to be aware of) but it did not work good enough, 90º turns we're more like 80º turns you 110º. Test this out, to convert to degrees: int Degrees = magnetic_heading * 180 / PI Įasy right? But this is considering a no interference environment and no tilting (Z always perpendicular to the ground!). ? Because we want all 4 quadrants (check out the definition of atan2įor more info). How you do this in programming? Well you need: float magnetic_heading = atan2(y,x) //returns heading in radians This way you can easily get the angle that the X-axis is making with the magnetic north just from the X and Y. If you have the sensor like that, the Z will be considered irrelevant. First case - Z-axis perpendicular to the ground.Usually it's also considered the field to be parallel to the ground for calculations and then a bit correction are made to get the true north (versus the magnetic north) - these corrections depend on the year and localization. The magnetometer detects any magnetic field and considering a perfect environment, only existing the earths magnetic field is ideal for this purpose. Getting a Yaw from a 3-axis magnetometer can be easy - getting a correct yaw is hard. If you aren't interested in this and came for the processing, skip ahead.
I will not explain how to use these particular sensors, just how to use generic data. In my project, I used a MPU6050 which includes a gyroscope and an accelerometer and a HMC5883L.