Critical Events in Log (with Timestamps)

1. PX4IO Errors
 [00:00.2 – 00:01.0] → Multiple PX4IO sync failures:
o “bad sync”, “bootloader not responding”, “error updating PX4IO”
 [00:01.3] → PX4IO start failed → IO board not communicating →
actuator outputs at risk.
⚠️This is already a fatal red flag — if PX4IO isn’t talking, motors can
suddenly cut.

2. Sensor / EKF Warnings

 [00:03.7 – 00:04.5] → Preflight Fail:
o “Accel 0 missing”, “Gyro 0 missing”, “Barometer 0 missing”, “ekf2
missing data”.
 [00:04.8] → IMU data gap detected (gyro/accel message missed).
⚠️EKF can mis-estimate altitude here → land detector might mis-trigger.

3. Landing Phase – False Land Detection

 [~00:35.9] → vehicle_land_detected.maybe_landed = true
 [00:36.1] → vehicle_land_detected.landed = true
o Altitude (vehicle_local_position.z) still ≈ 0.7–0.8 m above ground.
⚠️False land detection → triggers motor throttle cut.

4. Actuator Outputs Collapse

 [00:36.1 – 00:36.2] → actuator_outputs drop sharply → motors cut.
 [00:36.2] → Vehicle tips and crashes (loss of control).

Summary of Timeline
  0–1s → PX4IO fails to start (I/O board issue).
 3–5s → Sensors missing / EKF degraded.
 ~36s → False land detection while still in the air.
 36.1s → Motors cut (actuator outputs = 0) → crash.
Why It Crashed
 Root cause is combination of PX4IO comms failure + false land
detection.
 The PX4IO errors mean the flight controller couldn’t reliably command
motors.
 Then the land detector mis-triggered at 0.7–0.8 m, cutting throttle.
 Since IO wasn’t healthy, you couldn’t override with RC → full drop.

👉 Safe fix path:

1. Fix PX4IO first (reflash firmware, confirm no errors in console).
2. Disable auto-disarm during testing: COM_DISARM_LAND = -1.
3. Slow descent: MPC_LAND_SPEED = 0.5.
4. Allow RC takeover: COM_RC_OVERRIDE = 1.
5. Re-test hover + land.

1) LAND-mode logic & RC override

  RC can’t “break out” of LAND: If RC override isn’t allowed, stick inputs
won’t abort landing.
• Check: COM_RC_OVERRIDE (should be enabled if you expect sticks to
take over).
• Also check if you mapped a kill switch or arm switch accidentally hit on
landing.
 Instant disarm while still in the air (false land detection): vehicle thinks
it touched ground and cuts thrust.
• Watch the log: vehicle_land_detected.landed goes true before
touchdown → adjust land detector tuning (see §4).
2) Altitude/position estimation issues (most common)
 Baro error or EKF height jumps during rapid descent → vehicle thinks it’s
lower than it is, throttles down.
• Check logs: ekf2/3 innovations, vehicle_local_position.z, baro vs
rangefinder vs GPS alt consistency.
 Rangefinder glitches (lidar/tof saturates or sees propwash/reflective
ground) → false “ground” at height.
• Temporarily disable rangefinder for testing or set it to Aiding only;
verify valid range in logs.
 Terrain following misconfig (terrain enabled without a valid map or
wrong offset) → sudden height errors near home.
• Disable terrain following to test; ensure home alt and global alt frame
are sane.
 Vibration/IMU clipping on descent → EKF resets or position loss exactly
when you land.
• Check IMU clipping and vibration metrics; fix isolation, balance props,
lower descent rate.
3) Descent dynamics & controller tuning
 Vortex Ring State (VRS) from straight-down, high-rate descent → loss of
lift and wobble/crash.
• Set/verify MPC_Z_VEL_MAX_DN (and MPC_LAND_SPEED) to
conservative values; avoid long vertical drops.
• Land with a small horizontal motion or let the position controller
handle a gentle approach.
  Ground effect & propwash near ~0–1 m → oscillations, tip-overs, or
bounce + disarm.
• Slightly lower MPC_Z_P/I, confirm MPC_THR_HOVER is correct, ensure
MPC_THR_MIN isn’t too low.
• Add landing gear dampers/feet; reduce final land speed.
 Integrator windup / poor attitude tune shows up most at low throttle.
• Re-run autotune/manual PID tuning; verify ATC/MPC_* attitude gains
aren’t too aggressive.
4) Land detector/landing parameters
 Land detector sensitive → early “landed” detection in the air, then
throttle cut + disarm.
• Tune thresholds (names vary by PX4 version; look for LNDMC_*):
vertical speed, accel norm, and thrust thresholds, plus trigger time.
 Disarm too quickly on touchdown → if it detects land during a bounce,
you lose control.
• Increase COM_DISARM_LAND (delay) and ensure COM_DISARM_TMO
is reasonable.
 Landing speed too high
