Blogs

All Posts (14054)

Sort by

ArduPilot Success Stories/Videos

Posted by MC on April 17, 2009 at 5:10am
Hello Everyone,I am excited with the ArduPilot project and the DIY Drones community activities. I decided to buy an ArduPilot from Sparkfun (they do not have in their stock at the moment). Meanwhile I am searching for ArduPilot success stories, and successful flight videos with ArduPilot. Although there are a couple of ArduPiloted EasyStar flight videos on YouTube, those videos do not show accurate navigation results (I hope I am mistaken).If you know successful flight videos of ArduPiloted UAVs, can you post their links?May be the proprietor of this site can create a new tab/section specifically reserved for the listing of ArduPilot success stories/videos.
Read more…
T3

MatrixNav is released.

Posted by William Premerlani on April 15, 2009 at 8:55pm
Successful flight testing of MatrixNav is complete. MatrixNav is open source C firmware for the UAV DevBoard that provides pitch stabilization and return to launch functions for inherently stable aircraft that are controlled by rudder and elevator. MatrixNav is built on top of a method for integrating gyro signals into orientation information called direction-cosine-matrix (DCM). Flight tested firmware and documentation are available.A dozen test flights were made with an electric powered Gentle Lady under the following conditions:1. Both calm and windy conditions.2. Powered and gliding.3. Return to launch with the plane pointing away, toward, or perpendicular to me.4. Circling behavior under RTL control after the plane crosses the launch point.5. Hand launch in both manual and pitch stabilized modes.6. Landings with pitch stabilization turned on.MatrixNav completely solves an issue that I wrestled with in previous versions of my firmware: gyro cross coupling during a banked turn. If you attempt to use a pitch gyro signal to stabilize the pitch of a plane, it will measure a portion of the turn rate of the plane during a banked turn, and will cause the plane to dive into a turn if the bank angle is too great. The use of direction cosines eliminates the cross coupling and makes it simple to achieve a level turn at any bank angle.Furthermore, since MatrixNav relies mostly on gyros, not accelerometers, I was finally able to turn on pitch stabilization during hand launch.I added a feature to give the plane a kick during return to launch: you can program in the return to launch pitch angle. By deliberately pitching the nose down a bit, you can increase the return speed to better penetrate the wind.MatrixNav is intended for you to either use as-is, or to serve as the starting point for your own projects. So if you have a UAV DevBoard and want to use it to do some flying of an inherently stable plane, you will definitely want to try out MatrixNav.By the way, the MatrixNav documentation is not up-to-date about what the LEDs will do. Sorry about that, I really don't look at the LEDs anymore, they are usually hidden in my plane. Here is what they do:1. The LED on the EM406 will go out entirely, because MatrixNav puts the GPS communications in binary mode.2. Both LEDs on the the dev board will come on briefly during power up, to self test them.3. After power up, the green LED, stat2, will indicate whether or not MatrixNav is receiving valid pulses. It will be on continuously if there are valid pulses, otherwise it will go out.4. After power up, the red LED, stat1, will flash a few times, and then go out until the GPS is locked, and then it will resume flashing.After power up, MatrixNav goes through an initialization process that waits for both GPS lock and valid radio pulses. When pulses are received and when there is GPS lock, the rudder will wag a few times. When it stops wagging, MatrixNav records the present location as the return to launch point and you are cleared for takeoff.Bill Premerlani
Read more…

Three Cheers for Chris and Jordi

Posted by bGatti on April 15, 2009 at 4:51pm
For three wins:Ardupilot Team vs. TreesArdupilot 2 Trees 0
Find more videos like this on DIY Drones
For those that missed, it, today's Sparkfun event was a smash, literally and figuratively. It turns out that U(A)V's of all stripes have the same propensities as Charlie Brown kite. Aside from the Trees into which Jordi scored direct hits, the wheeled varietals made their own attempts to climb the Sparkfun forest.The wind certainly made itself known, and my first impression of the ardupilot (with pitot) was that it had very stable flight characteristics, wind notwithstanding, and that the waypoint acquisition was the low hanging fruit for improvement. I suspect the wind had decreased the accuracy outside the waypoint margin, resulting in several fly-arounds - but when the accuracy came withing range, it was quite effective in circling the building.
Read more…

