IMU in conjunction with GNSS for inertial navigation?

I’m curious to hear if anyone has tried using acceleration/rotation data off the IMU as an adjuvant to GNSS for navigation. I’m interested in building a copter that can hover without much drift, so will require navigation below the accuracy of the GNSS. Does anyone have any data or practical experience using the IMU for navigation?

1 Like

Hello, I am newbie to Navio and Rasperri PI. I want to log the raw GNSS/GPS data from ublox T series or other unit, and the IMU raw data on memory device to perform a post-processing inertial navigation system. I have seen a thread on RTK that I must follw to do it for my UAV but I am wondering what is the first steps to achieve my goal? To get log raw data from GPS, time stams and IMU on Navio. Do I learn Phyton, Linux…? At the moment I have some experience only with Arduino, I will like upgrade to Galileo Intel but It could be the wrong way

Thanks

You can do this using a kalman or complimentary filter. Both are a way to combine data from several sensors to get a better measurement than what each individual sensor can deliver. The kalman filter can also use a mathematical model of the copter (how it reacts to acceleration etc) and the pilot inputs to give you a better estimation. The math is not that complicated and it’s by nature an iterative filter.
Here’s a tutorial: http://home.wlu.edu/~levys/kalman_tutorial/

Now on the more practical side of things you have to understand and take care of these:

  1. Accelerometer noise. The motors/props add a lot of noise to the accelerometer and this can saturate the sensor. Since you will double-integrate the acceleration to get position, noise translates into drift (a lot of drift). You have to filter this noise both mechanically (search for vibration damping) and digitally. The higher sample rate you can use the easier it is to separate the high frequency vibration data (100-500Hz) from the low frequency useful data (1-20Hz). You can use a butterworth 2-4 pole filter with a 20-25Hz cutoff.

  2. You need a very accurate AHRS to know precisely the rotation of the copter. This is needed to be able to remove the gravity acceleration from the accelerometer data - so that you’re left with linear acceleration only. Any error in the rotation will result in polluting linear acceleration with the gravity vector - in essence you will think the copter accelerates in some random direction. Again - a kalman filter can be used to fuse acceleration, angular velocity and magnetic field direction into a rotation. A DCM - like in arducopter - gives you the same data in a different format.

  3. GPS gives you data in WGS84 - lat lon alt or lla - format. The accelerometer givs you linear acceleration (after substracting gravity) in local frame of reference. You need to have both data in the same frame to be able to work with it. A very convenient space is ENU (Earth North Up) which is the tangential plane to the earth’s surface at the GPS location. Converting between WGS84 and ENU is easy. Converting from local linear acceleration to enu is also trivial once you know the copter DCM matrix (or quaternion).

The problems you’ll face is from both ends - gps data tends to jump around so you need to filter out high freq components (>1-2 HZ) and accelerometer data tends to drift a lot once you integrate it into velocity and then into position.

5 Likes

This was an awesome and extremely informative reply – thank you so much, I really appreciate it.

jeanleflambeur thanks. You would be a great professor . :slight_smile:

Glad I could help. Thanks for the compliment, although when it comes to control theory and signal processing I’m still very much a student :wink: