Motor Test sped up by removing delay that triggered CPU Watch Dog
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
Ublox F9 GPS support
Integrated CPU Watch Dog for STM boards including logging of reset reason
ChibiOS I/O firmware for ChibiOS builds to support Spektrum binding
Auxiliary switch changes always logged
CUAVv5 Nano LED fix
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.
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.
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.
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.
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.
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.
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.
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
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.
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
@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.
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.
.