Unable to hold Position in POSITION flight mode

Flight Testing & Log Analysis
1

I’m using VIO data through ROS and the Pixhawk Cube enters POSITION flight mode, but does not hold position. Can anyone tell me why this might be from the following two flight logs?

log_o ; log_1

log_files_for_download

2

Log 0 Analysis by Px4LogAssistant - Px4LogAssistant

image
image1000×600 79.7 KB

Root Cause Analysis and Findings

  • Position Control Not Consistently Enabled: During the POSITION mode period, flag_control_position_enabled was disabled for a majority of the time (113 instances vs. 37 enabled). This suggests that even though the system was in POSITION mode (nav_state = 2), the position controller was not actively maintaining the vehicle’s position for significant portions of the flight.
  • Incomplete VIO Fusion: While external vision position data (cs_ev_pos) was fused into the estimator, velocity data (cs_ev_vel) was not. Velocity feedback is critical for position hold, as it helps dampen movement and correct drift. Without it, the controller cannot effectively stabilize the position.
  • Significant Positional Drift: The vehicle drifted substantially (X: 10.08 m, Y: 4.96 m, Z: 5.87 m) during the POSITION mode period, confirming the failure to hold position despite valid position estimates (xy_valid and z_valid).

Recommended Fix (Applicable to Both Logs)

  • Ensure Position Control Activation: Verify and adjust flight controller parameters or ROS integration to ensure flag_control_position_enabled remains active during POSITION mode, especially under offboard control. Check parameters like COM_OBS_MODE for potential misconfigurations.
  • Enable VIO Velocity Fusion: Configure the estimator to fuse both position and velocity data from VIO. Review parameters like EKF2_EV_CTRL to enable velocity fusion, and ensure ROS messages correctly publish velocity data to the Pixhawk.
  • Validate ROS Data: Confirm that VIO data sent via ROS is properly formatted and timestamped to avoid rejection by the estimator. Use rosbag or similar tools to inspect the data stream.
3

Thank you for your response.

Where can I find this flag_control_position_enabled? Parameter COM_OBS_MODE does not exist as far as I can see, I have checked QGroundControl and cannot find it under the parameters section. I am using PX4 firmware version 1.15.2. What other flight controller parameters are there, I have gone through them multiple times.

Are you sure velocity is definitely needed? I have done this with velocity as well and no difference.

I will have a look at using rosbag and see what I can find, I will post what I get here.

4
5

would you recommend I should be sending my VIO data to /mavros/odometry/in or to /mavros/vision_pose/pose_cov and /mavros/vision_speed/speed_twist_cov?

6

Here is the bag file, what am I to look for in here?
bag file

7

Hi Luke
flag_control_position_enabled is a runtime status flag within the vehicle_control_mode uORB topic.
When this flag is false, the autopilot will not attempt to hold its X-Y position, even if you’ve commanded POSITION mode. Our goal is to understand why it’s false and get it to turn true.
Why the flag is false in your logs?
VIO quality = 0
The quality field in the MAVLink ODOMETRY message is zero through the entire flight. PX4 treats that as “vision not trustworthy” and discards the sample before it ever reaches the controller.
Here’s the link of the run that i just did on log0:

Investigate your VIO system directly. Why is it outputting quality 0? Check its console output, logs, or any specific diagnostic tools it provides (e.g., ZED SDK, Realsense Viewer, etc.). This might indicate poor tracking, an uninitialized state, insufficient environmental features, an internal error, or simply that the quality metric isn’t being properly generated by your VIO ROS node.

8

Makes sense that that is why it is entering POSITIOn flight mode, but not using the data. I’m using the ZED 2i so it is the the ZED SDK.

The tracking and quality of the data from the ZED standpoint is great, I have worked with it a lot for tracking purposes and it’s steady when moving in each direction, the changes are consistent and only jumpy when very close to a target, but I mean within 15-20cm, I have flown this drone in open space and so data is not jumpy and it still does not hold.

Possibly there could be a quality metric that has to be fed to MAVROS to ensure it that the data is trustworthy and the quality is okay. I will investigate this part further. Anything else to add would be greatly appreciated.

9

does the parameter MAV_ODOM_LP have anything to do with it? This must be set to 1 according to here but it is removed in PX4 version 1.14? and I am using v1.15

10

Is there a way to hardcode in that the vio quality = 1?