Copter-4.0.5 released!

[rmackay9]

Copter-4.0.5 has just been released and should appear in the ground stations as the official/stable version within a few hours. The changes vs 4.0.4 are in the ReleaseNotes and copied below.

1. Bug fixes:
   a) Serial/UART DMA race condition that could cause watdog reset fixed (Critical fix)
   b) SBUS output when no RC input fixed (Critical fix)
   c) Acro expo calculation fix (fixes sluggish behaviour)
   d) F32Lightening board IMU fast sampling fix
   e) GPS minimum accuracy added to protect EKF from unrealistic values
   f) KakuteF7/mini DShot glitch fix
   g) RC input gets additional protection against out-of-range inputs (<RCx_MIN or >RCx_MAX)
   h) RC_OPTION = 4 fix on boards with IOMCU (Pixhawk, etc). This allows ignoring SBUS failsafes
2. Small enhancements:
   a) Linux boards accept up to 16 RC inputs when using UDP
   b) Protect against two many interrupts from RPM sensor, etc
   c) RM3100 compass support for probing all four I2C addresses
   d) Durandal telem3 port enabled

As always, thanks very much to our beta testers for putting their vehicles at risk to help us ensure this is a safe release.

[Webillo]

ArduCopter V4.0.5 (3f6b43e3)
ChibiOS: d4fce84e
mini-pix 0026003F 34365119 34363234
Param space used: 1332/3840

Done six very good flights with around eleven missions, with the ROI forgotten appearing twice, as had appeared here (TradHeli 4.0.0-rc2) and here (Copter 4.0.4-rc3).

Best observed with the tlog captures first and second flight, or with ATT.DesYaw/Yaw, which are coincident:

These are the logs:
First flight
Second flight

Note that on the first flight it occurs early, and on the second flight it occurs at the middle of the first mission, and later the mission is restarted and executed three times and it does not occur.

No idea why or when it happens, or how to repeat it. Some arithmetic problem when in a mission? Note that in both occurrences ATT.DesYaw/Yaw transitions from 360 to 0.

[rmackay9]

@Webillo,

I haven’t look at the log but the most likely reason is that the RC yaw stick has been moved outside the deadzone. So I’d recommend checking the RCIN for channel 4 and also check RC4_DZ is big enough

[Webillo]

You are right: in both ROI changes there is a single message showing not only a glitch on RCIN.C4 but also value changes in C1, C3, C5, C6 and C7 (not in C2 ???). So surely this is related to the problem. Anyhow, I am not sure of what would happen if you change yaw with a stick during a mission (I am certain that changing throttle does nothing), but will try this next time.

The transmitter in this case is a Futaba 7C. C5 is on two switches for mode change (channel 5), C6 is a knob (potentiometer, channel 6) for gimbal pitch (unused), and C7 is on a switch. RCIN.C6=0 and RCIN.C7=0, as appear in the message, would be impossible to get.

These ROI changes have been observed on different Arducopter versions and vehicles (first on Tradheli, with a Futaba T8FG), and using two different Futaba 7C transmitters.

Receivers used are FrSky TFR4-B in all these cases.

I didn’t move the sticks while in the mission. Otherwise, it would be impossible to manually do such a small instantaneous change on a stick, a knob and at least two switches, precisely with copter in north orientation.

These are the relevant configuration parameters:
RC1_DZ,20
RC1_MAX,1939
RC1_MIN,1146
RC1_OPTION,0
RC1_REVERSED,0
RC1_TRIM,1523
RC2_DZ,20
RC2_MAX,1938
RC2_MIN,1116
RC2_OPTION,0
RC2_REVERSED,0
RC2_TRIM,1519
RC3_DZ,30
RC3_MAX,1931
RC3_MIN,1092
RC3_OPTION,0
RC3_REVERSED,0
RC3_TRIM,1100
RC4_DZ,20
RC4_MAX,1950
RC4_MIN,1081
RC4_OPTION,0
RC4_REVERSED,0
RC4_TRIM,1520
RC5_DZ,0
RC5_MAX,1793
RC5_MIN,1092
RC5_OPTION,0
RC5_REVERSED,0
RC5_TRIM,1597
RC6_DZ,0
RC6_MAX,2119
RC6_MIN,920
RC6_OPTION,0
RC6_REVERSED,0
RC6_TRIM,1622
RC7_DZ,0
RC7_MAX,1884
RC7_MIN,965
RC7_OPTION,17
RC7_REVERSED,0
RC7_TRIM,965
FLTMODE_CH,5
FLTMODE1,2
FLTMODE2,0
FLTMODE3,3
FLTMODE4,16
FLTMODE5,9
FLTMODE6,6

