MPU6050 + HCM5883L + Arduino Nano (switched to Teensy 3.1)

[delphir-com]

Hi guys! Nice discussion there. I`m working now on my own gimbal for panoramic photo shooting and decided to use sensors for excellent camera positioning. I have MPU6050, HMC5883L and Arduino Nano.. at first I thought that "sensor" part of my gimbal will be the easiest one as there are a plenty of samples in the internet, but once I started to work on it - I found this annoying yaw drift problem. So after a continuous googling I came to your github repo Mike and this thread :)

For now I have a very simple question: is it possible to upload your freeimu lib into an arduino nano without cutting the magnetometer code-part? the original freeimu lib easily fits into the Nano but it has a huge drift (sometimes even on pitch and roll). As I understand you have added a lot of optimisation/etc math algorithms to the lib which must help with Yaw, but this affected the size of the sketch :) Is there anything what can be shrinked from the lib wihout loosing it`s functionality for using with my hardware? For example you have mentioned about AHRS vs MARG algorithms and in my case looks like MARG will be better as I have a HMC5883L so in total with mpu6050 this will give 9DOF.. What else can be removed?

P.S. Thanks for your great job on FreeIMU lib, Mike. Without you it would be frozen in the 2012...

P.P.S. I`m also thinking now on buying Tennsy 3.1 for this proj to get rid of this memory problem, but I wanna be sure that I will not reach this Yaw problem again.. as before buying my current HW I have also checked the internet and found a lot of videos about "MPU6050 with FreeImu without Yaw drift" but nobody have mentioned that this is not the original FreeImu lib and that this changed one will require more memory :)

[delphir-com]

Can you please show me how your sensor values looks in calibration UI when you have rotations only around every axis (similar to my pic: ).

As you see there, accel "center" is placed exactly in the center of sphere, but magnetometer "center" value is not in a real sphere center.. Is it possible that because of this center offset I`m getting wrong results in the GUI ?

[delphir-com]

P.S. I`m talking about the "crosses" inside of the red/green/blue ovals .

[mjs513]

I will do a calibration on one of my sensors and shoot it to you tonight, but for a couple of samples check the wiki because I did upload some samples. Can you also post a picture after you hit calibrate?

But the answer to your question is yes, a bad calibration will affect not only the GUI but the algorithm and the compass readings.

On Sun, Oct 26, 2014 at 5:25 PM, delphir-com notifications@github.com wrote:

P.S. I`m talking about the "crosses" inside of the red/green/blue ovals .

— Reply to this email directly or view it on GitHub https://github.com/mjs513/FreeIMU-Updates/issues/7#issuecomment-60532981 .

[mariocannistra]

Hi. I just uplodaed a video https://vimeo.com/110142862 with the results of some changes I applied in various places (both in sketch and processing gui).
I still have to go through the scale calibration using the cal_gui.py script. I found it slightly slow, probably because it uses the same bursts approach to receive data. I had a look at the source and I'm not sure it will be possible to change it in the same easy way i used for cube_odo.pde. Please read the video description for details. I've used a different approach to detect zero motion directly in the sketch and used that "zero" the gyro and accel values. This allows me to better see the effects of the compass on the quats and on the heading. Please note that I'm now now using a butterworth filter also on the gyro and I'm trying different sample and cutoffs using the available filter templates. Please let me have your thoughts / feedbacks. @delphir: about the magnetometer "center" I'm sure you will see centered data after the calibration. Hopefully this will happen for me as well :-) Find below a couple of charts I got using excel and a 2D calibration (only X and Y) of the compass with a custom tool i think i will abandon now. First is raw data, second is calibrated with offsets and scale:

...and yes, my compass is noisy ( MPU 9150 ), hope to change that soon.

[mjs513]

Hi Mario

Hope you are feeling better.

I am at the office right now so I will check the python code when I get home but you should be able to change that to read data continuously as well. When I get the slow reads (typical with the 9150/9250 and some other IMUs) I just up the baudrates in the both the arduino sketch and GUI to 115200 and it works fine. I will check out the video when I get home. I am interested in your experience with the butterworth filter and values you use. Are you using the AP_filter library or you home brew? For the 9150 and 9250 I use the filter on the mag and accel data. For other IMUs I just use it on the accel currently.

One limitation that I found with not using burst reads (ps just looked at the serial sketch and think it is implemented wrong) is wireless interaction with arduino. I have been playing around with the 3dr radios (and xbee) and found that I have issues when trying to send data back to the arduino (this was yesterday and last night for the 3dr radio) while the data is being transmitted. Between trying to use matlab to read the data from the arduino and the 3dr experiments found an issue with the burst not working as advertised - will have to get that fixed and see what effects that has on the wireless transmission. I am using the approach that bursting the data will let me do a form of handshaking. Also looking at using the fastserial library that Arducopter and others use.

As for the calibration GUI I have have found that after calibration the sphere does get centered (assuming you have enough points on the spheres), so I don't think that will be an issue when you it try. Even used it wirelessly using an xbee at 38400 with great success a while ago. On Mon, Oct 27, 2014 at 11:24 AM, Mario Cannistrà notifications@github.com wrote:

