Overall update from Luke

All of the known machining that had to be competed is now finally completed. Assembly of the physical frame was started on Friday, however was only short lived due to other obligations. Cody and I have spent lots of time reading up on the control algorithms that we have to familiarize ourselves with in order to keep our platform stable in the air.
I biggest technical problem is actually get our control loops to have enough speed to keep all of our physical systems in order.
Goals for next week include finish the quadcopter build. Receive all electrical parts. Possibly start populating the circuit board.

Autorouting beyond Eagle

So I have been using Eagle for quite some time, however I have never really had the need to use the auto router function due to my uncomplicated small boards. As I have been walking through this journey to get the PowerBoard completed for the quad copter I have run into lots and lots of problems. Some seen and some unseen. I would just like to focus on one of those today.
Autorouting is a neat and awesome feature because you have to do little to no work and computer does all the thinking for you, but is Eagle's Autorouter all that great? I would have to say that it is okay at best. Once you have gotten X amount of components per inch it is so bad it is nearly unusable.

Before any routing.

After Eagle's Autorouter. ~30seconds

So what else is out there? After reading through some forums I found a program called FreeRouting. After reading the Freerouting Eagle User tutorial I was stuck dead in the water. Their brd_to_dsn.ulp file did not work within Eagle 6.1, so some digging was in order. Here is a link to the file that will allow you to use FreeRouting in Eagle 6.1. This program has many benefits but at a price, computation.

Pros:

• Routes pins that Eagle gets stuck on
• Professional look
• Cross Platform
• Free

Cons:

• Not Open source
• You have to have internet access
• Runs on Java6
• Doesn't seem to be Multithreaded
• Takes much much longer than Eagle Autorouter

So is it worth all the extra computational power and time?  I believe that it is, but I will let you be the judge of that.

As of right now I have been routing the board pictured above for the last 2 hours and FreeRouting is still chumming away. I will post a picture as soon as it has completed.

UPDATE:


Just finished the auto routing in FreeRouting... if you were counting it has been about 5.5Hours, but look at the difference.

Weekly update from Luke

This week we made some more progress into our endeavor. We received our new IMU and Cody has started testing it and been writing drivers to ensure that all the data we can get can be used.
One thing that we hoped to complete last Friday was the building of the frame of the quadcopter. We had to drill some precision holes into our material to insure that everything would be nicely balanced. However, the machine shop was closed and we had do everything besides putting together the physical frame. We got all of our motors and ESCs soldered. We tested our first ESC and it broke shortly after. We tested our second ESC and everything passed with flying colors. We had the motor running for about 15 minutes continuously and everything was still working to spec.
This coming week we hope to have the frame assembled and maybe our final revision our power board done this week. Work on the control system should be in full swing.

Learning about Quaternions and Whatnot

Lot's of progress has been made over the past week, and I'm satisfied with the progress. I have been working on interfacing the CHR-UM6 IMU device. It's actually rather complex to interface to, mainly because it's a complicated device. There's approximately 50 registers or so, and numerous configuration options. In any case, I'll be writing the device driver for that. Should be lots of fun.

Luke and I also worked on assembling the frame on Friday. We got the motors up and running, and did some basic tests. Exciting stuff! Luke blogged about it, so check it out.

Finally, I also did some research into quadcopter control theory. Turns out that (no surprise) it's really complex. Quadcopters have so many different things going on concurrently, and so to control it all requires lot's of math. The best paper that I have found so far is "Design and Implementation of a Structured Flight Controller for a 6DoF Quadrotor Using Quaternions" (paper here, and html link here). This paper and the others have lot's of theory, but it appears that at the base of it all is a simple idea: your airframe is rotated to a certain orientation, and your control program has a desired orientation for the airframe. Then the program simply calculates the motor outputs necessary to rotate from the current orientation to the desired orientation, and you're flying.

Unfortunately, a quadcopter has any number of different problems. When the quadrotor is moving sideways through the air, the propeller blades "flap": the leading edge is pushed up above the plane of rotation, and the trailing edge below. When a quadrotor is moving up or down through the air, the moving airflow through the propellers creates a different amount of thrust relative to a stationary hover. In addition, each motor and blade is slightly different, so the same control input to each motor will produce a different thrust. Together, these (and more!) small things add up to make it much more difficult to control a quadrotor.