For RCIN.C5=1482 mode is Auto. For RCIN.C5=965 (glitches) mode would be AltHold during an instant, but mode is not changed.

So unless admitting that two different Futaba transmitters (7C (Copter) and T8FG (TradHeli)), or three different FrSky TFR4-B receivers, produce sometimes somekind of simultaneous channel glitches, precisely when the controlled vehicle is oriented north, and simultaneously somehow producing RCIN.C6=0 and RCIN.C7=0, there must be other explanation.

Anyhow, since 1516-1092=24 > 20=RC4_DZ, I will change RC4_DZ=30 and keep observing.

[rmackay9]

@Webillo,

Changing the yaw during a mission causes the vehicle to change heading until the next waypoint.

Maybe check how the failsafe is setup on the transmitter/receiver. It is best to set it to “no pulses” rather than to set some or all channels to a predetermined value.

[Webillo]

@rmackay9

Changing the yaw during a mission causes the vehicle to change heading until the next waypoint.

I didn’t move sticks while in the missions. Anyhow, this is good to know; I’ll try it.

@rmackay9

Maybe check how the failsafe is setup on the transmitter/receiver. It is best to set it to “no pulses” rather than to set some or all channels to a predetermined value.

On the TFR4-B you can set all, which is an advantage. I set all to neutral pulse except:
·C7 on two position switch: low (no action).
·C3: under FS_THR_VALUE=975 (as 925) with FS_THR_ENABLE=1 and FS_OPTIONS=0, and no action on transmitter. In this way I can simulate and test a radio failure, with a switch mix on throttle, causing RTL.

No failsafe on logs, only the instantaneous RCIN.C4 (yaw) glitches.

Isn’t that a Futaba C7? You shoud know it well!

[Webillo]

@Webillo

as had appeared

Here are ATT.Yaw/RCIN.C4 and RCIN messages for the other reported above ROI forgotten missions:

·Tradheli v4.0.0-rc2:
ArduCopter V4.0.0-rc2 (5701af1a)
ChibiOS: 0997003f
Pixracer 00250024 34385105 35383135
Param space used: 1350/3840
·Different transmitter Futaba T8FG.
·Other FrSky TFR4-B receiver.
·Same single message with distorted channel pulses. Last two channels RCIN.C7=0 RCIN.C8=0, impossible from transmitter.
·Yaw is not north, so this is not the cause.
·Two other glitches with similar RCIN distorted values.

The changes in RCIN.C4 seem natural, possibly because left stick knocked something and was displaced (at that time I didn’t know that moving yaw stick while in a mission distorted the ROI).

@rmackay9

Changing the yaw during a mission causes the vehicle to change heading until the next waypoint.

After changing yaw from the transmitter as in here (not on purpose), heading changes and ROI is lost, but this seems to last during the rest of the mission.

[Webillo]

Different case (video): quad-X flying at low height in a zig-zag mission, touches grass and 5" later looses ROI. No glitches in RCIN.C4:

---

---

20201108

@rmackay9

also check RC4_DZ is big enough

Tried 4 batteries with 18 started missions (14 completed), increasing RC4_DZ from 20 to 30. The RCIN.C4 glitch appeared just before ROI was lost again once:

(RCIN.C4=1085 departs more than RC4_DZ, so no effect), with again modified values also in C1, C3 and C5 (not in C2) and absurd values on the last two channels (RCIN.6=0 and RCIN.C7=0).
at the second mission of the first battery:

BTW, the batteries where changed on the fly. Energy consumed is not reset, so at the start of the third battery arming was not possible. MP showed an absurd situation:

so I did a PREFLIGHT_REBOOT_SHUTDOWN from MP.

PR 11615 suggests battery reset from GCS, but the controller, in this hardware case/situation, has enough information for detecting the battery change. Am I missing something?

[Christian81 (Christian)]

Does anybody know, if this Version fixes the problem with Configuration Check on the GPS M9N?

