All Posts (11086)

Sort by
3D Robotics

ArduPilot code update

We're been making progress on the ArduPilot code and are getting closer to releasing a proper beta. In the meantime, here's an update (and, for the brave, a pre-alpha look at the code): The basic outlines of the code (GPS parser, navigation loops, altitude control, servo control, etc) are written. The GPS parser is pretty well tested and works okay. The navigation algorithms have been tested on a simulator, but still need to be tested in the real world. The servo control needs to be tuned. Basically, the basics seem to be working okay, but it can't fly a plane yet. If you want to see it in its pre-alpha stage, you can download it here. Comments and suggestions very gratefully received. If nothing else, the code as it now stands is at least a tutorial on GPS parsing, basic navigation principles and RC interfaces. It's more than just a port of our Basic Stamp autopilot--we've really upgraded the navigation routines and waypoint handling, as well. Over the next few weeks, it will actually become a useful autopilot, too! (Note: this is the code for ArduPilot. Jordi is writing the enhanced version for ArduPilot Pro, and that won't be ready for a few more months) Some observations on writing the code to this point: 1) One of the hardest things to work with on Arduino is serial. The IDE uses the hardware serial pins, so if you're also using them for your GPS, you have to unplug your GPS every time you're uploading new code (you can still share the pins with the IDE for debugging text while the code is running). More troubling is that the serial routines aren't as rock-solid as those of the Basic Stamp, so it's easy to flood the buffers or otherwise mess up the serial timing if certain loops in your code are running faster or slower than you expected. You can actually do serial on any digital pin using software serial routines (either the official one or the better AFSoftSerial), but the timing problems are even worse for the software routines and because they don't use hardware interrupts, they take a toll on processor power. 2) For me, the hardest part about switching from Basic Stamp to Arduino (which is basically C) is that I keep forgetting to use a double "=" for logical comparisons. "if (x = y)" will always return true, because you're actually setting x to y in the statement. The correct syntax is "if (x == y)". I know that everyone is now slapping their head at what a noob I am, but the truth is that I've been programming in C long enough to know this. The problem is that I also program in other languages that don't have that syntax. I can't tell you how many hours I've wasted tracking down bugs that came from making that mistake. 3) On a positive note, after the nightmare of Basic Stamp's integer-only math and tiny variable memory, it's an absolute joy to use floating point without a second thought and use as many variables (even two-dimensional arrays) as I want. That alone is worth the price of porting the code to Arduino.
Read more…
3D Robotics

