Is this a good IMU Sensor?

[Dantesinferno]

http://www.pololu.com/catalog/product/1268

$40!
Info off site:

The Pololu MinIMU-9 v2 is an inertial measurement unit (IMU) that packs an L3GD20 3-axis gyro and an LSM303DLHC 3-axis accelerometer and 3-axis magnetometer onto a tiny 0.8″ × 0.5″ board. An I²C interface accesses nine independent rotation, acceleration, and magnetic measurements that can be used to calculate the sensor’s absolute orientation. The MinIMU-9 v2 board includes a voltage regulator and a level-shifting circuit that allows operation from 2.5 to 5.5 V, and the 0.1″ pin spacing makes it easy to use with standard solder-less breadboards and 0.1″ perfboards.



I'm probably going to buy 2 of these for my project in combination with an arduino, but I want some of you guys' opinions.

what do you think?

[cybereality]

Well I don't know much about that IMU, but I am looking as well.

This one from SparkFun looks interesting, but somewhat expensive for $100:
https://www.sparkfun.com/products/10724

Also found this on eBay, but for $18 I bet you get what you pay for:
http://www.ebay.com/itm/9DOF-9axis-degr ... 484c107b41

My only worry is poor documentation. I guess you could always get the data-sheets for the chips and try to figure it out, but this seems daunting for an electronics beginner. Would like something that came with some code to get up and running. Seems like that Pololu chip has some sketches for Arduino, so maybe that is a good choice. Hard to say.

[cybereality]

Well here is a video of the IMU integrated into 3DS Max. Looks decent.

[youtube]http://www.youtube.com/watch?v=PyUgsx3SuyE[/youtube]

[Dantesinferno]

Yea it seems pretty legit! Plus the person in the video is using v1 and not v2 .. So I expect this one to be better .. Thank god it's cheap tho! The yei tracker and hillcrest are great... But I'm young, and don't have a lot of money lol


Video of v2
[youtube-hd]http://www.youtube.com/watch?v=8daR-wtQIx0&sns=em[/youtube-hd]

[MSat]

The sensor is pretty neat, but keep in mind that it has an I2C interface and not USB. That means if you want to interface with the PC you'll need to do it either through a microcontroller such as the Arduino, or an I2C->USB interface chip. Another thing to mention is that if you want to use two of these, you won't be able to use one device with a single I2C interface unless you also add something like an I2C mux/switch, otherwise you'll need one for each sensor.

[geekmaster]

PCF8575 REMOTE 16-BIT I2C AND SMBus I/O EXPANDER WITH INTERRUPT OUTPUT
• I2C to Parallel-Port Expander
• Compatible With Most Microcontrollers
• 400-kHz Fast I2C Bus
• Address by Three Hardware Address Pins for Use of up to Eight Devices
• Latched Outputs With High-Current Drive

Using The PCF8575 i2c i/o Expander To Read Inputs With Arduino
This Instructable will show you just how easy it is to add extra inputs to your Arduino. You can use this technique to add hundreds of extra inputs to your Arduino with only two wires by using a fancy communication protocol called i2c (eye-squared-see).[/quote="http://www.ti.com/product/pcf8575"]

PCF8575 (ACTIVE) Remote 16-Bit I2C and SMBus I/O Expander with Interrupt Output
Sample & Buy
Free Sample

Or get a $10.90USD (free shipping) STM32F3DISCOVERY IMU with integrated ARM processor and microUSB port:
http://www.mtbs3d.com/phpBB/viewtopic.p ... 99#p106599
It is larger than the others, but it has a built in ARM processor to do the sensor fusion for you. Here is a video showing one of these in operation:
[youtube]http://www.youtube.com/watch?v=rqw5J4Ee6JE[/youtube]

The STM32F3DISCOVERY has all the pins broken out to connectors, so you could use it to control a bunch of the other smaller $18 units mentioned in the previous post above.

[MSat]

There's also the NXP PCA9540B (http://www.nxp.com/products/interface_a ... 9540B.html) I2C mux that uses I2C data to select the port instead of physical control lines.

Or as geekmaster says, go with the ST Discovery board which has 2 I2C ports.

Sometimes it's worth it to spend the extra money and buy something that has all this capability built in for the sake of simplicity, because if you're new to embedded programming then you'll have a long road in front of you. Of course, it's a great skill to acquire if you're interested