[amilcarlucas]

@Christian81 No, it was not backported, and yesterday on the meeting it was decided not to backport it.

[Webillo]

@Webillo

The RCIN.C4 glitch appeared just before ROI was lost again

This is another ROI loss providing a better clue for the ROI lost problem:

so really what happens is a channel shift: pulse width values appear shifted one place to the left. C1 is lost, C4 gets C5, and ROI is lost.

Controller is a Holybro Mini Pix on a QuadX. Reported above was a Pix Racer on Tradheli, where pulse width values appear shifted two (once) and three (twice) places to the left:

Common to all pulse width shifts:
·different controllers, but all without IOMCU,
·different receivers, but all were FrSky TFR4-B,
so it is not clear where the problem is located.

Note that pulse shift could occur in any situation; here it is noted since these are missions with ROI. A simple way to check could be:
·Choose a long log.
·Open it with MP.
·Filter on RCIN.
·Export Visible to .csv.
·Open .csv as a spreadsheet and order rows on last used channel column, ascending.
·Check if value is 0 on first row last channel.
·If so, check this row on .log log.

[rmackay9]

@Webillo,

Nice investigation. Of course you are not using an RFD900 radio right? We saw a similar issue that was caused by a bug in the RFD900 radio’s software (i.e. not ArduPilot). I don’t think you are using this radio but I just want to check.

[Webillo]

Wifi ESP’s. You indicate an aditional channel on a long interval; here are one or several channels lost (C1, C1+C2 or C1+C2+C3) in a single message.

I’ll try a different receiver next time.

[rmackay9]

@Webillo,

We discussed this on the dev call and we think that it’s possible the receiver has a problem and simply cannot report all channels within the 22ms it is allowed. Is it possible for you to reduce the number of channels that are used? Also the problem may only happen when the total PWM of all channels goes above a certain number.

So one solution is likely just to replace the receiver with a newer model. FrSky may also have an updated firmware that resolves the problem.

If you have a link to a log file we could check whether the total PWM value is too high.

[Webillo]

@rmackay9

22ms

Here are two views of a T8FG+TFR4-B signal capture:

So the sync pulse lasts 7ms and the pulse interval 400 µs. For 8 2ms pulses the total duration would be 8x2.4+7.4=26.6ms. If pulses are made even longer at the transmitter, such as 2.2ms 8x2.6+7.4=28.2ms
Where does the 22ms limit come from?

@rmackay9

replace the receiver

I’ll try a different receiver.

@rmackay9

If you have a link to a log file

Here you can find the .bin log of the Tradheli mission above with Futaba T8FG and FrSky TFR4-B, and a .ods file with exported RCIN messages, with two aditional columns:
·theoretical train pulses duration (assuming 7ms sync and 0.4ms intervals);
.markings for the ROI losses (rows 804, 2161, 2735 and 3468).

Correction/clarification: the pulse intervals are included in the pulse width.

[Webillo]

With T8FG+TFR4-B, moving transmitter sticks and switches so as to generate maximum pulse widths manually, and reading RC_CHANNELS messages on the generated .tlog file:

For the indicated line with pulses 1941, 1940, 1751, 1940, 1814, 1940, 1940, 1941, its sum plus 7400 µs (sync pulse) gives 22607 µs.

[Webillo]

@Webillo

I’ll try a different receiver.

Testing several battteries changed on the fly and a S.BUS receiver (so a totally different pulse train (coded widths)) no ROI losses:

Pending testing a different receiver (not S.BUS).

For clarification of the pulses train timing, hera are oscilloscope captures with a 8 channel receiver connected to a pulse multiplexer, which makes available the 8 individual pulses and the pulse train:

Pulses period, SYNC period and individual pulses. The periods are different, but this may be particular for the receiver used.
Note that the pulse multiplexer output is inverted, but this should not matter with respect to timing (detected on edges).

Individual pulses. C1 to C6 are synchronized but not C7-C8. Again, this may be particular for the receiver used.

[BlackBlack777]

Hello! please tell me how to disable the function, motor interlock enabled.
I plan to fly without a remote control through the QGroundControl
application and without a remote control I cannot disarm it.

[rickyg32 (RickyG)]

And again yet another drone where the logs are not available. It’s a plague