Replies

  • Hi!

    Due to my limited understanding of these things i can't really contribute to the discussion but i have something on my mind i want to post here because i think it is the right place to laugh about it :) . Gyros and accelerometers are disturbed more or less by vibrations in their measurements (acc >> gyro). Would it make sense to put some microphone or piezo directly to the frame (or sensor pcb) to measure these mechanical vibrations - perhaps it would make it easier to sort out some errors from a real change in attitude by some sort of "substraction"; perhaps the filtering can be more adaptive to the ammount that is really needed by knowing the frequency of disturbance? Perhaps a sudden and sustained increase of mechanical noise could trigger some sort of failsave (RTH) or a warning (light/sound). That's circulating in my mind for some time now since i played with some of the mwii acc code.

    Kraut

    Rob

  • I see it stabilize but it starts drifting again as soon as it is moved to a new orientation. Still very good performance and your support to ArduIMU is much appreciated! Thanks

    My application requires good yaw (heading) performance so I would like to try to reduce the drift. Do you or anyone else have any papers, links, or other sources of information on gyro calibration algorithms?

    In terms of GPS, heading accuracy is usually quite good (assuming some movement) and the update rates are 10+Hz on some units. I am going to look into adding GPS to FreeIMU but need to do research on it first. 

    Thanks again for the help in getting FreeIMU running on ArduIMU.

  • I doubt that having a GPS will improve heading accuracy much since it is a pretty low frequency and accuracy source of heading.. but I'm not really very experienced in GPS to say much about it.
  • Yeah, some residual drift is expected. Also note that with time it will stabilize if you held the board still.

    In theory we could get rid of it by better gyro calibration with thermal compensation but that's not something I'm very interested in right now since I'm pretty happy with what I do have. I'm not aware of any other open source project doing it better :-).
  • Thanks!! That was it. I had wondered about this as a problem but didn't know where in the code to fix it. I made the change to FreeIMU.cpp in getQ() by adding the second #elif i.e.:

    #if IS_9DOM()
    #if HAS_AXIS_ALIGNED()
    AHRSupdate(val[3] * M_PI/180, val[4] * M_PI/180, val[5] * M_PI/180, val[0], val[1], val[2], val[6], val[7], val[8]);
    #elif defined(SEN_10724)
    AHRSupdate(val[3] * M_PI/180, val[4] * M_PI/180, val[5] * M_PI/180, val[0], val[1], val[2], val[7], -val[6], val[8]);
    #elif defined(ARDUIMU_v3)
    AHRSupdate(val[3] * M_PI/180, val[4] * M_PI/180, val[5] * M_PI/180, val[0], val[1], val[2], -val[6], -val[7], val[8]);
    #endif

    I recommend this be added to the library.

    I am still seeing about 0.2 degree/sec of Yaw drift but will try calibrating again. I can't make out the numbers exactly but I think I can see this happening in your video as well. (thanks for the video!). Are you see this amount of residual drift in Yaw?

    I will consult the MultiiWii project as you previously recommended for including GPS. Do you think that will correct the rest of the Yaw drift?
  • Alpha version of the calibration GUI released. See http://www.varesano.net/blog/fabio/freeimu-magnetometer-and-acceler...


    Windows executables available.

    FreeIMU Magnetometer and Accelerometer Calibration GUI: alpha version out | Varesano.net
    I'm happy to finally publish a first working version of the FreeIMU Magnetometer and Accelerometer Calibration GUI. Currently, it should allow you to…
  • I wrote the modifications (mainly IC2dev) mentioned by Fabio in his post above. He also reported to me that users had compilation issues when trying to use this library "port"

    Fabio is agree to add the arduimu support, but we have to fix these issues.

    You can describe here all the problems Encountered when using the library
  • I've been also contacted by another ArduIMU user who also ported the FreeIMU code to the ArduIMU.


    He provided me his code at http://dl.dropbox.com/u/15226597/libraries.zip

    His approach has been different from Al. He modified the I2Cdev bus access code adding support for SPI too.. This way access to the sensors features are still made trough MPU6050.cpp both for I2C and SPI versions. Personally I find this approach more convenient because this way we don't have to maintain MPU6050.cpp and MPU6000.cpp which basically do the same stuff.


    What do you think?

  • There is a new release of FreeIMU with the updated calibration routines at:

    http://bazaar.launchpad.net/~fabio-varesano/freeimu/trunk/revision/18


    Also attached is a calibration.h file with how perfect sensors on the ArduIMU running FreeIMU should result.  I don't know if it is required but I use that version of the calibration.h file to compile and upload to theATMega328 with the FreeIMU_serial example.   I replaced the calibration.h file in the library folder FreeIMU\calibration with the attached version of the file and then ran the calibration Python py file

    I am getting private emails on ArduIMU with FreeIMU so and am recommending all subscribe to this forum to ask questions and discuss the topic here.  Here is some basic information about getting started:

    The way to "install" the version of the ArduIMU version of FreeIMU is to copy all of the folders in the libraries folder of the download above and then add the MPU6000 folder from the ArduIMU port to your Arduino folder.  Then replace the FreeIMU.h and FreeIMU.cpp files in the FreeIMU folder with the ArduIMU versions.  Also include the example file folders in the ArduIMU FreeIMU download to your sketchbook folder.  If you want to create your own ArduIMU/FreeIMU examples simply make the following changes to the #includes in the example sketch:

    add: #include  MPU_6000.h

    add: #include  SPI.h

    delete: #include MPU.6050.h

    One other thing I have done recently is to change the integral gain in FreeIMU.h:

    //#define twoKiDef  (2.0f * 0.1f) // 2 * integral gain
    #define twoKiDef  0 //integral gain

    This was suggested on Fabio Varesano's blog by another user and seems to really reduce the drift.  I readily admit I do not understand what this does (it may be detrimental for all I know!).  Please understand I am a user like anyone else and only did the programming so FreeIMU would run on Arduimu.

    So what are we going to do to get Fabio a ArduIMU board?  I still think either 3D Robotics or Sparkfun should donate a board to Fabio's excellent work.

    calibration.h

    ~fabio-varesano/freeimu/trunk : revision 18
  • After the huge response I got from this post <g>, I did the port myself.  This is for ArduIMU V3 and entailed creating an MPU-6000 (SPI) library, verifying the FreeIMU library for the HMC58X3 worked on the ArduIMU hardware, and updating FreeIMU.cpp and FreeIMU.h  to create an ArduIMU_V3 set of defines to conditionally build the code for that hardware.  I also updated a couple of the FreeIMU examples for test purposes.  In general, to have a program that uses the FreeIMU class, you need to add to the current FreeIMU example includes, two #includes for MPU_6000.h and SPI.h.  You should also remove the include for MPU6050.h

    The FreeIMU.h code on the ArduIMU hardware runs very well. It has a bit of yaw drift but that should disappear when I run the calibration function that is now available. 

    You cannot use ArduIMUTest with this system as the output format is not compatible.  Use either FreeIMU_cube or  FreeIMU_yaw_pitch_roll appropriately modified as above. 

    I have provided this code to Fabio Varesano, the creator of FreeIMU, and he plans to publish it in his repository. 

This reply was deleted.

Activity