Blogs

All Posts (14039)

Sort by
3D Robotics

Curt Olson interview part 2: we pause for a hardware moment

Posted by Chris Anderson on January 18, 2008 at 2:00pm
(part one of the interview is here. A followup to the post below, with some more specific advice, is here.)

Before we drill down with Curt on the specifics on one way to use FlightGear for simulation (synthetic GPS generation), I should start with a little primer on the hardware side of simulation.

The first thing we'll need is a way to connect a PC's serial port (or, if you're like me and only have a laptop with no serial hardware, a virtual serial port via USB) to your autopilot. In the example in the next post, we're going just be doing GPS simulation, basically tricking your autopilot into thinking that it's flying around when in fact it's right on your desk.

There are two ways to do make this connection with your PC, where the simulator will be running: in software or in hardware. The first is the easiest but requires you to change your autopilot code every time you do a simulation. The second is a simple plug replacement for your GPS module, but requires some one-time wiring.

The hardware approach:

If you're using a desktop PC with a real serial port, just cut the end off of a 9-pin serial cable and do one of the following, depending on your setup:
  • If you're plugging in your GPS with a standard three-pin RC servo plug, just connect the serial cable's pin 3 to the white wire of the servo plug. (See DB9 in this schematic to know which is pin 3)
  • If you're using a standard GPS connector, such as the little white one in the EM406, the serial cable's pin 3 should go to the connector's pin 4 (Tx), as discussed in this post.
  • If you want to go straight to your breadboard, just cut the end off of a 9-pin serial cable and solder pins 2,3 and 4 to a header strip (break off three pins from a breakaway strip). We're actually going to use only one of those pins--the Tx signal on pin 3--but you may want the others for other simulations later. Stick that headers strip on some unused part of your breadboard and connect it with a wire to whatever Basic Stamp pin you're using for GPS in.
If you're connecting to your PC with a USB cable, as I do, you'll need to buy a USB-to-serial converter such as this one ($20), Plug it into your breadboard and connect V+ and ground as shown in this tutorial. Connect pin 2 to whatever CPU pin your GPS Tx pin is normally connected to. If you're working on a development board, this is probably the easiest approach. It's what I'm doing. [UPDATE: here's a How-To for my particular setup]

The software approach:

At this point you're probably probably saying "But my autopilot is already connected to my computer! Why do it again?" Well, yes, but it isn't connected to your PC on the same wires as your GPS. If you to want have a simple plug trade between your GPS and your simulator, you'll have to use the hardware approach above. But if you're willing to tweak your autopilot code when you're running simulations, you can skip all of that and edit a single line, changing the pin on which your autopilot looks for GPS data.

In our Basic Stamp examples, you'd go to the constant declaration part at the top of the code and edit "Sio PIN 15" (or whatever you've set as your GPS-in pin) to "Sio PIN 16". That's because "16" is the Basic Stamp code for the dedicated serial-input pin (SIN, physical pin 2), which is normally used by the Stamp Editor during the download process. That will be different on different processors and programming languages, so revise accordingly if you're using something else. Just make sure you're telling the autopilot to look for GPS on the same pin it normally uses to communicate with the PC.

And now to simulation...

Now you can use the same cable and hardware setup you normally use, but the autopilot will look to the PC for GPS NEMA sentences. And those will now be generated not by a real GPS module, but by a simulator.

So now we can turn to the next part of the Curt Olson interview, which will talk about how to get that simulator running.

Read more…
3D Robotics

Interview: Curt Olson on FlightGear and UAV simulation

Posted by Chris Anderson on January 18, 2008 at 7:30am
I'm delighted to start our interview series with Curt Olson, the creator of the cool open source FlightGear flight simulator and a UAV engineer in real life. When I started researching how to use simulators (GPS and IMU) to ground-test UAVs (aka "hardware-in-the-loop" simulation), I found that Curt had done some of the most interesting work in this area. And because here at DIY Drones ignorance isn't a bug, it's a feature (learning in public helps others learn along with us), I thought I'd go straight to the source to find out how it's done.

We had a long email interview, so I'm going to break it into several parts. First an introduction and overview of the sort of UAV simulation you can do with FlightGear:

Q: Can you tell us a bit about yourself? We know you're the creator of FlightGear, but would love to hear a bit more about your day job and UAV projects. Also family, hobbies, odd things that nobody knows about you ;-)

Currently I'm employed in the Mechanical Engineering Department of the University of Minnesota, however that is only 50% time right now and I've been told that as of June, the department will be unable to renew my contract. <insert plug for Curt looking for possible employment or uav consulting projects> :-)

