Cody's Update

We have been very busy over the last few weeks as we work hard towards getting the quadrotor flying before the end of the quarter. I've been working mostly on the software, including, in no particular order:

- PID control
- Math equation to assembly compiler
- UM6 IMU integration
- Memory management

So far, our software is getting very close to completion for the first testing phase. We have all of the software components up and tested, and now I need to integrate them into a single program that works end to end. Our first testing will be on the roll pitch test stand, pictured above.

This stand will allow us to test the software without worrying about crashing and damaging the quadrotor. It allows the quadrotor to spin freely on a single axis. With this, we can tune the flying parameters and, hopefully, be able to go to stable flight once we figure out all of the different parameters here.

There is still some work to be done before stable flight, namely:

- Altitude sensor integration
- PID parameter tuning
- Altitude testing

I'm very optimistic, and am working hard to fly before our presentation in about a week.

Presentation Countdown

We have been answering lots of questions about our quadrotor, and most of them are "When will it be flying?" I'm here to tell you when: by our presentation! When is that? Well, it's not too far away:

UM6-LT IMU

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.

Writing PASM Code Update

Luke and I have been working very hard on the project. Over the past week I have been working on writting the CHR-UM6-LT IMU interface object, and it's been going ok. Check out the post on that topic for more information.

I've put in the whole weekend, plus time during the week for about a total of 40 hours in the past week. The main challenge in the past week was (re)learning all of the Propeller assembly that I've forgotten. The last time that I have programmed in PASM was during the summer of 2009, when I wrote some driver objects for the USB Memory Stick Datalogger and NMEA GPSs (link). Those objects share many of the same characteristics as the current work: streams of serial data, automatic parsing, and data control in the hub.

In the next week I'll delve more into the assembly, and hopefully get the UM6 object finished and the assembly code for flight up and running. I've relearned many of the tips and tricks of assembly programming, so it shouldn't be too much work getting everything else done.

In the meantime, here is a picture of Luke and I presenting our project at the Parallax Expo 2012 in Rocklin, CA.

Thrust/torque test video

We have our first video! Exciting times. Our thrust/torque test stand is still incomplete, but we are getting closer. All we need to do now is calibrate the darn thing and then we are done. Be sure to watch the video in HD: http://www.youtube.com/watch_popup?v=viVVwRabck4