Blogs

All Posts (14047)

Sort by

Today is a "work" day

Posted by Genesis Factor on July 25, 2008 at 3:30pm
@ 1:39PMSo...after sitting outside for about 30 minutes, i'm pretty sure that the antenna on my GPS is shot. I don't know how or why, but it sends NMEA 0183 nicely, but it doesn't seem to like picking up sats. It blinks a few, but nothing steady or strong. I was using my BT for testing purposes, but it failed, so it looks like i am up for purchasing something else. Maybe something else with WAAS. Nothing 5hz though as my software doesn't want to sample that fast lol.My box from all the people came. Of course, i went straight for the Surprise box. I think this is the highlight of shopping from them. You know you got something interesting when you drop the box on you couch and it starts making strange screaming noises for about 30 seconds. Turns out there were some circuits like in those noise maker cards. That should really get my little brother going... But that wasn't the only thing there. Turns out, that there were more Wacom pens, this time including the point, and these Zoran/Oak Technologies Integrated DTV chips that looked brand new. Apparently, they are used to get HD and SD signals, while processing the audio, and are generation9 chips. http://www.avsforum.com/avs-vb/showthread.php?p=5284893#post5284893I got a whole bunch of them, so i think they will hit ebay as a lot. There were other cool things, but i just got the box, and then realized its time to go to work...After talking to my hobby store, it turns out that i can make the left and right ailerons independant. Doing so makes them act like flaps. I find that very...desirable.I started looking back into Pico ITX. sadly, at 250, it is WAY over my budget ATM. Very saddening. I have to wait till someone puts one up for cheap lol. They are tiny though...and, sadly, more powerful than my VIA. They still look great though.@6:36Spent the ENTIRE time making a damn 5V to 3.34V converter with htat LM317 HVP. Took me hours to find the right resistors, then hours to solder it up together. I'm using a circirt write for the last part and i may have jumped my last soldering point. bah. Not only that, but i BURNED MY HAIR. Did you know that burnt hair doesn't smell good good? i need to get a new soldering point. The one i'm using now is a wedge edge and i need a pencil point. Sigh...atleast now i can possible read my Altimeter.In other news, i think i got myself done with reading the GPS through VPL. Now i just need to take those values and use them to go to waypoints. I probably will code that for the rest of the day. Trevor Taylor is starting a new blog, i'd like to think at my request. Yeah right. He's been an invaluable help thus far. i just hope he doesn't get sick of me!http://blogs.msdn.com/trevor_taylor/I downloaded this interesting GPS tracking program while testing my GPS.http://www.gpstm.com/I just thought it was interesting.@9:49Just bought a new gps. WAAS, here i come. 54g, titanium shell. yay me. It will be here tuesday or wednesdayWorking on the GPS code. I now have working variables that contain the course, heading, lat, long, alt, and velocity. This means i can start on my drift code eventually, as well as program in waypoints and stuff. I'm approaching a point where i can start to visualize my base station GUI and work on it. I still need to get some really good topographic maps though. Being 17M about mean sea level means nothing if you can't comprehend that that means that you're on the ground if you're in my yard. Well...it does mean when the ice cap melts, you'll be WAY under sea level... Has anyone gotten the GPS to work with a Topo map? I figure simple subtraction should get you your altitude above the ground--and simple vision can get you above the tree line!
Read more…

The 1 month report

Posted by Genesis Factor on July 24, 2008 at 10:30am
Written on the 20th