This leads to my critical question of the week: what is the basic control model of a quadcopter, and what are it's limits?

So, I'll be exploring that, along with writing as much low level driver code as I can get. I'll need to write some code to process the quaternion math: each iteration through a control loop will take an estimated ~10 quaternion multiplications. Each quaternion multiplication takes 16 multiplies and 12 adds, each of which is floating (or fixed) point. Since the Propeller doesn't have a hardware multiplier or FPU we'll have to come up with a way of working around that. The object exchange has a very nice floating point object (here) that has all the routines written for floating point. It even has timing for the function calls, from which I calculated that one quaternion multiplication will take about 1ms at 100MHz clock speed, using the provided code. But, if I modify that code and write a new object I anticipate that it will take somewhere around 0.2ms to complete a multiplication. At ~10 multiplications per control loop, it will be able to run at 500Hz.

All this took in excess of 30 hours to work on.

Next week, I'll be learning more about quaternions and quadrotor control, and I'll do some device driver programming to break up the monotony.

Soldering and Testing

Today Cody and I were hoping to be able to finally put our quad copters together, however we had one key thing that we needed to complete. Drilling holes.

We went over to the machine shop but it looked like no one was there so we decided that we would do everything else that we could do and machine things on Monday.

So we went out and picked up some Screws, Thread Lock, and Bullet connectors.

One key thing to keep in mind while building a device with lots of vibration; thread lock. Thread lock is a very cheap liquid that will help keep all of your screws where they are supposed to be. Plus it never hurts to be safe.

It took Cody a decent amount of time to solder all of the ESC's and their connectors. However we got nearly all of them done, but we ran out of connectors. Soldering the connector onto the 11.1V 5.0A 30C battery really had me concerned as far as safety. Cody managed to get this task done without arking the battery on himself. :)

I spent some time building a small motor mount so that we can test our motors and speed controls without attaching them to the quadcopter, while also allowing us to put a propeller on make sure or copter doesn't fly away.

We had tested the motor first without a propeller. The motor spun quite nicely with and without a small load. We then decided to attach our propeller. Cody disconnected the battery after disconnecting the motor and we heard a loud pop, but no ark was seen. Cody and I being spooked decided to still disconnect the battery with much more caution. Pliers and quick movements used. Once we had decided that the battery was fine and was not the problem we reconnected it to the ESC. The motor did a quick beep, but nothing happened. We tried some different tests, but we determined that the ESC had died.

Something that we expected to be plug and play, problem free, could really put a damper on the project. Always expect everything to fail and you will never be dissatisfied. X)

Tommorow I plan on tearing open the ESC to determine the failure. This will allow us to know if it was a user error or some type of internal failure.

Luke's recap of the UCSD visit

Cody and I went to University of California, San Diego Friday February 3rd. Our CS Senior Design Professor Dr. Brisk got us in contact with Dr. Kastner who has alot of research in exploration vehicles.

National Geographic and UCSD have teamed up to create broad range of robotic vehicles for exploration from the ground, sky and sea.  We meet up with Dr. Kastner's lab to see the multiple rotor copters that they working on. Tom is the main PHD student working on this part of the project.  Tom has been flying helicopters since he was a young kid and has a very good understanding on what it takes to keep something up in the air without crashing.  Tom showed us several different copters that he has worked on for the project. One thing that I have to say is that UCSD has a lot more funding than UCR. One of the newest copters that Tom was working on was a octocopter and was planned to be fitted with 8 lipo's and a DSLR rig big enough to hold an Red Epic or similar camera.

All of the copters that Tom has worked with were built and balanced from the factory.  Having a frame built and test from the manufacture themselves gives him a major advantage in getting his project off the ground.  One of the things that he had warned us about was having to constantly tweak the control systems yourself.  This can be a big time hog and set the project further back than expected.

Not only does Tom work on the control systems of the copters, but also on the wireless systems so that data can be sent and received by the vehicle.  The capability of sending HD video is a major problem within all wireless applications. Tom has worked up some code that has solved part of this problem. He takes the digital code and compresses it on a ARM 9 processor then sends that data down to a ground computer where it is decompressed and viewed.

