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

[jderimig]

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,

Bob,

The latter can be done very effectively with just a simple 3-axis gyro with no need for magnetic drift correction. (I have the prototype to prove it).

The former is an interesting concept thought.

 

[jderimig]

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.

I am moving to ARM in my next altimeter platform. I lament the relatively easy programming of the 8-bit mcus and they will still be ideal if you want to get some very simple functionality developed very quickly.

(Good) ARMS are cheap, little more difficult to learn and relatively inefficient with program memory unless you are using expensive development tools (IAR, Keil etc). I have a MARSA ARM prototype incorporating an IMU and was able to get all the processing in about 12K of code. Will fly it in the fall and hope to make it available soon after.

Better platforms include MACs (multiply accumulator) which moves more of the matrix multiplies operations to hardware. The upcoming Freescale FXLC95000CL is an example of a microcontroller specifically designed for sensor fusion applications. I can't wait to play with one.

Most people don't realize that they already have a 6 - 9 DOF IMU already. If you want to play with yours and learn about sensor fusion here's a link to an app that will unlock that world for you.

https://www.freescale.com/webapp/sps/site/overview.jsp?code=XTRSICSNSTLBOX

 

[CF-105]

Would a flight computer using such a board be restricted by ITAR?

 

[Adrian A]

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.

The MS5540 digital-output sensor used in the original Raven and Raven2 has been flight-proven to provide valid, accurate data over 100,000 feet. (See the Carmack-winning Aeropac flight that had baro altitude from the Raven virtually identical to GPS). By "virtually identical" I mean altitude error around 1% of the GPS altitude, which requires pressure accuracy better than 0.1% of 1 atm. The MS5607 sensor used in the Raven3 and several other current-generation altimeters is smaller, more rugged, less expensive than the MS5540, and still provides valid data up to around 100,000 feet. To say that it "craps out" at 30kft is not an accurate description. Perhaps you had in mind the older generation of analog-out sensors that used an amplifier to a 5V output that couldnt go much below 30kft equivalent pressure. I have tested several MS5607 altimeters side-by-side in a bell jar with the MS5540 to well over 100kft equivalent pressure, and it provides nearly identical results with the MS5540 up to about 50 kft, and gradually starts to under-estimate pressure from there. Between 80 kft and 100 kft it still provides valid data (for apogee deployments, etc) but significant altitude error (5%-10% IIRC) creeps in at that range.

 

[Adrian A]

Back on the original topic though, this part continues the trend of rapid progress I've been tracking in MEMs inertial sensors over the last few years. I'm going to focus the next few months on getting the Sparrow altimeter to production, and then evaluate what to work on next. I have lots of ideas for a major overhaul of the Raven, including switching over to a 32-bit ARM microcontroller. Using digital-output sensors across the board is definitely in the plan, but I haven't decided whether to incorporate a gyro into the next Raven or make a separate tilt-checking timer.

The Invensense parts have an annoying aspect of their advertised Motion Fusion capability; it is only provided as an object code library for running externally on the Atmel microcontrollers, the last time I looked into it. It will be a lot nicer when a chip like this outputs a quaternion. In the meantime there is a lot of code to be generated and a lot of processing time at run-time to turn 3 axes of rates into a continuously-updated attitude, especially if the magnetic vector is part of the process.

There is a 100+ G, digital-output, 3V accelerometer available; I have several hundred of those parts in my inventory ready for the next Raven overhaul.

 

[bobkrech]

The MS5540 digital-output sensor used in the original Raven and Raven2 has been flight-proven to provide valid, accurate data over 100,000 feet. (See the Carmack-winning Aeropac flight that had baro altitude from the Raven virtually identical to GPS). By "virtually identical" I mean altitude error around 1% of the GPS altitude, which requires pressure accuracy better than 0.1% of 1 atm. The MS5607 sensor used in the Raven3 and several other current-generation altimeters is smaller, more rugged, less expensive than the MS5540, and still provides valid data up to around 100,000 feet. To say that it "craps out" at 30kft is not an accurate description. Perhaps you had in mind the older generation of analog-out sensors that used an amplifier to a 5V output that couldnt go much below 30kft equivalent pressure. I have tested several MS5607 altimeters side-by-side in a bell jar with the MS5540 to well over 100kft equivalent pressure, and it provides nearly identical results with the MS5540 up to about 50 kft, and gradually starts to under-estimate pressure from there. Between 80 kft and 100 kft it still provides valid data (for apogee deployments, etc) but significant altitude error (5%-10% IIRC) creeps in at that range.

