Copter-4.1.0-beta5 has been released for beta testing

Copter-4.1.0-beta5 has been released for beta testing and is available for download from the ground stations.

Changes vs -beta4 are in the ReleaseNotes and also copied below:

Changes from 4.1.0-beta4

  1. Enhancements
    a) Arming check of distance from EKF origin increased to 250km horizontally (was 50km), 50km vertically (was 500m)
    b) Position control accuracy improved at very long distances (aka “Loiter bucketing”)
    c) Pre-arm check of FLTMODE_CH and RCx_OPTION conflict
    d) QioTekZealotH743 autopilot support
    e) Scripting support for set home and get EKF origin
  2. Bug fixes
    a) Autonomous mode (Auto, RTL, etc) stopping point calculation fixed (could cause alt drop entering RTL)
    b) Auto mode Internal Error fixed when origin and destination are very close
    c) Auto mode Terrain following less bouncy and RNGFND_FILT param added for configurable filtering
    d) EKF alt estimate more robust when using GPS-for-yaw
    e) EKF origin altitudes consistent across cores even if user takes off with no GPS lock
    f) Logging start does not affect EKF (EKF could become unhealthy due to timing delays)
    g) Loiter rocking while landing fixed
    h) Loiter speed fixed with low LOIT_ACC_MAX values
    i) Loiter aggressive deceleration fixed (occured if vehicle was previously switched out of Loiter during decleration)
    j) Longitude wrap fixed (allows flying across international date line)
    k) MOT_THST_EXPO limits fixed to allow values between -1 and +1 (was 0.25 to +1)
    l) Position jump fixed during GPS glitch and GPS/Non-GPS transitions
    m) Proximity sensor status (used for object avoidance) fixed when using only upward facing lidar
    n) Vibration failsafe fixed
    o) 6DOF copter fixed

Thanks again to all the beta testers! You have helped us uncover the issues found above which is incredibly important in terms of us getting a good stable release out. Thanks!

P.S. the list of outstanding issues is here.


Thanks. Will test soon…


I don’t want to clutter the Github issues with noise, but I’m having a problem with beta5 copter. I get “Compass Unhealthy” and cannot arm. This wasn’t an issue previously. I had been running beta4 until just now. I just tested downgrading to stable and it was okay and I was able to arm. Is there anywhere I can still download the fmuv3 beta4 binary so I can confirm the bug/feature appears between beta4 and beta5, as there’s nothing in the release notes that stands out so it seems odd?

2021-07-02 08:30:33.808 fmuv3 0027002A 3030510B 32393832
2021-07-02 08:30:53.320 u-blox 1 HW: 00080000 SW: ROM CORE 3.01 (107888)
2021-07-02 08:30:56.000 PreArm: Compass not healthy

With Beta4 I was having problem with altitude while also using gps for yaw. The altitude was wrong by a lot and it didn’t stay constant. I tested the beta5 and now it got much better, now when armed the altitude has a precision of +/-3 cm.

If anyone is using gps for yaw and having altitude inaccuracies or altitude problems,wrong altitude values or altitude inconsistency , should upgrade for beta5

1 Like

I had the internal compass set to “don’t use”. I enabled it, flew around with 4.0.7, ran MagFit and updated the calibration parameters. Now I can arm and fly with Beta5. Has anything changed with the way COMPASS_USE parameters are interpreted with the new release? Cheers.


No, there shouldn’t be any changes. It sounds like perhaps the external compass is not working. If you could provide an onboard log especially from when the “compass not healthy” message displayed that would be great.

I can re-generate -beta4 for you but there also shouldn’t be changes vs 4.0.7 in terms of what compasses are supported. Certainly we haven’t removed support for compasses as far as I know.

Also what autopilot are you using? I see “fmuv3” above but that covers a lot of boards so knowing more specifically what board is being used could help.

Thank you.
I’m ready!

Hi, thanks for your great job!
Does this release include the patch for Matek 405 CTR to have bidirectional dshot working?

Yes it does

