Copter-4.2.0-rc4 available for beta testing

ArduCopter Copter 4.2
,
1

Copter-4.2.0-rc4 has been released for beta testing and can be installed using MP or QGC’s beta firmwares links or it can be directly downloaded from firmware.ardupilot.org.

The changes vs -rc3 are in the ReleaseNotes and copied below

  1. FlyingMoon F407 and F427 autopilots supported
  2. Vibration failsafe disabled in manual modes
  3. Bug fixes
    a) Log file list with over 500 logs fixed
    b) Loiter mode ignores ATC_SLEW_YAW parameter
    c) RSSI when using IOMCU pin 103 fixed
    d) TradHeli internal error during takeoff fixed

This resolves all blocking issue for the 4.2.0 release so hopefully this will be the final release candidate. Thanks very much in advance for any testing whether positive or negative!

8 Likes
3

Hi, this is an issue that I have had for a while, but I did not have problems in previous releases (I have used 4.1.5 and 4.2.0-rc2, 3 and now 4). Did report it against rc3, but although people made suggestions, it was not resolved.

Am now using Copter-4.2.0-rc4 on a Diatone Roma L5, flashing to a Matek H743 flight controller and using an iFlight 4-in-1 ESC (flashed with BlueJay - PWM 24KHz). As part of the set up, I did a motor test, and all the motors span up in sequence, but when I go to arm to fly, I observe the following behaviour:

Initially, nothing happens. I disarm and arm, use full right yaw when arming, and at some point, 3 of the 4 motors start to spin (on different occasions, it is different motors that don’t spin). Keep on arming and disarming, and eventually, all 4 motors start to spin and then everything appears ok.

I get the normal tones from the ESC, a long tone, pause, a short tone, pause, and then the final 3 beeps.

Comment from Andyp1per:
You have SERVO_DSHOT_RATE=2 and SCHED_LOOP_RATE=400 which means the dshot rate is 800Hz which is a bit slow. Try SERVO_DSHOT_RATE=3

Tried it on 3 and on 4, same behaviour, but motors were twitching and spinning for a couple of cycles even when disarmed. Will try 5.

Only 2 motors span up after nothing on the first couple of arming attempts, then 3, and then finally all 4. Still twitching…

He then wanted to look at timers:

STABILIZE> ftp get @SYS/timers.txt -
Getting @SYS/timers.txt as -
TIMERV1
TIM8 CLK= 200Mhz MODE=DS600 FREQ= 4878048 TGT= 4800000
TIM1 CLK= 200Mhz MODE= PWM FREQ= 11 TGT= 11
TIM15 CLK= 200Mhz MODE= PWM FREQ= 11 TGT= 11
TIM5 CLK= 200Mhz MODE=DS600 FREQ= 4878048 TGT= 4800000
TIM4 CLK= 200Mhz MODE= PWM FREQ= 11 TGT= 11

That was as far as we got. Flashed rc4 today, no change. Checked other params, changed the motor stators to 12 for the Tokas on my quad, but no difference.
Roma L5 20220516 1859.param (20.4 KB)

Anybody got any other suggestions?

Thanks for any help, Bill

4

@bjowitt Try set MOT_SPIN_ARM to 0.2 and MOT_SPIN_MIN to 0.21，and hope it can help.

5

@ ztzintelligence

Sadly, that did not work. On the second arming attempt, it tried to take off on 3 motors with rather more vigour :grimacing: I actually used 0.2 and 0.3 as your figures looked out of limit, unless you know something I don’t…

6

There is something wrong with DShot in version 4.2.0. I have made quite extensive tests of rc3 last weekend. During arming 3 motors were initiated properly, motor #4 did not initialize. It was in constant loop of initialization while emitting sounds. My hardware is pixracer and LlittleBee Esc. No such issues in previous versions.

I exchanged DShot150 with PWM and motors armed properly. Having that done I have made a few successful flights in very windy conditions (60km/h gusts according to weather station). Drone was fighting heavily and did really well. Still I would like to come back to DShot some time.

Note: Also I had to revert to mavlink v1 for Serial5 port connected to WiFi. New version silently turns mavlink v2, but it looks like QGroundControl on linux and android is not supporting version 2 properly and download of parameters was not possible. Still getting continuous status worked without errors - dashboard presented position, gps, voltage etc. It took many hours to spot the reason of issue.

7

Thanks for the report. Is this regular pixracer (F427)? What littlebee ESC? I may be able to replicate your setup.

If you have time I can build some test firmware for you to try.

8

@jtkacz,

Txs for the reports. I’ll leave the DShot issues to @andyp1per.