Right now, the computer system is almost complete. After numerous discussions on the phone, PC104 boards were added, omitted, and sometimes stared at blankly. The end result is that there is one more PC104 board that had been expected. I guess it was an acquiesce where I wanted to get USB2.0 and was planning to buy an adaptec PCMCIA adatper to go with a dual PCMCIA PC104 board I had. I then found out that ISA bus only has 15.7Mbytes/s (actual power of 2 value, not some 10 based, rounded one), which, well, is not quite much more than the 12mbps of USB1.1. Saved myself $14. That's a lot of money. That's a V-Tail mixer right there. So in the end, after calling Sensoray, and asking them about the 311 framegrabber, which I have 6 of, it came down that logically I need two to accomplish what I wanted, which was dual video in at 30fps. The tech guy was actually VERY helpful, giving me free software links, such as VLC, and explaining bitrates and memory calculations and what not- even telling me that the USB2.0 idea wouldn't work due to the bandwidth of ISA- which ended up being very, very true after some independent research on my part. End result is this: at the best quaility video, which is 640x480, I get (640x480x(3 pixels for color))/8 bits/bytes= 115,200 bytes per frame. 30 frames each second = 3,456,000bytes per second of memory is needed for each frame grabber, or 6,912,000bytes a second on video alone, maximum. These are actually really high quailty, uncompressed images, so i'm not complaining much, especially since that leaves 9Mbytes/sec to do control a 2 axis stepper motor controller. I think it can manage. And what's my last PC104 board? A power supply. Sure, you might think its a waste of a slot, but its a 50Watt PSU and has power out at +12V, +5V and -12V and -5V. I have no idea what I can use the negative stuff for, but i'm sure i'll have fun trying to find something that needs -5V in. :)Bold idea for video recording...As for software, the Sensoray Support guy told me, that for streaming, I can encode using VLC on the onboard computer and capture using VLC on the client side, while viewing the stream. This helps because VLC is free. I like free. Cheap is good, but free and feature filled rocks. Also, he told me that if I wanted to capture a frame, the sub megapixel raw image data of each frame will be in memory for 1/10th of a sec. This means that I can just copy that memory data form that address to another one to save to the hard drive. This will give me a high resolution picture of what i'm viewing for retrieval while a realtime low resolution stream is simul-cast to the client basestation. I guess I can record the massive ~7Mbyte/second recording of the flight on board as well without killing the computer too much, if I really really wanted to. The good news is that chances are, it won't be that big. The resolution of the camcorder is not VGA. In fact, the FPV CCD has a better resolution and larger CCD than the panoramic view. Also the FPV view isn't going to be as important to me as the panoramic camera, so I can get away with shrinking the view a good bit, to maybe QVGA (320x240x3/8)or a bit under a megabyte per second. What this means, basically is that at my realistic highest quality, i'll probably be looking at 2 to 4Mbytes/s- and that is IF my VIA processor can handle it. Kinda missing Intel or AMD right now...Also on the software side, I will be exploring URBI. After seeing how it functions, and wieghing the pros and the cons, the best I can say is that unless I get the full engine and studio, it will have to be relegated to sending and receiving messages from sensors and MSRS, and some vision tracking. This decisions comes pretty hard after seeing that this software can see where faces are and track points in a video and gives me TCP/IP messaging, but its lack of true NMEA decoding, the 1ms per instruction, the fact that to get the full benefit, and the fact that after a weekend of trying with my friends, we STILL haven't gotten URBI to communicate with the local machine, means that, although its a great piece of software, its not a solid fit for this application, but is a SOLID addition for over network communications.Let's get back to the computer...Samtec sent me the cables, and i'm really happy that I called in the day they were made and asked them to lengthen the cables by 1.5” I should have added another half inch, but whatever.

DSC03190.jpgAs far as the computer goes, i'm separating it into 3 modules- Computing, Vision, and Motion. This move into modular organization started with the desire to not have a 3” high computer stack and the idea to spread the weight along the fuselage instead of some crazy 1.5-2 pound point mass. Hopefully this helps the plane's structural integrity.I will be running XPlite as certain option I want to play with are found only on XP. Being the resource hog that XP is, once I get everything going well on the system, i'm cutting out almost all the fat I can to make it as memory thrifty as possible. As long as I have a dedicated 15MB of memory for the video saving, 10 for streaming, and 30 for robotic control,g I will be happy. Out of 256MB, that leaves 201 for whatever fluff MS wants to have for .NET, and support services. If this sucker won't cut it, the PC104 devices and all software are cross-platform and should work great on linux, however I really REALLY wanted to play with some topo mapping software on this...The emergency parachute arrived early last week. Its light, looks strong, and took my 30 minutes to untangle. At 54”, it means my plane will hit the ground at ~15 ft/sec in the event that things happened. I haven't decided whether to mount it on the top of the plane, so that it can land on the landing gear, or on the bottom, so if the computing system breaks off if the plane cracks in half, the really good stuff is safe.

IMG_0774.jpg

