Copter-4.1.1-rc1 has been released for beta testing and can be downloaded from the ground stations’s (e.g. MP, QGC) using their “beta firmwares” links.
The changes vs 4.1.0 can be seen in the ReleaseNotes and below.
EK3_PRIMARY allows selection of which EKF core/IMU to use on startup
ESC telemetry sent during compassmot
TradHeli landing detector improvement
Bug Fixes
a) Auto/Guided mode fix to EXTENDED_SYS_STATE message’s “landed state” field after takeoff
b) MAVFTP init fix (could cause slow parameter download)
c) Scripting fix when logging strings
d) Serial flow control fix (affected at least Lightware LW20 serial lidar)
e) QiotekZealotF427 IMU (ICM42605) orientation fixed
For most users these changes are not critical and you shouldn’t notice any difference but still we would appreciate any feedback on this beta release. If you are one of those affected by one of the fixes above we are doubly keen to get your feedback!
By the way, the most serious fix is probably (3) which closes some loopholes in the TradHeli landing detector. These loopholes are long standing issues present in 4.0.7 but still we are keen to get this fix out in the stable release. Hopefully this version will completely beta testing in about a week.
The yaapu script still does not work on Omnibus F4 nano V6.0, also in FW 4.1.1 rc1 (it worked fine on 4.0.5). Probably the patch for the Galileo constellation does not work well, but I need to do more tests.
EDIT: Galileo now works well. Solution: remove flag from SBAS gps config parameters.
The yaapu script still does not work on Omnibus F4 nano V6.0
We’ve done a lot of testing of 4.1.x and we haven’t seen this issue so I suspect it is because of some specific parameters on the vehicle. Could you please post an onboard log (aka a .bin file)? If possible demonstrating the slow altitude hold issue.
I posted this question in the update document of 4.1.0, but I didn’t get a reply,
Upgrade from 4.0.7 to 4.1.0, which is the parameter I configured for 4.0.7:
PILOT_ ACCEL_ Z=1000
PILOT_ SPEED_ UP=500
PILOT_ SPEED_ DN+300
This is a screenshot of the log. Sorry, I deleted the original file
Flight using loiter and althold
When the maximum throttle climbs or descends, the acceleration of UAV response is very slow and lags behind, which was not the case before
It can be seen that even if the throttle returns to the middle position, it will continue to rise or fall for a distance
These words are translated by machine. There may be some expression errors. I apologize for this
Any chance you could re-do the flight and post an onboard log? Sorry but it’s really hard to investigate without a log. It’s just guesswork without it.
@dkemxr and I have been working with @Pedro_Claro on a menu issue in Mission Planner that began when he loaded 4.1. Details of the issue are Here
The short of it is that he has 4.1 on a KakuteF7 and the Heli menu in mission Planner doesn’t appear in the set up menu when he initially connects with USB. Then once he connects the battery, the Heli menu will show up.
@dkemxr has shown this to work on the bench with his board that is the same. I thought it might be something with the initial mavlink messages that define the aircraft type. Any help with this would be appreciated.
@rmackay9 Randy, been setting up a new Pixracer to test a new copter frame…Cannot get param downloads with 4.1 on mobile QGC app over WIFI…okay over USB on Windows QGC…flashing 4.0.6, QGC mobile WIFI param downloads works fine…maybe MAVFTP related?..during 4.1 dev I noticed that QGC mobile sometimes took a bit to get parms started, but this is a hard failure…
Thanks for the report. I’ve added this to the issues list but I’m not personally able to investigate it much. Perhaps @DonLakeFlyer could help us.
You’re using the latest version of QGC of course? Herelink’s QGC is working although that isn’t using wifi and it is a fork maintained by Michael Oborne.
The 4.1.0 issues list is probably the closest we have. During the beta testing there are a huge number of issues that are reported in parallel so we use a single consolidating issue to track of them all… in particular the regressions from the previous version must be tracked and resolved. Once the beta becomes the stable release, issue tracking becomes more “business as usual” with the full list of issues and enhancement requests being applicable. We still need to recognise and resolve any “crash-o-matic” or otherwise important bugs … and I will continue to do this for a little while longer using the linked 4.1.0 issue.
I just tried this FW 4.1.1 rc1 and unfortunatly the F.PORT issue is also here. Exactly the same behaviour reported in the Plane FW4.1.2.
I am going to fly it now and let you know later if issues found.
Thanks for the report. From my understanding of the discussion it seems the F-Port disconnection (after 25min) exists in 4.1.0 as well? Of course we want to fix it but whether it is a regression from 4.1.0 or 4.0.7 determines whether it is a blocker for 4.1.1’s release or not.
@rmackay9 ,
This FPORT issue disconnection happens after few minutes and I saw it first time during the 4.1 Beta versions. For a while I thought it was solved, but when the 4.1 stable came out realize it was there. The peculiarity of this issue is that it shows only if you update the bootloader, if you dont update the bootloader the F.PORT doesnt disconnect. This issue doesnt exist in the 4.0.7 or 4.0.9 versions.
