priseborough / InertialNav

Inertial Navigation Filter
BSD 3-Clause "New" or "Revised" License
626 stars 403 forks source link

Using This Code for AHRS or VRU applications #22

Open rafaelmendy opened 7 years ago

rafaelmendy commented 7 years ago

Hi Thanks for your impressive code. I want to use your code as a VRU estimation code. I mean, just estimating roll and pith angles. So in this application, the only observations are delta_angles and aelta_velocities. but in your code both of them are variable parameters and not observations. So i don't know how to run correction step in kalman filter. because there is no observation. Can anyone tell me that, how to use this algorithm in such situations?

xeonqq commented 7 years ago

Hello, @rafaelmendy I think in Paul's EKF, both delta angles (from gyro) and delta_velocity (from accelerometer) are used in the prediction step. The observation is the gps position and velocity. In order for Paul's Ekf to run, you would need a gps or motion capturing system in your design. Then roll and pitch you can simply calculate from the estimated quaternion. But if you just want to estimate roll and pith angles from a imu without gps, a complementary filter would also do the job.

rafaelmendy commented 7 years ago

Thanks for reply. I don't understand, where in Paul formulas, accelerometer data are used to correct gyro integration? In other implementations of kalman filter for ahrs or ins-gps, they use direct measurement of euler angles ( or quaternions) with accelerometers ( for examplepitch=asin(ax/g)) to correct gyro integration errors. but i don't find any similar action for correcting gyro integration errors. ofcourse it has gps and velocity and also mags. but usually accelerometers have most important role in gyro integration errors correction.

xeonqq commented 7 years ago

@rafaelmendy you are right and I have similar observations over other implementations of AHRS, they do only use accelerometers to correct gyro bias. The thing with this formula pitch=asin(ax/g) is that accelerometer doesn't measure gravity but acceleration, so this formular is actually wrong for non-static object. That's why Paul's formulation of the system equations are more accurate, he uses accelerometer to calculate deltaVelocity. And I think accelerometers also take part in correcting gyro bias, as in this formula vNew = [vn;ve;vd] + [gn;ge;gd]*dt + Tbn*deltaVelocity; there is a Tbn which is the rotation matrix calculated from gyro, so accelerometers and gyro are still inter-related. In the end, EKF do the magic of estimating the gyro bias.

rafaelmendy commented 7 years ago

@xeonqq yes you are right. In dynamic tasks, formulas like something that i mentioned, is problematic. But actually this is the magic of kalman filter that fuse (1)gyro, with ability to compensate for high dynamics with integration, and (2) accelerometers for compensating integration errors in longer times. the only error that can not be handled with this fusion is long term accelerations like centrifugal acceleration in loiter movement. specially if the radius of loiter is small. in these situations only a position or ground speed sensing (like gps) can compensate the estimation error. My question is that, how a simple gyro bias dynamic, that actually is a constant dynamic, can handle all integration error of gyros? Is Paul's Estimation method heavily dependent on location and velocity estimation? on the other hand, if gps fails, what is the performance of Paul's method in estimation of attitude? maybe other methods that use accelerometer directly, will be better in such situations?