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.
@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)
@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.
I’m working on a very similar case. In my setup, EK3_SRC1_POSXY and EK3_SRC1_POSZ are already set to GPS, and I’m using firmware version 4.5.7.
I am using Here3 GPS
However, I’m still experiencing some issues with poor tracking. I’ve noticed that when velocity tracking degrades, there’s a significant difference between PSCE.TPE and PSCE.PE as you see in the screenshots. The same applies to the vertical component.
This doesn’t look like an estimation problem, instead it looks like a tuning problem. Your aircraft will be limited by it’s basic manuverability properties and your controller tune.
It looks like you are getting something that looks like an occilation in velocity but given your target and measured velocity look like they are tracking reasonably well this may be just your position P term that is a little too high.
You may be able to get better performance if you did a full tune starting with the vertical acceleration controller. This is rarly required for most multirotor aircraft so support and guidance on how to best do this is hard to find.
