MPU-9150 Nine-Axis (Gyro + Accelerometer + Compass)

How long until the next Raven and other devices include this little baby?


URL: https://www.digikey.com/product-hig...-9150/3809?WT.z_sm_link=fb_invensense_pm_0725

MPU-9150 Nine-Axis (Gyro + Accelerometer + Compass) MEMS MotionTracking™ Device
The world’s first 9-axis MotionTracking device designed for the low-power, low-cost, and high-performance requirements of consumer electronics equipment

InvenSense's MPU-9150™InvenSense's MPU-9150™ is the world’s first 9-axis MotionTracking device designed for the low-power, low-cost, and high-performance requirements of consumer electronics equipment including smartphones, tablets, and wearable sensors.

The MPU-9150 incorporates InvenSense’s MotionFusion™ and run-time calibration firmware that enables manufacturers to eliminate the costly and complex selection, qualification, and system level integration of discrete devices in motion-enabled products, and guarantees that sensor fusion algorithms and calibration procedures deliver optimal performance for consumers.

Motion interface is rapidly becoming a key function in many consumer electronics devices including smartphones, tablets, gaming consoles, and Smart-TVs, as it provides an intuitive way for consumers to interact with electronic devices by tracking motion in free space and delivering these motions as input commands.

The MPU-9150 with MotionFusion and run-time calibration firmware enables consumer electronics manufacturers to rapidly commercialize cost-effective motion-based functionality.

The MPU-9150 is a System in Package (SiP) that combines two chips: the MPU-6050, which contains a 3-axis gyroscope, 3-axis accelerometer, as well as an onboard Digital Motion Processor™ (DMP™) capable of processing complex 9-axis MotionFusion algorithms; and the AK8975, a 3-axis digital compass. The part’s integrated 9-axis MotionFusion algorithms access all internal sensors to gather a full set of sensor data. The part is offered in a 4 x 4 x 1 mm LGA package and is upgrade-compatible with the MPU-6050™ integrated 6-axis MotionTracking device, providing a simple upgrade path and making it easy to fit on space constrained boards.

The InvenSense MotionApps™ Platform that comes with the MPU-9150 abstracts motion-based complexities, offloads sensor management from the operating system and provides a structured set of APIs for application development.

Features

Digital-output 9-axis MotionFusion data in rotation matrix, quaternion, Euler Angle, or raw data format
Tri-Axis angular rate sensor (gyro) with a sensitivity up to 131 LSBs/dps and a full-scale range of ±250, ±500, ±1000, and ±2000dps
Tri-Axis accelerometer with a programmable full scale range of ±2g, ±4g, ±8g and ±16g
Tri-axis compass with a full scale range of ±1200 µT
Reduced settling effects and sensor drift by elimination of board-level cross-axis alignment errors between accelerometer, gyroscope, and compass
Digital Motion Processing™ (DMP™) engine offloads complex MotionFusion, sensor timing synchronization, and gesture detection
MotionApps™ Platform support for Android, Linux, and Windows
Embedded algorithms for run-time bias and compass calibration. No user intervention required
Digital-output temperature sensor
Digital input on FSYNC pin to support video Electronic Image Stabilization and GPS
RoHS and Green compliant



Programmable interrupt supports gesture recognition, panning, zooming, scrolling, free fall interrupt, high-G interrupt, zero-motion detection, tap detection, and shake detection
VDD Supply voltage range of 2.4 V–3.46 V; VLOGIC of 1.8 V±5% or VDD
Gyro operating current: 3.6 mA (full power, gyro at
all rates)
Gyro + Accel operating current: 3.8mA (full power, gyro at all rates, accel at 1 kHz sample rate)
Gyro + Accel + Compass + DMP operating current: 4.25 mA (full power, gyro at all rates, accel at 1 kHz sample rate, compass at 8 Hz rate)
Accel low power mode operating current: 10 uA at 1 Hz, 20 uA at 5 Hz, 70 uA at 20 Hz, 140 uA at 40 Hz
Full Chip Idle Mode Supply Current: 8 µA
400 kHz Fast Mode I²C serial host interface
On-chip timing generator with ±1% frequency variation over full temperature range
User self test
10,000g shock tolerant
Smallest and thinnest package for portable devices
(4 x 4 x 1.06 mm)

