Blogs

All Posts (14047)

Sort by
Developer

New DIY Open-Source MUX...

Posted by Jordi Muñoz on December 6, 2008 at 4:00am
This an Open-Source multiplexor that will allow you switch between manual or auto mode using only one channel of your remote control, also include a "build-in" picoswitch with three states (down, middle and up) + reset mode, and all through one channel.This MUX is intended to be use in low power and simple autopilot systems. In case your uController do not have enough timers to control servos, you should try the pololu servo controller and interface it with the DIY MUX.The attiny firmware is also Open-Source and you can modify it as you wish, you will need winavr+avrstudio4 and of course an ISCP programmer, like this one.To buy a PCB click here.Part list from DigiKey:3 x 1k SMD(0805) resistor P1.00KCCT-ND1 x 10k SMD resistor P10.0KCCT-ND1 x .1uf capacitor PCC1828CT-ND2 x LEDs SMD(0603), the color is optional:Red: 160-1181-1-NDGreen: 160-1183-1-NDBlue: 160-1646-1-ND1 x Attiny 85, ATTINY85V-10SU-ND1 x Mux 74LS157 296-14884-1-NDThere is also an optional component (D1), (in the top of PSEL label on the schematics), this is just a protection diode, if you are not planning to use it you should make a solder bridge between the pads..Eagle files:ardumux4_v1.zipAttiny firmware:antifail_system.rarJust to remember, when i used to have no idea of basic PCB design rules:

Now i try to fallow some rules, for example NEVER use the autorouter. 100% by hand..
Read more…
3D Robotics

Jack Crossfire's quadcopter now doing autonomous takeoff and landing

Posted by Chris Anderson on December 5, 2008 at 7:49pm

For those of you who follow "Jack Crossfire"'s entertaining diaries of his autonomous helicopter projects. He struggled for more than a year to get a conventional helicopter to reliably fly autonomously, then switched to a quadcopter in hopes of a smoother path. Seems like it worked like a charm. In just a month, he's designed and built a platform and got it not just flying autonomously, but taking off and landing autonomously, too! Here's his latest post with details.
Read more…
3D Robotics

New board to allow use of 5Hz GPS modules with ArduPilot

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

(Shown at left above, with a Locosys LS20033 GPS module for size comparison) ArduPilot is designed to use the solid and reliable EM406 GPS module, which is a 5v, 1Hz device that works well under most conditions. But if you want more precise navigation, you may want to upgrade to the 5Hz Locosys module that Dean Goedde is using with AttoPilot. That's a 3.3v module, so you can't just plug it into the ArduPilot board. Instead, Jordi has designed a special daughterboard that does the following: --Converts ArduPilot's 5v power to 3.3v power --Provides a EM406 connector, so it's a direct plug-in replacement for the EM406 --Provides a break-out connector so you can add a wireless modem, such as a Zigbee. --Power LED We may release this as a pre-made product, but in the meantime you can make your own. Buy the board from BatchPCB here. Components:

Eagle files (schematic and PCB) are here.

Read more…
3D Robotics

Review: Multiplex EasyGlider Pro for UAV use

Posted by Chris Anderson on December 4, 2008 at 7:43pm

We all love the Multiplex EasyStar, but for autopilots that separate stabilization and navigation, its lack of ailerons is a limitation. (Stabalization--FMA Co-Pilot in our case--uses ailerons and elevator; navigation uses rudder and throttle). The next plane up in the Multiplex family is the EasyGlider, recently upgraded for brushless power with the EasyGlider Pro. It's bigger (71" wingspan vs the EasyStar's 54"), has ailerons and can lift more weight. But it's also a lot more expensive ($256 with power package, as opposed to just $66 for the EasyStar), and the front-mounted motor takes up a lot of interior room. How suitable is it for a UAV? I got one and tested it out last weekend. Here's my report:

As with all Multiplex kits, the build quality is excellent and the Elastopor foam goes together nicely with CA glue. If you get the optional power kit, all you need is four servos (2x HS55 and 2x HS81), a Deans connector, and a LiPo battery, along with your RC kit. You can put it together in one evening. I of course added a FMA Co-Pilot, and mounted the sensor above the wing. The plane is slightly nose-heavy in this configuration, but nothing a bolt or two in the tail can't cure. But when you put in all the equipment, you'll spot the first big disadvantage of the EasyGlider Pro: it's got less room inside than the smaller EasyStar! That's not just because the motor and the ESC are in the cockpit. It's also because the servo and pushrods are, too. In the EasyStar, they're all on the outside, leaving the cockpit entirely open for radio and camera equipment, but in the EasyGlider you have to share a narrower (albeit longer) space with everything else. You can see the two side-by-side in this picture:

The EasyStar is closest to us (it's the beat-up one!) and the EasyGlider is behind it. Even though I've added a camera-trigger servo on the EasyStar it still has more unused space than the EasyGlider. The only way to add more space to the EasyGlider would be to create a second "floor" layer above the servos and put autopilot equipment on that, under the foam canopy. Otherwise, anything you stuff in there risks tangling up with the servos, pushrods and other wires. Obviously, the other problem with the EasyGlider is that it's hard to put a forward-looking camera in it, since the prop is in the way, something which isn't a problem for the EasyStar with its pusher prop. There are people who have modded the Easy Glider to put the prop in a pusher configuration with a pylon, but that's too much work for me ;-) As for flight, the EasyGlider flies really well and the ailerons give more precise control than the EasyStar's rudder. But it's also a bit harder to fly for beginners, and if you crash nose-in, you're going to damage the prop and maybe the motor, which isn't a problem with the indestructable EasyStar. I found that the FMA Co-pilot had a hard time maintaining level flight at high gain settings, but that may be due to calibration problems. I'll have to test a bit more to see what the problem is. Bottom line: I prefer the EasyStar, but since I need the ailerons I'm going to continue working with the EasyGlider and create an autopilot layer for the cockpit as mentioned above. What I love about these foam powered gliders is that you can fly them anywhere and they can land on any surface without damage. So as an autopilot test platform, they're great for quick trials and experiments. But I wouldn't recommend the EasyGlider as the optimal UAV platform for serious use. For that, you'll want the usual high-wing trainer, even if that means having to take off and land from a proper runway.
Read more…

Octopilot -- Open source propeller-based autopilot

Posted by Ben Levitt on December 3, 2008 at 11:24pm
small.jpgOctopilot is open source autopilot hardware and software for radio controlled planes. It is based on the Parallax Propeller microcontroller, and uses a 5-degrees-of-freedom IMU plus a GPS and proximity sensor to stabilize and navigate your plane.It can be enabled/disabled through an extra channel/switch on your transmitter, and when switched on, stabilizes the plane and navigates it back to the starting location, where it will circle. It can also optionally trigger external actions, like taking a photo or dropping an item, when it reaches a waypoint.Coming soon: multiple waypoints, stabilization of inverted flight, on-board TV-out, and more.If you're interested in helping out, there's lots to be done! Swing on over to the project page and join the octopilot group.http://code.google.com/p/octopilot/
Read more…

New (Possibly useful) PIC

Posted by Tyler Nighswander on December 2, 2008 at 8:48pm
SparkFun has a new PIC that seems to have some very nice stats.It's not quite as useful now that the ArduPilotPro is almost ready, but it does look to have much better performance.The datasheet shows the most power hungry mode at 75mA max, and 80MHz, which might make processing GPS data in a UAV a whole lot easier, and a 32 bit processor and a ton of IOs are always nice to have.
Read more…
3D Robotics

Final ArduPilot production candidate

Posted by Chris Anderson on December 1, 2008 at 6:02pm

Third time's the charm! This is the ArduPilot board that's now going through the production process. If it passes QA, we're good to go! No big functional changes, but we added the option to use external power or RC receiver power, and we've broken out unused Atmega pins so you can use them if you want. Some other wiring changes, so you'll want to use the latest code. Eagle files here.
Read more…
3D Robotics

Awesome simulation setup for ArduPilot!

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

Jordi's really outdone himself this time! He created a amazing full-featured simulator for ArduPilot that does the following:

  • Uses the servo output from the autopilot or RC controller (depending on which one is selected by the MUX) to "fly" a plane in the X-Plane flight simulator, via a custom interface he's designed around this ARM board.
  • Also flies the plane in manual RC mode with RC controller output going through the MUX and then into the ARM board.
  • Displays the plane's attitude and other flight telemetry with a custom Ground Station built in LabView.
  • Uses LabView to simulate the FMA Co-Pilot, stabilizing the plane in flight using PID loops.
  • Display the plane's position in a moving map using Google Maps, which also shows waypoints.
As you'll observe in the videos here, you can see the plane's: 1) Flight in X-Plane 2) Glass cockpit with full telemetry and debug data in the Ground Station 3) Overhead position and path in Google Maps Here's a diagram that shows how everything is connected:

You'd note that he's using using the ArduPilot Pro board with just one atmega installed for this. (the other atmega does stabilization, which we're doing in the LabView Ground Station for this demo.) It's the board we use for development, since it's easy to replace atmega chips. It's best to have at least two computers and three screens for this, as you'll see in the video. Video 1 (above) just shows the setup Video 2 (below) shows the plane taking off in manual mode, switching to autonomous and flying to first two waypoints Video 3 (below) shows the plane flying to the last two waypoints, and switching back to manual mode and landing. Video 2 Video 3 Full code and instructions on how to create this simulation setup coming soon.

Read more…
3D Robotics

Autonomous blimp art shows

Posted by Chris Anderson on November 28, 2008 at 10:05am

Jed Berk's original Blubberbot was the inspiration for BlimpDuino. It isn't programmable and the sensors don't work predictably, so it just sort of bumbles around, bouncing off walls and floors. But it's lovely to have around and taught us a lot about what to do (use N20 motors and a 54" envelope) and what not to do (complicated and fiddly plastic gondola). We used it as the original prototype platform for BlimpDuino before we moved to modded toys and then our own custom vectoring servo platform. Anyway, Jed, who is an artist, continues to run art installations with Blubberbot, and they're always cool to see. Make has a full roundup .
Read more…
3D Robotics

Using the 5Hz Locosys GPS with Arduino/ArduPilot

Posted by Chris Anderson on November 27, 2008 at 2:00pm

Sparkfun is now selling the excellent 5Hz Locosys (Mediatek chipset) GPS that Dean Goedde uses in ArduPilot. We're developing a daughterboard that will allow this 3.3v module to be a plug-and-play replacement for the 5v, 1Hz EM406 GPS that we're currently using for ArduPilot. In the meantime, if you want to start playing with a 5Hz GPS with Arduino here's some code and instructions to get you started.
The code is Jordi's new NMEA parser for the Locosys GPS. It's checksum verified, rocksolid, continuous, no delays, loop rate is about 32000hz. It uses pointers, so it's efficient.

You have to configure the Locosys for the first time you use it. It's very easy, you just need an FTDI cable. Be sure to connect the GPS to a 3.3 volt source. (We'll do this setup for you in the commercial version)


Instructions (please use the picture above as reference):

1-Run Realterminal and open the port @4800bps, you should see all the NMEA stuff, is not check the connections..
2-Now make sure you have checked the options marked with the green arrow... +CR +LF
3-Copy and paste this code: $PMTK251,38400*27 to the box indicated with the red arrow.
4-Then click the "Send ASCII" button indicated with the blue arrow..
5-Then the NMEA should disappear, and starting showing strange values. Go back to the "Port tab" (yellow arrow),
close the port, and choose the Baud "38400", and open the port again. You should the NMEA data again... =)
6- Then go back to the "Send" tab, and copy&paste this code: $PMTK314,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*28 then click Send, this should turn Off all sentences except GGA and RMC
7-Copy&paste now this code: $PMTK220,200*2C This should increase the updates to 5hz... (WOW!!!)..
8- Now you are able to connect the GPS module to Arduino, (only connect the RX pin to the TX of the GPS)
9-Then upload the code above, and open the port monitor, you should see Lat, Lon, Course, Speed, Altitude, Fix Position... like this:
46024504 8050998 312 0 519 1 (and yes you now know the exact position of my Swiss Chalet =P)...

If you want other setup codes for this GPS, you can find them in this datasheet.

Code explanation