Hi. I just uplodaed a video https://vimeo.com/110142862 with the results of some changes I applied in various places (both in sketch and processing gui).

I still have to go through the scale calibration using the cal_gui.py script. I found it slightly slow, probably because it uses the same bursts approach to receive data. I had a look at the source and I'm not sure it will be possible to change it in the same easy way i used for cube_odo.pde. Please read the video description for details. I've used a different approach to detect zero motion directly in the sketch and used that "zero" the gyro and accel values. This allows me to better see the effects of the compass on the quats and on the heading. Please note that I'm now now using a butterworth filter also on the gyro and I'm trying different sample and cutoffs using the available filter templates. Please let me have your thoughts / feedbacks. @delphir https://github.com/delphir: about the magnetometer "center" I'm sure you will see centered data after the calibration. Hopefully this will happen for me as well :-) Find below a couple of charts I got using excel and a 2D calibration (only X and Y) of the compass with a custom tool i think i will abandon now. First is raw data, second is calibrated with offsets and scale: [image: raw_data_chart] https://cloud.githubusercontent.com/assets/1177953/4793323/1ae1cc7e-5ded-11e4-90df-2ac257b59cf9.png [image: calib_data_chart] https://cloud.githubusercontent.com/assets/1177953/4793326/1f4eeac6-5ded-11e4-96e3-aa2ffb50894b.png

...and yes, my compass is noisy ( MPU 9150 ), hope to change that soon.

— Reply to this email directly or view it on GitHub https://github.com/mjs513/FreeIMU-Updates/issues/7#issuecomment-60611169 .

[mariocannistra]

Hi Mike. Yes, thank you. Better and with more energy to spend on this project :-) Thank you also for your last email, still have to go through all the thoughts we exchanged, but i started at least :-)

Yes, I'm using the AP_filter library . At the moment I'm using butter10hz0_3 for the accel and butter100hz2_0 for both gyro and magnetom. I've seen great improvement in the gyro data (values less frequently changing, i think good effect on noise).

Another improvement came from the offsets calibration made on binary unfiltered values.
I've used this code to run the calibration: http://www.i2cdevlib.com/forums/topic/112-another-auto-offset-calibration-sketch/ by "titous" in i2cdevlib forum. works really fine and it's the one that gave me best results with the 9150.

So now i have offsets calibrated at rest for acc and gyro, filters on all 3 and noticed I have iCompass running average in the sketch and also in the processing GUI. Probably i should use just one heading algorithm. i will try different combinations and see.

Since noise seems reduced, next step will be to run the calibration gui in python to get also the accel and magnetometer offsets and scale factors on the 3 axis. if everything goes well i would like to have these pushed through the serial instead of re-compiling with the new calibration.h. will see if it's possible.

About the burst thing: Ah! got it! now i understand why... the radio exchange. ok, actually i'm not using a radio so it could be just an option but i've modified a separate copy of the cube.pde so no problem. i'm also switched speed to 115200 but this wasn't enough so did further changes.

will keep you posted

[mjs513]

Delphir: here are a couple of image captures that I did with the altimu10 board that I have - not the best and have since redone it but will give you the idea. On the calibration page of the wiki there are a couple of videos and other images. The first is the uncalibrated and the second is the calibrated

Mario: Glad you are feeling better.

I will have to give your filter settings a try. I got tired of trying the different filters so I settled on the ones that are currently in library. :)

Just took a quick look at the link for accel and gryo offsets. Interesting. It is basically the same approach that I used for setting the gyro offsets and what happens when you send the imu a "g" command. I am not 100% sure about the approach for accelerometer. Will have to look into it and see the differences.

For the calibration.h file I was thinking about the approach of storing the file on the SD card and just reading it in at will. But you can push it through the GUI as well since there are default values set up already. I push some data already through the GUI to the sketch and just use a call to library function to set the data - check the code for loading pressure and Calib on/off. Probably a slicker way to do it. I am not a real programmer so I just do what works.

Interesting on the speed change - since I mostly use the 6000/6050 now (not real crazy about the akami magnetometers) I don't really have that problem. Still playing with the radio - think the real issue is the way processing does its serial thing. If I use matlab with the radios (just tried that) don't really see that problem. Have to rethink and break out the python GUI that I was tinkering with may work better - who knows, or maybe just use matlab. By the way not sure if you have Matlab but you can pick up a copy from mathworks for $150. (home use license).

[abshafique]

Hi mjs513, I want to use the FreeIMU with the Arduino DUE. Do you have any solution to this or are you planning on porting to the DUE any time soon? Thanks!

[mjs513]

I have tested the earlier versions on the Due. If you try it with the serial_ARM_cpu.ino sketch it should work. I have not tested it all the updates that I have made to library but forsee no major issues. If I get around to it i will retest over the weekend. On Fri, Oct 31, 2014 at 2:36 AM, abshafique notifications@github.com wrote:

Hi mjs513, I want to use the FreeIMU with the Arduino DUE. Do you have any solution to this or are you planning on porting to the DUE any time soon? Thanks!

— Reply to this email directly or view it on GitHub https://github.com/mjs513/FreeIMU-Updates/issues/7#issuecomment-61224269 .