Mainline PX4 or voxl-px4 bug causing inconsistent Vz and z estimates by EKF2?
-
Hey there, if you are flying solely with VIO (no GPS), suggest loading our indoor estimator params to add to the current setup on PX4. Outdoor vio+gps is here. These set the vio sensitivity that is in line with the suggestions mention on your PX4 forum's thread. Also we're assuming that
extrinsics.confvalues have not changed and are same as the factory settings.Secondly, 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. If those values are correct, then we're looking at a PX4 tuning/config issue (we can still help).One thing that looks weird on your PX4 flight log is Roll and Yaw rates are not keeping up w/respective setpoints (noisy). [Hence, thirdly, suggest an] IMU calibration on the PX4 side.
Lastly in
/etc/modalai/voxl-vision-hub.confthere's a parameter calleden_reset_vio_if_initialized_inverted. It is set totrueas it's to account if vio was accidentally initialized upside down (while carrying the drone for example). You can set it tofalseand if there's a mismatch on VIO-PX4, you'll see it immediately. -
Hey there, if you are flying solely with VIO (no GPS), suggest loading our indoor estimator params to add to the current setup on PX4. Outdoor vio+gps is here. These set the vio sensitivity that is in line with the suggestions mention on your PX4 forum's thread. Also we're assuming that
extrinsics.confvalues have not changed and are same as the factory settings.Secondly, 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. If those values are correct, then we're looking at a PX4 tuning/config issue (we can still help).One thing that looks weird on your PX4 flight log is Roll and Yaw rates are not keeping up w/respective setpoints (noisy). [Hence, thirdly, suggest an] IMU calibration on the PX4 side.
Lastly in
/etc/modalai/voxl-vision-hub.confthere's a parameter calleden_reset_vio_if_initialized_inverted. It is set totrueas it's to account if vio was accidentally initialized upside down (while carrying the drone for example). You can set it tofalseand if there's a mismatch on VIO-PX4, you'll see it immediately.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. -
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
-
@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
-
Hey there, if you are flying solely with VIO (no GPS), suggest loading our indoor estimator params to add to the current setup on PX4. Outdoor vio+gps is here. These set the vio sensitivity that is in line with the suggestions mention on your PX4 forum's thread. Also we're assuming that
extrinsics.confvalues have not changed and are same as the factory settings.Secondly, 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. If those values are correct, then we're looking at a PX4 tuning/config issue (we can still help).One thing that looks weird on your PX4 flight log is Roll and Yaw rates are not keeping up w/respective setpoints (noisy). [Hence, thirdly, suggest an] IMU calibration on the PX4 side.
Lastly in
/etc/modalai/voxl-vision-hub.confthere's a parameter calleden_reset_vio_if_initialized_inverted. It is set totrueas it's to account if vio was accidentally initialized upside down (while carrying the drone for example). You can set it tofalseand if there's a mismatch on VIO-PX4, you'll see it immediately.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..
-
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..
-
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
-
@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.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login