NOTE: 4.6.3 was re-released on 20-Nov-2025 after we noticed that the version was incorrect left at beta instead of stable. The update did not include any functional changes but the githash (visible in the messages tab soon after startup) changed from 3fc7011 to 92b0cd7
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
No big deal of course but by the way, @Rob_Lefebvre was our trad heli maintainer for quite a few years especially in the early days of ArduPilot. You can still find his contributions on GitHub.
Rob,
Brandon is also on the core dev team, heās our expert in making 3D models for real flight (amongst other things).