Replies

  • Hi Khalid,

    I've been working with a FreeIMU V3 for some time trying to get a reasonable scaling on the sensor axis(using micro.net). I eventually thought my IMU was faulty. I then downloaded MultiWII software and had a look at all the drivers developed in the project. I hooked up my FreeIMU, modified the configuration to look for my IMU on the I2C port and dumped the program on a Arduiono Mini ATmega328, hooked up the IMU and powered up the system. MultiWII has a GUI that allows calibration of the sensors and a nice visual tool as well. The source is easy to read and, I would imagine, well tested. They have done a great job. I have multiple 'low cost' IMU's im using in prototyping and the MultiWII guy(s) have taken away a lot of the development pain with their sensor drivers.

    Have a look at their methodology - I'm sure you will find your answers there.

    Good luck,

    Antonie

    • I added this line to FreeIMU.cpp :

      accgyro.setFullScaleAccelRange(MPU60X0_ACCEL_FS_4); 

      The idea was to set the accel to +/- 4g, so that It would match how the ArduIMU 1.9.8 sets the accels.  I then used FreeIMU to initialize an MPU6050 using i2c instead of MPU6000 and spi.  I used the FreeIMU: my3IMU.getRawValues(raw_values) to replace the MPU6000_read().  I had to play with the sensor orientation and sensor signs in the ArduIMU sketch but it works. 

      I did it to see if I could use the DCM algorithm on a different board than ArduIMU and I can.  FreeIMU helped simplify it for me at least.

         

  • Please help!!! I really need to obtain those values!!

    • Khalid, I loaded the FreeIMUraw.pde and took a look.  I'd say it depends on how FreeIMU sets up the sensors so I took a look in the library MPU60X0.cpp file and the header file.  FreeIMU.cpp is using the

      #define MPU60X0_GYRO_FS_2000        0x03

      from the MPU60X0.h file to set the gyro at +/- 2000 degrees/sec

      I haven't been able to find how FreeIMU sets the accel but I'd guess it's a default and looking at the raw output it looks like +/- 2g.  That's based on the raw numbers that are about 18-21 so it'd be 2 * 9.8 m/s/s.

       

      • Okay, do I need to scale the values I get from getValue()? The values for the accelerometer are in the order of 1000s

        • Okay, after some digging in the source code, just like you suggested, I found that they set the full-scale range to 0, and according to the datasheet this corresponds to 16,384 LSB/g. So, I divided the values that I get by 16,384 and multiplied them by 9.81. The readings, as expected, are correct. I'm getting ~9.5 m/s^2 for z-axis when I hold the IMU horizontally. 

          Now, the question is do I need to do the same for gyro readings? how do I check If they are correct or not?

          • I found this line. 

            values[i] = ((float) accgyroval[i]) / 16.4f; // NOTE: this depends on the sensitivity chosen

            16.4f is the same resolution indicated by the datasheet for +/-2000 deg/s. I conjecture that the readings for the gyro are already scaled and they need no scaling from my side of code. Correct me if i'm wrong!

            • Good job!  I found this comment in the MPU60X0.cpp

               * FS_SEL | Full Scale Range   | LSB Sensitivity  * -------+--------------------+----------------
               * 0      | +/- 250 degrees/s | 131 LSB/deg/s
               * 1      | +/- 500 degrees/s | 65.5 LSB/deg/s
               * 2      | +/- 1000 degrees/s | 32.8 LSB/deg/s
               * 3      | +/- 2000 degrees/s | 16.4 LSB/deg/s

              Looks like 16.4f applies to the gyros too. 

        • What happens if you divide the accel values by 4096?  Do they then look like +/- 2g values?

          • If I divide one of the values by 4096, I get values between -4 and 4. What does that mean?

This reply was deleted.

Activity

gotham liked gotham's profile
15 hours ago
DIY Robocars via Twitter
RT @RoboticMasters: Monaco GP Circuit in the Donkey Sim (coming soon). Including buildings, tunnel and all! https://github.com/robotics-masters/sim-donkeycar-f1/tree/f1-tracks @diyr…
Wednesday
DIY Robocars via Twitter
RT @breadcentric: Here are the details of #AWSDeepRacer finals: https://blog.deepracing.io/2020/12/01/aws-deepracer-league-finals-2020-round-1-schedule/ #awsreinvent2020 #AWSreInvent https://t.co/ovqsjp8V…
Wednesday
DIY Robocars via Twitter
RT @breadcentric: #AWSDeepRacer League #awsreinvent2020 Open race is on Dec 1st - Dec 31st in three categories, 15 DeepRacer Evo (with LIDA…
Wednesday
DIY Robocars via Twitter
RT @a1k0n: @SmallpixelCar @diyrobocars It's just something that's easy to track with chroma keying. I ended up using different colors on th…
Monday
DIY Robocars via Twitter
Monday
DIY Robocars via Twitter
RT @TinkerGen_: "The Tinkergen MARK ($199) is my new favorite starter robocar. It’s got everything — computer vision, deep learning, sensor…
Nov 23
DIY Robocars via Twitter
Nov 23
DIY Robocars via Twitter
RT @roboton_io: Join our FREE Sumo Competition 🤖🏆 👉 https://roboton.io/ranking/vsc2020 #sumo #robot #edtech #competition #games4ed https://t.co/WOx…
Nov 16
DIY Drones via Twitter
First impressions of Tinkergen MARK robocar https://ift.tt/36IeZHc
Nov 16
DIY Robocars via Twitter
Our review of the @TinkerGen_ MARK robocar, which is the best on the market right now https://diyrobocars.com/2020/11/15/first-impressions-of-tinkergen-mark-robocar/ https://t.co/ENIlU5SfZ2
Nov 15
DIY Robocars via Twitter
RT @Ingmar_Stapel: I have now explained the OpenBot project in great detail on my blog with 12 articles step by step. I hope you enjoy read…
Nov 15
DIY Robocars via Twitter
RT @DAVGtech: This is a must attend. Click the link, follow link to read the story, sign up. #chaos2020 #digitalconnection #digitalworld ht…
Nov 15
DIY Robocars via Twitter
RT @a1k0n: Got a new chassis for outdoor races (hobbyking Quantum Vandal) but I totally didn't expect that it might cause problems for my g…
Nov 11
DIY Drones via Twitter
First impressions of the Intel OpenBot https://ift.tt/36qkVV4
Nov 10
DIY Robocars via Twitter
Nov 9
More…