FC: MatekH743-bdshot
Frame: Chimera V2 7.5" quadcopter, Frame Type: QUAD X BF Reversed
Motors: iFlight XING-E Pro 2806.5 (1800KV) using 4s batteries
ESCs: Mamba F55 4-in-1 ESC (55A), DShot600 with telemetry
ArduCopter 4.7.0-beta3
What happened
During an autotune flight I first noticed odd movements on pitch during roll tuning. The drone was able to recover those and continue. Then during pitch tuning the drone rolled left drastically and crashed full speed into the tree next to it.
I have tried to analyse the logs myself but would appreciate some help and advice.
Details
I set up this drone a while ago. The filters are configured and it was tuned with autotune then (Notably on a 4.7-dev build - possibly not the best idea). I upgraded to 4.7.0-beta3 now and wanted to use the fast rate feature. Iāve set this up and did a test flight which looked fine. Then I went on to autotuning. I did have FSTRATE set to āEnabled dynamicā and not āfixed when armedā but I did not see a loop rate changed message during the flight.
What I found in the logs
The initial pitch movements during roll tuning can be seen between 16:53:46.000 and 16:53:54.000.
The movements where not commanded by the FC or stick input.
Motor 3 (back-left, BF X reversed) seems to spin on lower RPM than the other motors. This is observable in the autotune log but hereās a screenshot of the RPMs from a later flight. Additionally the current readings from the esc seem quite odd to me as well. So I suspect there may be something wrong with the esc. Either faulty data or real data and a faulty esc or motor.
I did not find any errors with the AHRS. All data seems to be correct and agree.
Later flights
I replaced the broken props and tried again the next day. I reduced the aggressiveness and fixed the faster loop rate when armed. I did see movements on the wrong axis again but it was able to correct those and I got a tune.
Questions
Can anyone help me explain what caused this movement on the pitch axis during the roll movement and later vice versa?
Could the RPM deficit on M3 cause cross-axis coupling during the large autotune roll step and could that be the cause?
Does the data point to a broken ESC or motor, and should I replace it?
Logs
I have uploaded three logs. The main one is the AutotuneCrashLog. Additionally, thereās a hover flight right before that autotune and I have added a flight with the working tune from the next day as well. I presume looking at motor rpm not just for the autotune log may be useful.
No I donāt think so. Itās just a misconfiguration of the notch filter parameters. Heās got other problems too so when I see the RPM parameters ātellā I usually just stop there.
My initial setup followed the AMC guide. After that I picked up bits from other tutorials to refine things further. So itās possible I misconfigured something along the way. That said, the drone has been flying well overall and I donāt think configuration alone explains what Iām seeing. So Iād like to rule out hardware before redoing the whole setup.
Could anyone take a look at the logs and give a second opinion on the ESC data or suggest tests I could run to narrow this down?
Right before things went to hell, PIDs on roll and pitch, in P and D, spiked to insanely high values.
I guess this should never happen, this is remarkably similar to division by near-zero, and should probably be investigated further by people like @andyp1per. It might be fastrate-related.
UPD: I have seen some of these in the same log earlier, which did not lead to the crash immediately, so I have no idea how serious or normal this is. I have never seen anything like this in my logs, including those with fast rates though.
The vehicle pitches back (ATT.Pitch becomes negative) and rolls right (ATT.Roll becomes positive) which is towards motor 1 (this is a Quad X BetaFlight style)
Motor 1 (back right) and #3 (back left) go high while motors #2 (front right) and #4 (front left) go low but this doesnāt stop the vehicle rolling towards the back motors
This is the classic sign of a motor or ESC failure although I canāt say that I have a huge amount of confidence in this diagnosis because the incident is very short and it appears there is a twitch in the opposite direction a moment later.
As a follow-up at the end of the log when it crashes, it is an uncommanded roll left and pitch forward towards motor 4 (forward left). In the RCOU motor outputs we see motor 4 go high and the opposite motor 1 go low. This again indicates an ESC or motor failure.
So I think itās definitely motor/ESC related but itās probably not as simple as failed hardware. Maybe a signalling issue or ESC configuration? .. or maybe the ESCs just canāt handle the stress that autotune puts on them?
From a 4.7 issue tracking point of view it would be good to know if these issues are also present in 4.6 and whether they only happen when fast rates are enabled.
Although you have set SCHED_LOOP_RATE to 200, I suspect you are going to struggle with gyros at 4KHz and attitude loop at 4Khz. Only on a very few builds have I been able to make this work. I suggest you set FSTRATE_DIV to 2 and BRD_ENABLE_STATS to 1. This should give you a warning if your CPU is overloaded and significantly reduce your CPU load.
Hmmn, no that is definitely strange and would not be caused by CPU overload - more likely a bug that CPU overload makes more likely to occur. For instance I can imagine a situation where dt gets really small because the rate thread is unable to keep up and then the maths in the rate controller starts going weird.
Thank you all for looking into this problem and in particular @rmackay9 for the detailed log analysis.
Iāll check if I can reproduce the problem without fast rates on 4.7 and on 4.6 in general. Are there any parameter compatibility issues I should be aware of when switching between these versions?
Iāve also noticed that I was pushing the loop rates a bit much. Iāll reduce them as suggested and test this as well.
Once I have results on the current hardware Iāll swap the ESC as well, just to rule it out and see if anything changes.
I just signed up for an account to say that I had this happen about 2 weeks ago with an AOS 10ā āsmall high-powered copterā using FSRATE. It is grounded for now, after it flew sideways into a tree (thankfully it didnāt keep going) during the beginning of the pitch AT phase. I have been a frequent reader but plan to contribute going forward. Can someone describe to me how I can confirm that the āAT fix is inā before I update firmware and re-try autotune on this copter? I donāt want to downgrade because Iām also in need of Andy Piperās baro / rangefinder adjustmentsā¦same question, how do I go about knowing when those fixes are incorporated into the ālatestā dev builds, surely not when they become ācommitsā, correct? Any advice would be much appreciated, so that I can keep on top of the latest changes.
Matek Slim H743 running standard main loop, 4k gyro, 2k PID loop. I have many other copters with this FC/loop rate setup without issue, but on older firmwares. Iām sure that I saw some spikes in the logs prior to the final flight. NLon 150 ish. CPU always below 600/1000.
My theory had been that AT was causing voltage spikes, so I ordered some premium capacitors. However, given that Tridge + Claude can reproduce in SITL, it is probably not my capacitance, if my line of thinking is correct.
