Discussions

Hello all,

As some of you may already know, my pet project for the past couple of months has been what I call the AirDragon, a quadrotor UAV that will eventually be a fully automous robot.

The original specifications for the senior design called for a "autonoumous UAV that could move about a room-sized work area by using any available sensors." I originally was not too interested in this design project, until a classmate of mine decided to try and build a quadrotor in place of the blimp that had been used before.

So, here I am now with a semi-functional system that I had pretty much built the code entirely byself, considering that I haven't even heard of a quadrotor until perhaps a week or two before the time came to choose the design project! I have learned quite a bit about embedded systems since the start of the year,  but I'm afraid the goings have been quite slow and tedious.

So, introductions aside, I shall present to you the AirDragon project in three sections: hardware, operating system, and attitude controller/compensator:

Hardware:

Propellers : 10 x 4.7in APC, Slow-Flyer Electric

  These where originally chosen to provide an ample amount of thrust, which equations at the time assumed that you could predict the maximum height of the craft by using an kinetic and potential energy anylsis of the mass of induced air vs. the mass of the craft. So far I haven't been able to get proof if the equations where correct, but the 4.7 pitch ended up being a smart choice for tethered flight testing because the craft can tilt very easily.

Motors  : 150W, 13 Pole, 1000Kv, BP A2212-13 BLDC Outrunner

  To be quite honest, during the first few months we had no idea on what motor to get, becuase we didn't have a good enough idea of what the final weight of the craft would be. The design had a 1Kg weight limit, so we went "worse case" and ended up going with these guys... mainly because they had a good price tag and "seemed" to be adequate for our craft.

Battery : 2200mAh, 11.1V, E-flite LiPo

  As with the motor, we didn't know what battery to get. We originally went with some lighter 1000mAh or 2000mAh (I forget which), but ended up killing them because one of us forgot to check if it was charged. (...they know who they are...)

  The E-flite batteries turned out to be much more reliant and slightly heavier. In fact, these babies are perhaps the heaviest component on all of the quad! I've currently got one of the quads hooked up to the test rig with two of them on there, to ensure that it won't fly off and provide some extra time for attitude compensator testing.

ESC's :18A Auto-Ranging ESC's from BP

  We didn't know better, and pretty much went cheap on these guys. They provide basic functionality of the motors, but don't have the feature of retaining the input signal range (they retain the LiPo auto-shutoff setting and the "brake mode" however.) On the plus side, since they are Auto-ranging, I have been able to run them on a 430Hz frame rate. They currently run at a lesser 400Hz for noise safety.

Microcontroller : MC9S12DG256

  For both of our quadrotors, we're using the Freescale (formerly Motorola) MC9S12 chip soldered onto the MiniDragon and MicroDragon development boards made by EVBplus.com. We chose to go with this since our EEEN courses required us to buy a MiniDragon for a couple of classes, the MicroDragon was later used to shed some of the weight and unused goodies that the MiniDragon had permanetly soldered onto it, as well as allow a different method of voltage regulation. Originally, I had tried programming the entire thing in assembler (BIG mistake), and couldn't figure out a good way to come up with a PID routine. I had stumbled across some commands previously unknown to me, that turned out to be opcodes for performing the built-in 8-bit fuzzy logic microprograms. It from here on that the attitude compensators where to be built using fuzzy logic algorithms. Luckily during the summer I was able to get ahold of a C compiler, and have since then built the entire operating system and compensator routines.

Operating System:

The operating system is a rather simple one that more or less just schedules when the attitude compensators will be run. This is still currently under development along with the attitude compensators, as its still unkown to what all I'll end up adding to it.

  As mentioned before, the operating system is mostly coded in C99. The compiler we're using, CodeWarrior SE 5.9.0, allows for a mixed language project which so far has been handy when using the built-in fuzzy logic commands. It is unfortunately a garbeled mess, so there are plans to migrate over to C++ to take advantage its classes and other OOP features.

Future Enhancements:

Currently a flight recorder or blackbox is being included into the operating system. Also, a wireless telemetry subsystem using the Xbee's is being developed, so that the data from the blackbox can be sent to a monitoring PC (and so that we can get some lab data). Currently this will not be real-time, because I haven't figured out a good way to handle the serial communications while the compensators are running.

  I planning on possibly moving the communications to a separate MCU, kind of like the Pilot & Navigator/Comms Officer combination in fighter helicopters. The navigator will tell the pilot where to go (X, Y, Z, and heading), and the pilot manipulates the craft to get there. This also allows the pilot MCU to focus on the attitude controllers while the navigator MCU is sending data over the Xbee.

  Special Note: I am aware that all UAV's must have some sort of manual takeover feature in the event the waypoint following goes wrong... so after I get some data from the pitch and roll tests I'll look into getting the R/C equipment up and running.

Attitude Controller / Compensator:

  The heart of any quadrotor program, the Attitude controller/compensator currently uses fuzzy logic algorithms to control the angle of the craft's pitch (and later yaw and roll) as well as dampening the rate that the craft turns to managable levels.

  It does this by running two parrallel fuzzy controllers, one for the angle, and one for the angular velocity. The angle controller has a post accumulator on it, which acts simular to an integrator but disregards time. This was done so that the resulting output would hold its level if the output of the controller was 0. It works very well for steadily achieving the desired angle, but cannot account for any fast angular rates, which is where the other controller comes in.

  The angular rate compensator is another fuzzy logic controller, but without the post accumulation. Future testing will determine the effectiveness of an accumulator, but for now it seems to be working well against the unintended wind currents (A.C. and the wind generated by the quad itself) in the lab.

Future Enhancements:

Once the Pitch and Roll angles have been tuned to work at the same time, additional controllers will be made for the Yaw, and ultimately the X, Y, and Z positions. It's likely they'll also be fuzzy controllers, but a key point I've been trying to shoot for is a modular compensator feature... so that practically any algorithm may be used.

Personell:

Lead Developer, Coder, "Everything Guy" -- Allen Babb

Senior Design Partner who suggested to do a Quad -- Noe Cantu

Summer Camp Participant who helped with fuzzy logic control design -- Yan Xu

Mentoring Professor -- Muhitten Yilmaz

Special thanks to everyone who let me use the TAMUK robotics lab during the Summer!

Closing Comments:

I have a couple of photos already, and I'll see if I can upload them here over the next few weeks.