Mainline PX4 or voxl-px4 bug causing inconsistent Vz and z estimates by EKF2?
-
Amended the EVV and EVP noise and gate size values..
Doesnt seem to have made any diff; EKF2 local position Vz and z gradient are still in different directions during full left and right roll, whereas VIO reported Vz and z are seemingly correct instead. I have uploaded this log on the github post as well.
Extrinsics are correct because the VIO outputs are correct as mentioned.
I should also add that this is not based on the Starling but a smaller customized drone.
Have clocked at least 50hrs of indoor flight from SDK 0.9 thru 1.0 but only recently did i realize this behavior as i adjusted the max velocities up to 3m/s from 1m/s.
At 1m/s this issue is barely noticeable. -
@hmlow there are multiple sets of extrinsics
if you run
voxl-inspect-pose vvhub_body_wrt_localon voxl2 it will apply the extrinsics and output pose that should be inline w/PX4's local position. Please verify those outputs match what px4 is reporting.PX4 has its own rotations as well
-
@Moderator Yes the extrinsics are correct and the VIO pose matches PX4 EKF2 estimates well except during the segments max velocity rolling maneuvers at 3m/s where VIO and EKF2 Vz and z deviates (but VIO's estimates is correct and matches with visual observation), which is what this post was about in the first place.
Comparison of x y z between VIO and EKF2 local position estimates:
Comparison of Vx between VIO and EKF2 estimates:
Comparison of Vy between VIO and EKF2 estimates:
Comparison of Vz between VIO and EKF2 estimates:
Im attaching the voxl-logger VIO logs and PX4 ulg file here. The 2 files are already time synced so you can plot them directly.
Thanks
-
While the logs and graphs above are based on my own customized aircraft, I just tried the same maneuver on the Starling (with shipped params and configured for indoor VIO) and i can confirm that the same observation is repeatable.
Im curious if you guys would see the same uncommanded climb/sink if you would roll your own Starling aircraft left (or right) for 10 - 20m (3m/s, with CP turned off) and then in the opposite direction. The logs would also show that the EKF2 estimates having the same issues as i have described here and on the github post..
-
Hi did anyone manage to verify this?
-
Any devs?
I was able to produce this issue on two separate Starlings and a customized 250g drone
-
@hmlow I was seeing the same thing on my starling. Have you tried completely disconnecting the GPS/baro unit on top and turning off the parameter HAS_MAG?
-
@wilkinsaf That solved the issue for you?
-
@hmlow yes. Ideally you would adjust the EKF2 parameters to increase the gps/mag threshold so they wouldn't affect your local position. But, quick and dirty is to unplug the gps unit. See if that solves your issue. If it does, then worry about EKF2 parameters
-
@wilkinsaf actually no, I'm using neither GPS nor mag (disabled both) as my flights are entirely indoors
-
So, basically the main issue is that in the logs the qvio and ekf2 are reporting different position estimates? But, everything is flying correctly?
-
@wilkinsaf Flying correctly for the most part yes.
Except during specific maneuvers as i have described in my first post (details in the github link) and the third post.
Its challenging to summarize the issue in a few lines.. -
@hmlow I was flying over the weekend, and saw some inconsistencies as well tbh. The quality of the QVIO was reporting not as high as it was in version 0.9.5 SDK release. I will ask the devs and see what they say.
First, I need to compile some logs from voxl-qvio.