the 16g max is kind of low.

One word. AWESOME! This is a revolutionary 4 mm x4 mm x1 mm chip. 1 @ $12.70 each, 750 @ $6.47 each...... 16 G sensor in the z direction can be supplemented by a less sensitive accelerometer chip, and it can be coupled to a barometer and a GPS.

SparkFun has them on a breakout board https://www.sparkfun.com/products/11486 for $50.

I agree 16G is low, but still pretty impressive.

For sure this part, and other similar parts, are going to be working their way into flight controllers in the next few years. You'll still need a baro sensor, Meas Spec has just released an update to the venerable MS5607/5611 (the MS5637) that is only 3mm square, and only uses four pads. It's cheaper than the previous sensors too. The high-G accelerometer sensor is still an issue... there really isn't a good 3.3v part that is readily available yet.

Couple this chip with a 32-bit MCU with built-in support for wireless (Bluetooth communication to the PC/smartphone for wireless programming), and you've got a really powerful platform. A bit of overkill for simple dual-deploy, however...

st has one that looks interesting:

https://www.st.com/web/catalog/sense_power/FM89/SC444/PF253712

analog has one too, but it has analog outputs:

https://www.analog.com/en/mems-sensors/mems-accelerometers/adxl377/products/product.html

The ST part has been kicking around for about a year, but there's no availability yet. Seems the semi manufacturers all announce products about a year before you can actually get them, unless you're Apple or somebody like that. "Call for availability" means that a major consumer manufacturer has allocated all of the initial supply and you're gonna have to wait for another production run.

The ADXL377 is available, it's $8-$10 in medium quantities. Although it is analog, it will work on a 3.3v power supply, and it's ratiometric so as long as you have a stable power supply it doesn't matter what voltage you run it at. The previous AD chips ran at 5V (i.e. ADXL78/278, which are used in a number of flight computers) which made it somewhat more difficult to implement if you had other parts that ran at 3.3v. I know for fact, however, that the ADXL78 runs just fine on a 3.7v LiPo...

Derek said:

st has one that looks interesting:

https://www.st.com/web/catalog/sense_power/FM89/SC444/PF253712

analog has one too, but it has analog outputs:

https://www.analog.com/en/mems-sensors/mems-accelerometers/adxl377/products/product.html

Click to expand...

you're right, the st part doesn't seem to be available.

I think the real problem is companies like apple don't have a need to 100+ g parts. if they did, it would be available.

cerving said:

For sure this part, and other similar parts, are going to be working their way into flight controllers in the next few years. You'll still need a baro sensor, Meas Spec has just released an update to the venerable MS5607/5611 (the MS5637) that is only 3mm square, and only uses four pads. It's cheaper than the previous sensors too. The high-G accelerometer sensor is still an issue... there really isn't a good 3.3v part that is readily available yet.

Couple this chip with a 32-bit MCU with built-in support for wireless (Bluetooth communication to the PC/smartphone for wireless programming), and you've got a really powerful platform. A bit of overkill for simple dual-deploy, however...

Click to expand...

While the Meas Spec unit is a fine barometer, it craps out at 30 KFT so it isn't for a high end altimeter. The $39 PerfectFlite Affordable Precision Rocket Altimeter uses a barometer that is accurate to 100 KFT so there's accurate inexpensive rocketry barometers out there. I haven't conducted an exhaustive search fro 3.3 volt digital accelerometers but Analog Devices sells the ADXL180 iMEMS® accelerometer as a configurable, single axis, integrated satellite sensor that enables low cost solutions for front and side impact airbag applications. It is designed for automotive use so you would need a 5 volt supply and perhaps an I2C bus converter but it's certainly up to the boost phase task, so a z-axis sensor fusion is feasible.

That's funny, I've been pointing that out for some time but the vendors that use the MS56xx's swear that they're good to 100K'. My contention is that none of the integrated baro chips are certified by their vendors for accuracy over 30K', so if you want to fly high then you need an altimeter with a separate sensor and 24-bit ADC... like the G-Wiz. They need to be externally calibrated, which is a pain in the butt and which is why almost everybody has gone to the integrated sensors, which are factory calibrated.