I have been working with MEMS pressure sensor for 2 decades so I know how they work. Unfortunately many manufacturers don't include all features in their data sheets, and the mass market is barometer sensors used for ground level pressure measurements. Since Mount Everest is just under 30 kft, there's not reason for go over 30 kft for that application. You missed my second post https://www.rocketryforum.com/showt...ro-Accelerometer-Compass)&p=570218#post570218

 

[bobkrech]

Back on the original topic though, this part continues the trend of rapid progress I've been tracking in MEMs inertial sensors over the last few years. I'm going to focus the next few months on getting the Sparrow altimeter to production, and then evaluate what to work on next. I have lots of ideas for a major overhaul of the Raven, including switching over to a 32-bit ARM microcontroller. Using digital-output sensors across the board is definitely in the plan, but I haven't decided whether to incorporate a gyro into the next Raven or make a separate tilt-checking timer.

The Invensense parts have an annoying aspect of their advertised Motion Fusion capability; it is only provided as an object code library for running externally on the Atmel microcontrollers, the last time I looked into it. It will be a lot nicer when a chip like this outputs a quaternion. In the meantime there is a lot of code to be generated and a lot of processing time at run-time to turn 3 axes of rates into a continuously-updated attitude, especially if the magnetic vector is part of the process.

There is a 100+ G, digital-output, 3V accelerometer available; I have several hundred of those parts in my inventory ready for the next Raven overhaul.

We use a 32-bit ARM to fuse 6-DOF IMU(3D accel, 3D gyro), 3D magnetometer, barometric altimeter, and GPS sensors into positional and navigation info in our MAV. Costs less than $2.

 

[thomas]

Well I am not so impressed by the MPU9150.
It is a MPU6050 connected to an AK8975 in one package.
This is nice in regard of axis alignment but I would prefer to have a HMC5883L instead of the AK8975 .

Regarding high-g digital SPI sensors the ADIS16204 looks nice.

 

[Joe Walsh]

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

I wouldn't worry too much about this IMU being used to target stuff. The acceleration signal is noisy and sensitive to vibration. Integrating all that noise twice gives you a lousy estimate of the XYZ position. It's about as accurate as trying to target something with GPS.

 

[bobkrech]

I wouldn't worry too much about this IMU being used to target stuff. The acceleration signal is noisy and sensitive to vibration. Integrating all that noise twice gives you a lousy estimate of the XYZ position. It's about as accurate as trying to target something with GPS.

Noise is not necessarily an issue. That's what Kalman filters are for.

 

[UhClem]

The Invensense parts have an annoying aspect of their advertised Motion Fusion capability; it is only provided as an object code library for running externally on the Atmel microcontrollers, the last time I looked into it. It will be a lot nicer when a chip like this outputs a quaternion.

It appears that the 5.1 SDK supports 6 axis processing on the 9150. I spent a few minutes registering but I am not deemed worthy of downloading their code.

 

[Larry Curcio]

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

The name of the game is taking the onboard data and reducing them to that X, Y, Z frame around a ground observer. The instrument’s frame of reference is within the rocket, which is translating in three directions (3 DOF) and rotating around three axes (another 3 DOF). It's also accelerating. (Oh joy!)

The first step is to map the rocket’s internal coordinates to external 3-space; the second is to assess motion of the CG in that space. Such analysis requires a 3-axis accelerometer and a 3-axis gyroscope.

The remaining three DOF are new to me. (Anybody?)

Incidentally, nothing in the instrument (as I described it) senses gravity. The effect of gravity must be computed by dead reckoning, just as it is with our dinky single-axis accelerometers. (We assume a vertical flight and add in the effect of gravity by subtracting 1g from the instrument reading.) The difference is that a 6-axis instrument gives you a better idea of which way is down.

-Larry (semi-retired from the hobby) C.

 

[Adrian A]

The name of the game is taking the onboard data and reducing them to that X, Y, Z frame around a ground observer. The instrument’s frame of reference is within the rocket, which is translating in three directions (3 DOF) and rotating around three axes (another 3 DOF). It's also accelerating. (Oh joy!)

The first step is to map the rocket’s internal coordinates to external 3-space; the second is to assess motion of the CG in that space. Such analysis requires a 3-axis accelerometer and a 3-axis gyroscope.

The remaining three DOF are new to me. (Anybody?)

Incidentally, nothing in the instrument (as I described it) senses gravity. The effect of gravity must be computed by dead reckoning, just as it is with our dinky single-axis accelerometers. (We assume a vertical flight and add in the effect of gravity by subtracting 1g from the instrument reading.) The difference is that a 6-axis instrument gives you a better idea of which way is down.

