Copter-4.0.7-rc1 released!

ArduCopter Copter 4.0
1

Copter-4.0.7-rc1 has been released and is available for download from the ground stations using “Beta Firmwares” link. The changes vs 4.0.6 are in the ReleaseNotes and copied below.

  1. added automatic backup/restore of parameters in case of FRAM corruption for F7/H7 boards with 32k FRAM parameter storage

  2. 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

  3. fixed a problem with low accuracy data from UAVCAN GPS modules when GPS blending is enabled

  4. fixed an arming check failure with u-blox M9 based GPS modules

  5. fixed a race condition in SmartRTL which could cause a LAND mode to be triggered

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.

6 Likes
3

Was flying 4.0.7RC1. Been experiencing uncommanded pitch or roll movements. I have attached the log to see. Hope someone can check them out.

Logs can be found from here https://we.tl/t-NdVmuu7Li6.

4

You should adjust these:
FENCE_ALT_MAX,30
FENCE_RADIUS,30
and set these:
BATT_FS_CRT_ACT,1
BATT_FS_LOW_ACT,2
You’ve got a pretty poor tune there, and I think the “uncommanded pitch and roll” are because you are constantly hitting that Fence.

image
image1320×298 43.1 KB

Maybe fix the Fence settings, try some more tuning then see of you’ve still got the uncommanded pitch and roll. I can’t see anything out of place in that log.

5

@chandruth26,

As @xfacta says, the tune is quite bad on this vehicle. In particular I think the ATC_RAT_RLL/PIT_P/D values are probably too low.

You’ve seen the Tuning Process Guide of course? I guess you’ve used AutoTune and I think it unfortunately hasn’t worked well.

6

Yeah the autotune didn’t work well. I have since tuned the craft manually using the Alt+A on mission planner and done a manual tune. The ESCs on this craft doesn’t have active breaking so its a little hard to tune it perfectly but now it flies pretty well. Also realised somewhere along the way INS_HNTCH_ATT has changed from 15 to 40 for defaults. I can confirm 14 Cube Orange with Here3 running great on 4.0.7RC1. No resets yet. Did a 6hr+ long tethered flight in strong winds on one of the crafts as well. Posted a log here in case the data from the flight is useful for your further developments since not many do super long continuous flights for multi rotor. The log can be found here https://we.tl/t-WhaV56bNVZ. The craft has a SF40 on it which was enabled after the tethered flight. And I have realised on ArduCopter the rotation speed slows down after a few seconds after boot. Is this intentional? It would be great if it can spin at its maximum speed because I have realised there is delayed data in the avoidance data for each angle for about 0.5 seconds as it isn’t spinning as fast.

2 Likes
7

4.0.7 has been released now, is there anywhere more Details on what was changed in regard to the mRo boards ?
Thanks

1 Like
9

Sure, here it is: https://github.com/ArduPilot/ardupilot/pull/16638