bobkrech said:

While the Meas Spec unit is a fine barometer, it craps out at 30 KFT so it isn't for a high end altimeter. The $39 PerfectFlite Affordable Precision Rocket Altimeter uses a barometer that is accurate to 100 KFT so there's accurate inexpensive rocketry barometers out there. I haven't conducted an exhaustive search fro 3.3 volt digital accelerometers but Analog Devices sells the ADXL180 iMEMS® accelerometer as a configurable, single axis, integrated satellite sensor that enables low cost solutions for front and side impact airbag applications. It is designed for automotive use so you would need a 5 volt supply and perhaps an I2C bus converter but it's certainly up to the boost phase task, so a z-axis sensor fusion is feasible.

Click to expand...

P.S. The APRA uses a Meas Spec MS5607...

If Adrian could implement this into a Raven, I would buy one without hesitation.

I am excited to see Adrian's response.

There are some 9 axis sensor boards integrated with Arduino based autopilots for R/C aircraft. Definitely interesting stuff.

It's all about the software. The hardware is pretty much cut and dried... you can almost clone the manufacturer's app notes to design the flight computer, you just connect the sensors, add some memory, and some kind of high-current deployment drivers. Adrian has a really nice interface on the Raven, extending it to a 9 DoF IMU may be trivial, or it may be very difficult... it's one of those things that you can't tell until you actually try it.

BLKKROW said:

If Adrian could implement this into a Raven, I would buy one without hesitation.

I am excited to see Adrian's response.

Click to expand...

That's a pretty nice IMU.

Might have to incorporate that into the next revision of my shield, since it'll reduce circuitry complexity...

Currently I have a 16G 3-axis accel/magnometer paired with a 2-axis 55G accel. Next rev I'm replacing that 55G accel with the ADXL377 mentioned above. Switching to something like this would remove the separated gyro + 16g accel/magnometer. I've been using the BMP085 altimeter, since it seems to be a popular high altitude, high accuracy choice.

I'll get one ordered and try to play with it...

cerving said:

That's funny, I've been pointing that out for some time but the vendors that use the MS56xx's swear that they're good to 100K'. My contention is that none of the integrated baro chips are certified by their vendors for accuracy over 30K', so if you want to fly high then you need an altimeter with a separate sensor and 24-bit ADC... like the G-Wiz. They need to be externally calibrated, which is a pain in the butt and which is why almost everybody has gone to the integrated sensors, which are factory calibrated.

Click to expand...

Ignorance by the manufacturer and sales folks are most likely the reason for a lot of the issues. The MS5561C Micro Altimeter Sensor will work to vacuum but this fact is not publicized on their webpages but if go to the linked datasheet you will see that it can be done. I suspect that many of the new digital sensor will work at higher than specified if you reprogram the conversion constants. It appears that 300 mb - 1100 mb is a standard simply because you can't go higher than Mount Everest with a barometer. Going back to the original MEMS sensor elements of the 70's the sensing elements were to about 100-130 kft. (11 mb - 3 mb) however the amplified sensors didn't go that high because they weren't specified there, and the electronic amplifier design was not very good. I'll speculate that most of the newer digital sensors can be reprogrammed to 100 kft, and do so without recalibration. My guess as to why the manufacturer's don't do this as an option, is that the pressure values have some errors and when converted to altitude would have very large uncertainties and it wouldn't look good. Problem is that the physics. The TRA altitude records require a GPS above 30 kft. The number is not arbitrary because that's the altitude where the GPS altitude has equal accuracy under worst conditions to the barometric altitude. Below 30 kft, a properly calibrated barometric altimeter is on paper more accurate than GPS under the worst conditions. I looked into FAA altimeter calibration accuracies and posted it on TRF some time ago but I don't remember where or when.

bobkrech said:

One word. AWESOME! This is a revolutionary 4 mm x4 mm x1 mm chip. 1 @ $12.70 each, 750 @ $6.47 each...... 16 G sensor in the z direction can be supplemented by a less sensitive accelerometer chip, and it can be coupled to a barometer and a GPS.