My primary focus at the university has been engineering support for a very advanced driving simulator:

I've been involved in a couple UAV projects with the U of MN aero department. Tons of pictures and information here and here.

I am also involved in a UAV project with ATI, sponsored by NOAA. This has been a lot of fun because it involves designing a new airframe from the ground up, quite a few unique operational challenges (launch from a small boat, recovery in the ocean) and [twist my arm] a couple trips to HI.

Family: I'm married, two daughters, age 4 + 7 (by the time the readers read this anyway.) And 2 dogs. Before kids came along I enjoyed skijoring here in MN with our 2 huskies:

Hobbies: RC model airplanes since high school, small plastic and balsa models before then. I also play a little soccer in an old guys league in the winter and still try to chase around the young guys on my summer team.

Odd things? I was a big Duke's of Hazzard (tv show) fan in high school. My latest FlightGear invention is a tribute to simpler times ...think my sense of humor is optimized to entertain myself and probably not many others. :-)

Q: What are the range of options in UAV simulation/testing? We know about basic GPS NEMA sentence generation, but what else is possible, from course drawing to IMU simulation?

I think if you are careful and clever, you can test just about every element of your system on the ground. That's actually not a bad idea because it's often hard to trouble shoot something that's a couple hundred yards away that you don't have physical access to and have no way to look inside and poke around.

Q: What can FlightGear offer as a simulation engine? Advantages over other options, such as dedicated GPS sims or MSFT Flight Simulator plug-ins? Special suitability to amateur UAVs, etc.

FlightGear can be useful in a number of ways throughout the lifespan of a UAS project. Such as:
  • You can do a physics (aerodynamics) model of your model in flightgear and use that to do handling qualities test and/or turn the flight control gains.
  • You can create a 3d model of your UAV with animated control surfaces for the purposes of visualizing your flight and analyzing the aircraft performance. There's certain things where you need to stare at tables of numbers and graphs, but for some things, seeing what the thing does in 3d and in real time can be helpful. Certain things that just aren't right can jump out at you visually where as you might miss it if you just looked at plots or raw numbers.
  • It's possible to leverage FlightGear as a component for hardware in the loop testing. FlightGear can model the aircraft dyanmics, send "fake" sensor data to your flight computer, and accept control inputs from your flight computer.
  • It's possible to test your flight control system or higher level control strategies purely within flightgear before implementing them on an embedded flight computer.
  • As you begin the flight testing phase, you can feed your flight test data back into the aerodynamics model and make the simulation that much more accurate and useful.
  • Operationally, you can use FlightGear to replay/visualize past flights. You can feed the telemetry data to FlightGear in real time for a live 3d "synthetic" view of the world. You can overlay an advanced hud, steam gauges, or glass cockpit type displays. [example shown below of real video next to synthetic FlightGear view of the same flight]

  • If you have net access, you can connect the slaved copy of FlightGear to the FlightGear multiplayer system and then anyone in the world with a web browser could track your UAV live using our multiplayer map system (google maps based.)
  • You could also have multiple UAV's participating in the FG multiplayer (MP) system and you would be able to see each other in your respective synthetic displays.
[Next: a drill-down on getting FlightGear to drive an IMU]

Read more…
3D Robotics

Best way to simulate a UAV flight?

Posted by Chris Anderson on January 15, 2008 at 6:00pm
While it's cold and windy outside, the best way to test our UAVs may be simulations. As best as I can tell there are at least two ways to do this, but I can't say I really understand either of them well enough to implement:

  1. Generate synthetic GPS data with your PC's serial port, see what the autopilot does as a result. Here's a GPS NEMA sentence generator. The fake course data can be plotted in Google Earth. This is just for navigation, of course.
  2. Generate synthetic GPS and IMU sensor reading, and display the autopilot responses in a flight simulator. Curtis Olson, the creator of FlightGear (open source flight simulator) does that with his UAVs. No idea how. Impressive, though...

Has anyone tried either of these? Something else? Can you tell us how to do it?


Read more…
3D Robotics

Making a UAV fail-safe

Posted by Chris Anderson on January 14, 2008 at 10:03pm
A big part of the DIY Drones credo is keeping it safe, and by that I don't just mean adhering to FAA regs and staying away from built-up areas, but also keeping it safe for your expensive UAV! The truth, as we all know, is that computers crash and that aircraft flown by computers crash harder ;-)