The GPS I have, the ZYX-GM11-5U, in its shell, is waterproof, magnetic, and heavy. After removing the shell, it became very, very light. However, I just found out that it doesn't have WAAS. I guess I can't complain, as it was a freebie from a trade...Incoming...On order, and incoming, are several support components. The first was the gear system for the stepper motors to actuate the CCD. I had been staring at it for a while, but I didn't want to get it until I had more stuff to buy because there is something about paying more for shipping than for the item that gets under my skin, even if the item is at a steal of a deal price. I did find, Friday, the day I ordered, an identical pitch gear that will let me use my .06”, or 1.59mm, shaft with these gears, which have a 1.9mm bore. In other words, the hole is too big. Also, from surplus she is an acrylic dome. This is appararently clear gold, as, funny enough, these things are HUGE sellers at Surplus Shed and God was good enough to make me wait a day to order the other stuff. I was told that they would sell out in a couple of days and they JUST put them on. The best part is, that it is just the right size for what I wanted to do. The others that used to be on there weren't. Speaking of which, let me get into that...Attached to each stepper motor will be a that gear that fits, which will then spin a 1.9/2.0mm axle and work the Pan and Tilt. To make sure that the stepper motor will be affected by the wieght, or lack there of of the lens system or the whole camera body, I will be using worm gears right after the adapting gear. This means at the high speeds, if I want to do a rapid rotation, the torque of the stepper motor doesn't need to be anywhere as high as it ought to me, which is good because the faster you accelerate your stepper motor, and the faster you go, the lower your torque is. If you accelerate too fast, you can actually skip, or jump steps, making your readings inaccurate. Also, the worm gearing, would allow for precision movements. The stepper motor that I have does 20 full steps per revolution. This means, using ¼ stepping tricks, I have an 80 step resolution per rotation of motor shaft. Gearing it down, depending on which gears I end up deciding to use, I can really rack up the resolution to, hopefully a degree of rotation per step, which is nice. Not bad for a $4 stepper motor system. What makes it really great is that when I program the camera to track a certain GPS location, using the compass and altimeter, it can actuate the camera with pinpoint accuracy. The optical acrylic dome will be used to make sure that no camera motion translates into unintentional rudder motion:)Finally on order is a LM317HV adjustable voltage regulator from Electronic Goldmine. Mark was nice enough to go over how do to the equation, and I have a bread board set up ready to solder when it arrives in a week. This will take the +5V in from the PSU and make it into 3.3V for my logic level converter ($1.95 @ sparkfun), which lets my 5V parallel port talk to my Altimeter with limited fuss. The helping hands that I got from them in my last order was a BIG help thus far with soldering. I've actually grown to enjoy it. I did pick up a small super solar panel just to check it out, for adding solar to future UAVs, and some micro motors that fit on the head of a dime. What will I build with those motors? I have no idea. The they are tiny tiny! Oh, and after I found out that the two funny looking pens in the Big Surprise Box were $70 Gateway Stylii for the Wacom Based Tablet PCs, you know I picked up another one:).Lastly, I have to order the Vtail mixer. MX80, virturally no stepping.I have yet to weigh the computer stuff as it has changed since we started. However, I hope everything will be light. There isn't much fat left to cut. I changed lenses, lowered batteries, adjusted components...there's not much left without throwing out whole assemblies.
Read more…

Lithium Polymer Batteries and Chargers mini-primer

Posted by Cory on July 23, 2008 at 11:04am
Lithium Polymer batteries are an attractive power source for electric flight due to their high energy density. The combination of lithium polymer batteries and brushless motors now rivals glow power in terms of power and duration.The main difficulty when using lithium polymer batteries is choosing what batteries and charger to use. Batteries are specified in terms of voltage, capacity, and discharge rating.Voltage is generally listed as 1S - 6S. The S number refers to the number of cells connected in series that the pack uses. You can calculate the nominal (mostly discharged) voltage by multiplying the S number by 3.7 volts, so a 3S pack has a nominal voltage rating of 11.1 volts. Fully charged, each lipoly cell will measure 4.2 volts, so a fully charged 3S pack will have measure 12.6 volts.Capacity is measured in Milliamp Hours (mAh). So for example a 2000 mAh 1S pack can be expected to provide a voltage of 3.7 volts at a current of 2000 mA (2 amps) for 1 hour. In a nutshell, more mAh is better (and heavier).One of the more confusing specifications is the C rating. The C rating refers to the maximum sustained discharge rate that the battery can tolerate. The formula is 1/C hours. In the example above where we discharge our 2000mAh 1S pack using a 2amp load for one hour, we are discharging it at 1C. If that pack is rated for 20C, we could discharge it in 3 minutes (1 hour / 20C = 60 min / 20 = 3 minutes) with a load of 40amps (20C * 2000mAh = 20 * 2A = 40A). As I understand it, lipo packs should be charged at a maximum of 1C; so 2 amps maximum charge current for the pack in the example above.The main drawbacks to lipoly batteries are cost and sensitivity to abuse. Now your pack may not burst into tears if you insult its paternal lineage, but it may explosively combust if charged improperly or if it becomes damaged. See here, and here for examples of lipo combustion.I personally use, and recommend using a balance charger, and battery packs that have a balance connector. I would not use any batteries that did not have a balance connector. I use the IMAX B5 charger, which can balance charge up to a 5S pack, and will refuse to charge unless it determines that the battery is connected properly and is of the correct type.

I also use 20C rated packs with JST style connectors(see photo below).

I have found that HobbyCity.com has excellent prices and quick shipping(from Hong Kong).Also PLEASE READ the sticky post about Lithium Polymer batteries on rcgroups for much more in depth (and accurate?) information about the care and feeding of Lipo batteries.Happy flying!
Read more…
3D Robotics

FAQ: Confusing terms explained

Posted by Chris Anderson on July 21, 2008 at 10:30pm

