I have been chasing my tail over the last few days trying to get my ASI to match (average) GPS speed by manually changing ARSPD_RATIO according to the wiki. Unfortunately we have not had a day with less than 7m/s wind at height and using the average GPS speed to set the airspeed will (I think) result in errors.
My thinking – If 10 large circles are flown, the ground distance is 10x circumference.
If the plane had flown 10 perfect still air circles it would have drifted downwind by (time for 10 circles) X windspeed and therefore covered a greater ground distance.
I think, with a theoretical perfect ASI, when flying circles in a wind the average airspeed will be greater than the average GPS speed, making ASI calibration a tricky problem and best done in as near calm conditions as possible. Probably the auto calibration method will have the same error.
I’m sure its not too difficult calculate and account for this.
Id be happy for someone to tell me if this theory is not correct for determining airspeed in a circular path with wind component, and therefore allowing for a better ASI calibration.
This has my brain spinning gears so I’m going to be careful what I say just in case I’m missing something. Generally I don’t think you can get the average GPS speed to match the ASI. Apples and oranges. But I’m going to hold off on that line of conversation for a while as I chew on it some more.
One practical comment I have is how are you doing the circles? If they are in any automated mode (circle or loiter) then you need to look at the throttle setting. Arduplane will adjust the throttle in a turn to maintain altitude and for stall prevention. For this method to work I would expect you’d need to hold throttle, and bank angles consistent through the turn.
I don’t see any mention in the wiki of trying to match GPS speed. It’s an invalid comparison. Indicated airspeed is dependent on air density and will almost never match true airspeed, much less ground speed (which is closely analogous to GPS speed).
See here for a somewhat technical explanation of the ICE-T concept.
https://www.aircraftflightmechanics.com/AircraftPerformance/Airspeed.html
EDIT: I guess I do see some assumption about ground speed built into the manual tuning procedure. Begs the question as to what elevation you’re at and altitude you’re flying and/or whether air density is low due to the hot summer. Have you tried the automatic calibration process? It seems less prone to error.
I agree, it can get a bit baffling when first trying to consider the effect of the wind when flying ground circles but I think I have now grasped how to estimate the airspeed from groundspeed in order to calibrate the ASI.
I was flying the circles first in a large radius loiter and then in waypoint auto with a 400mtr radius. In both cases the indicated airspeed (uncalibrated) was at least very constant. I followed the wiki advice for manual calibration but it occurred to me that taking the average groundspeed did properly account for the wind. In an ideal world there would be a still air day to allow for calibration but here, we have not had one for weeks, so next best thing is to try to figure out a way that accounts for wind. I think I have.
Yuri, the last paragraph in the manual calibration method advises to calibrate the average airspeed to match the average groundspeed. I can see the temptation to assume that by taking the average groundspeed you have accounted for the fast downwind and the slow upwind sections of the circle and eliminated the wind effect. I think this is incorrect and the average groundspeed in a circle will decrease as the wind increases. The time taken to complete a full circle can be shown to increase with windspeed by taking the extreme case where airspeed = windspeed. The aircraft will become stationary on the upwind segment and the time will be infinite (so GPS speed = 0).
Since we are talking about mostly slow flying aircraft, a light wind could produce a large error.
I think its possible to get a good estimate of TAS like this -
Half the difference in GS between the fastest and slowest bits should be the windspeed.
Add the windspeed to the slowest GS (which should be directly into wind) and you should have a reasonable estimate of TAS to calibrate your ASI against.
In my case the conditions are very close to sealevel ISA so in still air the difference between ground and air speed (and TAS vs IAS) should be insignificant.
I can see that the auto calibration would be less prone to human calculation error but Im afraid that it is simply using the same theory as the manual system. Perhaps its not. Please advise.
Pic is a portion of my last flight with 400m radius WP circle in auto. In this case I think my ASI is over-reading by 1.13m/s. Perhaps not too bad.
You’ll see by my edit above that I did miss a key point in the wiki before my initial post.
If you’re that close to sea-level ISA, then I agree that no-wind groundspeed (true airspeed) and indicated airspeed should be very closely matched.
Your assumptions check out, and I think you can simplify the math by simply taking the median of the slowest groundspeed (trough in the plot) and fastest groundspeed (peak in the plot) to negate the wind and derive your true airspeed.
If you don’t mind sharing a log of that flight, I’d like to have a go at some transformations using MP’s log viewer (or maybe MavExplorer).
So here’s a thought experiment that I just worked out. If you can read my scribble, I’m working out what happens if you go A to B in no wind, and then with a wind. I know you’re using circles but I’m not that smart to do that math so I hope this makes my point.
A to B is 500m. So for each case the round trip is 1000m and the airspeed 15 m/s.
In no wind, it takes 66.6 seconds round trip. 1000m/66.6 seconds = 15 m/s. No brainer.
In a 5 m/s wind the A-B trip (tail wind) has a ground speed of 20m/s and takes 25 seconds. The B-A trip (headwind) has a ground speed of 10m/s and takes 50 seconds. Round trip 75 seconds. 1000m75 seconds = 13.3 m/s.
So all this to say I don’t think using GPS/ground speed will get you the average you’re looking for.
I’ve always used the auto calibration and it’s returned pretty accurate results based on flights in no wind conditions.
Okay, I just read your response to Yuri, and I think you’re already thinking what I’m talking about. I live about 1000m above sea level so getting to standard day conditions, even corrected, is not often reasonable. So again, I’ve relied on the auto calibration. I won’t use airspeed sensors on the maiden flights but I’ll turn them on so I can see the data to know it’s working. When I’m ready to turn on the airspeed I’ll fly a figure 8 pattern for the calibration. I’ve never got too far into the analysis but just comparing the AS vs GS on those rare non-wind days I feel the results are acceptable for the quality of sensor and the effort that was put into it’s placement on the airframe. 
Indeed, averaging groundspeed samples over time probably results in error. Averaging groundspeed samples by position on the circle would be more precise, but MP won’t display that. But again, the median between the peaks and troughs is the way to go and is easily calculated.
In fact, you can see the fallacy in averaging over time in the last screenshot. The peak groundspeed is 18.11, and the slowest is 4.21, giving a median value of 11.16 (so wind speed =7.95 m/s). Compare that with the mean value of 8.91 as displayed by MP.
Auto-calibration allows for air density correction, so that’s probably well advised when flying at higher elevations/altitudes or extreme temperatures, and it might be interesting to compare Vince’s results from a manual plot vs an automatic calibration on the same flight with BARO_GND_TEMP set appropriately.
We are defiantly on the same path. I find it helps to confirm my logic by checking the extreme case, as I said above. In your experiment, if the windspeed was the same as the airspeed, when the plane turned around to come home it would be stationary. The same applies even it were tracking 90deg to the wind. Just to stand still it would have to face directly into the wind and make no progress along the route.
Yuri, Im feeling a bit daft. I cant upload .BIN or .LOG of that flight. I know in the past I had this problem and realized I was doing something stupid but cant remember how I overcame it. Is there a max size? Its about a1M.
Yeah, there’s a max size. Use Dropbox or Google drive.
Thanks. I would appreciate an expert opinion on my attempts.
Notes about the files.
First flight -
I havent flown fixed wing RC for many years. I didnt trust FBWA on an untuned plane. Its quite large to hand launch with one hand so the takeoff was almost a disaster. Did some loiter circles to get readings for ASI calibration. Tried to find out the stall speed. This plane has a very nasty stall spin. Disaster narrowly avoided.
Second flight-
Tired auto takeoff mode - very nice. Did auto tune. Flew nice in FBWA before tune but a bit better after. Tried auto waypoint circles to check ASI again. Many of them. Tried different speeds by nudging throttle.
Again tried to check stall speed. Again very nasty wing drop. Didnt know how FBWA would cope with stall/spin so switched to manual to recover (very close to ground).
Thought I was in FBWA and tried to land. It woudnt come down. Switched to manual to land. Later after checking logs, realized I was still in Auto.
Thanks for checking logs. Any advise appreciated.
I’ll have a look this afternoon. I might be able to offer some basic tuning advice, but Plane is not my forte. I’ll definitely look at the airspeed calibration, as applies to this topic.
Sounds like this particular model has some nasty stall characteristics. We can probably estimate wings level, unaccelerated stall speed from the logs and keep you well away from that in the future. Depending on the motor arrangement, the spin tendency could be exacerbated by high throttle settings, so it might be prudent to chop the power during recovery, so long as you’ve got some altitude to spare.
The topic captured my interest, since my career is in fixed wing aviation, and I have an ArduPilot equipped plane on the bench waiting to fly.
I’ve looked at the second log. I think you need to run auto tune again and finish up the pitch. Roll finished and saved values, but pitch didn’t and I can see in the auto mission where the pitch is lagging behind. Not bad, and obviously flyable.
FBWA does a great job at preventing stalls, but if the plane does get into one, it does a horrible job of correcting. FBWA will try to keep the nose of the plane up and if a stall develops it will just aggravate the stall condition. It doesn’t “know” that that plane is stalled. If you do get into a fully developed stall, manual is your best friend.
I ran Magfit on your compass to help your compass calibration. Here’s the numbers:
COMPASS_OFS_X 30
COMPASS_OFS_Y 53
COMPASS_OFS_Z 39
COMPASS_DIA_X 1.015
COMPASS_DIA_Y 1.002
COMPASS_DIA_Z 0.984
COMPASS_ODI_X -0.010
COMPASS_ODI_Y -0.023
COMPASS_ODI_Z 0.002
COMPASS_MOT_X 0.480
COMPASS_MOT_Y 0.732
COMPASS_MOT_Z 1.243
COMPASS_SCALE 0.98
COMPASS_MOTCT 2
Looks good to me. There’s always room to fine tune but that gets into what do you want from the plane.
Thanks for taking a look Allister, thats interesting. Where do you see in that file that it didnt complete the pitch tune? Im still a beginner at analyzing these files.
Wandering off topic a bit but I have taken a look at this stall event. Im blaming my plane for having a vicious stall but I think FBWA is partly to blame. Take a look at the pic. I could have missed something but this is how it looks to me —
As I see the nose dropping slightly I stop pulling more up but the AP puts full up elevator (if im not mistaken).
Then I push. The AP is a bit late but then puts down elevator. I see the airspeed looks sufficient and begin to pull. the AP keeps negative elevator right up to the moment I select manual. Then normal(ish) recovery.
Is that what you see? Why would the AP keep negative elevator when im pulling and airspeed has recovered?
EDIT- Checking my parameters, it looks like stall prevention is turned on with a minimum speed of 11 but the speed gets below this and elevator keeps going up?
Yuri, me too. 35 years as commercial pilot and soon to retire. Will probably instruct in the sim a while longer.
In FBWA you aren’t controlling the elevator (or ailerons for that matter). You are requesting a pitch angle. That’s why there is the delay, and also why FBWA is so bad at correcting for a stall. The nose drops, but the FC is still trying to maintain the angle. Even when you push the stick forward in a stall, if the plane drops below the minimum pitch angle, the elevator will be up because it’s trying to bring the nose back up to that minimum pitch.
Stall prevention won’t do anything once a stall is developed. But it will lower the nose in steep turns, and in modes with throttle control such as FBWB or Auto, it will increase the throttle in turns as well.
Since we’re all admitting our poor life choices, I’m a helicopter mechanic (AME) and instructor. And I flew fixed wing for a few years. But now I get to play with drones nearly full time so can’t complain too much.
Edit: Forgot to say, I used MavExplorer to look at the logs and with that I can see all the in flight messages and parameter changes. There was a message about the roll being finished, but nothing about the pitch. Also, I could see the new roll PID values, but none for pitch. Mission Planner will technically do the same, but it’s so hard to pull it out that it’s really easy to miss there.
Here’s what I get for ARSPD_RATIO from the one brief time I see what appears to be about 2 circles in Loiter:
I assume this area of flight 2 was where stall speed was being tested, where speed is slow and it appears there are some pitch excursions:
On your first flight, indicated airspeed was 10-12 m/s where I thought I saw your bobble on takeoff, but that was in a climb, so probably not the best indicator of unaccelerated stall.
On flight 2, it looks like 7-9 m/s is where you experienced troubles (with an updated airspeed ratio of 2.27). If that matches your observation, then:
For stall prevention, I think you’d want to set ARSPD_FBW_MIN to at least 10 m/s and enable STALL_PREVENTION.
Yes that does match my observations. As you say, the stall happens below 9ms. I’m away from the computer right now but I’m 95% sure the stall prevention was turned on with a minimum speed of 11 but the AP keeps full up at much less than 11. I’d like to understand this better.