I have some experience with Ardupilot but now need to move to PX-4. I haven’t yet flown PX-4, so I’m rather new here. I am seeing what appears to me like very, very strange behavior around arming. I see, perhaps, two different points.
- “Preflight Fail: ekf2 missing data” seems to never go away
- The presentation of which flight modes may arm is incorrect
I don’t know if QGC is getting incorrect data or QGC is handling the data incorrectly. Stabilize mode presents as being “Ready”. Manual mode presents as “Not Ready”. QGC permits or prohibits attempts to arm the flight controller consistent with the presented “readiness”. Using the rudder arming gesture on the transmitter makes it possible to attempt to arm when QGC prohibits it. With Stabilize mode presenting is “Ready”, attempts to arm using either QGC or the RC transmitter are refused by PX-4. The refusal is presumably consistent with “ekf2 missing data”. Switching to Manual mode, the system presents as “Not Ready”. Yet, using the transmitter to arm results in the system arming.
I have been unable to find any leads on either the ekf2 problem nor the strange presentation of readiness to arm. I can guess that the ekf2 problem might be a parameter/configuration problem, but the message give not a hint of where to look. The presentation of readiness seems more like a bug, possibly specific to the Holybro Kakute H743-Wing flight controller I am using, but the policies involved would seem not flight controller specific.
I also have a question about the use and behavior of automated launch/takeoff. I am attempting to configure for a catapult or hand-launch. As soon as I arm the system it displays a message that it is “Ready for throw launch”, yet it is in Manual mode. I would expect to need to be in Takeoff mode (or a mission perhaps?) for it to be ready to be thrown. What is the correct usage of flight modes for hand launch and how should this message be interpreted?
@DonLakeFlyer , it is probably not correct to call you in this way, but because this post isn’t in the QGC section, I’m not sure if you’ll see it and QGC may have a roll in this set of issues. …I wasn’t sure if or how to split this post up.
Data log and screen recording linked below.
Screen Recording of QGC 5.1.4
None of this has anything to do with QGC. The firmware side is in control of arming. Also the “Ready” indicator is based on mavlink system health and event status which also comes from the firmware side. The only additional thing in the “Ready” added by QGC is whether all vehicle components are configure. It’s not exactly the same as how firmware side determines ability to arm. So it’s possible to be slightly out of sync. But it’s just a visuall UI indicator. It doesn’t prevent anything from working.
If QGC were decoding the mavlink data incorrectly, I believe it would present as I am seeing.
It is interesting that the Manual → Stabilized transition generally shows “Ready” (when it is not). The Takeoff → Stabilized transition shows “Not Ready”. The transition matters. Additionally, initial connection in Manual mode can show “Ready”, but transition from Stabilized → Manual always shows “Not Ready”, though it is Ready.
None of this makes any sense as this seems like policy that isn’t dependent on the flight controller type and everyone should be seeing the problem. That doesn’t seem to be the case.
The EKF2 missing data problem should not cause the incoherent arming readiness behavior, but I suspect it is triggering a bug. If the EKF2 missing data problem is resolved, I suspect that the arm readiness problem will no longer be visible, but would still exist.
“If QGC were decoding the mavlink data incorrectly, I believe it would present as I am seeing.”
Only with respect to a UI indicator which is visual candy only. As far as QGC decoding mavlink data for this incorrectly, that would be a first. Hence, I am highly doubtful.
Your best bet is PX4 Discord channel so you get firmware folks to see it.
@j3kestrel are you using an airspeed sensor?
This is what I see from the log:
Yes. Matek ASPD-4525 and SENS_EN_MS4525DO is enabled.
I had missed that mention in the logs and don’t know the implications of it. What does “selector module down” mean?
The first thing I would separate here is the persistent ekf2 missing data condition from the QGC Ready/Not Ready indication.
The Ready state in QGC may be useful context, but I would treat the firmware preflight checks as the source of truth for the actual arming decision.
For the EKF2 side, I would start from the log and check whether the estimator is actually receiving the sensor streams it expects, rather than assuming this is only an arming-policy issue. In particular I would look at:
estimator_status / estimator_status_flagsvehicle_imu_status- GPS / barometer / magnetometer availability
- estimator selector status
- any sensor timeout or data-invalid events immediately before the preflight failure
If ekf2 missing data persists continuously, there should normally be a specific input or estimator instance that never becomes valid. That may also explain why the different mode transitions make the UI state look inconsistent.
I would diagnose the EKF2 input validity first, then re-check the arming/readiness behaviour once the estimator is healthy.
If useful, I can also take a closer look at the Flight Review log and try to identify which EKF2 input is missing.
The EKF2 problem and the Ready/Not Ready behavior seem independent except that without the EKF2 problem the Ready/Not Ready problem may not show itself. The presented color and text do not match that of the autopilot.
Nothing in the suggested data groups is obviously a problem. However, I’m not sure what to look for without spending days in the source code to understand the meaning of each of the fields. I do see that the accel_error_count (and gyro_error_count) increment to 32 during the ~15 minute log, though nothing under any of the estimator fields seems to be upset about the IMU. …though I could easily not know what I’m reading.
At a superficial level (looking at the live telemetry in QGC), all the sensors appear to be working. Airspeed indicates, attitude indicator looks correct, heading looks correct, etc.
Any assistance interpreting the logs would be helpful.
Thanks that helps narrow it down.
I would not treat the accel_error_count / gyro_error_count increments as the root cause yet. Those counters are worth correlating with timestamps, but the fact that attitude/heading remain plausible and the estimator status does not obviously degrade suggests they may be secondary rather than the event that is holding EKF2 unhealthy.
The item I would investigate first is the selector module down indication that Julian pointed out.
In a multi-EKF setup, the selector is responsible for choosing and monitoring estimator instances. So I would want to establish:
- whether an EKF2 instance is actually failing to start or publish,
- whether the selector has a valid primary instance,
- which input makes the preflight check report
ekf2 missing data,
- and whether that condition exists continuously or only during a specific initialization window.
I would also correlate the IMU error-count increments against the exact timestamps of the ekf2 missing data / selector messages. If the counters increase independently, I would avoid conflating the two issues.
The fact that live QGC telemetry looks normal does not necessarily prove that every estimator-required input is valid the vehicle can still publish attitude and sensor telemetry while one estimator input or estimator instance is considered invalid by the preflight logic.
I’m going through the log with that sequence in mind. The next useful result would be to identify the first failing estimator/input condition rather than just the downstream arming message.
Did you find anything? Are there any additional logs I should collect?
Thanks!
I presently suspect this is a problem with the Holybro Kakute H743 port of PX4 and not a general PX4 problem. I am presently using an Cube Orange+ and don’t see these problems. I also briefly bench tested a Holybro Pixhawk 6x and it also did not display these problems. Some of it may be as simple as EKF3 tuning? Some of it seems far weirder. I have a batch of the Kakute’s and I like them. They are affordable, compact and worked well with Ardupilot, so I know they can perform. When I can find the time I will try diagnosing deeper starting with the assumption that the problem is Kakute specific.
That comparison is useful. The fact that you don’t reproduce the behaviour on the Cube Orange+ or during the Pixhawk 6X bench test makes a Kakute-specific path worth investigating, but I would still avoid calling it a board-port issue until we separate the board from the configuration.
If you return to the Kakute, I would try to make the next capture a controlled comparison rather than collect more general logs.
Ideally:
Kakute H743 — failing case
Cube Orange+ or Pixhawk 6X — non-failing reference
with the same PX4 release, as close to the same estimator configuration as practical, and the same power-up / pre-arm sequence.
Then I would compare the initialization timeline:
sensor drivers start → sensor publications become valid → EKF instances start → selector obtains a primary instance → preflight estimator checks become healthy → vehicle becomes armable
The useful question would be: what is the first event that differs between the Kakute and the known-good board?
I would capture the full boot-to-arm ULog and console/boot output from the Kakute if possible. Parameter exports from both configurations would also help distinguish a board/driver difference from an estimator configuration difference.
I would also keep the IMU error counters as evidence, but not promote them to root cause unless their first increase precedes and correlates with the estimator/selector failure.
If you collect a matched Kakute + known-good pair, I’d be happy to compare the two timelines.