This is a glossary of some of the terms you may read on DIY Drones. Please feel free to suggest others in the comments below!

  • 2.4 Ghz: The frequency used by digital (spread spectrum) radio communications in our applications, including 2.4Ghz RC, bluetooth and some video transmission equipment. This is a different band than the older 72 Mhz band that is used for analog RC communications. To avoid radio frequency conflict is it often a good idea to use 72 Mhz radio equipment when you are using 2.4 Ghz onboard video transmitters, or use 900 Mhz video when using 2.4 Ghz RC equipment.
  • AHRS: Attitude and Heading Reference System. See explanation here.
  • AMA: Academy of Model Aeronautics. The main US model aircraft association. Generally hostile to amateur UAVs, which are banned on AMA fields. But each AMA chapter and field may have slightly different policies, and it's possible to test airframes and some technology on AMA fields without violating the association's rules.
  • ArduCopter: Rotary-wing autopilot software for the APM and Pixhawk electronics
  • ArduPlane: Fixed-wing autopilot software for the APM and Pixhawk electronics.
  • ArduPilot: The overall autopilot project that ArduCopter, ArduPlane, and ArduRover live within
  • ArduRover: Ground and water autopilot software for the APM and Pixhawk electronics
  • Arduino: An open source embedded processor project. Includes a hardware standard originally based on the Atmel Atmega (and other 8-bit) microprocessor microcontroller and necessary supporting hardware, and a software programming environment based on the C-like Processing language. Official site is here.
  • BEC:  Battery Elimination Circuit. A voltage regulator found in ESCs (see below) and as a stand-alone product. Designed to provide constant 5v voltage for RC equipment, autopilots and other onboard electronics.
  • BASIC Stamp: A simple embedded processor controller and programming environment created and sold by Parallax. Often used to teach basic embedded computing and the basis of our autopilot tutorial project. Parallax also makes the very capable Propeller chip.
  • Bluetooth: A wireless technology standard for exchanging data over short distances (using UHF radio waves in the ISM band from 2.4 to 2.485 GHz) from fixed and mobile devices, and building Personal AreaNetworks (PANs). Originally conceived as a wireless alternative to RS-232 data cables. It can connect several concurrent devices.
  • Bootloader:  Special code stored in non-volatile memory in a microprocessor that can interface with a PC to download a user's program.
  • COA:  Certificate of Authorization. A FAA approval for a UAV flight. See this for more.
  • Eagle file:  The schematic and PCB design files (and related files that tell PCB fabricators how to create the boards) generated by the free Cadsoft Eagle program. This is the most common standard used in the open source hardware world, although, ironically, it's not open source software itself. Needless to say, this is not optimal, and the Eagle software is clumsy and hard to learn. One hopes that an open source alternative will someday emerge.
  • DCM:  Direction Cosine Matrix. A algorithm that is a less processing intensive equivalent of the Kalman Filter. See this for more.
  • DSM / DSM2 / DSMX: Spektrum, an RC equipment maker, refers to their proprietary technology as "Digital Spectrum Modulation." Each transmitter has a globally unique identifier (GUID), to which receivers can be bound, ensuring that no transmitter will interfere with other nearby Spektrum DSM systems. DSM uses Direct-Sequence Spread Spectrum (DSSS) technology.
  • DSSS: Direct-Sequence Spread Spectrum is a modulation technique. As with other spread spectrum technologies, the transmitted signal takes up more bandwidth than the information signal that modulates the carrier or broadcast frequency. The name 'spread spectrum' comes from the fact that the carrier signals occur over the full bandwidth (spectrum) of a device's transmitting frequency..
  • EEPROM:  Electonically Erasable Programmable Read Only Memory. A type of non-volatile memory used in computers and other electronic devices to store small amounts of data that must be saved when power is removed, e.g.,static calibration/reference tables.  Unlike bytes in most other kinds of non-volatile memory, individual bytes in a traditional EEPROM can be independently read, erased, and re-written.
  • ESC:  Electronic Speed Control. Device to control the motor in an electric aircraft. Serves as the connection between the main battery and the RC receiver. Usually includes a BEC, or Battery Elimination Circuit (BEC), which provides power for the RC system and other onboard electronics, such as an autopilot.
  • FHSS  Frequency-Hopping Spread Spectrum is a method of transmitting radio signals by rapidly switching a carrier among many frequency channels, using a pseudorandom sequence known to both transmitter and receiver.advantages over a fixed-frequency transmission: Advantages: 1. Spread-spectrum signals are highly resistant to narrowband interference. The process of re-collecting a spread signal spreads out the interfering signal, causing it to recede into the background. 2. Spread-spectrum signals are difficult to intercept. A spread-spectrum signal may simply appear as an increase in the background noise to a narrowband receiver. An eavesdropper may have difficulty intercepting a transmission in real time if the pseudorandom sequence is not known. 3. Spread-spectrum transmissions can share a frequency band with many types of conventional transmissions with minimal interference. The spread-spectrum signals add minimal noise to the narrow-frequency communications, and vice versa. As a result,bandwidth can be used more efficiently.
  • FPV: First-Person View. A technique that uses an onboard video camera and wireless connection to the ground allow a pilot on the ground with video goggles to fly with a cockpit view.
  • FTDI: Future Technology Devices International, which is the name of the company that makes the chips. A standard to convert USB to serial communications. Available as a chip for boards that have a USB connector, or in a cable to connected to breakout pins. 
  • GCS: Ground Control Station. Software running on a computer on the ground that receives telemetry information from an airborne UAV and displays its progress and status, often including video and other sensor data. Can also be used to transmit in-flight commands to the UAV.
  • GIT: A version control system for software developers. The DIY Drones team use a Git-based service called GitHub.
  • Hardware-in-the-loop simulation: Doing a simulation where software running on another computer generates data that simulates the data that would be coming from an autopilot'’s sensors. The autopilot is running and doesn't "know" that the data is simulated, so it responds just as it would to real sensor data. Hardware-in-the-loop uses the physical autopilot hardware connected to a simulator, as opposed to simulating the autopilot in software, too.
  • I2C: Inter-Integrated Circuit. A serial bus that allows multiple low speed peripherals, such as sensors, to be connected to a microprocessor. See this for more.
  • IDE: An integrated Integrated development Development Environment, such as the Arduino editor/downloader/serial monitor software. Often includes a debugger.
  • IMU: An inertial Inertial measurement Measurement Unit. Usually has at least three accelerometers (measuring the gravity vector in the x, ,y and z dimensions) and two gyros (measuring rotation around the tilt and pitch axis). Neither are sufficient by themselves, since accelerometers are thrown off by movement (ie, they are "“noisy"” over short periods of time), while gyros drift over time. The data from both types of sensors must be combined in software to determine true aircraft attitude and movement. One technique for doing this is the Kalman filter (see below).
  • Inner loop/Outer loop: Usually used to refer to the stabilization and navigation functions of an autopilot. The stabilization function must run in real-time and as often as 100 times a second ("inner loop”), while the navigation function can run as infrequently as once per second and can tolerate delays and interruptions ("outer loop”).
  • INS: Inertial Navigation System. A way to calculate position based on an initial GPS reading followed by readings from motion and speed sensors. Useful when GPS is not available or has temporarily lost its signal.
  • ICSP: In Circuit Serial Progammer. A way to load code to a microprocessormicrocontoller. Usually seen as a six-pin (two rows of three) connector on a PCB. To use this, you need a programmer, such as this one, that uses the SPI (Serial Peripheral Interface) standard.
  • Kalman Filter: A relatively complicated algorithm that, in our applications, is primarily used to combine accelerometer and gyro data to provide an accurate description of aircraft attitude and movement in real time. See this for more.
  • LOS: Line of Sight. Refers to a FAA requirement that UAVs stay within a pilot's direct visual control if they are flying under the recreational exemption to COA approval.
  • LiPo:  Lithium Polymer battery, aka LiPoly. Varients include Lithium Ion (Li-Ion) battery. This battery chemistry offers more power and lighter weight than NiMh and NiCad batteries.
  • MAV: Micro Air Vehicle. A small UAV. More here.
  • MAVLink: The Micro Air Vehicle communications Link protocol used by the ArduCopter and ArduPlane line of autopilots. See this for more info on MAVLink.
  • Microprocessor: A microprocessor incorporates the functions of a computer's central processing unit (CPU) on a single integrated circuit or at most, a few integrated circuits (system clock, memory, peripheral device drivers).
  • Microcontroller: A microcontroller (sometimes abbreviated µC, uC or MCU) is a small computer on a single integrated circuit containing a processor core, memory, and programmable input/output peripherals. Program memory in the form flash or EEPROM is included on the chip, as well as a typically small amount of RAM. Microcontrollers are designed for embedded applications, in contrast to the microprocessors used in personal computers or other general purpose applications.
  • NMEA:  National Marine Electronics Association standard for GPS information. When we refer to "NMEA sentences", we're talking about ASCII strings from a GPS module that look like this:        
  • $GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47
  • OSD: On-screen Screen Display. A way to integrate data (often telemetry information) into the real-time video stream the aircraft is sending to the ground.
  • PCB: Printed Circuit Board. In our use, a specialized board designed and "fabricated" for a dedicated purpose, as opposed to a breadboard or prototype board, which can be used and resused re-used for many projects.
  • PCM: Pulse Coded Modulation. A method used to digitally represent sampled analog signals. It is the standard form of digital audio in computers, Compact Discs, digital telephony and other digital audio applications. In a PCM stream, the amplitude of the analog signal is sampled regularly at uniform intervals, and each sample is quantized to the nearest value within a range of digital steps. Primarily useful for optical communications systems, where there tends to be little or no multipath interference
  • PIC: Pilot In Command. Refers to a FAA requirement that UAVs stay under a pilot's direct control if they are flying under the recreational exemption to COA approval. See Line of Sight above.
  • PID:  Proportional/Integral/Deriviative control method. A machine control algorithm that allows for more accurate sensor-motion control loops and less over-control. See this for more.
  • Pixhawk: The next-gen 32-bit autopilot, which succeeded APM. A collaboration between 3D Robotics and the PX4 team at ETH, the technical university in Zurich
  • POI: Point of Of Interest, also known as Region of Interest. Designates a spot that a UAV should keep a camera pointed towards.
  • PPM: Pulse Position Modulation. Signal modulation in which a set number of message bits are encoded by transmitting a single pulse in one of possible 2(number if message bits) time-shifts.
  • PWM: Pulse Width Modulation. The square-wave signals used in RC control to drive servos and speed controllers.
  • ROI: Region of Interest. Also known as Point of Interest (see above)
  • RTL: Return To Launch. Return the aircraft to the "home" position where it took off.
  • Shield: a specialized board that fits on top of an Arduino to add a specific function, such as wireless data or GPS
  • SiRF III: The SiRF is a technology company that has developed a standard used by most modern GPS modules. Includes SiRF III binary mode, which is an alternative to the ASCII-based NMEA standard described above.
  • Sketch: The program files, drivers and other code generated by the Arduinio IDE for a single project.
  • SVN: Short for the Subversion Version-control Number repository used by the DIY Drones (in the past) and other teams for source code.
  • Thermopile: An infrared detector. Often used in pairs in UAVs to measure tilt and pitch by looking at differences in the infrared signature of the horizon fore and aft and on both sides. This is based on the fact that there is always an infrared gradient between earth and sky, and that you can keep a plane flying level by ensuring that the readings are the same from both sensors in each pair, each looking in opposite directions.
  • UAV: Unmanned Aerial Vehicle. In the military, these are increasingly called Unmanned Aerial Systems (UAS), to reflect that the aircraft is just part of a complex system in the air and on the ground. Ground-based autonomous robots are called Unmanned Ground Vehicles (UGVs) and robot submersibles are called Autonomous Underwater Vehicles (AUVs). Robot boats are called Unmanned Surface Vehicles (USVs).
  • WAAS: Wide Area Augmentation System. A system of satellites and ground stations that provide GPS signal corrections, giving up to five times better position accuracy than uncorrected GPS. See this for more.
  • ZigBee (related: Xbee): A wireless communications standard, which has longer range than bluetooth but lower power consumption than WiFi.