[cybereality]

Hey Dantesinferno!

I just bought the MinIMU-9 v2. I can try to test it first, if you don't mind waiting. Hopefully the kit is worth it.

[Dantesinferno]

lol sorry @cybereality and the rest of you guys, i have to check this sub section of the forum more often. i keep checking the oculus section.

Yes if you could test it and show me your results that would be awesome! Are you planning on using an arduino? I'm going to try to make the sensor wireless by using an xbee .. but i have to do some more research/tutorial finding. The next thing that i'm unsure of is, say i want to use the info from the sensor in a game engine such as udk or unity, i'm going to have to learn to make my own dll file . Unless there is an easier way you know of?

[cybereality]

Yeah, I'm going to be hooking it up to an Arduino. I'll get it working over USB first, wireless can always be added. I am also somewhat new to the whole electronics thing, but it doesn't seem too hard so far. Still have to figure out how to interface it with a game engine. Its probably straight-forward using a C++ app, for Unity/UDK you might have to go the DLL route.

Anyway, I'll let you know how it goes.

[MSat]

Going the Arduino route is most likely the easiest way to start off, as there's a huge community around it. While I'm not sure if the performance is sufficient enough to do the sensor fusion on-board, but if it is, then all you might need to do is emulate a gamepad/joystick as a lot of games have at least some built-in support for them giving you something to work with. If it can't do the sensor fusion, but you still would like the emulate a joystick, it might be possible to have the Arduino enumerate as two different USB devices - one which transmits raw sensor data and receives the fused sensor data, and another that enumerates as a game pad and re-transmits the fused data as a joystick. You would have to write an application on the PC side that does the sensor fusion, but wouldn't have to necessarily interface it with the game directly.

