The AirDragon Project (WIP)

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:



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 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.




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.

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –


  • Well, I've been quite for the past couple of months, and I thought it would be a good idea to keep people posted.

    The original software I hashed together had finally given up by the end of November, and couldn't be revived at all. I had then undergone the process of actually designing a new software from scratch, this time using top-down methodologies instead of the typical experimenter's bottom-up approach (where you focus on the details of every little thing).

    I had successfully mapped out my new software design, and the next hurdle to jump was of course to start coding everything. I decided to try to go with C++ this time, since some things, especially PID controllers and sensors, could be instanced multiple times for different jobs. Along the way, I had also determined that an RTOS was a must now. Even though the control loops could be maintained as a traditional single-threaded program, I determined that the best way to future-proof the software design was to make it operable with a multi-threaded operating system... since you could dedicate an individual thread to different sensors and fusion algorithms as well as independantly adjust their operating speed without adjusting the speeds of other threads, like the attitude and heading controller.

    Well, I graduated! Suffice to say I'm still working on getting this puppy ready for its first untethered flight, and the current hurdle now is to convert my C++ files into C files... since the only compiler I have for it can't go past 1KB (My fixed-point class definition alone takes up 1.5KB!!) I am still going along with my software plans, but I'm still tackling the language barrier.

  • I've determined that the reason the quad would go unstable after awhile was due to the FLC's universe being too narrow. Whenever the quad's angle would go outside +-10 degrees, the error compensator could not respond fast enough and outputs what I call the triangle-wave of death.


    The triangle-wave of death, instead of reducing oscillations, actually drives them to even more uncontrollable angles.


    Fun stuff.


  • Ok, managed to crack the serial communications and got a nice data spew from the FDR (flight data recorder) over to a PC running hyperterminal. Currently I'm limited to maybe 16KB of data storage because I'm only using the RAM on the chip, will have to research how to save it onto the flash memory.


    The Current control algorithm is... well, it "acts" like its stabelizing the craft, but after several test runs it was clear that it's not doing the job. I've done more research on PID's, and I've come up with an algorithm that should work, but after a few test runs through MATLAB I'm a bit worried about the I term blowing up on me (since its discretely realized in the program).


    Mentioning MATLAB, the model I have of the craft is perhaps oversimplified, as it makes quite a few assumptions that ignore the effects of the moment of inertia and air drag. It does however account a bit for wind disturbances.


    Lastly, this is perhaps the third or fourth time I've reorganized the code for style and placement. This will hopefully be the second to the last, as I'm planning on the language migration to C++ in the future.

This reply was deleted.


DIY Robocars via Twitter
RT @chr1sa: You can see this in person in two weeks for our next live event with real cars. It's great fun for adults and kids alike, and…
DIY Robocars via Twitter
RT @chr1sa: The final race (1:24) at yesterday's @DIYRobcars virtual event was our best. It's only two minutes long but it has everything,…
DIY Robocars via Twitter
RT @chr1sa: The monthly @diyrobocars virtual race is starting now!
Mike Whitney liked Mike Whitney's profile
Jul 19
DIY Robocars via Twitter
Jul 2
DIY Robocars via Twitter
Jun 26
Abdulatif Tlaib liked Ryan's profile
Jun 24
DIY Robocars via Twitter
RT @SmallpixelCar: First time at @wsraceways. After tuning @HokuyoUsa lidar signal and camera sensor on @NVIDIAEmbedded, my car was able to…
Jun 20
DIY Robocars via Twitter
RT @breadcentric: The handy bit about racing with self-driving cars is that one can type while the car is racing. Report from #AWSDeepRacer…
Jun 18
DIY Robocars via Twitter
RT @chr1sa: Our Bay Area @DIYRobocars meetup is now at 2,700 members. Next in-person events (in Oakland) are training day on July 17 and…
Jun 18
DIY Robocars via Twitter
Videos from the ICRA autonomous racing workshop are now available:
Jun 10
DIY Robocars via Twitter
RT @SmallpixelCar: Prepared race track for Warm Spring Raceways @wsraceways and looking forward to test my new car at RAMS RC @ramsaicar fa…
Jun 6
DIY Robocars via Twitter
RT @f1tenth: Trying out some nasty blocking maneuvers 🏎️🤖 #f1tenth #autonomousracing
Jun 5
DIY Robocars via Twitter
May 27
DIY Robocars via Twitter
RT @araffin2: I will talk this Saturday from 18:00 to 19:00 Paris time for the @diyrobocars community about learning to race in hours using…
May 27
DIY Robocars via Twitter
RT @a1k0n: Luckily the infeasible hairpin problem was easily reproducible in simulation and I could test the fix before bringing the car ba…
May 26