Read more…
3D Robotics

Video of the BlimpDuino with vectoring thrusters

Posted by Chris Anderson on July 20, 2008 at 6:30pm

Switching BlimpDuino from modded toy blimps to a custom vectoring thruster platform was the best move we've made so far. Not only does it save a lot of money and fuss, but the vectoring thrusters give us much better control, including total command over the vertical dimension, which had plagued us before when we were using static thrusters. Right now we're testing it in RC mode to understand the flight dynamics better, but the same processor board can fly autonomously. Here's a video of it in flight, showing both turning (with differential thrusters) and altitude control (with vectoring); You might notice that it looks like I've got a breadboard with a tangle of wires controlling the blimp. That's because I do. I'm having trouble debugging the latest BlimpDuino board (the one with built-in RC mode), so I've replicated it on a small breadboard (using every single available row!). It's using this code. Here's what it looks like up close (and yes, those are Lego gears and shafts. Why use anything else?) :

Read more…
3D Robotics

DIY Drones on the Ning home page!

Posted by Chris Anderson on July 18, 2008 at 7:30am

Very cool! We're now a featured network on the home page of Ning, which is the social network service that this site is based on. They told me it was due to our "strong organic growth", which is due to all of you! We now average around 1,500 unique visitors and around 6,000 page views a day, and the growth is accelerating. By the end of today, we should break 1,300 members.
Read more…
3D Robotics