The aim of a good UAV is to have a fall-back system by which a human pilot can take over if (when!) the autopilot goes funky. There are at least three ways to do this, all of which we feature in one or more of the autopilots here:

  1. Completely separate the navigation and stabilization systems and ensure that the stabilization system can be overridden by manual RC control. That's what we do in GeoCrawlers 1, 2 and 3, all of which use the FMA Co-Pilot for stabalization (it controls the ailerons and elevator, leaving just the rudder for the autopilot and navigation). If the autopilot crashes, you can still fly the plane with ailerons and elevator alone, something we end up doing all too often! (The FMA system always allows for manual input)
  2. Mechanically separate the autopilot and RC control systems. In the case of the Lego UAV ("GeoCrawler1"), the Lego Mindstorm system moves the whole rudder servo back and forth, but the RC system can always turn the rudder servo arm, allowing it to override the autopilot if need be.
  3. Install a stand-alone "MUX" or servo multiplexer, that allows the operator to switch control from the RC system to the autopilot and back again with the gear switch on the transmitter, even if the autopilot catastrophically fails. As far as I know, there's only one commercially available one of these out there, and that one, by Reactive Technologies (shown), is not cheap ($99). Still, if you install one and give it an independent power supply, there should be no reason why you can't regain control of your plane no matter how wonky your onboard computer has gone.
What you should probably not do is exactly what we do (temporarily) with the Basic Stamp autopilot (GeoCrawler3), which passes RC signals through the Stamp chip and synthetically recreates them on the other side for the servos. If that program has a bug or the chip otherwise freezes, you've basically lost your rudder and elevator, which could make keeping the plane in the air difficult indeed. You'll still have control of the ailerons and throttle, but good luck getting the plane down in one piece if your program decides to crash with the rudder and elevator at full deflection.

So the Basic Stamp UAV project might be a good place for a MUX. Anybody know of a cheaper one? (This guy is looking for one, too)

Read more…
Developer

First Arduino IMU test

Posted by Jordi Muñoz on January 14, 2008 at 8:44pm

I'm trying to develop an IMU for my Arduino-based UAVS (heli) project. In my first test I just used a three-axis accelerometer, but it didn't work because the motor vibration generated too much noise. I then tried it just with gyros, but of course the the gyros drifted. So I learned through experience what everyone already knows: that the onlyway to make a good IMU is by mixing accelerometers with gyros andKalman Filters, which is eventually what I did ;-)

I ran a test to see how my IMU is responding, and I made a line chart to see the results. The test consists of rotating the device to 70 degrees and then shake it, to see how the filters reduce the "noise". It looks pretty good:


The samples was taken every 20 miliseconds, the blue line is just accelerometer and the red line is Accelerometer+Gyros+KalmanFilters.

Source code here: ArduIMU Beta1

Special thanks to Tom Pycke



Read more…
3D Robotics

The Paparazzi UAV team's amazing conference demo

Posted by Chris Anderson on January 14, 2008 at 2:30pm
A mindblowing report from Hackaday:

"The 24th annual Chaos Communications Congress in Berlin is already off to a great start. The first talk we attended was [Antoine Drouin] and [Martin Müller] presenting Paparazzi - The Free Autopilot. Paparazzi is an open source hardware and software project for building autonomous unmanned aerial vehicles. The main hardware board has an ARM processor and GPS. It uses inertial and infrared sensors to determine orientation and altitude. The four infrared thermopiles measure the air temperature. The ground is warmer than the sky and if you compare the temperature in the direction of each wing tip your can tell what angle the airplane is at. It's really that simple.

They did a pretty amazing live demo. Using the network connection they controlled a UAV flying in France and another in Germany. Both planes were streaming live video from belly mounted cameras. One relaying through a home DSL connection and the other through a UMTS cellphone. They were able to change way-points on the fly and issue flight pattern commands. There is a ground crew at each location with a security pilot that will switch the controls to manual if things get out of hand."

The slides, which are a must read, are here. The video of the presentation is here.

I'm giving a DIY Drones talk/demo at Etech in March with blimp UAVs. But it will be hard to top this.
Read more…
3D Robotics

Is the Arduino platform better than the Basic Stamp for UAVs?

