Mainline PX4 or voxl-px4 bug causing inconsistent Vz and z estimates by EKF2?
-
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.