If you want to go with the wireless route take a look at this kit from TI (http://www.ti.com/tool/cc2541dk-mini#0). It's not the cheapest thing, but you get some nice Bluetooth hardware and a programmer. The bottom right jumper on the key fob is a breakout for some of the chip's peripherals such as the I2C bus. Also, the fob has a built-in accelerometer which might come in handy.

Perhaps even better is this bluetooth kit: http://www.ti.com/tool/cc2541dk-sensor "...includes TI’s TMP006 IR MEMS temperature sensor, humidity sensor, pressure sensor, accelerometer, gyroscope and magnetometer" for only $25! You'll need to have a bluetooth transceiver for your computer, and write software to interface with games, but that price is really hard to beat!

[Dantesinferno]

WOW thanks Msat, I'll read more into that once i get home... all this vr craze/research has got my time management all out of whack! I'm in school constantly researching while the professor is teaching..

Thanks for the links! I'll edit my post once i read through it!

[V8Griff]

All very interesting stuff.

The technical side of this is way beyond me but from what I can see and understand the orientation stuff is all pretty well sorted from the videos posted.

What is the situation now from a positional side of things? Is there some way of piggybacking another device and/or adding a base station that could calculate the position of the orientation sensor from a fixed base point?

I'm thinking along the lines of a base unit that a hand held device is placed in and the once initialised can calculate the movement of the hand held unit from that base point?

[MSat]

All very interesting stuff.

The technical side of this is way beyond me but from what I can see and understand the orientation stuff is all pretty well sorted from the videos posted.

What is the situation now from a positional side of things? Is there some way of piggybacking another device and/or adding a base station that could calculate the position of the orientation sensor from a fixed base point?

I'm thinking along the lines of a base unit that a hand held device is placed in and the once initialised can calculate the movement of the hand held unit from that base point?

The most common method of positional tracking seems to be based on some type of optical system. As for a mixture of orientation and positional sensing, the PS Move is probably one of the most popular examples - it combines a "9DOF" IMU with an optical marker on a single controller.

Unfortunately, there's no single solution that is ideal for every situation. The biggest drawback of optical systems is that they suffer from occlusion problems. There's ways of mitigating it, but it's generally at the expense of added complexity.

No matter the system used, it tends to always be some sort of balancing act between ease of use/setup, cost, capabilities and robustness. There have been a lot of great threads in these forums that discuss various systems, along with their strengths and weaknesses.

[V8Griff]

I was wondering if the same accelerometers and gyros could be used to compute the positional space by calculating the distance from the origin.

My experience is with professional level magnetic tracking from both Polhemus and Ascension but those solutions are expensive and the Hydra's attempt seem to be flawed, has anyone investigated the potential of building an affordable magnetic tracker?

[cybereality]

@V8Griff: Unfortunately, positional tracking has not been solved yet in the way it has been for orientation. There are methods, for example optical (PS Move) or magnetic (Hydra), but it's not like you can just buy a chip that does it. I mean, I think it may be possible to estimate position using accelerometers and gyroscopes, but you would still need some sort of 'frame of reference' to stabilize the results. It would be great if you could do it all with just an IMU, but people have indicated the inaccuracies are huge. I'd still like to try, though, and that is one of the reasons I bought the IMU.

[V8Griff]

@cybereality. Thanks for your answer. What sort of a 'frame of reference' are you referring to?

[nateight]

What sort of a 'frame of reference' are you referring to?

I'm no expert, but I think cyber's refering to the reason a late-model Wiimote has three accelerometers, two gyroscopes, AND the IR sensor and bar - anything less isn't enough. Assuming a perfectly accurate IMU, turn it on and start feeding in data. It can tell when you turn to the left 10º easily enough, but because you didn't tell it what position it was in to start with that data isn't of much use. Now consider that any sort of accelerometer found in a consumer device is extremely crude relative to what your expectation of modern sensing equipment should be, errors on the order of that 10º turn you made earlier, serious problems with drift, etc. - and suddenly you need to constantly remind your device where it is and correct for some pretty major error margins. If you haven't already, look at PatimPatam's POSITTRON - absent some technological breakthroughs in determining orientation from stereoscopic cameras, I have a suspicion you're looking at something quite like what we'll see in the consumer Rift, and that's in addition to a full package of accels and gyros.

[V8Griff]

OK, that sounds logical enough.

That's why I suggested in my earlier post would it be possible to have some sort of base unit that the joystick would be positioned in initially and then removed once initiated and then refer back to that a point of reference?

ETA OK I had a look at the Positron, and I'd seen that before. Personally I don't think optical tracking is the way to go for home applications.

My thinking is either a solution based around IMUs, magnetic tracking or a combination of the two.

[nateight]

That's why I suggested in my earlier post would it be possible to have some sort of base unit that the joystick would be positioned in initially and then removed once initiated and then refer back to that a point of reference?

Sorry, doesn't work - forgetting that perhaps the only good way to get everyone orienting their base correctly would be to ask them to take out their laser levels, when I say serious problems with drift I mean serious problems with drift. I recently had a Wiimote hooked into GlovePIE, a software suite that enables using weird controllers in games that don't natively support them, etc.? This is the Big N, now, if there were accelerometers twice as stable and precise at twice the price they'd be using them; I layered on some fairly thick smoothing functions, and set the Wiimote down on my desk. Inside a Windows Game Controllers test panel, the axes I had two of the accels mapped to looked like they were taking a ride on a rickety old wooden roller coaster, just having the time of their lives. You'd need to be referring back to that base station constantly, literally every frame is what's optimal, else you fall out of alignment with reality so quickly the IMU ceases to be useful as any kind of reliable input device. Sensor fusion is the only option, because each individual data stream has massive flaws.

[V8Griff]

OK so we're talking serious limitations with the available hardware at the moment.

Thanks.

[MSat]

V8Griff,

From the sound of it, you're asking about dead reckoning - where current sensor data is constantly being integrated with previous sensor data to estimate position. As nateight and Cyber mentioned, there is a major issue with drift which stems from the underlying technologies used - mainly from the noise floor of the sensors and the fact that the sensor readings are quantized (so sensors can never be 100% accurate). When Cyber mentioned the "frame of reference", I believe he was referring to something that could periodically detect the actual position of whatever is being tracked, and use that as a correction factor. For instance, let's say we're interested in position tracking of the head; what we might be able to do is use a very fast low-latency IMU for dead reckoning position estimation, and a much slower camera with greater accuracy to periodically correct the position. It combines the strengths of two different systems as long as A) drift doesn't accumulate faster than the optical system can correct for it, and B) the optical system is robust enough to provide a sufficient correction factor.

[V8Griff]

MSat, thanks for that reply.