(Left to Right) Don Hatch, Tim Herd Performing an engine check before the competition practice flight. Location: Webster Field We've written a bit about this year's AUVSI student UAV contest, about which there isn't much information on the web. One of the participants, Andrew Bugera, who chairs the University of Manitoba UAV group (which won $1,800 for Honorable Mention in Mission Performance and a Prize Barrel for automatic takeoff), kindly wrote in to offer to explain more about the contest from a team's perspective. Here's my Q&A with Andrew: Q: Was your UAV essentially the one you used last year and described in this paper? What was the overall budget for your UAV? The aircraft itself was the same as the one flown in 2007. We bought a newer autopilot revision (Micropilot mp2128g) in order to use certain camera stabilization and tracking features. We changed our entire imaging payload this year in response to the competition rules (see question 4). While it's difficult to pin down the exact cost of the aircraft and other components, I would estimate that we spent $3000-$5000 to build the plane and outfit it with an autopilot and other items. Travel costs make up the remainder of our project budget. In addition to the monetary costs of the project, we also had to dedicate a lot of time. Q: Last year's used an off-the-shelf autopilot but it appears that the team did most of its custom work on image processing and transmission, using an on-board computer. Was that what you focused on this year, too? Basically, yes. Because the autopilot has worked well for us in the past (especially in 2006 when we were awarded Best Flight for mission performance and First Place overall), we were more concerned with implementing a good imaging system. In 2006, we used a still camera and pressed the shutter release button with a servo running on a timer. In 2007, we attempted to interface directly with the camera over its USB interface using gPhoto. Unfortunately, with only one software developer on the team, there wasn't enough time to test the system before the competition. An unknown error resulted in no photos being captured during our competition flight. This year, we were again focused on the imaging side (with some time spent dealing with the new autopilot features we were trying to use) but in a different way. Q: What was your contest strategy this year? How did you design your UAV for that? One of the aspects the judges added to the competition starting in 2007 was the opportunity for us to provide "live" (during flight) target location information if possible. This year we decided to switch to using two fixed-lens analog video cameras: one wide-angle and the other telephoto. The idea was to get a wider view of the field and pick out a target location with the wide camera and then aim the telephoto camera with a gimbal at that potential target to get a better look. These video streams were sent to the ground station for our imaging operator. Q: What's the hardest part of the contest? The easiest? The "easiest" part of the competition (or at least the one we sometimes take for granted) is the autonomous navigation aspect. Although this is mostly a solved problem and we can use off-the-shelf autopilots to control the aircraft, sometimes the competition prompts us to do things a little bit differently than the manufacturers intended. In general, using off-the-shelf components makes development easier but you still need to make sure they are suitable for your purpose. On the technical side, managing the interactions between many (sometimes poorly-documented) systems in order to create your desired product is probably the most difficult part. The way I've tried to deal with that over the past two years is to recruit team members from multiple disciplines (Computer, Electrical, and Mechanical Engineering and Computer Science). With this varied knowledge at our disposal, making decisions becomes much easier. An additional challenge that this competition introduces is transportation. We need to be able to disassemble our plane and bring it with us as airline luggage. The overall trip usually takes 12-14 hours from Winnipeg to Lexington Park, so we're usually pretty tired when we finally get to our hotel. Q: Can you tell us how your team did in the contest? What worked? What didn't? We haven't received the official scores yet. From the prize money awarded, we didn't do as well as we have in the past. The aircraft was stable and had no aerodynamic problems. Because we've been using this aircraft for the last two years, it is fairly well-tested and we are comfortable with its performance. Unfortunately, we had a small issue at the competition which caused bigger issues. As one of the safety requirements of the competition, if an aircraft can no longer detect the signal from either the RC safety pilot (required to be standing by in case of autopilot failure or other problem) or from the ground control station, it must perform a series of actions. Our particular implementation waits 30 seconds and then flies toward the takeoff location. After an additional 3 minutes without signal, the aircraft is required to cut the throttle and fully deflect all control surfaces to effect a "minimum energy descent". At one point during the competition, we momentarily lost the connection to the ground station and this failure routine activated. Rather than take the risk of a "flight termination", we elected to transfer control to our safety pilot. This almost certainly resulted in a loss of points because we were no longer performing the mission autonomously. On the positive side, our imaging system was still running through most of the flight. We were able to see a few targets in the incoming video streams and provide the judges with at least minimal information.

(Left to Right) Tim Herd, Andrew Bugera, Shunjie Lau, Mo Ran Wang (Not pictured: Andrew Oliver, Ashley Keep, Don Hatch, Rashed Minhaz) Reassembling the UAV after returning from the competition. Location: University of Manitoba Q: What tips did you pick up from the winning teams? Unfortunately, I didn't have as much time this year to chat with the other teams as I have in the past. We did have some interesting conversations with our friends from the University of Texas at Arlington regarding potential solutions to our radio problem. We also got to see two teams using the open source Paparazzi autopilot: Utah State University and Université de Sherbrooke. Once the 2008 journal papers are published, we'll all get to take a closer look at what the other teams designed and see if any of their ideas inspire some changes for next year. One of the best parts of this competition is the opportunity to talk to very smart people from around the world. Q: What will you do differently next year? Practice, practice, practice! :) The weather this year was not cooperative for flight testing. A long winter and rainy spring ate up many of the days the team had available to run test flights. Testing subsystems before the competition is very important, though. One of the other comments that the judges made this year was that the use of checklists is a very good idea. As in a manned aircraft, they suggested we include checklists for failure conditions as well. Knowing what to do in advance *when* something goes wrong during your flight would be a positive thing. Other that that, we'll take a look at the updated rules when they are published and decide what direction to go for the next competition.
Read more…
3D Robotics

Five good planes to convert to a UAV


I get this question all the time: what's a good plane to turn into a UAV? The answer is that it depends on your needs, your budget and your RC skills. But here are some good electric candidates:

For RC beginners:

The NextStar (see above) is roomy, slow-flying and comes with everything you need (including a RC flight simulator). It even has its own rudimentary flight-stabilization system with a Futaba PA-2 optical co-pilot.


For DIY'ers on a budget:


The $110 SuperStar is a nice-flying four-channel plane with enough room for an autopilot and cameras strapped below. The ARF kit comes with a brushed motor and NiCad batteries, which are enough to get you started. When you're ready, you can upgrade to a brushless motor and LiPos. This is the plane we use for GeoCrawler 2 and will also be the basic platform for our ArduPilot-based UAV. You can hand launch it in a park, or take it off from a runway at an airfield. It's tough and can handle wind. All and all, a really comfortable plane to work with, especially once you upgrade the motor and battery.


[Note. This plane appears to be discontinued. You might want to check out the NexSTAR Mini EP as a replacement. It's not quite as good, as it's more expensive and has less interior room, but it does the trick]


For those looking for long flight times:


The Aero-Master is a powered glider with a pusher prop, which means no propellers in the way of your cameras. This is the aircraft used by Marcus UAV.

For those who want to carry heavy, high-resolution cameras, with unobstructed views:


If you're looking for something like the classic Pioneer UAV, with a twin tail and a pusher prop, you might want to consider starting with this Skymaster RTF. Skip the front motor (put your cameras there instead), double the size of the rear one, and you're pretty close. We've got one and the plane looks beautifully made. We haven't flown it yet, but the dimensions are encouraging.

[This one appears to no longer be available, although a larger gas-powered one still is]

For an all-around great first UAV platform:


EasyStar. The classic. Easy to fly, hard to break and plenty of room for electronics. Works best with a brushless motor upgrade.

An even cheaper variation on this, with the helpful addition of ailerons, is the Dynam HawkSky. Well worth considering as an EasyStar alternative,.
Read more…

prototype of my uav-pcb

