Blogs

All Posts (11086)

Sort by
3D Robotics

BlimpDuino code Beta1.1 released

Posted by Chris Anderson on January 1, 2009 at 1:30pm

Jordi's now finished the Beta release candidate of the BlimpDuino code. Lots of goodies:

  • Full PID loops in both altitude hold and navigation
  • Autosenses if a RC receiver is connected and switches into RC mode
  • Voltage monitoring cuts off power to save LiPo when voltage is low
  • Fully proportional vectoring servo control
  • Goes into altitude-hold-only mode if beacon signal is not seen
  • Code better commented and easier to read
The source code is now located in a proper Subversion repository on Google Code. This version reflects the current operating instructions, both for assembly and flight (RC and autonomous). They've been updated, so if you haven't checked them out recently, please do.
Read more…
3D Robotics

The DIY Drones open source business model

Posted by Chris Anderson on January 1, 2009 at 12:30pm
MAKE magazine noticed my tweet about our business model: "Business model for my open source robotics startup: disclose the cost of everything and charge 40% markup. Want it cheaper? DIY!" What that means is that BlimpDuino, the first product we'll be launching ourselves (rather than through a commerical manufacturing/retail partner), will follow that model. I'll disclose the cost of every part and step of the manufacturing process, linking to sources wherever possible so you can do it yourself if desired. So in this case, the cost of the BlimpDuino kit parts and manufacturing are about $70. 40% margin is $28, so we'd charge $98. Let's say you want it cheaper. Although we get volume discounts on most of those parts, I provide links so you can buy single items for not much more, and avoid our 40% markup (you will be paying shipping and taxes with those retailers, so your savings will be less). The automated SMD soldering can't be done as a one-off, so you'd have to do that yourself (not hard if you've got a bit of SMD experience), saving more money. And perhaps you already have some of the needed parts. Great, more cost savings for you! Let's say you want to make your own company and compete with us, charging just a 30% markup, or maybe just 20%. Excellent! All of our source code and PCB/schematic files are open source and licensed to allow commerical use. If you can make it cheaper or better than us, go for it! The more the merrier. The only requirement of the license is that you credit us for the design and link back here. Let's say you're rich and just want to make them and sell them for cost, with no profit margin at all. Also excellent! More robotics blimps for all! The market grows! Our bet is most of you will be happy to pay us 40% for the security and convenience of making and testing the kit for you. Some of you will want to do it yourself, and that's terrific (we are DIY Drones, after all). And, frankly, I'd be delighted if some Chinese company decides to make BlimpDuino and sell it at half our cost, paying us nothing. We don't want to have to make the hardware if we don't have to (no dreams of being a factory manager here), and if someone can undercut us by that amount with the same or better quality, we will happily move on to designing other things where we can add more value. Everyone wins!
Read more…
3D Robotics

Review: World's first toy autopilot

Posted by Chris Anderson on December 30, 2008 at 12:00pm

WowWee's BladeStar indoor flying machine is advertised as the first toy with an autopilot. From its description: "The exclusive Autopilot Mode with sensor-based navigation enables it to glide through the air, avoiding ceilings and flying away from obstacles." Basically, it's got three IR sensors, two on the side and one on top. The lower sensor on the side is just to communicate with the controller. The one on the top just spots the ceiling and keeps the BladeStar away from it. The one on the side does all the clever work of staying away from walls. Here's a close-up (the sensor is circled):

That's a IR sensor shielded along the rotational axis. The way the Bladestar flies is that two props (tilted slightly up) on stalks spin the body, and the passive rotors are spun along with it, generating lift. Because the entire body is spinning, there's no "front" or "back" of the aircraft. Instead, all controls are relative to the absolute frame of reference (push left and it goes to your left). I presume the way the "autopilot" works is that it has an internal sense of its rotation speed within the absolute frame of reference (it sees the transmitter's signal most strongly once every 60th of second, say, so it must be spinning at 60Hz). So it times its motor controllers to slightly increases the speed of the motors when they're on the side opposite the desired direction of travel, which tilts the Bladestar slightly in the direction of desired travel. As for the obstacle avoidance, it must work the same way: when the IR sensor is showing higher readings (indicating that some warm object, like a wall, is near), the motor speed is slightly increased on that side. Then, as the IR sensor spins away from the wall, motor speed is reduced, and so on, with every rotation. Since the IR sensor is spinning the whole time with the aircraft, the motor speed controller and IR sensor must be tightly linked and pretty much instantaneous, with the speed gradient changing at the rotation speed of the aircraft. (I imagine the really advanced technology in this is the high-speed motor controller). So how well does it work? Pretty well. It does seem to want to stay away from walls, but the ceiling sensor is over sensitive (maybe the problem is that we've got a wood ceiling and it prefers white) and it sometimes plummets almost to the ground after sensing something above it. You can manually fly while it's autopilot mode, but the controls are very insensitive and it's at best a gentle hint of directional control. It's actually most fun to put it in a relatively small room and watch it hover, swinging gently away from the walls and otherwise seeking equilibrium. If you have two, they can also "dogfight", which actually just means that you point your controller at the other Bladestar while yours is in autonomous mode and try to get off three shots before your opponent can do the same to yours. If you're interested in indoor autonomy and optical-flow autopilots, this is worth checking out. It's also a neat toy and an impressive bit of sensor integration. You can buy them at Amazon. I got two for $18 each in a post-Christmas sale, but I see they're now $37, which seems to be the standard price.
Read more…

VicaCopter 3.0 4 U

Posted by Jack Crossfire on December 29, 2008 at 4:00pm
2 months after VicaCopter 2.0, it's VicaCopter 3.0. The autopilot has been moved to quad rotors. All control is done by VicaCopter. Just get 4 motors, 4 ESC's, 4 propellers, & fly. The quad rotor is the cheapest & easiest route to the air.A UAV programming language has replaced the table of waypoints to enable more complicated maneuvers. Automated takeoffs & landings, curved paths, pirouettes, turning towards a point are supported.Go to Vicacopter.com & build it.
Read more…

Project multirotor starting up.

Posted by Ari-Pekka Huttu on December 29, 2008 at 10:00am
I'm gathering information about multirotor controls and different type of ready products on wwwInteresting web site's on this projecthttp://www.draganfly.com/http://www.walkera.com/en1/particular.jsp?pn=UF0+4%23http://www.asctec.de/main/index.php?id=15&pid=14&lang=en&cat=hobbyAnd couple forumsAnd this ArduPilotPro sound good for this projectIf somebody find good website for this project i'm more than happy if you post www address for me :)Sorry my english but i hope you understand me...
Read more…
3D Robotics

ArduPilot code now in beta!

Posted by Chris Anderson on December 29, 2008 at 7:37am
Jordi's finished the first beta of ArduPilot, in anticipation of the board's commercial release. Changes and improvements include:
  • The code is now hosted in a proper code repository (Google Code) for version control and to allow others to contribute to the project. You can find it here.
  • RTL (return to launch) and waypoint modes are user selectable
  • Waypoints have altitude as well as lat/lon
  • GPS parser now returned to ASCII NMEA, for compatibility with any GPS module, 1Hz or 5Hz. Very efficient code will allow it to run at any baud speed the module can support.
  • PID loops used in all control functions
  • Lots of bug fixes and error-trapping inserted
Read more…
3D Robotics

Test flying an EasyStar with EasyGlider wings

Posted by Chris Anderson on December 28, 2008 at 11:00pm

After testing the new 4-channel EasyGlider Pro and finding it a great flier but without as much internal space as our beloved 3-channel EasyStar, people suggested I just modify some EasyGlider wings (which have ailerons) and use them on the EasyStar. So I did that. It was a pretty easy mod--you just have to carve off a little foam from the Easy Glider wings and thread a aileron servo y-adapter through the EasyStar's existing servo holes. How does it fly? Just so-so (see video). It's slower, which is nice, but because the body is now too short for the wings (in aerodynamic terms, the plane is now "short-coupled"), the elevator control is too twitchy and it tends to wheel about the sky a bit. Also, the ailerons tend to create as much drag as they do banking power, so turns can quickly devolve into a wing-over dive. (Ailerons also tend to be pretty ineffective at slow speed, which is often the case with gliders) I'm sure I can fix this with differential throw on the ailerons (make them go down more than they go up) and limiting the throw of the elevator a bit more. But the truth is that both the EasyGlider and an unmodified EasyStar fly better than the hybrid of the two. I'm going to stick with this frankenplane and tweak it to fly better, since I need a beater aircraft I can use for UAV and sensor tests at the park. But I doubt it will ever become my preferred UAV platform for standard use.
Read more…

My Initial UAV Project Proposal

Posted by Jeremy on December 28, 2008 at 9:00pm
Hello all,This is my debut to the site and I will try to continue to post throughout the development of my project. I am a senior in Computer Engineering and for my senior design I have chosen to make a fully autonomous aircraft. I have no experience in flying rc airplanes but I just have extreme interest in airplanes. I have three other team mates (1 computer engineer, and 2 electrical engineers). For the last month, I have been researching rc aircrafts and devices that I will need to use to make my autonomous flight successful.My intent is for the airplane to take off, navigate to gps coordinates, either record video for a specific duration of time or take pictures, then return and land.Another team tried making one of these in the spring of 2008 but not with such high goals. They completed building but were not successful because interference from the microcontroller was preventing the transmitter from having full control.Based off my initial research, these are some things I will have to use:• Spread Spectrum Transmitter/Receiver to eliminate the microcontroller from interfering with manual control• GPS receiver to specify current position and altitude (heard mixed things about gps’s altitude measurement)• A two axis tilt sensor (Looking for one that does 360 degrees)• A SD card to store and retrieve all information on flight and camera output.I have been debating my choice in rc airplane. I heard multiplex has good material for crashing and easy repair. I would really like to use either the predator or a jet design but I have a hard time figuring out how much thrust and extra space models have. As far as thrust goes, I wanted to use ducted fans but I have no idea if this is a “no-no”. I say this because I haven’t seen any other experiments with them. From what I have read, they are better at high speeds but cause a lot of drag at low speeds. The team from last year used a Multiplex Easy Glider Electric. Any suggestions!???A few ideas that I was playing with:• I would like to sensor the battery life with the microcontroller to see if each flight is can be done• Even further if I can somehow make a base where it the plane easily taxi to and charge its battery without human intervention• Retractable landing gear (probably would have to buy the plane like this)• Send information wirelessly when in reach (either though Wi-Fi or Bluetooth• Object avoidance using RF signalsAs you can see, I have ran away with the idea of this project. I am open to all opinions, questions, comments, and random rants. I really need people to challenge my ideas. Thanks and FIRE AWAY!View my next project update HERE.
Read more…

A Loaded Question (I think)

Posted by Paul Marsh on December 27, 2008 at 6:41pm
I am curious to know how members of this community got to where you are with regard to knowledge of controllers and the associated programming. I have been reading this site for weeks, have gone through much of the Paparazzi site and am getting overwhelmed with just where to begin to learn; or more precisely, where to go from here. It's all a little haphazard and disjointed. I even downloaded the Basic Stamp training materials and worked through the exercises (mentally, at least).I can't believe that everyone here is an engineer who just happens to specialize in controllers, so just how have you become so knowledgeable? Where did you begin? What process got you from knowing very little to being able to write code for an autopilot? It almost feels like cheating, now, to go with a plug-and-play autopilot. I really would like to learn the hardware and software, but I'm not getting far on my own.Any suggestions will be greatly appreciated.Thanks,Paul
Read more…

Maiden flight of "The Kodel": autopilot-to-be

Posted by Koen Delvaux on December 27, 2008 at 9:06am
Today my autopilot hardware took the sky for the first time. Although this maiden flight was successful, its only a first step.

The primary goal of the test was to see if the autopilot failsafe mechanisms operated fine:- no lockup on division by zero- instant regain of control after brown-out causing reboot- no lock on uncaught interrupts- handover to servo failsafe positions on RC reception lost- instant regain of control when RC signal returns- no erroneous lockups in main state machine when rebooting whilst in flightAll mechanisms operated fine and none where triggered during normal flight. This proves the autopilot is a stable and reliable platform for airborne operation.Built in mixer test.The autopilot has a built in mixer. On first use you need to tell the autopilot what the channel and mixer arrangement of your transmitter/airplane combination is. To put the autopilot in calibration mode, switch on the transmitter, put all sticks in the center and switch channel 6 to "ON". Now turn on the airplane.At this point you can calibrate the autopilot by putting all sticks in the center and subsequently actuating the aileron stick from full left to full right and back to center, followed by elevator (fullup, then down, then center), rudder (left, right, center) and throttle (zero throttle, max throttle, center). The autopilot will confirm completion of the procedure by turning the rudder full left, then full right and then back to center. From this moment on, you can operate the airplane with the controls as normal, but the calibration values are not saved yet.The last step in calibration is to calibrate the IR sensor for horizon detection. You do this by holding the plane level (or even better: flying it, turn down the throttle and trim for a best glide scope) and switching channel 6 to "OFF". At this moment, calibration values for the transmitter arrangement and the IR sensor are saved to the permanent memory of the autopilot.When you now fly the plane and engage autopilot mode, the autopilot uses the same channel mix,offset and endpoint adjustment as you programmed in your transmitter.This all works fine. When you switch to manual control, channels are passed transparently. This also works fine.Only when using part automatic / part manual control (like when using the autopilot for stabilization alone and operating rudder/throttle manually), the manual controls don't have the same midpoint and endpoint settings than when in manual mode. This still needs to be looked into.I would like some feedback on the first-use calibration procedure. Do you think it is valuable to have support for random channel assignments/mixes/atv/trims? Do you feel the initial calibration procedure it too complicated?
Read more…

SkySailor - 27 hours autonomous flight

Posted by fom on December 26, 2008 at 4:34pm
I came across a nice project for those interested using some solar power for their UAV. It appears that this relatively small plane was able to fly autonomously for more than 27 hours over 874 km (in big circle, but still...).http://robotics.ethz.ch/projects/sky-sailor/http://robotics.ethz.ch/projects/sky-sailor/docs/SkySailor27hFlight-21June2008.pdfhttp://asl.epfl.ch/aslInternalWeb/ASL/publications/uploadedFiles/FSR05_Sky-Sailor.pdf
Read more…
3D Robotics

Arduino debugging tips

Posted by Chris Anderson on December 26, 2008 at 3:00pm

3689308521?profile=original

If you're trying to upload code with Arduino and you get an error message that looks something like this:
"Problem uploading code.....

avrdude: stk500_getsync(): not in sync: resp=0x78
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x78"

(or any other error report when uploading code, aside from the obvious ones like compile errors or choosing the wrong serial port)

Here are the most common causes and things to check.

  1. Did you check the "Set RTS on close" box in the Windows Com port, as instructed in the manual?
  2. Are you selecting the right board? For ArduPilotMega, if your board uses an ATMega1280 processor (the big chip on the APM board will say "ATmega1280") select "Arduino Mega (Atmega1280)". If you've got an ATMega2560 chip, select "Arduino Mega 2560". For the original ArduPilot and ArduIMU, choose "Arduino Duemilanove".
  3. Is the cable plugged into a USB hub? That can sometimes cause trouble. Try plugging it straight into your PC.
  4. Are you using the latest FTDI drivers? Install them if not. If you're still having trouble, try reinstalling them.
  5. Check your solder joints! It's a good idea to reheat and reflow all of the ones you did, just to be sure.
  6. Other errors that have caused this problem in the past include a power source (such as your ESC) that is putting out a voltage outside the acceptable range of 4-7v, faulty USB or FTDI cables, and corrupted FTDI drivers. When in doubt, try a different power source, a different cable or a different PC.

Additional things to check if you're using the original ArduPilot board (not ArduPilotMega):

  1. [For original ArduPilot board only] Is your FTDI cable plugged in the right way? The black wire or side marked "black" should be on ArduPilot's BLK pin.
  2. [For original ArduPilot board only] Are you using the DIYDrones or Adafruit FTDI cable? We've had trouble with other ones...
  3. [For original ArduPilot board only] Is the ArduPilot board powered on, ideally through your RC system or ESC? (You can NOT power it from the FTDI cable; this is a safety measure to avoid power conflicts.)

If those all look fine and you're still getting the error message (especially if you can successfully load code to other Arduino boards), you may have a corrupted FTDI driver or a bad FTDI cable. Try reinstalling on another PC and see if that does the trick. If it doesn't, you may need a replacement FTDI cable.

In some rare cases, a power glitch may have resulted in a corrupted ArduPilot bootloader on the ATMega chip. This tutorial will show you how to reload the bootloader. (Warning--for experts only and requires an AVR programmer. This should not be necessary for most people.)

Other problems can include "Serial port not found" (just check that you've selected the right serial port in the Tools menu. It's the one assigned when you first plugged in the FTDI cable--probably 5 or higher), and the Arduino IDE freezing (try unplugging the FTDI cable. If that doesn't work, just reboot your computer).
Read more…
3D Robotics

Original DIY Drones UAV projects

Posted by Chris Anderson on December 24, 2008 at 2:00pm
These are projects from 2007 and early 2008 that were a lot of fun to do and are still worth checking out for UAV ideas. There is also a PDF/poster that shows how they compare to military and commercial drones.

GeoCrawler 1 (Based on a LEGO Mindstorms autopilot)

Img_4145

GeoCrawler 2 (Based on a cellphone autopilot.)


Viking1

GeoCrawler 3 (Based on a custom BASIC Stamp embedded processor autopilot)


3689308135?profile=original

GeoCrawler 4 (Predator airframe and AttoPilot autopilot)
Read more…

Reading PWM from a receiver

Posted by James Holbrook on December 23, 2008 at 11:30am
Hey all.I know this subject has been covered in many ways, but I am hoping that someone can assist me. I hope someone can have the patience to answer a few of my VERY NEWB questions.What I am trying to do is to send PWM to an arduino on an air vehicle which will then send the appropriate servo controls. Simple enough some may say, but I am in a bind since I just cannot get my head wrapped around this and frankly, I think my research has gotten me confused.My BASIC NEED is to be able to see the pulsewidth values in Milliseconds or in PWM values on Serial Monitor and see the values change as the sticks and knobs are moved.I know some may say, why not just use RC to control the servos without the Arduino? The answer to that is that I want to eventually turn control over to the Arduino like in ArduPilot, and use the Arduino as an IMU sort of. The ArduPilot code has been interesting to analyze but I have not gotten closer to my VERY BASIC need. Being able to look at the ArduPilot Pro code would likely be a very good insight......but that is not available to my knowledge.I have tried ServoDecode, ServoTimer2 and SerialServer libraries and I can capture the PPM for the channels alright on Pin 8, but it does not show me the changes to the pulsewidth when the sticks are moved. I thought I might have what I needed by downloading Chris' RCTest code but since I don't want to move anything like motors for thrust or vectoring and tried to uncomment the Servo stuff it doesn't do anything. When I compile it and run, it does nothing. It just sits there and the servos just jitter and sometimes go to extreme lock..I just need to see the pulsewidths and move SERVOS accordingly.. Jordi in his thread to Hack a receiver was a good piece of code, but the next file he released to read the PPM just displays a scattered array of numbers that don't relate to anything. In that code, and in finding the PPM string I get a value that goes like 214567. Is this a MicroSecond value and how could one convert this to a Milli-Second value? Multiply by 1000?Thanks to all in advance for any help or direction you may send my way.Happy Holidays to all.Jim
Read more…
3D Robotics

How to program the Attiny on ArduPilot

Posted by Chris Anderson on December 22, 2008 at 11:30am

To load the failsafe firmware on ArduPilot's Attiny chip, you need to do the following. 1) You'll need an ICSP AVR programmer. We recommend AVRSIP2. Connect the cable to the correct ICSP port on your board, as shown above. The red stripe on the cable should be on the same side of the connector as the square solder pad on the back of the board. (On our boards that means that the red strip is on the side closest to the processor) 2) Now you'll need to change (turn off) one of the default "fuse" settings in the Attiny45, which divides the internal clock by 8 so it only runs at 1 Mhz. (Explanation of all that and more about fuses are in the excellent Sparkfun tutorial here). Run the AVR Studio program that came with the AVRSIP2 programmer. Ensure that the board is powered on by connecting it to an ESC or other power source! The red LED on the board should be on. 3) To change the fuse with AVR Studio, connect the programmer and go to Tools/Program AVR/Connect. Choose AVRISP mkII. You may get an error (choose cancel). On the "Main" tab of the dialog, click the "Settings" button and pick 125khz and click "Write". Then make sure "Device" is Attiny45 and "Read signature". At the bottom it should say that all's okay. If so, switch to "Fuses" tab and uncheck CKDIV8. Press "Progam", then "Verify" to make sure it's woking. [Note for those who are curious: the AVR programmer can only work at 1/4 of the clock speed of the chip. The Attiny ships with a 8Mhz internal clock, but when that DIV8 fuse is set it's only running at 1Mhz, so the programmer must be running at less than 250khz. Once you clear that fuse and the chip is running at full speed, the programmer can run at 2Mhz, which is 1/4 of 8Mhz]. Your processor is working fine and ready to program. 4) Now you'll need to burn the firmware. Still in the AVR Studio dialog box you used above, go to the Program tab. Where it says "Flash", input our firmware hex file. If you've already downloaded it in some folder, you can select that here. If not, switch to your browser and download this file. Click "Program". All should go well and you'll see the OKs below. If you want to make sure it's working, you can click "Verify". Now you can go back to the "Main" tab and change the Settings to 2Mhz. That's it! The failsafe should be working now. Connect the CTRL lead to channel 5 or 6 of your RC receiver and power on the ArduPilot board. When you toggle that channel a red LED should go on and off on the ArduPilot board, indicating that control of the output channels is being switched from the RC receiver to the autopilot or vice versa. For extra fun, toggle it back and forth fast five times. That should reset the autopilot (for in-air recovery).
Read more…