So where do we fit in all of this?  We were able to ask a team with a lot more experience in these kind of endeavors what the challenges that we might expect and some of the approaches to overcome them.  The UCSD team thought that we were going to have lots of problems trying to be able to complete our task in such little time with so many different aspects of the project on the table. Another thing that we have not put lots of thought into was how we were going to autonomously take off and land.  Solutions include landing on an elevated object that will not cause ground air problems or using a laser/sonar ground distance sensor.  Obviously one of these solutions cost much more than the other solution.  Lastly we talked about the feasibility of completing the project and ways to take shortcuts so that we don't have to deal with mechanical problems.

Project Folder and Files Structure

Among other things, a good project has a meaningful and useful folder structure that allows easy navigation among the different files. Anzhelka is interesting in that source files not only include code for one processor, but potentially several; it has both hardware files and software files, and all the associated files are cross platform!

It's been quite a challenge to come up with something flexible yet meaningful, and not difficult to the point where we won't use it. So, the details are below. It will probably change as the project evolves, but that's ok: it can only get better.

So, what do we have?

Structure

 /hardware
    /frame
    /pcb
 /software
    /spin
       /src
       /lib
       /test
       /tool
       /config
    /java
       /src
       /lib
       /test
       /tool
       /config
 /doc
    /datasheet

Hardware
Subfolders will store the major components of the project. For example, the frame has several .dxf files that are sent to the laser cutter, so that will all go into a subfolder called frame. The project may have several PCBs made as well, and so each should go into a subfolder under pcb.


Software
The software is separated by language into separate folders. This makes sense because each processor in the project will have only one language running, but separate processors that are running the same language may share components (library files, for example). Each language has a number of subfolders:

• src is where the source code for the project is stored. Subfolders as appropriate.
• lib stores all general purpose library files (code) such as Propeller Obex objects.
• test stores the test harnesses such as unit tests and Spin code to test a particular module (the latter case would have a 'main' type method and would be self supporting when running on the Propeller).
• tool holds all the relevant development tools for that language (bstc for Spin, for example).
• config stores any sort of relevant compile time or testing configuration files.

Documentation
This folder stores all the relevant datasheets in the datasheet subdirectory, and any other project documentation that is deemed to fit. Note that most documentation probably belongs in the anzhelka wiki.


Note: all this information will be kept updated on the project wiki on this page.

Progress: A Report by Cody

Over this week I began working deciphering the chip that we are planning to use for our inertial measurement unit, the MPU-6050, and I reached an unfortunate conclusion: it won't work for us. Not because the chip doesn't do what it's supposed to. It seems like it will do a very good job of filtering, and it will even rotate the acceleration into a real world orientation frame. The downside is that it's incredibly complicated to interface to, and all the filtering information hasn't been released by the manufacturer yet. It's been over a year since they first introduced this chip, and they still haven't released the relevant information. So, we are going to bite the bullet and try a new system: the CHR-UM6-LT orientation sensor sold by Pololu. This sensor is quite expensive ($150 OEM version), but it has some nice features: quaternion and Euler angle output, a serial interface, and 1000 Hz update rate. In addition, the extended Kalman filter code that does the onboard processing is open source, so we can make modifications if needed.

Last Friday Luke and I visited some students of Dr. Kastner down at UCSD. First off, we visited the fixed wing lab and met Tim Wheeler and Lewis Anderson on the AUVSI team. They are doing some very nice work with their airplane, and it was nice talking with them and learning about how supportive UCSD is of their work. Later, we visited the Do-It-All grad student, Tom Wypych. Luke and I were mostly interested in Tom's work on the multicopters (as part of the UCSD NGS program), but Tom has experience all over the board and gave us lots of useful tips and pointers.

Thanks to Dr. Brisk for getting us in contact with Dr. Kastner, and thanks to Dr. Kastner for being so gracious to share with us his labs. And thanks to the Tom, Tim, and Lewis for sharing their work with us. It is much appreciated.

Over the last week I have worked on the meta organization of the project, I have worked on the MPU software, and we went down to UCSD which, all told, is about 30 hours or so. It's been a bit slow getting up and running, but now we have the routine down and we expect to be able to pick up the speed. In the next week or so I expect to get most of the peripheral code up and running, and added to specific branches of the repository before I merge it back into the main branch.