If you'd like to understand the NMEA parser code a bit better, here are some of the library functions that it calls (all from the standard C++ library):

  • First of all pointers, which are very easy. They just give you the memory address where a variable is allocated in the ram: info
  • Then the strncmp(), better know as String Comparator. We use it to compare the header of the NMEA string "$GPGGA": info
  • Then strtl(), which means String to Long Variable. It converts a string number into a long variable: info
  • Then the strtok(). This is the string tokens, which looks for tokens in a string, for example commas ",", the ones used to separate values in the NMEA sentence: info
  • The atoi() will convert strings to integers: info
  • If you want to know all the available functions, see the library called "strings.h", "stdlib.h": info and info
(All these libraries are already installed in the Arduino IDE.)
Read more…
3D Robotics

ArduPilot Assembly Instructions

Posted by Chris Anderson on November 26, 2008 at 9:30pm
Welcome to ArduPilot! Here's how to compete your new board: You should have received the basic ArduPilot board with all surface-mount components already soldered and the essential firmware already loaded on the chips. All you've got to do now is to solder on some connectors and load the autopilot software. For this first part of that you'll need a strip of breakaway headers, and three female-to-female servo connectors. You'll also need an FTDI cable if you don't already have one. The first thing to do is to solder on the connectors. Many of the holes on the board are for optional upgrades, such as sensors and additional RC channels, but for the basic board you only need to solder on three breakaway connectors. From your strip, use a pair of pliers or a snipper to cut off two 3-pin segments and one eight-pin segment.

First, solder the two 3-pin headers and the one 8-pin header in the circled holes above. The long side of the headers should be on the side with the chips. The easiest way to do this is to place all the pins in the holes, then place a pad of paper on top of the pins. Holding the board and the pad, turn them over so the board is on top of the pad, with the pin nubs showing through the board. Then solder just on pin in each segment. Turn the board over again and make sure the connectors are straight (if they aren't remelt the solder joint on the one that's tilting and finger-push it upright...make sure you're not touching the pin you're heating!). If they're all straight, solder the rest of the pins.

Next, we'll solder on the RC inputs. You can either use three more 3-pin headers in the holes circled in red above (in which case, you'll need female-to-female cables to connect to your RC receiver), or make and use "pigtails" instead, which is one less connector to potentially fall off. If you want to make the pigtails, cut two 12" female-to-female connectors in half, and split the wires on each end down about a half of an inch. Strip the insulation of each about 1/8th of an inch in. Now we're going to solder them in in the three sets of holes marked in red above. Black goes on the outside. This is a bit of a fiddly soldering job and it's easier with a helping hand. If you'll be using the ArduPilot 2.0 or above code, you'll need to add a few more connectors for sensors and a calibration jumper. Solder a five-hole female machine pin header strip in the five holes marked in blue at the top in the picture above. Then solder a regular two-pin header in the holes marked in blue at the bottom. [Note: the board comes from the factory set up to get power from your RC system. If you want to power the board from a separate power source, you can do so--the board has a built-in power regulator that can take power from 5v-15v. Instructions to make that change are here.] Now the basic hardware is complete. It should look like the below (connectors just used in ArduPilot 2.0 and up are marked in blue):

If you are making an ArduPilot 2.0 or above, you must now connect the FMA sensor to the ArduPilot board. Instructions for doing that are here. Now it's time to connect everything, plugging your female-to-female cables (or pigtails) into your RC receiver. CTRL should go to channel 5 or 6 (whichever has a toggle switch; if you're using ArduPilot 1.0 the other channel, which should have a knob, will be used to control the FMA Co-Pilot). For ArduPilot 1.0: Input 1 should go to your receiver's Channel 3 (throttle) and Input 2 should go to Channel 4 (rudder). Then plug your ESC (motor speed controller) in the ArduPilot Out 1 and the rudder servo into ArduPilot Out 2. Here's a diagram that shows all the components and how they should be connected (Rx is your RC receiver and ESC is your electronic speed controller):

Here's what ArduPilot 1.0 looks like in real life:

ArduPilot 2.0 and above: Input 1 should go to your receiver's Channel 1 (aileron) and Input 2 should go to Channel 2 (elevator). If you've got a three-channel plane like an EasyStar, connect the rudder servo to Out 1. For a four-channel plane with ailerons, connect the aileron servo to Out 1 (the rudder, which ArduPilot doesn't use in this configuration, can remain connected to your RC receiver for manual use). The elevator servo should be connected to Out 2, as shown below. Throttle is connected directly to the RC receiver; it is not used by ArduPilot in this configuration. Here's a diagram that shows the whole setup:

Software Now it's time to load the software. Download and install the latest version of Arduino, if you don't already have it. First, it's best to run some test code to ensure your board is set up properly. Dowload "ArduPilotNE" from our Google Code repository. This code just flies the plane in the NorthEast direction, so you can test it in the air, but for now, let's just test it on the ground by walking around with the autopilot on and GPS locked and watching the rudder move, as shown in this video: To load this code, power on the board by plugging your ESC into a battery or using some other 5v power source (do not attempt to just power the board with the FTDI cable. We did not connect the power pins on the FTDI port to the processor to avoid power conflict when the board is powered by the Rx and you're using the FTDI as a serial monitor). The red power LED should go on. Now plug your FTDI cable into the board (with the black wire or, in the case of the Sparkfun board, the GND pin on the side marked "BLK") and plug it into your computer's USB port. Here's what the Sparkfun FTDI board looks like when it's plugged in properly:

Then in the Arduino software in the "Tools" menu make sure you've selected the right serial port (the FTDI cable will create a new one, which is probably port 5 or higher). Also ensure that the board selected is "Arduino Diecemila or Arduino Duemilanove w/ATmega168" if you have one of the older 168-based boards, or .Arduino Duemilanove w/ATmega328" if you have the newer 328-based boards. At this point unplug your GPS module if it was plugged in. The Arduino code will not load if the GPS module is attached, because they share the same serial port. Once you've uploaded the code, you can plug your GPS module back in. Please remember this in the future as you're uploading code: you must ALWAYS unplug the GPS first. Load the ArduPilot "sketchfile", ardupilot.pde, which will load the rest of files in tabs. Now press the "Upload to I/O board" icon (the little arrow point to the right). Nothing should happen for about 30 seconds, and then at the bottom the software should report that the sketch was successfully uploaded by reporting "Done uploading" and reporting the Sketch size. If not, check out the Arduino debugging tips here. [Note: if you're still having trouble, you can upload the code with AVR Studio using the AVRISP2 programmer. Just connect to the Atmega168 chip following these direction, and program it with the ardupilot.hex file that Arduino creates in your ArduPilot folder's Applet subfolder.] Now you can disconnect the FTDI cable, reconnnect the GPS module and do the ground test as shown above. For this one, use the ArduPilot 1.0 connections: connect the throttle channel (Rx channel 3) to ArduPilot's Input 1 and the rudder channel (channel 4 from the Rx) to ArduPilot's Input 2. The toggle channel (Rx channel 5) should go to the ArduPilot's CTRL input. The ESC should go to Out 1 (you can disconnect your motor from the ESC, since you'll be testing this on the ground) and the rudder servo should go to Out 2. If your rudder servo is reversed (it would turn the plane in the opposite direction from that required to go NorthEast), look in the first tab of the code and change the number to 0: #define reverse_yaw 1 // normal = 0 and reverse = 1 [NOTE: If for some reason you have run the ArduPilot 2.x code first--naughty! follow the instructions!--the NE mode code won't work. That's because the 2.x code programs the GPS module into binary mode, while the NE code requires NMEA mode. All is not lost, however. If you let the GPS sit without power for a week or so, the internal capacitor will run down and it will return to its default NMEA mode and you can use the NE code again.] If everything checks out, you can now run the full autopilot. Download the latest ArduPilot code (1.x or 2.x, depending on which hardware configuration you want to use), which can always be found on the ArduPilot home page. Repeat the loading process as above. Congratulations! You have a functioning autopilot. You can now plug the GPS module back in and test the basics by toggling your enable channel (5 or 6, whichever you've connected) and confirming that the "MUX" status LED turns on and off. If you're using ArduPilot 2.0 and above, you now you need to go through the initial setup process for the GPS and/or sensors (depending on which version of ArduPilot you're using). Instructions for that are here. For version 1.0, there is no setup process. When the autopilot is enabled, it should move the rudder servo a few degrees in one direction on its own (it is doesn't, you may have reversed your channels--make sure that throttle is in Output 1 and rudder is Output 2). Also, if you're outside or near a window, your EM406 GPS should get a lock after a minute or two. When the LED starts blinking on the GPS module, a blue LED ("Lock") should light up on the ArduPilot board to indicate sat lock. A table showing all correct LED displays in each ArduPilot mode is here. Next, you can learn about using Arduino to set up an autonomous flight here.
Read more…
3D Robotics

Setting up ArduPilot for autonomous flight

Posted by Chris Anderson on November 26, 2008 at 5:00pm
ArduPilot has two modes: programmed waypoints and return-to-launch (RTL). In the first one, you enter in GPS Latitude and Longitude coordinates of your waypoints into the code with the Arduino IDE. In the second, you don't enter in any waypoints and the aircraft just returns to the Lat/Lon it was at when you first powered on the board (at your launch location). I fyou're using ArudPilot 2.1 or above, you can set it up with a desktop utility, as described here. If you're using 1.0 to 2.0.1, you need to do it by hand. Here's the process: 1) Go into Google Maps, satellite view, and right click on the location you want to be your waypoint. Select "Center map here", then click on the "link" icon in the top right corner. You'll see a URL come up, which contains your Lat and Lon. Copy each one and past them the "wp-lat" and "wp_lon" declaration for that waypoint in the Mission Setup tab of the ArduPilot code. Continue until you've got all the waypoints. Add as many waypoints as you want, but remember to set the "waypoints" definition in the first tab to the number of waypoints you're using. [Again, this will all get easier and more intuitive in the next version of the code] The altitude is relative to the initial launch position, not above sea level. So if your airfield is 500 meters above sea level and you enter "500" as the waypoint altitude, the plane will fly at 1,000 meters above sea level (but just 500 meters above you). 2) If you just want to have ArduPilot Return To Launch, then go to the first tab in the code and look for "#define RTL 0". This is the RTL flag. Set it to 1 if you want the plane to just RTL, or 0 if you want it to follow the waypoints in the Mission Setup tab. Once you've got the waypoints and settings the way you want them, upload the code to the board. Unplug the GPS module if it was connected, plug in the FTDI cable and click on the upload to I/O board icon on the Arduino IDE. Once it's uploaded, you can reconnect the GPS module. 3) Now it's time to set up your FMA Co-Pilot. Follow the setup instructions that came with it. At the airfield, calibrated it and fly a bit to get a feel for how much gain to give it (using your proportional control on the transmitter). Once it's stable, try turning on the Co-Pilot and then turning the plane using just the rudder. It should "skid" around turns with a bit of rocking as the Co-Pilot tries to keep the wings level as the rudder yaws the plane. What you're doing is manually testing what the ArduPilot will do under autonomous control. 4) Once that is set up, it's time to try an autonomous flight. Take off manually, and get to the altitude you want to run the course at. Turn on the FMA co-pilot and ensure that it's working. Now flip the ArduPilot control switch (your channel 5 or 6 toggle, depending on how you've set it up.) The aircraft should navigate to the first waypoint. If anything seems to be going wrong, remember that you can always override the the FMA Co-Pilot with your aileron and elevator sticks. Even if ArduPilot has done something very wrong with the rudder and throttle, you should be above to regain control and bring the aircraft back to you. Once the aircraft is back in control, turn the autopilot off and you will regain control of the rudder and throttle so you can land and diagnose the problem.
Read more…
3D Robotics

BlimpDuino debugging tips

Posted by Chris Anderson on November 24, 2008 at 3:39pm

Just a quick note for those building BlimpDuino boards from scratch and running into issues: First, the instruction on how to load the bootloader, etc, are here. If you're still having trouble and suspect a bad solder or dead component, here are Jordi's debugging tips: 1-Check if you have power... if you don't get 5 volts in the whole bus, maybe you have a defective component, make sure you have soldered the C4 100uf capacitor well, if not, maybe you burned the atmega.. Also change the power regulator 7805... 2-If you have power, maybe is a bad solder atmega and is moving around making false contact, try to re-solder the pins. 3-In case all the pins are well soldered, and you have power in all the power inputs of the atmega, maybe is a defective atmega168.. Could happen if you discharge static electricity, or from factory.... 4-Now if the power regulator is not working, and you want to know if the atmega is burned, try to connect a 5 volts battery (like the red ones included in the futaba receiver) into the servos inputs, be very careful with the polarity, the ground is located on the outside of the board... then see if the atmega is working.... (try with the FTDI or ISCP and upload something or read the fuses)...
Read more…

My first EasyStar RC flights- with GPS too!

Posted by Pat on November 23, 2008 at 10:32pm

Like many others, I have been mildly obsessed with the thought of building my own autonomous aircraft for some time now, and DIY Drones has been a wonderful inspiration. It helped convince me to purchase an EasyStar a year ago, but due to other activities in my life, it sat collecting dust in its box until 2 weeks ago when I finally began to assemble it. Well, I finished it last Thursday and had a coworker help with its maiden flight to ensure that all was well. I am flying with a 1500 mAh LiPO battery, so it was tail heavy and we needed to add some ballast to the nose. Fortunately, I had my Garmin Forerunner 305 GPS watch with me, which we turned on and placed in the cockpit. It did the trick for ballast, but the recording was less than ideal.Saturday morning came around, and it was time for my first flight of the Easy Star! The only plane I had previously flown was 2 channel Firebird Commander 2 from Hobbyzone, and I had serious butterlies since I was now moving up to a "real plane"! I learned from the maiden flight that the GPS watch should be set to record data every second instead of at automatic intervals, so with this correction in place, I hand launched the plane into the beautiful 60 degree air and slowly felt my butterflies disappear as I gained confidence in flying the plane. All in all, I was out there flying for nearly an hour on that single battery charge, and according to my recorded flight details, about 40 minutes was actually spent in the air. I have to say that everyone who has claimed tha the EasyStar is a wonderful flyer was right on the money! Not only was it money well spent, but I can't wait to outfit it further with aerial photography add-ons and finally with the ArduPilot!But back to the GPS! Once I got home, I uploaded all the flights to Garmin's MotionBased website where you can play back animations of the recorded paths. Check out the final flight of the day, which consisted primarily of unpowered gliding after the battery voltage got too low. Be sure to choose Satellite and Large within the Google map frame, select the playback speed to be 0.5x or 1.0 x, and hit the Play button!

And if that isn't enough, I was able to export the path to a KML file for 3D viewing in Google Earth! There were two tricks to get this to work properly. First, the MB Gravity Elevation Correction had to be disabled as part of the Activity Options within the MotionBased website. Otherwise, it uses a digital elevation model to estimate the elevation assuming that you are running or biking and would never be 200 feet off the ground! Second, in Google Earth, I had to set the Altitude Property for the path to be Absolute, so that it would be projected in 3D above the Earth. Now I want to figure out how to use the built in flight simulator to fly the path!Sure I don't have an autonomous plane yet, but I already have a successfully flying platform and have performed beautiful navigation recordings, and that's an encouraging start!
Read more…
3D Robotics

Coast Guard Academy course built around BlimpDuino!

Posted by Chris Anderson on November 23, 2008 at 5:03pm

This year the Coast Guard Academy's mechanical engineering department build a course around BlimpDuino, both to teach the students about aerial robotics and to help us beta test the blimp. The course was designed to help develop an aerial robotics contest and the students built several of the blimps, programmed them and are experimenting with different contest ideas. The course is led by Captain Vince Wilczynski, who is active in the FIRST robotics competition. This is awesome stuff--I wish I could have taken a class like this when I was in college! They've got the course wiki open here. Here are two particularly interesting/useful documents: The controls class just started, and here's their assignment: MCDS- Fall 2008 – Project Part 1 –Modeling Given: The BlimpDuino prototype is a small UAV designed for college robotics competitions. It employs PID altitude control using a microcontroller, ultrasonic sensor, and a thrust vectoring system consisting of two small DC motors with propellers and a servomotor. A 7 VDC battery supplies power to all components. Find: Develop a mathematical model for the altitude. Our model will differ from the physical system based on our assumptions. The actual system is nonlinear (as is life!), however we will attempt to approximate it as linear. To successfully model the system, and verify that model, we must apply concepts covered in MCDS and EMFTS. You will need to make several assumptions and decisions, so clearly describe your work using homework format. You may collaborate but all documents, including codes and plots, must be your own. In parts 2 and 3 you will apply P and PID control algorithms to this system. In part 4 we will alter the system gains to observe the system behavior. a) Sketch the system to show how components interact. List parameters and assumptions regarding size, weight, etc. I will walk through this with you when we introduce the project, so ask questions. b) Make a general block diagram of the system. Your diagram will identify key transfer functions, some which may not be defined yet. Your diagram will include A/D converters to account for the microcontroller. Let the ordered altitude be yr(t) and the actual altitude y(t). Include a disturbance representing the velocity of an air current directed in the direction of gravity, wd(t). A transfer function should be included to develop the force fd(t) resulting from the wind. c) Include a paragraph or two describing how the system components work together during operation. d) Develop the transfer function describing the sensor. This is a math model describing how the sensor “converts” the altitude, y(t), to a voltage, vA(t). Use the sensor background information. If this is not sufficient conduct experiments to develop a plot of y(t) vs vA(t). Use this plot to develop a gain. The current prototype sensor sends a PWM signal instead of a proportional voltage, however we will assume it operates in the latter mode to simplify our model. e) Develop the transfer function describing the conversion of sensor voltage to altitude. This is the algorithm used by the microcontroller to determine Y so it can be subtracted from Yr to get the error. f) Develop the transfer function describing the actuator. This is a math model describing how the actuator converts the command voltage Vm to a thrust force FT. Depending on your assumptions this will result in a simple gain or a transfer function of higher order. The actual prototype controls altitude by altering the position of the thrusters, not the magnitude of the thrust. This is a subtle, yet important, difference which makes the system nonlinear. Therefore we will assume the motors are stationary and can operate in forward or reverse. Here are two ways to approach this model. You should address both, choosing the results of one method as your preferred model: 1. Test the device. Conduct experiments and develop a plot of vm vs FT. Linearize your plot to develop a gain relating the parameters. 2. Determine analytically. Use what you know about Physics to develop a relationship relating the input voltage to the propeller thrust. g) Develop the transfer function describing the blimp dynamics (your “plant”). This is a math model describing how the blimp reacts to the input forces, fT and fd , to achieve some altitude. Consider drag and friction, weight, buoyancy, and “added mass”. Drag and friction are difficult to determine, and will result in a nonlinear model, so we will need to linearize it. Here are two ways to approach drag. You should address both, choosing the results of one method as your preferred model: 1. Test the device. Conduct experiments and develop a plot of drag vs. velocity. Linearize your plot to develop a gain which will relate the parameters. You can also find the total mass this way. 2. Determine analytically. Use Physics to develop a relationship relating the drag to the velocity. Remember you will need to linearize this for your model. Ref [1] below may be useful here. h) Redraw your block diagram with your chosen transfer functions included.
Read more…

extreme navigation 4 U

Posted by Jack Crossfire on November 21, 2008 at 10:30am
That's some extreme autonomous navigation. Forget about asking The Goog how it works or why anyone would bother launching a rocket sideways. We can only guess the 90 deg turn is to save space. There are probably some 1000000 deg/sec gyros in there. Maybe it's Attopilot 1.9.
Read more…

6-legged walking roboter

Posted by quix-fz on November 21, 2008 at 8:30am

slightly offtopic, but the servo-interface might be of interest to some people. here's my 6 legged walking roboter. there are 3 servos for every leg.

these are connected to two 4017 ic's (10 servos max each) and these are connected to the two timer-1-compare-outputs (pin 9 and 10) on the arduino. since i'm using the timer1 and interupts, the whole thing barely uses any cpu power. and you can still use the timer1-capture-input to read ppm from the receiver in parallel.regarding cpu usage. i got my prototype-uav running (big breadboard in the background of the photos) with 640Hz sample and update rate, with accelerator-sensor, pressure-sensor, 3-gyros, 10 servo output, ppm input and decoding, gps input and serial display output (had to add buffering to the Serial-library of arduino, but works :) ). the pcb is also on the way :-Dthe 4017 are really easy to work with. if there's interest, i can post the schematic and sourcecode.
Read more…