Copter-4.0.7 stable has been released and is available for download from the ground stations or from the build server. The changes vs 4.0.6 are in the ReleaseNotes and copied below.
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
fixed a race condition in SmartRTL which could cause a LAND mode to be triggered
fixed build on Durandal board
multiple fixes for mRo boards: ControlZeroClassic, ControlZeroF7, ControlZeroH7, ControlZeroOEMH7, PixracerPro
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.
As always, thanks very much to our beta testers for putting their vehicles at risk to help us ensure this is a safe release.
A big thanks to all involved developers!
I just completed a couple of test flights with 4.0.7 on my Tarot 650. Lidarlite, Px4flow, IR-Lock, ADSB, a TX2 connected via APsync and MavROS - all systems work well. Copter flies rock stable and smooth.
Hello after the update to stable 4.0.7 the motor test is not working properly. when I test the motors one by one motor A cannot be tested. Testing all motors works ok. In particular testing motor A rotates motor C, testing motor B is ok, testing motor C ok, testing motor D is ok. testing the motors in sequence gives the same problem. Have you noticed a similar behavior or have an indication for the problem.
It will run in sequence (A,B,C,Dā¦) if you press the āTest All In Sequenceā button. Starting from The Front Right Motor (A). It wonāt run in Motor Output number order.
I build a new Copter based on Matek H743-SLIM.
In Loiter mode after a while (about 10-20 min) the copter tilts forward and flies away.
After deactivating IMU0/ICM20602 all is fine.
I think this is the same issue with ICM20602 AccelY offset which was fixed with 4.1.0 some days ago ā¦ and is btw working fine with my 4.1.0-dev rover toys.
FC/AHRS_ORIENTATION is mounted 90 deg CW, so it tilts to the front and not to the left.
Will there be a backport of the PR to 4.0.7? And perhaps also for the plane release?
@amilcarlucas@tridge IMU2 in Cube Orange is the ICM20602. I am afraid to fly my drones now. Unless you are planning for a 4.0.8 release, this must be backported. Any suggestion?