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.
2 Likes
Thanks Tridge, I hadn’t seen that yet but went and searched it out. Appreciate the reply!
I’ve just release plane 4.0.9 stable. This is a minor release with primarily bug fixes. There has only been one change since 4.0.9beta1, which is to add support for the latest mRoControlZero boards.
The other changes are as given in the beta1 announcement:
- 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.
Happy flying!
5 Likes
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.
1 Like
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
Hi, when RSSI_TYPE set to 2 (PWM channel), then if the radio is turned-off, in the MP and OSD it remains the last RSSI value instead of going to zero. When RSSI_TYPE set to 1 (analog), then it is working well. Is it a bug, or is it possible to set it somehow in the MP?
In the Ardupilot documentation I have found this Note:
Certain sBus protocol variances may lead to channel values not being updated during receiver failsafe conditions. In this case, you will see the last valid RSSI value displayed during a failsafe. As the received signal strength usually gradually decreases under flight conditions, this will likely not have any negative effects. However, during setup and testing it might be confusing to see RSSI freezed at a compareably high value while your RC transmitter is actually switched off.
But in my opinion this issue cannot be a question of an SBUS protocol, if the same happens also when I disconnect the receiver from FC. The RSSI value (and also the respective channel input) freezes at the last value. I checked different Failsafe settings and different FW versions (currently 4.1.0), but still the same.
I encourage the responsible guys to check it, because it is very unpleasant and maybe sometimes also a dangerous feature.
Hi Tridge,
My recent internal error 0x2000000 was an " ISR Flood on pin 55 " I think it was caused by multiple parameters referencing Pin 55 including AUX3 as a PWM and AUX6 as GPIO CAM_FEEDBACK_PIN, Relay2, SERVO 11. Warning message came up as soon as Camera was activated. Went into Failsafe mode and RTL. More info and logs can be found here.
Hi Tridge,
I remember that there used to be the ability to take off and land on a mobile platform. Recently I wanted to test it, but I couldn’t find it. Is this function still available?
1 Like
This issue seems to be resolved by, Removing servo actions for camera – reconfiguring all camera Parameters to relay, and ensuring RELAY DEFAULT is set to 1 (for my camera)
I am also consulting whether there is an RTK function on the mobile platform to realize automatic take-off and landing.