Posted by Chris Anderson on January 12, 2008 at 8:30pm
Jordi has opened my eyes to the Arduino platform, which is being described as a "Basic Stamp killer". Is it a good candidate for autopilots? Well, let's look closer. Arduino is an open source embedded processor platform, based on the ATMega168 CPU, which has more memory than the Stamp and is a lot cheaper. There's proper development software available and SparkFun has a full line of dev boards and other accessories. Its programming language looks like C but should be easy enough to learn for people who know Basic. It started as an Italian project (it's named after an Italian king) and still has a European flavor, so that may explain why we in the US don't know it well. But Jordi, in Mexico, had done some very interesting work in exploring its potential as an autopilot platform. His main project is the "Arducopter" (shown at right), which has resulted in some very nice code, such as this navigation routine. In his comments, Jordi (BTW, he's just 21) described some of the cool things he's doing with it, which I'll simply quote with links here: "This is my first test with Boarduino (a breadboardable version of Arduino) controlling servos and using an accelerometer from a Nintendo Wii. Right now I'm using Gyros and Kalman filters. I even wrote code to read PMM signals, the GPS is finished and working pretty well, the IMU is in beta, and I'm developing an altimeter using I2C technology and high quality pressure sensors." Here are some links he provided: I'm intrigued. I don't see anything here we can't do with Basic Stamps with a little fiddling, but I have to admit that certain projects look like they would be easier with the Arduino, mostly thanks to its greater memory and full range of variable types, including floating point. Anybody else looking seriously at Arduino?
Read more…
3D Robotics

Basic Stamp autopilot tutorial, part 5

Posted by Chris Anderson on January 12, 2008 at 6:12pm
In my last tutorial, I showed you how to upgrade from the 12-sat Parallax GPS module to the much better (and cheaper) 20-sat EM406. Unfortunately, my instructions weren't compete and I've spent a frustrating week actually trying to get it to work properly. I've now diagnosed the problem and fixed it, so this tutorial will help you avoid the problems I ran into.

Just to remind you, the main difference between the Parallax GPS board and the EM406 is that the EM406 is a bare module that you've got to wire properly onto your Basic stamp dev board, and the EM406 outputs raw NEMA "sentences" that you need to parse rather than specific requested data fields as is the case of the Parallax board (trust me, the slight hassle of working with the 406 is more than made up for by its great performance).

In my instructions last time, I advised you to follow this tutorial that was in Servo Magazine this month. Unfortunately it has a serious error in the diagram of the EM406 pins--it actually has the Rx and Tx pins reversed. This took me days to work out, and eventually I went to the manufacturer's datasheet for the EM406 to get it right.

The only three wires you need are 1, 2 and 4. That's ground, V+ and Tx. (pin 5 is another ground, which I've also connected to pin 1 in the picture, but I don't think that's actually necessary).

If you click on the photo above, you can see that I've soldered those wires onto a header strip, plugged it into the Basic Stamp dev board's breadboard, and connected the Ground, V+ and Tx wires. I connected the Tx wire (the white one in the picture) to the Basic Stamp's pin 9, although you can choose any unused pin you want.

Here's the Basic Stamp code that will test the setup above. As always, change it if you're using a different pin for the GPS Tx or if you're using a Stamp other than the BS2p (by modifying the "GPSBD CON 500" as instructed by the comments on that line)

The EM406 should get a sat lock (LED starts blinking) in less than a minute, indoors or out. When you run the above code, your debug screen on your PC should start showing NEMA sentences with lat, lon, and a few other data points. You can then decide what data fields you want in your autopilot and write your code accordingly, or incorporate a full GPS parser as discussed in this series.

Previous posts in this series:

Tutorial 1 -- Servos
Tutorial 2 -- Reading the Rx
Tutorial 3 -- Adding GPS
Tutorial 4 -- Upgrading your GPS
Read more…
3D Robotics

Announcement: pages for other UAV projects and autopilot code (by processor type)

Posted by Chris Anderson on January 11, 2008 at 10:00pm
By popular demand, I've added two pages on this site, linked to from the text box on the front page
Given the constratints of the social networking platform we're on, the way these are set up is as blog posts that can be edited at will. Ultimately, I'll allow you to edit these pages yourself, wiki-style, but for now if you'd like your project to be included, please leave a comment on the relevent page or private message me (envelope icon above) and I'll include the links. No doubt I've missed a bunch of projects. Let me know what you'd like me to add.
Read more…

The Christmas Gift

Posted by uavdiyutah on January 10, 2008 at 10:09pm
The sale plane that i was building is about 3/4 of the way done, and i had to stop (unexpected guests and no where left in the house to build it), but for Christmas i was givin a small 95% ready to fly park flyer. now its the 29.99 special from Harbor freight called the yellow bee. but its actually a fun little airplane to play with until i get my other one done and get a radio for it. i have already crashed my "yellow bee" on the first test flight i lost control and it landed in a neighbors window well. but damage was limited and it still flys well.

i have also found one of the video systems i think i might use. it is called the FlyCamOne2. its about 100 bucks and is 3"x1-1/2"x1/2" in size and only weighs 1oz it does 640x480 video and 1280x1024 still. it uses SD cards for storage, and the camera lens can be rotated 90 degrees so you can point it basically any way you need. if any one has used this or the previous version i would be interested to hear how it works before i buy one.

Read more…

Building a UAV for photo mapping - Trial Balance

Posted by Paul Gregory on January 8, 2008 at 10:38am

I have now finished all the sub-assemblies of my Cularis, so before sticking the fuselage together, I decided todo a trial balance to check on the COG. Here it is, poised on the wingdimples. The airframe, with installed servos, but not motor, batteryetc. weighs 1.1kg including the two steel balls located in the tailsection.


In the photo below, you can see the Pentax A30 camera mounted down in the cockpit area which I expanded to a width of 60mm by machining out 6mm from each side wall. I then stuck the perspex side panels with thick CA as recommended to increaserigidity. The large nut and bolt weighs a little more than thePico-Pilot NA which have now bought second hand. There is a 3P2500mAH LiPo battery pushed up under the wing root with the stockMultiplex motor, ESC and spinner up front and a Multiplex dual conversion 7 channel Rx.


The real trick that made this all work was moving the elevator and aileron servos to the rear. Because of the 4:1 leverage, some 35gm of servos is now balancing 140gm of camera. It needs some careful work to machine out the interior ofthe tail section to mount the servo, but the result is worth it. I will post more details of my modifications in the Cularis building thread on rcgroups.




Building a UAV for phot mapping - Previous Posts


  1. The Goal
  2. Camera Selection
  3. Packing it all in
  4. Autopilot
  5. Kit Mods
  6. Trail Balance



Read more…
3D Robotics

Which Multiplex powered glider makes the best UAV platform?

Posted by Chris Anderson on January 6, 2008 at 11:00am
Like everyone else, we're huge fans of the Multiplex EasyStar, a cheap, sturdy and good-flying powered glider. It's a great aerial imaging platform (see our how-to here), but a bit small for a full suite of autopilot electronics. Fortunately, Mutiplex makes some bigger birds, too: the $195 Cularis and the $70 EasyGlider (shown).

People (such as our own Paul Gregory--see his build tips here) have tended to go straight for the larger Cularis in seach of room and lifting power for bigger cameras and more electronics, but Stewart Long from Pict'Earth, who tried that, has just written in with some cautionary advice and a surprising recommendation.

He says:

"The increased size of the Cularis has not allowed us to use larger cameras that we could with the Easy Glider. the wings are larger, and with more lift, but the Cularis that we set up was too nose heavy , even without a camera. We tried counterbalancing the setup by placing the servos in the rear of the plane, but the plane remains overly nose heavy. We have also had a difficult time with the wing spar, servo connection and latch mechanism. Because of this the plane flutters a little bit like the Easy Star.

So, the Cularis provides some interesting features, but I see a lot more bang for the buck with the Easy Glider. The materials cost is half with the Easy Glider, the flight of the wing is great, and the center of gravity in the Easy Glider allows for more tinkering. From an RC operations standpoint it was not very difficult for me to start using the Easy Glider after starting with the Easy Star.

Here is the setup for the Cularis:

  • Motor Dymond Gunther
  • ESC Hacker 70
  • Prop Cam 14X9.5
  • Lipo generic 2s3p (2 cell x3)
  • (Approx 450 watts, with 75 degree climb.)

Easy Glider (photo setup shown):


 Easy Star:

  • Motor: "Multiplex Permax 480-4D , and Multiplex Permax 480-6D. The 4D is more powerful, and will fly a heavier plane. With the 4-D full throttle is too high, I take off with about 60% throttle. The disadvantage to the 4-D is that it wears down the lipo battery over time. This has not proven to be a big problem though, because we have lost batteries at a higher rate"
  • Speed Controller: "Castle Creations Thunderbird" 36 Amp
  • Propeller: 6/4 plastic. "The first number is for thrust, the second number is for speed. The higher the number, the higher the value. For our platforms we want to have more thrust than speed."
  • Lipo: 3 Cell 2100 mAh


Read more…
3D Robotics

Blimp UAV project: spec'ing it out

Posted by Chris Anderson on January 5, 2008 at 11:03pm
As discussed in the white paper, the aim of the blimp UAV project is to build a prototype for an indoor aerial robotics contest. This will require contestants to design, build and program a blimp that can navigate a course inside a gym-sized space and potentially do certain tasks such as spotting targets and landing at intermediate points.

To do this, our blimp has to be able to know its current position in six degrees of freedom: x, y, z, yaw, tilt, pitch. This is hard enough outdoors, but it's especially tricky indoors, where GPS doesn't work. So what we're planning is a blimp with the following components, including a cool IR beacon-based system (shown) to simulate GPS:

  • Blimp: BlubberBot envolope (46"), which can carry a 125 gram payload
  • Inertial sensors: two-axis accelerometers for tilt and pitch, magnetometer for yaw.
  • Position sensors: Evolution Robotics NorthStar system, which uses stationary IR beacons in the room as reference points (not unlike the way a Roomba makes its way back to its charging station)
  • Altitude (Z) sensor: untrasonic sensor with 3-meter range
  • Three motor system (differential thrust for left and right, and one for up/down), like the Plantraco Microblimp
  • CPU: Undecided, but may well be Pic-based.
  • Usual I/O, including serial/USB for programming and a servo controller for at least two micro servos (use to be decided)
  • Power: 200 mah LiPos (5.4 grams)
  • PCB: Approx. 1x1.5 inch board (1/32” thickness for weight savings)
  • Programmable in RobotC
Seems very doable within our weight limit. Next step: CPU selection and building a breadboard prototype with the NorthStar board.
Read more…
3D Robotics

Blimp UAV project: The beginning

Posted by Chris Anderson on January 5, 2008 at 10:00pm
Aside from building this site, my two big UAV projects are taking the Lego Mindstorms UAV to the next level (it's mindblowing, although I can't talk about it yet!), and building a prototype blimp UAV as a platform for a potential indoor aerial robotics contest.

This particular blog series is going to be about the development of the second of those, the creation of a sub-$1,000 fully autonomous indoor blimp UAV.

For the curious, my white paper on why we picked blimps, rather that quadcopters, helis, microlight planes, etc, is here.

Now that we've settled on blimps, we had to start by trying what was already out there. To get a feel for how blimps handle, I got the best (affordable) RC blimp: the Plantraco Microblimp, which is a lovely bit of superlight engineering, with a 2.4ghz RC system, fully proportional controls, and LiPoly rechargeable batteries (it's the silver one on our dining room ceiling at right). First lesson: blimps have HUGE latency issues. Basically the inertial momentum means that you need to anticipate all of your turns by many seconds. That means that an autopilot will not only have to know where it is in six dimensions (x,y,z yaw, tilt, pitch), but also have an internal model of the blimp's response time (which ranges from slow to slower). Fun!

The second blimp we checked out is the only autonomous blimp you can buy (without a security clearance). It's the BlubberBot featured in Make Magazine last month (it's the the big white one in the picture above). I was particularily intererested in it because it's about the size we want for our blimp (46"--a bit less than four feet--long) and I was curious about how other people handled blimp autonomy.

