Blogs

All Posts (14056)

Sort by
3D Robotics

DIY Drones uBlox modules now available!

Posted by Chris Anderson on September 4, 2009 at 8:00pm

The awesome uBlox 5 GPS modules are now available in the DIY Drones store! From the product description: The powerful GPS is based on Ublox 5 chipset and the Saratel helical antenna to maintain sat lock from any angle. Includes uBlox adapter and comes pre-programmed for ArduPilot. Features * u-Blox 5H chipset * Sarantel omni-directional Geo-helix S-type active antenna * Real 4Hz Refresh rate * Fifty channels * Supports UBX, NMEA and USB&NMEA * High immunity to RF interference * Firmware upgradable * Includes 12" cable with EM406 connectors on both ends. The cost is $109.90, which is a bit cheaper than buying the module (if Sparkfun ever gets it back in stock) and the necessary adapter and cable separately, and these these come pre-programmed for ArduPilot, saving you a huge hassle involving making a custom connector for you FTDI cable and messing about with uBlox settings in their utility. It's designed to plug straight into the ArduPilot's GPS connecter--plug and play! When you switch to this GPS, remember to change the configuration file so ArduPilot knows! //1-7 #define GPS_PROTOCOL 2 // 0 = NMEA, 1=SIRF, 2=uBlox
Read more…

NASA Ames Excursion

Posted by paul hubner on September 3, 2009 at 1:30pm

I was fortunate to be a part of the DIYDrone trip to NASA Ames Research Center (ARC) yesterday at Moffett Field in Santa Clara. We were treated of wide variety of conversations with NASA's UAV professionals including Chad Frost, our sponsor for the day. (Thanks Chad and everyone else @NASA!). For those who couldn't make it, here is a little writeup of the excursion:

3689324597?profile=originalChad began by leading the dozen of us through security checkpoints to the 'escort required' side of Moffett Field and the UAV hangars. The first stop was a commercial UAV platform, an orange Calaban heli airframe, customized with an array of mission video and scanning laser sensors (in addition to the flight related sensors). Interestingly it used a PC running a tweaked Linux as the top layer managing OS. Sensors (ie GPS, 3axis accs, etc) were running in their own environments and feeding the outer loop(s?) system. The ground station(s) were housed in a trailer and received realtime updates from the UAV. Check out the imaging of us standing in front of the heli!

Next stop was a the largest research platform that Chad is working.

3689324690?profile=original

The Sierra frame has flow 41 times, 11 with payloads. It was just returned from Norway (No, it did't go off course!) doing some atmospheric science.


3689324760?profile=original

We were next shown a 41' wingspan Swift glider that is to be retrofitted with an electric motor and converted to a UAV. It should be able to take payloads up to about 220 lbs in total toward their goal of learning about green efforts in the UAV arena.(See my album for the spec sheet) Last we saw a 1/3 scale Piper cub that is being worked on to research dynamic adjustments of control surface, unless that was another one of the many other projects and offices we crashed.I was pleased to meet a sampling of the DIYDrones.com members too. I think we all learned quite a bit from NASA and each other and our projects. More pictures are in albums under:

I know I've left out a ton of detail (like Google's Dornier Alpha) so please comment on you experiences below and post links to your pix.

Thanks again to Chris and Chad for getting this together. The next time a field tip that comes up, I recommend you jump on it.

Read more…
T3

My autopilot

