Check out our new website www.airhacks.org, where we will be documenting the development of our new Quadrotor Platform - R.A.V.E.N.!
Saturday, October 9, 2010
New Website!
Check out our new website www.airhacks.org, where we will be documenting the development of our new Quadrotor Platform - R.A.V.E.N.!
Sunday, September 19, 2010
Final Cost
There has been high demand for a final pricing of the components used to build the Wyvern quadrotor. The following represents the final cost to the best of our knowledge:
| Item | Quantity | $/ea | $(tot) |
| 30 A ESC | 4 | 14.99 | 59.96 |
| Brushless Motors | 4 | 11.99 | 47.96 |
| IMU | 1 | 125.00 | 125.00 |
| Microcontroller | 2 | 20.00 | 40.00 |
| Battery | 1 | 16.95 | 16.95 |
| 2-blade props | 2(x2) | 7.59 | 15.18 |
| Bullet Connectors | 4 | 2.49 | 9.96 |
| Deans Connector | 1 | 6.5 | 6.5 |
| Deans Couplers | 1 | 3.95 | 3.95 |
| Aluminum Rods | 3 | 6.03 | 18.09 |
| RF Boards | 2 | 19.95 | 39.90 |
| Joystick | 2 | 3.95 | 7.90 |
| Joystick breakout board | 2 | 1.95 | 3.90 |
| Project Total: | 420.34 | ||
Thursday, May 13, 2010
Death of a Quadrotor
We have been experiencing more and more problems with the hollow aluminum support rods warping after some stress. After a fellow colleague convinced us to fly our unit with no angle controls and only thrust, we found out just how fragile our unit was. We managed to stabilize fairly well, but of course the unit was unable to correct for drift. The Wyvern hit a wall and slammed into the hard wood floor beneath. After bending the motors back we tried to fly it again. Unfortunately, we did not take enough care in fixing the arms, because the quadrotor flew even harder into the wall and spiraled to a crumpled death. The videos are below.
Update: We have replaced the broken arm. New photos are soon to come.
First Fall:
Second Fall:
Update: We have replaced the broken arm. New photos are soon to come.
First Fall:
Second Fall:
Thursday, April 29, 2010
Maiden Flight
After many frustrating nights of tuning our PID and a total of about 1.5 months of hard work, we decided to try our quadrotor.
We weren't completely happy with our PID terms, but we knew that we would only really be able to see how our unit responded while flying in air. We found a nice open area in the engineering building and set up camp. Our very first flight was a little rough but very promising! We could see that one derivative term was a little high on the pitch side, so we tuned that down a little and we could fly! We still have a huge amount of PID tuning to do, but this becomes worlds easier now that we can see our quadrotor actually flying. We broke some rotors on some rough landings, but nothing too serious. New landing gear helped us avoid too much damage.
This was a fantastic night. We took several videos of more than a minute of flight, and even then we only stopped flying because somebody had opened a door and a draft was flowing through the room that our sloppy PID couldn't handle well enough.
Finally, a good flight!
We weren't completely happy with our PID terms, but we knew that we would only really be able to see how our unit responded while flying in air. We found a nice open area in the engineering building and set up camp. Our very first flight was a little rough but very promising! We could see that one derivative term was a little high on the pitch side, so we tuned that down a little and we could fly! We still have a huge amount of PID tuning to do, but this becomes worlds easier now that we can see our quadrotor actually flying. We broke some rotors on some rough landings, but nothing too serious. New landing gear helped us avoid too much damage.
This was a fantastic night. We took several videos of more than a minute of flight, and even then we only stopped flying because somebody had opened a door and a draft was flowing through the room that our sloppy PID couldn't handle well enough.
Finally, a good flight!
Casualties
Casualties of the Wyvern Quadrotor Project:
- 1 Brushless Motor: We aren't actually quite sure what happened to this motor. After one of our test launches to see if the quadrotor could get off the ground successfully, we were delighted to see it rise up and clear the box take-off pad. However, we were then horrified to watch it plummet with great velocity into a lab bench. This also bent up our aluminum frame in a way that it may never forget.
- 1 tri-blade prop and 3 (so far) dual-blade props: The tri-blade prop was lost at the same time as the brushless motor above. The dual-blade props were all due to our first day of flights with the landing resulting in the quadrotor flipping over. While flipping, the props (much stiffer than the three blade props) scraped against the hard floor and chipped.
- First attempt at landing gear. This consisted of 4 standoffs screwed in perpendicular to the ground. This didn't last long with Paul behind the controls.
- "Nubbins": These are the small ABS plastic pieces that are glued into the motor supports so that screws can be used to hold the motor tightly to the aluminum support rods. These things fly everywhere!
Tuesday, April 27, 2010
IMU Errors
After almost two weeks of attempting to tune our PID controls, we found an odd occurrence. While at low RPMs, the IMU would output correct data for both Euler angles as well as rotational velocities. However, when we increased the speed of the motors to see how the PID controls reacted with higher RPMs, the IMU began to think that it was a consistent 3 degrees from horizontal while it was actually held flat. In addition to this offset, the data for the Euler angles (Pitch and Roll) as well as their respective angular velocities would vary greatly (about +/- 20 degrees for Euler angles and about +/- 200 degrees/sec for the angular velocities).
This was far from usable. These results would cause the quadrotor to move quickly in one direction without correction while also becoming wildly unstable. Hoping that it was a purely mechanical problem since the code on the IMU (Open-Source Razor AHRS code) uses high-level Direction Cosine Matrix (DCM) and normalization algorithms that are already tuned to the IMU characteristics, we started with two possible culprits: vibrations and electro-magnetic interference (EMI).
Our first idea was to try reducing the vibrations that the IMU experienced while the motors were running. The screws that were holding the IMU in place on top of nylon spacers were removed and small pieces of foam tape were placed in-between to act as dampening washers. These did not help, as the noise was still present in the output to the MaEvArM.
Our next idea was to replace the screws holding the IMU onto the nylon spacers with rubber bands placed in an "X" with the foam tape pieces in between. This actually helped at slightly reducing the errors we were seeing in the angular velocity as well as decrease the magnitude of the noise in the Euler angles. However, we were still seeing the 3 degree offset at higher RPMs.
After trying a couple vibration-reduction methods with small improvements in the IMU output, the possibility of EMI was addressed. Since the IMU was being placed close to the outputs of the ESCs (which had cables that changed direction quickly and carried high currents), it was thought that this could be causing some error in the IMU when the motors were run at higher currents/speeds. (Although moving a magnet near the IMU did not seem to have any effect, we tried this solution anyway). Using conductive tape, each of the wire groups output from the ESCs were covered and then grounded. This produced no visible effects in our tests. Noise and offset were still present.
Next, the idea that the rotors were causing too much vibration was addressed. When we visited the GRASP laboratory, we were able to inspect their quadrotors (which they purchased) and see them in action. One noticeable difference we saw was that the motors on the GRASP lab quadrotors cause little to almost no vibration. With this in mind we attempted to remount our rotors to try and balance them. This was not very effective with the tri-blade rotors for some reason (possibly since they are of lesser quality). When we switched to the dual-blade rotors, we saw a significant improvement in the amount of vibration. In addition, the noise produced by the rotors greatly decreased. We were surprised at this, since when we did our research we read that the tri-blade props were supposed to be quieter and produce less vibrations. Although this change did result in less noise, the errors in the data output from the IMU were still enough to prevent our controls from working effectively at speeds high enough to fly.
Our last idea before we attempted a software correction for this data error was to move the IMU to a new position and use a better dampening material. The IMU was swapped with the MaEvArM, which placed it directly onto the frame instead of on nylon spacers. To absorb vibrations, a square of open-cell foam was placed in between the frame and the IMU. The MaEvArM was then mounted on top of the nylon spacers (this actually helped a lot since the Load/Run swich and reset button on the MaEvArM were difficult to reach before). When the motors were spun up to speed, the IMU output was almost perfect (although there were small errors, these were less than a degree and would not prevent us from flying). The nylon spacers were believed to be amplifying the vibrations since they were not completely rigid (they were able to flex).
In the end, we determined that the vibrations caused from the motors spinning at high speeds induced large errors in the IMU readings. By moving the IMU to a location directly on the frame, using a better insulating material, and switching to the dual-blade props we were able to solve the errors and allow for further flight operations.
This was far from usable. These results would cause the quadrotor to move quickly in one direction without correction while also becoming wildly unstable. Hoping that it was a purely mechanical problem since the code on the IMU (Open-Source Razor AHRS code) uses high-level Direction Cosine Matrix (DCM) and normalization algorithms that are already tuned to the IMU characteristics, we started with two possible culprits: vibrations and electro-magnetic interference (EMI).
Our first idea was to try reducing the vibrations that the IMU experienced while the motors were running. The screws that were holding the IMU in place on top of nylon spacers were removed and small pieces of foam tape were placed in-between to act as dampening washers. These did not help, as the noise was still present in the output to the MaEvArM.
Our next idea was to replace the screws holding the IMU onto the nylon spacers with rubber bands placed in an "X" with the foam tape pieces in between. This actually helped at slightly reducing the errors we were seeing in the angular velocity as well as decrease the magnitude of the noise in the Euler angles. However, we were still seeing the 3 degree offset at higher RPMs.
After trying a couple vibration-reduction methods with small improvements in the IMU output, the possibility of EMI was addressed. Since the IMU was being placed close to the outputs of the ESCs (which had cables that changed direction quickly and carried high currents), it was thought that this could be causing some error in the IMU when the motors were run at higher currents/speeds. (Although moving a magnet near the IMU did not seem to have any effect, we tried this solution anyway). Using conductive tape, each of the wire groups output from the ESCs were covered and then grounded. This produced no visible effects in our tests. Noise and offset were still present.
Next, the idea that the rotors were causing too much vibration was addressed. When we visited the GRASP laboratory, we were able to inspect their quadrotors (which they purchased) and see them in action. One noticeable difference we saw was that the motors on the GRASP lab quadrotors cause little to almost no vibration. With this in mind we attempted to remount our rotors to try and balance them. This was not very effective with the tri-blade rotors for some reason (possibly since they are of lesser quality). When we switched to the dual-blade rotors, we saw a significant improvement in the amount of vibration. In addition, the noise produced by the rotors greatly decreased. We were surprised at this, since when we did our research we read that the tri-blade props were supposed to be quieter and produce less vibrations. Although this change did result in less noise, the errors in the data output from the IMU were still enough to prevent our controls from working effectively at speeds high enough to fly.
Our last idea before we attempted a software correction for this data error was to move the IMU to a new position and use a better dampening material. The IMU was swapped with the MaEvArM, which placed it directly onto the frame instead of on nylon spacers. To absorb vibrations, a square of open-cell foam was placed in between the frame and the IMU. The MaEvArM was then mounted on top of the nylon spacers (this actually helped a lot since the Load/Run swich and reset button on the MaEvArM were difficult to reach before). When the motors were spun up to speed, the IMU output was almost perfect (although there were small errors, these were less than a degree and would not prevent us from flying). The nylon spacers were believed to be amplifying the vibrations since they were not completely rigid (they were able to flex).
In the end, we determined that the vibrations caused from the motors spinning at high speeds induced large errors in the IMU readings. By moving the IMU to a location directly on the frame, using a better insulating material, and switching to the dual-blade props we were able to solve the errors and allow for further flight operations.
Monday, April 26, 2010
The Controller
Until this point we controlled our quadrotor with keyboard input from a computer transmitted with our RF board from SparkFun. It was somewhat naive of us to try to even fly without controls for yaw, pitch, roll, and thrust. Finally we incorporated 2 joysticks from SparkFun on our wireless transmitter to allow us to control Thrust/Yaw with the left stick and Pitch/Roll with the right stick. We also added 4 LEDs (red, green, yellow, and blue) to our controller to indicate different statuses.
The inputs from the controller ranged from 0 to 5V and therefore from 0 to 1023 when using our 10 bit ADC on the ATMega32u4. This corresponded to +/- 512 resolution for yaw, pitch, and roll, and +512 resolution for thrust (ignoring negative thrust inputs). This was scaled appropriately to give smoother PWM responses. The idle thrust was also increased from, on a scale from 1000 to 2000, 1106 (our very lowest idle PWM) to 1200 in order to give us more resolution in controlling the thrust. Note that hovering is around 1300.
In the future we will add buttons to the controller for start and emergency stop. As of now we still have to press 's' on the PC connected to the controller and SPACEBAR for emergency stop.
Update:
We have now added battery voltage ADC to the wyvern code. The battery voltage is sent back in Volts*10 every 6 seconds to the controller. If the voltage is below 10V, all LEDs on the controller will toggle on and off to warn the user of a low battery.
The inputs from the controller ranged from 0 to 5V and therefore from 0 to 1023 when using our 10 bit ADC on the ATMega32u4. This corresponded to +/- 512 resolution for yaw, pitch, and roll, and +512 resolution for thrust (ignoring negative thrust inputs). This was scaled appropriately to give smoother PWM responses. The idle thrust was also increased from, on a scale from 1000 to 2000, 1106 (our very lowest idle PWM) to 1200 in order to give us more resolution in controlling the thrust. Note that hovering is around 1300.
In the future we will add buttons to the controller for start and emergency stop. As of now we still have to press 's' on the PC connected to the controller and SPACEBAR for emergency stop.
Update:
We have now added battery voltage ADC to the wyvern code. The battery voltage is sent back in Volts*10 every 6 seconds to the controller. If the voltage is below 10V, all LEDs on the controller will toggle on and off to warn the user of a low battery.
Thursday, April 22, 2010
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.
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.
Saturday, April 17, 2010
IMU Data Transfer Corruptions
While receiving data from the IMU over the serial connection, a strange event was happening. Every once in a while (approximately every 20 data transmissions when we printed the data over serial to the computer) a large jump in the data would occur. These "hiccups" produced VERY bad responses. While attempting to work with our PID controls, the quadrotor would be smooth and then violently respond to the data (for instance, the pitch would read 0 and then jump to -1400).
After disabling subsections of our code one-by-one, the culprit was found. It was determined that the wireless transmission from the controller was causing our data from the IMU to be sporadically corrupted. These errors in the data were large enough to throw our quadrotor into an unstable state. Our solution to this problem was to disable the wireless receive interrupt (the pin-change interrupt that indicates there is data to be read) while reading the IMU data over serial. This allowed the data to be loaded in its entirety before the wireless was read, thus preventing corruption in our IMU data.
After disabling subsections of our code one-by-one, the culprit was found. It was determined that the wireless transmission from the controller was causing our data from the IMU to be sporadically corrupted. These errors in the data were large enough to throw our quadrotor into an unstable state. Our solution to this problem was to disable the wireless receive interrupt (the pin-change interrupt that indicates there is data to be read) while reading the IMU data over serial. This allowed the data to be loaded in its entirety before the wireless was read, thus preventing corruption in our IMU data.
Thursday, April 15, 2010
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.
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.
Wednesday, April 14, 2010
Battery and Charger
So our batteries are in ready to be charged. After some research to determine which characteristics (weight, Amp-hours, output current) would affect us the most, we decided to go with 3-cell (11.1V) Lithium Polymer (LiPo) batteries rated for 2200 mAh and 25C. This means that the battery can provide 50 Amps of continuous current (as well as hit peaks of up to 100 Amps!!!).
Blue LiPo 3-Cell 2200mAh 3S1P 11.1V 25C Battery
To charge the batteries, we chose a high-end LiPo battery charger with on-board balancer. Balancing the LiPo cells equalizes the voltage and results in both longer run-time as well as battery life. The Thunder AC6 battery charger is able to handle several types of batteries (LiPo, LiIon, LiFe, NiCd, and NiMH) as well as 1 to 6 cells. The charger can charge from 0.1 to 5 Amps and discharge (to give a fresh charge to a battery) from 0.1 to 1 Amp.
Thunder AC6 Battery Charger
Blue LiPo 3-Cell 2200mAh 3S1P 11.1V 25C Battery
To charge the batteries, we chose a high-end LiPo battery charger with on-board balancer. Balancing the LiPo cells equalizes the voltage and results in both longer run-time as well as battery life. The Thunder AC6 battery charger is able to handle several types of batteries (LiPo, LiIon, LiFe, NiCd, and NiMH) as well as 1 to 6 cells. The charger can charge from 0.1 to 5 Amps and discharge (to give a fresh charge to a battery) from 0.1 to 1 Amp.
Thunder AC6 Battery Charger
Tuesday, April 13, 2010
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.
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.
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.
Monday, April 5, 2010
Initial Thrust Testing
This past weekend we built a test platform in order to do some basic thrust tests with our motors and the two different props we have. This gave us a general understanding of how much current we need per motor in order to keep our aircraft hovering. We were able to more accurately determine this because we have our first body finished! There will be more on the body in following posts. The thrust test platform consisted of a lever made from ABS and a metric scale, so that prop thrust generated a proportional weight on the scale. By scaling this thrust by the ratio of the lever lengths we were able to get an approximate measurement of lift (in grams) versus current for our two props.
Thrust test bed:
Video of tri-blade ramping from idle to 8 Amps (12000 RPM):
Our findings indicate that the two prop configurations are similar, but at lower currents (as in hovering) the 2-blade prop is more efficient than the tri-blade, and at higher currents (above 5 amps) the opposite is true.
Thrust vs. Current plot:
The difference in efficiency at high and low current output is particularly evident when plotting RPM versus current as in the figure below. Note that at higher currents the dual-blade prop has a lower RPM gain per Amp than the tri-blade, and the tri-blade has a higher RPM gain per Amp than the dual-blade at lower amps. The general difference in RPM between the tri-blade and dual-blade is due mostly to the diameter of the props.
RPM vs. Current
To determine the efficiency of our system, we measure the entire weight of our body (adding on some weight to for wires to be conservative) with a particular battery, and determine the hover time based on battery capacity and the current required to hover.
For example, using Blue Lipo lithium polymer batteries with 2200 mAh (at about 185g) we have a total body weight of 615g. In order to hover we need each motor to generate 615/4 or about 154g of "thrust". With the tri-blade this corresponds to about 2.2 Amps per motor (8.8 Amps total). With the dual-blade this corresponds to about 1.8 Amps per motor (7.2 Amps total). With our 2200 mAh battery, this gives a flight time of:
Tri-blade -- 2.2 Amps*Hour * (60 min / Hour) * (1 / 8.8 Amps) = 15 minutes
Dual-blade -- 2.2 Amps*Hour * (60 min / Hour) * (1 / 7.2 Amps) = 18.3 minutes
This indicates that at hovering, the dual blades are (18.3-15) / 15 * 100% = 22% increase with respect to the tri-blade efficiency. This, however, was not enough to convince us to use the two blade props over the three blade props...the tri-blades are much quieter and, let's face it, look way too badass.
With a 1500 mAh Mystery Lipo we found the following flight times using the same metric:
Tri-blade = 12.5 minutes
Dual-blade = 15 minutes
Here's the mess we made in the undergraduate electrical engineering lab:
Thrust test bed:
Video of tri-blade ramping from idle to 8 Amps (12000 RPM):
Our findings indicate that the two prop configurations are similar, but at lower currents (as in hovering) the 2-blade prop is more efficient than the tri-blade, and at higher currents (above 5 amps) the opposite is true.
Thrust vs. Current plot:
RPM vs. Current
To determine the efficiency of our system, we measure the entire weight of our body (adding on some weight to for wires to be conservative) with a particular battery, and determine the hover time based on battery capacity and the current required to hover.
For example, using Blue Lipo lithium polymer batteries with 2200 mAh (at about 185g) we have a total body weight of 615g. In order to hover we need each motor to generate 615/4 or about 154g of "thrust". With the tri-blade this corresponds to about 2.2 Amps per motor (8.8 Amps total). With the dual-blade this corresponds to about 1.8 Amps per motor (7.2 Amps total). With our 2200 mAh battery, this gives a flight time of:
Tri-blade -- 2.2 Amps*Hour * (60 min / Hour) * (1 / 8.8 Amps) = 15 minutes
Dual-blade -- 2.2 Amps*Hour * (60 min / Hour) * (1 / 7.2 Amps) = 18.3 minutes
This indicates that at hovering, the dual blades are (18.3-15) / 15 * 100% = 22% increase with respect to the tri-blade efficiency. This, however, was not enough to convince us to use the two blade props over the three blade props...the tri-blades are much quieter and, let's face it, look way too badass.
With a 1500 mAh Mystery Lipo we found the following flight times using the same metric:
Tri-blade = 12.5 minutes
Dual-blade = 15 minutes
Here's the mess we made in the undergraduate electrical engineering lab:
Monday, March 29, 2010
Initial Motor Testing
So some exciting news: the motors and ESCs from Singapore have finally arrived! We have hooked them up and tested their speed/current characteristic using a 3A power supply set to 11.1V, a 50Hz PWM (Period of 20000 at 1MHz) signal from the MaEvArM, and the tri-blade rotors. Our initial test results and some pictures/video are below!
Dual-blade props with Mystery motor:
Tri-blade prop with Mystery motor:
Tachometer setup to read RPM of tri-blade props:
Temporary test bench with two tri-blade props:
Current and RPM vs. % duty cycle for tri-blade prop:
Tri-blade motor spin test:
Dual-blade props with Mystery motor:
Tri-blade prop with Mystery motor:
Tachometer setup to read RPM of tri-blade props:
Temporary test bench with two tri-blade props:
Current and RPM vs. % duty cycle for tri-blade prop:
Tri-blade motor spin test:
Saturday, March 27, 2010
Razor IMU Bootloader Issues
After connecting the Razor 9DOF IMU to the Arduino IDE and attempting the upload the code to the board, the following errors were displayed:
avrdude: stk500_getsync(): not in sync: resp=0x72
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x72
The board was connected correctly to the computer (since we were reading values output from the sample code pre-loaded onto the chip) and the IDE settings were correct. The correct COM port as well as the correct board (Arduino Pro or Pro Mini (3.3V, 8Mhz) w/Atmega328) were selected.
So after several hours of searching online and looking at other posts/replies regarding this type of issue (such as resetting the board, updating the FTDI drivers, etc), it was mentioned that it may be possible that either the Arduino Bootloader was the wrong version (since SparkFun just changed these boards from the Atmega168 to the Atmega328) or even the Bootloader was corrupted. With these in mind, we tracked down a programmer to try re-burning the Bootloader to the chip.
We weren't able to find an ISP programmer (any from the list in the Arduino IDE, such as the AVRISP or AVR ISP mkII), however we were able to find a AVR JTAGICE mkII programmer. This programmer is able to program through either the JTAG or ISP pins, which is great since the only connections available on the board are Serial and ISP/SPI. Since this programmer is incompatible with the Arduino IDE, we had to use AVRStudio4. Here are the steps we took to re-burning the Arduino Bootloader and getting the Arduino IDE to communicate with the chip:
avrdude: stk500_getsync(): not in sync: resp=0x72
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x72
The board was connected correctly to the computer (since we were reading values output from the sample code pre-loaded onto the chip) and the IDE settings were correct. The correct COM port as well as the correct board (Arduino Pro or Pro Mini (3.3V, 8Mhz) w/Atmega328) were selected.
So after several hours of searching online and looking at other posts/replies regarding this type of issue (such as resetting the board, updating the FTDI drivers, etc), it was mentioned that it may be possible that either the Arduino Bootloader was the wrong version (since SparkFun just changed these boards from the Atmega168 to the Atmega328) or even the Bootloader was corrupted. With these in mind, we tracked down a programmer to try re-burning the Bootloader to the chip.
We weren't able to find an ISP programmer (any from the list in the Arduino IDE, such as the AVRISP or AVR ISP mkII), however we were able to find a AVR JTAGICE mkII programmer. This programmer is able to program through either the JTAG or ISP pins, which is great since the only connections available on the board are Serial and ISP/SPI. Since this programmer is incompatible with the Arduino IDE, we had to use AVRStudio4. Here are the steps we took to re-burning the Arduino Bootloader and getting the Arduino IDE to communicate with the chip:
- Connected the programmer to the computer with the USB cable (and made sure that the computer had the correct drivers for it).
- Connected the programmer to the board. After soldering pin headers to the 6-pin ISP/SPI connection, the squid breakout cable (which allows for each of the 10 JTAG cables to be connected individually) was connected using the following websites: JTAGICE mkII (for the programmer connections) and Razor 9DOF IMU Schematic (for the Razor ISP/SPI connections).
- In AVRstudio, click "Tools" and then "Program AVR".
- In the "Main" tab, change the device to "Atmega328p" and the programming mode to "ISP".
- In ISP settings, we used 500kHz since the board has a 8MHz clock (ISP requires something under 1/4 the system clock for any board running below 12 MHz. 8/4 -> anything under 2MHz). We chose this just to stay on the safe side.
- Click "Read Signature". We got a long hex string back (in the box under device name). This is a very good sign, since it means that we are getting data back from the board.
- In the "Program" tab under "Flash", find the bootloader (this hex file is located in the Arduino folder so for us it was under arduino-0018\hardware\arduino\bootloaders\atmega). We used the ATmegaBOOT_168_atmega328_pro_8MHz.hex (several posts we found indicated that this was what should be used on this board).
- Click "Program". The Razor board as well as the Tx and Rx pins on our FTDI board lit up as the data was sent and the new Bootloader was burning onto the chip. We didn't see any errors listed at the bottom of the screen, but we clicked "Verify" to make sure.
Thursday, March 25, 2010
9DOF Board Has Arrived!
Alright, so a few updates since the last post:
The 9DOF IMU (Inertial Measurement Unit) has arrived today from SparkFun. At 1.95" x 1.10", the board is only slightly larger than the MaEvArM. Currently, the connections are set so that the board outputs all of the sensor data over the serial output (Tx and Rx pins), however we'll be looking into the other possible connectors on the board (look like SPI). If they are, we may be able to use the board to grab data from our barometric pressure unit, which also arrived today. This keeps the sensor data separated from our main processor (the Atmega32U4 on the MaEvArM) which will be doing the PID and motor control. More on this board will be posted soon.
9DOF Razor from Spark Fun
FTDI USB to Serial adapter from Spark Fun:
Barometer IC from Spark Fun:
MaEvArM Microcontroller with ATMega32u4:
The props have arrived. We've decided to get a couple variations to test which works best. (All our sets consist of two normal and two counter-rotating blades. This prevents us from having to tilt the motors in order to counteract the rotational inertia).
Lastly, we've been starting to program the MaEvArM's basic tasks to ensure that our specifications will be made. So far, two main tasks have been tested and working properly:
That's it for now, but we'll keep you updated with our progress!
The 9DOF IMU (Inertial Measurement Unit) has arrived today from SparkFun. At 1.95" x 1.10", the board is only slightly larger than the MaEvArM. Currently, the connections are set so that the board outputs all of the sensor data over the serial output (Tx and Rx pins), however we'll be looking into the other possible connectors on the board (look like SPI). If they are, we may be able to use the board to grab data from our barometric pressure unit, which also arrived today. This keeps the sensor data separated from our main processor (the Atmega32U4 on the MaEvArM) which will be doing the PID and motor control. More on this board will be posted soon.
9DOF Razor from Spark Fun
FTDI USB to Serial adapter from Spark Fun:
Barometer IC from Spark Fun:
MaEvArM Microcontroller with ATMega32u4:
The props have arrived. We've decided to get a couple variations to test which works best. (All our sets consist of two normal and two counter-rotating blades. This prevents us from having to tilt the motors in order to counteract the rotational inertia).
- The first set are two-blade, 8x3.8 props. (8" diameter, 3.8 blade pitch). These are fairly large rotors and have decent specs when run on our motors (will post more detailed results later).
- The second set are tri-blade, 7x3.5 props (7" diameter, 3.5 blade pitch). After some research, it was found that tri-blade props can be quieter than dual-blade when run at the same speed. We'll also post tests with these props once the motors come in (still on their way from Singapore!).
Lastly, we've been starting to program the MaEvArM's basic tasks to ensure that our specifications will be made. So far, two main tasks have been tested and working properly:
- Four 16-bit PWM channels (0-65536 resolution) have been tested to control the four motor controller (Brushless ESCs). With the System Clock set to 8MHz, a 150Hz output signal was able to be generated with a resolution of 0-53333 (this will have to be tested with the ESCs since they normally take 50Hz Remote Control Standard servo controls).
- Buffered Interrupt-controlled serial communication was successfully accomplished by modifying the AVR306 (Atmega UART) code to work with the Atmega32U4 registers. This will allow us to read the output from the 9DOF board without wasting CPU usage (allowing for our PID calculations, PWM Control, and Wireless Receive to run continuously). This code uses a Circular Buffer technique to get store data when the CPU is in use and read it when it has time to.
That's it for now, but we'll keep you updated with our progress!
Sunday, March 7, 2010
First Milestone!
Project Wyvern has officially begun! The orders have been placed for the quadrotor components. Once they arrive, we will begin testing and interfacing the different control/sensor elements and post our results
Some of the key components:
-FireFly Wireless Microcontroller Platform
-MaEvArM Microcontroller
-A2208-14 1450KV Outrunner Brushless Motors (x4)
-30A ESC (Brushless Motor Controllers) DC 5.6V-16.8V (x4)
-9DOF Razor IMU (3-axis accelerometer, 3-axis gyroscope, 3-axis magnetometer)
-3 Blade Rotor - Two sets of both normal and reverse rotation 7x3.5
Some of the key components:
-FireFly Wireless Microcontroller Platform
-MaEvArM Microcontroller
-A2208-14 1450KV Outrunner Brushless Motors (x4)
-30A ESC (Brushless Motor Controllers) DC 5.6V-16.8V (x4)
-9DOF Razor IMU (3-axis accelerometer, 3-axis gyroscope, 3-axis magnetometer)
-3 Blade Rotor - Two sets of both normal and reverse rotation 7x3.5
Overview
This overview for Project Wyvern is a basic explanation of the main components, controls, and applications of an inexpensive quadrotor aircraft.
Background
The majority of quadrotors are very expensive. The possibility of creating a budget quadrotor robot opens the door to new and interesting experiments such as group communication and flocking patterns. Within the scope of this course, building a quadrotor robot offers an interesting application of wireless communication, high frequency sensor and ADC measurements, and a combination of mechanical design, electrical design, and controls theory.
Microcontrollers
MaEvArM
The MaEvArM is a general purpose microcontroller platform using the ATmega32U4. The primary purpose of the MaEvArM on the robot platform is dedicated motor control to the four (4) ESC brushless motor controllers.
FireFly
Zigbee wireless communication, allowing for wireless control of direction, altitude, and localization information as well as feedback from on-board sensors.
ATMega168
Dedicated ADC microcontroller to output a constant stream of accelerometer, gyroscope, magnetometer values via SPI to the MaEvArM and FireFly.
Motors
Brushless Motors
Brushless DC motors are more efficient and longer lasting than brushed motors, offering lower cost in the long run and a greater thrust to power ratio. A downside to using this type of motor is that it requires a particular form of dedicated motor controller and is frequently more expensive than a brushed motor. Brushless motors have a significantly longer life-span and better performance per weight than one finds in most brushed motors. The proposed quad-rotor will utilise the Suppo A2208/14 motor which for the approximated weight will draw around 3.4 [amperes] at 7 [volts] for stable flight with an overall lifting capability of 700 [grams] and will be capable of an overall lifting capability of 1.2 [kilograms]. Moreover, the motor has a rise of 1450 [Kv]. The aforementioned properties should be sufficient for stability and most maneuvering. Variation of rotors will allow for differing lifting capabilities at greater ampere consumptions.
Brushless Motor Controllers
Brushless ESCs are used to allow a convenient PWM output from the MaEvArM to control the motors while producing the necessary sinusoids to drive the brushless motors at the necessary current. Using back-EMF the motor controller is able to determine the current phase of the motor and apply the correct voltage in sequence and cause the motor to rotate.
Sensors
Accelerometer
To sense changes in movement. Three degrees of freedom.
Gyroscope
To sense changes in direction and absolute position. Three degrees of freedom
Magnetometer
Absolute xyz orientation over time, correcting steady state fluctuations in Gyroscope (a novelty included in the sensor PCBA)
Barometer
To allow for autonomous flight or flight stabilization, a vertical height (altimeter) is required. Through the use of atmospheric pressure, a barometer is able to output voltage changes which can be converted into altitude within a 9 cm cylinder of air resolution.
GPS (possible add-on)
In addition to the barometer, GPS is another useful sensor for autonomous flight. In addition to position globally within approximately 2-3 meters, the global positioning system adds a second measurement for vertical position. Combining the measured vertical positions from the GPS and the barometer could lead to a more accurate measurement.
CCTV (possible add-on)
To transmit video wirelessly, two options are available. Serial video cameras use RS232 connections directly to the microcontroller with wireless capability (in our project, the FireFly). This video or image information can be directly used on a computer for use in image processing/autonomous modes. A downside to using this type of camera is that lower quality video/images are transmitted due to different processes (control, sensor information, etc) using the same transceiver. A more efficient and less expensive option would be to use a separate video/transmitter combo that uses the 2.4GHz frequency. The receiver, connected to a TV, would show the view from the aircraft in real-time. This option, however, is more difficult to use in image processing and autonomous control.
Airframe
Approximate Total Weight
600g
Material
Carbon Fiber (if feasible), otherwise acrylic/abs for manufacturability.
Flight Control
PID
PID, or proportional-integral-derivative controllers are loop feedback controls that aim to minimize over-compensation to data, which one might anticipate as being rather noisy. They use different feedback methods to limit the difference, or error, between the output and the desired goal.
Kalman Filter
A Kalman Filter is used to obtain more precise values over time from data that contains noise.
Roll (Left/Right Control)
Roll control, which is rotation about the X-axis (the axis between Front and Back rotors), is accomplished by increasing/decreasing the Left and Right rotors. A left roll is achieved by increasing the Right rotor while simultaneously decreasing the Left rotor. The opposite, increasing the Left rotor while simultaneously decreasing the Right rotor, results in a right roll.
Yaw (Turning Control)
Yaw control, which is rotation about the Z-axis (the vertical axis), is accomplished by increasing/decreasing the Left/Right and Forward/Back rotor pairs. A left yaw (or left rotation of the aircraft) is achieved by increasing the Left/Right rotor pair while simultaneously decreasing the Front/Back rotor pair. The opposite, increasing the Front/Back rotor pair while simultaneously decreasing the Left/Right rotor pair, results in a right yaw (or right rotation of the aircraft).
Pitch (Foward/Backward Control)
Pitch control, which is rotation about the Y-axis (the axis between Left and Right rotors), is accomplished by increasing/decreasing the Front and Back rotors. A forward pitch is achieved by increasing the Back rotor while simultaneously decreasing the Front rotor. The opposite, increasing the Front rotor while simultaneously decreasing the Back rotor, results in backward pitch.
Hovering
Stable, minimal oscillation flying at constant altitude--the first great milestone
Takeoff/Landing
Second great milestone--stable liftoff and landing, controlling aircraft in the face of air disturbances
Timeline
March 15 - Gather materials and parts
March 22 - Airframe construction complete
March 29 - Program Sensor MCU
April 5 - ESC PWM and birth flight, open loop
April 12 - Sensor serial communication to MaEvArM
April 19 - Initial PID design started
April 28 - Control tweaking and testing, etc.
Extensions
(Senior Design)
Wireless communication between multiple flying robots, flocking patterns, etc.
Conclusion
The proposed project is very ambitious, and care must be taken to divide it into parts that can be more easily managed. This will more than likely become a senior design project and, if it is done right, will allow for a multitude of very interesting applications and modifications.
Background
The majority of quadrotors are very expensive. The possibility of creating a budget quadrotor robot opens the door to new and interesting experiments such as group communication and flocking patterns. Within the scope of this course, building a quadrotor robot offers an interesting application of wireless communication, high frequency sensor and ADC measurements, and a combination of mechanical design, electrical design, and controls theory.
Microcontrollers
MaEvArM
The MaEvArM is a general purpose microcontroller platform using the ATmega32U4. The primary purpose of the MaEvArM on the robot platform is dedicated motor control to the four (4) ESC brushless motor controllers.
FireFly
Zigbee wireless communication, allowing for wireless control of direction, altitude, and localization information as well as feedback from on-board sensors.
ATMega168
Dedicated ADC microcontroller to output a constant stream of accelerometer, gyroscope, magnetometer values via SPI to the MaEvArM and FireFly.
Motors
Brushless Motors
Brushless DC motors are more efficient and longer lasting than brushed motors, offering lower cost in the long run and a greater thrust to power ratio. A downside to using this type of motor is that it requires a particular form of dedicated motor controller and is frequently more expensive than a brushed motor. Brushless motors have a significantly longer life-span and better performance per weight than one finds in most brushed motors. The proposed quad-rotor will utilise the Suppo A2208/14 motor which for the approximated weight will draw around 3.4 [amperes] at 7 [volts] for stable flight with an overall lifting capability of 700 [grams] and will be capable of an overall lifting capability of 1.2 [kilograms]. Moreover, the motor has a rise of 1450 [Kv]. The aforementioned properties should be sufficient for stability and most maneuvering. Variation of rotors will allow for differing lifting capabilities at greater ampere consumptions.
Brushless Motor Controllers
Brushless ESCs are used to allow a convenient PWM output from the MaEvArM to control the motors while producing the necessary sinusoids to drive the brushless motors at the necessary current. Using back-EMF the motor controller is able to determine the current phase of the motor and apply the correct voltage in sequence and cause the motor to rotate.
Sensors
Accelerometer
To sense changes in movement. Three degrees of freedom.
Gyroscope
To sense changes in direction and absolute position. Three degrees of freedom
Magnetometer
Absolute xyz orientation over time, correcting steady state fluctuations in Gyroscope (a novelty included in the sensor PCBA)
Barometer
To allow for autonomous flight or flight stabilization, a vertical height (altimeter) is required. Through the use of atmospheric pressure, a barometer is able to output voltage changes which can be converted into altitude within a 9 cm cylinder of air resolution.
GPS (possible add-on)
In addition to the barometer, GPS is another useful sensor for autonomous flight. In addition to position globally within approximately 2-3 meters, the global positioning system adds a second measurement for vertical position. Combining the measured vertical positions from the GPS and the barometer could lead to a more accurate measurement.
CCTV (possible add-on)
To transmit video wirelessly, two options are available. Serial video cameras use RS232 connections directly to the microcontroller with wireless capability (in our project, the FireFly). This video or image information can be directly used on a computer for use in image processing/autonomous modes. A downside to using this type of camera is that lower quality video/images are transmitted due to different processes (control, sensor information, etc) using the same transceiver. A more efficient and less expensive option would be to use a separate video/transmitter combo that uses the 2.4GHz frequency. The receiver, connected to a TV, would show the view from the aircraft in real-time. This option, however, is more difficult to use in image processing and autonomous control.
Airframe
Approximate Total Weight
600g
Material
Carbon Fiber (if feasible), otherwise acrylic/abs for manufacturability.
Flight Control
PID
PID, or proportional-integral-derivative controllers are loop feedback controls that aim to minimize over-compensation to data, which one might anticipate as being rather noisy. They use different feedback methods to limit the difference, or error, between the output and the desired goal.
Kalman Filter
A Kalman Filter is used to obtain more precise values over time from data that contains noise.
Roll (Left/Right Control)
Roll control, which is rotation about the X-axis (the axis between Front and Back rotors), is accomplished by increasing/decreasing the Left and Right rotors. A left roll is achieved by increasing the Right rotor while simultaneously decreasing the Left rotor. The opposite, increasing the Left rotor while simultaneously decreasing the Right rotor, results in a right roll.
Yaw (Turning Control)
Yaw control, which is rotation about the Z-axis (the vertical axis), is accomplished by increasing/decreasing the Left/Right and Forward/Back rotor pairs. A left yaw (or left rotation of the aircraft) is achieved by increasing the Left/Right rotor pair while simultaneously decreasing the Front/Back rotor pair. The opposite, increasing the Front/Back rotor pair while simultaneously decreasing the Left/Right rotor pair, results in a right yaw (or right rotation of the aircraft).
Pitch (Foward/Backward Control)
Pitch control, which is rotation about the Y-axis (the axis between Left and Right rotors), is accomplished by increasing/decreasing the Front and Back rotors. A forward pitch is achieved by increasing the Back rotor while simultaneously decreasing the Front rotor. The opposite, increasing the Front rotor while simultaneously decreasing the Back rotor, results in backward pitch.
Hovering
Stable, minimal oscillation flying at constant altitude--the first great milestone
Takeoff/Landing
Second great milestone--stable liftoff and landing, controlling aircraft in the face of air disturbances
Timeline
March 15 - Gather materials and parts
March 22 - Airframe construction complete
March 29 - Program Sensor MCU
April 5 - ESC PWM and birth flight, open loop
April 12 - Sensor serial communication to MaEvArM
April 19 - Initial PID design started
April 28 - Control tweaking and testing, etc.
Extensions
(Senior Design)
Wireless communication between multiple flying robots, flocking patterns, etc.
Conclusion
The proposed project is very ambitious, and care must be taken to divide it into parts that can be more easily managed. This will more than likely become a senior design project and, if it is done right, will allow for a multitude of very interesting applications and modifications.
Friday, March 5, 2010
Beginnings
Welcome to the home of the Wyvern, a quadrotor aircraft that is in its infant stage. We will be posting to this blog when we reach certain noteworthy milestones.
Subscribe to:
Posts (Atom)
