All Posts (14054)

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…

New panoramic system

after a whole bunch of trial and error, i'm happy to say that my the parts camcoder i will be using for the panoramic system is 100% operational, set up, and ready to be mounted. The biggest problem was getting the "no tape" warning off the main screen. It looks like i'll be only needing a servo for the zoom. I've spent the day researching my stepper motors and gears, pushing through basic equations and what not. In the end, if i get this gear set i want (and without using legos :) ), i should have a massive amount of torque, at a decent power/velocity and <1 degree rotational resolution for the pan, and <0.5* for the tilt. I am not sure how fast i can drive the motor, but i'm aiming for a 1-2 second fast spin for the pan (from rest), with a much slower spring for fine tune adjustments. worse comes to worse, i can use lego gears lol.

?action=view&current=Picture008.jpg

The camcorder is an ES75 from canon. It was from an old project, stripped of its viewfinder for a near eye display--before i found out that you need a CRT and this model has the new LCDs. Then i got a couple of the Wild Planet head sets and called it a day:). I'm really happy i never sold the box of the parts from all those camcorders.Picture is good and it weighs MUCH less than my other mega lens. I'm debating whether or not to use the digital zoom. I figure i should because it only has 270K pixels, or just under VGA resolutio, and i will be streaming the video anyways.My biggest two problems are the size/shape of the camera, and the lack of a steady shot. Despite being lighted, i needed to keep the main board attached to the lens, and have the rear panel button board attached for the power on and DC IN. This leads to an L shape that makes for a difficult mount and make sure it doesn't break. The ideal thing would be a 38 pin extension cable wit the right connectors, but i don't know where to find on of those yet. As for the lack of steady shot, i'm hoping some software will make that a non issue.

?action=view&current=Picture009.jpg

Read more…

Back to earth...running

so i got my pred today. Thanks again to helomix. Let's just say a whole bunch of mixed emotions arose when i saw it, from happiness that it was finally here, to the nervousness set in when i realized that i'm truly at the point where i need to put my skills where my mouth is, i mean, I already did it with money, to disappointment when i realized i have to cut back on a few items i my project :-P.

Picture002.jpg

There are two things i realized when i saw the pred- its is smaller than i imagined and there is less open space in the fuselage. I still love it though, but i think i will DEFINITELY need to get a smaller camera lens for panaoramic. In fact, i'm pulling it from the project for now. I will try again with a broken solid state camcorder when funds allow. At least then i have the option of recording

?action=view&current=Picture003.jpg

There are now TWO 14oz objects that need to go into this pred- the battery and the computer. Suddenly, a 5000mAh battery didn't seem like such a good idea as now i have to fit it OUTSIDE of the body (pics of that monster later). This means two things- i need proper placement. To do the CoG and moment equations correctly, all my engineering training says that i should build the basic plane first (motor, servos, stuff like that) and then find the "empty" CoG. After i do that, i weight what i want to add, run the equations in again, and see exactly where i need to put that to put the CoG 2" behind the wing. The problem is i am thinking i should put the battery directly over the computer, on top of the fuselage, in order to make sure that the CoG doesn't go to where the computer is and move outside of the body of the plane. I learned a big lesson today- Get the plane first before you build on it.

Picture007.jpg

That being said its time to quit whining, and do what i set out to do.I bought some fiberglass cloth to do reinforcements along the fuselage and the body. Sure, no more spiffy camo detail, but whatever. I will also have to cut into the body where the servos go because the ones i have are about a 1/4" too long. I'm not going to change though, because they have a 2Kg/cm torque, which may be necessary. I'll waterproof certain components with some sort of plastic wrap, while building a box for the computer. I'll take pics when we're done building.

Picture001.jpg

As for the software side, progress is slow until i get some action on the DSS front. Basically, i am close to completing the 2 main services that i need, one for a parallel port and SPI, and one for the serial port for the servo controller, but since i'm not done, i can't do squat. Very frustrating. I have completed the networking aspect, thanks to Vincent M., AKA Agashka, using winsock. it sends 8 variables (x,y, z, throttle, zoom in, zoom out, tilt up/down, tilt left/right) and receives two basic streams of data (NMEA data, and Altimeter data). Hopefully this will keep data transmissions fast and light, while also doing it simply. Camera will still be held by VLC.Future developments that i have been intensely looking into have been laser range finding and then LiDAR. I now know almost exactly what i need to do to make the thing work...sadly, it will be too heavy and expensive for this plane, and maybe any other of my projects. Also, the MAXIMUM range of the rangefnder is 1.2Km. Funny thing, i realized that there is a MUCH easier way and cheaper way to get rangefinding. It may not be 100% accurate, but it will be a decent approximation and suffice for the time being. You know your the height, your orientation, and you know the angle of the camera. Pretend the earth is flat (for Long Island, that's actually not something you need to pretend). Where your center pixel lies, you have your distance, +/-20 meters.Pics will be added later.
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…

Propeller: Google Earth GPS SD Card Logger

One of my goals for my UAV has been to use Google Earth as the tool to display flight paths, and next to create a waypoint list visually. Why reinvent the wheel right?Well I'm halfway there. This logger writes Google Earth Compatible KML files onto an SD card for direct use with Google Earth. Plug it in to your PC and click on the KML to see your path. I posted this last month on the parallax.com site for vetting and it seems to be working fine.This uses the propeller development board and simple connections to the GPS and SD card. The pinouts are specified in the software documents, but I've left out the hardware connections (all of a few resistors). These are referred to in the SPIN routines available on the parallax website. I removed the navigation routines, though there are vestiges, as this embodiment is really to show the logging features.The full forum and comments a can also be seen at the parallax site, including the downloads, image and sample KML.http://forums.parallax.com/forums/default.aspx?f=25&m=271943&g=272218Paul
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…