I have looked at the ESC part of the logs, and the RPMs don’t indicate any form of shutdown; the plane would literally glide this slope, but it uses reverse thrust to manage the energy. Here is why I don’t believe the stall theory; the pitch demanded and achieved are consistently together throughout, and the pitch recovers once reverse thrust stops during the late attempted go-around:
Also note the reverse thrust all of the way to the crash site; if it was below slope and descending rapidly, it should NOT be applying reverse thrust and pitch down command. Period.
I’ll attach successful logs soon of the flight just hours earlier with full auto landing successes; the only change was the addition of a rangefinder, and that was disabled for this last landing attempt.
@tridge, @MagicRuB, or @WickedShell, would you guys be able to take a moment to review the automatic landing sequence posted above on 4.0.7beta2 that resulted in a rapid descent and crash? I’m available all day on discord.
I’ve finally found the cause of this, sorry for the delay. It is not a new bug.
I’ve done a fix here:
it fixes two places where rangefinder data can influence landing even when RNGFND_LANDING=0
In your flight the bad rangefinder data was triggering incorrect glide slope calculation even though you had it disabled.
Cheers, Tridge
I’ve just released plane stable 4.0.7. This is a minor release with some important bug fixes.
enable telem3 on Durandal
fixed SBUS output when scanning for FPort on IOMCU
keep a backup of storage of last 100 boots
fixed a race condition in handling UART DMA transmit
Fixed F32Lightening board IMU fast sampling issue
fixed issue with EKF2 and EKF3 with use of high accuracy GPS modules. This is important for anyone flying with a RTK GPS
Fixed KakuteF7 DShot glitch issue
Fixes issue with checking for valid RC input in ICE disable channel
fixed an interrupt flood issue with any sensor that uses interrupt timing measurement, such as RPM sensors.
Modified RM3100 driver to probe all 4 possible I2C addresses
Fixed UDP RC input on Linux boards to accept up to 16 RC inputs on UDP
fixed an issue with use of rangefinder in landing with RNGFND_LANDING=0 (thanks Nate!)
The most critical fixes in the above list are:
ISR Flood Issue
The ISR flood issue happens when a misbehaving external sensor (such as an RPM sensor for a petrol motor) starts providing pulses faster than the flight controller can process them. If this happens then the CPU can be overloaded in the interrupt handling for the sensor and stop flying the vehicle. The level of interrupt rate needed to cause this issue is around 500k interrupts per second, so to be safe we have
added a limit of 100k interrupts per second. If a single interrupt source produces more than 10k interrupts in a single 0.1 second period then we disable that interrupt source, print a warning to the user and raise an internal error.
SBUS Issue
When the dedicated SBUS output port is used on boards with a IOMCU (such as Hex Cube or Holybro Duandal) then SBUS would be interrupted on loss of RC input. The problem was that the same UART was used for both SBUS output and RC input. When RC input is lost the RC protocol system starts searching for a receiver, which involves changing
baudrate on that UART. That baudrate change affected SBUS output. This means if your aircraft depends on SBUS output to fly and you get an RC failsafe you risk losing RC outputs. The fix is to not change baudrates on that port when SBUS output is enabled (which means protocols like FPort can’t be used when IOMCU SBUS output is used).
Hi,
Pixhawk1-1M has HAL_MINIMIZE_FEATURES defined which in turn disables quite a lot of features, I extracted a list grepping !HAL_MINIMIZE_FEATURES, it should give you an idea, for the importance you should look up in the wiki each one of them and decide for yourself.
I am having an issue with ArduPlane 4.0 on Qgroundcontrol GCS. I am using a PixHawk Cube Orange and previously flashed it with MissionPlanner. I switched because QGC was more linux friendly, etc. Are there any common problems with this transition? I am trying to diagnose what is not working at the moment, but each time I try to connect my Cube I get an error in a different place than previously. Will update
I’ve just released plane 4.0.8 stable. This is a minor release with a few small fixes.
fixed a bug where an unhealthy airspeed sensor could be fused in EKF2/EKF3
fixed FPort RSSI scaling
fixed timestamp on RAW_IMU data to be 64 bit
fixed an issue with BLHeli pass-thru on some ESCs
Please note that it will take a few hours before this release is available on our build server as it is still building the Copter-4.0.5 release that was made earlier today.
I’ve just release plane 4.0.9beta1. This is a minor release with just bug fixes:
added automatic backup/restore of parameters in case of FRAM corruption for F7/H7 boards with 32k FRAM parameter storage
fixed a bug in EKF2/EKF3 that could cause memory corruption if external naviagtion sources (such as vision based position and velocity data) is supplied before the EKF has initialised
fixed a problem with low accuracy data from UAVCAN GPS modules when GPS blending is enabled
fixed an arming check failure with u-blox M9 based GPS modules
The main reason for this release is the parameter backup/restore. This has been an ongoing issue for quite some time. The symptom is an unexpected full parameter reset on boards using FRAM (also known as RAMTRON) for storage, particularly those using F7 or H7 based MCUs. The issue has most commonly been seen on the Hex CubeOrange board, but has been seen on boards from other vendors as well.
The issue has been frustratingly difficult to reproduce. We did narrow down one cause last year which was a floating CS pin in the bootloader triggering corruption before ArduPilot starts. An updated bootloader reduced the occurrance of the issue a lot and we thought it was solved. Since then the problem has still happened a few times on boards that have had a bootloader update.
This release avoids the issue by keeping a complete second copy of the parameters in the 2nd half of 32k FRAM devices. On boot we check the integrity of the primary parameter storage area via a simple signature check and if it has been corrupted then we restore from the backup area. We also raise an internal error named" params_restored". You will then need to reboot to clear the error, but your parameters will have been automatically recovered, avoiding the need to reload parameters and re-calibrate.
If you get this internal error then it would be appreciated if you could send us the contents of your APM/STRG_BAK directory on the microSD card so we can analyse the corruption that happened and ensure that the fix covers all real cases.