Tilt Error Compensation

Posted by Akram Habib on April 15, 2009 at 3:00pm
Hi,First of all I many thanks to Chris for directing me to the right link, which has enabled me to have an enormous understanding to what I needed to do and gained other info that I was not aware of...Brilliant Forum!!!Right now I am working on the CMPS03 digital compass. I have managed to get the compass programmed and it works fine on the Horizontal/Yaw manoeuvre. I am working on the till error compensation right now (Pitch & Roll). However, I am struggling with the following areas:- I am experiencing a random flickering during the tilt “Pitch” on the North & South direction. Is this okay or is it due to something that I have done wrong?- I plan to use an additional CMPS03 to detect the Z-axis because I could not find another single axis compass, which also uses I2C interface. How can I use only one of the sensors reading when pointing on the Z-axis.- I have looked into the brilliant comparison in the FQA between “Gyros, Accelerometers, Infrared sensors....”. to avoid complexity and expenses as am still learning about UAVs & RC Aircrafts, I thought to go for Infrared sensors. is my understanding right that I would be able get the till measure through an Infrared horizon sensor and would it work with this compass module.Thanks for the support.Best regards,
Read more…
3D Robotics

WE WON!!!!

Posted by Chris Anderson on April 15, 2009 at 2:00pm
With the plane down from the tree and taped up, we were the last team of the day to do the last run. The winds had picked up to 10-15mph, gusting even higher. We had one run to hit it. Jordi took off, went downwind and switched it into autonomous mode. It made the first waypoint (into the wind) easy and them zoomed by the second one, then took the third waypoint (downwind) really wide. Then it started heading back into the wind towards the finish line. Oh no, it looks like it's too close to the building and we're going to cut a corner! But then, at the last minute, the plane corrected, moving slowly into the wind, and drifted to clear the corner by about a foot. Then straight and true over the finish line! 36 seconds! First place! Hurray!!!!!
Read more…
3D Robotics

Sparkfun contest report: round 2

Posted by Chris Anderson on April 15, 2009 at 12:35pm
Competition is heating up! One rover did 1'32"! Our second run was better than the first. We did five laps, but only the first counted. Unfortunately, the judges said we missed the first waypoint and cut off a corner. Too bad, because we did it in 32 seconds! The other laps, naturally enough, were all perfect but didn't count. We've increased the radius and pushed that first waypoint out a bit further for round three, in about an hour. Please wind don't pick up.... Oh, and in manually landing the plane after one test run Jordi got caught in a low tree hanging over a little river! We drove around the river and I climbed the tree to shake it out. I think it's the most useful thing I've done all day...certainly made for some entertaining photos, which will no doubt be emerging soon.
Read more…
3D Robotics

Diaster! Plane in tree!

Posted by Chris Anderson on April 15, 2009 at 12:30pm

