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.
Happy flying!
Any chance you can push the tags for plane 4.0.7 and 4.0.8 to github please?
done, sorry for the delay
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.
Happy flying!
Hi is this going to fill the Dir with is STRG13.bak each time it boots some 16k some are 32k in size
the ones from the new beta (or master) are 32k. It will keep at most 100 of them. So max 3.2MByte.
Thanks Tridge! Is there any consideration to have the reboot not be required, even as an option? Or perhaps have an option that can be set which will empower ArduPilot to self-reboot? We’ve been chatting about this since the partner meeting and we’re worried that the user experience of this message prompting for a reboot on power-up - while better than the user experience where the autopilot has no idea what’s going on or what it is we expect it to do - is not quite as refined as could be. Curious your thoughts, and thanks again!
This is the reply I gave to Eric on the facebook post. I’ll copy it here for a wider audience:
We may remove the reboot requirement in a future revision. For now we want users to know it has happened and to get the STRG_BAK logs sent in. I think once we’ve had a good number of those to confirm that the param restore is really solid we likely will remove the reboot (which means removing the internal error). The problem with this issue has always been that we can’t reproduce it on demand, so we’re reliant on the occasional report. We’ve only had 4 users that have sent us STRG_BAK logs. For each of those 4 cases the logs show the change in this release would have restored the parameters correctly, but we’d like more of those logs.
Thanks Tridge, I hadn’t seen that yet but went and searched it out. Appreciate the reply!
The other changes are as given in the beta1 announcement:
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.
Happy flying!
Hi Tridge, thanks for the update! I was previously using 4.0.7 and had saved a copy of my full parameter list. Once I updated the firmware to 4.0.9 and loaded the parameter list file, it gave me a notification that 169 parameters were missing. Some of these are related to battery failsafe and a lot of them starting with Q, I suppose they are all related to quad plane. I have attached a screenshot of the missing params message. Are these parameters in a different location or with different names in 4.0.9? Your help is much appreciated!
Hi, when will 4.1 stable be released? I’m looking to use two Here3 GPSs on CAN 1 & 2. Thanks
they haven’t changed at all.
That sort of message happens when the associated enable parameter wasn’t set. For example, if Q_ENABLE was 0 then all the Q parameters would be hidden. When you load a parameter file the first time the hidden parameters are “missing”. If you refresh your parameters after having set Q_ENABLE to 1 then you will find they have appeared. The same thing happens with the battery monitor enable parameters.
Why do that? The parameters will be persistent when the new Rev is flashed. I find it to be bad practice to load another parameter file. They are good for archiving/reference.
Any updates on this?
It is likely to be a few weeks yet before the first beta.
Thanks Dave, I agree. In this case I was loading the parameters from an old rev from a different hardware to a new hardware which did not previously have any parameters set.
@tridge, I thought we solved the EKF issue, but I’m not sure if this is the same issue or a new one. Our new build sat on the ground with RTK Fixed while the altitude once armed ran away to 1km in about 30 seconds. https://github.com/ArduPilot/ardupilot/issues/16791
