Replies to This Discussion

3D RoboticsPermalink Reply by Chris Anderson on June 5, 2012 at 2:58pm

Ozan, this is really good work. The best way to integrate code into the official Ardu* codebase is to work within the dev team. Would you like to join? If so, please PM me your email address and I can add you to the dev list so you can get a sense of how it works.

Best,

Chris

Permalink Reply by Ozan Aktaş on June 5, 2012 at 4:20pm

Hi Chris,

i would love to join to dev team. I will send you my email address.

Best,

Ozan

DeveloperPermalink Reply by Andreas M. Antonopoulos on June 5, 2012 at 4:57pm

oh yay! more devs, we like more devs!

ModeratorPermalink Reply by Roberto Navoni on June 5, 2012 at 11:49pm

Welcome in dev group Ozan :)

Best

Roberto

Permalink Reply by Ozan Aktaş on June 7, 2012 at 3:30am

Thank you Robero, soon i will offer my other suggestions for v2.6. Keep update.

 

Best,

O.A

Permalink Reply by Ozan Aktaş on June 7, 2012 at 11:27am

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

 

Attachments:

• ellipsoid_fit2magnetic_data.m, 3 KB
• magdata.csv, 11 KB

DeveloperPermalink Reply by Marco Robustini on June 10, 2012 at 3:31pm

Very nice job O.A.!
I hope all this integration in the future code, i can't wait to test it!

Bests, Marco

Permalink Reply by afernan on June 11, 2012 at 11:04pm

Hi Ozan: welcome to dev´s. I´ll give a try to the Quaternion-DCM. I guess it´s enough with substitute the two files in the AHRS lib.

Thanks for your ideas.

Angel

Permalink Reply by afernan on June 11, 2012 at 11:15pm

I´ve loaded your code in a APM1 and made some hand test with  MP and works great. My impression is that reacts quicker and precisely than DCM code (It´s only an eye impression). I tryerd to torture it a lot and leave long time to see if it drifts and ...all OK. I´ll give a fly try this afternoon.

Angel

Permalink Reply by Ozan Aktaş on June 12, 2012 at 2:08am

Yes it is enough, but you must manually built it. I will update arducopter git soon with final status.

I am happy to hear that finally someone wants to give it a try :)

I also observed  norm of quaternions without any renormalization statement in the code, there was really super slow change in norm like 1 million part per second. Normalization with taylor expansion is more than enough. I use it now. I also compared two algorithms with moderate turn rates, there are even differences up to 1 degrees on the average which can be important for the stability of quad. With very slow rates there are indentical. I found that DCM algorithm underestimates angles especially with high angular velocities. There is also smaller numerical biases with DCM+quaternion hybrid algorithm since is intrinsically conserving magnitude of quaternions and is an exact solution, that's not linear approximation of kinematic equations.

Bests,

ozan aktaş

 

 

Unfortunetly i have a electronic problem with my card APM1 (No receiver inputs). I ordered new one with atmega 2560 and waiting for it now.

Permalink Reply by Guillaume Helle on June 12, 2012 at 2:48am

Ok it seems a very good algorythm!

Just a question : there is a Nasa patent on it.

What about the use of this algorythm for us? Is it Ok?

Bests,

Guillaume

Permalink Reply by Ozan Aktaş on June 12, 2012 at 3:08am

Patent was taken in 2000. Probably there is time limit for obsolescence (10 year or so). And it is a mathematical algorithm which can be derived very easly. I don't understand why someone needs to take a patent on it. Also for non-profit or non-military usage, i dont think it will problem. you may not use it :)

 

Bests,

Ozan

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page