(BTW, those weird pink and blue things hanging off the bottom are children's forks and spoons for ballast!. I wanted to find out how much weight that envelope could carry [answer: about 125 grams] and so I filled it with more helium than recommended. That meant extra ballast, which meant raiding the kids' silverware drawer.)

It took all day to build the kit, which requires soldering all the components to the PCB and connecting four sensors (light left and right, touch at front, and, randomly, cellphone proximity) and four output components (sound, vibration and two LEDs). It uses a pre-programmed ATMega168v CPU and two motor driver chips for the two props. No vertical control.

You can see the PCB at right, with the cellphone sensor hanging off the bottom. Overall, it's missing quite a bit of what we want in a proper blimp UAV, from programmability and location awareness to proportional control. It's designed to seek out lights and bounce off walls, and I suppose under the right lighting conditions it might actually do that (mostly it just wanders about). But we need more.

One thing that I did learn from the BlubberBot, however: There's no need to keep the motors going all the time, as you might with a plane. The BlubberBot pulses the motors, then coasts while it reads its sensors, then pulses them again in 10 or 15 seconds. I think we'll do the same with ours. A great way to save power!


Read more…

UAV Electronics Integration

Posted by Nullified on January 5, 2008 at 8:30pm
For those of you who have not heard of this project, I am a member of the Missouri University of Science and Technology UAV Team (www.aessuav.org) and we are building a UAV to compete in the 2008 Australian UAV Outback Rescue Challenge. We are currently in the processes of integrating all of our electronics that will go into our UAV (you can find previous blog posts about our progress on our site). I'm not sure if our project would really fit into the average DIY Drone user's price range, but here it is anyways.

