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.
Reading along? Create a free ModalAI Forum account to join in.
With an account you can reply, ask your own question, get an email when a ModalAI engineer answers, and mark the reply that solved it. Your place in each thread is saved between visits.
Questions about VOXL, Flight Core, ESCs and ModalAI drones are answered here by the engineers who build them.
Register Login