I just flew a ~20 min flight, several miles away with 4.1 beta4 and it so far seems that the issue is gone. I’m wondering how such a severe issue was even able to occur on what should be a mature flight control system. Maybe an integration test needs to be added for ultra-long flights.
Dear Sir. With all due respect, the software you implemented is a “Beta” version. Beta versions are pre-final versions and meant to do exactly what you suggest: integrated testing. Once this stage is completed, it will be released as a final, stable version.
Yes, the Ardupilot software is pretty much a mature flight control system. However, it is open source, free of charge and only thanks to the unlimited dedication of the developers, it is available to you and me.
You have contributed tremendously by finding and reporting this issue, and I think the community is very thankful for that.
Is there an integration test for long flights? I think that would have caught this early. If there isn’t one, this would be a good reason to add one, or modify an existing one to look for EFK anomalies.
we do some quite long flights in our CI tests that are run on every commit. Longer flights of real vehicles is harder to organise, especially if the problems happens without turns as most places we can test have a quite limited area.
So really do rely a lot on people like yourself doing tests of the beta or pre-beta versions (called ‘latest’)
btw, talking about long flights, one of the features we focussed on for the changes in 4.1.0beta4 was very long distance flights. In the simulator I flew a plane from Canberra -> Auckland -> Los Angeles -> London -> Perth -> Canberra. This is the first release that can go around the world without EKF issues.
I will be installing the latest beta and running the exact same mission, hopefully I will get a chance to do that this evening. Will post logs back into this discussion. Just a quick one, when updating is it ok to copy / replace all params or are there some that need to be omitted between versions? (i.e. to use the default values)
you should just update the firmware, the new firmware will take care of any param mappings needed.
the param backup/restore thing I commonly see on the forums for upgrading firmware is a bad idea. It defeats the code that automatically manages any translation of params needed between firmware releases.
Why do we have to recalibrate the FC every time we update FW? Is there a way to backup and restore the FC calibration data?
If you do the firmware upgrades normally and dont try to restore anything, I’ve never seen any need to recalibrate anything. As Tridge says, any params that have changed name/funtion/range are automatically remapped to the new params.
That should not be necessary - we try very hard to avoid users having to
do that. There are rare exceptions where we do have to force it.
Are you finding that it is? Can you give and example of
old-version/new-version where it happened?
I was doing at the hard way, by completely reflashing the board with the STM 32 tool. I didn’t know ardupilot can now successfully flash the h743-wing.