PX4 EKF convergence delay causing instability on init

[andrewjong]

AirStack Version
0.18.0-alpha.4 (issue not observed in alpha.3)

---

Describe the bug
On startup, the system exhibits unstable and inconsistent orientation behavior, particularly visible in RViz when running Isaac Sim. The drone’s orientation (yaw) may abruptly change or “flip” during initialization.

Screencast.from.2026-04-16.15-28-19.mp4

This appears to affect simulation environments (viewing in RViz with Isaac Sim and AirSim). The issue may be related to EKF initialization producing erroneous state estimates at startup. In some cases, the drone incorrectly estimates its position (e.g., reporting z ≈ 9m instead of z = 0), which leads to incorrect takeoff behavior.

As a result:

• Takeoff may fail entirely or take significantly longer.
• The vehicle may attempt to take off relative to an incorrect odometry frame (e.g., from z ≈ 9.4m to 10m).
• Orientation may flip or drift unexpectedly during initialization.

There are indications this may be a startup race condition introduced or exposed in alpha.4, possibly due to faster initialization timing (e.g., single GUI setup).

---

To Reproduce
Steps to reproduce the behavior:

1. Launch the simulation (RViz / Isaac Sim / AirSim SITL with AirStack alpha.4)
2. Initialize PX4 and begin the startup sequence
3. Observe RViz state and/or drone orientation during initialization
4. Attempt takeoff
5. See:
   • Orientation flipping or instability on init
   • Incorrect altitude estimate (e.g., ~9m instead of 0m)
   • Delayed or failed takeoff

---

Expected behavior

• The drone should maintain a stable and consistent orientation during initialization.
• Yaw/orientation should not change unexpectedly during startup or takeoff.
• EKF should converge to correct initial state (e.g., z = 0).
• Takeoff should execute reliably without requiring artificial delays.

---

Host Compute (please complete the following information):

• OS: Ubuntu 24
• GPU: RTX 5090, RTX 4090
• CPU: Not specified

---

Additional context

• Adding a delay before starting SITL or PX4 appears to mitigate the issue, suggesting a timing/race condition between simulator data availability and EKF initialization.
• The delay allows sensor readings (e.g., from AirSim) to stabilize before EKF convergence begins.
• This workaround is not ideal; a more robust solution would involve:
  • Waiting for EKF convergence before enabling takeoff, or
  • Adding a readiness/precondition check in the robot control pipeline.
• It is unclear whether EKF convergence delay is expected PX4 behavior (as in real-world systems) or a simulation-specific artifact.
• The issue was not observed in alpha.3, suggesting a regression or timing-related change in alpha.4.