Next generation sensor platform ... MPU9250 vs. LSM9DS0

[Thomas Roell]

Looks like there are now a few more choices out the as opposed to the MPU6050/HMC5883 or LG3D20/LSM303 combos.

The MPU9250 has a 14 bit AK8963 embedded, which could update at 100Hz automatically. But there is no DRDY pin on the MPU9250 for the AK8963, which means you have to build up a manual measurement sequence using the I2C state machine on the MPU9250. Measurement time is 9ms (7.2ms typical), so this could be synched to the accel/gyro output of the MPU6500 (which is the on-die accel/gyro of the MPU9250). At a 20Hz bandwidth filter for accel/gyro, the delay for gyro is 9.9ms and for accel it's 19.8ms. This means the measurement for accel is about 10ms delayed relative to gyro. That was not the case with MPU6050, where the delta was about 1ms ... The realign could be done in software by queuing up 10 gyro samples ...

The read of the AK8963 has some I2C bus consequences, as there is only 1 I2C write possible at a lower sample rate. That means you can trigger a measurement, but still read it back at sample rate. So if one wanted to have 1kHz accel/gyro readings, one has to read 20 bytes each per packet. That is 24 10bit bus transactions (device address and register index included), so 240 I2C clocks. That means the bus utilization of the 400kHz I2C close to 60%, so still doable. 

The LSM9DS0 is still kind of a puzzle to me. Looking at the datasheet I fail to see what the gyro precision is, and what the effective magnetometer precision is. Some information on the net suggests the magnetometer is from Honeywell, so it's probably 12 bit. The real odd thing is the sample frequencies for accel/gyro. They are 800Hz vs. 760Hz. So if you use the gyro as the master input for your EKF, then the accel might be out of sync by 1.3ms. That is a magnitude worse than the 0.1 ms that the MPU9250 has. 

My EKF had the assumption that samples for accel/gyro are arriving virtually at the same time. With the MPU9250, I kind of can do that, but with the LSM9DS0 this seems to be impossible. If one let's the EKF run at say 250Hz only, then uncertainty of 1.3ms does not seem to be that much compare to the filter rate of 4ms ... 

Anyway, I am looking at this really from the interfacing and timing side. The real precision and quality of the samples is something I could not derive from the data sheets. I was wondering whether any of you had some thoughts on that.

- Thomas

[Minuteman]

We use the MPU6050, and get less than 1/2 degree drift over 60 seconds. We have it in single axis mode and sample it at 1 kHz. I'll be interested to see what others come up with, but for now, the MPU6050 is working great for us. 

[Michael Shimniok]

On 06/26/2014 03:22 PM, Minuteman wrote:
> We use the MPU6050, and get less than 1/2 degree drift over 60
> seconds. We have it in single axis mode and sample it at 1 kHz. I'll
> be interested to see what others come up with, but for now, the
> MPU6050 is working great for us.

Sounds awesome. I'm still working on the MAX21000. I had other more
important things to work on with the Jeep so it went by the wayside. If
I make any progress and can duplicate Josh's findings, I'll let you know.

Michael

[Ted Meyers]

I'm curious, are you going single axis just because you don't care about the other 2?  I guess the KISS rule applies here.

 

Also, do you do any noise floor filtering?  And what rates do you set the gyro at?

 

1/2 a degree is good enough, for sure!  I imagine that your starting angle error is more than 1/2 a degree.  I'll probably keep my compass, just for that reason.

 

Ted

[Rich B (Roadrunner)]

The starting angle error is 0 because the angle is zero'd out when the switch is flipped to start. Additionally, since most runs are <60 seconds, 1/2 degree drift still provides VERY good accuracy and consistency.

Concerning the other 2 axes, yes, the KISS principle is definitely used as much as possible. We've only ever used 1 axis and it has provided EXCELLENT results. The MPU-6050 gyro has build in filtering and provides very good data. I believe the gyro is sampled at 1kHz. 

[Thomas Roell]

Question is now whether parts that are 2 years newer at better or not. And if so, which one is better, and why.

- Thomas

[Ted Meyers]

Actually I was referring to the initial starting heading (not angle error -- I misspoke), which I'm assuming must be manually set as you do not have a compass, correct?  It seems like it would be difficult to manually place the bot within 1/2 a degree of the desired initial heading.

On Thursday, June 26, 2014 4:22:33 PM UTC-6, Rich B (Roadrunner) wrote:

[Rich B (Roadrunner)]

