Increasing Code Efficiency

After we completed our first full version of code we spent several days in the lab trying to fine tune our PID terms. After a lot of frustration, we decided to take a look at the quadrotors in Penn's GRASP lab as a comparison. After feeling their PID response, it was painfully obvious that our response time was not nearly as fast as we thought it was. The GRASP lab units run their full PID loop at 1000 Hz. We thought that we were running our PID loop somewhere around 40 Hz, and, being a little naive, we thought this would be adequate. After all, we can't see that fast!

In order to increase our code efficiency we did several things. First, we increased the UART baud rate from the IMU to the MaEvArM from 38,400 to 250,000. This allowed us to read in angle and gyro values faster so the PID functions didn't hang up waiting for information. Second, we changed some while loop codes in the UART receiving functions to brute force assignments. This had an amazing effect, changing our 40 Hz response to 120 Hz! Of course, this was not nearly as fast as the response in the GRASP lab, but, having read reports of successful PID loops as low as 70 Hz, we thought we'd give the new code a try.

The difference was incredibly clear; the derivative terms were much more responsive, and our morale was much improved after fruitlessly toying at PID gains for so many days.

After this, we constantly checked the frequency of our PID loop after adding any new considerable block of code. Also, the bottleneck for increasing our code speed was determined to be the output of the IMU. Running the DCM and correction algorithms produced a max speed of 120 Hz. One possible method to increase this (without changes in code) would be to replace the 8 MHz oscillator on the Razor IMU with a 16 MHz or even a 20 MHz oscillator. The Atmega328p is able to handle these clock speeds, and increasing to them would result in large improvements in the data output speed.

Wireless, PID Controls, new Props, and First Motor Spin-up

We have completed and started several things since the last post. First of all, we have fairly robust RF communication between two MaEvArMs. This allows us to send motor commands to a Wyvern unit and to receive telemetry data back from the unit. As we continue to tweak our PID controls, this will also allow us to change our gains without reprogramming the unit. We have finished writing the majority of the PID control code, but the road to a stable, hovering quadrotor will undoubtedly present us with more challenges than we foresee.

After all of our soldering and wiring we re-massed our unit at about 695 grams. After landing gear we expect to be just slightly above this. This would give a new flight time of about 12.5 minutes with the tri-blade props that were tested in previous posts. However, since then we have ordered new tri-blade 8x4 props that have characteristics similar to the two-blade props tested earlier. In fact, they seem to match the two-blade props at lower RPMs and even outperform them at higher RPMs.

The first motor spin-up was very successful. We were able to achieve a thrust that we determined to be adequate for hovering (determined by holding the body lightly and seeing if it would lift). Knowing that all of our mechanical parts were in order, we were able to turn our full attention to developing the rest of the code.

Below are some videos of test flights before our PID code was optimized.

Mechanical Design

Design Considerations:

We went into the design process with the goal of creating a simplistic, low-cost, robust, and manufacturable quadrotor platform. The general design consists of three major components, the motor nodes, the support rods, and the central node. It was essential that the design be reconfigurable, thus a multiple node schematic was followed which allowed for an extent of modularity that enables us to potentially adapt the quadrotor to multiple roles. With this in mind, no part of the quadrotor is glued together (.....yet, as we have not found any significant structural issues, though it is possible that the high frequency vibrations induced by the motor/rotor might reveal a need for gluing). Additionally, we have attempted to utilize electrical connectors over soldering, at a slight weight cost.

Below are photos of our SolidWorks model and of the design process. In the SolidWorks model the rotors are represented as clear cylinders.

SolidWorks-Looking down and Iso views:

As referenced above; A, B and C represent a motor node, the support rods, and the central node respectively. One might note that the central node consists of two layers; this facilitates component placement. Following images will show the configuration of components.




Materials:

With regards to materials, the motor nodes and central node are cut out of 1/8 [in] Acrylonitrile Butadiene Styrene (ABS), while the support rods are 3/8 [in] hollow aluminium. Additionally, a number of 3[mm] steel screws are used for fixing the motor nodes and central nodes to the rods, and for fixing the motors and boards to the nodes. We felt that the aforementioned materials allowed for rapid assembly while maintaining a reasonable overall weight. This was confirmed by our overall frame mass which was about 130 grams. Improvements in the use of materials will be noted in the 'comments' section.

Assembly:

Assembly proved quite rapid and easy. A few iterations for finding the optimal hole sizing for the node->rod interface were necessary, but meticulous modeling ensured that the majority of our parts fit well. It was apparent that the rods would have to overlap in some way, which we solved by crimping the rods at intersection points. Holding the nodes in place was accomplished through the use of screws that pressed down on the rods, providing a surprisingly robust fix. If one watches carefully during the thrust testing video they will see a nut fall off of a screw, while this was not an issue during the test since each screw had an additional redundant nut, we decided to eliminate such uncertainty in our quadrotor by tapping the ABS. The ABS to screw friction combined with the dampening that the ABS provides should keep the screws from rotating during operation.

A motor attached to a motor node:

Close up of the Center Node:

Central Node Configuration:

The slots in the central node house the ESCs for our brushless motors (A2208-14). Wires from the ESCs are routed through the openings at the top of the node through those between the rods out to the motors. The battery is placed on the bottom of the central node, and the 'ping' sensor (our current altimeter, at least until we get our barometer output working properly) will be placed under the node as well. Our Control, IMU, and wireless boards are configured to be placed between the ESCs on the top of the central node.

The Frame with ESCs, Battery, and Motors incorporated:

Central Node with ESCs, Battery, Control Board:

Comments:

We believe that the current frame will prove sufficient for our purposes. It is light, sturdy, easy to construct, and capable of housing the components we require, yet we feel that when we have more time improvements are possible. Wiring up the quadrotor has made us realize that more consideration of wire routing might prove beneficial during the modeling process. Moreover, our nodes seem more robust than necessary and we could probably stay within our design goal of robustness while reducing mass of material used. In the future, use of carbon fiber tubing and sheets, and perhaps even thermoplastics might allow for an equally functional structure that is lighter and more aesthetically pleasing.

Overall though, considering that we designed and assembled the quadrotor over a weekend and accomplished the majority of the wiring in a day (some wiring was on hold while we waited for the appropriate connectors), we are quite happy with our results. And we must admit, this is one cool looking quadrotor.