A blog of my experiences with ArduPilot

Having 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 flight

However 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 2009
Went 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 2009

Ok, 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 2009

Success 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 properly

What 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 2009

Had 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 5m
2) 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 the
servo - 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 good

23 July 2009

Back 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 2009

Have 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/e

14 October 2009

Here's a video of my main problems - frustratingly the AP can't maintain a straight line to a waypoint

zigzag.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

Views: 616

Comment by Reto on April 15, 2009 at 11:56am
Graham, great summary review of progresses and congrats for your successful flights with AP! Reading the post title, I expected much more misses than successes. I was wrong and that's good news for all of us who still are tweaking, preparing, or building and coding. Thanks.

Moderator
Comment by Graham Dyer on April 15, 2009 at 12:41pm
Thank you, appreciate that.
Comment by Bryan Cuervo on April 15, 2009 at 3:11pm
That is a thrill to have your plane fly autonomous for the first time! Did you fly RTL only or were you able to fly waypoints? I'm finding it takes a lot of code tweaking to get reliable flights, especially with roll gains.
Good luck.

Moderator
Comment by Graham Dyer on April 15, 2009 at 11:12pm
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)

I agree too, more tweaking than I thought.
Comment by Michal on April 16, 2009 at 3:13pm
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

Moderator
Comment by Graham Dyer on April 17, 2009 at 12:10am
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
Comment by Gagarien on April 17, 2009 at 4:29am
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!
Comment by Bryan Cuervo on April 17, 2009 at 4:51am
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.

Moderator
Comment by Graham Dyer on April 20, 2009 at 10:37am
Boom height change to lower x-y sensor made no difference (see update)
Comment by Bryan Cuervo on May 23, 2009 at 10:56am
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.

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service