Posted by Andrus Kangro on September 3, 2009 at 7:00am
I received request to publish more information about my "custom" autopilot, used for TTT contest, so here it is:My autopilot current version is 4. It all started when I received Welleman pic programmer & experiment board as Christmas present (to be honest, it was selected by myself). My initial interest was to make my sailplane turns more efficient and for that I needed to hold wings always crossed with gravity vector.Initial autopilot (V1) was built around 16f627 pic controler and the only thing it did was to use Parallax dual-axis accelerometer for controlling ailerons; rudder and everything else was under manual control. V2 autopilot used pic16f870 chip and added airspeed measurement (using mpxv5004dp sensor) and attempted to regulate sailplane speed by controlling elevator (it also had MPX4115 sensor for altitude measurement, but it was not used at this stage) . When I upgraded my RC-equipment to 2.4G and receiver inputs started to come in parallel groups, then 8-bit PIC did not manage any more and I upgraded autopilot core to dsPIC30f4013 (autopilot v3), adding also GPS to it. As I struggled to understand, what was actually going on inside autopilot during flights, then I attempted to add SD-card logging into autopilot, but faced memory shortage issues on 30f4013. So I upgraded autopilot core to 30f6012 and current version of autopilot (v4) was born.V4 hardware has 3 revisions, I'm using currently revA, but there is also one board of revB ready and its clear by now that there will also be revC. revA has 10 digital change notification inputs (8 for receiver and 2 for accelerometer, all used), 8 analog inputs (gyros, battery voltage, current sensor, 2 pressure sensors - 6 used currently) and 8 servo outputs(5 used), serial port for GPS/2x16 display and SPI port for SD-card. RevB has 14 digital inputs (change notification or input capture), 8 analog inputs and 8 servo outputs, 2 serial ports (for gps and terminal/radio modem), SPI for SD-card and i2c for (future)electronic compass + 3 led's. RevC will change location of some inputs/outputs. I attached Eagle schematics for revision B board here:apv4.sch.Is my autopilot inspired by UAV devboard - no, its parallel development. However, I would probably use UAV devboard, if it would have more powerful chip, much more inputs/outputs and SD-card on board. I'm also looking forward to implement cosine matrix transform in my software like in Matrixnav (waiting for gyros to arrive at the moment). I sometimes browse through Paparazzi and Matrixnav and other firmwares in order to get ideas and avoid inventing bicycle - however, I find it much easier to understand what others have been doing, if I have been working on topic myself also at least to some extent. So, I will keep inventing my own wheel also.As my goal was never to hold wings level with horizon, then there are no IR sensors, although they can probably be connected to vacant analog port if needed.What I've done with my pilot so far: the progress has been very guick since I got SD-card logging working. Once gyroscopes got involved, then direction control started to work reliably as well. My target was to make my sailplane to hunt for thermals and come home automatically and I succeeded on that: current autopilot can control plane speed, altitude and direction and can bring it home if I order it to. It also detects thermals and circles in them, attempting to shift circling center closer to stronger lift area, while making sure that it does not drift too far from "home". During best flight it used engine only for climbing into altitude and the plane stayed up thermalling for one hour without needing to turn on engine again (then I had to leave and took plane down). Thermalling is problematic in my area due to closure of the airport, so I can not do any altitude records where I usually fly. But, if there is suitable weather during some weekend and no family activities, then I plan to drive to G1 airspace area (this is reserved for sailplane flying) and see, how high it really goes....TTT competition is good stimulus for improving autopilot software and algorithms, I'm looking forward for next round. At the end of it I will probably have wp navigation mode with altitude control done via elevator and speed via motor, also navigation accuracy should be greatly improved. Better control over plane (especially when cosine matrix transform is implemented) will help me to make better thermal turns also, so its all very positive what is going on here.
Read more…
T3

Altitude hold for UAV DevBoard

Posted by William Premerlani on September 2, 2009 at 2:26pm

09038-1_i_ma.jpg

UAV DevBoard pilots,I am putting the most recent releases of MatrixNav and AileronAssist back on line. I briefly reverted to the previous releases while I investigated a system issue that I just ran into.I just bought an EasyStar, ready to fly, with radio, servos, ESC, and radio already installed. I did some flying with MatrixNav. Most of the time it worked fine, but once in a while there were problems that popped up at random. Once in a while the firmware believed the radio signal is lost, and reverts to return to launch mode. Sometimes the elevator will work in only "bang-bang" control mode, responding to manual control by going either full up or full down. Typically, the problems arise at random, after about 10 minutes of flying.After some investigation, I discovered a system issue that a few of you have already run into. It turns out that low battery voltage will cause a "brownout" situation for the CPU. It turns out there was a problem with the ESC. Although the CPU did not reset, some of the hardware configuration registers reverted to their default values. This will cause the firmware to think the radio signal is lost, and it will go into return to launch mode. This will happen with any of the releases of MatrixNav or AileronAssist.When I have some time, I will take a closer look at handling low battery voltage.In the meantime, be sure to use good batteries and a quality ESC.Best regards,Bill PremerlaniAltitude hold is now available as an option in the most recent releases of the control and navigation firmware for the UAV DevBoard, MatrixNav1.7, and AileronAssist1.6. Both are available from the UAV DevBoard home page.The altitude hold function has been tested by both Sid and myself. According to Sid, it is "precise".During my tests, AileronAssist was able to hold my Goldberg Endurance in a turn at a 45 degree bank angle, at constant altitude, for 30 minutes.Next, I am going to implement waypoints.Best regards,Bill Premerlani
Read more…

