Copter-3.6.10 released!

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.

Mission planner or QGC?

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

@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.

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

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.

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

PixRacer performance is good. Most features tested.

1 Like

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

@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

@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.

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.

  • noor

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

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.

@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.

Thanks for the reply! Fair enough and sound advice. I do understand that the not yet released version is not safe in the general sense, I should have been more precise. I meant specifically as it relates to stock Solo support and the 3v vs 5v signaling flaw, which, as I understand, will be natively supported in 3.7 without the need for an upgraded cube. And by safe, I meant in terms of the maturity of the features that will allow such support, aka no sudden motor issues.
And if I’m misunderstanding any of these points, please feel free to correct me :slight_smile:

@loicspace,

I hope we will start beta testing Copter-3.7 in 3 to 4 weeks. There are three features we need to complete:

  • Integration of object avoidance into Copter
  • Addition of stay-out zones
  • High vibration failsafe

3.7 does include two new parameters MOT_SLEW_UP_TIME and MOT_SLEW_DN_TIME which I’m pretty sure are intended to resolve the Solo’s 3v vs 5v issue (at the cost of some reduction in vehicle’s performance).

@rmackay9 Great, thanks for the update!
I’m actually also looking forward to the collision avoidance feature, since that will be an important topic when flying multiple vehicles in the same air space.
As for the Solo, that makes sense. I’m not worried about the performance cost as my application is more concerned with autonomy and robustness than “flight fun”.
I’m still new at the world of ArduPilot so for now I can only say thank you to all the developers for the amazing work, hopefully, I’ll be able to contribute back in the future.

On a more subjective note, (and off topic, happy to move that to a private message or different thread) I really like the Iris (but it’s likely a bit outdated in terms of hardware) – and I think I’ll like the Solo too (but for the software fix to the hardware flaw, and still aging) – but as I look to expand our fleet, are there other vehicles that are as RTF and capable as these, or close to, with ArduPilot compatible hardware in a somewhat budget-friendly range? From the ArduPilot ready to use doc, I also have several SkyVipers and they are great to experiment and test with, but limited obviously because of the form factor. Others seem either in the “toy” range or “commercial” range (i.e. $$$) The build from scratch route downside is scalability, as I would like to end up with a half dozen or dozen of vehicles, initially

1 Like