Copter-4.6.3 has been released as the stable/official version for multicopters and traditional helicopters and will be available for download from the ground stations within a few hours. Alternatively the .apj file can be directly downloaded from firmware.ardupilot.org and then installed manually using your GCS’s “custom firmware upload” feature.
The changes vs 4.6.2 are in the ReleaseNotes and copied below
Board specific changes
Accton Godwit G-A1 support
ARK FPV, ARK Pi6X, and ARKV6X Extended Range support
Blitz Wing H743 and H743 Pro I2C pullup fixes
Blitz Wing H743 and H743 Pro now use SPA06 barometer
BOTWINGF405 support
Brahma F4 support
CUAV OpenDroneID support
CUAV-7-Nano now uses IIM-42653 accel/gyro
CUAV-X25-EVO support
DAKEFPV H743 and H743 Pro support
GEPRC TAKER H743 BT support
Orqa FC 3030 H7 QuadCore support
RadiolinkF405 support
S-Vehicle E2-Plus support
SequreH743 now uses DPS310 and DPS368 baro
SIYI N7 now uses ICM45686 accel/gyro
SkystarsF405v2 support
SPEDIX H743 analog VTX enabled
TBS LUCID H7 fix VSW control
TBS Lucid H7 Wing AIO support
ZeroOne X6 bi-directional DShot support
Driver bug fixes and enhancements
DJI goggles support for iNAV multi-page fonts
Gremsy mounts cope with NaN in device information
OSD can now be controlled over DroneCAN serial passthrough
Copter specific fixes
Correct setting of deadzone on RC tuning channel
Plane specific fixes and enhancements
Added option to disable IMU check with ICE running
Fix landing flare when using rangefinder
Fix landing slope when when a rangefinder exists, but is not in use
For gliders with airspeed sensors mounted behind the prop, disable airspeed calibration when throttle is not idle
Improve TECS behavior when using MIN_GROUNDSPEED
Make RNGFND_LANDING a bitmask
Quadplane terrain avoidance applet
Remove roll-rate limit in fixed-wing recovery
Bug Fixes and minor enhancements
Correct starting of CAN multicast server
Cygwin SITL stability fixes
Data race in parameter creation fixed
ECC check no longer causes firmware wipe if error is recoverable or if only param pages impacted
FFT uses primary gyro instead of first available
GPS blending fix when one GPS loses lock
Harmonic notch filter fixes for scripted motor mixers
I’m working on setting up/tuning a sporty 5" quadcopter, and ran across an issue… ? I’m trying to tighten up the altitude controller, and changed PSC_VELZ_FF from 0 to 0.1, and attempted an Alt_Hold flight. Immediately after trying to take off, it flew up suddenly into my safety net.
MP was reporting
Internal errors 0x 10000I:66 flow_of_ctrl
I rebooted, set PSC_VELZ_FF back to 0, and behavior returned to expected. Tried setting PSC_VELZ_FF back to 0.1, and attached ballast to hold the quad down. Upon attempted takeoff, it immediately goes high throttle again.
Re the Septentrio issue, @Jai.GAY’s given the link to the PR. I also talked with PeterB about it and he said that his Septentrio simply didn’t work without this fix. Many users are successfully using Septentrio GPSs with AP so it’s not clear what was different about this particular GPS but I guess, in short, if you find that your GPS doesn’t work at all with AP, then perhaps 4.6.3 will resolve the issue.
I’ve tuned them up, but it was still strangely loose. I knows there’s an altitude error and just wasn’t trying very hard to close it. But it does over time. But looking at the log, I think I see the issue, it’s not updating the Hover Throttle. I read that it won’t update if it’s below .125? Looks like it’s at 0.08ish, so it’s just staying at 0.20. So I think what’s happening is when I engage Alt_Hold, it starts to rise until it adjusts the I-term. And it has to do it from scratch every time.
I tried setting the PSC_VELZ_FF to 0.1 and 1 and I wasn’t able to immediately reproduce the issue. As discussed, maybe PM me the log and I’ll see if I can figure out where the internal error is coming from
It would also be good to make sure it’s a control issue and not an estimation issue. So for example it could be baro interference on takeoff or a laggy rangefinder.
Yep, could be baro interference. But I can see that it actually knows it has an error, and isn’t correcting it. After looking at the logs, I realized it’s a Hover Throttle issue. I’ll fix that and test again.
But I think this is a separate issue from that error code being thrown?
If you get a chance upload a photo of your drone. I not updating my FW right now but have flown a lot of custom crafts. For now I would just start over reset to defaults to remove any odd settings and fly it. Then use the Tuning guide.
It’s a pretty standard 5" FPV racing type drone. I don’t really want to hijack this release thread with tuning advice.
I’m just interested in the error that was thrown:
Internal errors 0x 10000I:66 flow_of_ctrl
It’s been a few years since I used Ardupilot, and never seen this sort of error message before. Seems like a new diagnostic capability was added (which is awesome!), and it’s signaling a bug. That’s what Google AI is telling me.
Or does this code get thrown from simply getting tuning params wrong?
Thanks for the logs so hopefully this will help me reproduce the issue. An internal error like this is not normal nor expected. It means that the code got to a place that we think it shouldn’t have been able to. Normally it’s innocuous but it might not be.
Ok, I’ll try to have a think about my particular setup, and why I might have triggered it, but it didn’t in your testing.
The error isn’t what I thought it might be, something like a “stack overflow” or memory error, something like that. This is “functional” if you know what I mean. Might only be possible to get in this state with a ridiculously powerful quadcopter like I’m working with.
I’m not really concerned about it personally, because I’m not attempting to use that parameter anymore anyway. I’m more concerned with finding a lurking bug.
Looking at that line, I’m now not sure if the root cause of the full-throttle launch was due to this Internal Error, or if the internal error was also simply caused by that parameter being set.
Like I said, I did an A-B-A comparison, and it’s that parameter that does it, on my setup.
I might try a smaller number like 0.01, just to see if the problem occurs with anything non-zero.
Resetting your craft to defaults is not tuning advice is it. full-throttle launch can be a simple as a radio recalibration especially if your coming from Betalight.. I did have a loss of my radio and flyaway on a older version of FW setting up a new board, AERO SELFIE H743 Flight Controller. I think it was to do with custom cables i made up that can be a challenge.
BTW can anyone describe this error for me and what a incorrect setting mean? “Correct setting of deadzone on RC tuning channel”
It seems to be referring to setting the deadzone on RC6 in just one place (instead of multiple places in the code) so the behaviour should be consistent.
I think:
when RC6 is NOT used for tuning the deadzone takes effect (like any other RC channel)
when RC6 is set for tuning the deadzone is NOT used so you can make fine adjustments to some parameter
The fix applies to any channel set for tuning so the behaviour should be the same as for RC6