Copter-4.1.0-beta7 has been released for beta testing

Copter-4.1.0-beta7 has been released for beta testing and can be downloaded from the ground stations (e.g. MissionPlanner, QGC) using the beta firmwares links.

The changes vs -beta6 are in the ReleaseNotes and also copied below

  1. Enhancements
    a) Attitude and altitude control changes to support higher lean angles
    b) Flywoo F745 supports external I2C compasses
    c) GPS-for-yaw arming check added
    d) GPS_DRV_OPTIONS allows forcing UBlox GPS to 115200 baud
    e) Guided mode accepts higher speed and accel targets (no longer limited by WPNAV_ parameters)
    f) Lua scripts can be placed in root of ROMFS (only relevant for developers)
    g) PSC_VELXY_FILT renamed to _FLTE, PSC_VELXY_D_FILT renamed to _FLTD
  2. Bug Fixes
    a) Beacon driver protected from requests for data for non-existant beacons
    b) CAN threading fix to resolve potential lockup when lua scripts use CAN
    c) EKF3 GSF can be invoked multiple times with source switching (no longer limited by EK3_GSF_RST_MAX)
    d) EKF3 IMU offset fix (vehicle’s reported position was slightly incorrect if INS_POS_XYZ params set)
    e) Guided mode terrain following init fix (might fly at incorrect alt on second use)
    f) Guided mode yaw rate target timeout fix (vehicle could keep spinning even after targets stopped arriving)
    g) OSD overwrite and nullptr check fix
    h) Proximity Avoidance auxilary switch also disables avoidance using upward facing lidar
    i) Proximity sensor pre-arm check disabled if avoidance using proximity sensors is disabled
    j) RCOut banner displayed at very end of startup procedure to avoid invalid output
    k) Tricopter tail servo alway uses regular PWM (fixes use with BLHeli motors)

The feeling in the dev team is that we are getting close to the stable release of 4.1 although there will certainly be at least one more release candidate to resolve an issue with Traditional Helicopters taking off in Guided mode (they can’t). We also still have a significant number of issues reported in earlier betas that require investigation.

All testing and feedback is greatly appreciated!


I don’t know what you did between b6 and b7, or maybe it’s mp latest today but I’m able to run sik radio telemetry to telem1 and companion computer on usb, and connect via UDP from companion. I haven’t tried loading a mission yet but hoping it all works afterwards. Thanks, Aaron

1 Like

I get an InternalError 0x100000 (5 zeros :slight_smile:
This happens at almost every flight, sometimes earlier, sometimes later.
It also happened with earlier 4.1.0-beta releases.

At first I thought it was the imu_reset error from the Matek H743. But this is a different error code.
Quadcopter with Matek H743-SLIM, Frsky FPort with Yaapu telemetry, SIK telemetry, TF mini/serial lidar.
I use the MATEK-H743-BDShot version.

I start in Stabilize mode, switch to Loiter and then leave the copter until the error occurs. Then switch to Stabilize and land. The error message comes almost every flight. Sometimes earlier, sometimes later.
The error does not affect the flight. Continues flying without visible effect.

During Flight:

Afer Landing:
2021-08-17 11_28_28

Here is the log:

1 Like

Hi @RainFly,

Thanks for the report.

The issue is that there is a very long loop (60ms or 0.060 seconds) appearing. We can seed this delay appearing in the “PM” message (Performance Monitoring).

This is triggering this Internal Error is the position controller.

By the way, we know this is the line because the PreArm is displaying:

PreArm: Internal errors 0x100000 l:955 flow_of_ctr

The “l:955” (that’s an L not an I) means that the internal error is occuring on line 955 so if we search for “InternalError” though the appropriate version of the code (Copter-4.1 in this case) we turn up the line linked above.

I’ve added this to the 4.1. issues list and we’ve created a specific issue here as well.

1 Like


Work in progress…

As 4.10 beta is in final stages, I had a try on my CUAV V5+.

Some parameters (WPNAV SPEED and WPNAV ACCEL ) were changed without my consent?

I had a navigation stored in memory and I use to run it to check if all is working as I want…

Before flight, I removed some waypoints (Landing gear related) then wrote waypoints back to memory. (Mission planner latest was used).

I didn’t check other params before flight. WPNav speed was changed from 500 to 1000 and WPNav Accel changed from 100 to 250.


Capture d’écran 2021-08-19 à 10.04.33

Link to .bin
4.10 beta7!AlTaMbgj9DGHgYlwp3XO18QOyJ0_Uw?e=Wcx8Wj


By the way, Navigation was at high speed but RTL went fine with landing near the arming-take off place.


Thanks for giving it a try and reporting back.

Yes, we increased the default wpnav speed from 5m/s to 10m/s and we should have included a warning or at least put it in the release notes. The way the changes to defaults works is if you’ve never changed the default value, then the new default is used but if you have changed it then it keeps the value you changed it to.

I’ll be sure to put a warning in the final official release notice.


Good information,


@rmackay9 and @Leonardthall I would like a second set of eyes on an issue on of my tradheli users had with my autotune firmware.

This was based on 4.1.0 beta7 however he was not using autotune when this issue occurred. I just want to be sure there isn’t any problem with the vertical position controller for heli’s. I have used althold many times and had not seen any issue with the vertical controller on takeoff.


Just closing the loop between the two threads. See @Leonardthall response here

He confirmed that it was an issue with excessive vibrations and not the firmware.

1 Like

Thanks a lot @bnsgeyer , lesson learned, hope to keep that in the future