because there's no easy way to connect the arduino to a normal perf-baord (stupid 2mm space between digi7 and digi8) i decided to make it the right way from the beginning. so i downloaded eagle and played around the last few days. this is what has come out. :) i plan to use the arduino bootloader and just connect the few needed pins to a empty diecimila board for easy programming. all the traces are already handrouted.i'll use the following sensors (plugged in on the pinheaders [should be female ones on the board]):3x Gyro Breakout Board - MLX90609Triple Axis Accelerometer Breakout - LIS3LV02DQBreakout Board for MEMs Barometric Pressure Sensor - SCP1000they all run on the spi bus. there's a 74hc4050 for level-shifting 5v to 3.3V for the accelerometer and pressure sensor.- there are 4 keys based on http://www.arduino.cc/en/Tutorial/TwoSwitchesOnePin- the 4 pins on the left are i2c + power for the sparkfun-blinkm- ppm input (see my previos blog post)- ppm output (ppm and reset signal also driven by timer1) and a 4017N decoder to 10 servos. that should be enough :)the cool thing about this is that when coded correctly, this thing wont lose control when the software crashes. since the the interupts are called in hardware by the timer, as long as the crashed software doesn't modify the timer-setup-registers, the interupts will continue to be called! so you could check in the input capture interupt each time if the programm is running (increment variable for each loop or like that): if yes, use the computed servo-position, if not, directly pass the position from the receiver.the display (ttl serial crystalfontz) is pluged in for setup.the ublox (got it here http://ppzuav.com/) has a very nice software for windows. you can connect it with usb, experiment with the settings, and save the default settings to flash! so you wont need to do this on every start up. the gps is only connected with serial-in, 5V and gnd.what i noticed on the ublox is that it's not as sensitive as a sirf3! my old sirf3 easily works indoors. the ublox wont, i have to at least put it next to the window...this is just a prototype or alpha version. i connected all the stuff the way i think it should work.- ppm input works- ppm output works, but without the reset-signal at the moment (should usually work without problems, but if for some reason a pulse is skipped, all the following pulses/servo-positions will be shifted by one servo... which is not so good...)- gps works (at least with nmea messages, ublox messages will be even easier)- display with simple menu-system works- pressure sensor works (but with a simpler level shifter, have to first get the 74hc4050)todo:- connect all parts on a breadboard- read all sensors- get board made- write software....once the baord is finshed, i'll probably release the eagle files. the design is quite universal and can be used for everything! more sensors/hardware can be easily connected to i2c or spi-bus (there are 3 unused i/o pins the atmega)PS: i should probably add headers for a rf-transmitter or maybe add battery-voltage-input (voltage divider) or a sd-card slot (on the backside?) instead of eeprom.
Read more…
3D Robotics

An old skool instrument panel for OSD data

This is just the coolest thing. It's not exactly UAV-related, but our FPV (first-person view) friends use much of the same technology as we do, from real-time video links to on-screen displays (OSD) of GPS and telemetry data. Here's what one FPV guy did to avoid having to have an electronic integration of his telemetry into his video stream: he built an analog instrument panel and put it in view of his onboard camera!

Behind that panel is a GPS and an embedded processor (I don't know what kind) which is presumably driving three servos, which move those dial needles. The reason you need this is that it's really easy to get disoriented and lost when doing FPV, with those video google on and the birds-eye view of your location. Now he just needs to "glance at his instrument panel" through his video googles and he can see (from left to right) his speed, bearing (straight up means he's heading back to home) and altitude. His write up of how he made it is here. Full points for creativity!

(Thanks to the Make Magazine blog for the find)

Read more…
3D Robotics

New tilt-compensated compass sensor

Sparkfun has released a lovely (if expensive) bit of silicon: a tilt-compensated magnetometer. "The HMC6343 has three axis of magneto, three axis of accelerometer, and a PIC core running all the calculations. What you get is a compass heading over I2C that stays the same even as you tilt the board." Not cheap at $250, but if you understand what a pain it would be do to that three-axis tilt-compensation yourself, you'll see why it's worth it.
Read more…
3D Robotics

ArduPilot Board V3, assembled

We're now testing the ArduPilot code on the real board (not just a breadboard prototype), which is the through-hole version of Beta 3. A few notes on assembling this board, if you've got one on order:

  • I've updated the parts list in the original post to reflect our recommended configuration (with pigtails rather than right-angle servo and RC receiver connectors)
  • The GPS connector doesn't have as robust a physical connection to the board as we'd like (we need to tweak the board to give it a little more room). If you're using this board, you might want to epoxy it on before soldering its electrical connections.
  • We accidentally designed this board with a surface-mount reset button, when the reset button that comes with the Boarduino kit that we use for parts is through-hole. I've listed the surface-mount part you need in the original post, but we'll tweak the board to use the through-hole version in the future.
  • Use the jumper that comes with the Boarduino kit to bridge the power selector pins (top left corner in the photo above) for the option you want: power from the RC receiver or another source. I use the RC receiver and it works great, but if you want power redundancy you may want to go with a second battery just for the autopilot.
Read more…
For those of you not familiar with the project we are a university team competing in the 2008 UAV Outback Rescue Challenge, for more information about our team visit our site: www.aessuav.org
On May 10th we attempted our first bottle drop from 400 feet. The bottle had an aluminum tab attached to it which was held by small servo at the center of gravity of the UAV. We took off under manual control and gained altitude, as the UAV flew it’s oval path autonomously, the bottle was released over the field. The first bottle we dropped was a 500mL Nalgene bottle, which failed miserably (see picture below).Missouri S&T UAV
With the water bottle attached, the flight characteristics were not affected, although takeoff distance was increased, the autopilot’s ability to control the UAV was not affected noticably. During these flights the winds were relatively high, ranging from 10 to 15 MPH, which made navigation for the UAV difficult, but the autopilot performed admirably. Though at times it was blown off the path, it returned quickly to the intended flight path. Several autonomous test flights were performed in the windy conditions, further demonstrating the robustness of our UAV platform.Missouri S&T UAV Team - Nalgen Bottle
Three more test flights were performed on May 15th, all of which included water bottle drops with different bottle designs that took into account lessons learned from the first test. Enclosures were developed for subsequent bottles that allowed them to survive the 400-foot drop. Data was also gathered about where the bottles landed and at what point they were released. With this data the theoretical and actual horizontal distance traveled were compared. After analysis it turned out that the horizontal distance traveled from two of the drops was consistent, this allowed a simple model to be developed for the trajectory of the bottle. During the final flight, aerial video of the bottle being released was also obtained from the onboard digital camera (see the video below).These test flights provided valuable data about how the bottle’s trajectory is affected by the wind resistance, as well as about how the UAV platform handles moderate winds. The next crucial step will be to integrate the onboard computer along with the camera into the aircraft to allow testing of the system as a whole.
For more visit: www.aessuav.org
Read more…
3D Robotics
[Marc Ramsey gave a fantastically clear and concise answer to a question that's asked here every week, so I'm going to reprint it here with some slight edits as a FAQ that we can link to from the front page.] Q: What's the difference between a gyro and an accelerometer? Do I need both? An accelerometer measures acceleration. A 3-axis accelerometer will tell you the orientation of a stationary platform relative to earth's surface, once that platform starts moving, however, things get more complicated. If the platform is in free-fall, it will show zero acceleration. If it is accelerating in a particular direction, that acceleration will simply be added to whatever acceleration is being provided by gravity, and you will not be able to distinguish. A 3-axis accelerometer in an aircraft in a properly coordinated turn with a 60 degree angle of bank, for instance, will show 2 G "vertical" acceleration in the aircraft, despite the fact that the aircraft is tilted 60 degrees relative to the horizon. So, accelerometers alone can't be used to keep in an aircraft in a particular orientation. A gyro measures rate of rotation around a particular axis. If a gyro is used to measure the rate of rotation around the aircraft roll axis, it will measure a non-zero value as long as the aircraft is rolling, but measure zero if the roll stops. So, a roll gyro in an aircraft in a coordinated turn with a 60 degree bank will be measure a rate of zero, same as an aircraft flying straight and level. You can approximate the current roll angle by integrating the roll rate over time, but you can't do so without some error creeping in. Just to make life more interesting, gyros drift with time, so additional error will accumulate over a period of minutes or even seconds, and eventually, you'll have a totally inaccurate idea of your current roll angle relative to the horizon. So, gyros alone can't be used to keep in an aircraft in a particular orientation. So, in a nutshell: Accelerometers are right in the long term but wrong (noisy) in the short term. Gyros are right in the short term but wrong (drifiting) in the long term. You need both--each to calibrate the other--to be right all the time. But even that only works in for pitch and roll. For yaw, which is orthogonal to gravity, the accelerometers can't help you, so you need something else to correct your drifting yaw gyro. That's either magnetometers (electronic compasses, which are vulnerable to magnetic interference and intertial forces) or GPS. GPS has a relatively slow update rate (1 to 10 Hz) and is subject to short term errors. It is possible to use GPS alone to keep a very stable and slow flying airframe on a particular ground track on a calm day. An inertial measurement unit (IMU) combines (fuses) information from two or more sensors, such as gyros, accelerometers, magnetometer, and/or GPS, to determine orientation and velocity vector relative to the earth. The computations are fairly complex, and special filtering is often required to eliminate the measurement noise these silicon devices are subject to, so a "low cost" off-the-shelf IMU with decent specs can easily cost $1000 to $5000 US. Infra-red horizon sensing "copilots" are inexpensive and work fairly well as long as they have a clear view of the horizon. Unfortunately, mountains, clouds, haze, buildings, etc., will confuse them. [Chris here: I think IR stabalization is more effective than people give it credit for, and is actually rarely confused in standard usage. Both Paparazzi and AttoPilot are built on it, and they work great. See this interview for more.] In the end, the techniques used to stabilize a UAV will be very much dependent on the intended use, budget, and how comfortable one might be working with sensor fusion, Kalman filters, etc.
Read more…
3D Robotics

SMD BlimpDuino board, assembled

All the necessary components for the new surface-mount BlimpDuino board have arrived, so I spent a fiddly couple hours carefully soldering the tiny parts. (If you're going to solder SMD components, watch videos on how to do it first).

The new SMD board is the smaller one on the right of the picture above, shown with the previous through-hole BlimpDuino board for comparison. As you can see, it's about 30% smaller. As noted in the earlier post, it has several significant improvements over the previous board, including:

  • Two dedicated RC channel input ports, so you can easily fly in RC mode (for testing) or autonomous mode.
  • A new power supply that can handle anything from 3V to 18v and output both 3.3v and 5v. This will allow you a range of battery options, from 2 or 4 AAAs (cheap) to a 7.4v Li-Po (expensive).
  • Includes a port for a servo, for the vectoring thruster
  • Includes ports for a Bluetooth wireless module and a magnetometer (compass)

Here's the bottom view of the two boards (new one is on the bottom):

Read more…
3D Robotics
As cool as our Lego Mindstorms IMU-driven UAV is, it's a shame that HiTechnic hasn't yet released the commercial versions of the prototype servo MUX (RC multiplexer + servo controller) and integrating gyros that make it possible. As a result nobody else can make a similar UAV--we've got the only prototypes that HiTechnic let out. Lattebox does sell a servo controller board (not also a MUX, sadly), but unfortunately it hasn't released drivers for that using RobotC, which is what my Mindstorms autopilot is written in. But now comes good news in the form of a new Mindstorms servo controller board that does have Robot C drivers. Mindsensors has just released a Servo Controller board ($47.75) that can control up to 8 servos. Even better, they're working on a way to attach servos to Lego parts, so you don't have to use superglue and rubberbands like me ;-) (Thanks to the NXT Step blog for the tip)
Read more…

C Compiler for Parallax Propeller Chip

ICCV7 GUI

The BASIC Stamp and Arduino aren't the only microcontrollers out there. The Parallax Propeller chip, as many of you have already discovered, is a more powerful microcontroller. Boasting eight 32-bit processors, it is capable of parallel processing.The major turn off for people to the Propeller was having to write code in the high-level, proprietary Spin language or low-level assembly. There's a good support forum and large object code library, however.ImageCraft has now released a C compiler and IDE for the Propeller as Ken Gracey promised a couple months ago here. You can download a 45-day demo on the ImageCraft website or purchase two different packages (also available at Parallax). The commercial programs are a bit pricey for hobbyists at $99 and $249. Since it's still new, there are only a handful of libraries for it. The IDE interface is a bit clumsy and takes a minute to figure out, but it works. I like the built-in terminal, which you'll have to configure to work with the example codes included (Tools -> Environment Options... -> Terminal tab -> pick COM port & set Baudrate to 57600)ICCV7 for Propeller Features at a Glance: (as listed at the ImageCraft website)
  • comprehensive target support
  • powerful and user-friendly IDE
  • ANSI C compiler
  • optimizations
  • assembler / linker
  • debugger support
  • libraries
  • documentation
  • third party tool support
  • technical support
  • (Additional features, debugger information, etc. listed below)
  • uses Large Memory Model (LMM) to bypass 2K byte limits of Cog code
  • typically 5 to 10 times faster than Spin
  • access Propeller multiprocessing and other Propeller specific features in C
  • write native assembly code and launch it in another Cog for high performance driver
  • built-in terminal
  • support for Parallax's Propellent DLL for program downloading
  • Include libraries such as ASyncIO, VGA Text, etc.
Parallax has promised to begin including C codes in their object exchange, so you can expect to see more useful codes popping up soon.
Read more…
FLY MARINES - Photo of Utah State TeamJoe Brennan, the competition director, has emailed me the results of the AUVSI student competition mentioned in the last post. After a lot of googling, I have discovered some of the UAV team websites. I've also included a link to each of the university websites. If any of these are missing or incorrect, let me know in the comments or PM me (little envelope) and I'll update it.Students searching for a college with an active UAS program should find this information useful.2008 AUVSI UAS Competition Results (listed in order of prize money won by each university)Mississippi State (UAS website, university website) – Wins $10,500 for First Prize Overall, First Place in Mission, 2nd in Orals and Journal, and Prize Barrels for Autonomous Mission Flight, Perfect Identification of the Off-Path Target, JAUS and Identification and Location of the Emergent TargetUtah State (UAS, university) – Wins $8,000 for 2nd Place Overall, 2nd Place in Mission, Honorable Mention in both Orals and Journal, and Prize Barrels for Autonomous Mission Flight, Autonomous Landing, JAUS and Perfect Identification of the Off-Path Target.University of Texas at Arlington (UAS, university) – Wins $5,250 for 3rd Place Overall, 3rd Place in Mission, 1st Place in Orals, 1st Place in Journal, and Prize Barrels for Automatic Takeoff and LandingUniversity of West Florida (UAS, university) – Wins $3,750 for 4th Place Overall, 4th Place in Mission, Honorable Mention in Journal and Orals, and the Safety Prize.Oakland (UAS, university) – Wins $3,600 for Honorable Mention in Mission, Orals and Journal, and three prize barrels for automatic takeoff, automatic landing, and JAUSNorth Carolina State (UAS, university) – Wins $2,750 for Tied for Second in Orals and 3rd Place in JournalUniversity of California at San Diego (UAS, university) – Wins $2,700 for Honorable Mention in Mission Performance and Journal and a Prize Barrel for Autonomous Mission FlightSherbrooke (university) – Wins $1,900 for Honorable Mention in Journals and Prize Barrel for automatic takeoffEmbry Riddle (Blackbird) (university) – Wins $1,900 for 4th Place in Journal and Honorable Mention in OralsUniversity of Manitoba (university) – Wins $1,800 for Honorable Mention in Mission Performance and a Prize Barrel for automatic takeoffEmbry-Riddle (SOAR) (university) – Wins $1,700 for Honorable Mention in Journal and a Prize Barrel for JAUSUniversity of Alberta (UAS, university) – Wins $500 for successfully flying at the competitionUCLA (UAS, university) – Wins $500 for successfully flying at the competition
Read more…

2008 AUVSI UAS Student Competition

The Sixth Annual Association for Unmanned Vehicle Systems International Unmanned Aerial Systems Competition was held on June 18-22, 2008 (see competition website).There hasn't been much buzz generated on the internet about the competition. However, one of the local Maryland newspapers has covered it.Student engineers send creations into aerial competition Webster Field hosts UAV contest
Students representing 16 colleges and universities gathered at Webster Field last week for the sixth annual Association for Unmanned Vehicle Systems International unmanned aerial systems competition.Joe Brannan, the competition’s director, said this year’s teams were among the best he’s seen since the event began in 2003.‘‘Both of the first two top finishing teams” in this year’s event, Brannan said, ‘‘were significantly better than I’ve ever seen” in past events.NAVAIR’s Program Executive Office-Weapons and AUVSI’s local Seafarers chapter co-host the annual competition.‘‘Northrop Grumman is our biggest supporter, with $10,000,” said Brannan, ‘‘with Boeing, Lockheed, The Patuxent Partnership and Johns Hopkins Applied Physics Lab each contributing $5,000.” More than a dozen other defense contractors also support the annual competition financially. This year’s competing teams were awarded a total of $44,850 in prize money.The college competitors must design and build an unmanned aerial vehicle that can be programmed to fly autonomously for a specified time over a specified area and, while airborne, locate and photograph targets on the ground below. When the aircraft lands, the digital information it captured during the flight is downloaded and analyzed.
See SoMdNews.Com for more.
Read more…

Arduino GPS shield with SD card logging.

I saw this yesterday over on the Make blog. Adafruit has come out with a new Arduino shield which looks excellent for UAV usage. The shield has support for several gps modules, and can log data to an SD card.

Even with the GPS and SD card, there are still 5 digital and 5 analog IO open.Here are the details(text below lifted from adafruit.com):GPS shield for Arduino kit with data-logging capability. After building this easy kit, you can create your own geo-locative project.This shield is designed to make GPS projects straight-forward and easy. Plug in a supported GPS module and run any of the example Arduino sketches for parsing GPS data (NMEA sentences), logging to a FAT16-formatted SD flash memory card and storing analog sensor data along with precise location, date and time in CSV format.The shield is designed specifically for use with the EM-406a module: the small surface-mount GPS connector is pre-soldered for you. (It is a high-quality engine with quick time-to-fix and excellent reception, even in downtown New York City!) It can also be used with a Tyco A1035D, EB-85A or Lassen IQ module (see the webpage for more details).GPS module, Arduino, and SD memory card are not included. Please check the parts list to see what is included. NG arduino users should probably also upgrade to an ATmega168.More Info
Read more…