• Reduce MPC_LAND_SPEED; confirm final descend setpoints in the log
match your expectations.
5) Powertrain & hardware gotchas
 Battery sag at the end → low voltage → thrust collapse exactly on
landing.
• Check cell voltages vs current; try a fresh pack; review battery_status.
 ESC desync / motor issue that appears at low throttle.
• Try slightly higher MPC_THR_MIN; check motor/ESC temps, connector
solder joints, and DShot settings.
 Loose arms/landing gear → contact triggers land detector or flips the
frame.
• Physically inspect for play; tighten everything.
6) Failsafes & mode transitions
 RC loss / GCS loss triggers a failsafe at the same time you command
LAND → sudden mode change or termination.
 • Review commander_state, vehicle_status for any failsafe flags at that
time.
 Geofence breach near landing (height or boundary) → RTL or terminate.
• Check geofence and mission altitude vs home elevation.
7) Mission vs “Land” button behavior
 QGC LAND button sends immediate land at current position; a mission
LAND can include a final approach.
• If the on-screen Land causes issues, try a mission with a dedicated
LAND waypoint and a small approach slope, or use RTL then land.
• Verify you can switch to Position/Altitude mode manually and regain
control (test with COM_RC_OVERRIDE=1).
What to check in a log (ULog) – quickest path to root cause
Open the crash flight log and graph these together around the landing
moment:
 vehicle_land_detected.landed, vehicle_land_detected.maybe_landed
 vehicle_local_position.z, vz, and dist_bottom (if rangefinder)
 actuator_outputs / total thrust vs setpoint
 commander_state.main_state, nav_state, failsafe flags
 ekf2/ekf3 innovations, hgt, states_reset_count, vibration/clipping
 battery_status.voltage, current
 manual_control_setpoint (did your sticks move? were they ignored?)
If landed flips true while altitude is clearly >0.3–1 m, tune the land
detector and/or fix the height sensor. If thrust suddenly falls with no
“landed”, look at power/ESC/motor/limits. If mode changes or failsafes
light up, fix those first.
Safe fixes to try (one at a time)
1. Lower descent rates: set conservative MPC_Z_VEL_MAX_DN and
MPC_LAND_SPEED.
2. Enable stick escape: set COM_RC_OVERRIDE=1; practice switching to
Position mode to abort.
 3. If you use a rangefinder: test without it; if the issue vanishes, revisit its
mounting/filters and validity thresholds.
4. Increase COM_DISARM_LAND delay; avoid immediate disarm.
5. Rebalance props, check motor screws, verify no IMU clipping; re-run
tuning if needed.
6. Try RTL instead of direct LAND and see if the behavior differs.
7. Fresh battery test; watch voltage sag in the log.

After log upload

most likely causes (ranked)
1. PX4IO / I/O (IO coprocessor) communication failure → loss of
motor/RC outputs during landing. This is the single most suspicious
thing in the log and is the most likely cause of a sudden uncontrolled
drop at LAND. (logs.px4.io)
2. Estimator / sensor data problems (EKF2 missing data, missing
baro/gyro/accel warnings) → bad altitude/position estimate during
landing. If the estimator sees bad data it may command unsafe thrust or
the land detector may trigger prematurely. (logs.px4.io)
3. Land detector / auto-disarm mis-triggering (system thinks it’s landed
and cuts motors while still above ground). The log shows land detector
activity and auto-disarm behavior is relevant. (logs.px4.io, docs.px4.io)
4. Less likely here (but always worth checking): battery/ESC/motor failure
or Vortex Ring State / high descent speed — these would show up as
power collapse or very high descent rates in the telemetry.
Key log evidence (what I actually saw)
 The Flight Review shows this run is an HIL simulation using a
CubeOrangePlus, and a number of alarming console messages appear.
(logs.px4.io)
 Repeated PX4IO errors: bad sync, bootloader not responding, error
updating PX4IO, Failed to communicate with IO, PX4IO start failed. PX4IO
is the IO board that handles RC and actuator outputs on Cube-style
hardware — if it fails you can lose motor control. (logs.px4.io)
 Health / preflight warnings: Preflight Fail: Accel Sensor 0 missing,
barometer 0 missing, ekf2 missing data, Gyro Sensor 0 missing, Compass
Sensor 0 missing. These indicate the estimator was degraded or missing
data at times. (logs.px4.io)
 IMU message gaps (EKF: IMU message missed / vehicle_imu gyro/accel
data gap events). Even occasional IMU gaps can make EKF produce bad
height/state estimates at critical moments. (logs.px4.io)
 Flight Review summary shows extreme values (e.g. large max tilt)