Custom airframes and other parts direclty from CAD - www.nwuav.com

Posted by Alexander Graham Dick on September 2, 2009 at 12:00pm
I am new to the DIY Drones community and UAVs in general but have a lot of experience producing durable parts made directly from CAD data. When considering the DIY Drones site I noticed there is some great resources for electronic components but what if someone wants to design and produce a stellar airframe or other custom parts? Has anyone dabbled in CAD and considered producing their own parts in nylon without a mold???My company NWUAV (www.nwuav.com) has produced custom airframes as well as shrouds, intakes, brackets, etc for industry and I thought, why not for hobbyists too? If you can design it in CAD, we can build it! Any complexity with walls 0.020" and up (note: best to design 0.040" and up for any load bearing feature). Our parts are flying on thousands of planes. If anyone has some interest, let me know! You can send your CAD files to alex.dick@nwuav.com.
Read more…

The Ultimate Modular Open Source Auto Pilot

Posted by Scott Plunkett on September 1, 2009 at 3:38pm
I have spent a lot of time looking around at all of the different models of autopilot from the simplest Arduino implementation to the most complex solutions in the $10K range. The thing that most of these seem to lack is modularity. I'd like to see the community come together to develop a "Main Board" and then a bunch of additional add-on components that are designed to work together with the appropriate code. As an example, say I want to start out with a simple main board, thermopiles and a gps, but them later decide I don't want the thermopile anymore and I want an IMU based system, and acoustic rangefinder for auto-landing - but wait, later still I want a system with a laser rangefinder, onboard video for FPV, and I want to log the data from a bunch of the components...obviously, I'd be throwing out a lot of hardware every time I wanted to learn more or upgrade. So how about it?? Who is in? I'm kinda liking the name ModuPilot..
Read more…

SLUGS AP: Fully Flight Tested and Open Source

Posted by SLUGS Team on August 31, 2009 at 12:22am

So after endless hours in the lab I am happy to report success in all fronts of the autopilot and making the GIT repository publicly available. The project's website has been updated to reflect the new hardware version and all the changes in the software. New videos have been added to our video section showing some air and ground footage.A new blog entry presents some plots of the Autopilot performance when doing waypoint tracking and the address of the GIT repository containing all the project.
Read more…
T3

UAV low altitude flight, autopilot with IMU

Posted by Krzysztof Bosak on August 30, 2009 at 11:49pm
Will it fit the meadow?

UAV low altitude flight, autopilot with IMU from Krzysztof Bosak on Vimeo.

Amateur robotic plane flying at tree level (10m above takoff point).Envelope pattern with 150-170m legs and very little error margin for anything.Only barometric altitude sensor has been used, GPS might drift too much during banked turns.Takeoff and landing in manual mode (classic RC transmitter).There was also 8m flight but the camera power died.In general altitude control band is +/-4m, 8m in windy weather worst case.NO distance ranger has been used.
Read more…
3D Robotics

A Lego PicoPilot!

Posted by Chris Anderson on August 30, 2009 at 10:00pm

