So again shortly after takeoff when flying in POSHOLD my Navio 2 drone crashed. Exactly the same sequence as before where I would arm and take off in POSHOLD and while I am flying forward the drone will toilet bowel and and crash. This time however I have the logs so that is attached.
The sequence of events were as follows.
I started flying yesterday in this spot and did the mag calibration.
Today I did 2 auto tune flights before the 3d and last flight.
I armed the Copter in POSHOLD and took off landed again and took off again. After a couple of seconds of forward flight the drone started fishbowling and crashed. Just before the crash I got a “communication lost” message on Qgroundcontrol. The crashed occurred immediately after that .
In the video recording you will see the Videofeed die midflight. The crashed happened directly after this.
When reaching the drone I noticed that there was a slow blinking blue light.
I did notice that of the 3 flights only one telemetry file was logged on my Tablet.
I looked at the logs and there is a GPS glitch shortly before the crash but what I can not determine is if the glitch occurred because of the wild Toiletbowling or if the crash occurred because of it
Thanks Mark I am also sorry. I really think that this is now an indication to go to Pixhawk. I have really had a enough of Emlid. I have had 2 Navio2 boards on 2 different Raspberry pi 3’s and the crashes are always the same. Luckily this time it was only the 1 arm that broke.
I was only doing yaw autotune which was not successfull 2x
The system has redundant power supply. One power module and one UBEC that poweres the servo rail. I test for continuity after soldering everything so if there was a short I think I would have picked something up pre-flight.
I have used different power options with the same results. I have powered the system using only the power module and only via the servo rail and the crashes always seem to happen in POSHOLD mode
If linux was running the video feed would still be running as far as I can understand. To me it would make sense that Linux stopped running as the video feed is a process in SystemD. One thing is that the motors were still turning as the aircraft went down. Not sure how to check for coredumps. Can you help with this?
If Linux is crashing this is most likely RPi issue, rather than Navio 2.
Here is some info on the core dumps, although other forum members need to tell exact process for Ardupilot core dumps - I didn’t do it myself (there was no need).
There is indeed an issue with an ArduPilot cycle delay that is very likely causing the crash. As you can see from the attached screenshot the loop duration time was increased drastically before it happened.
Such a response from the system is observed when external equipment is misbehaving or misconfigured. For instance, it can be a driver issue. Or, as @anton.pryamostanov mentioned, there might be something wrong with a build design.
While we don’t see the whole build and can’t test the same setup you use, we are quite limited with helping you in finding the source of a glitch causing ArduPilot failure.
All we can do is to suggest accomplishing the following test:
Reflash the SD card with the latest image
Start with a standard setup: connect ESCs, motors, power module + battery, and RC to Navio2 (without other devices such as Ubec, Wi-Fi module, etc.)
Extensively test this setup flying not very high (on 1-1,5 m above the ground). Make sure the issue doesn’t appear again
Connect the components from your additional hardware set one by one. Thoroughly test the setup on the ground after connecting each of the components
Record the logs all the time so we can catch cycle delay if it emerges again
This test will help to understand which of your components causes the issue. Please save all logs and hardware setup photos of each stage of testing and share it with us so we can move forward.
