Yesterday, I conducted some hardware flight tests, during which I commanded the drone with X, Y, and Z velocities via /mavros/setpoint_raw/local in the earth frame.
Upon reviewing the results for all the tests, I observed that in the north direction, the PSCN.TVN, PSCN.DVN, and PSCN.VN values align almost perfectly. Similar is the case for PSCE. However, in the Z direction, although PSCD.VD follows PSCD.TVD, there is a noticeable discrepancy between PSCD.DVD and PSCD.TVD.
I have confirmed that vibration compensation was not enabled, as there were no “Vibration compensation ON” warnings on the GCS.
Could you kindly help me understand what might be causing these inconsistencies between PSCD.TVD and PSCD.DVD?
For your reference, I am attaching images of the log and the log itself.
log file: 00000068.BIN - Google Drive
Thank you very much for your time and assistance.
Update to ArduCopter 4.5.3-beta1
Why are you using 3.6.x ?
sorry my bad
It’s actually 4.3.7…
Thanks for correcting.
Can you upgrade to 4.5.3-beta1 and re-test?
Could you please help with some insights on what changes in the beta version could be beneficial?
Take a look at the change log between 4.3.7 and 4.5.3 and you will find all the information you need.
The bug (if any) might have already been fixed in 4.4.x or 4.5.x
There are no more 4.3.x releases planned, so the fix (if any) will only be available at 4.5.x or 4.6.x anyways.
1 Like
@amilcarlucas , could the issue be related to Throttle Accel PID tuning?
I looked at CTUN’s BAlt (baroalt), DAlt (desired alt) and Alt (inertial nav alt estimate)
It seems Balt was slightly offsetted with respect to the other two. What do you think?
Yes the problem can be tuning
And most of the times the problem is exactly that: lack of tuning
@amilcarlucas none of your comments were relevant to this problem or it’s solution.
@radiant_bee Even though you are commanding just a vertical velocity the autopilot is integrating that vertical velocity to calculate a vertical position target. When the target velocity deviates from the desired velocity, coming from your guided command, it is to compensate for some position error. In your case you are seeing an 0.6 m/s deviation caused by an 0.6 m height error.
I suspect a lot of this height variation is due to using barometer as your primary height source. For many years now I have been using GPS as the primary height source and find it is more reliable.
EK3_SRC1_POSZ 3
I find barometer is more susceptible to significant height changes due to changes in speed or attitude and therefore results in relatively fast and regular variation in height of 2 to 5 m (30m in extreme cases). Barometer also drifts as the pressure changes if you are flying while a front approaches or just after a storm passes but this isn’t when most people are flying so it probably isn’t very noticeable for most people.
GPS height can occasionally move up or down relatively quickly but it is something I see very rarely. When it does happen it tends to be very noticeable especially given how good it is normally. This is also something that can be fixed by adding an RTK reference.
So I guess there are two points here:
- You expect to see some variation between desired and target velocity to correct for disturbances.
- Moving to a GPS height reference should help reduce height estimation errors that can cause false disturbances.
Hi @Leonardthall ,
Thank you so much!!
I will go another flight test and test switching to GPS as height source and then put up an update here