The most basic autopilot you can buy is the UNAV PicoPilot N, which is basically just a one-axis gyro and a GPS, with an old Pic processor inbetween. It's a "turn-rate leveler", which is to say that it keeps the wings level with the gyro and uses the GPS to correct for gyro drift (and to handle navigation, of course). It's twenty-year-old technology, but it works well enough on high-wing rudder & elevator trainers. I've got a couple of them (which cost an incredible $700 each at the time I bought them!), and my irritation with the dated technology, high price and closed system was one of the reasons for starting this site and our projects--I knew we could do better with open source. I also have a long-standing love affair with Lego Mindstorms, which is the best robotics prototyping system out there. I've built a few Lego Mindstorms autopilots, but the truth is that for anything sophisticated it's better (smaller, cheaper and more flexible) to design custom hardware, as we've done with ArduPilot. But I've always been looking for a way to offer a Lego autopilot here that makes sense and could be built by many people. Finally, it came to me. Rather than duplicate the functionality of our full-function autopilots in Lego, why not just make a Lego version of the basic PicoPilot? So here you have it: the hardware for a Lego Mindstorms turn-rate limiter autopiliot. Basically, it's a one-axis gyro, a Bluetooth GPS (Mindstorms has Bluetooth built in and it's the best way to get serial data into it), and an ArduMUX to handle switching between RC and autonomous mode, interfaced with the NXT brick with a Hitechnic prototype board. All the functionality of PicoPilot, but open, pretty cheap, and Lego! The components are as follows (along with the NXT controller). See picture above to see what's what. --Hitechnic gyro sensor --Hitechnic prototype board --ArduMUX --Mindsensors servo driver --5Hz Bluetooth GPS (a different model is shown in the photo) Total cost of these components is around $200 (if you already have a Lego Mindstorms NXT kit), which is half the price of PicoPilot! It's no ArduPilot, but if you're into Lego it's pretty awesome all the same. Now that the hardware is in place, I'll turn to the software, modding my previous Lego autopilot code to handle turn-rate leveling. Given that this has a 5Hz GPS, I expect it will significantly outperform PicoPilot ;-)
Read more…

Replacing FMA with a 6DOF IMU

Posted by Roberto Hawkowski on August 30, 2009 at 7:22am
Hello,If I understand right, Ardupilot is dependent on FMA for roll and pitch stability.I have 6DOF IMU from Sparkfun and I want to use it to monitor the roll, yaw and pitch angles of my model airplane and use this data to perform FMA functions i.e. maintain roll and pitch stability.Sparksfun's 6DOF IMU gives accelerations and gyro data. On benchtop experiments, I can accurately measure my roll and pitch angles using only accelerometers. But, if the IMU flies in model UAV, it will be subject to all sort of other accelerations, rotations and accelerarometer readings will not be sufficient to measure roll and pitch angles.Can someone tell explain how to use 6DOF IMU to calculate roll,yaw,pitch angles in flight and eventually use 6DOF IMU to replace FMA? Do you have Arduino code for thisRob.
Read more…

Ardupilot ordered! Now for the fun adapting this to a non-rc ROV!

Posted by Aaron Buckner on August 29, 2009 at 7:57am
Hi everyone, I'm new to the community though I have been keeping an eye on this project for several months with the hopes of integrating it with my ROV Project. Last week I finally ordered my initial load out of Ardupilot gear. For starters I'll explain my project and my goals.My project is very different from anything I have seen using Ardupilot of course I could be wrong and if I am thats going to make my life easier :) My project is a PC Based Tread-Based ROV Chassis (more details here). There are several issues I will have to overcome in order to get this to work properly, Control, Data Transfer and I'm sure I'll hit a few other snags.So far on my list:The ROV isn't "RC" so I have to somehow send the control commands to the PC and then interpret them into signals the motor controller understands (currently using an Phidgets HV Motor controller).The ROV doesn't have a typical control system, no "steering" system its just like a tank, turning based on motor speed.Communicating with the Ardupilot is also going to be interesting, I'm not currently looking into Xbee as I have a wifi link to the ROV, but I'm not ruling it out, I have some short range Xbee modules I may do some testing with.Thats it for now, I know I have alot of work ahead I certainly don't think this is going to be a quick and dirty project but thats half the fun. I have an Ardupilot and the new "Main" Sensor board with an EM406 GPS unit coming next week.
Read more…

Video: UAV in a Firefight of a Different Kind

Posted by Tim Trueman on August 28, 2009 at 6:24pm
Here's a video about the University of Alaska's operation of a Scan Eagle UAV I posted about earlier:http://www.wired.com/autopia/2009/08/firefighting-uav/"Earlier this month in Alaska, a 40-pound Insitu Scan Eagle saw duty fighting wildfires after dense haze grounded conventional aircraft. The UAV is operated by the University of Alaska, which according to university officials is the first entity other than NASA and the Department of Defense allowed to fly an unmanned aircraft beyond the line of sight in civil airspace. The Department of Homeland Security also is using UAVs for border surveillance."
Read more…

First try with ardu communicate