Yes I've heard the term 'dead reckoning' before in reference to this so that's what I mean although I couldn't have explained it in the terms you have.

It may be a mental block I have through less than great experiences with very expensive optical tracking in the past but I still think the occlusions that occur in optical tracking make it less than ideal for accurate and affordable positional tracking in the home.

I keep coming back to magnetic tracking as the ideal solution but I know it's not cheap. As I've mentioned the Hydra is a good first stab at this but it seems to be very low power and quite inaccurate.

Polhemus and Ascension both produced PC board solutions for Virtuality in the '90s that were reasonably affordable and I can't help thinking that with the processing power and chip technology we have today that a system could be produced today at a price point similar to the Rift

[MSat]

I hear ya. I think magnetic tracking is great - Sixense has proven that it could be affordable, and that it has a ton of potential, but that's not to say that it doesn't have its own weaknesses as well. But as I said before, the expected usage will largely dictate the methods used. In any case, I think the best solution for any type will combine a few different systems. For example, the problem John Carmack had with using a Hydra for head tracking could have likely been eliminated with the addition of an accelerometer to detect the gravity vector.

I certainly wouldn't write off optical tracking, though. There are a lot of ways it could be implemented while mitigating the effects of limited occlusion.

[Dantesinferno]

I've got a plan for positional tracking.. that doesn't require any IR led's ,camera's, or magnetic fields and etc. I'll unveil it in a few months so BE READY

but i have another question, can i have more that 2 sensors plugged into an arduino? I'm looking at plugging in around 11 total!

[MSat]

but i have another question, can i have more that 2 sensors plugged into an arduino? I'm looking at plugging in around 11 total!

Technically, you can't have more than one I2C sensor with the same address plugged into the same I2C bus unless you use an appropriate multi-channel mux/switch (which effectively creates a multi-path bus, or you implement additional I2C buses in software on in the Arduino.

Think of it this way: you have all the sensors hooked up on the same telephone line, and each one has the same phone number. Because of this, there's no way to "call" the specific sensor that you want to get data from because they're all answering the same call and trying to speak at the same time.

So I did a quick search, and found at least one software I2C library odbot.com/blog/2010/09/25/softi2cmaster-add-i2c-to-any-arduino-pins/ so you can have multiple devices on a different bus, but it claims it's still a work in progress. There are probably more libraries like this out there

If I may, I'd like to suggest you check out the Parallax Propeller microcontroller ( http://www.parallax.com/tabid/407/Default.aspx ) which implements almost all of its peripherals in software, so you can basically have as many separate I2C channels as there are pins on the chip! Also, the Parallax forums are filled with some extremely knowledgeable and helpful people that have solutions for almost anything you can throw at them.

[Dantesinferno]

Thanks @msat! I really had no clue about that microcontroller... But now I'm stuck between a rock and a hard place.. I was looking to somehow connect all 11 stm32f3 discoveries together, they all use micro usbs and all need their own USB power supply .. I haven't made a purchase yet, I just want to get all the info down now. I think I might just have to find a cheaper 9dof imu that I can use with the parallax propeller. Unless somehow I can connect those stm32f3 discoceries

[MSat]

Whoops! I didn't even realize that the discovery board has a 9DOF IMU. I thought you were still talking about the Pololu device.

In that case, you can probably use 3 or 4 powered USB hubs to connect them all to the computer. No need for any additional microcontrollers.

[nateight]

Technically, you can't have more than one I2C sensor with the same address plugged into the same I2C bus unless you use an appropriate multi-channel mux/switch

I'm an I2c newbie so please don't take this as gospel, rather be precisely technical in correcting me so I can continue learning myself. I think what MSat meant to say is that you can't have more than one I2C master device per bus - up to 128 uniquely-addressed slave devices can be attached to a bus, but at 100KHz (or even "High Speed" mode at 3.4MHz) I'm guessing you'd hit the practical performance ceiling pretty quickly with certain kinds of sensors. Telephone-based analogies break down when you're talking about data communication protocols; I2C is a serial protocol, which means a great many different "conversations" can happen across a single I2C bus, they all just have to wait their turn. For something like even a fairly complex IMU with only a handful of sensors, the I2C bus seems perfectly fine. Consider what you already know is possible with I2C - it's the bus the Wii Remote Extension Port uses, meaning that a Nunchuk is a single I2C slave device that crams data from a two-axis joystick, three accelerometers, and two buttons into a six-byte report. I'm guessing one of those MotionPlus dongles counts as another I2C slave device, which is why you can plug a nunchuk into it and use both at once on the same bus - and now you've essentially got a 6DOF IMU very comfortably piping data into your Wiimote. Muxing I2C data isn't something that should have to happen under any kind of normal circumstances. Does this make sense? Can an expert correct me?