Wall Street Journal: Unmanned Aircraft Face Hurdles

Posted by Chris Anderson on July 16, 2008 at 10:14pm
From today's WSJ: Unmanned Aircraft Face Hurdles By ANDY PASZTOR July 17, 2008 FARNBOROUGH, England -- Unmanned aircraft are rapidly becoming mainstays of military and border-security operations worldwide. But significant commercial uses for the planes aren't expected to emerge for at least another decade because of regulatory and technical challenges, industry and government officials said at the international air show here. Between now and 2017, worldwide demand for unmanned aircraft, their payloads and related ground control systems is projected to top $17 billion, according to Forecast International, a Newton, Conn., consulting firm. But only about $100 million of that demand is expected to involve commercial applications. There has been sharp growth in the number of so-called Unmanned Aerial Vehicles used by the U.S. government in recent years for tasks ranging from battlefield surveillance in the Middle East to tracking wildfires in Western states. On an average day, some 30 unmanned Pentagon aircraft are in the skies over Iraq and Afghanistan. More than half of the 93 planes the U.S. Air Force envisions buying by late 2009 are UAVs, designed to be flown remotely by pilots on the ground. European governments also are showing greater interest. Aerospace companies are talking to the British government about possibly using unmanned aircraft to supplement conventional helicopters in providing security and monitoring car traffic at the 2012 summer Olympics in London. By then, according to Mark Kane, who heads the UAV business at BAE Systems PLC, the market for governmental uses of such aircraft could climb to as much as $10 billion annually, not counting the U.S. It has been widely assumed that there was considerable pent-up demand and momentum for commercial applications. But officials here indicate that may be wishful thinking. Regulatory hurdles, combined with technical and business challenges, are likely to block widespread commercial UAV operations on both sides of the Atlantic for a long time. "I don't foresee any certification in commercial airspace until 2020" or later, said Francois Quentin, senior vice president of the aerospace division of Thales Group SA. Earlier this summer, Federal Aviation Administration officials told a U.S.-European industry conference that preliminary proposals spelling out how UAVs can be widely integrated into the U.S. airspace were at least seven years away, with final regulatory approval unlikely before the end of the next decade. Kevin Brown, who runs Boeing Co.'s air-traffic control unit, said that figuring out how unmanned aircraft can sense and avoid other aircraft -- taking evasive maneuvers if necessary -- "is one of the hardest corners" of airborne-traffic management. In light of such complications, he said, "commercial applications are much further down the road." Nor are potential operators and customers beating down the regulators' doors to speed up their deliberations. What specific interest has surfaced primarily focuses on smaller and simpler UAVs. "Most of the applications we see are below" 300 pounds, according to Yves Morier, a senior European safety official. General Atomics Aeronautical Systems, which has its Predator aircraft deployed by the U.S. military in the Middle East, has looked at selling other UAVs to mining companies looking to use high-tech sensors for prospecting, or to monitor oil pipelines. But customers are scarce because "they're not ready for it," according to Thomas Cassidy Jr., president of a unit. Other advocates of unmanned aircraft also see a long uphill climb to commercial acceptability. "There are safety elements that need to be proven and policy decisions that must come before" UAVs become commonplace, according to Judy Marks, the head of Lockheed Martin Corp.'s air-traffic control unit. Safety requirements are lower for military and governmental versions, because they typically operate in segregated airspace and don't have to worry about potential collisions with airliners or general-aviation aircraft. For military applications, Boeing, United Technologies Corp. and BAE Systems are looking at developing completely autonomous UAVs, intended to fly or hover without any pilot input.
Read more…
3D Robotics

