The ladder crew came to the rescue! The plane lives to fly again in round three, the final round! I'm not sure how much more drama I can handle....this is nail-biting stuff. And the wind has picked up. Yikes---will we pull this off? Stay tuned....
Read more…3D Robotics
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
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!
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
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:
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…
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
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…
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…
How to create a "realistic" UAV flight dynamic model of a popular UAV airframe (such as MutiplexEasyStar ) 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…
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
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…
Has anyone achieved autonomous takeoff and landing with ArduPilot yet? If so can you share with everyone how you accomplished it. I have been wondering how to achieve this and what additional sensors / hardware will be required. Is it just a matter of setting way points and triggering certain tasks to take place at those way points for both take off and landing, or is there another way to accomplish this?
Read more…
Posted by Bryan Cuervo on April 12, 2009 at 8:46am
I posted an earlier blog with pictures on how I placed the avionics in an EasyGlider Pro for autonomous flight. I found out that was the easy part! Now I’m performing flight tests to hone in on the code mods for stable flight ( as Jordi states, the latest code is optimized for the EasyStar). My method has been:Fly and observe performance in autonomous mode – record observations – make code modifications on laptop – remove GPS and upload code – replace GPS – fly again. Laborious but also fun since physical computing yields immediate effects that you get to see.I’ve attached a table I made in Excel to organize my iterations and keep me on track. Maybe this will help others in the same situation. One mistake I made was getting in a hurry to go fly. I could have found out about the reversed servo throws and IR sensor placement by just walking the plane around on the ground and changing its attitude by hand. This would have avoided the “death spirals” I experienced on that first day of flying!Bryan
OdysseyThis is a unit for a full size plane, but it would be nice if the GCS could look something like that when it's done!! This unit also have a very impressive list of features. Wonder if one can use it as a GCS+AP and have only the sensors with Xbee on the plane.
Read more…
Hey everyone,I haven't been on the site in a while and I am amazed at what is/has come out of this community in the past 8 months.Anyway, I made a blimp last year for a class at RISD taught by Paul Badger. The blimp follows people. Its based around the arduino, a pyroelectric sensor, and an ultrasound sensor. The code is quite simple: it scans for heat (IR at ~ human frequency) and once it finds a maximum above threshold, it moves towards the location of heat and corrects for height.I started out with some mathematically complex programming but soon learned that very simple rules performed satisfactory. I don't plan on adding any more advanced controls or processes: its simple, stupid, and fun.A video of the blimp is here.also on the video is some other stuff I've done including a drawbot that draws in polar coordinates, and a bicycle powered record player (hah, not done).
Read more…
Posted by Robert Drone on April 11, 2009 at 7:18am
What does anyone think of this radio:http://www.nitroplanes.com/72waraco4chf.htmlWalkera Radio Control 4 Channel FM Transmitter Perfect for Helicopter and Airplane4 Channel R/C Set included, complete Left/ Right, Up/ Down Control ( RUDDER, AILERON, ELEVATOR AND THROTTLE. Suitable for Indoor / Outdoor / Backyard / Park ( 500 sqft area )Includes:One 4 Channel FM Transmitter w. Tx Battery holderOne ReceiverOne Crystal SetOne Receiver Battery Box w/ BEC connectorTwo 9 Gram ServosOne Switch HarnessOne Tx AntennaBattery HolderRequires: 8 AA batteriesRegular price: $99.95Sale price: $44.95It looks good to me and very affordable. What does every one else think?Link:http://www.nitroplanes.com/72waraco4chf.htmlRead more…