[MSat]

Actually, you can have multiple masters on an I2C bus!

What I meant was that in the case of the Pololu board, each chip has it's own fixed address. For simplicity's sake, lets say the gyro is address 1, mag address 2, and accel address 3. Those addresses will be the same on every Pololu board you buy, so if you try connecting two boards on the same bus, there's no was to address, say, the gyro independently, because when you send a command to address 1, both boards will think that you're talking to it.

Some chips have pins that you can connect in a certain way which configure the device to use one of several possible addresses to overcome that issue, but they usually don't have more than 4, so directly tying 5 of them to a single bus isn't possible.

[nateight]

in the case of the Pololu board, each chip has it's own fixed address.

Oh, interesting! It makes me wonder if you could pipe one of these Pololus into something like an Arduino acting as a master, and have several Pololu+microcontroller rigs also acting as I2C slaves connected into another central I2C master. Mostly, though, it just sounds like you'd want to find some different hardware you had more direct control over assigning - it does not appear the I2C bus itself presents any serious limitations to the sorts of data transmission even complex IMUs require, but if your sensors themselves won't play nice you can quickly run into problems.

[MSat]

The easiest way is to use a microcontroller that can run multiple separate I2C busses. So instead of hooking up all the IMUs as a daisy chain or star or whatever on a single bus, you would have to run an individual I2C bus from each IMU into the microcontroller which would act as a hub.

[cybereality]

So I got the Pololu IMU. When they said it was mini, they weren't kidding. This thing is small.

Unfortunately, work is kind of crazy at the moment (with GDC coming up) so I doubt I will get to play with this chip for a little while.

[Dantesinferno]

Thanks guys for the replies! I'm learning a whole lot throughout this process. I haven't excluded the i2c/imu with arduino route yet.. I still plan on buying one pololou board.. But say I was going to buy 11... If this were somehow going to be manufactured for the masses, how low would those sensors prices get ? All hypothetical, I'm just looking for the cheapest price point for all. $40 to ? And also I had a dream I got the rift devkit .. Such a tease

[MSat]

Thanks guys for the replies! I'm learning a whole lot throughout this process. I haven't excluded the i2c/imu with arduino route yet.. I still plan on buying one pololou board.. But say I was going to buy 11... If this were somehow going to be manufactured for the masses, how low would those sensors prices get ? All hypothetical, I'm just looking for the cheapest price point for all. $40 to ? And also I had a dream I got the rift devkit .. Such a tease

If we're talking strictly about the sensors boards (no enclosure, and no on-board microcontroller), here's a rough estimate along the high side:

magnetometer+accelerometer chip: $2
gyro chip: $2
passive components (resistors, capacitors, headers, etc): $1
PCB: $2
PCB assembly: $2

You can then wire them up to a single microcontroller "hub"

microcontroller: $2-4
PCB: $2
PCB assembly: $2
passive/active components (assuming you need to specialized external I2C hardware): $2-3

Keep in mind that a finished and packaged product (not to mentioned R&D time and other expenses) could almost double the total cost.

[Dantesinferno]

@Msat YOUR THE MAN! thanks for the estimates. What would be your estimate of all 11 sensors plugged into a microcontroller hub with all other expenses added in, would i directly be paying the workers of the chips? or woud i just pay the chip provider and they distribute the money. I know this is an overgeneralized question. Thanks ahead of time.

[MSat]

It's difficult to provide an estimate of the final cost of just the hardware (again, neglecting R&D, etc) as the end-product design needs to be considered - such as sensor packaging, how they're attached to the user (suit, straps?), where they're manufactured, etc. Not only is it complicated, but I certainly don't have all the answers

[Dantesinferno]

@msat lol I knew i was asking for a lot! hmm, I guess i'll just have to wait and see! thanks for your help so far though!