kriswiner / MPU9250

Arduino sketches for MPU9250 9DoF with AHRS sensor fusion
1.03k stars 472 forks source link

Using MPU-9250 on custom board, without break-out #177

Open aclex opened 7 years ago

aclex commented 7 years ago

Hello, Kris,

Greatly thanks to your detailed sketches and articles I managed to use MPU-9250 on my several boards properly without any major issues, but now I'm thinking of developing a custom board for my project (actually a hat board with sensors for Orange Pi) and would like to ask you several questions about using MPU-9250 chip on it, if you please.

  1. In general, is MPU-9250 still optimal solution across 9-DOF sensors? I've read the discussion in this issue carefully, and from it it seems, that's still right, but maybe something better or more precise is coming. I actually quite happy with the results I get from MPU-9250, especially after calibration, with proper use of Madgwick or Omid-modificated fusion filter, but my project is for quadcopter and the main thing I need is to make it hover stable and steadily with as little side movements, as possible, so, I think, any increase in sensor precision would help.

  2. From your experience, is there any preference in the connection protocol, I2C or SPI? It looks like with I2C it's slightly easier (and maybe faster) to query AK8963. And maybe it's less main CPU/MCU intensive. For example, on my current board I connect with SPI, and reading function takes about 300 us.

  3. From your experience with placing it to the board, do you have any recommendations on typical circuit, apart from the reference operating circuit in the datasheet? Or maybe there're some special moments with soldering it to the board?

  4. You've recommended to order the chips from New Hope seller, is it still the best choice? Their chips are usually of quite a higher price, that other sellers, but that's obviously due to better quality and control.

  5. And one small question about barometer: in your sketches it's shown, how to use both MS5611 and MS5637. How they are compared to each other? From the datasheet it seems, that MS5637 is slightly less precise, but my MS5611 (on Navio2 board) in real life has quite significant deviation in rest, about 0.7 m, and also a zero drift, probably due to the temperature increase, so sometimes even if the altitude increases, it registers, that it decreases. Did you notice MS5637 is less or more prone to such inaccuracy?

Thank you in advance for any details on these questions!

kriswiner commented 7 years ago

We still prefer the MPU9250 for all orientation estimation, we use it in our own flying robots. I usually buy them from aliexpress without problems and I use a variety of vendors. You can find them for $2.50 a piece; I always choose to order from several vendors to lower any residual risk. I use the reference circuit, and there are plenty of examples at OSHPark.com of circuits I have designed (Pesky Products) that work well. See here https://www.oshpark.com/shared_projects/rPoFArMY, or here https://oshpark.com/shared_projects/WnZaoIHh, for instance.

We prefer the MS5637 over the BMP280, and the latter is at end of production anyway. The MS5637 is as good as the MS5611 but is smaller and costs half as much, so this is what we usually use.

I prefer I2C since it is easy and plenty fast enough.

I designed a flight controller for Simon Levy http://Simon%20Levy%20%3Csimon.d.levy@gmail.com%3E that is open source, programmable via the Arduino IDE, and has just finished initial production. I think Simon is planning to use them in his classes but he might be willing to sell one or more. Here https://www.oshpark.com/shared_projects/2rxr8Eff is the design. It uses the EM7180 motion co-processor to manage the sensors and perfrom the fusion providing quaternions or Euler angles to the host via I2C register reads. We use this solution for all of out quad and hex rotors. The EM7180 is described here https://github.com/kriswiner/EM7180_SENtral_sensor_hub/wiki .

I hope this answers your questions, if not please ask again at tleracorp@gmail.com.

On Fri, Aug 18, 2017 at 4:01 AM, Alexey Chernov notifications@github.com wrote:

Hello, Kris,

Greatly thanks to your detailed sketches and articles I managed to use MPU-9250 on my several boards properly without any major issues, but now I'm thinking of developing a custom board for my project (actually a hat board with sensors for Orange Pi) and would like to ask you several questions about using MPU-9250 chip on it, if you please.

1.

In general, is MPU-9250 still optimal solution across 9-DOF sensors? I've read the discussion in this issue https://github.com/kriswiner/MPU6050/issues/6 carefully, and from it it seems, that's still right, but maybe something better or more precise is coming. I actually quite happy with the results I get from MPU-9250, especially after calibration, with proper use of Madgwick or Omid-modificated fusion filter, but my project is for quadcopter and the main thing I need is to make it hover stable and steadily with as little side movements, as possible, so, I think, any increase in sensor precision would help. 2.

From your experience, is there any preference in the connection protocol, I2C or SPI? It looks like with I2C it's slightly easier (and maybe faster) to query AK8963. And maybe it's less main CPU/MCU intensive. For example, on my current board I connect with SPI, and reading function takes about 300 us. 3.

From your experience with placing it to the board, do you have any recommendations on typical circuit, apart from the reference operating circuit in the datasheet? Or maybe there're some special moments with soldering it to the board? 4.

You've recommended to order the chips from New Hope seller, is it still the best choice? Their chips are usually of quite a higher price, that other sellers, but that's obviously due to better quality and control. 5.

And one small question about barometer: in your sketches it's shown, how to use both MS5611 and MS5637. How they are compared to each other? From the datasheet it seems, that MS5637 is slightly less precise, but my MS5611 (on Navio2 https://emlid.com/navio/ board) in real life has quite significant deviation in rest, about 0.7 m, and also a zero drift, probably due to the temperature increase, so sometimes even if the altitude increases, it registers, that it decreases. Did you notice MS5637 is less or more prone to such inaccuracy?

Thank you in advance for any details on these questions!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/177, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qiGzdcNtxlqAn8AP1mazhWkDKQpHks5sZW7wgaJpZM4O7aFn .

aclex commented 7 years ago

Thank you very much for detailed information and useful links, Kris, I think, it indeed answers all my questions completely.

As for using I2C: I seem to notice in the MS5611 datasheet, that it could be sensitive to activity on the bus during some phases of its working process, as datasheet of MS5637 looks quite similar, I think, it's mentioned there, too. Have you experienced any troubles like this, when using MPU9250 and barometer on one bus?

kriswiner commented 7 years ago

No

On Fri, Aug 18, 2017 at 9:44 AM, Alexey Chernov notifications@github.com wrote:

Thank you very much for detailed information and useful links, Kris, I think, it indeed answers all my questions completely.

As for using I2C: I seem to notice in the MS5611 datasheet, that it could be sensitive to activity on the bus during some phases of its working process, as datasheet of MS5637 looks quite similar, I think, it's mentioned there, too. Have you experienced any troubles like this, when using MPU9250 and barometer on one bus?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/177#issuecomment-323403628, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qpbzrOnTiwjWcQa4-OTMnEN2qB0Vks5sZb-IgaJpZM4O7aFn .

aclex commented 7 years ago

Very good. Thanks again for help and suggestions!