SparkFun 9DoF Razor IMU M0

The SparkFun 9DoF Razor IMU M0 combines a SAMD21 microprocessor with an MPU-9250 9DoF (9 Degrees of Freedom) sensor to create a tiny, reprogrammable, multipurpose IMU (Inertial Measurement Unit). It can be programmed to monitor and log motion, transmit Euler angles over a serial port or even act as a step-counting pedometer.

The 9DoF Razor’s MPU-9250 features three 3-axis sensors—an accelerometer, gyroscope and magnetometer—that give it the ability to sense linear acceleration, angular rotation velocity and magnetic field vectors. The onboard microprocessor, Atmel’s SAMD21, is an Arduino-compatible, 32-bit ARM Cortex-M0+ microcontroller also featured on the Arduino Zero and SAMD21 Mini Breakout boards.

In addition to a pair of ICs, the 9DoF Razor IMU includes a µSD card socket, LiPo battery charger, power-control switch, and a host of I/O breakouts for project expansion. It comes preprogrammed with example firmware and an Arduino-compatible bootloader, so you can customize the firmware and flash new code over a USB connection.

Get Started with the 9DoF Razor IMU M0 Guide

  • Integrated MPU-9250 IMU and SAMD21 microprocessor
  • LiPo battery charger
  • µSD card socket
  • Preprogrammed example firmware that streams and/or logs:
    • Accelerometer, gyroscope and magnetometer data…
    • …and/or quaternions, and Euler angles
  • Arduino-programmable via USB
  • New MPU-9250 Arduino library with support for the chip’s digital motion processing capabilities
  • Extra SAMD21 pins broken out
  • System on/off switch

SparkFun 9DoF Razor IMU M0 Product Help and Resources

9DoF Razor IMU M0 Hookup Guide

December 1, 2016

How to use and re-program the 9DoF Razor IMU M0, a combination of ATSAMD21 ARM Cortex-M0 microprocessor and MPU-9250 9DoF-in-a-chip.

MPU-9250 Hookup Guide

July 28, 2016

Get up and running with the MPU-9250 9-axis MEMS sensor.

To use hardware serial.

For the hardware serial issues, see this forum post: https://forum.sparkfun.com/posting.php?mode=reply&f=14&t=45291&sid=a9427fa6f969d2777d15e1d0eed89394

You need to: * Edit out some code we use for testing in production. See the line beginning with ‘For production testing only’. * Change the baud rate on the ‘Serial1.begin’ line * Change config.h from ‘#define LOG_PORT SERIAL_PORT_USBVIRTUAL’ to ‘#define LOG_PORT SERIAL_PORT_HARDWARE’

Once that is done, upload the revised code and output will be on the RX/TX pins on the edge of the board.

The blue will pulse letting you know you’re in bootloader mode. (double check your COM port, it will change when this happens)


Common question.

https://github.com/sparkfun/9DOF_Razor_IMU/blob/master/Firmware/9DoF_Razor_M0_Firmware/9DoF_Razor_M0_Firmware.ino#L161 since it is looking for a “$” for testing. By changing a few lines and printing the string to one of the hardware UARTs, other serial UARTs can read the serial data. Additionally, the serial object is defined here => https://github.com/sparkfun/9DOF_Razor_IMU/blob/master/Firmware/_9DoF_Razor_M0_Firmware/config.h#L25 for the Arduino serial monitor or the hardware serial UART port 1 on pins 0 and 1.


Smart SOS

cesare tamagno

Wearable device for swimmers with an integrated visual detection system paired with an app for the rescuers.

CharlieTheRobot

CharlieTheRobot

Autonomous robot project combining Arduino Mega and Raspberry Pi. Uses Behavior tree for decision making.