Click to expand...

Have to agree with Bob.
Amazing little bugger, we have the SparkFun breakouts and use them for Golf car testing, if it wasn't for the 16G max limit it would be in a rocket already.

Bob: I agree with you in that the manufacturers may simply not test them at lower pressures than they expect them to be used. A pizo sensor element is going to keep moving well past its rated pressure unless there is some physical "stop" or it breaks, and as long as the ADC can handle it you'll probably get a usable reading. That's probably why Meas Spec gives both the "operating range" (the calibrated readings that they guarantee based on their statistical sampling) and the ADC range (what the 24-bit ADC can handle). You can probably empirically extrapolate the range up to the limit of the ADC, giving up some accuracy (say, 100 ft instead of 10 ft up to 100K'). BTW, the MS5561 only has a 16-bit DAC, so it probably would not be a good choice for a high-altitude rated altimeter.

I'm guessing that at some point, NAR and TRA are going to realize that very high altitude flights do not lend themselves well to baro altitude determination, that inertial and GPS together in a Kalman filter are the best solution. The Carmack prize required GPS verification.

bobkrech said:

Ignorance by the manufacturer and sales folks are most likely the reason for a lot of the issues. The MS5561C Micro Altimeter Sensor will work to vacuum but this fact is not publicized on their webpages but if go to the linked datasheet you will see that it can be done. I suspect that many of the new digital sensor will work at higher than specified if you reprogram the conversion constants. It appears that 300 mb - 1100 mb is a standard simply because you can't go higher than Mount Everest with a barometer. Going back to the original MEMS sensor elements of the 70's the sensing elements were to about 100-130 kft. (11 mb - 3 mb) however the amplified sensors didn't go that high because they weren't specified there, and the electronic amplifier design was not very good. I'll speculate that most of the newer digital sensors can be reprogrammed to 100 kft, and do so without recalibration. My guess as to why the manufacturer's don't do this as an option, is that the pressure values have some errors and when converted to altitude would have very large uncertainties and it wouldn't look good. Problem is that the physics. The TRA altitude records require a GPS above 30 kft. The number is not arbitrary because that's the altitude where the GPS altitude has equal accuracy under worst conditions to the barometric altitude. Below 30 kft, a properly calibrated barometric altimeter is on paper more accurate than GPS under the worst conditions. I looked into FAA altimeter calibration accuracies and posted it on TRF some time ago but I don't remember where or when.

Click to expand...

cerving said:

Meas Spec has just released an update to the venerable MS5607/5611 (the MS5637) that is only 3mm square, and only uses four pads. It's cheaper than the previous sensors too.

Click to expand...

Yeah, but i2c only, which is definitely not my favorite serial interface. It's also slightly less precise (larger error band) than the MS5607. Interesting option for products that can tolerate an I2C interface though.

cerving said:

The high-G accelerometer sensor is still an issue... there really isn't a good 3.3v part that is readily available yet.

Click to expand...

Yeah, the MMA6556 is pretty much what you want, just not available.

cerving said:

Couple this chip with a 32-bit MCU with built-in support for wireless (Bluetooth communication to the PC/smartphone for wireless programming), and you've got a really powerful platform. A bit of overkill for simple dual-deploy, however...

Click to expand...

We like to use one radio at 70cm for both telemetry and over-the-air programming, and then convert that to bluetooth or USB on the ground. Flying fewer radios always seems like a good idea to me. For 32-bit MCUs, we're using both the STM32L series (Cortex M3) and the LPC11U14 (Cortex M0) as appropriate. These both have native USB support, which means you get on the ground configuration and battery charging without needing to get any radios working.

Having a radio definitely isn't "overkill" though -- anyone flying high or small needs tracking of some kind, and having real telemetry in addition to basic tracking data doesn't cost much while providing so much more information (battery voltages, igniter continuity, flight computer status, etc).

And, a 32-bit MCU isn't much more expensive than an 8-bit one. We're getting the LPC11U14 for about $1.48 in modest quantity, in a 5mm x 5mm package. Cheaper than an atmega 328p.

cerving said:

Bob: I agree with you in that the manufacturers may simply not test them at lower pressures than they expect them to be used. A pizo sensor element is going to keep moving well past its rated pressure unless there is some physical "stop" or it breaks, and as long as the ADC can handle it you'll probably get a usable reading. That's probably why Meas Spec gives both the "operating range" (the calibrated readings that they guarantee based on their statistical sampling) and the ADC range (what the 24-bit ADC can handle). You can probably empirically extrapolate the range up to the limit of the ADC, giving up some accuracy (say, 100 ft instead of 10 ft up to 100K'). BTW, the MS5561 only has a 16-bit DAC, so it probably would not be a good choice for a high-altitude rated altimeter.

I'm guessing that at some point, NAR and TRA are going to realize that very high altitude flights do not lend themselves well to baro altitude determination, that inertial and GPS together in a Kalman filter are the best solution. The Carmack prize required GPS verification.

Click to expand...

You can measure pressure with 24-bit precision and be fairly accurately (0.01 - 0.1%) with a MEMS pressure sensor, but you have to convert it to altitude and that process is not so accurate or precise. It is not possible with consumer GPS or with a superbly accurate pressure transducer to measure altitude to 10' accuracy at 30 kft or 100 kft. The consumer GPS altitude calculation and be off by hundreds of feet. A 300' error at 30 kft is a 1% error. And a barometric altimeter can easily be of by that amount or greater at high altitude. Here are the FAA Part 43 Appendix C altimeter requirements. +/- 180' scale error at 30 kft is permissible with an FAA certified aneroid altimeter, and 140' in friction error which is a 1% error and that doesn't cover even more permissible altitude error if the sea level pressure is different than 29.92". The best altitude information is obtained by a radar altimeter, but this is not practical in a rocket. TRA at present has HP altitude record rules that specify that a TRA supplied altimeter must be used for flights to 30 kft, and a (TRA approved?) GPS must be used for flights over 30 kft.

keithp said:

.....We like to use one radio at 70cm for both telemetry and over-the-air programming, and then convert that to bluetooth or USB on the ground. Flying fewer radios always seems like a good idea to me. For 32-bit MCUs, we're using both the STM32L series (Cortex M3) and the LPC11U14 (Cortex M0) as appropriate. These both have native USB support, which means you get on the ground configuration and battery charging without needing to get any radios working.

Having a radio definitely isn't "overkill" though -- anyone flying high or small needs tracking of some kind, and having real telemetry in addition to basic tracking data doesn't cost much while providing so much more information (battery voltages, igniter continuity, flight computer status, etc).

And, a 32-bit MCU isn't much more expensive than an 8-bit one. We're getting the LPC11U14 for about $1.48 in modest quantity, in a 5mm x 5mm package. Cheaper than an atmega 328p.

Click to expand...

Yes, you need a real radio, not Bluetooth, to get data downlinked from a rocket. It may not seem right to use a 32 bit MPU to flash a few LEDs but we also determined that a 32-bit MCU costs less than a dollar more than an 8-bit MPU and if you already have the development system and coding down, it's actually cheaper since you don't have to learn how to program another MPU.

bobkrech said:

You can measure pressure with 24-bit precision and be fairly accurately (0.01 - 0.1%) with a MEMS pressure sensor, but you have to convert it to altitude and that process is not so accurate or precise. It is not possible with consumer GPS or with a superbly accurate pressure transducer to measure altitude to 10' accuracy at 30 kft or 100 kft. The consumer GPS altitude calculation and be off by hundreds of feet. A 300' error at 30 kft is a 1% error. And a barometric altimeter can easily be of by that amount or greater at high altitude. Here are the FAA Part 43 Appendix C altimeter requirements. +/- 180' scale error at 30 kft is permissible with an FAA certified aneroid altimeter, and 140' in friction error which is a 1% error and that doesn't cover even more permissible altitude error if the sea level pressure is different than 29.92". The best altitude information is obtained by a radar altimeter, but this is not practical in a rocket. TRA at present has HP altitude record rules that specify that a TRA supplied altimeter must be used for flights to 30 kft, and a (TRA approved?) GPS must be used for flights over 30 kft.

Click to expand...

Are aircraft GPS any more accurate than a WAAS enabled consumer GPS? The reason I ask is because with new RNP-0.1 LPV RNAV approaches, aircraft are using GPS generated glide-slopes to minimums that are approaching CAT I ILS minimums, so I'd imagine those GPS systems would have vertical accuracy similar to a traditional ILS glide-slope system.

You are correct. Meas spec does not spec accuracy above 30Kft equivalent atmospheric pressure.

However I agree with Bob that the pressure accuracy is probably still very good and probably significantly LESS than the variance of the standard atmospheric model to the real atmosphere of the flight.

Exactly what is the utility of a 9DOF Imu in a rocket altimeter other than hitting a target in X,Y,Z space?

That's probably true, but I have not heard of anybody testing any of the integrated baro sensors against a known standard above 30K'. It would be an interesting project. I have flown both the Bosch and MS sensors simultaneously, albeit only to about 2000', and they agreed very closely. Above 30K', I'd give the nod to the MS with its higher ADC precision (24 bit vs 19 bit).

Re: 8 bit vs 32 bit MCU's, I'm with Keith... anything relatively complex screams 32 bits. I'm just about pushing the envelope of what at ATMega328 can do in the Eggtimer, so I'm not surprised that most of the new devices are 32 bit. It's difficult and slow to do much math (i.e. Kalman filtering) with an 8-bit processor, it can be done of course, but it uses a lot of extra cycles and wastes a lot of memory. The 8 bit MCU's just don't have the memory capacity. They're fine in a relatively simple dual-deploy/recording application, but once you get into 9 DoF, all bets are off.

jderimig said:

You are correct. Meas spec does not spec accuracy above 30Kft equivalent atmospheric pressure.

However I agree with Bob that the pressure accuracy is probably still very good and probably significantly LESS than the variance of the standard atmospheric model to the real atmosphere of the flight.

Click to expand...

Bob: I was referring to using Bluetooth to PROGRAM the computer, so you don't need a cable. Of course, you can't use it for a downlink... in fact, I heard that a lot of people have had trouble with the range on some of the 2.4GHz radios, it's an extremely congested band nowadays. 70 cm is the way to go... Ham technician licenses are easy to get and cheap.

bobkrech said:

Yes, you need a real radio, not Bluetooth, to get data downlinked from a rocket. It may not seem right to use a 32 bit MPU to flash a few LEDs but we also determined that a 32-bit MCU costs less than a dollar more than an 8-bit MPU and if you already have the development system and coding down, it's actually cheaper since you don't have to learn how to program another MPU.

Click to expand...

cerving said:

Bob: I was referring to using Bluetooth to PROGRAM the computer, so you don't need a cable. Of course, you can't use it for a downlink... in fact, I heard that a lot of people have had trouble with the range on some of the 2.4GHz radios, it's an extremely congested band nowadays. 70 cm is the way to go... Ham technician licenses are easy to get and cheap.

Click to expand...

I didn't phrase it right. I agree with you 100%.

jderimig said:

Exactly what is the utility of a 9DOF Imu in a rocket altimeter other than hitting a target in X,Y,Z space?

Click to expand...

If you are lunching a large Class 2 or a Class 3 rocket, you most likely want to track your trajectory. If the GPS looses lock or fails, the IMU will still accurately know where the rocket it. Additionally if the rocket is multistage, a decision can be made not to fire the next stage if the rocket angle is improper,

COrocket said:

Are aircraft GPS any more accurate than a WAAS enabled consumer GPS? The reason I ask is because with new RNP-0.1 LPV RNAV approaches, aircraft are using GPS generated glide-slopes to minimums that are approaching CAT I ILS minimums, so I'd imagine those GPS systems would have vertical accuracy similar to a traditional ILS glide-slope system.

Click to expand...

Usually GPS with WAAS is quite accurate in LAT-LON however the altitude accuracy is dependent on having 1 or more satellites overhead which is less probable than having them near the horizon. In general the altitude is known about 50% ore more less accurately than the LAT-LON, but most of the time its still quite accurate but errors of 50' to 100' can occur. Take your GPS or smart phone outside and turning it on in the LAT-LON-ALT mode and look at the altitude. It will change a lot more than the LAT-LON.