Copter-4.3.2-rc1 available for beta testing

ArduCopter Copter 4.3
1

Copter-4.3.2-rc1 is available for beta testing and can be downloaded using MP or QGC’s “Beta firmwares” link. The change vs 4.3.1 are in the ReleaseNotes and copied below.

  1. Arming check that main loop is running at configured speed (e.g. SCHED_LOOP_RATE)
  2. uBlox M10 fixes to reliably provide 5hz updates
  3. Autopilot specific changes
    a) CubeOrange defaults to using 2nd IMU as primary
    b) SIRF and SBP GPS disabled on BeastF7v2, MatekF405-STD, MAtekF405-Wing, omnibusf4pro
  4. Bug fixes
    a) AutoTune gains loaded correctly during pilot testing
    b) Camera driver’s CAM_MIN_INTERVAL fix to cope with mission and pilot triggering
    c) EKF3 fix when using EK3_RNG_USE_HGT/SPD params and rangefinder provides bad readings
    d) Main loop slowdown after arming fixed (parameter logging was causing delays)
    e) Main loop’s fast tasks always run (caused twitches in Loiter on heavily loaded CPUs)
    f) MAVLink commands received on private channels checked for valid target sysid
    g) ModalAI cameras support fixed (ODOMETRY message frame was consumed incorrectly)
    h) Param reset after firmware load fixed on these boards
    - BeastF7v2
    - CubeYellow-bdshot
    - f405-MatekAirspeed
    - FlywooF745Nano
    - KakuteF4Mini
    - KakuteF7-bdshot
    - MatekF405-bdshot
    - MatekF405-STD
    - MatekF405-Wing-bdshot
    - MatekF765-SE
    - MatekF765-Wing-bdshot
    i) Siyi A8 gimbal support fixed
    j) Windows builds move to compiling only 64-bit executables

WARNING: we have a report that the first item (the main loop arming check) may interfere with the Motor Test and CompassMot calibration features. This is not dangerous but may be annoying and we may need to drop this arming check for now.

Thanks for any help you can provide with testing!

4 Likes
3

@rmackay9

Is this the same firmware that you linked in the discussion bout the internal error with Leonard?

And also, does this firmware include Leonards new controller mechanics?

Thanks!

1 Like
4

These appear to be some pretty big changes!

I installed RC1 on a brand new EDU-450 build earlier today (before the announcement) and flew a few short tuning flights without significant issue. I’m seeing some yaw realignments that I’d prefer to eliminate, but I’ll chalk that up to calibration for now.

It does retain the “disabled channel” bug that apparently has been fixed in master, but that was quite annoying when my LED script caused prearm issues. Might be nice to see that backported.

5

@Axel1,

This release is very similar to one of the firmwares I provided in this discussion. It includes the fix so that Loiter doesn’t twitch due to main loop slowdowns. It does not include Leonard’s more complete enhancement that allows the controllers to more accurately handle main loop slowdowns.

I think we will discuss at tomorrow’s dev call when we should include Leonard’s more complete fix.

2 Likes
6

Hi @Yuri_Rage,

Thanks for testing!

I’m not aware of the “disabled channel” bug (I’m not tracking it on the 4.3. issues list). I guess @andyp1per knows about this one?

7

Thanks!

I’m waiting for parts for my test rig now but I should get them by the end of the week. I’ll test Leonards firmware as soon as I get into the air again!

If you guys come up with something you need to test regarding Leonards firmware on tje dec call, just write here and I can do the tests!

1 Like
8

@rmackay9,

The specific prearm message is “PreArm: SERVO14_FUNCTION=94 on disabled channel.” @iampete and I had a short Discord conversation about it today, since I thought it may be related to script development.

Relevant PR appears to be this one:
AP_Arming: allow scripting channels to be disabled by IamPete1 · Pull Request #22012 · ArduPilot/ardupilot (github.com)

1 Like
9

@Yuri_Rage,

Ah yes, that one. Ok, thanks very much for clearing that up.

10

Hi Why did you change to using 2nd IMU as primary ?

11

@norim,

My understanding is that some CubeOranges had some sort of hardware issue that caused the first IMU to reset quite often. My understanding is that the 1st and 2nd IMUs are both of the same quality so using the 2nd one is a better default choice.

I’m afraid I don’t have any information on how many CubeOranges are affected. I fly them all the time and I haven’t noticed any issues and I haven’t heard of any crashes because of this issue… but I’m really not the expert on this issue.

FYI @bugobliterator

1 Like
12

Flight Mode 5 is configured to SPORTS but even if the switch is positioned at Flight Mode 5, the current mode says STABILIZED. Please refer to screenshot. And YAPPU is also reporting STABILIZED as the flight mode.

image
image793×402 50.3 KB

20221213.param (19.5 KB)

13

I thought Sport Mode was removed. Not surprised it still shows up in Mission Planner.

14

Well its still there. But it cannot be used. Confusing cause its still in WIKI. I suggest it must also be taken out from WIKI.

Was there a replacement for Sports?

15

No. Nobody used it, removed to save space.

1 Like
16

Yup, I’ve already taken it out. Thanks.

17

I would like to test Throw flight mode in replacement for Sports. Any advice if this is safe and what preparations should be made?

18

@Carlou,

Thanks for the report. @dkemxr is right of course although we haven’t completely removed the flight mode but it requires using the custom build server to add it to the firmware. I’ve added a to-do item to the wiki to make this clear.

image
image687×891 68.5 KB

1 Like
19

I endeavoured building a custom firmware but never succeeded. Is it possible to say in the builder to copy the firmware of say KAKUTEH7V2 and then the user will just add what they want? This way, it’s safer rather than manually choosing everything. Just a suggestion if possible.

1 Like
20

There is a comprehensive Wiki entry for that, it’s not a 4.3.2-rc1 Beta Release question.

1 Like