I was the person using a level at the competition. I'd line the level up with a few known spots at the starting line and place my tires against it. It produced very repeatable results (6 out of 6 attempts at the hoop). Minuteman uses a crack or some other defect on the asphalt to line up his car and also gets very repeatable results. I don't know if we are more or less than 1/2 degree off with our methods, but they are obviously good enough.

[Minuteman]

Ted, we are using the 42 Hz internal filter, only. We sum the output at 1kHz into a 32 bit buffer. That's all, really. The buffer is converted to radians when needed for navigation calculations. We use the default gyro rate of 250 deg/sec. I have done quite a bit of testing, and I really have to make sharp turns to saturate it (which doesn't happen in normal use).

We don't do any tilt compensation, so we don't bother with the other two axes. I don't think we get excessive roll in the chassis, so we make the assumption that it remains parallel to the ground. It has been good enough so far.

[Ted Meyers]

Hey, thanks for the explaination, that's really very impressive what you can do with just the one sensor!  Awesome!

 

You might think about a second gyro to deal with saturation situations caused by impacts (likely from other vehicles -- see other thread!)  I did notice that Minuteman's heading changed significantly right after colliding with JRover.

[Thomas Roell]

What is the 42Hz choice based on ?

- Thomas

[Minuteman]

Our dead reckoning is not tolerant of any external impacts or abrupt changes in angle--probably because of saturation as you've pointed out. I'll have to think about adding another gyro--for now I'm focusing on avoiding those impacts.

[Minuteman]

The 42 Hz is the default filter setting. I didn't play much with that setting. I do know that more filtering creates a significant lag in the readings. We just got really clean results, so we didn't mess around with it much.

[Thomas Roell]

42 Hz is interesting because it's the sweet spot between filtering and divergence of accel/gyro measurements.

- Thomas

--
You received this message because you are subscribed to a topic in the Google Groups "diyrovers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/diyrovers/TZJIvRdDrls/unsubscribe.
To unsubscribe from this group and all its topics, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/35a61468-9ec1-4579-88a2-18c473572ca0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Thomas Roell]

Just reviving this old thread.

I have been playing some with the MPU-9250, and it seems to have a tad of a lag if you want to use it's filtering (accel & gyro have different delays). 

The MPU-6050 did not have those oddities. I am wondering whether perhaps a MPU-9150 may be a better idea ?

- Thomas

[Ted Meyers]

It looks like Sparkfun is going to have their  MPU9150 and their LSM9DS0 breakout boards on sale on Cyber Monday (don't know the discount; they say 30% to 50%).  Of course they have the stupid one hour flash sales, so you can't order both at the same time (I don't get it, do they want to sell sale items, or not??)  I'm certainly not making multiple orders and paying shipping multiple times in one day!  (sorry about the rant).  Oh, they also have their OpenLog board on sale, it is a handy board for logging data.

I've been using the Pololu MiniIMU-9 (L3GD20H and LSM303D), and I've been happy with it (plus it is relatively inexpensive).

Ted

[Thomas Roell]

Ted, with the L3GD20H + LSM303D combo, have you found any documentation as to how long a delay is added from the measurement to data ready by the use of the low pass filter ?

- Thomas

[Ted Meyers]

No, at one time I went looking for that info but didn't find it; I don't remember if I couldn't find it in the datasheet, or if I couldn't make sense of what I did find.  At the time, I had intentions of rolling my own AHRS code, but the AVC started getting close and I gave in and just used the arduino library that Pololu has posted (that and I have so many other things I'd rather do than write code for IMUs -- I know, I'm wimping out).  In the end, it seems to work well enough, but I know it could be better.

[Robert Bouwens]

Thomas,
change the strategie.
use no filtering on the mems device and use an external pt2 element for filtering.
i am using a 1khz rate to read data from the device and feed it into a pt2 element.
this way you have a common delay at the price of a few cpu cycles.

robert

[Thomas Roell]

I think you on to something interesting.

In reality your filter/sensor system will produce a state at t0 (say P(t0), V(t0)), while your control loop needs to know the state at t1 (P(t1), V(t1)), which means P(t1) = P(t0) + V(t0) * (t1 - t0), V(t1) = V(t0).

Thus is you do Accel/Gyro filtering on the host, then you know what delay that results in and who know what t0 is.

That seems to be more reasonable than to assume P(t1) = P(t0), V(t1) = V(t0) and jump throu hoops to keep t1 - t0 at a minimum.

- Thomas