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...
You need to be a member of diydrones to add comments!
For what it is worth.... Knowing hover throttle level and frame angle + duration + initial acceleration it should be possible to estimate current speed rather accurately. Combinig the speed + experimantal baro degradation data it should be possible to calculate offset for a given frame angle and speed...
I don't believe true air speed is the issue here. It is change in speed, or more specificly change in acceleration relating to the begining of a maneuver and at the end of a maneuver. Basically,a high pressure bubble compensator.
A parameter that would allow a throttle correction factor relitive to the acceleration/ deceleration rate of the aircraft might do it.
If only acceleration was the case, we would se the copter change altitude right away (upon acceleration) but we usially see it after a certain speed is reached. As illustration, compare the pressure on your arm.if you stick it out of a moving car at 20mph and at 80mph.... Big difference. Not quite the same, bur similar thing is happening with our copters. Also, this offset is not linear and will vary greatly with speed and frame angle at which this speed is sustained. Another experimental point: naza will drop a little altitude when abraptly removing pitch angle and letting it drift. But the drop is negligible compard to AC... a mere. 10-20cm ... I do believe they rely a lot on IMU data for level flight instead of baro. The key there is good vibration filter, so when the change is abrupt, vibrations go outside the filter ability and naza drops a bit falling back to baro data.
I agree with Wes, it might be possible to modelise the stuff in the soft with maybe one or two variables ("gain", and maybe "delay" or "Accel" for example to tune the smoothness of the compensation).
Ok it is always risky to add variables as it depends on the shape of each drone, but we can see that the behaviour is more or less always the same. If you drift for 10 meters, you see a loss of altitude a bit delayed, then a few seconds later it climbs again. So it is directly (and only?) linked to ACC values.
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?
Replies
@Chris
calibrated power meter can be used to control altitude alike barometer.
For the set altitude in AltHold mode, energy consumed can be constant
- if you notice energy drop, you can expect drone altitude to drop
- for altitude to rise more energy is consumed
so I would suggest implementation of power meter into Pixhawk
as a sensor of special importance to control uncontrolled fly-aways
and have power meter values saved to log file for post mortem analysis.
That presumes a stationary hover. Any directional motion would show up in your 'power meter' as an increase in altitude...
For what it is worth.... Knowing hover throttle level and frame angle + duration + initial acceleration it should be possible to estimate current speed rather accurately. Combinig the speed + experimantal baro degradation data it should be possible to calculate offset for a given frame angle and speed...
Oh you're right, it is air speed estimation that is relevant and not ground speed. So there are lots of inputs :-( that is hard to develop.
A parameter that would allow a throttle correction factor relitive to the acceleration/ deceleration rate of the aircraft might do it.
If only acceleration was the case, we would se the copter change altitude right away (upon acceleration) but we usially see it after a certain speed is reached. As illustration, compare the pressure on your arm.if you stick it out of a moving car at 20mph and at 80mph.... Big difference. Not quite the same, bur similar thing is happening with our copters. Also, this offset is not linear and will vary greatly with speed and frame angle at which this speed is sustained. Another experimental point: naza will drop a little altitude when abraptly removing pitch angle and letting it drift. But the drop is negligible compard to AC... a mere. 10-20cm ... I do believe they rely a lot on IMU data for level flight instead of baro. The key there is good vibration filter, so when the change is abrupt, vibrations go outside the filter ability and naza drops a bit falling back to baro data.
Hi
I agree with Wes, it might be possible to modelise the stuff in the soft with maybe one or two variables ("gain", and maybe "delay" or "Accel" for example to tune the smoothness of the compensation).
Ok it is always risky to add variables as it depends on the shape of each drone, but we can see that the behaviour is more or less always the same. If you drift for 10 meters, you see a loss of altitude a bit delayed, then a few seconds later it climbs again. So it is directly (and only?) linked to ACC values.
Just a curiosity, and maybe a useful data point -
Does the PX4 flight stack have this issue?
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.
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?
-
3
-
4
-
5
-
6
-
7
of 11 Next