InertialNav icon indicating copy to clipboard operation
InertialNav copied to clipboard

Using This Code for AHRS or VRU applications

Open rafaelmendy opened this issue 7 years ago • 4 comments

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?

rafaelmendy avatar Jan 06 '17 13:01 rafaelmendy

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.

xeonqq avatar Jan 08 '17 18:01 xeonqq

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 example pitch=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.

rafaelmendy avatar Jan 08 '17 20:01 rafaelmendy

@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.

xeonqq avatar Jan 09 '17 09:01 xeonqq

@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?

rafaelmendy avatar Jan 09 '17 14:01 rafaelmendy