Hi, not sure if it is related to latest beta but I just had a violent crash on a mission today. Despite having tried to analyze the log file, I can’t figure out what hapened. My tricopter took off normally and reached first 2 waypoints but then began to loose altitude very quickly going to third waypoint and finally crashed. If someone skilled in log analysis can take a look at it, I would be very pleased.
This is the mission initial wpts. Tricopter crashed between 5 and 7
I had a quick look at the logs but they end suddenly just after the vehicle reaches about 5m altitude. Initially I thought this was an in-flight software failure (and maybe it is) but there is also no indiciation that the vehicle reached the 2nd waypoint (e.g. no message in the log saying it reached the 2nd waypoint).
If it is a software failure then there should be another small log produced afterwards with a WDG message and also a message would have appeared on the GCS HUD if telemetry was being used.
My guess is that the logging failed or the log file anonymisation procedure cut off the end of the log. Maybe you could check if you see the same things as I have posted above after graing CTUN.DAlt vs Alt?
.
I also looked at the tlog but nothing special appeared in the GCS HUD.
It is very strange that the log does not mention anything about waypoint 1 nor waypoint 2 as the copter crashed aproximately at waypoint 2 position. I also noted that the tricopter reach 12m/s speed while it should only be at 5m/s at this portion of mission. 12m/s is the speed that it should reach after second waypoint.
After few hours repearing my tricopter (2 arms broken…), I tried again to run that mission and this occured again. By chance, this time I had my fingers on the auto switch and was able to switch back to poshold in extremis. Again, nothing appear in this log about that. I then flew back to home doing some maneuvers to test my tricopter attitude and launched the mission again. This time the mission goes well. Here is the log of that, maybe you will find something interesting in it: https://www.amazon.fr/clouddrive/share/8gIXqoFP1B2EMPQ6wtxxRUiHofNWOtsiAz68Gz1Og8I
I would just add that this never appears before beta6. This does not mean that it is linked to beta but it cloud. Also, since beta6, I switched to onshot125 instead of dshot300 due to beta issue (see Tricopter pre-arm tilt motor angle). Probably nothing to see but I prefer to say it.
I’m quite worried about this crash actually because it seems repeatable (by you) and we don’t know why it is happening.
I can imagine that it could be a software problem to do with initialisation of some variables. This would explain why it crashes and stops producing logs the first time you run the mission but it works the 2nd time.
I have taken the mission and run it in SITL and I could not reproduce the problem but that doesn’t mean we don’t have a problem.
Do you have a Tlog of the incident? Maybe we can find some information in there.
By the way, I think -beta7 resolved the issue with Tricopters + DShot issue.
Hi, here is the tlog of the crash: 2021-08-14 11-46-12-anon.tlog (441.5 KB)
If you need, I can also send the tlog of the second flight where the crash was avoided.
Tridge, Leonard and I had a look at your log again in the fresh light of a new day and we are pretty confident that it is a power failure. The reason is that the RSSI information from the Sik radio stops at the same time as the autopilot. If it was a software failure and the power remained stable we would expect the radio to keep on sending it’s independent RSSI information… but it doesn’t.
It is a bit hard to see but below is a screen shot of the tlog messages (converted into a text file) taken from the moment the autopilot stops sending mavlink messages. The “remrssi” values stay frozen at “132” until they eventually timeout and switch to “0”. These messages are sent to the GCS from the ground radio but the remrssi values are from the telemetry radio on the drone.
A random guess as to the problem is that the tail servo is sharing power with the main CPU and so when it moves it can cause a brownout. That’s a total guess but it seems likely that there is a power issue of some sort.
Thanks again for the report and I hope this helps in some way.
