I have worked out a new way to account for acceleration in the computations to detect roll and pitch gyro drift in IMU computations.
The method that is commonly used right now is based on computing centrifugal effects in the body frame of reference. This method requires an aerodynamic model of the aircraft that can be used to compute acceleration in the body frame using the rotation rate vector measured by the gyro, and the air velocity vector. As a result, this method has small errors when used with a fixed wing aircraft, and has large errors when used with a multicopter.
The new method, described here, does not require a model of the aircraft at all, so it is an exact method, not an approximate one. It is based on three innovations to the currently used method:
1. The roll-pitch reference vector is acceleration minus gravity, instead of gravity.
2. The calculations are performed in the earth frame, so there is no computation of centrifugal effects needed at all.
3. The computation uses a formulation based on integrals, which attenuates the effects of noise.
I have not yet tested this method, but I am confident that it will work. I will report back, and post a blog entry, when I have some test results.
Hi Andrew, Bill,
Thanks for the reply.
However, it looks to me that the null_offsets() routine is used to continually adjust the compass offsets in the long run.
What I’m actually looking for is the code that executes the compass calibration when you rotate the board in all 3 axes (for 30 sec) after you hit the “Live Calibration” button on the Mission Planner/Configuration/Hardware Options/Compass.
Hi Andrew, Bill,
Can you tell me how you do the testing for APM (esp. getting those graphs of the sensor outputs that are part of this discussion (seen in many replies).
I want to do similar testing (visually) for the project I have undertaken for stabilization of the camera mount (using APM, Ardupilot code) where I wish to study the IMU stabilized output for the servos and how they stabilize over time (PID settings).
Are there any specific tools (that can be setup easily) OR can we do that over Mission planner or something?
The graphs from tridge were produced with python scripts that I believed consume the tlogs from mission planner. If you're just getting started it's probably easier to use the mission planner itself to do the graphing. There are some descriptions here, here and here on how to do this. At a high level there are two types of logs in arducopter/arduplane...dataflash logs that are stored on the APM and tlogs that are stored on your computer if you have telemetry enabled.
Dear Bill, I am trying to build a framework for quadcopter that try to superposition different functions rather than calculating them all together.
I hope you give me your opinion.
I looked at your link. Sounds like fun and that you have some good ideas. I wish you well, and "may the force be with you." That is all I will venture to say.
I went through that link. Are you the author of that beautiful page "HefnyCopter"?
Thanks ... that is encouraging
Brillant job. Thanks a lot William.
I went through the code in file AP_AHRS_DCM.cpp, it seems ArduCopter(Quadcopter) runs only this algorithm on APM2 for gyro drift compensation.
But it relys on GPS and my APM2 flys perfectly indoors (with GPS intalled, having not location fixed).
Anyone has idea? Is there anyother gyro drift compensation algorithm (without help of GPS) in the ArduCopter?
Basic gyro drift compensation only requires accelerometer and magnetometer, both of which generally function indoors. This is used in the absence of good GPS data.
Thanks for reply, Philip.
I went through the function drift_correction function in class AP_AHRS_DCM. But I could not find any logic in the code that will redirect to other accelerometer based roll-pitch compensation when GPS is not available(yaw compensation based on magnetometer and GPS is clear for me now).
For APM2 based ArduCopter firmware, I think ahrs in ArduCopter.ino is a object of class AP_AHRS_DCM, while ins in ArduCopter.ino is a object of class AP_InertialSensor_MPU600. This understanding should be right for 3.01. and 3.1.5 version.
Would you please tell me more details about how the code shifts to accelerometer based roll-pitch compensation? if you are familiar with the ArduCopter code.
Thanks in advance.