Warning: bad experience with UNAV

Posted by Chris Anderson on July 16, 2008 at 9:18pm
I've had mixed experiences with UNAV (maker of the Pico Pilot) in the past. I like their autopilot hardware, but the software is terrible and it all feels a bit dated and old-school. Based on some early looks I think Dean Goedde's AttoPilot is going to blow the Pico Pilot away (a proper review will be coming as soon as I get my hands on the hardware). But I wanted to be fair to UNAV, so I offered to review their new PicoPilot groundstation sofware, despite its high price ($100). UNAV's Dave Perry sent a disk and then the trouble started. Basically, it's the most amateurish software that I've ever seen offered for sale. It only works on Serial Port 1, which as everyone who has bought a computer in the last decade knows, is no longer the default serial port in the USB era, so you have to go into the windows device manager to remap the serial ports. All sorts of Windows error message pop up, such as "array out of bounds", of the sort I haven't seen since high school programming class. Worst of all, it doesn't do what it says it can do, which is to let you use a point-and-click interface to enter new waypoint data. The manual describes buttons and options that aren't in the software, and the UI is clumsy beyond belief. It may work as a groundstation, displaying aircraft position in real time (I didn't test that), but it doesn't work for data entry, which what I think most people would want it for initially. I could go on for paragraphs... So I wrote Dave with a list of bug reports, hoping that he'd thank me for my time in helping improve the software and offer to send me a new version once it was done. Sadly, that wasn't the case. Here's what he wrote: "I have no doubt that you've had problems with your PICO-GS. But since the program works fine on all our systems and our beta testers didn't report any significant issues and now several customers are successfully using it, I can only conclude that you are suffering from "operator error". Did you spend any time reading the manual ? From your descriptions, I'd take a wild guess and bet you didn't set your windows display to 1024x768 ( as called for in the manual ). If you don't have the time or patience to read the manual and follow the instructions, then I'd agree it would be a waste of time for you to continue with a review." Wow. "Operator error", as you all know, is the insulting term that bad programmers use to "blame the victim". It's a really crappy way to treat customers or, for that matter, reviewers. And when was the last time that you used software that required you to manually change your display resolution? 1997? Note no response to any of the bug reports, and a total refusal to acknowledge that the software simply doesn't work. Anyway, I've had it with them. I no longer recommend the PicoPilot, and I'll be switching our own UAVs to AttoPilots (which will be cheaper and better) as soon as they're out in a month or two.
Read more…

new plan

Posted by Aaron Weinstein on July 16, 2008 at 8:30pm
after much thought, i'm copping out of creating a UAV with video tracking.now the plan is to mount a decent video camera in a controlled environment in order to track infrared signals.blimps will have IR emitters on top, emitting some sort of modulated signal. with some fourier transform and the computing power of my mac, i can then locate and identify a given number of blimps in view.i'm trying to identify true (x,y,z) position of each blimp. i'm thinking of using some sort of pattern recognition (with led's set up in a simple pattern with set dimensions on top of each blimp) or i may just cheat and stick an ultrasound sensor on the bottom of each blimp. this would not be that good since any ground interruptions, like people, will greatly mess with the data. theres a bit to be ironed out of this scheme.anyway, the idea is that the blimps will be cheap (fast and out of control) and the computer is the brains, telling each blimp what to do. this way, i can get the computing power behind the video tracking. as of now i'm thinking of using JMyron in processing, since its easy to use, should be suitable, and i don't know Max/Jitter. I fear not being able to get enough data to have accurate fourier transforms (leakage, aliasing...?). the max fps of jmyron has me on edge.communication between comp. and arduino will use Xbee.been thinking of choreographing movement of blimps in a number of ways. ie: calculate thrust vector based off (x,y,z) and then blimps react accordingly. just a thought. could use some nice E&M potential fields as models.this is all one big changing thought. i just like the idea since it incorporates quite a bit and will provide a lot of new ideas to learn.
Read more…
3D Robotics

