Mavros/local_position/odom Z-Axis drift
-
Hello, we are running into an issue where the qvio-server doesn't match with the odometry msgs published on /mavros/local_position/odom on the Starling platform.
I have run plotted the qvio and mavros/local_position odometries over time and there is an extensive divergence with the platform completely still
-
Hello, we are running into an issue where the qvio-server doesn't match with the odometry msgs published on /mavros/local_position/odom on the Starling platform.
I have run plotted the qvio and mavros/local_position odometries over time and there is an extensive divergence with the platform completely still
@Kashish-Garg Just bumping to get a hand with this. i have tried disabling Baro sensors and playing with enabling/disabling other sensors. Its clear the mavros/vision/pose is accurate, but on the z-axis in local_position is drifting/showing significant error. Any help is greatly appreciated!
-
@Kashish-Garg Just bumping to get a hand with this. i have tried disabling Baro sensors and playing with enabling/disabling other sensors. Its clear the mavros/vision/pose is accurate, but on the z-axis in local_position is drifting/showing significant error. Any help is greatly appreciated!
@Kashish-Garg Does it fly properly without your code in manual and position modes? What does local_position report in QGC when you fly?
Are you waiting a long time before taking off? What if you fly first to let EKF2 converge?
We don't have enough information to help you, you'll need to start with first principles to debug the system
-
@Kashish-Garg Does it fly properly without your code in manual and position modes? What does local_position report in QGC when you fly?
Are you waiting a long time before taking off? What if you fly first to let EKF2 converge?
We don't have enough information to help you, you'll need to start with first principles to debug the system
Hi @Moderator and @Kashish-Garg, we have noticed a similar behavior involving a discrepancy between the qvio server and /mavros/local_position/pose on the z-axis. We have attempted to resolve this by disabling and re-enabling the barometer sensor, but the issue persists. The inconsistency does not always occur and does not appear to be related to aggressive flight behaviors.
-
Is this indoor our outdoor flight? If you are running indoors, then the barometer should not be the main item used for ekf2_hgt_mode in PX4 and vision should be the detector for height source.
Can you attach an altimeter like a benewake lidar or something that is very bare metal and have that sensor become the range finder in the px4 instance?
Zach
-
Hi @Moderator and @Kashish-Garg, we have noticed a similar behavior involving a discrepancy between the qvio server and /mavros/local_position/pose on the z-axis. We have attempted to resolve this by disabling and re-enabling the barometer sensor, but the issue persists. The inconsistency does not always occur and does not appear to be related to aggressive flight behaviors.
@Riccardo-Franceschini We were not able to resolve this issue. However because our control stack is sending TRPY commands to mavros, this didn't come into play at all. The concern for us originated when the drone was taking off significantly higher than commanded. It turned out the propeller coefficients we received from ModalAI were insufficient.
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