Posted by remzibi on August 28, 2009 at 3:00pm
I am sorry for a late , but lastly I had really lot other problems so no time at all for any "flash" work .However I made few lines of code to made possible communicate sending to OSD from any external devices , so from Ardupilot also - anyway that was the base reason . HappyKillmore already wrote about it - but here detailed descryption of message format .So we can deliver information to display on OSD at location x,y looks like that :[leading character][text message][ending character][ending space]ending space is displayed always after mesasage.String to OSD shoult look like that :"$MXXYYLLEEabcd"must be end by enter character CR LF linefeed and carriage return .$M - means that it is meassage to display (M must be uppercase)XX - is a x coordinate on screen , must be hex valueYY - is a y coordinate on screenLL - is leading character hex value from font tableEE - is ending character hex value from font tableabcd - is a "text message" to dispalay (for now can be 30 char long)when LL or EE is Hx00 - then will be not displayed at allwhen text message is "" [empty] then also will be not displayedSo string to OSD can be like that in C Arduino sampleserial.println("$M050a4a4bI like that")so at location x=05 y=10 will be displaed this :" <<I like that>> "as you see LL is 4a it means [<] char and EE is 4b it means [>] char .or can be done like this way:[code]serial.print("$M") //header for messageserial.print("050a") //x and y coordinatesserial.print("4a4b") // leading and ending characters(graphics)serial.println("I like that") //message with LR CR ends string[/code]This is exactly how is working this function in OSD now .As advantage of this system when we define most significant bit of XX coordinate for 1 then we choose small fonts for text message display (only capital letters) - when is 0 then default big letters are displayed from characters table capital and small letters .[code]XX |= (1<<7) // set 7 bit for small charactersXX &= ~(1<<7) //reset 7 bit for big characters[/code]To be possible custom screen configuration , need of understanding how it is work .The screen is divided on net where the charcters are writen .The grid is 30x16 with PAL mode nad 30x12 in NTSC mode .Looks like that:[code]. X------>Y 1 2 3 4 5 6 7 8 ... 29 30: 2: 3: 4v 5. .. 15. 16[/code]So when we made configuration we just teel the program where on the screen we want first character(or graphic) of our information - up left corner is coordinates X,Y (1,1) , bottom right corner is X ,Y (30,16) - remembre that NTSC mode Y must be no more than 12 .How do we know what mode are currently in use ? - we will see after OSD init logo .I foloowed of mmormota idea about add to OSD firmware ability to display any custom information delivered by RX input at the same baud rate with GPS module .So if anyone have external device with GPS and retransmitiing GPRMC GPGGA messages , OSD can be used in usuall way - inluding autodetecting baud rate .But also in middle of NMEA messages is possible to put custoom dispaly instruction - all described detaily in post above .So here is the beta version of firmaware 1_60 - mostly for mmormota to test with ardupilot software .It is working exactly as remzibi OSD (including GPS configuration commands sent at begining by TX line after baud rate detection) plus ability to display any custom oinformation delivered by UART(com port) in the middel of NMEA messages , format described in post above :"$MXXYYLLEEabc"So with this solution there are a bit solved problem of insufficient space in OSD's chip . maybe will be possible also displaynig artifical horizon and pitch using characters E0 to E7 from character-font table .Here is my imagination of artifical horizon .Too smal chip not allowed to made it in OSD for roll - but in Ardupilot that counting can be done and using "$Mxxxxx" mesages - that should be possible - as well as pitch .a2721448-192-horizon.JPGSo for now are avaliable to firmwares for OSD , first as display termional only working without GPS named no_gps.hex and second normal OSD firmware OSD1_60.hex with ability to display anything in the middle of NMEA commands .No GPS firmware can be downloaded here - http://www.rcgroups.com/forums/showpost.php?p=12973661&postcount=1344and 1_60 firmware is already avaliable with PC software update - or here - http://www.rcgroups.com/forums/showpost.php?p=12973724&postcount=1345with pictures of possible connections .I hope that this firmware will help for many peaples doing his own project and will made poor man's OSD more open to world , also be more universal to variouse usage in many other project , not only flying platforms .
Read more…

How to change labview GCS Baudrate to 19200...

Posted by Vikram on August 28, 2009 at 6:15am
Hi all, i had to make little changes in program to get the data at 19200 baud rate...... so its all woking with wireless telemetry.. But the only problem is groundstation... how to change baud rate of ground station. Since its in labview so facing problem of changing its baud rate i have its source code also but cant get how to change.. ..or is there any software emulator to get data on 19200 and reproduce on other serial port at 57600 for GCS.. Suggestions please ..
Read more…