While landing after a test run, Jordi accidentally put it in the tallest tree around :-( Fire department called, men with ropes now climbing and attempting a heroic rescue. Praying for a miracle! Our other EasyStar doesn't have the airspeed sensor so probably wouldn't handle the wind. Argh!!! UPDATE: The fire department has a arrived with a ladder truck. Go firefighters!

Read more…
3D Robotics

Sparkfun contest report: round 1

Posted by Chris Anderson on April 15, 2009 at 10:52am

Round one is over and so far only one vehicle (a rover) has finished the course, in a time of about 2.5 minutes. ArduPilot did a perfect course, but unfortunately it looks like the Google Maps GPS coordinates are a little off, so we cut some corners. We're resetting the waypoints for the second round, in about an hour. We're the only UAV competing. The other one we were most worried about (a UAV pro with an IMU) decided not to bring his plane when the PID loops weren't cooperating in recent tests. So far the winds are under 10mph so we're okay. Fingers crossed for the afternoon runs. Jordi is running the ArduPilot 2.2 code with the airspeed sensor (see above for the pitot tube coming out of the nose) and controlling the throttle, so we should be able to handle the wind better than 2.1, but there are limits....
Read more…
3D Robotics

Atmega328s are in!

Posted by Chris Anderson on April 15, 2009 at 8:35am

We're here at Sparkfun and the Atmega328s came in yesterday! They populated three boards, which we're testing today. Assuming all goes well, we'll give the green light and production will start tomorrow! Backorders should be filled early next week. Here's Jordi and some kids in the pits, getting ready for our first run in the competition:

Read more…
Moderator

Failures and Sucesses

Posted by Graham Dyer on April 15, 2009 at 1:30am
A blog of my experiences with ArduPilotHaving messed around with RC craft for the last 20 years or so and having built and flown all kinds of 'craft' from 1/4 scale to 28g (1oz) planes - heli's, boats and cars too, I thought the ArduPilot project seemed a interesting new avenue to try.Started on my AP (ArduPilot) project with the arrival of my Arduino168 board, wasn't sure I wanted to commit a plane yet so tried it in an RC car. ArduPilot board /EM406 GPS, v1.0 software, RTL set to 1, code uploaded successfully, 'OUT2' to steering servo, 'IN2' from Rx Steering channel, GPS lock on, MUX LED illuminates to indicate the autopilot is switching correctly, etc.Couldn't get it to work at first (details here: http://diydrones.com/forum/topics/ardupilot-not-working) but manged to get it working mainly by adding a dummy servo onto 'throttle' and reducing the PID values to reduce the turning circle so that AP could get accurate readings from the GPS and calculate it's trajectory and position.Once that was sorted (well it sort of worked...) then I moved AP over to an aircraft, the plane was an old Soarstar (similar to Wingo) which has had a wingspan increase of about 20%, it's rudder/elevator (only as I found out later) but was lying around gathering dust and is a very stable high-wing pusher plane. I had quite a few problems with the Soarstar mostly due to trimming it for hands-off flight as wing incidence and motor thrust had to be sorted out first. It would dive on application of power, not a desirable flight characteristic, so the thrust line was changed (+ up-thrust), this helped but it still wasn't right so the wing decalage was increased. eventually things were sorted and it flew very well (27 minutes powered flight on a 1200mAh battery)I didn't have an x-y sensor but the plane handled this ok, just the PID values needed to be turned down - to less than 10 from 30, if the turn was too tight the AP couldn't handle it. The plane self-righted extremely well due to having fairly high dihedral and the high (almost parasol) wing, and so coped without the x-y sensor pretty well.In anticipation of the x-y sensor arriving I installed ailerons onto the Soarstar wing however this later proved to be a problem as adverse yaw was excessive (the down-going aileron having so much drag that the plane wouldn't roll). I mixed out all the down movement of each aileron with my 2.4GHz Futaba 9CAP which improved the situation considerably however with the AP one has to use a y-lead for 2 aileron servos so couldn't use that mix any more as AP doesn't support two independent aileron servos (yet).Eventually my x-y sensor from FMA arrived and the plane and navigation was flight tested, stabilization was amazing but I couldn't get it to navigate, then about a week ago late one afternoon I got everything to work after some changes to the code (and a calm day). I was thrilled! - A Google Earth plot of a 2nd flight here: 2009-04-10.kmz

GE plot of soarstar flightHowever the plane wasn't even close to ideal so......onto a new airframe, I tested the Soarstar wing with a twin boom tail and pod fuse which was promising but the wing still seemed to be the problem, so got a friend with a CNC foam cutter to cut me a new wing using the GO-795B airfoil which just happened to be the right thickness for the size of the piece of foam that I had (wingspan is 150cm or 59", weight 750g or 26oz).The new plane was test flown on Monday the 13th April '09 without AP (flies really great!) and hope to fly it with AP installed this week.Further updates as they happen...

16 April 2009: Flew again yesterday with the new airframe and AP, the plane flew well but tended to "tuck under" as it sped up when gliding, so I've increased the decalage (angle of attack of the wing relative to the horizontal stab), I will move the cg forward a bit too (it's at about 28%).The AP on the other hand didn't work, the plane rolled from side to side very vigorously at first so I edited the code like so:#define head_error_max 25 //The maximun output in degrees to control the roll setpoint (from 45)#define head_error_min -25 //The min output in degrees to control the roll setpoint (from -45)The rocking from side to side now is still fairly pronounced but better, however the x-y sensor is mounted on the pylon as seen in the pic possibly exacerbating the effect, but there is very little flex so I'm not sure how to correct this... perhaps with the diagonal sensor placement coming in v2.1 will help?Navigation did not work, probably due to the rocking.17 April 2009:Did a very quick test fly this morning to check if the few changes I made had any effect, I have moved the x-y sensor onto the wing close to the leading edge and increased the decalage. I had originally put the sensor high and way ahead of the wing so that the wings wouldn't interfere with what the sensor 'saw' and having put the sensor now over the wing I can't discern much difference. The decalage change has as the plane no longer 'tucks' as it flies faster.The rocking is still very apparent so will start looking at the code again to see what can be changed...20 April 2009Went for a short test fly this afternoon after having reduced the height of the pod onto which the FMA sensor is perched, to less than 1/2 it's previous height ->... interesting... there was no change re: the excessive rolling.Then turned the #define roll_min and max values down to -10, 10 from -55, 55 ->... much better, the rolling is almost imperceptible now but with seemingly enough authority to correct any steep banking.So stabilization now is fine but it's not navigating at ALL.I tried disconnecting the x-y sensor and did some flybys a short distance from 'home', it seems to turn in the right direction when switching briefly to RTL but with the sensor plugged in there is no change in roll at all, the plane just continues straight ahead.Then disaster... last flight of the day after tweaking some code, rookie mistake - got muddled with switching the toggle switch, elevator and a wrong plane attitude at the same time, by the time I sorted things out the plane hit the ground... hard! Good news is that the AP board & GPS seem to be fine (although the impact broke the GPS header clean off the AP board) and the plane should repairable - bad news is that a wing servo's gone and the 2.4GHz Rx is also toast. $@#&...!Oh well, one of those things.I have soldered the header back on & the AP board seems to work fine. I replaced a tiny broken SMT capacitor on the Rx (that was the only damage that I can see), but the Rx flashes an error code constantly so will have to replace that and the servo. The plane also will take a few days to sort out. 'til then..24 April 2009Ok, plane rebuilt, had to completely rebuild the fuse and the center portion of the wing. It flew yesterday for the first time again just to check if everything was ok and then again today with the AP board. Everything works as it should on the ground. Testament to the strength of the EM406 GPS and AP board for surviving the crash!Tried the latest v2.1 but hit a snag, there are no waypoints at all under the waypoint tab. And if I copy those from v2.0.1 over it gives me a ' "wp_alt" not declared in this scope' error.So I can't use v2.1 until this gets sorted out. I uploaded v2.0.1 again and flew, things seem to be fine in the stabilization dept but it's still not navigating at all. Landed and tried a few different settings in the code but no success. Went up again and again trying different things and the plane was flying well until the sun started to set and things went a bit haywire, presumably due to the low sun and the IR sensors getting confused.I will try again in the morning and have raised the issues I've had on the v2.1 forum hoping for a speedy solution.25 April 2009Success at last, well, some limited success at least. Flew again this morning and had some time to experiment with different settings. The main problem was good stabilization but no navigation, but after about 12 flights today I managed to get the RTL to work reasonably well, it still needs more tweaking but things are looking up. The wind was bad today which didn't help as one really needs a calm day to test properlyWhat I established was that the navigation seemingly didn't have enough authority to override the stabilization. When I found what gave it more authority things were better. The plane would turn quickly towards home but then would fly past and not return, or return on a very very wide arc. Some more changes and it navigated fairly well back to home.Anyway I'll keep testing and post my settings here when they're sorted out.23 May 2009Had a chance to test and tweak the plane again today, conditions weren't ideal, very cold initially (winter's coming here) with a breeze from the south.The first flight (just using RTL function) showed that the plane was doing a couple of unwanted things:1) Climbed continuously despite the RTL altitude set at 5m2) Navigation:....a) zig-zagging a lot en-route to way point....b) long, very wide downwind turns once past 'home'to sort out 1) I changed with the following:#define pitch_trim - eventually settling on -33, the thermopiles somehow see that the plane is level when it is at about a 10° up pitch!???#define pitch_max 10#define pitch_min -60 - the aircraft somehow needs seriously more down than up otherwise there's no response from theservo - weird, the servo movement is normal and doesn't bind anywhere.to try sort out 2a) I changed with the following:#define head_P (to 0.8 from 2)to try sort out 2b) I changed with the following:#define head_error_max 50 //The maximum output in degrees to control the roll setpoint(from 20 to 50, 60 was too much)#define head_error_min -50 //The min output in degrees to control the roll setpoint(same)Will try again tomorrow if the weather's good23 July 2009Back after a break with ArduPilot, I had some mixed results with AP last weekend, spent some time tweaking the parameters for v2.0.1, getting the aircraft to behave acceptably. Was finding that the aircraft would bank too steeply to correct for a direction error. The setting "#define head_error_max" was very sensitive, on 58 it rolled not steep enough and 60 was too steep, so I settled on 59.Why this was I don't know, my understanding is the the roll correction and heading correction have to "fight" with each other to produce an acceptable change in direction. Heading is trying to cause a roll and the Roll (IR sensors) are trying to prevent one so there has to be a middle ground to allow the plane to do a turn, but not knowing/understanding properly what each parameter does it's very much a case of trial and error. At least this time I kept a few notes. As I experiment hopefully my understanding will improve as to what parameters affect what flight characteristics so that I can see a flight behavior that I don't like and then go straight to the code to correct it.Sunday I tried again but something was not good as the results were very erratic, some turns were very steep and others very wide. After some frustration I packed it in and went home.I decided to upgrade to v2.1.2, I can't go higher though as I can't buy the FMA z-sensor alone anywhere, FMA no longer sells them and only the XY AND Z can be bought from the AP shop, maybe I can persuade them to sell me only the z-sensor...?Tried again on Wednesday 22nd, and things were better but the trims were out by a quite a bit so it took some time to set those up so that there was no trim change when hitting the AP enable switch. It was windy too with a strange direction as a cold front approached. I established that it seems to work fairly well but with the wind and the cold I didn't get much flying time and that a few things needed looking at. I then played around with the Config Tool (Beta 3) 's source code and have made some substantial changes to the layout. It's been sent to Jordi to have a look at so maybe it'll become the new v3.1.This weekend I'll try again, just need a calm day...Aug 2009Have been testing on and off for a few weeks now but it's been pretty frustrating. The navigation is problematic, it will either make repeated wide S-curves toward the waypoint responding sluggishly, and/or miss the waypoint completely and make stupidly wide turns to get back to the missed waypoint. I was expecting more precision but no matter what I do I can't get it right.my settings are as follows:#define head_P 1.5 //.7 Heading error proportional (same used to move the rudder)...#define head_I .1 //.1heading error integrator Not used#define head_D 5 // experimenting with this to see what happens, 5 does seem to help a bit.Will try get a GPS log of what's going on this w/e14 October 2009Here's a video of my main problems - frustratingly the AP can't maintain a straight line to a waypointzigzag.wmv (2.11MB)Haven't been doing much testing or flying. However I did see a UAVDevboard equipped plane fly and am very impressed with it's performance so much so that I think ArduPilot was maybe the wrong choice.My advice, do your research carefully before deciding on a system, ArduPilot came across originally as a cheap good performer. It's not cheap (>$200 for everything), it's a fair performer but may have been superseded by the various other systems around, IMU's etc.I now have to decide if and what to upgrade to?Graham
Read more…

IMU alignment code progress

Posted by Tom Yochum on April 13, 2009 at 9:43am
We received our IMU!Brian is busy making it talk to the Arduino board. Meanwhile, I have been working on the alignment code. The alignment proccess uses the IMU's sensors to determine its orientation (roll, pitch, and heading) while stationary. I spent the last few days writing code based upon this document. Sorry, it's not free. Based upon the equations given in the paper, I wrote a Kalman filter that iteratively converges to the true orientation while the IMU is stationary. I wrote the Kalman code in Matlab and created a Simulink model to provide the sensor inputs. But that is as far as I got. Apparently, the student version of Simulink has a limit of 300 blocks.So I spent all that time and was so excited to see this thing run, and I got nothing. I wanted to pitch my laptop off the balcony.So now I need to do a bunch of work to turn complicated sets of Simulink blocks into a single Matlab block just to get the number of blocks below 300. I have also asked for a quote to upgrade to a new version of Matlab/Simulink, but I already know that is out of my budget.I hope to upload some simulation results as soon as I get the code running.Tom
Read more…
T3

A theoretical approach to choosing your airframe

Posted by Sami Finnila on April 13, 2009 at 9:00am
As a part of a paper (some school stuff) covering my NXT AutoPilot I went into details of choosing an airframe. I thought that this might be of intrest to you as well.Here is something to consider while choosing your airframe:

(, where F(i) is drag, P is required power, v is the required speed to keep the airframe aloft, m is the mass of the airframe, A is the wing area and k, rhoo, and C(v) we can assume to be constant.)From the equation we see that if the weight of our airframe doubles the needed power to keep it aloft gets multiplied by almost three: 2^(3/2))=2,818... Also if the wing area doubles we need only about 3/4 (actually about 0,7) of the power we needed before (assuming the coefficients k and C(v) are constant). This is, of course, based on idealized situations but it's probably something worth keeping in mind while choosing your airframe since the more power you consume the more expensive your set up gets and your flight times get shorter. You might also want to consider the following:

, where 'a' represents the scale (size coefficient) of the airframe (again a highly idealized situation). But if we combine this equation with the first equation we come to the conclusion that the smaller the airframe the better. If we, for example, choose to use a model half the size of some other airframe we are going to consume only about 1/10th of the power we would use with the bigger model (if we assume the wing area to be roughly 1/4th of the bigger airframe and the shape of the both airframes to be identical).You should note, however, that these calculations only take the power needed to stay aloft into consideration and if you carry a payload the weight of which doesn't vary with the size of the airframe you will probably have to resort to bigger airframes.
Read more…

Two funerals in one weekend :-(

Posted by Jonas on April 13, 2009 at 4:30am
How two Ardupilots died in one weekend.Yes I was so proud. I had a perfect working ardupilot. I was going to attach my just arrived Z sensor.Then Murphy law kicked in. When a friend was over I showed him my ardupilot. and the working.The positive power line of the lipo accu was not perfectly isolated and made contact with the back plane of the ardupilot.Yes it fried it. :-( . No swet I have a spare one). Solderd the headers tested the upload all fine. Now I needed to load the new firmware for the failsave. I dit this before and had some trouble but I managed. Now I really made a mistake. I forgot to power the arduino externally with the esc when I burned the hex and fuses and is not responding any more. So my attiny45 is gone now. So I just logged in the sparkfun site to backorder two new Ardupilots. And some xbee's end some other stuff.
Read more…

A "realistic" UAV flight dynamic model of a popular UAV airframe

Posted by MC on April 13, 2009 at 2:06am
  • How to create a "realistic" UAV flight dynamic model of a popular UAV airframe (such as Mutiplex EasyStar ) for simulation?
  • Is it possible to create a generic model such a way that the model can later be re-configured for different UAV airframes?
The model should be able to accurately approximate the next state (position, attitude, velocities and accelerations) of the UAV given its current state and control inputs (throttle, ailerons, rudder, elevator control values). That is, the model should tell me what will happen in dt (delta t, i.e. short time interval) time in the future if I apply a know set of control inputs.
Read more…

Hardware-in-the-Loop test results of inner loop/navigation

Posted by SLUGS Team on April 12, 2009 at 11:18pm
Waypoint tracking is one of the most sought-out features in an autopilot. Essentially it allows the end-user to program (generally via a map or an aerial picture) a path (composed of waypoints) that the UAV is commanded to track. When we started working on SLUGS it was clear that this would be the first high-level feature we would add.Today I am happy to report that it is fully working in software simulation and hardware-in-the-loop (HIL). You can read a bit more about it here and watch a couple of movies showing results from a Simulink software simulation and a full Hardware-in-the-Loop test.
Read more…
3D Robotics

How ArduPilots are tested at Sparkfun

Posted by Chris Anderson on April 12, 2009 at 9:25pm

While we're waiting for the Atmega328 chips to come in so we can restart ArduPilot production (hopefully by the end of the month), I thought you'd be interested in this picture of ArduPilot being programmed and tested, which showed up in a Sparkfun post about their in-house production techniques. Here's the description: "Thanks to Pete, our in house test bed master and proprietor of the "sneaky footprint", we use pogo pins for our test beds in production. "
Read more…