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.
Subscribe to:
Posts (Atom)