Lunch with Arduino co-founder Massimo Banzi

Posted by Chris Anderson on July 14, 2008 at 10:35pm

Massimo Banzi, the co-founder of the Arduino project, was in San Francisco today after spending the weekend at FOO Camp, and he dropped by for lunch with me at Wired. As you know we're huge Arduino fans, so this was a rare treat to learn more about how the project works and where it's going. We, along with Alexandra Deschamps-Sonsino, his business manager at his IT consultancy, tinker.it, happily chatted for a couple hours. Here, from memory, are a few of the tidbits I gleaned.
  • The Arduino roadmap includes new boards with speciality functions, including GPS, ethernet, ZigBee wireless, and cellular wireless.
  • The next generation of Arduino core boards will include Atmel's AtMega line with 64 I/O pins and 256k of memory.
  • After that, the project will move to Atmel's 32-bit line of chips.
  • People are considering implementing a proper debugger on the current Arduino platform, which would be great
  • Arduino could be ported to the ARM chips pretty easily, although there are no plans to do so at the moment
  • The project pays its bills by charging a license fee for officially certified third-party Arduino boards, such as the Arduino Nano
  • People think Arduino was named after a 15th century Italian king. It's actually named after the pub where the founders first started planning the project.
  • Projects such as our own ArduPilot and BlimpDuino, which use derivatives of the Arduino name, are generally fine, but should be sold as "Arduino compatible" rather than called Arduino boards.
  • Massimo and I talked a lot about what the breakout product would be for open source hardware in general and the Arduino project specifically. Odds are that it's no one product, but instead speciality products in different industrial verticals. But we agreed the most fertile ground for open source hardware is in the emerging GPS+wireless space: location-aware, net-connected sensing devices, or what Bruce Sterling calls "spimes" (a neologism combining "space" and "time").
  • Finally, he left me with a gift: one of the last remaining blank boards from the first version of Arduino, back in 2005. Only a few hundred were made. Here's a picture:

Read more…
3D Robotics

Is this for real?

Posted by Chris Anderson on July 14, 2008 at 9:30pm

Spotted in the current issue of Unmanned Systems, the AUVSI magazine: an ad for a sniper rifle/quadcopter UAV (shown above). Absurdly, it says you can take off the rotors and camera and also use the fuselage as an assault rifle! If this were the April edition, I'd think it was an April Fool's joke. The ad is full of typos and the company, AUS International, has a one-page website that looks like it was made in Microsoft Word in about ten minutes. There is no other information about them on the web, and whois says the company website was just registered in April of this year. Apparently they're based in Laredo TX, assuming that they're a real company at all.

What do you think? Is this for real?

Read more…
3D Robotics

ArduPilot code update

Posted by Chris Anderson on July 13, 2008 at 9:00pm
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

Posted by Genesis Factor on July 13, 2008 at 5:17am
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

Posted by Genesis Factor on July 12, 2008 at 2:00am
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

Interview: Andrew Bugera on the 2008 AUVSI Student UAV contest

Posted by Chris Anderson on July 11, 2008 at 5:30pm

(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

Posted by Chris Anderson on July 10, 2008 at 11:00pm


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…