2 mid-air crashes using v1.8.2

🧪 Flight Testing & Log Analysis
1

Hi everyone,

I have encountered 2 mid-air crashes on last Thursday & Sunday. In both cases, the log file (at least according to my understanding) ends abruptly.

I couldn’t find any hardfault logs on the sdcard, but I also doubt both cases were battery disconnect or something like that (I can’t rule that out completely, but I’m pretty sure it isn’t the case)

I would appreciate any help on figuring out what happened, or at least what should I do in order to provide more information if those crashes happen again.

  1. Flight log #1 (Thursday): https://review.px4.io/plot_app?log=cacc99f6-5d04-4742-a5f6-f18c79e7c2d0
  2. Flight log #2 (Sunday): https://review.px4.io/plot_app?log=0861c9ed-2f5a-476f-97b8-7f97653b2dc2

Some information on the configuration:

  1. I am running v1.8.2 on Pixhawk4 with a slight modification in mb102xx (just changed the BUS_ID)
  2. I was running using EKF2_HGT_MODE=2, and I increased the LOCAL_POSITION_NED mavlink rate to 200
  3. I doubt those changes are the root cause, but just mentioning them.

I wasn’t able to find anything suspicious in the logs, appreciate your help.

Koby

2

We’re currently investigating an I2C issue in the NuttX OS. Do you have particularly long I2C wires?

3

I am using 2 I2C devices as far as I understand:

  1. ublox n8m gps + compass - the compass is connected to the GPS port using a ~20cm I2C cable.
  2. mb12xx sonar - connected to the I2C-A port using a ~10cm cable

Is there a way to validate / rule out this assumption? Any particular logs I can add?

Thanks for the help!
Koby

4

Do any of the I2C cables go close to ESCs, switching regulators or power cables? Even with the NuttX issue fixed you could still have data corruption issues.

5

Not really, they are not bound together…

Any reference to the nuttx I2C issue you were mentioning? Any indications I can look for to be sure this is what I’m hitting?

6