consistent with an out-of-control moment during the log. (logs.px4.io)
Together, the PX4IO comms failure + estimator/sensor warnings are highly
suspicious: if the autopilot lost comms with the IO coprocessor (or the IO
failed) the motors could stop responding (or disarm) right as LAND begins;
alternatively, the EKF may have jumped or land detector mis-reported landed
and triggered disarm.
Concrete tests & checks to do (in this order)
1. Confirm PX4IO / IO board status
o In QGC (or in the console) check for PX4IO messages and reflash
px4io firmware if needed. The log shows PX4IO start failed and
bootloader not responding — reflash/check connections first.
Evidence: many bad sync and error updating PX4IO lines.
(logs.px4.io)
o If using a custom harness/Sim/HIL, ensure the IO channel mapping
is correct (HIL can mask real IO behavior).
2. Inspect the Flight Review plots at the landing moment
o Open your flight in logs.px4.io and plot (around the crash time)
these topics:
vehicle_land_detected.landed and
vehicle_land_detected.maybe_landed, vehicle_local_position.z
(altitude), local_position.vz (vertical velocity), actuator_outputs (or
actuator_controls / motor_*), commander_state / nav_state, and
battery_status.voltage.
If landed flips true while altitude is still > ~0.3–1 m or actuator
outputs collapse at the same time, that confirms false land
detection or an I/O/motor cut. (You can find the Plot selection list
inside your Flight Review). (logs.px4.io)
3. Check EKF / sensor health
o In the Flight Review look at ekf2 innovations, states_reset_count,
and any accel/gyro gaps around landing. If EKF reports large
innovations or resets just before the crash, fix sensor wiring,
calibrations, or vibration. The log already shows ekf2 missing data
warnings and IMU gaps. (logs.px4.io)
4. Test landsafe parameters (safe software changes)
 o Temporarily disable auto-disarm so the vehicle will not cut motors
automatically on landing: set COM_DISARM_LAND = -1 while
testing. That will help determine if auto-disarm triggered a cut.
(Docs: Land Detector / COM_DISARM_LAND). (docs.px4.io,
BKUEng)
o Set a conservative landing descent speed: MPC_LAND_SPEED = 0.5
(or 0.6 m/s) to avoid vortex ring state or abrupt descents.
(docs.px4.io)
o Enable RC escape (so you can take over immediately): make sure
COM_RC_OVERRIDE is set appropriately (so sticks interrupt auto
LAND). (docs.px4.io)
5. Ground checks
o Power the vehicle and watch the console for PX4IO errors before
arming. Fix any PX4IO/IO firmware issues first (reflash if required).
The log shows PX4IO communication failures that must be
resolved. (logs.px4.io)
o Verify IMU/gyro/accel calibrations and no IMU clipping/vibration
(balance props, tighten screws).
6. Replay in SITL/HIL (if available)
o Because your log is HIL, reproduce the mission in SITL/HIL while
watching for the exact moment when PX4IO communication or
EKF warnings happen.
What to look for in the log to prove the root cause (exact signals)
 If PX4IO failed: look at actuator_outputs (do they go to zero?) at the
moment of LAND; and check console messages for PX4IO errors at the
same timestamp. If motor outputs go to zero with no commanded
landing thrust reduction, that's IO/ESC/mixer issue. (logs.px4.io)
 If land detector mis-triggered: vehicle_land_detected.landed == true
while vehicle_local_position.z > 0.3–1 m. That’s a smoking gun for
premature disarm. (logs.px4.io, docs.px4.io)
 If EKF/IMU: ekf2.innovations spikes or states_reset_count increments
near the landing time; or vehicle_imu data gaps coincide with the event.
The log already shows IMU gaps. (logs.px4.io)
  If power/ESC: battery_status.voltage collapse or esc telemetry (if
present) fails at that moment.
Quick parameter fixes to try (safe, incremental)
 COM_DISARM_LAND = -1 (disable auto disarm while testing).
(docs.px4.io)
 MPC_LAND_SPEED = 0.5 (reduce descent speed). (docs.px4.io)
 COM_RC_OVERRIDE = 1 (allow stick override to abort landing).
(docs.px4.io)
 If rangefinder used: temporarily disable or re-mount it (rangefinder
glitches often cause false land) and re-check dist_bottom traces.
Final recommended next steps (what I can do for you right now)
1. Fix the PX4IO connection / reflash px4io firmware and re-run a short
hover test — do not attempt another autonomous LAND until PX4IO
errors are gone. PX4IO errors are present in your log and are the top
suspect. (logs.px4.io)
2. After that, re-run the mission, record a new log, and check whether
vehicle_land_detected toggles incorrectly or whether actuator outputs
collapse.
3. If you want, I can mark the exact timestamp(s) in your current log where
the failures occur (I can extract the time of the PX4IO errors and the time
of any landed flag flip). Tell me if you want those timestamps and I’ll pull
them out of the log and interpret them precisely.
If you want, I’ll do the timestamped deep dive now (I can extract the exact
seconds where PX4IO errors appear, where landed flips, and show the actuator
output trace around that time) — say “yes, show timestamps” and I’ll extract
them from your log and point exactly at the lines/plots to inspect.
(Short recap: the PX4IO communication errors and missing sensor/EKF
warnings in your log are the biggest red flags and likely the reason the vehicle
became uncontrollable when LAND was commanded.) (logs.px4.io)