UAV Electronics Test Rig


I recently started assembling a test rig to integrate all of the electronics that will be going in the UAV. Byperforming all of this integration on test bench, the finalinstallation and configuration will be performed much faster. This willalso allow us do our HIL (Hardware In the Loop) simulation with all ofthe components connected.

You may have noticed that there are two large NiHM battery packs, these will soon be replaced by two (11.1V 3200mAh) Lithium Polymer battery packs, saving us about half a pound of weight and significantly increasing our power capacities. Although for bench testing all of the electronics will be powered of off a standard ATX computer power supply. The next step is the get the HIL simulation working with theautopilot and the it’s simulator, this part has been a bit finicky butit should be resolved now.

As a team we have also discussed possible strategies for image acquisition and processing. We had previously planned on simply acquiring VGA resolution video at 30 frames per second, but after reconsidering what altitudes we will be required to fly at to cover the search area in a reasonable time we quickly realized that VGA video would not provide the resolution we need to identify a human target onthe ground from an altitude of 400 feet. We have since decided it wouldbe best to use a much higher resolution still camera taking images atset intervals and tagging them with the GPS coordinates and theorientation of the UAV.
Read more…
100KM

propeller auto pilot

Posted by crystal garris on January 5, 2008 at 1:15pm

here is the code i have to date it uses the proto board and the Hitachi H48C Tri-Axis Accelerometer Module.started with code by Paul Hubner . works good but cant get passthrugh to turn of .not much time but should get to fixing it soon.plan on using the Kalman filter object with an imu soon as well

