Effects of frame design on barometer performance ( and all other non 3.3 specific AC questions)

According to Randy the know issue of altitude loss after a high speed run is at its heart a frame issue.

This seems to me a very worthwhile discussion to have.

Once the majority of us understand this, we will be less likely to muck up other threads.

Take it away Randy...

Views: 14289

▶ Reply to This

Replies to This Discussion

Permalink Reply by Wes on August 16, 2015 at 10:41pm
Permalink Reply by Randy 7 hours ago
Ok, so this is a "known issue" called "altitude loss after fast forward flight" in all versions of Copter including AC3.3 and is not an issue we were attempting to resolve with AC3.3. In this way it's a bit off topic but in any case, it's the barometer being upset by pressure differences caused by wind hitting the frame at different angles.
This is quite visible in the log. When the vehicle's Pitch angle (yellow, scale on right) goes to 40 (leaning back) the barometer altitude (dark blue, scale on left) climbs from 6.7m to 13.5m (a nearly 7m change). the 7m baro climb drags the inertial nav altitude up so it thinks it's climbing and so the vehicle descends to compensate.
There have been discussions on software solutions but at heart, it's a frame issue. A frame that's built with the baro effect in mind does not suffer from this effect. An IRIS for example does not suffer from this because it has somewhat balanced air holes on the top and bottom. A Solo does suffer from the problem because it's a closed top with a large hole on the bottom for the gimbal.
If we want to discuss this item further could someone create a separate discussion and post a link?

DeveloperPermalink Reply by Randy on August 16, 2015 at 11:32pm

So the issue is discussed on this to-do item but in short, on some frames a pressure bubble forms when the vehicle leans back especially after a fast flight forward.  This causes the barometer to read a low pressure, which makes it thinks it's climbing so the vehicle's altitude controller asks the vehicle to drop.  Here's a video of the effect.

Below is a picture of a device that Leonard tested with on a large copter that was suffering quite seriously from this interference.  The metal tube has a rubber tube attached on the non-visible end which is then hot-glued over top of the Pixhawk's barometer case.

To use it the circular end should be placed so that as much as possible it's out of the air wake of the vehicle.  Because of the shape, the pressure is as equal no matter the attitude.

It's just a prototype and there have been similar prototypes tested by John Challinger and David Pawlak and have been shown to reduce the interference.

Another proposed solution (from Leonard) is this hamburger-ish style case that the flight controller is placed in. The brown squares are airholes, the rest of the case is sealed.


DeveloperPermalink Reply by leonardthall on August 17, 2015 at 12:21am

Hi all,

I have done a fair amount of work looking into this issue. There are a couple issues that are at play here.

1. During takeoff there is a high pressure bubble caused by the down wash of the blades hitting the ground. This causes the autopilot to think that it is going down when it isn't or it thinks it is at a lower altitude than it really is. Depending on exactly what happens this can result in a slow take off or an overly aggressive take off. In landing this can cause the copter to bounce on the ground or pause just before touch down.

2. During forward flight the baro can experience a change in pressure caused by the air flowing over and through the copter. This is normally a reduction in pressure causing the baro altitude to increase. This increase in altitude causes the EKF to make corrections to it's vertical position and velocity. Because the autotpilot thinks it is too high it compensates by reducing it's altitude. This is the characteristic drop on forward flight behavior.

