Why are the magnetic and accel/gyro sets of axis references not in sync? Is this intentional (or typical)? I guess SW can "fix" that without a problem.

How does this compare to the SparkFun 9DoF IMU Breakout - LSM9DS1 (part SEN-13284)?

The Sparkfun example code MPU9250BasicAHRS_I2C does not work out of the box, because the I2C address is incorrect. Fix that, and also enable the magnetometer calibration.

See also the major bug that produces nonsensical yaw, pitch and roll angles, reported in a separate comment below.

The Sparkfun code MPU9250BasicAHRS_I2C has a serious bug that makes the yaw, pitch and roll angles nonsense. The bug is also in Kris Winer's original BasicAHRS code for Arduino/MPU-9250. The magnetometer coordinate system as defined is left handed and has NEVER worked properly. See issue #368 on Kris Winer's Github page.

A simple fix to the code is to invert the sign of mz, AS SHOWN IN THE FOLLOWING, CORRECTED LINE:

MahonyQuaternionUpdate(myIMU.ax, myIMU.ay, myIMU.az, myIMU.gx * DEG_TO_RAD, myIMU.gy * DEG_TO_RAD, myIMU.gz * DEG_TO_RAD, myIMU.my, myIMU.mx, -myIMU.mz, myIMU.deltat);

Of course, if the magnetometer is not properly calibrated, the orientation angles will also be nonsense, so activate the built in calibration procedure, and make sure that all possible magnetometer orientations are sampled reasonably well in the 15 seconds you are given.

With the above fix, and the magnetometer properly calibrated, yaw = 0 corresponds to the acelerometer/gyro X axis pointing toward magnetic North, Yaw increases as the X-axis sweeps toward West (unlike a magnetic compass). See the comments in the code to interpret the meaning and signs of the other angles.

My sensor works only when provided with 5V (simplest setup I2C). Every information that I found says that proper voltage is 3.3V, not 5V. When powered with 3.3V nothing happens. No sensor response. Can anybody explain this to me?

I am working on a device that has a base and inside has a part that rotates. the part is small and therefore can be placed/moved in any direction. Inside the base, I have a part that moves laterally with respect to the base. I want to know the position of the moving part, with respect to the base. The simpler solution is to put physical limit switches for me to know when the part is in certain locations but I want to know the location at all times.

Will putting two of these modules (one on the base and the other on the moving part), and using all 9 readings, work in determining the lateral location of the moving part?

for example, if the part is at a 30 degree angle from the base, and the base is flat on the surface, I will get the 30 degree reading. But I want to get the same 30 degree reading if the whole part is at a different pitch and yaw. I think this should be possible, I just want to ask before I go ahead and buy two of these

This sensor will not give you great heading accuracy without proper calibration. You need to remove the biases on the x,y,z planes for both the magnetometer, gyro and the accelerometer to get headings that make sense. On top of that, the board layout will affect the measured magnetic field causing the response surface for the magnetometer x,y,z to be non-spherical. You need to apply a vector transform to compensate. You can use a program called "Magneto v1.2" to determine both the biases and the transform that needs to be applied based on samples taken as you rotate the board around all axis. Once you do all that, you can get +/- 4-5 degrees heading accuracy when using Mahony/Madgwick sensor fusion algorithms. The MPU9250 is now officially end-of-life (EOL) by Invensens/TDK. Although the TDK ICM-20948 is supposed to be a replacement (and pin compatible) it operates the I2C at a maximum of 1.8v.

The Sparkfun Arduino library example code is misleading. It leads one to think that changing the code to include a local adjustment for magnetic variation will get a valid yaw output that can be used to obtain heading data. Not so. The code contains bias values for the magnetometer that are unique to the MPU-9250 that was used to develop the library. These bias values will not be your required bias values to obtain useful heading data from the MPU-9250. Without these bias values, the library example AHRS code can be expected to output valid pitch and roll info, but wildly inaccurate (unusable) yaw info.

I am using this part with a 5v pro mini. I compiled the example code MPU9250BasicAHRS that was included with the library which I installed with the arduino library manager.

The code is connecting to the MPU9250, displaying reasonable data for pitch and roll, but yaw, not so much.

I applied the correct magnetic variation for my location, but note the following:

When the x axis of the accelerometer is aligned with true north, the yaw output is around 35 degrees, east gives values around -159, south shows 135, west 84. This does not make sense. The Yaw is changing in the wrong direction when rotated from north to east.