Download mainuav.spin

Download pass rc reciever.spin

also need "BS2_Functions[1]", "FullDuplexSerialPlus","Servo4",&"H48C Tri-Axis Accelerometer" from the parallax object library

Read more…
3D Robotics

The DIY Drones Mission (aka The Five Rules)

Posted by Chris Anderson on January 4, 2008 at 10:00am

3689297692?profile=original"Because $10,000 $5,000 $1,000 is too much to pay for an autopilot, especially one that doesn't do exactly what you want."

An Unmanned Aerial Vehicle (UAV, colloquially known as a "drone") is basically an aerial robot. As we define it, it is capable of both remotely controlled flight (like a regular RC aircraft) and fully-autonomous flight, controlled by sensors, GPS, and onboard computers performing the functions of an autopilot. Our UAVs include airplanes, helicopters, quadcopters and blimps. Most of them are under five pounds, and some of them (especially the blimps) can be used indoors.

We are focused on non-commercial ("recreational") projects by amateurs, although pros are always welcome too. Reasons to make your own UAV range from a fun technical challenge, student contests, aerial photography and mapping (what we call "GeoCrawling"), and scientific sensing. We are primarily interested in civilian, not military, UAV uses here.

If you're new to all this, start here.

DIY Drones is a community based on the Ning social networking platform, and anybody who registers (it's free and easy) can post their own blog entries like this one on the front page, along with starting discussions in the sidebar at left or uploading videos below that. Your registration gives you the ability to do a lot on the site--so feel free to post anything you think will be of interest to this community!

There are other amateur sites out there, from the discussion forums of RC Groups to individual blogs, but DIY Drones is explicitly built as a social network, which means that the community is as important as the content. We're also focused on the most accessible end of the amateur UAV world, with the aim of potentially including high school students.

This means we emphasize amateur UAV projects that are:

  1. Simple: The aim of this project is to create new amateur UAV platforms, including those that could be used for a FIRST-like contest appropriate for students. While we're at it, we'll make amateur UAV development easier for everyone.
  2. Cheap: The target cost of all of our platforms is less than $1,000. You can buy a very good autopilot system for $10,000, but that's not our approach. Cheaper is better, especially with students and schools.
  3. Safe: We follow the current interpretation of the FAA guidelines on small UAVs. Recreational use (non-commercial), under 400 ft altitude, line of sight, "pilot in the loop" and onboard safety systems that always allow for manual control in the case of malfunction. We're building experimental platforms that demonstrate autonomy and the capacity to do real useful UAV work, but we test them in controlled settings. If you want to fly miles out of sight or map cities, we're going to assume you've got the proper FAA clearance or we don't want to know about it.
  4. Participatory: Share and others will share with you. That means that whenever possible, we open source our code and post it online. Everything on this site is published under a Creative Commons "attribution" license, which means that anyone can use or repost it, as long as they give credit to the original author.
  5. Civil: This is a community site of peers helping each other. Bad behavior, from rudeness to foul language, will be deleted. Generosity and kindness is often rewarded with reciprocal behavior and help.
Here are the full set of Site Policies:

  1. Civility is paramount. Treat others with respect, kindness and generosity. Some of our most expert members are people who were once total n00bz but were helped and encouraged by others, and are now repaying the favor with the next generation. Remember the Golden Rule. Don't be a jerk to anyone, be they other members, moderators or the owners. This is not a public park, and you have no constitutionally-mandated right to free speech. If you're creating a hostile or unpleasant environment, you'll be warned, then if it continues you'll be suspended.
  2. No discussion of politics or religion. This is not the place to discuss your views on the wisdom of military use of UAVs, any nation's foreign policy, your feelings about war, or anything else that is inclined to turn into a political debate. It is our experience that the rules for good dinner party conversation--no discussion of politics and religion--apply to online communities, too. DIY Drones aims to bring people together, and we find that discussions of politics and religion tend to polarize and drive people apart. There are plenty of other places to discuss those topics online, just not here.
  3. Ask questions in the discussion forum; inform others in blog posts. Submitted blog posts that are just questions and should have been posted in the discussion forum will not be approved. The moderators may or may not message you with the text so you can repost in the right area. To avoid losing your post, put it in the right place from the start.
  4. Blog posts are for informative topics of broad interest to the community. They must start with a picture or video, so the image appears on the front page on the site and gives a sense of the topic as well as inviting people to click in for more. Videos should be embedded (paste the embed code in the HTML tab, not the Rich Text tab). The post should also include links where appropriate. Don't make people do a Google search for what you're talking about if you can provide a link. 
  5. The Discussion Forum is for questions and tech support. We prefer to do all tech support in public, so that others can follow along. If you have a problem, please describe your particular system setup completely, ideally with a photograph, and pick the right forum tags so that others can find the thread later.
  6. No discussion of military or weaponized applications of UAVs. This site is just about amateur and civilian use.
  7. No discussion of illegal or harmful use of UAVs will be tolerated. Responsible use of UAVs is at the core of our mission. That means conforming with all laws in the United States, where this site is based, and insisting that our members elsewhere follow the laws of their own countries. In addition, we feel that part of our responsibility it to help the relevant authorities understand what's possible with amateur UAVs, so they can make better-informed policies and laws. So we have encouraged all relevant regulators, defense agencies and law enforcement agencies to become members here and even participate to help them do that, and many have. In addition, if we see any discussion of UAV use that we feel is potentially illegal or intended to do harm, we will bring it to the attention to the relevant authorities, and will comply with any legal request they make for information about users (although we don't know much that isn't public; see the next item).
  8. Promote safe flying. Moderators may delete postings that they decide are unsafe or promote unsafe activity. This is a judgement call, since it is also healthy to have public discussion about why certain activities are unsafe, but the decision as to whether to leave a post or edit/delete it is at the moderators' discretion. 
  9. Your privacy is protected, up to a point: This is a social network, so everything you write and post here is public, with certain exceptions: 1) Your private messages are private. Administrators are unable to see them, nor can anyone else other than the recipient. Members must not make private messages public without the explicit permission of everyone involved. 2) Your IP address is private. We are hosted on Ning, which controls the server logs. DIY Drones administrators can only see your username and email address; they cannot see your password and do not have access to your account.
  10. Do not publish personal emails or PMs without permission. This is a violation of expected confidentiality (that's why they're called "personal messages") and is grounds for banning.
  11. Do not type in ALL CAPS. It's considered SHOUTING. Posts in all caps will be deleted by the moderators.
  12. Absolutely no personal attacks. It's fine to disagree, but never okay to criticize another member personally.
  13. Share. Although we are not limited to open source projects, the ones that tend to get the most participation tend to be open source. Don't wait until your code or design is "finished"--post it as it is, and you may find that others will help you finish it faster. The best way to contribute is with your creativity--we love data, code, aircraft designs, photos of UAV projects, videos of flights and build logs. Post early and often!
  14. Keep comments open: Authors of blog posts and discussion threads technically have the option to close their comments or approve them before they appear, but we ask members not to do that. We want to encourage a free flow of conversation and blocking or delaying comments only interferes with that. The Moderators are standing by to ensure the conversation remains on-topic and civil, so please leave your comments open and let them do their job.
Read more…