-Larry (semi-retired from the hobby) C.

The other 3 measurement channels (I agree DOF is poor terminology) are from a 3-axis magnetometer. That's useful for preventing gyro errors from accumulating and causing the attitude estimate to wander off. It only provides information on 2 of 3 rotational DOF with any one measurement, but it's still effective when used in a Kalman filter, especially as the rocket rotates around. In the continental U.S., the magnetic vector is only about 30 degrees from vertical, though most people are only aware of the smaller horizontal components.

 

[CarVac]

With a sufficiently accurate IMU, you can fuse that data with GPS to get a reliable 3D flight path. Whether that's useful or not is up to you to decide, though.

 

[UhClem]

With a sufficiently accurate IMU, you can fuse that data with GPS to get a reliable 3D flight path.

With the right GPS, you don't need the IMU.

 

[cerving]

Intriguing idea. Which GPS would you suggest? If the GPS were accurate and responsive enough, you might be able to replace the baro and accelerometer as well, reducing both cost and complexity.

With the right GPS, you don't need the IMU.

 

[jderimig]

The Unafffordia Model 901T.

 

[UhClem]

Intriguing idea. Which GPS would you suggest? If the GPS were accurate and responsive enough, you might be able to replace the baro and accelerometer as well, reducing both cost and complexity.

So far I haven't seen any commercial product. But the idea is very simple.

The flight unit does no processing of the GPS signal other than to digitize the IF output. All of the processing for position is done on the ground.

The first example I saw of this was a very expensive GPS translater/S-band telemetry transmitter But we don't need anything like that. SD cards provide more than enough storage and there are cheap (<$5) GPS receivers available. You can even find code to process the data for free. Although I would consider the code just a starting point.

Consider that the typical GPS receiver computes a position infrequently. A typical consumer GPS does it once a second. You could, if you had the data available, compute a solution with every data sample but I doubt if anyone requires position updates every micro-second. Post processing allows you to do things you could never do in real time.

 

[cerving]

I think if the goal was to build a GPS-based dual-deploy flight computer then 2-5 times per second would probably be OK for the update rate. 1/sec is probably a little bit slow, but would probably still work for determining a reasonable apogee point and triggering the main. It would be a simple matter to calculate the vector position from launch with just about any MCU, and that might be what you would want to send out the telemetry port ("I'm 2312' downrange from the launch site at compass position 332").

It would probably take one of the new helical antennas, a patch antenna would probably lose lock too easily. Either that, or you'd need to use several patch antennae in some kind of orthagonal array to improve the omnidirectional performance. That's way beyond my mortal RF skills, however.

I'd love to know which GPS units are under $5... that's probably in 1M quantity, I assume. Most of us don't have Apple's pull in determining pricing with the vendors...

So far I haven't seen any commercial product. But the idea is very simple.

The flight unit does no processing of the GPS signal other than to digitize the IF output. All of the processing for position is done on the ground.

The first example I saw of this was a very expensive GPS translater/S-band telemetry transmitter But we don't need anything like that. SD cards provide more than enough storage and there are cheap (<$5) GPS receivers available. You can even find code to process the data for free. Although I would consider the code just a starting point.

Consider that the typical GPS receiver computes a position infrequently. A typical consumer GPS does it once a second. You could, if you had the data available, compute a solution with every data sample but I doubt if anyone requires position updates every micro-second. Post processing allows you to do things you could never do in real time.

 

[UhClem]

I think if the goal was to build a GPS-based dual-deploy flight computer then 2-5 times per second would probably be OK for the update rate. 1/sec is probably a little bit slow, but would probably still work for determining a reasonable apogee point and triggering the main. It would be a simple matter to calculate the vector position from launch with just about any MCU, and that might be what you would want to send out the telemetry port ("I'm 2312' downrange from the launch site at compass position 332").

I thought the subject was 3D position, not a deployment controller. Post processing of GPS data is useless for that.

I'd love to know which GPS units are under $5... that's probably in 1M quantity, I assume. Most of us don't have Apple's pull in determining pricing with the vendors...

SE4150

But like I said, it does no processing other than digitizing the IF output.

 

[cerving]

Yes, a traditional deployment controller is basically working in 1D. 3D gives you the ability to tell you where the rocket is in space, and maybe with a steerable parachute and a few servos have it come back to you. Wouldn't that be cool? Obviously, the unit has to be self-contained so remote processing isn't an option, so you will either need a GPS module with some intelligence or you will have to have enough CPU power to do the post-IF processing on-board. Lots of possibilities...