I've been working recently with the CHR Robotics UM6-LT Inertial Measurement Unit. At first glance, the sensor seems to be ok, and within it's price range ($150) it's certainly the best that we could find. Most IMUs have, in the past, been very expensive. However, a couple of things that I don't like about the UM6:
- The product is under documented (see below for specifics).
- Customer service is lacking (see email conversation below).
- Their interface software is windows only.
- They say their software is open source, but what they really mean is that you can download the .hex programming file. No source code available.
I've written a driver object, soon to be uploaded to the Propeller obex, and currently available via our repository (code.anzhelka.com).
Datasheet Omissions
I've noticed that the datasheet is missing some critical information, which I have written below:
1. The orientation of the axes of the sensor. [NEED TO FIND OUT]
2. The sensor has no reverse polarity protection. If you connect it backwards you'll fry the board, and then it won't work.
3. You cannot power it at 3.3v (this has been updated in their most recent datasheet).
4. The checksum is calculated as the unsigned sum of all bytes from the first 's' to the last data byte.
5. Data bytes are transmitted such that D3 is received first, followed by D2, D1, and D0.
6. By default, processed xy accel, gyro, and magnemometer are transmitted; along with xy euler angles, Note that Z (yaw) is not transmitted for any of these.
7. The newest version (with GPS "support") does not use the GPS in the filter algorithms.
8. When it is working, the gyros will heat up and need to have their bias adjusted after 5-10 minutes.
9. The UM6-LT board has 2 green LEDs that should be lit when in normal operation.
10. When outputting quaternions, the UM6 outputs [a=w,b=x,c=y,d=z] where w is the scalar (from here).
Customer Service
When testing a few weeks back, I noticed that the sensor was not responding. I emailed their technical support, and through some emails we went back and forth on things to check to see what was wrong. Eventually, I was told to mail the IMU in so that they could test. Below is the complete email record from that point forward. I've removed names and salutations from the excepts.
Me (Sun, April 6):
I've posted via USPS the sensor to the address you specified. It should be there on Monday. Thank you for taking a look at it,
Me (Wednesday, April 16):
Have you received the sensor yet? It was scheduled to arrive last Monday the 9th of April.
CHR (Thursday, April 17):
Yes, we have received it but haven't yet had the opportunity to troubleshoot it. We'll have a look as quickly as possible and I'll get back to you.
Me ( Friday, May 1):
I just wanted to check on the status of the IMU, and whether you have had the chance to test it yet.
Me (Thursday, May 7):
You've had the sensor for four weeks. If you're not going to take a look at it like you said, do you think you could mail it back?
CHR (Thursday, May 7)
Please accept my apologies for the delay.
We tested your sensor near the end of last week and determined that the RX UART line on the device has been damaged, possibly due to over-voltage or ESD. Since we took so long to investigate the issue, we'll replace the damaged module at no charge. I'll see that a replacement is shipped tomorrow.
_____________________
So, in short it took them a month to respond back to me. I appreciate that they were willing to test it in the first place, but I don't think their customer service was any good. At the very least I expect a response to any emails that I send, even if it's just to say that they have not been able to test it yet.
Conclusions
Still, the CHR UM6-LT sensor is among the best value sensor that I could find. The next runner up that I'd like to try is the X-Monkey IMU. It looks to be a very nice module with all the features that we really want. I've also found an article in Circuit Cellar called "The FreeSpace IMU" which gives a complete description of a simple IMU version, along with source code (here). If we ever get around to implementing our own IMU I'll probably look into this as an alternative algorithm.
My goal with this review isn't to be unfairly harsh. The IMU hardware itself seems to work ok at this point, but the support for the product is minimal. I'll keep using it since we are committed to the module now, but unless it improves we'll look elsewhere when we next work on the IMU side of things.