hi Arducopter fans there,
i will try to give some suggestions regarding arducopter v2.6 before its release. Since there has been some time without any improvement about AHRs algorithms over recent arducopter versions. I think, the best place to begin is DCM algoritm itself.
My suggestion is to combine DCM and quaternion methods with their most superior parts. I know there has been a marg quaternion algorithm, but it is unnecessarily complicated. We know that DCM is easy to understand and has a better implemention for drift correcting algorithms and magnetic offset calculations. But DCM algorithm needs to orthogonalize and normalize rows or colums of the direction cosine matrix, also it is slightly inefficient due to 9 elements of the matrix is to be updated. As for quaternion method, only one vector of element size 4 needs to be updated and normalized. Actually, it is possible to integrate quaternions while preserving their unity. There is an algorithm for it. A DCM matrix, which can be calculated from updated quaternion will have aldready orthonomalized rows and columns. So i think it will be much more efficient and logical to do attitude update using quaternions with unity preserving integration and then calculate DCM representation from the updated quaternions and use it when necessary .
I have already implemented my DCM-quaternion hybrid suggestion. It can be easly integrated to the arducopter v2.5.5 code just using new versions of AP_AHRS_DCM library which i put in the attachments. I hope we will have more stable loiter and waypoint navigation in the future.
Kinds,
O.A
Replies
Ozan, I had a go at your code and it works pretty well. Unfortunately where I am now is very windy all the day, so it is difficoult to have a real comparison.
But I had more or less 6 batteries and had no issues at all.
What do you thing about gains in the DCM? Do you think they need to be updated, or should we just stick with defaults?
I'm talking about the KP_roll_pitch and KP_yaw.
Chers,
Emile
Hi guys,
my next suggestion for Arducopter code v2.6 is about compensation of unwanted magnetic effects such as hard-iron, soft-iron and scaling/calibration effects.
As we know that, since earth magnetic field is locally constant , the locus of all data points taken while a 3D magnetic sensor is rotated around every orientation, must be a sphere centered at origin. But in reality, it is generally a arbitrary rotated elipsoid centered at some offset from origin. Hard-iron effects, scaling errors and soft-iron effects are reasons for the offset, the elipsoidal shape and rotation of the elipsoid around some arbitrary axis, respectively.
Today, i rotated my arducopter with hand and meanwhile collected raw magnetic data from Diydrones magnetic sensor using logs of AP Mission Planner (after setting magnetic offsets to zero initially). What i found is my sphere was depressed on polar caps in the direction of z axis. I wrote a matlab function (see attachement) to find an elipsoid least square fit to the raw magnetic data. My results are below (See attachment for details).
Output parameters of matlab function (ellipsoid_fit2magnetic_data.m) are offsets and a transformation matrix. After translation of all data points using offsets to the origin and then applying transformation matrix (inverse W) , all magnetic raw data lying on the elipsoidal surface can be transformed to a sphere centered at origin eliminating hard-iron, soft-iron and scaling effects. Offsets i found are nearly similar to what AP mission plannner found. But for different calibration trials, contrary to my algorithm, live calib in AP mission planner gives slightly different results which i suppose was the result of using sphere least square fit (Tridge's algorithm) neglecting soft iron and scaling effects. As far as i know, Bill's latest automatic magnetic offset calculating algorithm in the arducopter v2.5.5 also neglects soft-iron and scaling effects. Someone may think that Diydrones magnetic sensor's built-in calibration deals with scaling error, however what i found says opposite.
My suggestion is to use elipsoidal fit algorithm in Mission Planner for the additional compensation of scale error and soft-iron effects and include transformation matrix into the code of arducopter v2.6, and then use Bill's algorithm. I suppose efficiency of algorithm will be superior.
Actually what i described here is not limited with 3D magnetic field sensors , it can be also applied to 3D accelerometers for calculating sensor offsets since gravitational field of earth is also constant locally. I also experienced scale errors for 3D accelerometers before. But data acquisition for compensation of accelerometer hard,soft and scale effects will be difficult unless eliminating inertial accelerations during the recording of accel data with different orientations.
Best all,
O.A
For documentation
http://cache.freescale.com/files/sensors/doc/app_note/AN4246.pdf
ellipsoid_fit2magnetic_data.m
magdata.csv
Hi Ozan have you a link or a reference of that on the Nasa site?
Best
Guillaume
Thanks Ozan for your suggestion, I pointed out this discussion on dev list.
Can you integrate your update in the latest GIT code? Have you tried this mod in flight?
I mean if there's substantial difference in the DCM library, i really want to try it.
Bests, Marco
Wow, nice shot! Are you from NASA?
Did you already try this on your copter or is it just a SIM implementation?
@Jani I think this is slightly different from what tried till now.
This is a Hybrid implementation using Quaternions and DCM.
Will have a look later and maybe try it on the SIM.
Thanks,
Emile
Ozan, we already tried quaternion several months ago and results were not as good as we expected. If you look our source code, you can still see custom quarternion compile time flags there and if you wan you can test them by your self too. But you need to compile codes manually.
After 1.5 months of endles work devs stopped to work with code at least for now. But if you have some more suggestions. Post them here and we can let our devs to check them out.