More characters

1 Like

Thanks. Here’s a log from this morning when it was saying ‘compass not healthy’

It’s a PixHawk 2.4.8 board… I’m not sure how to get more specific hardware details?

I remembered an issue which is probably related - I have the compass pre-arm disabled because it says ‘Compass 1 Not Found’ even though the compass shows up as a connected sensor, logs data and generally seems to be just fine. That’s also why I had COMPASS_USE set to 0. Since I calibrated the compass with 4.0.7 and then re-upgraded to beta5 this morning it is arming and flying well, but I still get the anomalous ‘Compass 1 Not Found’ prearm failure if I don’t disable the check. Compass 1 is the internal compass.

The unhealthy gps when using gps for yaw still persists.

Maybe I did something wrong but seems like my i2c display (ssd1306) was working in beta4 but now I don’t see the parameter ntf_display_type after upgrading to beta5 and the display is blank. Running pixhawk1-1m and I went through the NTF_LED_TYPES and tried adding them one at a time then all but can’t seem to bring that display back to life. edit just confirmed an identical display is working on its sister craft running beta4 (that I haven’t upgraded yet)

It was removed in beta5 on 1Mb boards but by popular request will be back in beta6

1 Like

Thanks for taking time to support us legacy folks on the old Pixhawk boards

If anyone else runs into this running a pixhawk1-1m and wants to go back to somewhere between beta3 and beta4 I found the June 1st build to have the i2c ssd1106 display enabled

Definitely a nice thing to have all the builds up on that site, or I’d have to wait for beta6 to fly that craft again :slight_smile:

Finally did a full chip erase before doing full calibration process and everything is ok now. Sorry for that previous useless post.

1 Like

I didn’t see alex78’s original post but that reminded me of an issue I had a few years ago with my Pixhawk, it was wanting to fly with down facing the horizon. It would flip on takeoff. Motor directions were ok, FC orientation correct in the parameters… I finally figured out it wanted to fly sideways by holding the copter as I armed and took off, ramping up the throttles then physically moving it around and watching the motors… it wanted to fly on its side, that’s when all the motors were the same speed. It fought any other orientation with winding the motors up much faster. But anyways, it was fixed by loading plane, then loading copter back on (3.3 iirc). This was after doing about countless parameter resets from copter that didn’t seem to fix it. Anyways that was years ago but wanted to mention that in case someone has something similar (like alex?) and doesn’t know what’s going on.

edit thinking about it maybe I had to do that because it wouldn’t let you load the same firmware on. Does Missionplanner read back the firmware after loading and verify no errors happened?


The flying-sideways issue might have been caused by the AHRS_ORIENTATION parameter being set incorrectly.

By the way, to save a bit of time it is possible to reset the parameters using the “Reset to Default” button on MP’s full parameter list or full parameter tree screens instead of loading plane then copter on the autopilot.

I’m pretty sure that there is a check on the firmware being loaded because I’ve never heard of an issue of a corrupt firmware being loaded on an autopilot. It is definitely possible to load a firmware that does not work including failing immediately at boot but this is a little different.

Hope that helps in some way.

1 Like

Hi all, just did some flight tests with beta V4.1.0-beta5 (98c73a0b) wow it fly’s in Stabilize like the old days. However I noticing some twitch’s in Loiter mode and drops that 4.07 seemed to remove that i think seemed to be introduced in Beta , the twitches do not do not show in Stab mode. Ground effect seems better overall but not perfectly stock. Thanks!

1 Like

Maybe check / adjust the following?

LOIT_ACC_MAX : max acceleration in cm/s/s. Higher values cause the copter to accelerate and stop more quickly
LOIT_BRK_ACCEL: max acceleration in cm/s/s while braking (i.e. pilot has moved sticks to center). Higher values will stop the vehicle more quickly
LOIT_BRK_JERK: max change in acceleration in cm/s/s/s while braking. Higher numbers will make the vehicle reach the maximum braking angle more quickly, lower numbers will cause smoother braking