I’ve often wondered why we get somewhat poor altitude performance (jumpy) when weighting (non-RTK) GPS to 100% of the EKF source. Seems we should just trust it more and filter it better…
I’m familiar with much larger/higher performance UAS platforms than ArduPilot typically operates that use filtered GPS as the sole altitude source to great effect.
I don’t know what the default weighting is - but even just more than the current split would probably work better.
I have ran some aircraft that only use GPS for altitude (RTK) and those work great but that is expected.
The ones with which I’m familiar probably use very fast update rates with extremely robust hardware, but none of that is RTK.
I wonder if the reason we don’t weight GPS heavily for altitude is because of its drift over time. With baro comp we are only comparing it to baro alt for a short period of time so maybe its fine to use as the more accurate altitude then?
I guess what I am trying to figure out is if there is a way to do this in real-time during flights instead of it being a tuning process that needs to occur.
Similar to how we have a parameter for hover throttle that is constantly being updated - would be nice if the baro comp parameter was constantly updated throughout flight. Just looking at quick 15 second snippet every now and then comparing GPS alt to barometer alt to calculate the value.
According to this slide - the only two data points you need are difference in height error and airspeed. Where height error is just the difference between GPS alt and baro alt.
Great! I will definitely try this script and share the results
I was looking for some alternatives to estimate the momentum drag coeff. as the original method explained was a bit trial & error based approach. This script surely reduces some errors.
My best copter for developing this is still on the bench for repairs, and I’ve been busy with other commitments lately, but I do want to revisit this and refine it as discussed above. Happy to take inputs on improvement!
I was trying this script the other day but I was getting an error “Transmitter Sticks must be neutral”. So to rule out the obvious:
Since I’m running with a non-centering throttle the RC3_TRIM is 988.
Is RC3_TRIM the culprit or is there another reason why I’d get the error?
That’s likely the reason. The script looks for throttle near the trim position.
Hello, I loaded the script to FC and set one of the stick and assigned scripting1, also I enable wvane_enable param. Once I take off and hold the stick for less than 1sec its changing the orientation and in messages its showing AHRS wind 110 at 3m/s but wherein weathervane is not happening. tried for two full days but result is negative.
what should be done to complete this test?
Follow the instructions step by step.
Followed these steps when I hold the assigned switch for atleast one second and release it, shows AHRS wind 123 at 5m/s but whereas its not aligning with the wind. if I hold aux switch and release it message shows orientation changed or else switch is not neutral. Weathervane is not happening.
What firmware version?
The WVANE parameters have nothing to do with this script and should probably remain disabled.
I am using 4.4.4 stable version, earlier I tried with WVNAVE parameters disabled but weathervaning is not happening or drone is not aligning with the wind. Even the following the above procedure.
Hello, I have executed the script on FW 4.4.4 and everything went well and got the result for moment drag coefficient as 0.23. I am wondering how to check this value is perfect for my drone. How does its going to work in future and it pros and cons?
