that isn’t really proven, we would need @Leonardthall to confirm it is really the same thing being reproduced in SITL, there is a good chance it isn’t
Hi @Snowtrek,
Txs for the report!
If you have a log file we can probably look for the same PID spikes to see if it’s the same issue but in any case, the best way to keep up with this issue is to following this thread and/or check the, "Copter crash while using AutoTune with fast rates " in the consolidated 4.7 issue list.
Claude couldn’t reproduce anything. Waist of time.
1 Like
Thanks for your responses. I’m horrible at log management but plan to improve. I will leave the subject copter exactly as it was during the issue, only upgrade the capacitance, see what happens, and report back in a week or two after the Rubycon capacitors arrive. If the issue persists, I’ll send the log file. I agree with what some have said about Rosser’s tuning video, but I do trust his capacitor testing. Cheap capacitors have leads with too high resistance for high power copter application.
The subject copter is using BLheli32 version “9”…the last version with the ‘spurious spin up’ problem that has been documented to hurt fingers by spinning up when disarmed. Maybe look for commonality WRT to this happening most often with high power copters, or this (last?) BLheli version. My copters hover around 16 to 22 percent throttle with expo 0.4 to 0.55, lower than recommended because I understand and have experienced that there is an issue with having a copter set up with hover throttle below 15%.
Rosser has a video of his 200mph copter design experiencing voltage spiking during hover due to inadequate capacitance. It jumps around but does not crash. I suppose that this is an example of PID spiking (too?).
Knowing this copter could help someone seeking commonality.
AOS UL10, 2.1kg, Brother Hobby 3110 730kv, 6s2p Molicel P45 Li-ion, Master Airscrew MR 10x8 bi-blades.
Maybe excessive voltage sagging / late voltage sag compensation could be disrupting some algorithm. Going further out on a limb, maybe somthing else needs to run at the fast rate.
Yes a log file is essential. Please also look at my comment about BRD_IDLE_STATS above
Roger, BRD_ENABLE_STATS.
BTW @tridge suggested to me yesterday that the PID spikes could be log corruption instead of a divide-by-zero issue. This is just an idea and to prove this we might need to create a special build that produces and internal error and ask @Snowtrek to re-test assuming it is repeatable.
There are no zero dt’s that I can see, but if you look at the dt’s actually being used you can see how much the board is struggling:
Your target dt is 250us but for a significant number of loops it is double that - which is why your min is down at 100us (which is clamped as the lowest value IIRC) - you are just not going to get good control in this scenario because your gyro samples are coming at a fixed rate.
Also quite high variability at the angle level which is not a good sign:
2 Likes
After some recollecting, before I had the tree incident the quad was experiencing some PID spiking-like behavior and I was aborting AT before crashing while holding low altitude. In, fact there were one or two gentle crashes prior. This goes to repeatability. I believe that I was trying to tune it out by reducing harmonics on a single ESC notch, but that wasn’t working. I think that I felt that the CPU was struggling. I always aim for a CPU load 600hz or less, but I could have been exceeding that. All I have is this antectotal evidence at this point. This was day 1 for this quad. I have the same AOS UL10 (10” prop) frame on 8s2p, using older firmware, same 2k/4k 400hz loops, with no issues.
My rigs are generally tough and fitted with premium but well protected sensors. I’d be willing to test the rig as it sits, or otherwise.
In the future, I can envision myself asking how I can help test betas. I have a diversified engineering background, but not code based. Like Andy, I am ‘aways autotuning’. Below is my fleet for current and possible future reference. They are all on high current li-ion and Matek FC.
- AOS UL5 (5” prop), 4s1p 18650, H743 mini, 450g, 23min
- AOS Mantis (7” prop), 6s1p 18650m, H743 slim, 1100g, 16min
- AOS UL10 (10” prop), 6s20 21700, H743 slim, 2100g, 25min
- AOS UL10, 8s2p 21700, H743 slim, 35min
- AOS UL10, 24v constant (tethered repeater), H743 slim, lightweight, unlimited
- AOS 7” Mantis, 8s1p 21700, heavy
All have the battery packs silicone-glued to the top plate to effectively dampen vibrations. This, in addition to the low-vibration frame designs and greased carbon plate fitted connections produce I what I suppose could be called an ‘edge case’. I accept that I am an edge case.
If you can get a flying log that will tell us a lot. You can also build firmware with stats which will show per-thread CPU utilization
Ok, but if the custom built FM involves more than using the custom firmware builder website, along with setting the option under BRD_IDLE_STATS in MP, I’ll need some guidance. I don’t see any obvious setting to include enable idle stats at the custom build website. Here is what I’m thinking:
- develop a basline flight log tonight, before making any changes, with my expectation that there is 80% chance the issue will repeat. Send a log either way. Only change: select ENABLE_IDLE_STATS in case the loaded FM has that capability already
- replace any damaged props, upload new FM build with stats, repeat
I will need something like Dropbox but have privacy concerns that I will need to work out. A recommendations is welcome.
There should be a log file posted above if I did it correctly. The flight was short. There was some slow rocking in Loiter that was becoming progressively worse. I switched to Loiter a second time, initiated AT Roll within a few seconds, and after the first or second twitch, it rocked wildly and climbed before I disarmed and crashed onto the inground pool cover wet spot. I was wrong, it is a 2k PID loop and 2k gyro setting. In stabilize mode, it was flying well.
Ok for @RobinIJ you can see that in this log the CPU is not struggling. dt is stable and max and avg are approx the same:
2 Likes
This looks like a control oscillation to me. You can see that R is always about RDes and if you give it enough of a kick it becomes uncontrolled:
You are trying to autotune on default PIDs - generally that’s not a good idea. You at least want it to be flying approximately via a manual tune first or else you risk this outcome. I would suggest that you try halving your gains and then fly applying some manual roll and pitch twitch inputs - you need to make sure that it does not lead to oscillation. If its too soft but flyable - that’s ok, autotune will take care of that. If its still uncontrolled try reducing by 50% again.
1 Like
I would not have thought of that given the PID levels that I usually end up with, thank you. The behavior was distinctly different than the tree incident, unfortunately.
I was filtering a lot too on these first flights.