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
I just read that 2.2 will be released in a few weeks. I predict that we will get more predictable results with this along with adding the new shields with the pressure sensors. I probably won't do more tests flights until I get the updates.
I'm still using v2.0.1 so don't have Alt_pitch_min so have just tried the #define pitch_trim in this version which seems to have helped a lot, will re-try and see what else I can improve. Fortunately the weather's very good here this time of year - very few clouds 'till October :-)) I did have some trouble but only once with the setting sun affecting the IR sensors.
Graham,
You can also try lowering the Alt_pitch_min value to stop her from climbing. It seems the best settings one day won't work on the next! I'm guessing it's the IR sensors affected by the weather.
The other issue is an inconsistant throttle speed.
By "rocking", do you mean roll? In my EasyGlider, the roll corrections(rocking about the X axis) were exaggerated. What worked for me was changing the #define roll_min and max values and changing the #define roll_P value. I found that changing the proportional gain (P value) made a HUGE difference.
PS
Really like your little, twin boom design. I've been thinking about the same thing but with an A tail.
Hi Graham, you can definitely lower that boom. I’ve had good stabilization with CPD4 mounted just in front of the leading edge, the aft sensor was partially blocked.
Your roll is exaggerated by the longer moment arm. Good luck!
I was down to 6 and -9 but that was without the FMA x-y sensor, (the Soarstar turned better one way compared to the other hence the differential). The PID gains were the only changes I made as it's main problem was turning too tightly. Once the sensor was installed I just used the default gains in v2.0, there was still some rocking but the AP was controlling rudder/elevator for that flight so it wasn't that bad.I did mechanically reduce the rudder throws though.
I just have the x-y sensor and not CPD4 so I can't change it's angle until v2.1
Graham, very exciting story. I believe rocking would be less visible if you shorten the pylon with X-Y sensor. You can try to turn the sensor 45 degrees in horisontal plane and reconfigure CPD4 for this angle.
I have small AP about 1 m wingspan. It has similar tendencies to zig-zaging and not following WP. It would be great for me to know what PID gains were during your succesfull Soarstar flight. Did you decreased heading_max and min as well?
Regards
Michal
RTL worked and waypoint nav too, a Google Earth plot here: 2009-04-10.kmz (I discovered on the new Goggle Earth one can rotate around a point using CTRL and left click)
Comments
Am attempting a similar project of my own but am still light years off. Nice..your very interesting new plane was flown on my birthday!
You can also try lowering the Alt_pitch_min value to stop her from climbing. It seems the best settings one day won't work on the next! I'm guessing it's the IR sensors affected by the weather.
The other issue is an inconsistant throttle speed.
PS
Really like your little, twin boom design. I've been thinking about the same thing but with an A tail.
Your roll is exaggerated by the longer moment arm. Good luck!
I just have the x-y sensor and not CPD4 so I can't change it's angle until v2.1
I have small AP about 1 m wingspan. It has similar tendencies to zig-zaging and not following WP. It would be great for me to know what PID gains were during your succesfull Soarstar flight. Did you decreased heading_max and min as well?
Regards
Michal
I agree too, more tweaking than I thought.
-
1
-
2
of 2 Next