Home | Product Categories | IMU | SEN-10736

9 Degrees of Freedom - Razor IMU

sku: SEN-10736 RoHS Compliant

Description: The 9DOF Razor IMU incorporates three sensors - an ITG-3200 (triple-axis gyro), ADXL345 (triple-axis accelerometer), and HMC5883L (triple-axis magnetometer) - to give you nine degrees of inertial measurement. The outputs of all sensors are processed by an on-board ATmega328 and output over a serial interface. This enables the 9DOF Razor to be used as a very powerful control mechanism for UAVs, autonomous vehicles and image stabilization systems.

The board comes programmed with the 8MHz Arduino bootloader and some example firmware that demos the outputs of all the sensors. Simply connect to the serial TX and RX pins with a 3.3V FTDI Basic Breakout, open a terminal program to 57600bps and a menu will guide you through testing the sensors. You can use the Arduino IDE to program your code onto the 9DOF, just select the 'Arduino Pro or Pro Mini  (3.3v, 8mhz) w/ATmega328' as your board.

The 9DOF operates at 3.3VDC; any power supplied to the white JST connector will be regulated down to this operating voltage - our LiPo batteries are an excellent power supply choice. The output header is designed to mate with our 3.3V FTDI Basic Breakout board, so you can easily connect the board to a computer's USB port. Or, for a wireless solution, it can be connected to the Bluetooth Mate or an XBee Explorer.

Having a hard time picking an IMU? Our Accelerometer, Gyro, and IMU Buying Guide might help!

Note: This product is a collaboration with Jordi Munoz of 3d Robotics. A portion of each sales goes back to them for product support and continued development.

Features:

  • 9 Degrees of Freedom on a single, flat board:
    • ITG-3200 - triple-axis digital-output gyroscope
    • ADXL345 - 13-bit resolution, ±16g, triple-axis accelerometer
    • HMC5883L - triple-axis, digital magnetometer
  • Outputs of all sensors processed by on-board ATmega328 and sent out via a serial stream
  • Autorun feature and help menu integrated into the example firmware
  • Output pins match up with FTDI Basic Breakout, Bluetooth Mate, XBee Explorer
  • 3.5-16VDC input
  • ON-OFF control switch and reset switch

Dimensions: 1.1" x 1.6" (28 x 41mm)

Documents:

Replaces: SEN-10125

Pricing

Only 6 left!

124.95
112.46
99.96

6 in stock

price
10-99
100+



Add to Wish List


