IMU (Inertial Measurement Unit) -- What's best?
LoopyByteloose
Posts: 12,537
I have gotten back into pondering a balancing robot. In trying to sort out what I have from what I need, I have come across IMUs as an alternative to piecing together separate gyros, accelerometers, and compasses. (My gyro is only 2 axis and analog; while my accelerometer is 3 axis and I2C digital -- ugh!)
Prices vary with Ebay offering rock-bottom alternatives. But I am unsure what people feel might be the best unit out there today.
http://www.ebay.com/itm/9DOF-9axis-degree-of-freedom-IMU-sensor-ITG3200-ITG320-5-ADXL345-HMC5883L-Module-/310513793857
My main focus is the 9 DOF units as I can always migrate them to another project. Maybe I will even get the 10DOF units that include a barometric device for altimeter.. in case I want this on a flying machine.
What has become obvious is that putting together the devices I have will be something substantially larger in footprint far less likely to have other's sharing insight on how to proceed.
Prices vary with Ebay offering rock-bottom alternatives. But I am unsure what people feel might be the best unit out there today.
http://www.ebay.com/itm/9DOF-9axis-degree-of-freedom-IMU-sensor-ITG3200-ITG320-5-ADXL345-HMC5883L-Module-/310513793857
My main focus is the 9 DOF units as I can always migrate them to another project. Maybe I will even get the 10DOF units that include a barometric device for altimeter.. in case I want this on a flying machine.
What has become obvious is that putting together the devices I have will be something substantially larger in footprint far less likely to have other's sharing insight on how to proceed.
Comments
The things to look out for are noise amplitude, sampling rates, ranges,
speed of interface (many are slow I2C, those that claim SPI are bending
the truth I've found), power consumption.
Both the sensor and the Arduino can be purchased for a few dollars each. My plan is to have the Arduino send the filtered data over a serial line to the Prop.
There's some really nice MPU6050 code that will run on the Arduino. I think there is also C code that will work on the Propeller but I think the Spin version of the MPU6050 code doesn't take advantage of the chip's internal filtering hardware.
I also like the HMC5883L 3-axis magnetometer which can be purchased for a couple dollars.
Some good points have been raised. I2C is slower that SPI, which a lot added protocol.
The main point here is that these devices seem to have overtaken where one might have constructed their own IMU from various bits before.
And it seems that the combination of a gyro and acellerometer sorted out with a Kalman filter is preferred to get accuracy and less drift on any axis.
In sum, I am just trying to cut through the internet hype and locate which is the best deal for most of us at this point. I'd rather not have an Arduino between the IMU and the Propeller.. added weight, added learning curve, though I suspect that driving multiple rotors would be a big reason to tack a Propeller on to an Arduino.
$69.00 USD with the Propeller included seems very hard to beat. Not sure if I2C is an issue or not on these. Definitely worth serious investigation as I was considering including the Propeller in anything that I built.
$70 May be a goof price, but I encourage you to look at some of the MPU6050 demos. I ran the MPU6050 on a little Arduino clone and I was amazed at how little drift there was. Even the yaw was accurate (and without a compass).
I doubt you need to spend more the $7 (not counting Propeller) to get a decent IMU.
Dog drat you, Duane, $2.31. I may have to investigate!
http://www.ebay.com/itm/1pc-6DOF-MPU-6050-3-Axis-Gyroscope-and-Accelerometer-Sensor-Module-for-Arduino-/131231041891?pt=LH_DefaultDomain_0&hash=item1e8dfac963
When the MPU6050 was combined with a compass on one chip, it seems that not much was gained. Sparkfun has a huge debate about this that is over a year old. ... No real code to support fusion of all 9 degrees.
Adafruit seems to have 9 degrees handled better with user information in a different product.
I may just go for th 6 degrees in a MPU6050 for now as that is quite a bit to handle, and really all I need.
+++++++++++++++
Once again...
The Ebay cheapies won't ship to Taiwan! Arg... have to turn to Sparkfun or Adafruit.
Regarding the I2C versus SPI...
At 400Kbits/sec versus 1Mbits/sec, the I2C seems to be fast enough.. even if I2C downloads might be 4 bytes versus SPI data at 1 byte.
The goal is to update the motor controller 250 times per second. It may be a challenge with the Arduino, but I suspect the Propeller can stay on top of it.
http://code.google.com/p/propforth/wiki/GY80
The code is sloppy, and right now it only basic drivers, and displays the 9 axis data values using a text only display, or logs the data and displays fewer values. I ran out of memory to do both full display and logging, and rran out of time to keep messing with it. Both Sal and Vic are doing other projects, so the actual IMU part is on the back burner again.
There is example Spin code for HoverFly Gimbel board (look in the Propeller Forum for it or use the HoverFly link in this thread to get there), and a complete schematic.
So it seems extremely appealing to opt for a device that has actually seen real world use as a camera gimbel on quad-copters. I am just about to download the zip and see what the Spin code offers.
Raw data is pretty much a basic requirement. The real important need is to have each axis take the gyro reading and the accelerometer reading and use the Kalman filter to eliminate drift. Ideally all the maths is done in binary rather than floating point... just to get it done fast. Not sure if the log tables in the Propeller help this along, but they might.
After all that is done, having PID motor control on all motors is strongly preferred. The HoverFly $69.00 USD complete IMU with Propeller, with schematic, and with some code examples might be easier to deploy that just a rock-bottom IMU. (Hard to say how much easier.)
++++++++++++
These can be use as sensors for input devices, like the Wi input devices that take hand and body gestures and provide game input.
Or they can be 'the robotic inner ear' of any robot that flies, crawls, or swims.
++++++++++++
The results of my crawling the web have been the following.
A. Ebay has the cheapest deals available, but you may get older chips with less that optimal performance.
B. HoverFly makes a very nice packaged deal for a fast start with the Propeller environment.
C. Sparkfun has stuff ... but their support community seems to be fading away.
D. Polulu and Adafruit are not cheap, but you will get fresher versions of chips AND a better support community.
The Ebay stuff tends to hook up with the Arduino community that expects somebody else to write a library for the hardware and then everyone will glob onto their example code. But don't expect the vendors to provide schematics or explain how to deploy the device.
I disagree with wisdom of the web.
I was amazed by the performance of the cheap ebay parts. I used a $3 MPU6050 and a $4 Pro Mini clone and and used the magic code which takes advantage of the MPU6050's internal filtering and got beautifully filtered data displayed to the terminal. My plan is to trim the serial output to just the data I want and have the Propeller parse in the filtered data.
The code for the HoverFly board gives the raw data from the sensors but I don't see any filtering going on.
My bet is the $7 IMU would provide a quicker path to a balancing robot than the HoverFly board. I don't think the HoverFly board is a bad board but the MPU6050 is a pretty amazing little sensor when used with the code capable of taking advantage of its hardware filtering ability and there is code available (mentioned several times on the forum) which does take advantage of the chip's hardware filtering.
When I tried this super duper MPU6050 code it worked so well it was eerie. Here's a link to the Jeff Rowberg code (great stuff). Here's more info at the Arduino Playground (I thought someone else just linked to this but I don't see a link in this thread.)
The HMC5883L sensors are really inexpensive and IMO work great. Here's a link to my code for the sensor.
I think Jeff Rowberg has code which uses the HMC5883L sensor along with the MPU6050 but I haven't tried it.
Here's a link to a gizmo I made which uses the HMC5883L for position feedback but I mounted the sensor to close to the servos and the servos interfered with sensor. I tried the same experiment with the sensor raised about three inches above the servos and it work MUCH better. I think the code I linked to lets you set any of the sensors parameters from the serial terminal so you can test out various configurations. I haven't figured out how to use the interrupt pin yet (I haven't tried very hard).
I intend to use the same gizmo with the MPU6050 but I keep getting side tracked with other projects.
My personal stumbling tends to be over two issues.
A. Building a whole concept board -- HoverFly offers a way out of that
B. Can't seem to get going on solving the gyro drift issue with Kalman filter and accelerometer input.
Everything I see on Kalman filters indicates
1. matrix maths
2. floating point maths
3. a state machine
That is quite a lot for many users to optimize into a real solution. So the MPU6050 may offload some of A and some of B. So far, I have only found two objects in OBEX for gyro+kalman filter searches, and both are floating point. Floating point eats up cogs and slows processing.. best avoided for warp speed.
My wandering mind has Googled "Kalman filter alternatives" and there are some; including a 'double exponential smoothing algorithm.'that claims to run about 135 times faster with simpler code There is also a 'multi-fractional order estimator'
So for now, I am playing mental bumper pool with Google on extremely geeky math discussions. If the MCP6050 bypasses all that through an internal process, what's not to like?
BTW, I really hate to capitulate to Arduino and load a mess of 'magic code' while not actually learning something along the way. (After all, this entry-level newbie hacking and I feel unwilling to go back to that.)
This link seems helpful at to what the MPU-6050 does... (It seems the DMP eliminated the Kalman filter and offloads a lot of hassle).
http://www.geekmomprojects.com/mpu-6050-dmp-data-from-i2cdevlib/
I should add that we sold several manufacturing runs of this board and it was a highly successful product. It was considered the "best" servo based gimbal controller on the market and sold for $360. The Freefly Radian competitive product sold for $1000. We replaced many Radians with the HoverflyGIMBAL board because it actually worked much better. Customers liked it because it never drifted and worked the same every time they used it. As I mentioned in my original post the advent of the brushless gimbal killed its usefulness.
The nice thing about the Experimenter Board is that you can plug it in via USB and start playing. The power is also routed in such a way to support three servos drawing higher current.
At the Ebay price of the MPU6050 I will probably get one too....but for Propeller dev the Experimenter Board is just easy. The code only needs to be modified slightly to switch to the MPU6050 later on.
for filtering. I had been trying to use it with my quadcopter until I burned out the FTDI chip on my Propeller proto flight board. I have been considering using it with a balancing bot.
My problem is lack of skills using these devices and I can't yet say it would be proper for either of those. But it seems to have very stable output using the Propeller to read it.
I can't help but like the fact that the HoverFly is a complete solution in one board.
Obviouls the MCP6050 is an easy entry. But I tend to agree that buying both is a win-win.
As far as the filtering, via Kalman filter or other alternative filter solutions -- this is simply the heart of learning how to deploy a custom IMU.
I just tend to be slow to commit to purchases as everything cost more to ship to Taiwan. And I can't simply buy an MCP6050 6 degree device from H.K. for $2.50USD. I have to get someone to deliver it to in the USA and then ship it here.
Thanks for mention this.
I suppose I will just buy a HoverFly ASAP and an MCP6050 device to compare.
The MCP6050 may be easier for entry level quick use, but the HoverFly seems to be far more useful and desireable over the long haul.
The filtering issue is daunting to quite a few. While everyone mentions Kalman filtering, I kept running into workable alternatives that are both simpler and faster. But one has to accept studying the math with an eye toward what one is trying to achieve.
Thanks for a great offer.
http://tinyurl.com/ka795z5
bunch of other options I can control using the Propeller. When I was at the beginning of trying to use it for a quadcopter it was interesting seeing the effects of switching different options while monitoring it's
output with motor vibration with ViewPort. I have a long way to go. Have fun with trying to balance something!
I understand C enough to translate from C to Spin several different Arduino programs. I did this for the MIFARE 13.56MHz RFID program (another inexpensive wonder). By the time I've translated a program from C to Spin, I generally understand how the program works pretty well. The MPU6050 code just looked like it would be too daunting of a task and would require more time than I'm presently willing to spend on the project.
There is a C version of the MPU6050 code that will run on a Propeller.
The Arduino uses "magic code" on several levels. Not only is the overall C program difficult to follow but the program loads an encrypted "blob" to the chip when it first starts up. This "blob" is really "magic code" but it's required to take advantage of all the chip's built in features.
If you need someone state side to pass along ebay purchases, I'm willing to do so.
I probably have an extra MPU6050 and HMC5883L board I could send now. It wouldn't be a problem for me to wait 3-weeks for replacements. This way you'd just have wait the shipping time from the US to Taiwan to receive the parts rather than waiting for me to receive the parts first. I may even have an Arduino board I could spare. Let me know if you want me to ship you some of this stuff.
I am more than willing to send you a bank check on a USA bank and to wait for it clear before you send anything to me. I will send you a PM to discuss what you feel comfortable with doing.
++++++++
Just to restate my feelings...
The MCP6050 versus a more generic IMU filtering approach is likely to be an endless debate. The cost savings for the MCP6050 is likely to win an extremely loyal following that would never consider a Hoverfly (especially if you saw the FedEx shipping rate to Taiwan).
But I am just really curious and each has its merits and drawbacks in terms of different learning curves.
Nonetheless, I am look forward to more lively exploration of creative uses for IMUs. You simply must have both the gyro and the accelerometer for each axis to get good results. It is silly to buy these things in separate units as they now come at least on one board and in some cases as one chip.
This is going to be fun.
I'm certainly willing to be your middleman with ebay but what about some of the other low price sources? ElectroDragon carries MPU6050 sensors and is inexpensive. HobbyKing isn't as inexpensive but not too bad. What about Amazon or DealExtreame? Do any of these other places ship to Taiwan?
I don't want to get into a long soap opera story, but ordering from Taiwan at times is very convoluted. Many EBay accounts won't ship to Taiwan; and many will only deliver PayPal to the address on the account -- not another shipping address in a different country.
In the end, I seem to often get tagged with shipping fees that are 50-100% of the item costs.
Let's see... You mention
Kalman
AlternatingKalmam
Complimentary
Quarternion gradient descent
Magneto-resistive Quaternion gradient descent
And then there is the....
MCP6050 Black Box approach... seems to include Quarternion gradients.
And I have come across...
Alpha, Beta, Delta filtering
Double exponential smoothing filtering
All belong to the math topic referred to as 'predictive tracking'.
And for the complete noob, complimentary filtering is likely the easiest starting point and may be completely satisfying. It is just that programmers and mathematicians can't seem to quell their desires to seek a new and better optimization. Some of these are very theoretical, others require lots of computational power.
The Kalman filter may be useful for gaining some design reference parameters. Matix maths isn't that hard, but I am very rusty at using it. May have to buy a Schwam's Outline. There are also other topics in Schwam's Outlines -- like Vector Analysis.
http://www.amazon.com/Schaums-Outline-Matrix-Operations-Series/dp/0071756043
And so, I have ordered a HoverFly and trying to buy an MCP6050. Meanwhile, I am taking what I have learned and trying to get into a pragmatic study mode.
BTW, after you get all of the above done --- you still will want to have motors with encoders and PID if you want a balancing robot on sloped terrain.
So getting into IMU programming is certain an upgrade in robotic skill sets. R U ready for the big time?
DealExtreame seems to have FREE shipping to Taiwan. I will give it a try.
I think Hanno's section of the Propeller book is about his dance bot. I haven't made a balancing bot myself but I helped someone convert Hanno's code to use a different accelerometer.
I have some PWM code which also reads encoders posted here. I don't recall if I have a version posted to produce PWM output and also read quadrature encoders for two motors or not. I know there's code to read two encoders but the code to both read and produce PWM signals may be written for four motors. The four motor stuff should work with just two motors.
I'll try to find a link to more info about Hanno's dance bot.
Edit: Here's website mentioning the robot but it doesn't include details.
Edit again: Here's the code for chapter 6 (the dance bot chapter) of the book I mention.
Balancing bots really are dependent on one axis. I suspect trying to monitor and manage all three is silly. But the quad-copters have reason to deal with at least two, and at times with three. Underwater ROVs as well. Or a flying camera gimbals.
I got into shopping mode as I didn't have a gyro with I2C and likely went way over the top. But the HoverFly is likely to migrate through several projects.
It is the typical story, I went looking for something that needed just one axis of gyro and accelerometer, and got carried away with 'wonderfulness of high tech'. I am feeling a bit dumber than dumb, and certain it will take a long time to grow into the hardware.
++++++
I am beginning to grasp Kalman filters. But they are far more generalized math than gyro applications. That is why the learn curve is tougher than the Complimentary filter... more abstraction.
===========
In reading about one blogger's experience with comparing the MCP6050 deployed via a complimentary filter versus it's internal processor, he did get it working.
But.... in order to do so, he had to slow the output to 20 times per second versus 100 times per second for the other. I am targeting 250 times per second for balancing. Either he doesn't understand how to streamline his data flow and overruns the buffers because of that, or the Arduino is too slow for the MCP6050. ((Hint -- Maybe the Propeller can relieve this bottleneck))
______________ The Bottom Line_________________
I am having a lot of fun with this... more than 3D printing.
It is possible that all these accelerometers, gyros, kalman filters and so on are overkill. I have seen such balancing bots managing to stay upright with nothing but a "bang-bang" controller. No micros or funky algorithms at all. Sorry I cannot find a link to such at the moment.
Seems I manage to stand upright and walk and for sure is no kalman filter anywhere in my body.
You haven't see the ball bot video? I'll try to find a link. Edit: Here's the link.
Erco wrote an article (I think for Robot magazine) about his balancing bot. I'm pretty sure it didn't have a gyro or an accelerometer. I think he just used a Ping.
It may not be a kalman filter exactly but you certainly have balance sensors and hopefully a brain to process their data.