When configured to output the Euler values, the values drift considerably when the IMU is sitting still on a desk and are erratic to the point to appearing random if the IMU is not perfectly still.

The pitch values oscillate slowly around 0, from 339 degrees to 20 degrees. The roll values also oscillate in a similar fashion between 350 degrees to 10 degrees The yaw values just drift, making a complete 360 in 42 seconds or so.

If you slowly pitch or roll the IMU 30 to 45 degrees the values become erratic.

Update: I sent an email to technical support per Kansukee's suggestion. It is a week later and I haven't received any response other than the "Thank you for contacting SparkFun Technical Support" auto-reply.

I used this to make a quadcopter flight controller. It's really nice having everything in such a compact package. It makes testing so much easier with everything being on one board. The SAMD21 is a great chip too!

Small form factor, low power consumption. Quick and easy to get up and going, I had half of my application built within 12 hours which is fantastic.

Really cool features: 1 cell li-poly AND li-ion (according to the charge IC's data sheet) charging. USB connectivity works well (most of the time).

The MPU-9250 and supporting library is a disappointment. The spark fun supplied library does produce data but it is essentially useless for most applications. There are errors in the code that make the output from this library unusable without modification. As an example the euler angle output provided are relative to some imaginary reference so a rotation of 90 degrees about the Z axis will swap pitch and roll.

There are a few steps skipped in the tutorial that require external tools or better code for calibration of the MPU-9250 to produce usable data.

The magnetomer has internal biases that need to be part of an adjustment made to each reading. The library does not have a function for retrieving these biases and writing the function requires some device specific commands. There are some examples on krswiner's GitHub https://github.com/kriswiner/MPU9250.

To obtain a decent magnetic heading the board must also be calibrated using either a calibration function such as the one provided by kriswiner on GitHub or MotionCal from the creator of the Teensy. The calculation will also need the aforementioned offsets. The library needs to be modified to handle this. Each board has different biases so the procedure is device specific.

I managed to link the Motion Processing Library external library so as to try out the MPL (functions preceded by inv_ are part of this library). Allegedly there is a 9DOF "Sensor Fusion" algorithm. This does not seem to work. I had hoped to use the pitch and roll from the DMP/MPL to provide a tilt and pitch corrected compass without using raw accel values. Unfortunately after startup the MPU-9250 DMP/MPL calculated pitch and roll will precess until the internal calibration function determines stability. After that the reading seem to be stable. Unfortunately, this leaves pitch yaw and roll in a state that is no longer aligned with the package body requiring additional coding and testing to provide an offset.

The thing that is really frustrating is that the DMP and MPL produce what appear to be a stable pitch yaw and roll output but it ends up off axis. For whatever reason the accelerometer readings are not re-integrated into the orientation processing to provide a world oriented position.

It is possible to use the raw values with one of the AHRS libraries out there but calibration of the gyro, accel and mag are needed for this to work correctly. This ends up being a lot of additional work.

The potential power savings of the DMP is pretty high so this is disappointing.

All in all, I have to agree with the previous review, "Not an IMU out of the bag". Getting this board to work at sample rates above 100-200/s will take substantial work. I wanted to give this 3 stars, but at the end of the day too many issues currently exist. I'd love to see some updated code and a hardware revision, there is substantial promise with this platform.

I would like to comment on a few things beyond what's mentioned in that earlier review.

One easy thing to change in the example sketch, which immediately improves the sample rate, is to ensure the code isn't polling the sensor more often than once per ms. The loop runs much quicker than that, and the sensor gets a bit confused if you poll it too often. Here's a quick stub of what I did to limit the sensor polling rate.

static uint32_t lastDisplayMs = 0;
uint32_t currMs = millis();

if (currMs > lastUpdateMs) {
  lastUpdateMs = currMs;

  .... sensor poll code here
}

One may also ask, why poll when interrupts are possible? Well... it's complicated, but possible.

In this release of the hardware, the MPU interrupt pin is attached to pin 4 in the Arduino environment. Unfortunately, the interrupt type attached to this pin in the ARM chip is what's known as a non-maskable interrupt (NMI), and there are some extra considerations. Likely in the interest of simplicity, the Arduino devs decided to disable support for interrupts on this pin. There is an unofficial workaround, which I have used with success.

If you'd like to modify your Arduino core files to allow interrupts to work with this hardware version, check out this link: https://github.com/arduino/ArduinoCore-samd/issues/248. Just make sure to read all the comments so you understand the possible issues.

I'm pretty sure SF is aware of this, as their 'interrupt' example (e.g. if (digitalRead(INTERRUPT_PIN) == LOW)... ) is really just a slightly faster way to poll the sensor.

Finally, to really get decent performance when logging to an SD card, the SdFat library is really needed. The base SD library is fine for a basic example, but some effort towards a lower latency SD logging example doesn't seem like too much to ask. For those interested, the SdFat/LowLatencyLogger example is a good start on more performant logging code.

To be sure, I don't expect SF to implement a myriad of examples. However, I do feel that the example provided in this case is lacking, especially considering the sensor library is largely written by a third party.

The good news is that after combining these pieces, it is possible to get this device to come close to 1k samples/s. Even when polling, I'm able to hit 950-1k samples/s saved to SD when this is the only sensor used, and limiting serial output to once every 30-45ms. Using interrupts, a solid 1k samples/s is possible.

A very capable processor. I'm not a huge fan of the "canned" functions, very slow. But easily programmable to do just what you want. Great for breadboading a concept or implementing in a hobbie project. The breakout version of the sensor is also good if you want to use a more powerful processor with more RAM.

I wish it was a little more robust, I fried the magnetometer with a neodymium magnet, maybe a little too strong. that also degraded the gyroscope badly. but i didn’t really need those anyway. i wrote a visual basic program which displays the accelerometers in oscilloscope type form, which i’m trying to see if i can adapt them for use on our machines at work to monitor the bearings. now i need to do it with wifi.

Reset is not brought out to a standard sized pad, more IO would also be appreciated - even SMT pads.

Bootloader is very slow to upload with Platformio, did not figure that out before I moved on to a different setup.

The IMU is not the latest version (TDK ICM-20948), performance is comparable but the interface, library and documentation are different.

On the plus side the packaging, features, size and IMU chip performance, make this an excellent platform for some interesting applications. The standard application that comes loaded on the device is very capable right out of the box. There is a wealth of information online on processing sensor data to remove biases and compute rotation and position.

Had issues with Serial1 port. No examples. Had to search in SAM21D section.

Just edit config.h, it is ready to use for my project.

it is handy thing. Software and hardware. But I can't properly callibrate yaw angle. It is flow +/- 10 deg. I try a lot of time in different places. But it is the same result.