first of all let me say it's a week I'm studying IMU and how to use it, so I'm totally new to this type of sensors. I've read a very intersting post (http://www.starlino.com/imu_guide.html) about how to get and handle gyroscope/accelerometer info directly from this kind of sensors and now I see what a microcontroller (an Arduino in our case) is expected to do to calculate roll and pitch (and eventually yaw).

I have few questions:

1) there are lots of breakout boards on the market, some of them provide just the sensors (like this one form Adafruit http://www.adafruit.com/products/1714 or this one from Sparkfun https://www.sparkfun.com/products/10724), other include also a digital processor (like this one https://www.sparkfun.com/products/11028). I don't see any relevant difference in price (between $40 and $50), so I guess the real differences are in the sensors, correct? It's not so easy for me to understand what I have to look in the datasheets: info like sensitivity seems to be the same for all the boards...

2) looking at the example code provided by the manufacturers, it seems to me that the board with a DSP (or DMP as Sparkfun call it) is able to provide roll/pitch/yaw info with no need for additional code, is that correct? I have no prob with the math involved, but I've seen how much code we need to transform raw data from accelerometer and gyro and I'm a bit worried about the size of the resulting sketch I should load into the Arduino's memory. So using an IMU with a DSP on-board seems to be a good choise: is this a real concern according to you?

3) last but not least: in case of board with digital processor, I've seen there is a FIFO used to interface with the microcontroller, but it's not clear to me how often I can access this FIFO looking for updated data. Let's consider a scenario where my sketch just gets the data, throws it away and then looks for new data... just to stress the Arduino<->IMU communication. Is the IMU-DSP so 'quick' and the Arduino so 'slow' that every time I will ask for new roll/pitch/yaw data I will find something updated in the FIFO? or could I find an empty list? I don't think the IMU-with-DSP board can be the bottleneck of the architecture, but just to be sure

The IMU calculation needs to proceed continuously on a more or less uninterrupted basis.

Processors are cheap. It makes sense to have the IMU calculation on a dedicated processor where it can be debugged and optimised once, and then not messed around with afterwards, and do other activities on a separate processor.

So, just to make an example, if I would stabilize a quad-copter I should go for an IMU with a processore on-board like the MPU-9150, correct?

Assuming I really need a dedicated processor (again the quad-copter example), do you think it's better to get a board with sensors and a processor or to get a set of sensors (gyro/accelerometer/compass) and use a dedicate Arduino to calculate the roll/pitch/yaw? I know that any IMU-with-processor board comes with its own library able to provide what I'm asking and for sure I don't want to reinvent the wheel but the algorithm used by the legacy processor is something I cannot control or change and I've see there are a lot of different ways to calculate roll/pitch/yaw starting form the raw data. I'm trying to understand if there is any side effect in choosing an IMU-with-processor Arduino<->IMU_with_processoror vice versa if there is any real advantage in choosing a set of sensors and use an Arduino to manage them (like the control on the algorithm)Arduino_Master<->Arduino_IMU_dedicated<->IMU_sensors

My previous comments were related to the flight control boards which actually have another arduino type processor in them, not the so-called processor of the MPU gyro chips. But the purpose of those is fundamentally the same, to take some of the processing load off the other processor.

Hobbyking multiWii board. Its actually an Arduino Mega with all the sensors attached and ready to go. Even has a serial GPS tossed in the mix. If you need software examples on how to use it, there's the open source multiWii codebase to look at. Although, the multiWii codebase is, for me, really tough to understand what they are up to.