Copter-4.0.2-rc4 available for beta testing

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

This release includes several more fixes on top of the previous release candidate (-rc3). These are listed below and in the ReleaseNotes:

  1. Bug Fixes:
    a) Spektrum receivers decoding fix for Pixracer
    b) Current Alt frame always relative to home (RTL could return at wrong alt)
    c) Circle mode pitch control direction fixed (attempt2)
    d) EKF only uses world magnetic tables if COMPASS_SCALE is set
    e) Logging reliability improvements especially for FRAM logs
    f) RangeFinders using PWM interface use RNGFNDx_OFFSET param (attempt2)
    g) SpeedyBeeF5 probes all I2C ports for external baro
  2. Rangefinder fallback support (both must have same _ORIENT)

@JoshW, @winstonsaz, @wn0x could you confirm you’re happy with the Circle mode pitch direction?
@mtbsteve could you confirm 1f is OK? (rangefinder offset param issue)

The Copter-4.0.x release has maybe been a little bumpy but the outstanding issues list is quickly getting shorter now so hopefully it will become smoother after 4.0.2 goes out.

Thanks again for your help with beta testing!

3 Likes

My apologies Randy, I haven’t been able to fly in days, I’m recovering from surgery.

1 Like

Hey @rmackay9
Got to test rc4. Circle mode works as mentioned. I’ll upload long in some time.

2 Likes

Excellent. Circle mode should be working properly and as described in the wiki now as of 4.0.2-RC4. Pitch stick “forward” will reduce the radius, as in moving forward from an FPV perspective. Pitch stick “back” will increase the radius, as in moving in reverse from an FPV perspective.

3 Likes

Can’t wait to give it a go.

Thanks for “upstreaming” this from Solo to ArduPilot, Matt.

1 Like

When was rc4 uploaded? Was the “lastest” I grabbed last night rc4? or was it somewhere between rc3 and 4?

Here’s the log for rc4 test flight.
@Pedals2Paddles Yes, It works exactly the way described.

2 Likes

The “Latest” directory on the firmware server is master. You’ll want to look in the beta directory for the Copter 4 beta releases, and stable for the most recent stable release.

I do understand that. I needed something beyond rc3 last night… I grabbed from “lastest” and then rc4 was released this am… Wasn’t sure if the latest from last night was actually rc4

@smartdave,

“latest” and -rc4 are different in a lot of mostly small ways. The Copter-4.0 branch was created off of “latest” a few months ago so at that moment they were identical but since then we’ve only been selectively pulling across (aka merging, aka cherry-picking) fixes from “latest”.

1 Like

Gotcha. Thanks.

So if I want the newest of the new. Is that latest or is that beta?

Latest will be the -dev version so on the cutting edge.

2 Likes

That’s what I thought. Thanks

@rmackay9 sorry for the delayed response. RC3 was working exactly backwards both on direction and radius but it looks like @Pedals2Paddles has worked this out in RC4. Finally quit snowing so I hope to test Saturday. Again, thanks Matt for working on this.

3 Likes

@rmackay9
Hi Randy,
I can confirm that the RNGFND_OFFSET fix is working in RC4.

I also tracked down the Jeti telemetry problem. Issue was that during the update to 4.0.2 RC4 a number of the SR01, SR02, and SR03 parameters got wiped out and therefore the telemetry was broken.

I regard the frequent but random parameter losses in AC4 as a serious issue. You need to verify every single parameter after an upgrade in order to ensure that nothing is broken. Thats a real PITA.

1 Like

When testing V4.0.2-rc4 today, the quad suddenly flew away to the left by itself (in QLOITER mode and crashed into the ascending ground before I could switch back to QHOVER or QSTABILIZE). Thanks to the damp floor, nothing really broke.
But I’m not sure of the cause. With V4.0.1-rc2 and identical setup the copter flew well, mainly in QLOITER and ZigZag mode.
Could it have anything to do with the high compass offsets? Only the pixracer’s internal compasses are used (X:146.88, Y:250.36, Z:144.23 /
X:146.00, Y:250.00, Z:144.00)
Film (See at 00:33) : https://vimeo.com/389998527
Logfile (Flight to the side at 11:07:57.000 , crash at 11:08:00.200) : https://www.magentacloud.de/share/c4-k8nm-76
Regards Rolf

1 Like

I didn’t check the log yet! But i could listen to ESC boot sound at the end of the crash. I think your ESCs have some issues.

Thanks for the hint. But i think that the sound is the sound of the ESC emergency shutdown (Lumenier 23 A 4-1 BlHeli_32) after the impact due to a blocked propeller. You can see in the log file that the ESC switched off the motors (the current drops to almost zero) before the crash detect became active.

@mtbsteve,

Thanks with your ongoing help with beta testing, it’s very much appreciated.

Re the parameter changes, the SRx_ parameters are normally set when a ground station or companion computer (if present) sends a REQUEST_DATA_STREAM message to the vehicle. This is normally one of the first things they send. Users can set the SRx_ parameters manually but they will be overwritten if the ground station sends one of these request-data-stream messages.

I took the extra step of loading up Copter-3.6.12 on a CubeBlack and then set all the SRx_ parameters to uinque values then upgraded to Copter-4.0.2-rc4. The parameter values were the same after the upgrade except for SR0_ which is the USB port (which I was using) so this would have been caused by the MP’s request-data-stream messages.

I looked through the log file (link see previous message) of the crash again. The “mini-fly-away” starts (GPS Speed increase suddenly) at the very moment when AHR2.Yaw and ATT.Yaw differ.


ARMING_CHECK is 1. The only problem while arming was that through the update FS_THR_ VALUE was set back to 975 and I had first to change this valus to the old value before the copter could be armed.