tl;dr This started as what I thought was a possible power issue; then chased it as an ESC Sync issue; back to power issue; and ended with me using a different setup.
Old info…
Before I turn this into an issue on GitHub wanted to make sure I am not missing something. There is a reported issue with ESC Sync that is addressed in 4.0.2RC3 but it seems to deal with IO timing and the Kakute does not have IOMCU. That issue is here:
Setup:
300mm wheelbase
Luminier 2000kv 14pole motors with 6in props on 3S
Kakute F7 w/ AC4.0.1
Tekko32 4in1 w/ ESC Telem and DShot150
HolyBro Mini GPS
Default PIDS w/ changes to enable HNTCH per wiki
Also changed params per Tuning Setup Process Wiki
Results:
Went through about a dozen props, lots of solder and two sets of ESC’s before I updated BLHeli firmware from 32.6 to 32.7 and changed SCHED_LOOP_Rate from 400 to 800.
Prior to those changes motors would randomly cutout if I pushed even a little hard. Logs showed ESC telem voltage going to 0 on one or more ESC just before actual and desired roll/pitch diverged.
After changes to main loop rate and updated BLHeli the thing flew great. No problems with althold or loiter. Really smooth considering it was not tuned. So I went for autotune of pitch and roll.
A few minutes into AutoTune the motors cut out again;it flipped; and this time had enough altitude to recover. I switched back to loiter and landed.
Logs again show ESC telem voltage headed to 0 but this time they recover.
It seems like it has to do with ESC Sync but I am out of ideas. Any help appreciated. Here’s the param and logs from the autotune that had the uncommanded flip:
I am willing to try 4.0.2RC3 if there has been a fixed submitted that is related. I could not tell since the issue above was closed without reference to a commit.
Thanks for the report. I don’t think we can assume that it’s an AP software issue though. There is definitely a timing issue in AP’s I/O firmware since 3.6.10 that could cause sync issues with some ESCs but of course that doesn’t mean that all sync issues are caused by timing issues in AP.
My guess is that it’s a power issue on the vehicle itself. Is it possible to try and reproduce the problem on the ground?
If it were me I would actually not push up the sched loop rate to 800. I would try and keep the AP setup as standard as possible.
I also thought it was a power issue which is why I am on my second set of kakute and tekko hardware. Triple checked all solder joints etc etc. only thing that has made a difference so far is updating blheli and increasing main loop rate.
Cant really do much on ground. I guess I can load up betaflight and go bang it around to see if it happens again. Was really hoping someone could peak at my logs and find something easy. What I see is it starts to lose esc telem and motors glitch. But is that AP or blheli on the tekko not liking something?
I also don’t think it’s an issue w/ ArduPilot… I have a bunch of copters running dshot 600 and 1200, and don’t have this sort of issue. And I wouldn’t expect a sync issue to show up as 0v in the logs (but don’t have any experience w/ it, so am not positive).
That’s what I am trying to determine. I was running dshot 150 at 400 main loop and it would crash in about 30 seconds. bumping to main loop of 800 and updating to latest blheli got me pretty good results.
I have bumped to dshot600 and am keeping the default of 24khz in blheli to see what happens.
But as far as I can tell there is no single point of reference for these types of setups. My hunch is the closer I get it to what is expected from an FPV racer the happier the Tekko will be.
Just a Holybro Mini GPS. And sadly cant measure current draw as the Tekko has four seperate current sensors that only measure motor current. The current pin that comes out of 4in1 appears to do nothing on the Tekko 4in1.
Thanks to @rmackay9@wicked1 and @andyp1per for keeping me honest. I think I have it fixed after flying through two batteries without issue. What I finally noticed after about the fourth flight was it was happening below 11v on flight battery. Did not think it would be a big deal to have X4R and a Mini Compass module on the 5v bus of the Kakute. Apparently it is. I supplied the GPS/Compass module with it’s own 5V supply and have been able to pass two batteries through it without issues.
I will hop on the sub250 thread an supply some of the settings I used re blheli dshot just so we have another data point. Because when the motors don’t glitch it flies really well.
Are you using the full size kakute, or the mini? Someone (I think Andy) mentioned he had power issues w/ the mini. And I sort of do, but it’s manageable after adding a large capacitor (570uf, 6.3v) to the 5v rail. It could barely power the GPS, RC receiver, and my VTX.
Full size but not AIO. I bet a cap would fix it too. Seemed to happen when I would let it settle and add throttle when the battery was getting below 11v. Motors would glitch and that was it unless I was high enough. Happened more often before the bump to main loop to 800 and update of blheli because I had optical flow as well.
Yeah, I recommended to Holybro that they supply a separate 8v rail for camera/vtx like the Omnibus does. I had all sorts of weird issues when I had too much connected. I also found that it wouldn’t go into bootloader mode with the GPS connected.
By the way, if BATT_MONITOR = 9 then the BLHeli ESC telemetry will be used for voltage (and current?) monitoring. I have never tested this but I wanted to point it out in case you haven’t seen this. … which means we probably need to add a note into the wiki to mention this… either into the power module section and/or the BLHeli setup section.
What does it mean that “BLHeli ESC telemetry will be used for voltage (and current?) monitoring”? Mean values? Maximal? Minimal? (chosen from all the ESCs)?
Maybe it would be reported as a BATT2/CURR2 parameters, so that we could compare the measurements with the Power Module sensors?
You can set it up as a 2nd power module and monitor both the ESC telemetry, and the values from traditional sensors.
My ESC is wrong, and the calibration field in MP has no affect.
In my case I am using it as the primary. Not sure if it’s average values or min or max from the four ESC’s reporting. I did notice today that the amp/volt calibration setting in MP has no impact. BLHeli32 does allow you to calibrate amp readings I think. Have not tried it yet.
BTW, even putting the GPS module on it’s own 5V does not fix it completely. Had it glitch on me today, but not as bad. Must be brown out now. So I put a cap on one of the 5V lines. Any idea if it’s all the same 5V bus? Or is there a specific spot that cap needs to go? Besides on the PCB from the factory.
I’m just not sure this is the issue… There are a lot of people using that board, powering all their peripherals. Unless your GPS or something is particularly power hungry. You can look at the 5v rail in the logs, to see if it’s sagging.
I don’t have the full size one, so maybe someone else will be able to let you know.
The nano has one 5v regulator and a diode separating the left side of the board which has the camera and video pads, from the right, which has the uarts for GPS, etc. That way when you plug it in to USB, only the right side of the board gets power, and you aren’t powering the VTX, etc. And in that case, the regulator is on the left side of the board… And that is where I put the capacitor.
Second set of hardware and both had same issues. Even changed rx today. GPS is on it’s own 5v reg now so is not issue. You can’t get a clean boot with this board on USB as the barometer will not initialize without battery power.
I am starting to wonder if it’s a 3S issue as it does appear to be a problem when vbat gets under 11v.