Re mavlink1 vs mavlink2, mavlink2 has been the default for a few versions (e.g. the default for all telemetry ports has been SERIALx_PROTOCOL=Mavlink2 for years) but in 4.1.x (and earlier) AP would still use mavlink1 until it received at least one mavlink2 packet. After that first mavlink2 packet arrived it would start using mavlink2. This allowed more mavlink1 only telemetry systems to keep working but in a way it also hid the problem so with 4.2 we decided to remove that fall back to expose these radios because there are real advantages of using mavlink2 (faster param downloads with MAVFTP, many new messages are only mavlink2,etc). I’ll try and make this more clear in the release annoucement for 4.2.0.

9

I noticed a little hiccup with the parachutes. I mentioned it in another thread for RC1, but I just upgraded to RC4 so I figure all put it here since it’s still happening:

I’ve setup a parachute system, and I did the initial setup with RC10_OPTION, 22 (parachute release). No problems.

I changed RC10_OPTION, 23 (3-postition switch), and then I noticed that CHUTE_ENABLE is reset to 0 and of course all the other parachute related parameters are no longer visible. I did bench test the manual release like this and it appeared to still work, even with CHUTE_ENABLE set at 0, but I wasn’t able to ground test the automatic release so I can’t say if that still works

I reset the RC option back to 22, and CHUTE_ENABLE to 1, and all my previous settings were still there so no data was lost.

10

@Allister,

Txs for the report, I had somehow missed it in other discussions. Is the CHUTE_ENABLE being reset to zero repeatedly or was it a one time thing?

I think the issue is most likely caused by one of these two things:

  1. An RC switch has been set to “ParachuteEnable” (21) instead of “ParachuteRelease” (22). Could you check if any RCx_OPTION params = 21?
  2. A Button has been setup to Parachute Enable. This is unlikely but maybe have a peek for BTN_FUNCx = 21
  3. a “DO_PARACHUTE_ENABLE” command was somehow sent from a GCS or companion computer to the autopilot. This is very unlikely I suspect.
11

It’s repeatable. I tried it a few times because it was odd enough I figured I forgot to save parameters or something fat fingered like that. Any time I change from 22 to 23 it happens.

I just double checked and there are no options set to 21. I’ve only been using a single switch for this.

I’ve only been connected to mission planner at this point with the quad. I don’t have any companion computers. This quad did have a simple four-point test mission in it’s memory, but that was from before I started the parachute project so there were no parachute commands.

I’ve never set up a button on this quad so that should all be default, but I’ll double check that one later tonight just in case.

For reference the FC is a PixRacer R15.

12

@Allister,

Ah, ok, I see the problem. RCx_OPTION = 23 is the Parachute-3Pos auxiliary function which, like PARACHUTE_ENABLE (21) directly sets the CHUTE_ENABLE parameter when the RC switch is in the low or middle position. This has the unfortunate side effect of showing/hiding the parameters when using a ground station but should have no effect on the functionality of the feature.

So just for clarity:

  • If the RC switch is put into the low position, CHUTE_ENABLE will be set to 0 and the remaining parameters will be hidden
  • If the switch is in the middle, CHUTE_ENABLE will be set to 1 and the params will be visible (you may need to press Refresh Params on the GCS to see them)
  • If the switch is in the high position, the chute will be deployed/released

The switch directly changing the CHUTE_ENABLE parameter is really not good so I’ve raised an issue to fix it. It is a long standing problem though so it’s unlikely to be fixed for 4.2.

13

Thanks @rmackay9

I’ve just tested it out and it works as you say. When I have the switch in the middle position and refresh the parameters then CHUTE_ENABLE is set to 1. And when the switch is low and I refresh the parameters then CHUTE_ENABLE is back to 0.

I agree this isn’t ideal, but as long as the parachute works when I move the switch then I’m good with it. I appreciate you looking into this.

1 Like
14

Thanks @jtkaz - that gave me a clue to try and fix the problems I had been having on my quad (above). I set MOT_PWM_TYPE from 6 (Dshot 600) to 5 (DShot 300) - tested my quad and it armed first time, no rudder input, all four motors spinning. I am not sure what effect that will have on performance or flight characteristics, but I don’t race or do much freestyle, so I am sure that I will be fine.

In conclusion, it does look like 4.2.0 has a problem with Dshot - I don’t know what the implications are, but presumably people will want to use Dshot 600.

15

@bjowitt so you were using BlueJay in previous releases without issue? BlueJay was one of the reasons for making this change because in my testing it did not work.

16

@bjowitt what I would like to do is send you some test firmware with some additional config options to see if we can nail down what works and what doesn’t on what hardware

17

@andyp1per I am pretty sure that I had flashed BlueJay before I started trying to get ArduCopter to work and the latter worked fine on previous versions. The reason that I started trying to use 4.2.0 release candidates, is that I use HD Zero and could not get the OSD up in 4.1.5.

Very happy to help on testing firmware. My current parameters attached.
Roma L5 20220518 1037.param (20.4 KB)

18

Are you using the bdshot version of the firmware?

19

No - I can try and flash that now and try it with the original MOT_PWM_TYPE setting.

20

Would be helpful to know. Not much point in using BlueJay if you are not using bdshot …