Servers by jDrones

Copter-3.6.10 released!

stable-release
(rmackay9) #1

After a few weeks of beta testing Copter-3.6.10 has been released.

The changes are listed below and in the ReleaseNotes.txt:

  1. mRobotics ControlZeroF7 board support
  2. Motor Test sped up by removing delay that triggered CPU Watch Dog
  3. EKF improvements:
    a) learns biases even for inactive IMUs
    b) EKF uses earth magnetic field model to reduce in-flight compass errors
    c) EKF switches to first healthy IMU when disarmed
    d) IMU fix for dropped samples during high CPU usage
    e) Optical flow fusion start fix when some gyros disabled
  4. Ublox F9 GPS support
  5. Integrated CPU Watch Dog for STM boards including logging of reset reason
  6. ChibiOS I/O firmware for ChibiOS builds to support Spektrum binding
  7. Auxiliary switch changes always logged
  8. CUAVv5 Nano LED fix
  9. Solo Gimbal fix when some gyros disabled

The EKF improvements are important for handling the recovery of a failed IMU. Copter-3.6.9 was critical in terms of handling an inflight IMU failure and this release builds on that to improve handling in case the IMU recovers.

Thanks very much to the beta testers!

8 Likes
First Flight Octacopter - Crashed
Dev Call July 29 2019 2300 UTC
(rmackay9) pinned #2
Dev Call Aug 5, 2019 2300 UTC
(LJu) #3

FYI:
Upgrade from 3.6.6 ChibiOS to 3.6.10 caused parameter loading to get stuck at STAT_RUNTIME. However upgrade to 3.6.9 works :thinking:.

HW: CubeBlack

I have not tried to do a clean install by installing a plane firmware and then copter 3.6.10. Will try that later, when I have time.

(rmackay9) #4

ok, that’s not good… maybe get a parameter file when Copter-3.6.9 is loaded may provide some clues…

Also to avoid the possibility that the wrong firmware is being loaded perhaps try manually downloading and then uploading arducopter.apj from this directory.

(proficnc) #5

Mission planner or QGC?

(LJu) #6

Both MP & QGC get stuck loading the parameters. Update was done on MissionPlanner.

(rmackay9) #7

@VDLJu,

Instead of wiping all parameters, could you try perhaps loading master onto the board? This can be done by opening MP’s Install Firmware screen and then press Ctrl-Q. The version displayed below the multicopter icons should change to “3.7.0-dev”. If this works then I was wondering if you could then download a dataflash log and post it somewhere? You may need to set LOG_DISARMED = 1. If the vehicle is locking up on startup my guess is that it’s the independent watchdog that is being incorrectly triggered and a message will appear in the log written on the next startup after the lockup.

(FRED GOEDDERT) #8

I updated a Quad and one Heli from 3.6.9 to 3.6.10 both with QGC, no problems at all. But have not flown yet.

1 Like
(Mohamed Noorudeen) #9

Hey Randy,

we updated our Cubes to the new 3.6.10 stable FW today, and found the following issue across 2 different units, after updating the RCIN through SBUS is not recognised when SBUS is being fed through an IP based Digitial Datalink, in our case we tried two different type of radios, one is the Microhard PMDDL2450 and the other is the MainlinkAero M51, both of these units displayed the same issue across different cubes running 3.6.10, upon downgrading to 3.6.9 it resolved the issue. However, when feeding SBUS directly via a Frsky R9M this issue is not seen.

We have been using these radios since 3.6.5 and never had this issue.

AC 3.6.10 and error reading SBUS
Need Help trex 450 and cc3d revo
(Rick) #10

Is your datalink outputting sbus, or are you using something to translate serial or IP to sbus?

(Dave) #11

PixRacer performance is good. Most features tested.

1 Like
(rmackay9) #12

@VDLJu, can you also tell us what happens with the LEDs? A video of the LEDs during the stall would be a big help.

(rmackay9) #13

@Mohamed,

I had a chat with @tridge about this and he says that he suspects this is caused by corrupted SBUS packets that are being caught by the ChibiOS I/O firmware that is more strict in order to better catch SBUS corruption like we saw with the Pixhawk4.

If you could provide more details of your setup that might help. Tridge also suggests that we will likely either need to get the same hardware to diagnose the issue or we need the output from a logic analyser (like one from saleae.com) attached to the SBUS input/output.

1 Like
(Mohamed Noorudeen) #14

@rmackay9 @Anubis

Here’s further details of our 2 different setup:

  1. I use a ground station that outputs commands in Serial which is fed to the Base unit Microhard PMDDL2450 directly as serial and on the air we have PMDDDL2450 Picroradio the serial commands are then converted to Sbus using Serial to Sbus which is a teensy board running a code to convert it.

  2. The second unit is from MainlinkAero which accepts Direct Sbus input and Outputs Sbus, i would assume internally it is doing the same job of converting it to serial or vice versa due to the fact that the whole thing communicates in single frequency. both of them are 3 in1 units, the product is very new and there is not much info in their website about it. But i would assume this issue can be replicated with any 3 in 1 digital data links. MainlinkAero

I have a Digital oscilloscope i guess with storage the DS212 from MINI, which i had used to confirm whether or not i was receiving signal, would that be of any help? also i can procure one of the logic analyzer and send you the data provided if i know a brief of what i must givee as a sample signal as I have never used that before.

Dev Call Aug 12, 2019 2300 UTC
(tridge) #15

Hi @Mohamed, I’m the maintainer of the SBUS decoder in ArduPilot, so it is likely that I will be the one to look at these traces.
What we need is a trace which shows what is different about the SBUS signal coming out of a receiver which works and the signal which doesn’t work. A scope trace could be used, but very often it is difficult to see a complete SBUS packet with a scope. SBUS is 25 bytes (at 12 bits per byte).
The easiest sort of trace for me to work with would be a capture from a Saleae logic analyser. That will give me data that I can directly compare to what we expect, plus give me the timing in the detail needed to work out what is wrong. The Saleae Logic software can also check the serial config for us.
Make sure you capture at a high enough rate (2MHz or above would be fine).
My guess is we will find it is something like the number of stop bits being wrong, or the packet spacing not being sufficient.
Cheers, Tridge

(Mohamed Noorudeen) #16

Hi @tridge thank you for reaching out, I have just placed an order of Saleae Logic Pro 8, for troubleshooting this issue, i will update you with the capture once the unit arrives.

  • noor
(Harald Schmid) #17

Hi

Using a Radiolink minipix. It was once solved that Telemetry 1 and Telemetry 2 was swapped. Now with 3.6.10 it is swapped again. That means Telemetry 1 is on Serial 2 and Telemetry 2 is on Serial 1

BR

Harald

(Lorenzo Pessah) #18

hello,

We have the same problem with our serial-2-Sbus arduino based translator.

Is it possible to “enlarge” back the chain of Sbus decoding on AC 3.6.10? EKF compass improvements helps us quite a lot.

(Loic Chappaz) #19

@rmackay9 @tridge Is there a rough ETA for a release for 3.7.0? Is the 3.7.0 dev (which is the Master branch? Or another branch?) in its current state safe to use on a stock 3DR Solo?
I have two Iris+ at the moment and am planning to expand the fleet, I imagine the Solo would be an upgrade (would it ?) but since I plan on buying several more drones, having to spend the extra money for upgraded cubes on each is a bummer.

(mtbsteve) #20

A development version is subject to frequent change, includes newly developed and yet untested features and therefore is not to be considered as “safe”.
3.7 isn’t even in beta testing yet.
Unless you know what you are doing I would wait at least until the formal beta testing starts.