Copter-4.1.1-rc1 available for beta testing


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:
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

I am not sure whether this is because a parameter is not set or a vulnerability is encountered, or even the original effect is 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.

OK, I have a chance to test again. It’s estimated at the weekend

@rmackay9 and @tridge

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

1 Like

Can you offer a link to an issues log so we can keep track of what’s progressing?


Not sure if this is what you’re looking for but but in any case, the overall ArduPilot issues list is here and this is the issues list for tracking issues reported during 4.1 beta testing.

Apparently not restricted to QGC…also MP over wifi…and Plane…MavFTP & Arduplane 4.1.2 >> parameters do not load

I was thinking of the issues list for 4.1 beta testing - as per your link. It brings up a document titled " Copter: 4.1.0 issues list #16478"

I was wondering if some document like this existed for 4.1.1 and onward.


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.

1 Like


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.

Hello guys, I’ve tested this version (4 auto missions, 30 minutes) and it has fixed the problem with lightware lw20, its working properly.

But now the copter wont go further than 7.5m/s, my mission has a DO_CHANGE_SPEED = 10m/s, I have checked everything that it related with speed without sucess, in all missions the top speed was 7.5m/s.

I dont know if it is a bug from 4.1.1 but I cant extract flight logs via mavlink, it takes forever. In 4.0.7 was normal.

Here is all logs including mission:

1 Like

Where is the .bin flight log?

Just uploaded, check again please.

I had to disassemble the copter to extract the log via sdcard.

please try disabling flow control on SERIAL5 by setting BRD_SER5_RTSCTS=0