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: 14293

Reply to This

Replies to This Discussion

Artem,

I understand why you would think that your test eliminates aerodynamic issues as the culprit. However, if you had a copter that didn't have the problem to begin with, removing flight controller's case may not cause the problem to appear.

Can you share any pics of your setup?

I've concluded testing of my baro mod. Today I tried placing it on a mast of it's own, higher still than the GPS and I had the same performance as the stock Pixhawk. I'm not sure what happened. Initial results looked so promising. I'm not ready to give up on the remote port yet. Others have had success this way, and the reasoning seems too sound to ignore.

I sent the Gill inlet CAD off to a 3D printer today. I tried to keep it small and light, and it looks like the geometry is small enough that the only way to reproduce it well is on PolyJet, which is a pretty expensive process. I'd still be happy to make the files available to the community, if it works. There may be a way to massage it to make it more DIY friendly, but is unlikely to ever work well with FDM. It'll be a few weeks before all of the parts show up, so I won't have testing results for a month or so.

In the interim, Leonard, your design, using two disks of FR4 looks pretty cool. Can you share more details? 

Lol, which one, I have quads, tricopters, Y6, 250mini quad... All.completelly different setup and all suffer from this issue. I am building APM powered copters since 2011-ish and ao far exactly the same copter with the dumb naza thrown on it instead of a pixhawk will fly in a straight line! This been the case from the beginning! (at least my beginning) 

Can't say how would naza perform.on a tricopter simce its not supported, but it handles Y6 basic flight like a champ! 

Is the Naza using gps for altitude maybe? Does it work with a real low sat count? 

My naza equipped discovery flies strait fast and low.

My naze32/w baro on a mini 250 looses altitude the same as my Hawk platforms.


Is unreasonable to think that Dji also encountered this altitude sink issue and made a software patch to fix it?

Would it be terribly difficult to add some kind of altitude compansation relitive to initial acceleration in to the code?

Might be worth a try.

Nope, GPS alt is really imprecise.... Mybe yes maybe no, I just know that even without gps naza alt hold works very well, its called attitude mode. I believe they rely much more on accelerometers and gyros filtering out regular vibrations very well.... I just know that I never had to worry much about balancing props with naza to fly well, only for good videos. 

There's a parameter coming in Copter-3.4 that will allow using the GPS as the primary altitude input to the EKF.  I haven't tried it yet.  Even with that change, I don't think there will be blending of GPS+Baro.  It's one or the other.

To reduce the reliance on baro and increase reliance on the accelerometers, there's a parameter listed on this wiki page called EKF_ALT_NOISE.  Increasing that number will reduce the reliance on the barometer (and increase reliance on the accels).  I haven't played with it myself but we had something equivalent in the older inertial nav and it really was a trade-off.  A higher number would make the vehicle more prone to vibration problems.

Imho robust vibration filtering is the key to this problem, as you said, Randy, increasing ekf_alt_noise makes copter really succeptible to vibes. 

I try with the old inertial one, It's helps something but not resolve the problem in my case; I resolved with better vibration bed and covering the controller but not completly as photo above.

I am aware that there is a bias factor for baro vs accels,
But it is a static relationship.

What might be interesting to consider is to find a way to make the relationship dynamic instead of static.

The sink only happens while accelerating, so only during this period of acceleration would a change in bias factor be desirable.

The more aggressive the acceleration the more dramatic the sink rate.

If there was tuning parameter that only affected the acceleration period, in regard to altitude, a larger number would cause the aircraft to climb relitive to acceleration rate. Then a user could tune this value to their specific frame.

This would allow an Iris which has excellent aerodynamic properties to continue to perform unchanged while also allowing the poorest frame design to tune out the undesirable altitude loss.

Just a curiosity, and maybe a useful data point - 

Does the PX4 flight stack have this issue?

I played with this parameter in Copter-3.2. I took it up to 4.00, from the default of 1.00, without any apparent improvement.

Has there been further development on this in 3.3 or 3.4?

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service