So to explore this problem I added a static port to a standard pixhawk so I could connect it to specific ports around the fuselage of a copter. There were 5 configurations I wanted to compare (I haven't got to number 5 yet) :

1. Standard umbrella setup

2. Single static port on top

3. Two static ports on each side connected using a T junction

4. A double disk connected using a brass tube and mounted 100mm above the fuselage

5. The standard 3dr pitot tube static connection mounted at the front of the copter.

Here are a couple of photos.

I found that both the side ports and the double disk worked quiet well, the double disk in particular. However I could still get some altitude drop in some directions at some speeds. The port on the top of the fuselage worked very well at low speed but could get 30m altitude errors at speed!!!

Based on what I have seen so far the best approach is to sit the pixhawk on a nearly solid plate with minimal holes in it. Then cover it with a dome of some sort, leaving only a small gap around the edge. This should then minimize altitude variations caused by attitude and speed.

Looking at the logs I believe we can still get significant improvements from the EKF in the way it handles these errors. However, this is fundamentally a aerodynamic problem and as such to completely remove this effect the air frame must be designed to provide a quality static pressure measurement.

Permalink Reply by Rob_Lefebvre on August 17, 2015 at 4:09am

Good to see this testing being done, my gas heli is really badly affected by this too.

I think the idea of having the Pixhawk in a hamburger-case is not a great one, because it makes the device very large, it's already large enough.  I would prefer the concept of have optional external barometers, as it requires less space, and also allows us to place them in an ideal location on the vehicle.  Ideally, I'd like to have a baro board with just a port, allowing the user to port it however they want.  In some cases, dual ports on the side might be best, in others, the sandwich plate might be best.

Permalink Reply by Wes on August 17, 2015 at 5:25am
Could some photos be posted on how to modify a standard Pixhawk case to allow for a static port?

Randy mentioned that Iris does not suffer the same way the solo does, could we elaborate on what a "good" frame looks like?

Thank you for the insight so far, I am being enlightened.
Permalink Reply by Wes on August 17, 2015 at 5:43pm
Here is a link to another deep discussion on the baro effect:

https://groups.google.com/forum/m/#!topic/drones-discuss/TsuDlbWn_qc
Permalink Reply by Wes on August 17, 2015 at 6:49pm
Where is the INAV_TC_Z setting located?

I have scanned through the full parameters list multiple times.
Did the name change? NTUN is another I am having trouble finding in the 3.3 logs.
Permalink Reply by Wes on August 24, 2015 at 8:13pm
I have found the answers to most of my questions...

Rather than approach the alt hold as a function of baro data, could alt hold be approached as a function of changes to the accelerometers?

No frame design will over come sudden changes in barometric pressure such as are found in windy conditions or behind obsticals.

I understand lidar could work as a more precise alt hold in changing conditions, but I think it could be possible do achieve a comparable result through code.

Perhaps a seperate flight mode in which changes accelerometers are weighted more heavily than the baro or GPS. The weighting could be such that flight controller ignores baro/GPS position changes less than 2m for alt and 2m for GPS.

It could be called "Severe Conditions mode".

A mode that is not intended to be precise, but a limited hold in severe conditions.
Permalink Reply by Richard Kennedy on August 24, 2015 at 8:16pm

This is what I did and it works great. As expressed in this thread by others it's a balance of getting air but not high or low pressure from flight. I had to play around a bit with this. I ended up with the front of that plexiglass cover a bit higher than the back. I think it develops high pressure in the front from forward movement and a bit of a vacuum effect in the rear. Anyway I can easily go 25-30 mps with very little alt change. Around a meter. But as important it doesn't change when I let go of the stick and let it coast to a stop. But not easy to come up with a universal fix for all the DIY airframes out there!

Permalink Reply by Richard Kennedy on August 24, 2015 at 8:26pm

re-external baro...I also like that because I think if one dunks his MR in the drink the baro can be ruined? Have you heard of that Rob or is this a myth? Anyway an external baro would be beneficial in this situation as well. 

sorry WAY  OT did you ever try a Pixraptor? I know you have interest in other open source controller designs is why I ask and I might spring for one. I've now bought 2 apm's and 2 pixhawks I think every 5th controller I will try a clone or OPPS I mean a compatible type design. ha 


DeveloperPermalink Reply by Randy on August 24, 2015 at 8:34pm

Wes,

The INAV_TC_Z was the inertial nav parameter that's been replaced by the EKF's EKF_ALT_NOISE parameter.  Here's a wiki page with some EKF info.

Permalink Reply by Wes on August 25, 2015 at 7:14am
Does the EKF AlT noise parameter allow an input greater than "1" such that reliance on the accelerometers is greater than the baro?

If yes I would like to experiment with this parameter. When I have altitude drift the barometer does not show the change so I would like to weight the accelerometers more heavily and see what happens.

▶ Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service