Comments 117 comments

  • I purchased this board based on my hope (reading the production description) that it would be an elegant, relatively straightforward way to add an AHRS to my various projects. I’ve tried the 9DOF AHRS Code base that is provided above. It is out of date and doesn’t work. It doesn’t read the Magnetometer correctly. I’ve tried the “Updated Code”, but that isn’t really AHRS code. I see major confusion in the forum here about what AHRS firmware code will actually work, along with suggestions to try using the firmware of competing products (which I’ve tried and they don’t work either). I’ve tried them all with no good results.
    So, my question is this: Does anyone (at Sparkfun or in the forum) have a link to AHRS firmware that actually works on this board? Is anyone at all using this version of this product successfully? It seems like this is a very cool and important product for Sparkfun. If someone could link me to some functional AHRS that would be great.
    Any help would be appreciated.

    • Robert451,
      You are right. There is MAJOR confusion. I’ve got an older Razor and the magnetometer just doesn’t work at all. Have asked SF about a hardware patch (see above) but heard nothing. You’ve tried the latest board and still have problems – which doesn’t make me want to buy one after I’ve already bought one that doesn’t work and they can’t tell me how to fix it.
      As for code then I’m trying to create a plain vanilla AHRS/DCM system using WebbotLib (http://webbot.org.uk) that can be adapted to work with ANY gyro/accelerometer plus compass or magnetometer. Not released yet but if you want a .hex file to program the Razor with then give me a shout on webbot@webbot.org.uk
      Perhaps we can “get there” together since SF and their suggested AHRS code are totally out of sync.
      Perhaps SF should take lessons from the Mongoose board. The latter are clever enough to add an I2C header so that you can, at least, use other gyros/accel/magnetometers etc plus add any other I2C device.

      • The issue was a bug in the test/example firmware, not a hardware defect. The new firmware revision v22 has been pushed to the [github repo]{http://github.com/a1ronzo/SparkFun-9DOF-Razor-IMU-Test-Firmware} and all future builds will have this fix. Sorry for the confusion everybody!

    • I managed to get something working using http://code.google.com/p/mongoose-9dof-imu/
      “ckdevices” seem to be making a business out of reading complaints and making better products than Sparkfun. This isn’t an inexpensive board. Too bad it doesn’t work out of the box.

    • Unfortunately, we do not host the AHRS code, so we have no control over when it gets revised. However, the example/test code on future builds should work now with the new v22 firmware revision. See the [github repo]{http://github.com/a1ronzo/SparkFun-9DOF-Razor-IMU-Test-Firmware} for the updated v22 hex file. Also, keep in mind, SparkFun’s test firmware is only a demo of the sensors and does not implement AHRS.

      • What is the license for the AHRS code? Perhaps you should fork it, and then you can always make sure there is a version that works with your product. Better to have a version that may be out of date than a version that doesn’t work at all. Based on comments from other people, this looks like a pretty serious issue. I’d be pretty annoyed if I spent $125 on a board that said it was compatible with the AHRS code, only to find out that, uh, its not compatible with the AHRS code.

    • Robert451; I just received my board this week and have gone through the same frustrations as everyone else here (Poor or non-existent Magnetometer readings). A little research into the AHRS sample code previously linked(SF9DOF_AHRS link appears to have been removed) reveals a sequence of instructions in the I2C.pde file that may be at the heart of most problems. Looks like problem originates with the fact the the AHRS third party code was written for the previous Razor board which used the HMC5843 chip. The storage registers for the XYZ locations are in that order, however on the HMC5883chip the same registers hold the XZY data. When the code executes and reads the HMC5883 data it processes it according to the HMC5843 register sequence and generates garbage for yaw indications. I’ve tried different combination of register read sequences with varied but inconsistent results. Any programmer out there might have better luck.

  • The code under “9DOF AHRS Code Base” is not using the ITG-3200 gyro. It is using the old analog gyros which doesn’t work with the ITG-3200 and I2C. This can’t be the code you are shipping with, where is that code? The “updated” code is just some libraries for the ITG3200, not full Razor code.

    • The code that ships on the 9DOF is found in the Test Firmware link in the documents section above. This code simply outputs raw values from the sensors.

      • Ah, so this is a “develop your own imbedded-code IMU board” not a “ready to be used as an IMU board”. Personally, I would make that more clear in the description. Thanks for the reply! :)

      • The product description is extremely misleading. I understand that the unit ships with a test code. It also very clearly states that there is an AHRS firmware the allows you to use this as an AHRS.

        Upon not being able to get any kind of correct data out of the linked to AHRS code, I wrote tech support asking if I am doing something wrong. Here was the response:

        “…AHRS firmware is written by a 3rd party and has not been updated to use the ITG3200 yet. It also looks like in the past 6 months we’ve updated the magnetometer so its possible the code hasn’t been updated for that either.”

        I appreciate tech supports honesty and I wish the product description would have been half as clear because knowing what I know now, I would not have bought this unit.

  • Don’t expect to get a working out of the box AHRS with this board and the associated software (or the Mongoose software) without a correct calibration of the magnetometer … On mine, I had large hard-iron and non negligible soft-iron errors

    • Did you actually get the AHRS code to work? I’ve found that the code that is linked to does not support this version of the board.

  • I got an LabVIEW implementation of an AHRS with sensor data from this IMU:
    http://code.google.com/p/labview-quaternion-ahrs/
    Youtube vid of the stuff in action:
    http://www.youtube.com/watch?v=-uKoqIaFCpU

  • Hi,

    Great to see that the new AHRS has been updated for the new board. I was having a lot of trouble getting the FreeIMU firmware working properly with this board. It looks like Sparkfun is now contributing some of the proceeds to Jordi Munoz, who created the AHRS code. This seems like a very fair outcome seeing as though the board is effectively useless without the right code.

    In the AHRS code it appears as though there is a small error. The gyro x & y have been swapped around. This is very easy to fix though, I have included the necessary change below, but I think it should be updated on the code so that others don’t have this problem.

    Cheers,

    Mike

    —-Code fix —-Swap around gryo x & y values

    GYRO[1] = ((((int)buff[0]) << 8) | buff[1]);    // X axis
    GYRO[0] = ((((int)buff[2]) << 8) | buff[3]);    // Y axis
    GYRO[2] = ((((int)buff[4]) << 8) | buff[5]);    // Z axis
    

    —-Change gyro x to negative

    int SENSOR_SIGN[9] = {-1,-1,-1,1,1,1,-1,-1,-1};
    
    • Hi Michael,

      I was just about to release a tutorial and a updated and extended version of the AHRS code, because it seemed it wasn’t developed any longer and I had already done it a while ago. Now there is an update, but nevertheless I still want to throw it out, because I think it has some useful features (like sensor calibration, binary output mode, etc) and test program which is easier to run (because it uses Processing instead of Python).

      But I only own the predecessor of this board (SEN-10125, on which it works better than the original) and I can’t test if the code runs on this one too. As I see it, the only difference in using the new magnetometer is swapping y and z registers.

      It would be very very cool if you could test my code and see if it works! So I can give back the world some open code instead of just taking all the time :)

      Here’s the link: dev.qu.tu-berlin.de/projects/sf-razor-9dof-ahrs/files

      It’s just uploading the Arduino program and then starting the Processing sketch (using Processing 1.2.1: processing.org/download; versions 1.5 and 1.5.1 have a serial bug).

      Would be really great if you could do that!

      Cheers, Peter

      • Or maybe any one else could help me out here? My email address can also be found on dev.qu.tu-berlin.de/projects/sf-razor-9dof-ahrs

        • Thank you so much PeterBa. Tested your code here and it works very well. I have the 10736 version here and tested it with your processing and arduino code. Seems to work very well. I may need to do a little calibration before it’s perfect so I look forward to seeing this section of your tutorial. Let me know if I can help in any way.

          P.S. The latest code from a1ronzo also works now with the fixes suggested by michaelt88.

          • Cool! Thanks a lot, mrgoblin!! So it’s release-ready :)

            I just uploaded the final firmware version on the files page.

            I also completed the Tutorial and added the section about sensor calibration.

            Hope this will be useful to some people. Happy tracking!

            • PeterBa, great work. The software and tutorial you posted is way more useful than the one SF provided. Calibration is a little tricky, but once you get it, you’ll wonder how you ever used the SF code without it.

              The product post should probably be amended to say: “Note: This product is a collaboration with PeterBa. A portion of each sales goes back to him for product support and continued development.”

              Thanks so much for this great contribution.

              • Thank you dds21! Good to hear you like it!

                • Is the code compatible with the 9DOF stick from sparkfun? I believe all the chips are the same at this point, so would it just be a question of reorienting the axes?

                  • Hi, I don’t own the 9DOF stick, but like you said: It should work, but you’d have to reorder the sensor axes in this file: https://dev.qu.tu-berlin.de/projects/sf-razor-9dof-ahrs/repository/entry/trunk/Arduino/Razor_AHRS/Sensors.pde. If you want, let me know when you have it.. I can incorporate it into the Firmware. You can also drop me a mail.

                    • I’m having the same problem with the 10724. It appears that the MAG is rotated 90 deg CCW on the board compared to the Razor so that X is now Y and Y is -X. I’ve tried changing the SENSOR_SIGN value and the magnetom[] axis but I am still missing something. Any help?

                      • Hmm, I had a look at the datasheets and it seems the y accelerometer axis is not labeled right on the board, it should point in the opposite direction…

                        But other than that I see it like you said: magnetomter X is Y and Y is -X. You can send me your changed code via email and I have a look, if you want.

                        The forward direction should be towards the connector, too…

                        • That has been a source of confusion. When I looked at the data sheets, it looked like the Y direction was toward the hole and X was to the right for the Accel and the Gyro, but the Mag has the Y to the right and X toward the 4 hole row.

                          Got it! I changed around the values in the SENSOR_SIGN array to {-1,-1,-1,1,1,1,1,-1,-1} in Razor_AHRS.ino and switched the buffer addresses for magnitom[0], magnitom[1] in Sensors.ino.

                          Works as expected now.

                          • Ah, so you’re using the (older) SF9DOF_AHRS code and not the Razor AHRS Firmware. I can only speak for the latter one… Could someone try this? In Sensors.pde change the block in Read_Magn() to this:

                            #if HW__RAZOR_VERSION == 10125  // SEN-10125 uses HMC5843 magnetometer
                                // MSB byte first, then LSB; X, Y, Z
                                magnetom[0] = -1 * sensor_sign[6] * ((((int) buff[0]) << 8) | buff[1]);    // X axis (internal sensor y axis ( = -x axis on 9DOF Stick))
                                magnetom[1] = sensor_sign[7] * ((((int) buff[2]) << 8) | buff[3]);    // Y axis (internal sensor x axis ( = y axis on 9DOF Stick))
                                magnetom[2] = sensor_sign[8] * ((((int) buff[4]) << 8) | buff[5]);    // Z axis
                            #elif HW__RAZOR_VERSION == 10736  // SEN-10736 uses HMC5883L magnetometer
                                // MSB byte first, then LSB; Y and Z reversed: X, Z, Y
                                magnetom[0] = -1 * sensor_sign[6] * ((((int) buff[0]) << 8) | buff[1]);    // X axis (internal sensor y axis ( = -x axis on 9DOF Stick))
                                magnetom[1] = sensor_sign[7] * ((((int) buff[4]) << 8) | buff[5]);    // Y axis (internal sensor x axis ( = y axis on 9DOF Stick))
                                magnetom[2] = sensor_sign[8] * ((((int) buff[2]) << 8) | buff[3]);    // Z axis
                            #endif
                            

                            And you have to set HW__RAZOR_VERSION in Razor_AHRS.pde according to which magnetometer is on your 9DOF Stick. The newer Stick version 10724 matches Razor version 10736, the older Stick matches Razor version 10125.

            • this is great. I was looking for something just like this. I have an older version of the board but I don’t see any issue integrating your calibrations. I’ll let you know how it goes.

    • Hi Michelt88,

      I have somehow managed to get mine working with FreeIMU (thanks fabio) by using a workaround. I comment out the gyro feedback resulting into a more stable behavior. Even if this is not a perfect solution it removes the my drift on the yaw axis. Check out Simple-Sensors.co.uk It works for me for relatively low dynamic behavior.

  • Is the image set correct? What’s the 5th chip on the board?

  • LOL, “Attitude and Heading Reference System”. But anyways, I’ve been wanting one like this, thanks Sparkfun!

  • Your link to the ADXL345 brings you to the ADXL335 page.

  • The firmware still doesn’t really look complete. It only looks like there is an update for the gyro but it isn’t really part of the AHRS code. What about the magnetometer? This version uses the HMC5883L, but the AHRS Code Base still looks like it uses the HMC5843.

  • I think this website has complete AHRS firmware that will work for the Razor. http://store.ckdevices.com/products/Mongoose-9DoF-IMU-with-Barometric-Pressure-Sensor-.html

    • I could use the source code by ignoring “Baro” functions.
      But the source code has a limitation of horizontal direction.
      It can use only flat direction of circuit board.

  • FYI I believe the default firmware on the new IMU wants to talk at 57600, not 38400 as indicate above. If you get junk in your terminal @ 38400, try 57600.

  • Just connected up my 9dof board. As indicated, board is setup to 57600 baud not 38400 on default.
    Using the example firmware loaded – the data shows activity, accelerometer and gyro data make sense. Mag data is pretty wonky though. Static data at random position shows (for all outputs):
    $-13,32,199,42,-24,7,32,53,-516#
    $-14,33,201,43,-27,12,52,-517,31#
    $-14,33,200,41,-29,10,-515,31,51#
    $-13,33,199,41,-26,10,31,50,-521#
    $-14,33,200,36,-33,9,50,-517,33#
    $-14,33,199,39,-32,12,-517,30,50#
    $-13,34,198,35,-25,12,35,50,-519#
    $-13,33,200,38,-23,9,50,-515,34#
    $-14,33,199,41,-28,8,-518,32,53#
    Looks like one output is being missed with each row?
    Is this something I should worry about, or an artifact of the bootloader firmware?
    PS – looks same if I just choose Mag data.

    • I do have exactly the same problem with the same configuration. Are these boards tested with this test firmware after production ?

      • Thank you for posting that.
        Since they are using a new magnetometer – I bet the I2C data read is a little different that the old one. Looking at the firmware code, it appears it reads 6 bytes, then adds another read that is supposed to be needed to reset the index to 3 (where the first of 6 bytes is supposed to be loaded).
        I don’t see the need for this extra read when I look at the data sheet listed above.
        I suspect the “extra” read is no longer needed, and instead begins reading the next byte… which means that we are now offset with the next 3 reads. That matches what I am seeing.
        If Sparkfun allows me to update the firmware to test this out (and still allow me to send this back if there is a H/W issue), I’ll post again with my results.

        • I tried the following code
          http://www.drotek.fr/ftp/HMC5883.pde
          and data seem to be ok so the test firmware is probably outdated

    • I think there is 9 output in each row corresponding to each DOF. The problem is the output of the magnetometer. I guess the order of XYZ output is cycling.
      Have you fixed this bug? If you do, can I share your updated firmware?

  • In your description you say ‘HMC58883L’ – it should be ‘HMC5883L’ (ie too many ‘8’s).

  • I got this board working with the FreeIMU firmware (just configure for FreeIMU v3):
    http://www.varesano.net/projects/hardware/FreeIMU
    I’m thinking about buying some more for a motion-capture system. I’ve posted some enhancement requests for the next revision here:
    http://forum.sparkfun.com/viewtopic.php?f=5&t=29397

  • hi
    I’ve just bought a sen10736 board but i dunno how to use it! :?:
    is it necessary to use a USB-Serial module or I can connect it through a COM port to my PC?
    if so how?
    also the program on the mega328 is fixed or not? =If itsnt , whats the use of programming it when it is sending datas without reprogramming it.
    please help me to study how i can run the board.a

  • What is the item’s mass?

  • You know how much it draws on the 3.3v line ? less than 50mA or more ?

  • where can i get the source code for this IMU..?

    • Define ‘source code’? All of the files are near the top of the page under ‘Documents’ – this includes Eagle files for the board, the firmware, and the codebase.

    • ckdevices have complete code for their 9DOF IMU which uses the same sensors. Their code should work with this IMU as well.

  • I have the previous Sparkfun Razor-9DOF, it worked perfectly for more than a year but now the Z axle gyros, gives wrong measurements. (example on steady position Standard Deviation of a sample is 200+ , it should be around 0.8 like the other gyro axles). Can I do something about this? All the other sensors works fine.
    Thanks in advance

  • can i get more detail information what is sensor output and is the data out is processed angle … and are you using some filter or some other thing … and at what rate we can receive it ….

  • Has anyone managed to get the AHRS code to work properly with the latest revision of the board yet? Or does anyone know how to modify it to make it work properly?
    Thanks!

    • Sorry, I found the answer to my own problem. For anyone else who was wondering there is a google group for this with updated AHRS code its in the comments for the previous revision of this board.

  • Hi,
    is it possible, that the newest version of the code: http://code.google.com/p/sf9domahrs/ dosen`t work properly with the newest revison of the board ?
    The movement and the accuracy of the IMU is much more unprecisely as it should be.

  • hi ,
    I used ahrs code version 1.o and 1.1 [ tried both ].
    Python 2.7 , Serial , Win components and Vpython on Win7 x64 [ and tried on win32 ]
    Edit the comport on .py file.
    Try AHRS code on Arduino UI , open serial port with 57600 everything works. First initilization after !ANG’s coming. I can see the degree's
    After closing arduino ui and start .py file it draw interface and 3d box but nothing happened , console screen returns empty lines.
    No error message ?
    any ideas ?
    it returns ;
    Sparkfun 9DOF Razor IMU v1.06
    9 Degree of Measurement Attitude and Heading Reference System
    Initialization…(IMU flat and still)
    Offset values:
    18.26
    17.95
    18.71
    -88.94
    127.70
    -498.60
    !ANG:0.08,-0.08,0.09
    !ANG:0.14,-0.14,0.14
    !ANG:0.20,-0.20,0.21
    !ANG:0.23,-0.25,0.26
    !ANG:0.29,-0.32,0.33
    !ANG:0.35,-0.35,0.38
    !ANG:0.26,-0.25,-0.80
    in arduino serial monitor.

    • O solved problem. It’s related about rebooting arduino.
      I add
      ser.setRTS(False)
      line and everything looks ok.

  • Hi, I hope anyone can help me.
    When I am turn the Razor (360 degree)in yaw axis parallel to the ground (pitch and roll = 0) then compass show incorrect values, just a range of -35 to +35 degree. I had tested some different firmwares, but always the same problem.
    When I turned also the pitch axis additional, then the right value is shown.
    Have anyone an idea?

  • Hi, did anyone get the updated AHRS code (http://groups.google.com/group/sf_9dof_ahrs_update) running on the latest version of the IMU? On SEN-10125 it works perfectly, however, on SEN-10736 the magnetic reading gives wrong values.
    If I’ve seen it correctly, there are (at least) two differences: the chip is oriented differently on the board and the data registers of the magnetic sensor are in a different order (x,z,y instead of x,y,z). However, so far, I wasn’t able to get it running. Anyone can help?
    Thanks

  • Is the link for updated code correct? Above on this page, under “Documents:”, I see a link titled “9DOF AHRS Updated Code (thanks Sean!)”, when I click on it it takes me to page which seems to be Arduino code for an ITG-3200 3 axis gyro not a 9 Degrees of Freedom – Razor IMU. Does anyone know where I could find the updated code for the 9 Degrees of Freedom – Razor IMU?
    Thanks in advance.

    • Here you can get the updated AHRS code which works correctly on SEN-10125, however, on SEN-10736, the magnetometer reading is wrong, and thus the stabilization of the gyro in the yaw axis is incorrect (more details, see google group):
      http://groups.google.com/group/sf_9dof_ahrs_update
      -tobs

      • If you think there is a hardware defect, please contact techsupport at sparkfun dot com. We would like to get a board in our hands to verify your issue.
        Also, the orientation of the mag has changed since it is a new part, but the axis labels should still be correct.

  • Anyone can comment how this with the given firmware (freeIMU etc) compares with other commercial IMUs like xSens, PNI space point fusion or VectorNav? Is sensor noise a problem here? Or the free firmware has a good kalman filter that eliminates these problems?

    • The default (free) firmware simply outputs the raw values from the sensors, there are no calculations or filtering.

  • This is now the 3rd (released) revision of the Razor board and one would have thought that life would become easier. Alas not. The ability to download the correct firmware for the correct board from this site is a nightmare. Posts on each product forum would agree.
    Revision 1 of the board (http://www.sparkfun.com/products/9623) had a serious problem with the magnetometer (see http://forum.sparkfun.com/viewtopic.php?f=14&t=14756 and lots of other Google hits). This renders mine next to useless. After 2 weeks of playing the hardware only works once in a blue moon. Yes I’ve tried 6v unregulated to the battery header, +5v regulated to to the battery header, 3v3 to to the FTDI input etc etc. It just doesn’t work! All the forum posts say is that I have to solder on a new SMD capacitor which I cannot do (why would I buy an SF breakout board if I can do my own SMD work?)
    So:
    1. What is SFs policy on returning items that do not work due to their own bad hardware design?
    2. Does such a policy apply to their worldwide dealers as well?
    3. Is the latest revision of the board free of such issues?
    4. Why would I want to risk spending another $125 to buy another version of their board when I have already spent $125 on a board that doesn’t work – unless they guarantee that the answer to 3 above is ‘Yes – it works 100% irrespective of power source'
    5. Isn’t it rather telling that there are lots of other posts saying 'use the Mongoose firmware with the Razor’ – when they could just say ‘buy a Mongoose’.
    I don’t expect to get any sensible reply from SF as they normally only reply to the posts that suit them. May be I’m better to save future money that I would spend on ‘SF breakout boards’ and spend it instead on kits to allow SMD ICs to plug into a breadboard.
    Rant over. Now waiting for the usual silence…..

    • Thanks for your input! BTW, if you need anything returned or would like to receive support for your issues, please contact techsupport at sparkfun dot com.
      The possible issue with revision 1 seemed to be part of a larger issue with the magnetometer. It seemed to affect anyone that was using the example schematic in the datasheet. And there is nothing in the datasheet to indicate special attention needed to be paid to the capacitor in question. Either way, we have since moved to a new mag.
      As for the more recent revisions. Yes, the hardware has changed (and will continue to change) and thus any code for the board must change, but there is nothing defective in the hardware, as far as we know. We don’t host the AHRS code, so we have no control over if that gets updated. As for the example code that is sold on the board, it might have a bug, which would explain other’s issues. We will look into this and push a rev if need be.
      Thanks for voicing your concerns!

      • Thanks for the quick response.
        It’s re-assuring that this version of the board appears stable.
        Comparing the datasheets for the new HMC5883L and the old HMC5843 they both mention using low ESR caps, and removing any traces from under the chip. The only difference appears to be the addition of 0.1uF caps between Vdd and Gnd.
        Given that buying another board is not an option for me at the moment can SF give any official advice on how to ‘fix’ the older boards (ie adding the extra caps and/or replacing existing caps with low ESR ones). Or is it a more fundamental issue?

        • Oops – now Robert451 has posted to say the magnetometer value is wrong. Did I speak too soon. The two magnetometers are the same other than the Y and Z values being reversed in the I2C registers.

          • The issue was a bug in the test/example firmware, not a hardware defect. The new firmware revision v22 has been pushed to the [github repo]{http://github.com/a1ronzo/SparkFun-9DOF-Razor-IMU-Test-Firmware} and all future builds will have this fix. Sorry for the confusion everybody!

  • I just purchased this board along with the 3.3V FTDI Basic Breakout. I connect it to my PC. When I first plug it into the USB port, the green status light flashes once, then twice quickly, then stays off. There is a dim red light near the power jack that stays on that I assume is the power indicator. I bring it up in the Arduino Terminal window set to 57600 baud. I see the menu, but whenever I type any of the choices, such as 4 to show raw data, the menu just displays again. No data comes out. So, the board seems to be alive, and running the Test Firmware, but I can’t get it to display any raw data. I’m sure I’m missing something simple.
    What am I doing wrong?

    • Ignore this. I figured out my problem. I had the Arduino Terminal window set to Carriage Return. WHen I set it to “No line ending” the data started flowing.

  • Does anyone have even interface it with Xbee, if yes, how is connected

  • Hi, is there anyone who tried to communicate between Razor IMU and some ARM board via serial?

  • So, plz someone tell me IS it really true that “The board comes programmed with the 8MHz Arduino bootloader and some example firmware (not AHRS) that demos the outputs of all the sensors” ??
    Ive just connected my board to a FTDi 3.3v – the red LED is ON and the yellow one is blinking but there is no serial T/R !!
    what should i do??!
    and also Ive download the code suggested above but I couldnt find any .pde file for the test firmware,so that i could reprogramm my board.
    any help is fully appreciated.

    • You’ll need to upload the .hex file using avrdude or similar.
      On linux I use

      avrdude -C~/avrdude.conf -v -v -v -patmega328p -cstk500v1 \  
         -P/dev/ttyUSB1 -b57600 -D -Uflash:w:/path/to/file.hex:i
      
  • Are you planning to make a new PCB design that would also provide some of the PWM outputs of the processor?

  • Am I the only person that is not able to utilize the AHRS functionality of this chip? The 9DOF AHRS Code Base linked in the description is out of date.

    The SF firmware appears to work perfectly, returning reasonable value on all sensors. When you upload the SF9DOF AHRS 1.1, the gyro returns only zero values. It looks like the code in the link was last updated February 2010.

    Sparkfun, please help!

  • This board would be amazing if the PWM outputs from the Atmega were broken out to a header. That way you could use it as the brain for a drone or other vehicle.

  • Hey Everyone, Does anyone know if there is a simple way to have this device automatically account for a non-level startup. IE if the board is started at a 45 degree angle (in my experiance) it assumes that 45 degrees is the zero point, I need the board to account and correct for this. Any ideas?

  • I had prove the version v22 of a1ronzo’s code and i still have the problem with the magnetometer. I had checked line by line that the code in my imu is the last hex code uploaded by a1ronzo. To anyone, the last code has the correct order of magnetometer’s data?

    • v22 of the code fixed the magnetometer output. If you are still having issues, please contact techsupport at sparkfun dot com.

  • Has anyone had the opportunity to test the newly uploaded AHRS code? I modified some of the old code but could not get the yaw to function properly. Curious if the updated code fixes that issue completely.

    I’m really hoping Sparkfun pulled through on this one. This board has really good potential.

  • In a future version of this board, can you please expose the SS pin with a through-hole connector? Allowing this device to be an SPI slave opens up a ton of possibilities for interfacing with UART-starved systems.

    • I agree, and would go so far as to say that spinning an SPI version of this board would be really helpful, with different SPI compatible sensor chips of course. i2c is so dreadfully slow because of the addressing overhead on the bus.

      I’d like to see a new incarnation starting with a full fledged atmega32u4 breakout board with USB connector, then making it bigger to accommodate the sensors, hooking em in via SPI. Since all the other pins are broken out, the buyer gets the value of the tightly packed sensors and CPU, but all the access he needs to add on other controls or interfaces like GPS, servo control, etc. SPI for speed, the rest for accessibility. Shucks, that sounds so good, I’d do it myself if I had the equipment.

  • Hi,

    Great to see that the new AHRS has been updated for the new board. It looks like Sparkfun is now contributing some of the proceeds to Jordi Munoz, who created the AHRS code. This seems like a very fair outcome seeing as though the board is effectively useless without the right code.

    In the AHRS code it appears as though there is a small error. The gyro x & y have been swapped around. This is very easy to fix though, I have included the necessary change below, but I think it should be updated on the code so that others don’t have this problem.

    Cheers,

    Mike

    Code fix ***Swap around gryo x & y values

    GYRO[1] = ((((int)buff[0]) 
    
  • I’ve been wanting one of these for years. Finally i bit the bullet and got one, why not its a tiny box of data awesomeness!

    I’m developing a 3d Device driver for the 9dof to be used by… anyone. I see the need for 3d positioning with direction for the newest technologies. Augmented reality, better game controllers, imaging.

    A demo of my first application is on youtube,

    http://www.youtube.com/watch?v=QeNRoTkqH04&feature=youtu.be

    Thanks, -C

  • Hi everyone

    I have purchased this board and planned to modify the AHRS code.I downloaded the latest code and modified it.In the beginning,it programmed and i was able to use it.But now ,the same code on the same board shows an error while compiling in arduino 0023. the problem is it says the roll is not defined.

    Can someone please help me?

    • How would this board behave for a balancing robot application?? And how is its noise sensivity towards motor vibration??

      Regards

      Petar

  • The “AHRS/Head-tracker Tutorial” is great! Anyone using this board should work through this tutorial.

  • Hi everyone, I have some doubt about firmware code existing in my razor. Firmware version seems to be V22, but if I look into the code given in http://github.com/a1ronzo/SparkFun-9DOF-Razor-IMU-Test-Firmware the gyros are supposed to return an unsigned int on 16bit as shown by the prototype of function: uint16_t x_gyro(void). But the firmware returns numbers that are signed.

    How could it be explained?

  • Hey, we were able to connect 9DOF razor IMU to the computer through Arduino UNO, without the FTDI breakout board. For all those who may want to see the connections, we followed the connections in this website: http://blog.mobileapes.com/2010/09/read-data-from-9dof-razor-imu-via.html. You can also read the instructions here: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1270577613/10#10. Make sure that the wiring is not loose and you have “No Line Ending” option selected in the serial monitor. In case you are having gibberish on the monitor, try changing the baud rate.

    We now are trying to upload AHRS code from pc to 9dof through arduino, but do not really know how to do it. Can anyone please help us out on that? Also, in the future we would want to communicate the data from 9dof to Arduino Uno. Does anyone know how to do that? We will really appreciate your help!

    • While you can easily pass serial data through an Arduino, I know of no simple way to upload code through an Arduino. The reason is that one of the signals the FTDI provides is a reset signal (on the DTR line); this signal initiates the reprogramming process, and the first Arduino in the chain would be reset and reprogrammed when it sees that signal.

      The easiest way to reprogram the Razor is to connect it by itself to a FTDI board. Once it’s reprogrammed, you can disconnect the FTDI and reconnect the Arduino.

      To have the Arduino receive and act on the data coming from the Razor, you’ll need to write a sketch to grab the data from the serial port and interpret it as required. This shouldn’t be hard, see the serial reference of the Arduino site for commands and example code.

  • hi, I am principiant about arduino but i am working with razor 10125 (adxl345, itg-3200 and hmc5843). I need help with code Jordi Muñoz from SENSOR_SIGN[9] = {-1,-1,-1,1,1,1,-1,-1,-1} i don’t understand this reference. Adxl345 corresponding with print axis board (razor) and his datasheet. Why itg-3200 is -1 his orientation is the same that razor board, hmc too is -1??? I’m working with body coordenates thanks

  • Hi

    I have just received this board, and the stock software is not optimal for my use as i only need the gyro x and acc x output. So I have tried to use the firmware code which is available at this site but it does not compile in the arduino environment. So I have tried the ARHS code instead as it is .pde, but what is the main file?? and does this code work as it is??

    Regards

    Petar Durdevic