I know the magnetic sensor coordinate axes are not the same as the accel axes, but it is not clear if the example code is intended to correct for this before displaying yaw, pitch, and roll amounts.

Has this code been verified to output sane results, and if so how exactly is the part oriented physically when oriented towards true north?

I've been trying to get accurate yaw data for 2 days straight ad I have no idea what is wrong. I don't know here to start. I'm using sparkfun's library and the yaw data is constantly shifting all over the place and has never once pointed me towards north. Also the yaw sporadically jumps when I go past (what should be) 90 degrees. There seems to be absolutely no correlation between how far I turn it and the yaw. I'm going insane trying to figure this out and it doesn't help that I have no understanding of quaternion filters and all the crazy math going on.

Is an interrupt pin required? The sample code defined an intPin but didn't really use it. I couldn't find anywhere in the library code that uses interrupt either.

I have a question regarding the yaw angle. According to wikipedia, turning the nose to the right is positive yaw. According to the sparkfun tutorial, this seems to be the opposite. The mag. declination angle (east of true north being positive) is subtracted from myIMU.yaw (line 391). This means that if your device points 8.5 degrees east of true north, your magnetometer will show zero and you end up getting -8.5 degrees after the subtraction. Can someone explain the difference? Thanks.

https://en.wikipedia.org/wiki/Aircraft_principal_axes https://learn.sparkfun.com/tutorials/mpu-9250-hookup-guide?_ga=2.41541028.747198559.1526401852-836860115.1440527768

What is the sampling frequency of this sensor?

https://www.youtube.com/watch?v=6ijArKE8vKU

Can i do 3d tracking like above with this sensor?

If yes means Please help me to do this?

Thanks in advance

Pardon my noobness but does this also include a compass so I can get data on the orientation of the device? I plan to use this in an obstacle avoiding drone and want to make sure that the sensor to detect the obstacles is always pointed in the direction of movement.

I am trying to change the address of the chip in the firmware, but can't seem to find where SparkFun defines "slave_addr". Has anyone been able to do this?

***UPDATE: I found where the register address is defined. It's hard-coded into a struct. Navigate to the inv_mpu.c file. Go to "const struct hw_s hw = {", line 435 in my version of the code and "const struct hw_s hw = {", line 516 of the code. The register address is stored in variable ".addr". Not sure why the original author of the library decided to hard-code this value in vs. allow the user to pass the address as a parameter (had a good reason I guess--maybe easier to manage?? -- would someone care to comment?), but that seems to be the case. Hope this helps someone else.

What are the dimensions of this item?

I see that in data sheet Figure 4 and 5, the axes are diagrammed. It appears that the axes are exactly on top of each other. Is this true, or is there slight angle deviations between axes? That is, is the X axis of accelerometer a certain angle theta off from the X axis of gyroscope? Is the X axis of accelerometer a certain angle phi off from the Y axis of the compass? If so, can this information be found anywhere? I want to know the exact theta and phi for a given IMU.

Thanks!

Was reading some additional documentation on this chip (found using this search: AN-IVS-0002A-00) as well as reading though Kris Winer's various Q&A. It says the exposed die pad should NOT be soldered to the PCB. Kris refers to this as a big no-no. Is there something I'm missing here, because it looks like your breakout does put paste there for soldering (as well as running traces beneath the device, which also is discouraged)? I am asking because I bought a couple of these and I am having a very hard time calibrating them (wondering if this could be at least part of the issue).

Does this board also have a dmp ?

What is the best/right logic level converter to connect the IMU to a UNO? :)

I hooked up the MPU-9250 SPI pins to a Teensy 3.2, but the WHO-AM-I register is incorrectly returning zero. Does the breakout board need any special treatment, like desoldering one of the jumpers or anything else?

I prefer SPI because my robot needs a 3 foot CAT-5 cable to the IMU and SPI is less susceptible to noise and it's way faster than I2C. I've done SPI for the LSM6DS3 IMU, but now I need magnetometers too.

I would like to know about the sensors' uniformity. In other words, if I use 2 of these sensors to measure the same movement, how different will the 2 measurements be, compared to each other?

I want to measure very small changes in a objects position. tip/tilt. direction etc. But I'm looking at fractions of a degree not large changes for example.
is one of these appropriate for that type of measurement.? what would be a better choice if not?

Oh and it would be placed on a large aluminum plate. would that cause interference of any kind

Are those tattoos for real?

You misspelled "Gyro" on the silkscreen...