Customer Comments

  • Anyone has a AHRS compatible firmware for it? I looked over here: https://github.com/Razor-AHRS/razor-9dof-ahrs/wiki/tutorial but they only have support for older Razor boards.

    Any help is welcome!

    Thanks

    • A bit late, but I tried my best to update the firmware to make it compatible with the M0 : see https://github.com/lebarsfa/razor-9dof-ahrs.

  • Driver installation on Windows 8.1 Pro doesn’t work. Driver is found but INF file doesn’t contain informations of numerique signature. Could you help me ? Edit: On Windows 10 Family, driver installation is not requiered ! Just plug and play. But I need to work with on my W8.1Pro. Windows says that you are the solution…

  • With the example firmware, the Euler angle Yaw drifts by roughly 1 degree a second when subject to no motion. Is this experienced by others? I’ve seen it on 2/2 boards I have tested. Thanks!

    • What you’re seeing is a very common problem in orientation sensing. As I understand it, the built-in DMP is fusing only the gyro and accelerometer. The magnetometer must be used for stable orientation on all 3 axes, which is the art of 9-DOF sensor fusion. This and many other relevant issues are well described in this wiki.

      As strider points out, there was support for 9DOF fusion in the previous razor board’s library (which was in fact a fork from the repo by the author of that wiki), though it’s mysteriously absent from this new version… it would be great to see this added!

    • I just observed yaw angle after leaving the new razor imu on my table; what you say happens in my Razor as well. I think the angles we observe are estimated only from gyroscope and accelerometer data; if magnetometers are calibrated and included in the estimation, the heading values can be much better. It was better in the previous version of the Razor IMU, in the code written by Peter Bartz. In that code, Peter provided soft and hard iron calibration of magnetometers; the complementary filter used there was taking the magnetometer data into account in heading estimation.

  • Dissapointing product and a rip-off. Compass doesnt output meaningful results. Library poorly designed and missing a lot of features i would expect when paying this premium e.g. tilt compensated compass out-the-box. Library hasnt been updated for years. Doesnt output to Serial1 and USB , despite the TX and RX pins, so you can use it like you would a sensor with another processor . Its a half-baked product at full price.

  • When logging the inertial data to an SD card, I frequently have huge outliers. For example, when i put the IMU flat i continuously measure -1g. However, when on the SD card I find occasionally large outliers. For example, on 9027 milliseconds:

    8951, 0.01, 0.00, -1.00, -1.28, -2.01, 0.67, 80.57, 49.06, -96.92

    8960, 0.00, 0.01, -0.99, -1.34, -2.01, 0.67, 78.62, 47.86, -96.02

    8970, 0.02, 0.01, -1.01, -1.28, -1.95, 0.67, 79.07, 47.86, -96.02

    8980, 0.00, 0.01, -1.00, -1.40, -1.95, 0.79, 79.07, 47.86, -96.32

    8990, 0.00, 0.01, -0.99, -1.28, -1.95, 0.73, 79.97, 48.31, -96.92

    9027, -0.00, 0.00, 1.21, -1717.44, 729.70, -1736.52, 80.12, 49.21, -92.87

    9101, -0.00, 0.02, -1.00, -1.40, -2.01, 0.67, 79.22, 46.96, -95.42

    9112, 0.00, 0.01, -1.01, -1.34, -1.89, 0.67, 79.07, 49.21, -94.67

    9121, 0.01, 0.01, -1.00, -1.34, -2.01, 0.73, 79.67, 48.46, -95.27

    9131, 0.00, 0.01, -1.00, -1.22, -1.95, 0.67, 78.17, 48.01, -95.12

    9142, 0.00, 0.01, -0.99, -1.28, -2.01, 0.67, 79.67, 48.91, -96.32

    9151, 0.01, 0.02, -0.99, -1.40, -1.95, 0.73, 79.52, 48.76, -95.12 How can I solve this problem?

  • I cannot have Li+ batteries shipped to my current place of residence. I found a 3.6V LITHL battery that lasts 7700mAh. Will I need to implement any protection measures outside of what’s currently implemented on this IMU? If not, what should I use? This will be going on a rocket, so space is limited.

  • Is it possible for this module to spit out the raw IMU data on the I2C bus to another microcontroller and still allow the SAMD21 to control the IMU? Also is it possible to have 2 of these boards on the same I2C bus? I see that the AD0 pin should be set to VCC and will require changing the IMU address on the SAMD21 for each module.

  • For charging, the Razor IMU supplies a 450mA Charge Current. What might happen if I used the Razor IMU to charge a 400mAh battery? eg https://www.sparkfun.com/products/13851

    Might this battery explode, or would it just be bad for the health of this battery?

  • Does the µSD card socket happen to support SDHC or SDXC? What is the max SD card capacity supported?

  • I find that the pitch and roll angles don’t seem to be independent. I’m using the firmware from the hookup guide that lets you turn the Euler angles on and off with the ‘e’ command and while the yaw seems right, the others are confounded. If you rotate the board about the x axis, the y axis changes significantly as well and vice versa. But rotating about z (laying board on table and twisting) only affects the z axis. Any idea why this is? It’s not very useful if you can’t separate the axes…

  • Is the Atmel’s SAMD21 low-level ARM Cortex libraries compatible with Arduino Due’s AT91SAM3X8E micro-controller?

    I want to know if I can use this 9Dof IMU at full capabilities with the Arduino Due instead of Zero.

  • If I am using the DMP example I get a drift of one degree about every 3.5 minutes. I thought it odd because the old 9DOF Razor’s magnetometer compensated for the drifting. With a quick test I noticed that the magnetometer is not being used (putting a magnet nearby shows no change in the yaw).

    Is this by design? Looking at dmp.begin() arguments it appears there is no argument flag for using the magnetometer.

  • Does anyone understood what are the Euler angle axes and the sequence which is used (to decompose quaternions into eulers)? It is supposed to send (pitch, roll, yaw) but I do not get which are the axes of these rotations? Are the Euler axes the ones of the Accelero/Gyrometer? If yes, then it means that the angles which are send should be rotation around the Yaccelero (“Pitch”) , rotation around Xaccelero (“Roll”) and then rotation around Zaccelero (“Yaw”). And therefore the final posture of the board should be easily reconstructed by applying successively -in the correct order YXZ, these three rotations. Does anyone have any clues about this?

  • Hi, I’m trying to get this to send data over the pins marked TX and RX on the 8 pin header on this module. Any idea which Serial port it corresponds to. Nothing seems to be working other than the SerialUSB at the moment.

  • Sorry if this an amateur question, but is it possible to make this a wireless unit with a lipo and a Bluetooth or other such device? If so, what are the connections? Wanting to make a wireless head tracker for PC games like flying and driving.

    • You should definitely be able to do that. The connections will depend on what type of wireless you want to do and how. The easiest is probably a bluetooth/wifi module that you can connect over the hardware serial ports on the board. The other (and much trickier) option is to use the OTG feature on the board and connect a USB boothtooth/wifi dongle. In this case you will probably end up writing ‘drivers’ for it, but it is also possible someone has already done it. Look into the Simblee board, the ESP8266, nRF boards, and the Bluetooth Mate as a few cheaper wireless options. If you have any other questions feel free to email our techsupport department.

      • So using a Bluetooth Mate, its just as simple as

        Razor IMU Mo —-> Bluetooth Mate Silver GND —> GND 3v3 —> VCC TX —> RX RX —> TX

        What does the RTS 0 and CTS I get wired to? Are they needed? Would this then be wireless to a computer paired by Bluetooth using a USB mini module?

        Thanks

        Rollo

  • When I followed the hookup guide, and finished “Install Arduino SAMD Boards” section, first I tried to verify firmware code “_9DoF_Razor_M0_Firmware.ino” but Arduino displayed fatal error: sam.h: No such file or directory. Then I tried to verify and upload “MPU9250_Basic.ino” located at the SF MPU-9250 library. I obtained the same fatal error.. Did anybody face this problem when verifying and uploading code to Razor IMU?

    • Arduino’s latest versions of the SAMD board definition’s (1.6.9+) tripped a few things up with the 9DoF Razor’s board definitions. We just pushed a compatible update to the board manager.

      Update the “SparkFun SAMD Boards” core to 1.3.2 by following the same steps in the Installing the SparkFun Board Definition section of the tutorial, but instead of clicking “Install” click “Update”. That should fix it.

  • Any idea of the fastest sampling rate to the uSD card?

  • Congratulations on the new MPU-9250 library. :D

  • Wouldn’t have been better to have the sensor at the center point of the board? If this board is spun (about the mid-point of the mounting holes), the accelerometer and gyroscope sensors will show periodic variations, rather than a simpler 0 acceleration and pure rotational changes.

  • I’m curious, how does this compare to the Razor board it replaced? Obviously, it uses an ARM processor instead of the Atmel one but how about the sensor itself? It’s an all-in-one unit now but I’m curious if the old one may have any advantage over this one in any way or if this is better all around.

    • This board has a much better IMU sensor. The old one used 3 separate chips for accel, gyro, and mag, while this board uses the all in one MPU-9250 IMU. That alone makes it better, no issues with small misalignments, but also, the newer sensor is generally better; less noise and more sensitive.

Customer Reviews

3.7 out of 5

Based on 9 ratings:

Currently viewing all customer reviews.

1 of 1 found this helpful:

So tiny, but so powerful!

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!

2 of 2 found this helpful:

Not an IMU out of the bag

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.

1 of 1 found this helpful:

Great idea, could improve execution (and move interrupt pin)

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.

5 of 5 found this helpful:

Euler values are not usable

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.

Sorry to hear about the issues with the Razor IMU.

Have you contacted our technical support team at techsupport@sparkfun.com - they’re usually pretty good at helping to get products working properly, they may have some strategies to help get rid of the erratic drift on the sensor.

1 of 1 found this helpful:

It's a good little device

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.

OK.

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

Easy to use.

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.

Good little unit that can do a lot of things

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.